[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Current signature formats insufficient


Another example of a non-binding signature : the signature could just be used to assure the integrety of a message.


11/07/2000 15:34
To:	frankb%valicert.com@Internet, ietf-pkix%imc.org@Internet
cc:	 (bcc: Thierry Van Doninck/GKBCCB)

Subject:	RE: Current signature formats insufficient

Hello Frank,

in the context of my original message, a "non-binding signature" would be a
signature for the purposes of, say, authentication.

Suppose you are connecting to a secure website - say, an e-banking
application - that requires private key authentication. For the purposes of
authentication, your equipment will have to sign a challenge that is sent to
you from the server. Now, since this signing process is intended only for
authentication, you want the resulting signature to reflect this fact. You
don't want to find yourself in a situation where you signed something that
you thought was intended only for authentication, only to find later that it
was in fact the hash of a contract that you have never seen before.

To sum up: for the scope of this discussion, we could vaguely define that a
signature is "binding" if it can be used as a legal tool to force the signer
to do something or not to do something. Otherwise, a signature is

Examples: if you sign a contract, that is a binding signature. If you sign a
purchase order, that is a binding signature. If you sign a cryptographic
challenge intended for authentication, that is a non-binding signature.



-----Original Message-----
From: Frank Balluffi [mailto:frankb@valicert.com]
Sent: 11. julij 2000 14:49
To: 'denis.bider@denisbider.com'; ietf-pkix@imc.org
Subject: RE: Current signature formats insufficient


You refer to non-binding signatures. Why would I bother signing something if
it were non-binding?


> -----Original Message-----
> From: denis bider [mailto:denis.bider@globera.com]
> Sent: Tuesday, July 11, 2000 4:42 AM
> To: ietf-pkix@imc.org
> Subject: Current signature formats insufficient
> Hello folks,
> we probably agree that smart cards, as well as a variety of
> other similar
> cryptographic tokens, are insecure. Their primary insecurity
> lies not within
> the tokens themselves, but rather in the way they are most
> commonly used.
> Most frequently, a cryptographic token is attached to a PC,
> and it does
> whatever cryptographic operation the PC tells it to do.
> This concept is obviously insecure, since:
>  - PCs are insecure. Every average hacker down the street can
> break into
> anyone's Windoze PC, and it is trivial to write an exploit
> that will capture
> a smart card's PIN, wait for the smart card to be inserted
> and then perform
> a signature operation.
>  - Even if the user is as security conscious as to use a
> secure PIN entry
> device, or a fingerprint scanner for that matter, it is still
> the PC that
> decides exactly what information the smart card is going to
> sign. It is
> again trivial to write an exploit that will make the smart card sign
> something that the owner did not mean to sign.
> With the advent of digital signature laws which make digital signing
> commonplace, it is time to remove these security holes before
> hackers and
> newspaper articles start popping up. (How would any of you smart card
> manufacturers like to see your company's name placed
> conveniently next to
> "FRAUD!!" in TIME Magazine?)
> The ultimate solution, of course, would be for everyone to
> have a secure
> device, containing the private key, with the following
> characteristics:
>  - In order to sign anything, the user must put their finger on the
> fingerprint scanner. (Or other biometrics...)
>  - In case the signature is binding (ie, contract as opposed to
> authentication), the user must check the contents being
> signed on the screen
> of the secure device.
>  - In case the signature is binding, the user must enter a signature
> passphrase (PIN) as well.
> Now, since users do not want to enter passphrases every time
> something needs
> to be signed, and since that would be dangerous in the first place
> (increased risk of passphrase exposure), there is a practical
> need for the
> secure device to be able to distinguish between a binding
> signature and a
> non-binding signature.
> In the case of a non-binding signature (eg, proof of
> identity), the behavior
> of the secure device could simply match the behavior of all the
> cryptographic tokens currently out there. Ie, the device
> would sign anything
> that it receives - most commonly a hash of something -
> provided that the
> user confirms the signature operation by putting their finger on the
> fingerpring scanner. However, in contrast to the cryptographic tokens
> currently being used, any such signature would be explicitly
> marked that it
> cannot be considered binding.
> In the case of a binding signature (eg, a contract), the
> secure device would
> insist on receiving the entire content that is being signed,
> formatted in a
> well-known and secure format, so that the content can be
> shown to the user
> before anything can be signed. The user would also need to
> authenticate
> themselves in a more secure manner before a binding signature
> is made; and
> when it is made, the signature would be explicitly marked
> that it CAN be
> considered binding.
> It is my opinion that the following efforts need to be made:
>  - The current signature formats need to be extended so as to include
> information about the extent to which the data being signed
> was verified by
> the signer - or simply whether the signature can be
> interpreted as binding
> or not.
>  - A format for binding content needs to be selected or
> defined. (RTF, ASCII
> text, anything?) - this is the format in which any binding
> content is sent
> to the secure device so that it can be shown to the user, who in turn
> decides whether to sign it or not.
>  - The current APIs for communication with cryptographic
> tokens need to be
> modified to support this. Eg, in PKCS#11, the following modes
> of signature
> could be introduced:
>         - sign this hash and mark the signature as non-binding
>         - here is the 34kB file containing the binding
> content to be signed,
> show it to the signer, sign it and mark it as binding
>         - here is a hash of the binding content to be signed,
> sign it and
> mark it as binding (deprecated, but must be included since it
> is not yet
> possible to transmit 34kB of data to every kind of
> cryptographic token)
> I feel that the above issues are important and that somebody
> needs to take
> them on. I cannot decide whether or not this workgroup should
> do it; but
> somebody has to. (Or else...)
> Comments are welcome. Also, does anyone have information whether these
> issues have been addressed by the xmldsig workgroup, or is
> their format as
> clueless as the ASN.1 signature format?
> Regards,
> denis bider
> //
> //  denis bider, denis.bider@globera.com
> // [alternative: anything@denisbider.com]
> //  globera d.o.o., Ljubljana, Slovenia
>     http://www.globera.com
>     +386 1 510 7740