dual-use digital signature vulnerability

[Anne & Lynn Wheeler]

there is a variation on the EU FINREAD terminal that sort of provides a 
chain of trust/evidence (that has almost nothing at all to do with the 
traditional trusted third party certification authorities and their 
certificates)(

1) there ae a certain class of certified terminals with security modules, 
tamper evident, and are known to always present an accurate text of what is 
about to be signed ... and then asked the person if they agree with what 
was presented .... which they have to indicate by pressing some button (or 
set of buttons)

2) these are a certain class of certified hardware tokens which contain 
unique private keys.

3) the specific certified hardware terminals are able to verify what kind 
of hardware token they are dealing with and only work with the appropriate 
hardware token

4) the specific certified hardware tokens are able to verify what kind of 
terminal they are dealing with and only work with the appropriate hardware 
terminals.

5) relying party gets a signed message

6) the relying party can verify the digital signature with a specific 
public key known to be associated with a known hardware token

7) the known hardware token is known to be in the possession of a specific 
person .... which implies "something you have" authentication

8) the known hardware token is known to satisfy requirements #2 and #4

9) the corresponding terminals that the hardware token works with are known 
to satisfy requirements #1 and #4

10) given conditions 1-9, the relying party has some assurance that the 
token owner has actually read, understood, and agrees with the contents of 
the message.

In this scenario the relying party wouldn't need direct evidence included 
as part of the integrity of each message that the signing took place in an 
non-repudiation environment .... the infrastructure assurance as to the 
kind of terminals, tokens, and procedures provide such indirect evidence as 
part of the infrastructure operation (aka the chain of evidence/trust 
scenario .... having nothing at all to do with traditional third party 
certification authorities and their certificates).

This kind of scenario falls apart .... if the hardware token ever 
digitallly signs some contents that is not provided by a trusted terminal. 
In which case the chain of evidence/trust is lost as to whether the token 
owner has read, understood, and agrees, approves, and/or authorizes the 
contents of what is being signed.

Either you

1) have some proof that every use of the specific hardware token (and its 
corresponding unique private key) digital signing always meets the 
requirements laid out as to human reading, understanding and agreeing, 
approving and/or authorizes the contents of what is being signed ... and it 
can never be used in any other way

2) or that every use of the specific hardware token (and its corresponding 
unique private key) digital signing that is purported to meet the 
requirement for human reading, understanding and agreeing, approving and/or 
authorizes the contents of what is being signed .... carries in the 
integrity part of the message some indication/proof of the human reading, 
understanding and agreeing, approving and/or authorizes (and that 
indication can't be fraudulently fabricated if the hardware token was to 
ever be used in signing some message that doesn't involve 
reading/understanding/approval by the token owner).



--
Anne & Lynn Wheeler    http://www.garlic.com/~lynn/ 

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