Forgot your password?
typodupeerror
Security Hardware Technology

Unspoofable Device Identity Using Flash Memory 145

Posted by timothy
from the double-edged-sword dept.
wiredmikey writes with a story from Security Week that describes a security silver lining to the inevitable errors that arise in NAND flash chips. By seeking out (or intentionally causing) defects in a given part of the chip, a unique profile can be created for any device using NAND flash which the author says may be obscured, but not reproduced: "[W]e recognize devices (or rather: their flash memory) by their defects. Very much like humans recognize faces: by their defects (or deviations from the 'norm') a bigger nose, a bit too bushy eyebrows, bigger cheeks. The nice twist is that if an attacker manages to read your device identity, he cannot inscribe it into his own device. Yes, he can create errors — like we did. But he cannot control where in the block they occur as this relies solely on microscopic manufacturing defects in the silicon."
This discussion has been archived. No new comments can be posted.

Unspoofable Device Identity Using Flash Memory

Comments Filter:
  • by zero.kalvin (1231372) on Friday October 15, 2010 @05:02AM (#33905746)
    Just because we don't know a way. That doesn't mean it can't be done.
  • Unspoofable? (Score:5, Insightful)

    by Anonymous Coward on Friday October 15, 2010 @05:13AM (#33905790)

    ...you mean I can't create a simple device that works as a flash drive, but every time the OS requests a bad block, it responds with an entirely fake response that just so happens to match the identity of the spoofed drive? Say, by using any low-cost prototyping board to spoof a USB interface? Or SATA interface?

  • by JensR (12975) on Friday October 15, 2010 @05:14AM (#33905792) Homepage

    So what? We connect another memory device through an FPGA and emulate the error pattern. At least to the extend detected by the software.

  • Why? (Score:4, Insightful)

    by jgoemat (565882) on Friday October 15, 2010 @05:17AM (#33905802)
    I fail to see the utililty... If the OS can be compromised, this doesn't help at all. If it can't, then why bother?
  • by jojoba_oil (1071932) on Friday October 15, 2010 @05:28AM (#33905834)

    So let me get this straight... They "create" an ID by writing and rewriting a bunch of bits until they start failing, then mark the whole block bad. To "read" the identity, they set all bits to 0 and see which ones are stuck at 1 and then set all bits to 1 to see which are stuck at 0. The "bad block" ID area has already been written to thousands of times intentionally. What's going to guarantee that by "reading" the bad block ID (with 2 assignments each time), we won't unintentionally be making the final write to an extra bit or two?

  • by Anonymous Coward on Friday October 15, 2010 @05:30AM (#33905842)

    What if one more bit goes bad during normal usage..Identity is gone. Any thing tied to it will stop working.."Very much like humans recognize faces: by their defects"..if your son had plastic surgery without your knowledge..you will fail to recognize him?

  • by thegarbz (1787294) on Friday October 15, 2010 @05:37AM (#33905852)
    Spoofing means to make a parody of or mis-represent. Spoofing does not imply that you're duplicating the original device it means that you make others think it's the original device. You don't need to re-create the hardware errors to do this, just intercept the calls which are looking for this hardware ID, and then spoof it.

    This may be an unduplicatable ID, but it is a far cry from unspoofable.
  • by Joce640k (829181) on Friday October 15, 2010 @05:56AM (#33905924) Homepage

    Can't you create a device emulator and emulate the defects?

  • by pegdhcp (1158827) on Friday October 15, 2010 @05:57AM (#33905932)
    "All this has happened before, and all this will happen again!"

    At first It was mechanical punctures on floppies, then random laser marks on CD, now this...

  • Re:Unspoofable? (Score:5, Insightful)

    by Thanshin (1188877) on Friday October 15, 2010 @06:05AM (#33905966)

    And the most retarded part is that just about everyone in any technical community can tell them why the idea is idiotic, useless and dangerous. I mean, there are pretty few things the internet does better than highlight your stupidity; they should learn to use that wonderful virtue.

    Can someone send them a simple email explaining how to first post their new ideas in a tiny forum so children can tell them why it won't work, before talking to the news?

  • by KiloByte (825081) on Friday October 15, 2010 @07:03AM (#33906232)

    If you have a working Treacherous Computing setup that you believe isn't breached, what would you want the technique in the article for? With working TC, you have all of that and more. Without TC, it can be worked around with a simple kernel patch.

  • by Joce640k (829181) on Friday October 15, 2010 @07:26AM (#33906360) Homepage

    If it can be done in software then it's cheap...hackers have a lot of spare time.

  • by JeffSpudrinski (1310127) on Friday October 15, 2010 @07:51AM (#33906474)

    Very true.

    It's getting almost funny how someone states that something is "unbreakable" or "uncopiable" (remember quantum encryption stories?) and then a few months later, someone finds a workaround, or some previously unthought of method of breaking the security.

    That said, though, relying on random microscopic flaws for unique identity is very clever and would be *extremely difficult* (not impossible) to copy.

    Not saying I can do it, but I'm sure someone...somewhere...will figure out a way.

    Just my $0.02.

    -JJS

  • by Anonymous Coward on Friday October 15, 2010 @08:09AM (#33906576)
    In a virtual machine, time is adjustable too. It can easily run 1000 times slower without the code knowing it.
  • Re:Why? (Score:3, Insightful)

    by Wonko the Sane (25252) on Friday October 15, 2010 @08:11AM (#33906590) Journal

    Stop discouraging them! Let them think their scheme is flawless so that they'll actually implement it instead of something stronger.

  • by time961 (618278) on Friday October 15, 2010 @08:42AM (#33906774)
    Schemes like this are (as others have observed) pretty common, and don't address the real problem: what we "desperately need" is a trustworthy way of knowing that an automated system is acting in accord with its owner's intent. Alas, that does not seem to be on the horizon.

    I mean, suppose my computer has "secure boot" and "unspoofable identity" and "remote attestation". That's great, if my goal is to prove to the secure server at the other end of the connection that I am running various specific (albeit a priori bug-infested versions) of Windows, drivers, browsers, JVMs, etc. But that's a silly goal, because my adversary is just going to take advantage of it, by running malware on my system that looks like it's acting on my behalf (after all, it has ready access to my unspoofable identity) but is actually transferring the contents of my bank account to the Netherlands Antilles without my knowledge.

    Not to mention the general uselessness of "remote attestation" that a TPM provides: it may be able to attest to your configuration (modulo flaws in your gigabytes of software that enable attestation to be subverted or bypassed), but how on earth is the remote end going to make a meaningful decision based on the identity of hundreds or thousands of components that are attested to? Sure, it can reject known bad (flawed) components, but it's preposterous to imagine that you can know what all the bad components might be. Remote attestation is a plausible way of validating that a machine's configuration is the same as it was when it left a corporate IT department, but for making decisions about arbitrary machines in the hands of arbitrary consumers, it's useless.

    And as for this specific scheme, come on: it might be a way to identify a flash device reliably if you have the hardware in hand, but, as described, it's done in software. That's right, software, which can be made to emulate any particular configuration of bit errors it desires, without there necessarily even being a physical flash device in the picture. Yes, for limited-resource embedded systems, and environments where access timing can be inferred with high accuracy, there are tricks one can use to make such attacks difficult, but for general-purpose PCs connecting over unreliable high-latency networks? Nope... not without mountains of false alarms.

    Make no mistake: trustworthy computing is a hard problem. Unique IDs are fun to research, but not closely related to the solution.
  • by maztuhblastah (745586) on Friday October 15, 2010 @09:59AM (#33907512) Journal

    If you have a working Treacherous Computing setup that you believe isn't breached, what would you want the technique in the article for?

    Funding.

Man must shape his tools lest they shape him. -- Arthur R. Miller

Working...