Am I the only one slightly embarassed after reading about copy protected hard drives on slashdot?
On that supposedly competent forum nobody gave me an impression of knowing what the hell they are talking about.
Some say the protected files could be read but not the key on a special partition. Others say protected files cannot be read and copied at all without the key.
But almost everybody there intends to stock 'old standard' hard drives just in case.
So what is the real nature of this copy protection scheme?

You should be the only one embarrassed. The /. main articles had hyperlinks to information at The Register. From there, there were other links that spelled out what it is and how it works. If you spent a little time investigating you wouldn't be complaining here. You should be embarrassed.

Not really. The Register did not give any details.
The only technical link provided was to a pdf file that does not say whether encrypted file could be copied (without the key of course).
Some people at /. and kuro5hin said they *think* it could be copied. Others said they *think* it cannot be copied. Nobody was very sure.
In case encrypted file could be copied it would be useless without the key that remained on the original disk. Big deal, so you can't decipher it but at least it breaks backup ONLY in the sense copies of protected files are useless.
But in case encrypted file cannot be copied at all, it's a major blow for defragmentation and backup.
A lot of people at /. and kuro5hin can't really say which case is going to be implemented. That includes people that have read the pdf file I mentioned earlier.
You see, the reason I asked is that I hoped for an answer.
If you know the answer please share it with me. Consider me a clueless dimwit, but just give me the answer. And your reasons for thinking so.

Here are some quotes from kuro5hin, just to show that I am not the only one confused:

>I would be very hesitant to post something on this
>subject with no one but the Register to site as a source.

>I'm not saying that it doesn't work, just that I don't
>understand how.

>Maybe I don't understand the scheme, which is understand-
>able since the register article was a little vague. I
>wish there were a few more details.

>If I'm wrong, and instead the idea is that everything
>is encrypted, well, this is just unworkable. besides
>the issue of backups, how would you even optimize a
>drive? It just doesn't make sense...

>As far as The Register is concerned, I've seen a lot of
>overdramatic B.S. posted on there before, and I tend to
>not trust it very much anymore. At least not without
>other, more reliable sources, to back them up.

>I'm not sure that I totally understand this.

>This is hardware-level encoding. It apparently sets
>aside an area of the disk to store keys in, and keys
>need to know the physical disk location of the data
>(or something like that) to read that data. Like, the
>unlocking and decryption will be done before software
>gets a bit off the drive. It's entirely below the
>software level.
>Beyond that, I don't know anything either. Perhaps
>someone here has a better understanding of how this
>thing works.

Erovin,
Watch your fucking mouth you fucking asshole. If you act elite, hopefully someone will take a bat to your fucking head bitch

Hey, children, don't fight inhere. This is getting off-topic anyway. Saying fuck 5x in a row doesn't show how great you are; but neither does complaining about an article inhere. I'm not choosing sides, and I'm not looking for a fight.

Please behave

-Pred

this is the document that you should read for technical details (note that this a draft, nothing final/approved). based on this (especially page 14) i think it's quite obvious, that the compliant ATA drive will *not* perform any encryption/decryption per se, it will only respond to challenges (so that a player/recorder can authenticate it) by using a hashing algo. this is detailed on page 13 which i think is the source of most of the confusion regarding what can be copied/moved/etc on a compliant drive. namely, the challenge (issued by the player/recorder device *or* software... hint hint ;-) is the result of a hash of two values. one is the dynamic media ID and the other one is some random bit sequence (denoted by c0...c4). the confusion comes from the representation of the latter as it is transmitted in the sector/cylinder/features fields of an ATA command. but it does *not* mean these values would actually be *real* s/c/f values (although they could be by chance or (bad) choice). after all, a challenge should be some random number by its nature (the diagram on page 14 clearly says so as well), there would be nothing challenging in responding to a well known (small) set of 'challenges'...

what this comes down to is that once you acquire some encrypted content which was specifically created to be stored on your compliant drive, you can move it around as you want, just make sure that when you want to play it, you will stream it from the drive it was created for (since the player will use that drive to come up with the decryption key). now if you suspect this whole scheme smells quite a bit and will be subject to the same attack as the CSS used for DVD, you're not far from the truth. again referring back to page 14, you see that the player ('portable device' in their terminology) uses nothing secret/hidden/etc to come up with the decryption key, every bit of the information is (will be) accessible through ATA commands. so as soon as the player manifests in software, you will have access to the decrypted content - probably nothing surprising for our kind ;-). so if the industry wants to avoid making the same mistake, they would have to ensure a fully encrypted path from the drive storing the content to the actual decoder/display device - obviously this excludes software only (player) solutions. whether and when they will figure it out remains to be seen.

end notes: i can very well imagine that all the above may not be quite correct, it was only my first impression/understanding of the issue. if anyone has any *constructive* observations, please feel free to share them with the rest of us.

Thank you Owl !

To Predator: I did not say f**k at all. To the contrary, I admitted that maybe I am a clueless dimwit

vir iracundus provocat rixas et qui ad indignandum facilis est erit ad peccata proclivior. superbum sequitur humilitas et humilem spiritu suscipiet gloria

I hope this is the last msg of this kind you say, you cannot talk like this here, I warn you...
regards,

Tsehp

Just caught up with things after the christmas holidays.

Not a follower of /. so am just going o what I have seen in this thread, but as I understand it someone is proposing encryting files using info peculiar to ID info on a disc drive.

I wonder what happens when the info is stored on a striped volume set such as you can do in NT, or with a scsi controller under any op system? might this foul up the encrytion or is all the key info got from data within formatted sector data like the disk ID microsoft uses. It would certainly be hard to use a drive serial number as part of the encryption, or perhaps they haven't thought of raid systems

Secondly does this mean the file cannot be stored on a network drive because you cannot get at the ID bytes?

Presumably the idea is some form of e-commerce file download system. I guess a standard encryption file is downloaded and decrypted/recrypted using local info by a special program. One then envisages someone coming up with a trojan program that will buy once/download and store standard encryption/do many saves to different disks for distribution to friends operation.