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."
Obscure Security and Marketing Fud? (Score:4, Informative)
Bad blocks are inherent in NAND flash. SLC NAND Flash devices are more reliable (have fewer errors) and costly. MLC NAND Flash devices are less reliable (have more inherent errors) but are affordable and easily available. NAND Flash devices are known to progressively degrade [cyclicdesign.com] until the number of bad blocks is too high to reliably store data. Inherent errors during manufacturing increase on usage (both read and write.) Most Flash Storage Devices will ultimately become too error-prone to store data. The industry might want to justify inherent errors (and gradually increasing errors) by calling it a fingerprint. They are still searching [intel.com] for techniques to make NAND Flash more reliable.
The article fails to provide mathematical basis to prove that two NAND flashes cannot have the same bad blocks on manufacturing or at some point of usage thereby obscuring identity. NAND flash controllers are designed to check and resolve errors using known algorithms. Most controllers allow hardware to hide errors while allowing OS device drivers to read the NAND flash medium. The Operating System and the NAND Flash Controller are at least two points were any such fingerprint can be compromised. The Filesystem adds another layer of abstraction. The number of "Real" bad blocks and remaps is usually stored on the NAND Flash. Altering the Bad Block Table is not difficult.
Hard Disks interestingly have similar failure rates and complex issues like Data remanence which have been studied. I wonder why no one proposed a signature scheme for using errors on Hard Drive Platters to identify them. Computer Forensics for Hard Drives has a longer track record of being studied. Marketing fud can be ignored.
Defeated by Trusted Computing (Score:4, Informative)
Re:Unspoofable? (Score:5, Informative)
you mean I can't create a simple device [...] by using any low-cost prototyping board to spoof a USB interface? Or SATA interface?
Markus Jakobsson wrote in the article:
No need for error-correcting codes; in fact, we will read and write "raw", which is possible since all of this will be done on OS level.
He's talking about using raw NAND flash without a (hardware) controller, which is more than likely soldered to the motherboard. All USB flash drives have a controller performing error correction, as do all CompactFlash, SD, and Memory Stick memory cards. The only popular consumer flash storage devices that don't have a built-in controller are SmartMedia and xD-Picture cards; the controller for these is inside the camera or the USB card reader.
Driver level (Score:3, Informative)
Easy to spoof by implementing a flash memory emulation in a microcontroller. A chip that will behave like a flash chip, but in fact provides an extra abstraction layer and simulates faulty areas. Just like HDD controller that remaps faulty sectors to free area at the end of the disk, so from PC viewpoint the disk is fault-free and continuous, doing a similar device (which on top of remapping bad sectors, simulates ones where ones are not present, and makes them look precisely as expected) for flash seems quite easy.
Re:Unspoofable? (Score:3, Informative)
This isn't so much about DRM as verifying the source of information. Similar technologies are involved, but it's not the same concept. DRM is about obscuring information to all but authorised users, while signing information is about making sure that an authorised source has written a message (or a driver for example), and anyone is free to read it.
Why this won't work. (Score:3, Informative)
I'm an embedded designer, and I recently created a system which has a raw NAND flash memory chip installed on it. We've manufactured a few hundred of these already, and the majority NAND chips come from the factory with half a dozen bad blocks marked, but I've personally seen a few NAND chips which have *no* bad blocks.
And devices which do have bad blocks have the blocks marked as bad by programming them, so you can mark any good block as bad if you want. So there's nothing stopping me from buying a few trays of NAND, reading the bad blocks and picking out the few error-free ones, and cloning the NAND chip from one of these supposedly "unclonable because of its bad blocks" devices referred to in the original post - copying bad blocks and all.
But you don't even have to do that.
Even devices which *do* have bad blocks may not have hard failures in those blocks, where a bit is completely unable to be programmed or erased. And if you successfully erase a bad block, you've just marked that block as good again. So with enough program/erase cycles, you may be able to successfully make a bad block good again and hold the data you want. If not, move onto the next chip from your tray of NAND and try again.
And you might not even have to get that 100% right, provided you don't have more than 1 bit of error per sector between the original device and the clone. The ECC will correct that bit error, and the now-cloned device (assuming it uses a proper NAND filesystem) should just encounter the bad sector, move the block and mark the previously-bad block as bad again. At this point, you may only need to buy a few NAND chips instead of a few trays in order to clone any given NAND chip.
Now as a protection against this last idea, the device could fsck its NAND on boot and set a maximum # of new bad blocks as a tripwire for cloning protection. But if you know what that threshold is, just throw more NAND chips at the problem until you successfully program one below that threshold.
History repeating itself (Score:5, Informative)
Re:Now if. (Score:3, Informative)
because this "trusted" hardware will/can have a specialized chip that contains a non-tamperable key.
Its not easy - but TPM has been proven breakable.
http://hackaday.com/2010/02/09/tpm-crytography-cracked/ [hackaday.com]
http://www.nzherald.co.nz/technology/news/article.cfm?c_id=5&objectid=10625082 [nzherald.co.nz]
Re:Defeated by Trusted Computing (Score:3, Informative)
When you test for specific hardware behavior as a means of authentication, it's always a good idea to include speed measurements & checks in your code. That way, it's harder for the emulator to fake stuff. As this is common practice, an attack against this scheme would need to take care of these tests, as well.
Re:Nice try but (Score:1, Informative)
Actually, errors will be more likely to occur in parts of the chip that are geometrically contiguous. The physical pattern that these errors tend to occur in on any individual chip could be likened in some ways to a fingerprint for the chip, with minute width lines of imperfection coiling and spiraling around and through the chip not entirely unlike like striations in marble. No two manufactured chips would ever have the exact same pattern, and to try to reproduce a particular pattern would be costly in the extreme (wholly a matter of trial and error that could quite easily take years, if not decades), because manufacturing tolerances cannot be made equal to or better than the level of detail at which we can observe them (if they were, we could not detect errors in manufacture).