Slashdot Mirror
Unspoofable Device Identity Using Flash Memory
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."
Just because we don't know a way. That doesn't mean it can't be done.
"I'm unspoofable! Not even Zeus himself could spoof me!"
Some of my favourite people are from th US; Vonnegut, Chomsky, Bill Hicks.
...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?
So what? We connect another memory device through an FPGA and emulate the error pattern. At least to the extend detected by the software.
Someone could just create an emulator/interpreter to sit between the chip and the PCB. It reads the input, responds correctly for the emulated chip, and puts it a good or bad space according to what the emulated chip should be.
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?
Given a legitimate device all I have to do is make my device return fake bad sector errors (I'm assuming a file system here) in the same sectors they do and that's just one idea, you can exploit this at few other places alone the line (literally and metaphorically).
The last line in TFA gives the problem in this scheme:
"If we run a secure boot or a reliable software-based attestation scheme before we ID a device, we know that there is no active malware that may modify the report that results from reading the machine identity. So we know that the reading actually comes from the intended block, and that it was done correctly."
However if this secure boot thingy is comprimised you can force to read it form a virtualized memory block that contains a forged block. . You can beat this with all secure hardware, but at that point having generic nand memory is not the point, because this "trusted" hardware will/can have a specialized chip that contains a non-tamperable key.
From what I know of flash, the 'bad bits' aren't repeatedly bad. The bad-sector-swap-out-routine in most flash drives and USB sticks will actually swap out a sector after a single read that can't be ECC-corrected, but that doesn't mean all the bits in the sector can't be written correctly ever again.
For example, in this article (IEEExplore, so paywalled for you, sorry) a generic NAND flash chip has been tested for bit-error-rates. In the 5K write cycles after an average bit has failed, it only failed to be written correctly 4 times more. That would mean that a single erase-rewrite cycle would write the complete sector without any bit errors 99% of the time: to find 'most' of the bad bits, the sector would have to be rewritten 1000s of times every time the software would want to check the fingerprint.
Not only would that take a fair amount of time, it would also introduce new failed bits. That would mean the ID of the flash chip can only be checked so many times beffore the complete sector goes bad.
I don't understand any of this guy's arguments. First of all he states that we are "desperate" for a way to uniquely identify machines, and that the best way to fight fraud is to put unique IDs on processors. I'm sorry; for what reason are we desperate to expose our identity to every other computer that happens to connect with ours, and are crooks not able to replace their CPUs? Last time I checked, purchasing new hardware also did not require a license or verification of ownership so how this would stop fraud is anyone's guess.
With regard to the actual flash ID technique, I thought any decent flash device (e.g. all SD cards) would have a wear-leveling controller, which effectively means the physical address is hidden. Even if you were to write "raw from the OS" as he says, the OS does not have raw access in this context. It doesn't even have "raw" physical access to system memory if you consider the funny stuff that memory controllers can do (e.g. ganging, interleaving).
So if you have a bad block somewhere, the flash controller remembers where it is, but the OS has no practical guarantee unless the device remains untouched, and that eliminates any usefulness for this theory. Maybe I'm missing something obvious here but it seems to me that this suggestion is bunk. To do what he's proposing would require getting past the flash controller to get direct access to the NAND, or be able to put the flash controller into some low-level diagnostic mode to make it give you real physical addresses instead of virtual ones.
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..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?
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?
Especially if that plastic surgery was done unintentionally just by looking at him one time too many.
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.
Microsoft's Windows activation thing could become even more annoying in the future.
Well, the "device identity verification" is always done by a software.
Won't take long till it is reversed, and a "patched" executable released,
so that it always gives the "right answer".
Super easy with nano-technology. They can position atoms at will, for fucks sake.
Spoof my ass.
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 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 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.
No Greater Friend, No Greater Enemy! (Lucius Cornelius Sulla)
Spoofing means to make a parody of or mis-represent.
I guess I'm too old, but for me, spoofing meant The Three Stooges : http://en.wikipedia.org/wiki/Three_Stooges
If they were alive today, they'd be connecting water mains to your Internet tubes, so you would get a splash in your face, when you pull the cable on your DSL.
Then you would hear, "Oh a wise guy eh? Nyuk, nyuk nyuk!"
Schroedinger's Brexit: The UK is both in and out of the EU at the same time!
The device emulator that you suggest would fail a Trusted Platform Module check. From the article: "run a secure boot or a reliable software-based attestation scheme".
a piece of software to alter the signal
Please see my answer in another comment.
There are tons of problems with this, not the least of which lies in the fact that if you have a secure boot and trusted environment, you don't really need a NAND chip to read an identity from, you can make do with a file that user cannot remove or alter, i.e. a system file. That's what trusted would mean here. This however presents another problem - amount of users willing to use such a "trusted" system is inversely proportional to how many of these users grok computers. Typically, your mildly paranoid hackers and UNIX minimalists will reject such system on sight because they value their right to introspection and control, while someone like their moms and dads with Windows won't even know or care as long as they can write their Word documents and send email. Then again, the first group goes out of their way to enlighten all other groups on how to grok more IT, including deleting all cookies, which is freely available through Googling, including links to software that does it for you with a click of a button. Making a completely secure identification scheme, if possible, would lead to revolt in the first group (and outright rejection, as mentioned) and an active propaganda with the aim of educating all the other groups against using the method again.
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.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
With regard to the actual flash ID technique, I thought any decent flash device (e.g. all SD cards) would have a wear-leveling controller
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.
It appears he refers to raw NAND flash chips without a dedicated hardware controller in front, soldered directly to the motherboard. These chips don't behave like an SD or CF or SATA or USB device; they're more like xD-Picture cards.
This is the kind of DRM that gets spoofed in a week with a highlighter.
If all you want is data I can't change, on my general purpose machine, sorry, that's not gonna happen
Then the major motion picture studios can choose not to sell or rent their works to you if you choose to use only a general-purpose machine. Some major video game developers have made similar decisions.
SafeDisc (and older DRM schemes) detected bad sectors on disks, which are hard to duplicate. On the other hand, they've very easy to emulate. This technique sounds very similar, and the fact that they haven't addressed the emulation issue makes me VERY skeptical.
While the idea is good a system is only as strong as it's weakest part. He completely skims over the solutions for reading these keys. Yes the keys themselves can't be replicated reliably in the same format, but it would still be vulnerable to MITM attacks.
But then again this is often the case with new security technology isn't it, in theory it is flawless and unbreakable if you could only implement the new technology in a system where all the other parts are also secure and unbreakable.
Sounds like something that I read many years ago that was being done to 5-1/4 floppies. There was copy protection scheme that catalog the weak bad bits, or sectors, of an original floppy. Making a copy of that original disk would not have the same weak bits thus when the copy protection, during installation, would not find those original weak bits on the new floppy the software would shut down and not install. The method around this copy protection scheme was to copy the floppy thru an analog reading, rather than digital, so that it would copy everything including the positions of the weak bits and pass that on to the new floppy. I forgot the name of the company that made this digital-to-analog pc card.
Unspoofable? Buahahahaha!
And they want their cartridge protection scheme, or band protection scheme, or even their 90th cousin 5 1/4 and 3 1/2 inches protection scheme back. And their little brother from the 00th with CDROM and DVD rom protection back. All of which are crackable if the OS / firmware / driver is tasked to spoof whatever is need to pass the protection.
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.
Really, this just goes to prove the ease with which patents are granted. The same idea has been patented with DRAM. That too has manufacturing variety. And those faults too are not bit for bit reliable, but combined they statistically are unique and reliable. This patent seems to be "like DRAM but with Flash cells.
(In the DRAM case, the manufacturing variance causes a particular bitpattern after a chip is reset - some bits are more likely to zero than others)
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.
This sounds like an early 80s copy-protection scheme that depended on the bad-sector map of the installed hard drive to identify it. It was reliable because only a low-level format would change the pattern, and very few people ever did a low-level format to their drives. The scheme failed when production improved and most drives could be manufactured error-free.
...I think the authors are oversimplifying way too much.
OK, you take your flash, write it until it breaks, and use the resulting cells to determine an identity. How do you read it? Write it, then read back which cells aren't written. Uh, wait, if you read it by writing it, won't you cause more failures?
Furthermore, flash often doesn't fail so cleanly. Some cells will simply not write to 0. However, other times, they will become leaky and read as 0, but then flip back to 1 at some later time. So the apparent device identity may depend on the time between the write and the read, and other factors less controllable.
Also, I'd wonder how uniform the defects are. It's quite possible that defects in a flash memory block may be much more likely to occur in some parts of a block than others.
And, emulating it is easy assuming I can use something much faster than flash (e.g. SRAM) to do the emulation.
Prior to that, they had a similar issues with bad tracks on floppies, and I believe software CD's as well.
It's not really a new concept, and besides other than DS carts I don't see much software actually being *distributed* on flash, or do they plan on locking the software itself to defects on a given machine?
Just like how HTTP Referrers cannot be spoofed, because the person would need to navigate to exactly the same pages as the target.
What they are saying is that this hardware has a unique "biometric" and that can be used to definitively identify true chips/boards from fake. Hmmm...
First thought that popped up is that this isn't new: floppy disks were "copy protected" using defects punched into the original disk. That didn't work out very well so why would this?
Second thought was that biometrics have strengths and weaknesses and are not unspoofable. Why would this be any different?
Several other things come to mind:
1. If a h/w encoded w/o (write only) serial number is not good enough, why is this better? Is it because it is cheaper? ie: the flash mem is already there so additional gates/circuitry is not required?
2. What happens if the h/w tech changes? ie: flash mem is no longer cheap and ubiquitous because the whole h/w base has moved to a new technology? In other words, it binds h/w verification, which we want to be a reliable long term solution, to h/w technology which is highly volatile. Probably not a good idea.
3. There is an assumption that these defects are random. I know from experience that many things we assume to be random are actually patterned and predictable. For example: I have observed DRAM chips that power on with repeatable bit patterns that sometimes vary with production run. Highly consistent, quality controlled production runs tends to remove entropy from the product. Faults and errors occur but within well defined constraints. So... disk drives used to fail within a fairly broad standard deviation from the MTBF but now, in a storage centre with hundreds of drives, I get multiple drive failures almost all at once. The standard deviation is much narrower because the manufacturing process is so well controlled. I used to replace drives when they failed and I was confident that the spares and RAID set redundancy would be sufficient to cover the rebuild time. Now I replace drives before the point in time when I expect failures to start because I can get multiple drive failures within the disk rebuild time. The failures are random but correlated. Go figure. Fortunately, tech change often happens before pre-emptive replacement is required.
If we base a h/w verification scheme on the randomness of some aspect of a manufactured product then the scheme is bound to the manufacturing process. If you change your process then you change the verification confidence and security. Not good to make these things dependent.
I think that if there is a need to provide h/w verification then the scheme should be controllable and independent of h/w technology and processes. It should also be able to encode other information with it (er ... it should be extensible). Code a w/o number onto the chip that works like PGP or a cert. Forget about biometrics.
So what happens as you continue to use the flash and new error regions show up?
Outstandingly informative post. Thanks for taking the time to share your invaluable knowledge and experience!
What do I need the NAND for?
This whole thing is dumb. If I had a system which already couldn't be tampered, I wouldn't need this NAND thing. And for the NAND, I can read out all the info about the NAND that could possibly be used as a key and then replicate it in a hardware-based emulator that I attach to the board in place of the NAND, leaving the rest of the system in place so it can answer any difficult security questions that are asked.
The NAND system adds nothing of value because it is replicable. Even if you can make a secure system from it, the rest of the system is doing all the security and the NAND adds nothing.
http://lkml.org/lkml/2005/8/20/95
I think German said the same thing about their Engima machines.
ELOI, ELOI, LAMA SABACHTHANI!?
They are relying on the fact that once a bit goes bad it will never fix itself, so it doesn't matter much if a few more errors creep in. Let's say
They are just trying to sell stuff that fails QA as useful for something, something everybody was made to be afraid of.