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

[Anne & Lynn Wheeler]

At 03:10 PM 1/5/2004 +1100, McMeikan, Andrew wrote:

>The only danger to such a world of peace would be those who refuse goverment
>signed keys and use their own payment provider and trade amounst themselves,
>they would have to be hunted down seperately.

The original issue involves three factor authentication

* something you have
* something you know
* something you are

A public key can be representative of  hardware token ... say a token where 
the private key is generated on the token and is designed to never leave 
the token. A digital signature that can be verified by the corresponding 
public key can be used to infer possession of the hardware token (something 
you have). Furthermore, a hardware token can be designed to only work in a 
specific way when the appropriate pin/password (something you know) or 
biometric (something you are) have been entered into the token. The entity 
receiving the digital signature doesn't need a copy of the pin/password or 
biometric (making it a shared-secret) but infers by the operation of the 
hardware token that there has been something you know &/or something you 
are authentication to have happened.

An institution can enroll the person in possession of the token using 
whatever processes they feel necessary (say anonymous for ISPs up to "know 
your customer" identity as required by various legislation for financial 
institutions).

The issue is that can the validating of the entity in possession of the 
token be a separate business process issue from validating the integrity of 
the hardware token. The idea is that the integrity of the hardware token 
can be treated as a totally separate business process from the process of 
validating the entity being enrolled (an entity that happens to possess the 
hardware token).

Treating them as totally separate business process doesn't preclude 
collapsing the enrolling of the entity and enrolling the hardware token 
into a single process. However, not treating them as separate business 
process will pretty much preclude ever being able to treat them as separate 
processes.

So the question is as part of the enrolling process, can the integrity of 
the hardware token be treated as a totally separate business issue from the 
characteristics of the entity in possession of the hardware token, say like 
the advertisements for the service that allows being able to research the 
history of a used car. Most institutions already have all sorts of business 
processes involved with enrolling the characteristics of an entity. What 
would be the incremental requirement for adding being able to enroll (& 
trust) the integrity of a consumer presented hardware token.

So, i'm a little bit biased, I claimed that I ruthlessly discarded all 
feature and function from AADS chip strawman that wasn't needed for trusted 
authentication
http://www.garlic.com/~lynn/index.html#aadsstraw

complexity can contribute to insecurity ... KISS and focus can contribute 
to security.


--
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