Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Unspoofable Device Identity Using Flash Memory

timothy posted more than 3 years ago | from the double-edged-sword dept.

Security 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."

cancel ×

145 comments

Argument from ignorance (4, Insightful)

zero.kalvin (1231372) | more than 3 years ago | (#33905746)

Just because we don't know a way. That doesn't mean it can't be done.

Re:Argument from ignorance (-1, Troll)

Anonymous Coward | more than 3 years ago | (#33905758)

Just because zero.kalvin claims he once got laid doesn't make it true.

Re:Argument from ignorance (3, Funny)

Anonymous Coward | more than 3 years ago | (#33905786)

The paternity test and court-ordered child support, however, is compelling evidence.

Re:Argument from ignorance (1)

oPless (63249) | more than 3 years ago | (#33906402)

Not to mention the restraining order.

Re:Argument from ignorance (4, Insightful)

Joce640k (829181) | more than 3 years ago | (#33905924)

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

Re:Argument from ignorance (1)

Nerdfest (867930) | more than 3 years ago | (#33905964)

This translates to "It can't currently be done cheaply".

Re:Argument from ignorance (1)

someone1234 (830754) | more than 3 years ago | (#33906002)

How cheap is some code that:

1. reads an existing pattern
2. outputs that pattern via the known device interface.

Re:Argument from ignorance (4, Insightful)

Joce640k (829181) | more than 3 years ago | (#33906360)

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

Re:Argument from ignorance (1)

multisync (218450) | more than 3 years ago | (#33907458)

If you have "spare time" you're probably not a hacker.

Re:Argument from ignorance (1)

Abstrackt (609015) | more than 3 years ago | (#33907234)

This translates to "It can't currently be done cheaply".

So it's reasonably secure for day to day stuff then.

Defeated by Trusted Computing (3, Informative)

tepples (727027) | more than 3 years ago | (#33906032)

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".

Re:Defeated by Trusted Computing (4, Insightful)

KiloByte (825081) | more than 3 years ago | (#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.

Re:Defeated by Trusted Computing (1)

RichiH (749257) | more than 3 years ago | (#33906298)

Not simple as timing will definitely be used in a scheme like this. Still, it sounds hard, not impossible.

Re:Defeated by Trusted Computing (1)

Joce640k (829181) | more than 3 years ago | (#33906386)

I think the hard part will be getting some quality time alone with the device you're trying to clone.

Still ... this is just some academic paper. I doubt it will ever be used in practice.

Re:Defeated by Trusted Computing (1, Insightful)

Anonymous Coward | more than 3 years ago | (#33906576)

In a virtual machine, time is adjustable too. It can easily run 1000 times slower without the code knowing it.

Re:Defeated by Trusted Computing (1)

leuk_he (194174) | more than 3 years ago | (#33906788)

No... read again. If you run a TPM module [hp.com] (BAD certificate... HP how could you fuck up the certificate on a article on a TPM product... :X :X ) you get:

" HP-UX Trusted Computing Services (HP-UX TCS) provides software support for hardware-enforced key management "

Meaning that the TPM provider already providedd some means to create a unique identification, supported by $$$ hardware. HP determines what you can do wiht this id. You don't owe that hardware, HP does. But TPM hardware is required for trusted booting. Why add som cheap software hack is the TPM hardware has this capability. and you cannot apply the cheap software hack to simple software because the environment is not trusted (malware infested or virtualized)

Re:Defeated by Trusted Computing (1)

PremiumCarrion (861236) | more than 3 years ago | (#33907144)

I'm somewhat confused as to why timing would be a problem, typically I believe processors are a little faster than flash memory devices.

Re:Defeated by Trusted Computing (3, Insightful)

maztuhblastah (745586) | more than 3 years ago | (#33907512)

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.

Re:Argument from ignorance (1)

nospam007 (722110) | more than 3 years ago | (#33907016)

Sure, 30 years ago there were floppy copy protection schemes with damaged areas, (uncopyable! they called it) after a couple of weeks somebody had found a way to simulate the damage.
They never learn.

Re:Argument from ignorance (-1, Troll)

airjordans11 (1922186) | more than 3 years ago | (#33906018)

Very nice post. I really enjoy the reading. I come here from the google while searching for some good article.Thanks
<a href="http://www.sneaker-trade.com/" rel="dofollow"><b>Air jordans</b></a>
<a href="http://www.sneaker-trade.com/" rel="dofollow"><b>Michael jordan shoes</b></a>
<a href="http://www.discount-coachhandbags/" rel="dofollow"><b>coach handbags</b></a>
<a href="http://www.sneaker-trade.com/" rel="dofollow"><b>air jordan 11</b></a>
<a href="http://www.sneaker-trade.com/" rel="dofollow"><b>air jordan shoes</b></a>
<a href="http://www.sneaker-trade.com/air-jordan-c-681.html" rel="dofollow"><b>air jordan</b></a>
<a href="http://www.sneaker-trade.com/" rel="dofollow"><b>brand handbags</b></a>
<a href="http://www.sneaker-trade.com/" rel="dofollow"><b>NFL jerseys</b></a>
<a href="http://www.sneaker-trade.com/" rel="dofollow"><b>brand sunglasses</b></a>

Re:Argument from ignorance (2, Insightful)

JeffSpudrinski (1310127) | more than 3 years ago | (#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

Re:Argument from ignorance (1, Interesting)

Anonymous Coward | more than 3 years ago | (#33906478)

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.

Re:Argument from ignorance (0)

Anonymous Coward | more than 3 years ago | (#33906706)

Thats nice, but
Laser DVD Stripe never used
HD Magnetic Strip+ disk read head = never used
Japanese Ink Spots - Never Used
Making use of mobile phone - hah uncommon.

These do the job very well, but as consumers have credit card protection, and the banks make big money
on card fraud and don't want it fixed. The above solutions cost pennies.

Famous last words? (4, Funny)

migla (1099771) | more than 3 years ago | (#33905766)

"I'm unspoofable! Not even Zeus himself could spoof me!"

Re:Famous last words? (3, Insightful)

pegdhcp (1158827) | more than 3 years ago | (#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...

Unspoofable? (5, Insightful)

Anonymous Coward | more than 3 years ago | (#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?

Re:Unspoofable? (2, Interesting)

somersault (912633) | more than 3 years ago | (#33905796)

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..

Re:Unspoofable? (1)

dna_(c)(tm)(r) (618003) | more than 3 years ago | (#33905944)

My first thought was about DRM too, and from there immediately to "it 'll only last for a few days"

Re:Unspoofable? (1)

somersault (912633) | more than 3 years ago | (#33906066)

Yeah. I don't know that much about security, but I think having a board on the device to digitally sign data from the drive would be better (public key cryptography type thig). At least that way you couldn't simply copy the device's signature using a program in the machine it's plugged into. If you design it right you'd have to have physical access to the internals of the device to copy its private key.

Re:Unspoofable? (0)

Anonymous Coward | more than 3 years ago | (#33906208)

Dude! Can you stop already?! We're trying to defeat DRM --- not enhance it.

Jeez.

Re:Unspoofable? (0)

Anonymous Coward | more than 3 years ago | (#33906300)

Oh wait... The Wii tried to do what he described (public/private keys) and failed pretty miserably. See old posts at HackMii [hackmii.com] for details.

Re:Unspoofable? (1)

somersault (912633) | more than 3 years ago | (#33906626)

I wasn't talking about public/private keys for DRM, I was talking about verifying sources of information (information which anyone is free to read). I also implied it would probably be possible to copy the private key if you had physical access to the device. With the Wii or an iPhone or whatever you wouldn't even need to have access to the private key to sign software, you would just need some way of making the device think that all sources are authorised.

Re:Unspoofable? (1)

silanea (1241518) | more than 3 years ago | (#33906326)

[...] We're trying to defeat DRM --- not enhance it. [...]

Those two are the same. Any truly secure DRM renders the protected content unusable, thereby rendering the DRM useless.

Re:Unspoofable? (2, Informative)

somersault (912633) | more than 3 years ago | (#33906594)

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.

Re:Unspoofable? (4, Insightful)

Thanshin (1188877) | more than 3 years ago | (#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?

Re:Unspoofable? (0)

Anonymous Coward | more than 3 years ago | (#33906550)

I guess they thought they could maybe post to relevant forums asking people to help find the flaws - and probably receive zero feedback as most people can't be bothered helping someone else finesse their project. Alternatively they can form their statement as a challenge - our idea is unbeatable - and let the egos of a million geeks do the work for them. They now have a ton of useful ideas they can test against to improve said product, and all it cost them was a little public humiliation.

Re:Unspoofable? (1)

Thanshin (1188877) | more than 3 years ago | (#33906692)

It's a nice theory but if that was the case, wouldn't they get a higher level response by presenting an idea with less obvious flaws?

Or you mean they didn't have in the vicinity anyone technically able to help them correct some of the most obvious problems.

Re:Unspoofable? (4, Informative)

tepples (727027) | more than 3 years ago | (#33906060)

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.

Re:Unspoofable? (1)

JasterBobaMereel (1102861) | more than 3 years ago | (#33906580)

Can this be emulated - Yes

Since this relies of flaws in the silicon - it is surely really easy to accidentally change the error profile of a device so it is no longer recognised ...

This is the flaw in facial recognition as well, to make it so that it does not report false negatives it is easier to fool as well

Sigh. We can emulate it. (4, Insightful)

JensR (12975) | more than 3 years ago | (#33905792)

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

What if one more bit goes bad during normal usage. (3, Insightful)

Anonymous Coward | more than 3 years ago | (#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?

Re:What if one more bit goes bad during normal usa (4, Funny)

jojoba_oil (1071932) | more than 3 years ago | (#33905848)

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.

Re:Sigh. We can emulate it. (1)

L4t3r4lu5 (1216702) | more than 3 years ago | (#33905846)

I get the impression that they would apply a specific "identity creation" process to the NAND chip, and that would bring out the inherit flaws in the chip fab process. You can apply the same process to other silicon, but you won't get the same result.

You may well be able to emulate it using some awesome hardware, but how is that going to help if this is using your mobile phone internal memory for purchase authentication? You going to carry around your FPGA emulation rig to spoof payment authorisation?

Re:Sigh. We can emulate it. (1)

Lazareth (1756336) | more than 3 years ago | (#33905920)

If the authentication is going over a signal being emitted from your mobile, a piece of software to alter the signal to send a "correct" signal is all you need.

Trusted Computing (1)

tepples (727027) | more than 3 years ago | (#33906088)

a piece of software to alter the signal

Please see my answer in another comment [slashdot.org] .

Re:Trusted Computing (1)

Lazareth (1756336) | more than 3 years ago | (#33906236)

Oh, I see. So their claim is unattackable because their initial assumption is that no attempt to spoof is being made, thus they are unspoofable. I see the logic. Pass along.

Re:Trusted Computing (1)

r_a_trip (612314) | more than 3 years ago | (#33906320)

What point is using NAND flaws for ID, if they already have an encrypted key on your device in the TPM to which they hold the private key.

It's a bit like using minoxidil against male hairloss when your testicles have already been surgically removed.

TPM is currently a very hard to spoof ID mechanism. No need for NAND flaws.

Re:Sigh. We can emulate it. (1)

Peeteriz (821290) | more than 3 years ago | (#33906030)

How is an external device know what defects are in my silicon? The bits flowing through the connector will tell it whatever I want.

Re:Sigh. We can emulate it. (1)

tepples (727027) | more than 3 years ago | (#33906106)

How is an external device know what defects are in my silicon?

The device is not external. Please see my other comment [slashdot.org] .

Re:Sigh. We can emulate it. (0)

Anonymous Coward | more than 3 years ago | (#33906834)

You know, there is this technology [google.be] which can spoof something external to be internal.

Re:Sigh. We can emulate it. (1)

tepples (727027) | more than 3 years ago | (#33907582)

System requirements for the technology that you mention include soldering, and a lot of end users don't have the coordination to solder a TSOP [wikipedia.org] or especially a BGA [wikipedia.org] correctly.

Re:Sigh. We can emulate it. (1)

jojoba_oil (1071932) | more than 3 years ago | (#33906084)

but how is that going to help if this is using your mobile phone internal memory for purchase authentication?

There are already systems in place for that: SIM cards and electronic serial numbers. Neither of those require purposefully breaking read-write memory in a way that provides no benefit over simple ROM, and both are just as "unspoofable" as this is. Not to mention that SIMs/ESNs have a much reduced chance of randomly changing the identity.

Re:Sigh. We can emulate it. (1)

tepples (727027) | more than 3 years ago | (#33906124)

There are already systems in place for that: SIM cards and electronic serial numbers.

Neither of which will help if you have removed the SIM card in your unlocked smartphone to use it as a PDA.

Re:Sigh. We can emulate it. (1)

jojoba_oil (1071932) | more than 3 years ago | (#33906254)

Neither of which will help if you have removed the SIM card in your unlocked smartphone to use it as a PDA.

With the example of iPhone/iPodTouch, they still have EDID (basically ESN) when no SIM is present... And if you never connect the device to a network, the whole reason for having this kind of ID is moot anyway.

I don't understand what you're trying to argue here.

Emulate? (1)

tagno25 (1518033) | more than 3 years ago | (#33905798)

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.

Why? (3, Insightful)

jgoemat (565882) | more than 3 years ago | (#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?

Re:Why? (1)

amn108 (1231606) | more than 3 years ago | (#33906304)

Precisely. And compromising an OS is in fact an expected norm by any self-respecting computer user. It goes together with having the right to f.e. change system files etc. So the second question is valid: why bother? For those with "trusted computing" systems however, it's a whole other mixbag.

Re:Why? (2, Insightful)

Wonko the Sane (25252) | more than 3 years ago | (#33906590)

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

Easy (0)

Anonymous Coward | more than 3 years ago | (#33905816)

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).

Now if. (2, Interesting)

leuk_he (194174) | more than 3 years ago | (#33905826)

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.

Re:Now if. (1)

JasterBobaMereel (1102861) | more than 3 years ago | (#33906598)

The maxim of security is that if you have physical access to the hardware then all security is pointless

This is why you are always kept one (or more) steps away from the actual hardware in secure systems

If you can secure clean boot the system then you have physical access and you can manually verify the system so this is unnecessary, if you can't then it is not reliable

Another solution looking for a problem ....

Re:Now if. (0)

Anonymous Coward | more than 3 years ago | (#33906812)

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.

True, but there are still some use cases where this scheme seems useful such as credit cards. In that case, the reader has a vested interest in remaining trusted (since the reader's owned by a merchant who will most likely be on the hook for fraudulent purchases) while the chip would contain an identity that the reader wants to verify.

Not sure if that'd work... (4, Interesting)

Sprite_tm (1094071) | more than 3 years ago | (#33905828)

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.

What about the wear-leveling flash controller? (0)

Anonymous Coward | more than 3 years ago | (#33905832)

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.

Controllerless flash (1)

tepples (727027) | more than 3 years ago | (#33906172)

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.

Re:Controllerless flash (1)

Peeteriz (821290) | more than 3 years ago | (#33906768)

It means that I control the hardware (motherboard) which does the identity checking - and for any practical purpose of identification, it means that I can force it to claim that "yes, I have a NAND chip with xxxx pattern" to anyone who wants to identify my harware - say, a software program installer or a networked device. It's just like the processor ID numbers, which were embedded in the silicon and 'unchangeable'.

It's just like spoofing a hardware dongle - since the consumer OS isn't "trusted", almost anything which goes through it can be spoofed.

The only way how I imagine this feature somehow working would be someone having a secure/trusted physical device outside of your control, where they ask you to put in your flash-memory, like a chip-card reader.

How long do you want your ID to last? (3, Insightful)

jojoba_oil (1071932) | more than 3 years ago | (#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?

Re:How long do you want your ID to last? (2, Interesting)

redhog (15207) | more than 3 years ago | (#33905900)

That can be fixed by using some kind of error recovery code. But I still don't see the utility of this. It's just a ROM with random content for every device.

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.

Sorry, appliances only. (1)

tepples (727027) | more than 3 years ago | (#33906192)

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.

Re:Sorry, appliances only. (1)

John Hasler (414242) | more than 3 years ago | (#33906542)

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.

And, of course, no one can live without those movies...

Re:Sorry, appliances only. (1)

tepples (727027) | more than 3 years ago | (#33906690)

For one thing, intentionally remaining ignorant of part of the popular culture would make me look like the Area Man Constantly Mentioning He Doesn't Own a Television [theonion.com] . For another, even if I don't buy copies of movies, enough other people do that MPAA studios' business model remains sustainable. Once enough things are blocked from general-purpose computers, the economies of scale in making and selling home computers become weaker, and home computers eventually get discontinued in favor of home-priced appliances and business-priced workstations. This arguably happened to set-top home computers in the 1980s, leading to the great console/PC split.

Re:Sorry, appliances only. (1)

r_a_trip (612314) | more than 3 years ago | (#33906652)

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.

Wrong way around. If the major motion picture studios want to sell or rent their works to someone to get money for it, they better sell what the market wants, not whatever kind of spyware fantasies they themselves entertain.

It is simple. Make a good product at fair prices and you hit the optimum between sales and copyright infringement. Treat your paying customers as criminals and all you will breed is copyright infringers. The product of copyright infringement, a DRM free copy, has vastly higher use quality than the DRM-ed version.

No matter what scheme is being dreamt up, if one group is able to lock something, another group is able to unlock it. All it takes is time and determination. DRM is a failed concept. No matter how obscured, the recipient gets both the lock and the key. If this wasn't the case, the customer wouldn't be able to watch the content. All that needs to be done is find out how to emulate the key.

Look at CSS, AACS, SecuROM, StarForce, XCP, SafeDisc (etc.) as examples of DRM not working.

Re:How long do you want your ID to last? (2)

thijsh (910751) | more than 3 years ago | (#33905908)

Yeah, this sounds more like unspoofable stupidity...

Re:How long do you want your ID to last? (1)

Lazareth (1756336) | more than 3 years ago | (#33905978)

Spoofable. Look at sensational media in general.

Re:How long do you want your ID to last? (1)

hAckz0r (989977) | more than 3 years ago | (#33906108)

Not only that, but the law of entropy demands that new errors will happen just when you need to use it online to pay your mortgage. Now try replacing it? If the premise is that you can't intentionally create an error to match a known pattern then how does one replace a "failed" identity? You simply do it like this http://www.flylogic.net/blog/?p=10 [flylogic.net] Actually, forcing an error is easy, its getting rid of an unwanted error that is hard, and you can't prevent new errors. In other words, John Doe is toast when a bit changes, but Nation States with deep pockets can become John Doe any time they please.

Doesn't know what spoofing means. (4, Insightful)

thegarbz (1787294) | more than 3 years ago | (#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.

The Three Stooges (0, Offtopic)

PolygamousRanchKid (1290638) | more than 3 years ago | (#33906028)

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 [wikipedia.org]

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!"

Re:The Three Stooges (1)

wolrahnaes (632574) | more than 3 years ago | (#33907260)

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.

This post really isn't getting the attention it deserves. The Three Stooges were great and "A Plumbing We Will Go [youtube.com] " is possibly one of my favorites.

Re:Doesn't know what spoofing means. (1)

vegiVamp (518171) | more than 3 years ago | (#33906642)

In a sense,you're mis-representing your own ID / hardware signature -- just like when you're spoofing a mac address.

Seems like.. (2, Funny)

airfoobar (1853132) | more than 3 years ago | (#33905872)

Microsoft's Windows activation thing could become even more annoying in the future.

Guess this could be spoofed anyway (1)

LordAzuzu (1701760) | more than 3 years ago | (#33905934)

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".

Spoofable as hell (0)

Anonymous Coward | more than 3 years ago | (#33905936)

Super easy with nano-technology. They can position atoms at will, for fucks sake.

Spoof my ass.

Re:Spoofable as hell (1)

DrSkwid (118965) | more than 3 years ago | (#33906132)

1d107

Obscure Security and Marketing Fud? (3, Informative)

betasam (713798) | more than 3 years ago | (#33905986)

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.

A problem... (1)

amn108 (1231606) | more than 3 years ago | (#33906122)

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.

Driver level (2, Informative)

SharpFang (651121) | more than 3 years ago | (#33906160)

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.

yeah right (0)

Anonymous Coward | more than 3 years ago | (#33906182)

This is the kind of DRM that gets spoofed in a week with a highlighter.

PIC (-1, Offtopic)

Anonymous Coward | more than 3 years ago | (#33906264)

I had a shitty job making PIC microcontrollers spoof little 24C 256 byte eeproms for toner cartridges (manufactured with special locations write protected) so they could be refilled.

Reverse engineering is humilating -- definitely a flaw in capitalism. I was not doing work, I was getting paid to undo work. I get more done doing nothing, but don't get paid.

God sees nuainces, not black and white. He said reverse engineering has it's place in training young engineers. He also said adultery under special circumstances is okay--wouldn't press your luck.

I see how immigration policy is practical if not appealing to a perfectionist.

God says...
search savour agreed slavery Euodius shakes dishes upper
beholder voluptuous couldest multiply Saviour empty messages
merged smoothing unreasoning Thinkest Whoso Psalm allege
wheresoever presides strengthened faithfulness unseemly
lusting relapse Sabbath unworthy Woe condemns ills beset
Central wealthy Inhabitant shadow volunteers murmured
melt plant paradise warfare Duad impulses unchangeably
inevitable unlocked mystery healedst strikes breathing
stays granted hanging burned discreetly usual conversing
bewailing unwholesome intention DISCLAIMER antecedent
day fain verse enlightening kindly vapours have passages
gently soothed quest adversities deceitful thundering
usury forsooth gratefully Name observation harsh listened
unconscious terrible bathe meddle garner Sacraments needful
minded fruitfully infancy denotes begins share unjust
misery ordinarily perished confuted devoured Cross stilled
mute compressed centre churches Same repose fiercest regions
fleshly consequential Passing comment regard learning
waterest directions between triumph daughter Latinum recite
regeneration requited pobox careful important mirth

Sounds like ancient DRM (1)

supersat (639745) | more than 3 years ago | (#33906268)

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.

Re:Sounds like ancient DRM (1)

wolrahnaes (632574) | more than 3 years ago | (#33907330)

That was my immediate thought as well. Not only were those systems easy to emulate, they also had the problem that damage would make the disk (or disc) unusable by the application long before it was actually unreadable by screwing up the pattern. As with most content protection, it didn't work and screwed legitimate consumers while not harming pirates at all, yet for some reason the idea keeps coming back with every new data medium.

good idea, but... (0)

Anonymous Coward | more than 3 years ago | (#33906288)

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.

Anonymous Coward (0)

Anonymous Coward | more than 3 years ago | (#33906406)

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.

lol (2, Funny)

Charliemopps (1157495) | more than 3 years ago | (#33906410)

Unspoofable? Buahahahaha!

The 80th called (0)

Anonymous Coward | more than 3 years ago | (#33906482)

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.

Why this won't work. (2, Informative)

gmarsh (839707) | more than 3 years ago | (#33906658)

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.

Not another me-too patent please. (0)

Anonymous Coward | more than 3 years ago | (#33906724)

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)

We don't "desperately need" device identity (3, Insightful)

time961 (618278) | more than 3 years ago | (#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.

History repeating itself (5, Informative)

mobilityguy (627368) | more than 3 years ago | (#33906786)

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.

Nice try but (1)

russotto (537200) | more than 3 years ago | (#33907666)

...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.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...