Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)

[Anne & Lynn Wheeler]

At 10:51 AM 12/16/2003 +0100, Stefan Lucks wrote:

>I agree with you: A good compromise between security and convenience is an
>issue, when you are changing between different smart cards. E.g., I could
>imagine using the smart card *once* when logging into my bank account,
>and then only needing it, perhaps, to authorise a money transfer.
>
>This is a difficult user interface issue, but something we should be able
>to solve.
>
>One problem of TCPA is the opposite user interface issue -- the user has
>lost control over what is going on. (And I believe that this originates
>much of the resistance against TCPA.)

In sci.crtypt, there has been a thread discussing does OTP (one-time-pad) 
and how does integrity and authentication play and somewhat subtread about 
does authentication of a message .... involve checking the integrity of the 
contents and/or checking the origin of message. A security taxonomy, PAIN:
* privacy (aka thinks like encryption)
* authentication (origin)
* integrity (contents)
* non-repudiation

http://www.garlic.com/~lynn/2003p.html#4 Does OTP need authentication?
http://www.garlic.com/~lynn/2003p.html#6 Does OTP need authentication?
http://www.garlic.com/~lynn/2003p.html#17 Does OTP need authentication?

One of the issues is that privacy, authentication, and integrity are 
totally different business processes and that the same technology, lets say 
involving keys might be involved in all three, aka digital signatures (& 
public/private keys) can be used to simultaneously provide for 
authentication (of sender) and integrity )of message contents).

Both privacy (encryption) and authentication (say digital signatures) can 
involve keys that need protecting; privacy because key access needs to be 
controlled to prevent unauthorized access to data, authentication because 
unauthorized access to keys could lead to impersonation.

In the authentication case, involving public/private keys .... the business 
requirement has sometimes led to guidelines that the private key is 
absolutely protected and things like key escrow is not allowed because it 
could contributed to impersonation.

In the privacy csse, involving public/private keys  ... the business 
requirement can lead to guidelines that require mandated escrow of private 
key(s) because of  business continuity issues.

This can create ambiguity where the same technology can be used for both 
authentication and privacy, but because the business processes are 
different, there can be mandated requirement that the same keys are never 
used for both authentication and privacy ... and it is mandated that 
authentication keys are never escrowed and that privacy keys are always 
escrowed.

TCPA chip can also be used to protect private keys used in authentication 
.... either authentication of the hardware component as its own entity .... 
say like a router in a large network, or possibly implied authentication of 
a person that "owns" or possesses the hardware component.

An authentication taxonomy is 3-factor authentication:
* something you have
* something you know
* something you are

A hardware token (possibly in chipcard form factor) can be designed to 
generate a unique public/private key pair inside the token and that the 
private key never leaves the chip. Any digital signature that can be 
verified by the corresponding public key can be used to imply "something 
you have" authentication (i.e. the digital signature is assumed to have 
originated from a specific hardware token). A hardware token can also be 
designed to only operate in specific way when the correct PIN/password has 
been entered .... in which case the digital signature can imply two-factor 
authentication, both "something you have" and "something you know".

 From a business process standpoint it would be perfectly consistent to 
mandate that there is never key escrow for keys involved in authentication 
business process while at the same time mandating key escrow for keys 
involved in privacy.

At issue in business continuity are business requirements for things like 
no single point of failure,  offsite storage of backups, etc. The threat 
model is 1) data in business files can be one of its most valuable assets, 
2) it can't afford to have unauthorized access to the data, 3) it can't 
afford to loose access to data, 4) encryption is used to help prevent 
unauthorized access to the data, 5) if the encryption keys are protected by 
a TCPA chip, are the encryption keys recoverable if the TCPA chip fails?

--
Anne & Lynn Wheeler    http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
  

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com