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."
Re:Unspoofable? (Score:3, Interesting)
wiredmikey writes with a story from Security Week where they admit "we're idiots who don't know anything about computing or, indeed, security"
These are the sorts of guys that get publishers to buy into moronic DRM schemes..
Now if. (Score:2, Interesting)
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.
Not sure if that'd work... (Score:4, Interesting)
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 [ieee.org] 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.
Re:How long do you want your ID to last? (Score:3, Interesting)
If all you want is random content on my machine that I send multiple times to you, it can be stored in normal undamaged flash and generated in a multitude of ways.
If all you want is data I can't change, on my general purpose machine, sorry, that's not gonna happen - I can just swap the whole chip (or even the whole machine).
if all you want is data I can't change, on my machine that you sold me, you can just use ordinary ROM.
Re:Argument from ignorance (Score:1, Interesting)
Exactly. the "dongle" manufacturer's claimed this with the "unchangeable" flash serial numbers in CF cards and the usb dongles.. That was gotten around in a very short amount of time. Heck I proved it on one maker that said "it's locked to the CF card".. and I replicated it 100% in that conference room, handing them a copy of their cf card that when installed in the mpeg router it worked.
Remember... HDCP was "uncrackable" a short time ago... Now it's so cracked that you can download a program for your low end quad core to decrypt 1080p and fpga's that can do it even faster will be around very soon.
er... done before? (Score:5, Interesting)
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.
And over time... (Score:3, Interesting)