I need to correct myself.
----- Original Message -----
From: "Joseph Ashwood" <[EMAIL PROTECTED]>

> Suspiciously absent though is the requirement for symmetric encryption
(page
> 4 is easiest to see this). This presents a potential security issue, and
> certainly a barrier to its use for non-authentication/authorization
> purposes. This is by far the biggest potential weak point of the system.
No
> server designed to handle the quantity of connections necessary to do this
> will have the ability to decrypt/sign/encrypt/verify enough data for the
> purely theoretical universal DRM application.

I need to correct this DES, and 3DES are requirements, AES is optional. This
functionality appears to be in the TSS. However I can find very few
references to the usage, and all of those seem to be thoroughly wrapped in
numerous layers of "SHOULD" and "MAY." Since is solely the realm of the TSS
(which had it's command removed July 12, 2001 making this certainly
incomplete), it is only accessible through few commands (I won't bother with
VerifySignature). However looking at the TSS_Bind it says explicitly on page
157 "To bind data that is larger than the RSA public key modulus it is the
responsibility of the caller to perform the blocking" indicating that the
expected implementation is RSA only. The alternative is wrapping the key,
but that is clearly targeted at using RSA to encrypt a key. The Identity
commands, this appears to use a symmetric key, but deals strictly with
TPM_IDENTITY_CREDENTIAL. Regardless the TSS is a software entity (although
it may be assisted by hardware), this is and of itself presents some
interesting side-effects on security.
                Joe

Reply via email to