PKCS#11 - How to protect smartcard owner, from malicious smartcard provider when writing new certificates on an already provisioned smartcard

Question

I am currently learning PKCS#11 and there is a certain scenario that I don't know how to deal with.

This is the scenario:

• A client who would like to acquire certificates from a provider enters his data,
• A client comes to a provider facility, where he can acquire ordered smartcard, with certificates (qualified, and commercial for example) written on it,
• Two things have to happen with the smartcard: provider has to generate key pair for both certificates, and then write a certificate on card (which requires User PIN)

Smartcards, as far as I know have two types of user: normal user (User PIN), and SO (SO PIN).

So what is the problem? When provider uses the User PIN for generating keys, and writing certificates, we can change it programatically with SetPin interop operation, or let client change it later in home, with appropriate software. Problem occurs, when a client would want to acquire new certificates for his smart card, and at this stage, provider doesn't know the User PIN for the card (i.e. he is not able to use any cryptographic mechanisms on the card). If the client would provide the password for the providing person, he would be able to make the client sign some random documents with his certificates, instead of using the PIN for the right cause (utilizing PKCS#11 mechanisms for writing a new certificate)

So my question is:

Is there any way that we can have a second User PIN on the card (separate for provider, and client) for certain tokens? Can we make some PKCS#11 mechanisms available only to specific user (for example generating key pair only for provider, and signing documents with certificates only for the client)?

What would be standarized scenario for dealing with this kind of problem? I would be glad to hear your opinions.

Answer 1

While you correctly describe user and SO-PINs, real cards may have significantly more PINs, and other authentication methods as well such as biometric authentications and challenge response tests (proving knowledge of a secret symmetric key).

For an authentication against a system the PIN mechanism is inappropriate (can be attacked via replay) and challenge-response is the typical solution. This also has the advantage, that it will not allow to perform a signature.

Another option (if the key can only be generated once) would be via the life cycle of the certificate file. An un-initialized file may not require an authentication at all and only after writing the certificate the life cycle of the file is changed.

One can also re-order the complete process, so the User-PIN is not yet valid and therefore no signature can be created at the time of certificate writing. Only afterwards the user chooses a PIN value and establishes that.