Re: Enterprise Right Management vs. Traditional Encryption Tools

[Alexander Klimov]

On Fri, 11 May 2007, Jon Callas wrote:
 What about DRM/ERM that uses TPM? With TPM the content is
 pretty much tied to a machine (barring screen captures etc)
 Will ERM/DRM be ineffective even with the use of TPM?

There are two different features of TPM: it can work as an embedded
smartcard (to identify computer), and it can be used to vouch for
integrity of booted software. The first feature does not add
much to DRM, because the attacker has the computer. The second feature
can be bypassed if OS or DRM software has exploitable bugs (or
with relatively simple hardware techniques, but let someone
build a bug-free DRM software first :-) ).

 If someone is so impolite that they'll put the TPM chip under
 a scanning electron microscope, they can probably just read
 the bits off.

Actually there is no need for any TPM intrusive methods to
bypass the second feature mentioned above (the first one does
not need to be bypassed since attacker has the computer). Let us
see how TPM works:

  after reset, CPU sends a sequence of messages that report
  hashes of the booted software;

  TPM changes its internal registers (PCRs -- platform
  configuration registers) as a result;

  CPU sends a key to be encrypted and a description of PCR
  values required to decrypt it;

  TPM returns encrypted blob (it stores PCR requirements inside the
  blob).

Once the blob is saved outside, it can be used to make sure that
only required software can access the key:

  after reset CPU reports hashes of booted software and TPM
  changes PCRs;

  CPU send a blob to be decrypted;

  TPM decrypts it, checks PCR requirements, and return the key
  stored inside.

The crucial assumptions here are that (1) TPM cannot be reset
independently of CPU; (2) CPU's boot ROM cannot be changed (note
that in many cases the ROM used for boot is actually flash);
(3) the bus between CPU and TPM cannot be tampered with.

Now, to decrypt any blob there is no need to have a FIB (focused
ion beam) or a scanning electron microscope, because the only
thing an attacker needs is to break one of the above
assumptions, for example, boot Linux, reset TPM by some hardware
manipulation, write a program to send to TPM the needed set of
PCR change requests, send the blob, get the decrypted key, and
print it out.

Note once again that TPM works exactly as expected, the only
problem is that the assumptions do not hold.

-- 
Regards,
ASK

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Re: More info in my AES128-CBC question

[Hal Finney]

Earlier someone asked about comparisons between full-width CFB and CBC.
They are very similar in certain ways. For example, the sequence of
operations for both are the same: xor the next block of plaintext; encrypt
the result; xor the next block of plaintext; encrypt the result; and so
on. The difference relates to the handling of the IV and the last block;
and more importantly, to where in this chain we define the output to be.
For CBC the output is after the encrypt steps; for CFB the output is
after the xor teps.  This also implies that, except for the first and
last blocks, you can transform a CBC encryption into a CFB encryption
by xoring the plaintext into the ciphertext, and vice versa.

In terms of IV, CFB encrypts the IV and then xors with the first block
of plaintext.  CBC xors the IV with the plaintext and then encrypts.
So you have a little more flexibility in terms of choosing your IV,
with CFB mode.  A simple counter should be good enough.  However the
penalty for erroneously reusing an IV is worse; it reveals the XOR of the
respective plaintexts, whereas in CBC mode it will only reveal whether
the plaintexts are identical.

Hal Finney
PGP Corporation

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]