Subject: Smart Card sign key and PIN-code Was: Non-Repudiation

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 14 Aug 1999 08:59:58 +0100

Just a little comment on the side of this great(?) NR-debate.
I think that this requirement to force a different PIN for signings and
always require it is a bit rigid.  It should depend on what you are signing.

For example: Assume that all credit-card transactions should be signed.  If
you require low value-payments (that you tend to do frequently) also to
go through a lengthy sequence of keying, such a system may become rather
impopular.  In the CyberPhone/Thin PKI specification there is a limit like
$1000/24hours before the system will enforce a PIN-code.  To always have
to use the PIN-code lowers security as it will be exposed in public.

For authentication purposes, a high-value resource should probably have
its own "PIN-code" and the PIN-code in the user-end becomes less needed 
(redundant I would say).  

Anders

-----Original Message-----
From: Peter Gutmann <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Saturday, August 14, 1999 01:45
Subject: Re: Non-Repudiation

>"Dale Gustafson" <[email-masked]> writes:
>
>>Smart card vendors will provide software libraries and card operating systems
>>that include support for a "signing only" key pair.  The distinguishing
>>characteristic of this special type of public/private key pair is that access
>>to the private key component is protected by a special "Signing Key PIN"
>>(distinct from the User PIN that controls general user access to the card).
>>The Signing Key PIN must be entered each and every time that private key is
>>used to create a digital signature (preferably through a protected
>>authentication path reader device -- the PIN characters go directly from the
>>keyboard or PINpad to the card and do not traverse the user's desktop or
>>laptop machine.)
>
>Is there any rigorous definition of exactly what's required for this, or just a
>general requirement that a user explicitly take some action to enable the key
>for each use?  The way I've implemented this is to allow an extra key attribute
>which acts as a usage counter for the object (eg a signature key), after every
>use the counter is decremented and once it reaches zero the object destroys
>itself.  For the "signing only" use described above, you'd just set the counter
>to 1.  This sort of thing would be fairly easy to add onto existing
>implementations, for example it could be a new PKCS #11 attribute which can be
>set when a key object is created (but not changed afterwards), once you've
>implemented it in the PKCS #11 driver you'd automatically have support for it
>in any apps which use the driver.
>
>Peter.
>
>

---

From: "Dale Gustafson" <[email-masked]>
Date: Mon, 16 Aug 1999 14:25:12 -0500

Anders, Peter,

When I first became aware of the requirements for the German Digital Signature laws
I thought the desire to control the mechanics of all signing key operations at the
crypto library level (essentially from the time the key pair was created) seemed
more than a little awkward.  Having listened to the ongoing PKIX debates on NR, I
can better understand the need to define such restrictions for a signing only key
pair.  These concepts may be useful irrespective of whether the key pair is created
and stored in a smart card or in a software lib.

Additional comments inline.

Best Regards,

Dale Gustafson

Anders Rundgren wrote:

> $1000/24 hours before the system will enforce a PIN-code.  To always have

Good point -- we need to ensure that such distinctions can be accomodated.

> >in any apps which use the driver.

I think the intent is that making a digital signature should be a "willful act" on
the part of the signer.  Entering a signing PIN for each digital signature operation
has been given as but one example of how a system could be implemented.  Clicking a
single button on a computer screen was given as a counter example of a user
operation that perhaps did not require sufficient user attention to be deemed a
"willful act".  For source material, I've been using the ESSSI Final Report, 7/20/99
provided earlier by Nick Pope or Denis Pinkas.

At the crypto library level, these high level requirements have been translated to a
specific capability:

 - a signing-only key pair can be created such that the user must be authenticated
(via a unique PIN) prior to using the private key as part of a digital signature
operation
 - the user is logged in to the signing key for the duration of a single digital
signature operation only.

The following is (at best) a very rough approximation of one of the new capabilities
being defined for PKCS#11, version 2.1.  The secure application will be able to
create a signing-only key pair that has a special, write-only (can never be read by
any application / can only be updated by a user or application who knows the current
value) attribute that contains the "signing PIN" for this key pair.  This PIN must
be entered each and every time the private key component is used to create a digital
signature.  Programatically, the signing PIN is provided by the calling application
once for each digital signature operation (a multiple command sequence in PKCS#11).
If a protected authentication path (secure PIN) reader is used, the crypto library
is directed by the secure application to initiate secure PIN entry via the
computer's keyboard or a PINpad device that's part of the reader, etc.

Similar signing key access control logic could be provided in software
implementations (sans secure keyboard/PINpad reader and smart card, of course).