Subject: Current signature formats insufficient

From: "denis bider" <[email-masked]>
Date: Tue, 11 Jul 2000 10:41:34 +0200

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: Dale Gustafson <[email-masked]>
Date: Tue, 11 Jul 2000 09:01:01 -0500

Denis,

Take a closer look at the "Signing Key with Secondary Authentication PIN"
capabilities added to PKCS#11 v2.10.  Works with optional Secure PINPad readers
such that the PIN values are not known to PC software.  This feature can be used
to provide the "user must enter a special PIN for each and every signature
created" functionality you describe.  An application could create a key that is
used only for signing binding / contract documents, etc. thus providing one
clear indication that a "non-repudiation" service is being provided.  This
approach is different than adding bits to a signature block but provides a
similar effect.  I agree that the secure application should be specifically
requesting a distinct signature service (signalled to relying parties by use of
a dedicated signing key and certificate).

Cryptographic tokens typically provide 2-factor authentication -- something you
have (the physical card) and something you know (the User PIN / Passphrase).
This is clearly more secure and portable than storing your security information
on your PC hard drive.  Nevertheless, any scenario that defeats both factors
eliminates the additional security provided by the token.  For example; if
someone threatens you, takes your token away, and makes you tell her your PINs
then your smart token and any private keys stored within can no longer be
considered secure.

The problem with any all singing / all dancing technical solution is that in
order to make the smart token really nifty you have to provide much of the
functionality of your Windows PC (e.g. so you can see the web page or movie clip
you're signing).  You can go to three-factor authentication (something you have,
something you know, something you are) and beyond but there's invariably a point
of diminishing returns for any real network, user community, and applications.

Best Regards,

Dale Gustafson

---

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

Hello Dale,

yes, I agree - a proper security device would indeed be more complex than
smart cards currently are. In fact, I expect that either mobile phones or
PDAs will take on the role of security devices in place of smart cards. Both
types of devices already provide more than sufficient functionality to host,
eg, a secure document viewer that the consumer can use to view a document
before signing it.

However, I think that we have to admit that the solution you identified as
"all singing / all dancing" is, in fact, the bare minimum that needs to be
implemented before we can move into a true, paperless electronic era.

The fact I wanted to expose is that, without the kind of additional token
functionality that I described, the current system is much too flawed for
widespread use. A PC with a smart card is too easy to crack, and that's it.
It's too damn easy to crack.

Sooner or later, we will need a secure device which will be able to:
 - show the document being signed to the user so they can proof-read it;
 - before signing, verify the user's identity with, say, a fingerprint
scanner.

Assuming that I have proven sufficiently that such a device is needed and
that its widespread availability is required, because otherwise we will
never be able to rid ourselves of the acute need for paper, I now put forth
the following theory:

- Sometimes the device will be used to sign data for authentication; at
other times, it will be used to sign documents which the user has to
understand thoroughly before signing.
- The device will receive data that it is supposed to sign from untrusted
sources, such as from a PC (signing an email, or logging into a website); or
from a cash register in a supermarket (signing to pay for stuff); or from a
door (authentication to enter a house, or an apartment).
- This device will not always be able to influence the protocol in which its
cryptographic services are required. Hence, the device will not always be
able to control the format of data that needs to be signed. Only if the
format of data can be understood by the device, only then can the device
perform a signature on this data that somehow binds its user. Otherwise, if
the format of data is not understood by the device, we have two options:
    * The device must not perform any signature operation.
    * The device performs a signature operation where it explicitly states
"I do not understand this data, hence this signature cannot be considered
binding to my owner."

It is my proposal that a signature format is designed which will allow an
entity to say exactly this: "I signed this data, but I didn't understand
what I signed. You are free to use this signature as proof that I possess a
certain private key, but this is also the only purpose for which this
signature can be used."

Currently, I am not aware of a signature format that allows an entity to do
that. And because there is no such signature format, people are constantly
going ahead and signing data they don't understand anyway! Smart cards, as
currently used, are a perfect example of this behavior. (You may think you
know what you're signing, but trust me, you don't. It is preposterously easy
to write a virus that will circumvent any smart card's security without
being noticed. I will do it for $25,000; a college student next door will do
it for free.)

I am convinced that a signature format is needed that will allow an entity
to safely sign information that it does not understand. Otherwise, people
will continue to sign such information with a protocol that BINDS them to
what they have signed, regardless of the fact that they are not sure about
what they are signing.

This is dangerous.

Regards,

denis

-----Original Message-----
From: Dale Gustafson [mailto:[email-masked]]
Sent: 11. julij 2000 16:01
To: [email-masked]
Cc: [email-masked]
Subject: Re: Current signature formats insufficient

Denis,

Take a closer look at the "Signing Key with Secondary Authentication PIN"
capabilities added to PKCS#11 v2.10.  Works with optional Secure PINPad
readers
such that the PIN values are not known to PC software.  This feature can be
used
to provide the "user must enter a special PIN for each and every signature
created" functionality you describe.  An application could create a key that
is
used only for signing binding / contract documents, etc. thus providing one
clear indication that a "non-repudiation" service is being provided.  This
approach is different than adding bits to a signature block but provides a
similar effect.  I agree that the secure application should be specifically
requesting a distinct signature service (signalled to relying parties by use
of
a dedicated signing key and certificate).

Cryptographic tokens typically provide 2-factor authentication -- something
you
have (the physical card) and something you know (the User PIN / Passphrase).
This is clearly more secure and portable than storing your security
information
on your PC hard drive.  Nevertheless, any scenario that defeats both factors
eliminates the additional security provided by the token.  For example; if
someone threatens you, takes your token away, and makes you tell her your
PINs
then your smart token and any private keys stored within can no longer be
considered secure.

The problem with any all singing / all dancing technical solution is that in
order to make the smart token really nifty you have to provide much of the
functionality of your Windows PC (e.g. so you can see the web page or movie
clip
you're signing).  You can go to three-factor authentication (something you
have,
something you know, something you are) and beyond but there's invariably a
point
of diminishing returns for any real network, user community, and
applications.

Best Regards,

Dale Gustafson

---

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

Hi all,

My 2c worth -

You should look to handwritten (analog ?) signatures as an analogy for what
you are trying to solve here with digital signatures. The technology makes
it easy to mess with the format of signature encodings but laws for
handwritten signatures will migrate easier to digital signatures if the
differences between them are minimised.

Hand written signatures do not vary (colour / size etc.) to imply more or
less intention regarding the content of what was signed. The only way I know
of to boost the non-repudiation value of a signature is to have it witnessed
by some competent authority (a JP). The content of what is signed is what
binds the signer to whatever the contract is about.

Carelessly given signatures, digital or otherwise, should still be binding
otherwise ignorance becomes a defense for repudiating a signature. Only
fraudulently or forcefully obtained signatures should be able to be
repudiated by recourse to the law and the courts.

In my opinion there is no difference between adding some signing intention
indicator into the signature encoding or to the content before it is signed.
Effectively you are marking the content as "void" before signing it so that
its contents become irrelevant. The way content should be marked as legally
"void" may vary according to local laws so there may not be much point
trying to standardise it (yet).

Frank Ballufi's suggestion -
> 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.

This seems to be a good enough way to get the effect you want using current
practise and encodings. I.e no new signature formats are needed.

> understand thoroughly before signing.

I'm sure there is no doubt that such a device is required however I dont
think you should be trying to find ways to use private keys that are
intended for non-repudiation for ephemeral signatures anyway. It seems like
a dangerous and unnecessary overloading of these type of keys. You are
trying to solve two problems, non-repudiation and authentication, with one
private key.

Any ambiguity in the use of this device will undermine its non-repudiation
value. Another device or at least another key should be used for the
ephemeral type signatures.

I also think private keys should have their own usage attributes and
implementations shouldn't look for usage attributes for the private key in a
public key certificate since the certifcate and private key do not need to
be stored on the same device and the association between them is not trivial
to check. Usage attributes on private keys can be implementation dependant
since private keys typically stay where they were generated.

Simon McMahon
ERACOM Pty. Ltd.

---

From: Jan Holger Schmidt <[email-masked]>
Date: Wed, 12 Jul 2000 18:02:29 +0200

Denis,

to change the signature format would not solve your problem. As you say, you can
not be aware of what you sign. So how do you know, that the signature is in the
right format and the bit for "non-binding" isn't set in the right way?

As already adressed by others you should do this with different keys having
different certificates (e.g. one for non repudiation ('binding') and one for
authentication ('non binding'). When you don't trust your PC to select the right
key from the card, you could either protect the different keys with different
PINs or you cold store the keys on different cards.

Hopefully there will be soon secure/trustworthy devices, where you can use your
'binding' key with a lower risk of signing something you couldn't see. However,
to build them for many document formats will be a challange.

Best regards

Jan

---

From: Dale Gustafson <[email-masked]>
Date: Wed, 12 Jul 2000 10:55:42 -0500

Denis,

denis bider wrote:

[snip]

> implemented before we can move into a true, paperless electronic era.

Did not intend to imply any limits on how sophisticated and elegant security
products might become -- just noting the ever present tradeoff between security
and useability/functionality.  There will no doubt be many significant
developments over the next few years.

Getting back to your main point.  Clearly, the signer must have authoritative
control over the electronic document signing process.  For example, if one signs
a (paper) legal document today, it is not unusual for the one or both parties to
"edit" the document via hand-written changes which are initialed by both
parties, etc. (prior to signing/dating) and become part of the written
agreement.  I'm not aware of a similar capability in the digital world yet.
Perhaps others could comment on whether this is a significant and immediate
requirement that is not being addressed today and, if yes, whether the PKIX can
help at this time.  Perhaps there are other presentation layer standardization
efforts that are also applicable.  Apparently there are -- messages from Antonio
and Malte arrive as I edit this (timing is everything :-)

A limitation of putting such control information in the signature block (or in
the x.509 certificate) is that much has to be anticipated well in advance of a
signing event.  Logically, additions and / or changes should be included in the
electronic document before it is signed and the format of those adds / modifies
likely need to be document-specific.

Best Regards,

Dale Gustafson

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Wed, 12 Jul 2000 19:35:13 +0200

> to build them for many document formats will be a challange.

The best for now is to recommend to insert the smart card just before signing a
legally binding document, and remove it just after.
Which does not prove the document you sign is the one you read, but still lowers the
risks a lot.

And use a software key, with authentification only key usage, for ssl authenfication
and the like.

---

From: Aram Perez <[email-masked]>
Date: Wed, 12 Jul 2000 11:06:45 -0700

Jean-Marc Desperrier wrote:

[snip]
> And use a software key, with authentification only key usage, for ssl

If by "authentication only key usage" you mean the DS bit, what happens when
a key has both the DS and NR bits set?

Regards,
Aram Perez

---

From: Tony Bartoletti <[email-masked]>
Date: Wed, 12 Jul 2000 11:28:21 -0700

>a key has both the DS and NR bits set?

Use the CA's CP/CPS for guidance?  ;)

___tony___

Tony Bartoletti 925-422-3881 <[email-masked]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900

---

From: Eric Murray <[email-masked]>
Date: Wed, 12 Jul 2000 13:19:03 -0700

> Which does not prove the document you sign is the one you read, but still lowers the

I'll agree that leaving a smartcard in the slot (and unlocked)
wil soon be Really Dumb..  but only inserting it when it's
needed doesn't add much to your security.

PC/SC, the most common host-side smart-card-reader API, can wake up
a process that's waiting for a smartcard insertion event.

That process could be the one that's signing your document or
it could be rogue code that's going to have your smartcard sign
something bad, and/or start a keyboard sniffer that'll capture
the smartcard PIN.

So I don't think that it lowers the risk very much.

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

---

From: Ed Gerck <[email-masked]>
Date: Fri, 14 Jul 2000 00:18:17 -0700

> the signer - or simply whether the signature can be interpreted as binding

Indeed.

Around September 1999 I made the same call in this WG, when PKIX was
discussing non-repudiation concepts.  To motivate a simple but already
useful scenario, I suggested a second-order model for validity in four
mutually-exclusive but mutually-neighboring levels.

I also pointed out that we don't need new things for this -- we just to
need to encode the already existing DS and NR bits in keyUsage somewhat
more cleverly.  This would easily provide space to encode four different
levels of validity, in the four possible states of the DS (digital
signature) and NR (nonrepudiation) bits in keyUsage.

Let me extend and exemplify this approach, now that the need to define
more signature attributtes begins to be felt more acutely. These four
levels can be so summarized for the benefit of discussions here, as I
posted to PKIX then (but now with the new two-letter acronyms UP/NP/RP/IP
instead of what I used then: SYN/DS/POA/NR) in terms of a 4-level encoding
using the DS and NR bits in keyUsage:

Application      DS NR      Result
-----------      -----   -----------------------------------------
signed object:    0  0    UP -- unknown presumption when signing
                  1  0    NP  -- no presumption when signing
                  0  1    RP -- rebuttable presumption when signing
                  1  1    IP  -- irrebuttable presumption when signing
authenticated
connection:       0  x    no presumption of authentication
                  1  x    rebuttable presumption of authentication

Based on conversations I've had on and off of this list, including the
DIGSIG list, it would be useful to examine these correspondences also
to *induce* four levels of liability (as Bob Jueneman suggested, for
example). And they can also be used to induce four levels of power, four
levels of rights and four levels of duties.

The cornerstone in this approach is the four levels of validity, as the
basic yardstick which organizes the other decision spaces of liability,
power, rights and duties.

The whole discussion becomes more interesting when the third-order theory
is used with 4^3 = 64 levels of validity, because then we can distinguish
between the validity of the tangible object (called entity), the validity
of the text (called reference) and the validity of the meaning (called
sense), each one with four levels.  But, for now, 4 levels suffice -- thus
describing the object's validity as a whole.  In this case, describing
the signature's validity.

It may be interesting to note also that these four levels are able to
explain the hypothesis predicated in the null-theory model used in
relational databases, which deals with *incomplete information* --
i.e., when the validity of information is not known with certainty
(a very real-world problem).  The idea followed in database theory was
to use special values called "null values" as placeholders for information
that is incomplete. And, lo and behold, they were found already in 1979
by E. F. Codd (the father of relational database theory) -- in three
different types of null values, with the complete information itself
being the fourth type in our classification of validity.  Thus, based
also on other examples from other areas, I consider these four validity
types (as identification types) to be basic types in our grading and
understanding of *information* -- and, therefore, a recurring theme
in our use of information and incomplete information.

The relationship between the four types considered in the null-theory
approach in database theory, the four types of identification considered
in the second-order theory (I-2) summarized here, the legal-based
description of signature validity, and the two-letter
certificate/signature validity label is:

I-2 identification  null-theory          legal validity        cert/sig

D- Distinguished     complete         irrebuttable presumption     IP
A- Ambiguous        one of many       rebuttable presumption       RP
O- Obscure         no specification      no presumption            NP
F- Formless        no-information      unknown presumption         UP

To exemplify, using a text-book database case:

1. the first line corresponds to the middle name of "Franklin Delano
Roosevelt", as he signed the Yalta Agreement -- it has 'complete
information', the middle name is "Delano". The validity is
Distinguished (i.e., unique and singular), there is 'irrebuttable
presumption' of the validity of that middle name, and the the
cert/sig label would be IP for that middle name in a signed message.

2. The second line corresponds to the middle name of "Winston
Churchill", as he signed the Yalta Agreement without his middle
name -- it has 'one of many' information because we know that
Churchill was from a titled English family, so he most probably had
a middle name.  We just do not know which, out of the many possible
and common in the UK.  The validity is Ambiguous, there is 'rebuttable
presumption' if we assume any middle name in a balance of probabilities,
and the cert/sign label would be RP if any particular middle name is
assumed in a signed message.

3. The third line corresponds to "Charles DeGaulle", as he
signed the Yalta Agreement -- it has 'no specification'
information because DeGaulle was French and would not use a
middle name.  So, we most probably expect DeGaulle not to have
a middle name, which means that there would not exist a specifiable
value for it. The validity is Obscure because the middle name is
not specified as non-existent with certainty, even though we
do not expect it to exist.  There is 'no presumption' in a balance
of probabilities if we assume any middle name, since a middle
name is supposed not to exist.  The cert/sign label would be NP
if any particular middle name is assumed in a signed message.

4. The fourth line corresponds to "Joseph Stalin", as he
signed the Yalta Agreement -- it has 'no-information'
because nothing can be inferred for that middle name. Stalin
was Georgian, so he probably had a patronymic as a middle
name but might have abandoned it together with his original
last name (Dzhugashvili). The validity is Formless because
we do not know if the middle name exists but we cannot see
it, or if it does not exist at all. There is 'unknown presumption'
because it is unknown in a balance of probabilities whether
a middle name exists or not. The cert/sign label would be
UP if any particular middle name is assumed in a signed
message.

Other examples can be built, illustrating the concept. The grade
of a student in a course, for example. If we know the grade, it
corresponds to the first line D; if we know that the student took the
exam but we do not know the grade yet, then we have the second line A;
if we know that the student recently registered at the course, then
we have the third line O; if we know that the course ended but we do
not know whether the student stayed in the course until the exam,
then we have the fourth line F.

BTW, if keyUsage is (0,0,0,0,0,0,0,0) then  this can be unambiguously
assigned to UP, as it seems natural.  Since UP is actually a neutral case
(neither affirmative nor denial), the case for CA or CRL bits in
keyUsage can be handled well with DS=NR=0 and can have the usual meanings.

So, there seems to be a practical way to encode four different levels of
validity for signatures, without breaking PKIX's current framework.  We
just need to break some new ground -- digital signatures are not simply
binding or not. There are degrees of binding as well.  And four seems to
be a convenient number to start.

Cheers,

Ed Gerck