Subject: RE: Current signature formats insufficient

From: Frank Balluffi <[email-masked]>
Date: Tue, 11 Jul 2000 05:48:37 -0700

Denis,

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

Frank

> -----Original Message-----
> From: denis bider [mailto:[email-masked]]
> Sent: Tuesday, July 11, 2000 4:42 AM
> To: [email-masked]
> 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, [email-masked]
> // [alternative: [email-masked]]
> //  globera d.o.o., Ljubljana, Slovenia
>     http://www.globera.com
>     +386 1 510 7740
> 
> 
>

---

From: "denis bider" <[email-masked]>
Date: Tue, 11 Jul 2000 15:36:49 +0200

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
"non-binding".

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.

Regards,

denis

-----Original Message-----
From: Frank Balluffi [mailto:[email-masked]]
Sent: 11. julij 2000 14:49
To: [email-masked]'; [email-masked]
Subject: RE: Current signature formats insufficient

Denis,

Frank

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Tue, 11 Jul 2000 16:32:03 +0200

> challenge intended for authentication, that is a non-binding signature.

This is what certificates are for.

To do that, you use several different private keys, each being associated with a
certificate that has different usage extensions.

It is already a recommended usage to use a different key for SSL
authentification and to sign a document.

What you are saying is not linked to the format of certificates, but to the way
they are used and the policies that should be enforced for legally binding
signatures.

Nothing in the RFC says, or will or even could say, how a private key has to be
used to be legally binding.
Therefore this is quite out of suject here.

Could you shorten your quoting please ?

---

From: Ben Laurie <[email-masked]>
Date: Tue, 11 Jul 2000 16:03:50 +0100

> You refer to non-binding signatures. Why would I bother signing something if

When a man comes to the door with a package, I sign it because he asks
for a signature. I do not consider that signature to be binding in any
sense I understand the word.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/

---

From: Paul Koning <[email-masked]>
Date: Tue, 11 Jul 2000 11:16:10 -0400 (EDT)

>>>>> "Ben" == Ben Laurie <[email-masked]> writes:

 Ben> Frank Balluffi wrote:
 >>  Denis,
 >> 
 >> You refer to non-binding signatures. Why would I bother signing
 >> something if it were non-binding?

 Ben> When a man comes to the door with a package, I sign it because
 Ben> he asks for a signature. I do not consider that signature to be
 Ben> binding in any sense I understand the word.

I don't understand the notion of a non-binding signature.  To put it
differently, the purpose of a signature is to bind your identity to
some assertion.  The only question is what that assertion is.

It could be "I (insert name) agree to buy 100k shares of FOO
Corporation".  That would be a "binding" signature in the sense it has
been discussed.

But in the example you give, the assertion is "I have received package
xyz (and consequently agree not to press insurance claims for
non-delivery of that package".  Is that any less "binding"?  The
amount of money at stake may be less, so there's a difference in
degree, but I don't see a difference in essence.

Similarly the example of authentication for a web banking
application.  Even if you're only looking at information, you're
making an assertion that you're authorized to do the looking (or in
other words, that accesses so authenticated will not later be
challenged as violations of privacy).  Again, the amount of money at
stake changes, but...

      paul

---

From: Ben Laurie <[email-masked]>
Date: Tue, 11 Jul 2000 17:17:00 +0100

> degree, but I don't see a difference in essence.

This is really digressing from the point, but that is not the assertion
I am signing - in order for that to be the case, I'd have to see more
than a form with my name (or someone else's) and address on it with a
box saying "signature" on it. If you insist on there being an assertion
linked to the signature, it must be "I am signing in this box like the
man on my doorstep asked". What that might bind me to, I can't imagine.
Nothing, IMO.

Cheers,

Ben.

---

From: "denis bider" <[email-masked]>
Date: Tue, 11 Jul 2000 20:17:05 +0200

Paul,

you are right - the definition of a 'binding signature' depends very much on
the definition of what "binding" actually means.

The 'non-binding signature' that I referred to was, in fact, meant to be a
"signature of data that the signer does not understand" - hence, a signature
which implies no more than the subject's willingness to participate in a
third party's effort to validate the subject's identity. An 'ephemeral
signature' therefore, by Hal Lockhart's definition.

Regards,

denis

-----Original Message-----
From: Paul Koning [mailto:[email-masked]]
Sent: 11. julij 2000 17:16
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Current signature formats insufficient

      paul

---

From: "denis bider" <[email-masked]>
Date: Tue, 11 Jul 2000 20:19:37 +0200

Hello Jean-Marc,

I'm not sure that using multiple certificates is the proper solution.
Rather, I think it is an attempt to patch the problem rather than to resolve
the issue at its roots.

The core problem is that there is no standardized signature format that
allows a person to say: "I am signing this, but I don't understand what I
have signed."

One example why using multiple certificates is a context-specific patch
rather than a general solution:

Suppose you have an e-banking service. The e-banking service uses private
key authentication to login, and it also uses digital signatures to confirm
payments.

With the "multiple certificates" solution, it is up to the designer AND the
administrator of the e-banking service to provide support for multiple
certificates - one for authentication, and one for confirming payments.
Thus, if the service designer and/or administrator are not
security-conscious enough to take care of this issue, the user has no way of
protecting themselves against trojan attack.

Keep in mind, again, that what we are trying to protect the user from is a
trojan attack, where the user's PC is compromised and the user is tricked
into allowing an authentication-only signature take place, where in fact the
authentication-only data has been replaced by a trojan horse with data that,
when signed, binds the user to an agreement or contract that they have never
seen.

If, in contrast, a signature format existed with which it was possible to
sign data safely without knowing its semantics, this danger would cease to
exist.

Btw - a real-world example: a few years ago, an old lady in Austria lost her
apartment to a very similar trick. Someone rang her bell and explained to
her that some simple formality needs to be signed so that something or other
will be taken care of. She couldn't read very well, so she signed the paper
without knowing what it said. However, the paper was actually an agreement
that she is giving the apartment to a third party she had never heard of.
The judge enforced the validity of the agreement and she lost the apartment.

Again, thousands of people with PCs and smart cards are unnecessarily
signing electronic documents like this every day - just because there is no
digital signature format which would allow a person to safely sign data
which they can't understand.

denis

-----Original Message-----
From: Jean-Marc Desperrier [mailto:[email-masked]]
Sent: 11. julij 2000 16:32
To: [email-masked]
Subject: Re: Current signature formats insufficient

To do that, you use several different private keys, each being associated
with a
certificate that has different usage extensions.

What you are saying is not linked to the format of certificates, but to the
way
they are used and the policies that should be enforced for legally binding
signatures.

Nothing in the RFC says, or will or even could say, how a private key has to
be
used to be legally binding.
Therefore this is quite out of suject here.

---

From: "Simon McMahon" <[email-masked]>
Date: Wed, 12 Jul 2000 12:23:27 +1000

Hi all,

My 2c worth.

You should look to the analog-signature as an analogy. It's the content of
what you sign that includes the terms and therefore the extent to which the
signer is bound. Carelessly given signatures should be legally binding,
otherwise ignorance will be used as a defense for repudiation, and only
fraudulently or forcefully obtained signatues should be able to be
sucessfully repudiated by recourse to the law and courts.

You never modify the nature of a handwritten signature to indicate your
intention, e.g different coloured pens or pressing harder, writing bigger /
smaller than normal makes no difference if the handwritten signature can be
shown to be yours or you say it is yours. Its what you sign that binds you.
Having a signature witnessed by a competent authority (a JP) is the only way
I know of to boost non-repudiation of a standard signature. A non-witnessed
signature is presumably easier, but by no means trival to repudiate.

Just because its easier (relatively) to mess with digital signature formats
than handwritten ones dosen't mean that you should since laws for
handwritten signatures will migrate easier to digital ones if the analogy is
kept closer.

I dont agree with either digital alternative for indicating the signers
intention in a legally binding way, i.e. boosting or removing
non-repudiation. Firstly that the certificate's usage attributes should
dictate anything about the private key since they may not both be stored on
the same device and the association is not trivial to check, or, secondly,
that the signature format should indicate my intention when I signed. All of
my intentions should be indicated in the content of what I signed.

Any "intention" indicator added to the signature encoding could just as
easily be encoded into the content before signing. It is effectively
modifying the contract before signing it. For "ephemeral" signatures you
effectively stamp the content "void", then sign it.

Frank's suggestions :
> In the case of an authentication protocol, you could include an OBJECT
> IDENTIFIER or string in the data to be signed to constrain the use of the
> signature. For example:
>
> AuthenticationInfo ::= SEQUENCE {
>    disclaimer UTF8String,
>    nonce      OCTET STRING
> }
>
> Another technique would be to use PKCS #7 authenticated attributes.

These look like good mechanisms for this purpose and use current practise
and encodings. No need for yet-another-encoding :-).

I dont believe that private keys for non-repudiation signatures should ever
be used for ephemeral signatures. It just seems like a dangerous and
unecessary overloading of an important object - the private key. The private
key should be stored with its own usage attributes to avoid looking up the
certificate to see if it is such a key. The device doing the signing should
do whatever the law requires it to do with these keys, regarding
authentication and secure containment, to make non-repudiation enforcable.

Simon McMahon
ERACOM Pty. Ltd.

---

From: Venkateshwara Reddy A <[email-masked]>
Date: Wed, 12 Jul 2000 09:44:35 +0530

denis bider wrote:

> If you sign a cryptographic challenge intended for authentication, that is a
> non-binding signature.

That is called `commitment`

Regards
Venkateswara Reddy

Security Consultant,
PSI, India

---

From: Paul Koning <[email-masked]>
Date: Wed, 12 Jul 2000 10:38:24 -0400 (EDT)

>>>>> "Simon" == Simon McMahon <[email-masked]> writes:

 Simon> Hi all, My 2c worth.

 Simon> You should look to the analog-signature as an analogy. It's
 Simon> the content of what you sign that includes the terms and
 Simon> therefore the extent to which the signer is bound. Carelessly
 Simon> given signatures should be legally binding, otherwise
 Simon> ignorance will be used as a defense for repudiation, and only
 Simon> fraudulently or forcefully obtained signatues should be able
 Simon> to be sucessfully repudiated by recourse to the law and
 Simon> courts.

I think that's a fine analogy, and it also serves to illustrate the
issue that Denis is concerned about.

With classic signatures, the norm is that you see what you sign.  (One
exception is the standard story about the overworked executive who's
handed a stack of 50 memos to sign, with little yellow tabs marking
"here's the spot" and someone slips in a ringer.  Don't know how
common that is outside novels.)

With digital signatures, the norm is that you have no idea.  As Denis
mentioned, current smartcards have no way of showing you what you're
signing.  If you use an application that signs things (like a mailer)
the binding is a little better.  There you still have to trust that
the text you entered is in fact what's being signed -- in other words,
that the program is trustworthy, correct, and unsubverted by trojan
horses.  One good reason for using PGP, because you can check this,
unlike closed source mailers.

The new (USA) digital signature law scares me, because it makes no
sense so long as digital signature mechanisms continue to provide no
meaningful way for the user to know what is being signed.  

	   paul

---

From: Eric Murray <[email-masked]>
Date: Wed, 12 Jul 2000 08:53:06 -0700

> common that is outside novels.)

I don't know how often ringers are slipped in, but normal people
are expected/encouraged to sign things without reading them fully
all the time.  A good example is when buying a house.  I have
bought two houses (both in California), and at the final document
signing meeting for each, signed between 20 and 40 documents.  Both I
and my girlfriend who I bought the houses with read fast and
have negotiated many contracts so we're somewhat practiced in
reading contractese.  We split up the docs to read and skimmed them
rather than reading in depth.

It took us twice as long as the escrow agents had allotted to do the
signatures.  People who read slower and aren't familiar with contractese
would take all day to read every document carefully.  It's obvious that
they don't expect most people to read the documents, and certainly not
to read them carefully.

> unlike closed source mailers.

With PGP you can check the source of the mailer/encryption program.
Being able to do so doesn't help your checking for trojans in the OS
and it's there that it's easy to attack the smartcard or mailer signing
program- just substitute the hash of the Bad Document for the hash
of the Good Document before it's signed.

> meaningful way for the user to know what is being signed.  

Everyone is pretending that the OS is secure because no one wants to
have to fix it.

-- 
 Eric Murray www.lne.com/~ericm  ericm at the site lne.com  PGP keyid:E03F65E5
    Security consulting: security models, reviews, protocols, crypto.

---

From: "Simon McMahon" <[email-masked]>
Date: Thu, 13 Jul 2000 12:23:05 +1000

> common that is outside novels.)
Thats right but people make classic signatures with less care when they take
into account their environment. If you are in a reputable establishment, or
your workplace, where accountablility for fraud is higher you are more
likely to forego the formality of reading every word of what you are
signing. The risk is their but people (reasonably) tend to limit their
effort with respect to their perception of that risk.

> unlike closed source mailers.
The smart card is not "the signing device" the PC with all its software is.
It is, fortunately, able to show you everything before it uses your card to
sign what you saw. It is also, unfortunately, hackable if exposed to a
hostile environment. Most PCs hanging off the Internet or using uncertified
software fall into this category.

The fix is to make more secure (more expensive) signing devices or reduce
the liability resulting from a hack on a less secure (cheaper) one.

I dont see how any of this is an argument to change signature formats. Its
an argument to use NR keys in more secure devices and non-NR keys in PCs. I
still think there is a case for limited liability NR keys in hackable
(cheap) PCs because thats what people will want to do. Buy and sell stuff
(not their house) over the Internet from their home PC.

Simon.

---

From: Irene Gassko <[email-masked]>
Date: Tue, 18 Jul 2000 14:46:54 -0400

Hello,

Blind signatures provide another viewpoint. Here a signer does not
know what it is signing but the key used indicates the value of a
monetary unit. 

If keys have very limited usages it will be more difficult to misuse
them. Even the most technically unsophisticated consumer will be
suspicious if a librarian will ask for his credit card instead of his
library card. On the other hand, a contract to sell one's home
signed with an e-mail signature key instead of "high value transaction"
signature key will be much easier to repudiate if those keys are
explicitly defined. I think all of this is achievable with currently available
PKIX tools.

Cheers,

Irene

>authentication and secure containment, to make non-repudiation enforcable.

----------------------------------------------------------------------------
-------------------------------------------------------
Irene Gassko			 Bell Laboratories		http://www.lucent.com
Lucent Technologies		Secure Technologies Dept.
1600 Osgood Street			 phone:	(978) 960-5767
Room 30-2-A31			 e-mail: 	[email-masked]
N. Andover, MA 01845		 fax: 	(978) 960-3240

---

From: Ben Laurie <[email-masked]>
Date: Thu, 20 Jul 2000 09:28:35 +0100

> know what it is signing but the key used indicates the value of a

Very good point (BTW, see http://anoncvs.aldigital.co.uk/lucre/ for a
free implementation of blinded signing) - but in this case the signer
_does_ know that it is effectively signing a random number. But this is
a good example of why the _key_ should say what it can be used for (I
realise the signature could, too, but that's a waste of space, surely?).

Cheers,

Ben.