[linux-elitists] CPRM moves forward

Seth David Schoen schoen@loyalty.org
Mon Dec 25 11:48:08 PST 2000


Eugene.Leitl@lrz.uni-muenchen.de writes:

> Does 3l33t involve paying premium for mass storage?
>  
> > But wouldn't putting an encrypted filesystem (Linux International Kernel
> > Patch, anyone?) onto one of these just fake it out of its socks anyway?
> 
> Would you at all be able to put a CFS on it?

I think it works like this --

There will be an ATA command to read an encrypted disk block and a
command to write an encrypted disk block.  (Maybe also to erase one,
which won't require a key.)

At least reading will require providing a key inside the ATA request,
if the operating system is asking to read an encrypted block.  Very
possibly, writing will too.  On top of the key, you might need to
supply some sort of copyright holder serial number -- e.g. "I want
to read block 0x654722, protected by INTERNATIONAL-BUSINESS-MACHINES;
an appropriate key is ...".

There are actually a bunch of possible key schemes:

- The key is embedded by the content creator, and the content is
  pre-encrypted.
- The key is stored on the disk, but encrypted and decrypted in
  hardware inside the drive.
- The key is provided by (trusted) software at write-time; other
  software must provide a valid decryption key in order to read.
  Note that this requires a trusted IDE driver running in protected
  mode (in the sense in which the copyright industries use "trusted",
  which includes "secure against an end-user", because the end-user
  is one adversary from the point of view of the system's design).
- The block's contents are pre-encrypted in memory before the
  write request; but only read requests which contain an appropriate
  decryption key will succeed.

and more.

Some design goals I think CPRM has:

- No effect on non-CPRM content.
- Trusted software; a pretty effective (modulo DMCA) means of limiting
  access to CPRM-encrypted content to trusted software.
- If you open up the hard drive and remove the platters and look at
  them with a read head in another hard drive, or with exotic
  devices, you'll still not be able to read the content.
- Publication of the specifications and relevant algorithms doesn't
  diminish security (unlike CSS).  One way of doing this would be
  to use some strong public key cryptography in hardware.  In
  general: strong cryptography plus reasonable key management.
- Content publishers can (with the help of licensing or key management
  entities, maybe) create they own keys, key management, licensing,
  and access policies.  For example, if I wanted to use my own keys
  with CPRM and only allow Linux users to process the text philes I
  write, I would at most have to apply to LMI and then work with
  software authors (Linux ATA driver maintainers, in this case) to
  get them to support decryption of my content.

  After CSS, I don't know that copyright holders would trust LMI to
  control their keys and the distribution of same.

The idea then is that software that can read a block must ipso facto
have been written by someone who agreed to enforce whatever
restrictions the "owner" of that particular block has decided on.  So
the hard drive doesn't have to worry too much beyond that: the
software will figure out what may or may not be done by the user from
that point on.

The fact that David Wagner and Bruce Schneier have repeatedly pointed
out that this is impossible need not deter anyone: we have laws to
guarantee that technology is able to do impossible things!

So CPRM isn't aimed at taking total control of the hard drive, but of
allowing it to store some files (if software so desires) that will no
longer be transparent to unauthorized/unlicensed software.

Presumably, traditional ATA reads and writes work just the same way
they always did -- unless you have previously written an encrypted
block, in which cases reading it by standard means either fails, or
(equivalently) returns an encrypted version.

Some of the above is wrong; I haven't read the CPRM specification or 
seen a presentation about it.

-- 
Seth David Schoen <schoen@loyalty.org>  | And do not say, I will study when I
Temp.  http://www.loyalty.org/~schoen/  | have leisure; for perhaps you will
down:  http://www.loyalty.org/   (CAF)  | not have leisure.  -- Pirke Avot 2:5



More information about the linux-elitists mailing list