Subject: [KEYPROV] Securing PIN policies - From provisioning to enforcement

From: Anders Rundgren <[email-masked]>
Date: Thu, 19 Mar 2009 16:38:27 +0100

For those of you guys who are slightly research-oriented, the following 
may be of some interest...  :-)

Somebody told me that specifying things like PIN policies in a 
provisioning protocol was a bad idea since the client-could do whatever 
it wanted with this information, including ignoring it.

However, after thinking a bit about this glaring wart for a while, I 
believe that this is yet another area where external key MAC schemes 
excel because you could make (locally enforceable NB) issuer policy 
information a part of a key integrity MAC as well.

Assume that the issuer has specified a PIN min-length you could have a 
key-import API like the following:

importKey (<encrypted key>,<MAC>, <declared PIN min-length>, <user-set PIN>)

Properly designed, the API should reject a tampered-with PIN policy as 
well as a user-defined PIN that doesn't match the policy.

I don't intend to add this scheme to KeyGen2 because KeyGen2 ties 
general-purpose credential policies to attested key-pairs instead of 
MACs which is more powerful since policy violations are detected already 
during the issuance process rather than leaving the user with a 
potentially half-provisioned, non-working token.

The idea behind this is creating a "smarter smart card" which together 
with embedded device certificates, could be technically quite secure to 
provision in the field using computers not configured (or known) by the 
issuing organization which have several important use-cases:

- consumers
- employees who are outside of the organization's regular domain and 
desperately need a replacement card
- mobile devices using built-in crypto HW

Anders R