Unspoofable Device Identity Using Flash Memory 145
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."
Argument from ignorance (Score:5, Insightful)
Unspoofable? (Score:5, Insightful)
...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?
Sigh. We can emulate it. (Score:5, Insightful)
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)
How long do you want your ID to last? (Score:4, Insightful)
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?
What if one more bit goes bad during normal usage. (Score:3, Insightful)
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?
Doesn't know what spoofing means. (Score:5, Insightful)
This may be an unduplicatable ID, but it is a far cry from unspoofable.
Re:Argument from ignorance (Score:5, Insightful)
Can't you create a device emulator and emulate the defects?
Re:Famous last words? (Score:4, Insightful)
At first It was mechanical punctures on floppies, then random laser marks on CD, now this...
Re:Unspoofable? (Score:5, Insightful)
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?
Re:Defeated by Trusted Computing (Score:5, Insightful)
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.
Re:Argument from ignorance (Score:5, Insightful)
If it can be done in software then it's cheap...hackers have a lot of spare time.
Re:Argument from ignorance (Score:3, Insightful)
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
Re:Defeated by Trusted Computing (Score:1, Insightful)
Re:Why? (Score:3, Insightful)
Stop discouraging them! Let them think their scheme is flawless so that they'll actually implement it instead of something stronger.
We don't "desperately need" device identity (Score:3, Insightful)
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.
Re:Defeated by Trusted Computing (Score:4, Insightful)
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.