Add support for public key authentication and n-of-m threshold scheme

[CardContact]

The newly released 2.0 version of the SmartCard-HSM (named "EA+" for extended authentication) supports public key authentication with a n-of-m threshold scheme.

The mechanism allows shared control over keys on a SmartCard-HSM, which is in particular useful for CA, sensitive SSH or code signing keys. It replaces the user PIN with a public key authentication scheme using ECDSA and a challenge-response protocol. The threshold scheme is defined during initialization and defines the total number of authentication keys and the quota required for a successful authentication.

As PKCS#11 does not support such an authentication mechanism directly, I would like to start a discussion how an integration with OpenSC could be accomplished.

[dengert]

On 10/29/2015 8:33 AM, CardContact Software & System Consulting wrote:

The newly released 2.0 version of the SmartCard-HSM (named "EA+" for extended authentication) supports public key authentication with a n-of-m threshold scheme.

The mechanism allows shared control over keys on a SmartCard-HSM, which is in particular useful for CA, sensitive SSH or code signing keys. It replaces the user PIN with a public key authentication
scheme using ECDSA and a challenge-response protocol. The threshold scheme is defined during initialization and defines the total number of authentication keys and the quota required for a successful
authentication.

As PKCS#11 does not support such an authentication mechanism directly, I would like to start a discussion how an integration with OpenSC could be accomplished.

PKCS#11 does support CKF_PROTECTED_AUTHENTICATION_PATH flag in CK_TOKEN_INFO which could be used to indicate that this feature might be supported.
and C_Login with a NULL password indicates to use some other authentication path. This is usually taken to be a pin pad reader.

PKCS#11 allows for *_VENDOR_DEFINED Objcts, Hardware Features, Certificate, Attributes, Mechanisms, Return values:
CKO_VENDOR_DEFINED, CKH_VENDOR_DEFINED, CHC_VENDOR_DEFINED, CKA_VENDOR_DEFINED, CKM_VENDOR_DEFINED, CKR_VENDOR_DEFINED.
Netscape and now NSS has used some of these mostly for indicating trust.

One way would be to define a vendor_defined object or vendor_defined mechanisum. to pass out and in parameters needed to the authentication.

Then to do the the ECDSA, C_Sign pointing at a special ECDSA key or keys one for each party.

(In any case VENDOR_DEFINED values should all start with 2 bytes that would not conflict with some
other vendors use of these. (OpenSC does use
#define CKA_OPENSC_NON_REPUDIATION (CKA_VENDOR_DEFINED | 1UL)
which is 0x8000000001, which could cause conflicts Starting with something like 0x80EA would be fairly unique.

—
Reply to this email directly or view it on GitHub #594.

Douglas E. Engert [email protected]

[CardContact]

CKF_PROTECTED_AUTHENTICATION_PATH is what I had in mind as well.

I guess the problem to solve is how to plug public key authentication into C_Login.

One way I could think of is to implement a RAMoverHTTP client that would allow an external component to perform the authentication steps. That way the pkcs#11 module in C_Login would connect to an authentication server and hand-over APDU access to the device. On the server the necessary authentication steps could be performed by key custodians logged into the server. Once authentication completes, the server terminates the connection and the module returns from C_Login.

[dengert]

On 10/29/2015 1:23 PM, CardContact Software & System Consulting wrote:

CKF_PROTECTED_AUTHENTICATION_PATH is what I had in mind as well.

I guess the problem to solve is how to plug public key authentication into C_Login.

One way I could think of is to implement a RAMoverHTTP client that would allow an external component to perform the authentication steps. That way the pkcs#11 module in C_Login would connect to an
authentication server and hand-over APDU access to the device. On the server the necessary authentication steps could be performed by key custodians logged into the server. Once authentication
completes, the server terminates the connection and the module returns from C_Login.

This is an N-of-M authentication. Does the card know the public keys of the M possible keys?
Does it then generate M challenges one for each of the M keys?

Application asks for attributes for a N-of-M vendor defined object, that returns the value of N, M and M challenges
possibly along with the M public keys as attributes Or query the token for one attribute that has all this.
This causes card to expect the responses.

Application then uses other means (Maybe pkcs11 to access N cards) to have each of the challenges signed.
Once application has N of the M challenges signed, it uses PKCS#11 calls to create another vendor-defined object,
with attributes for each of the N challenges. This is stored in PKCS#11 application (or on card).

When C_Login is then called without PIN, the above data is then presented to card, or card is told to verify the
signed challanges and card returns 9000 if it has worked.

So all the authentication is done over one PKCS#11 session.

Another way:

Define one vendor define attribute for the token.
If card does not support this it returns CKR_ATTRIBUTE_TYPE_INVALID.
If it does it returns a structure with all N, M and M challenges.
This also signals PKCS#11 implementation that next C_Login with NULL pin is not for a pinPAD reader,
but for the N of M authentication.

A call to C_Login with NULL PIN starts the process.
This also signals PKCS#11 implementation that this type of login has started.

Application then gets N of the M challenges signed, and presents
each response using C_Login with userType set to CKU_CONTEXT_SPECIFIC and the signed
challenge as the pin. (the PIN should be character, so may need to be base64)

Only after N calls to C_Logins with userType set to CKU_CONTEXT_SPECIFIC is the
PKCS#11 session considered R/W. and complete.

—
Reply to this email directly or view it on GitHub #594 (comment).

Douglas E. Engert [email protected]

[CardContact]

This is an N-of-M authentication. Does the card know the public keys of the M possible keys?
Does it then generate M challenges one for each of the M keys?
Yes, M public keys are registered during device initialization. This is
done outside of PKCS#11. A challenge is generated for each of the N
authentication keys.

I guess the individual authentication steps could be implemented using
C_GenerateRandom() to get the challenge and C_Login() with a structure
containing the key identifier and the signed challenge encoded in
Base64. The n-of-m state information (M, N and number of currently
authenticated keys) could be made available in a vendor defined object.

However this approach requires a modification of the application to
perform n-of-m. With CKF_PROTECTED_AUTHENTICATION_PATH changes are
higher that an application will work without modification, if the
authentication part is taken out of the equation.

Maybe we need both.

[dengert]

On 10/30/2015 4:09 AM, CardContact Software & System Consulting wrote:

This is an N-of-M authentication. Does the card know the public keys of the M possible keys?
Does it then generate M challenges one for each of the M keys?
Yes, M public keys are registered during device initialization. This is
done outside of PKCS#11. A challenge is generated for each of the N
authentication keys.

I guess the individual authentication steps could be implemented using
C_GenerateRandom() to get the challenge and C_Login() with a structure
containing the key identifier and the signed challenge encoded in
Base64. The n-of-m state information (M, N and number of currently
authenticated keys) could be made available in a vendor defined object.

However this approach requires a modification of the application to
perform n-of-m. With CKF_PROTECTED_AUTHENTICATION_PATH changes are
higher that an application will work without modification, if the
authentication part is taken out of the equation.

Maybe we need both.

OK, I can see how it could be very important to not change the application.

Has anyone implemented PKI authentication for C_Login? i.e. a 1 of 1 version?
If they have, could the same approach be used, but require N of M calls.

An example of a vendor using the VENDOR_DEFINED features:
https://wiki.ca.com/display/AA80/PKCS+11+Module

Something similar that required multiple PINs was deprecated:
http:https://www.cryptsoft.com/pkcs11doc/STANDARD/pkcs-11v2-11r1.pdf

6.7 Secondary authentication (Deprecated)
6.7.4 Secondary authentication PIN collection mechanisms
In 2.20 This was replaced with CKU_CONTEXT_SPECIFIC

—
Reply to this email directly or view it on GitHub #594 (comment).

Douglas E. Engert [email protected]

[CardContact]

A blog post explains the motivation and gives more background information.

[dengert]

Cool. The presentation show it nicely.

On 10/30/2015 9:23 AM, CardContact Software & System Consulting wrote:

A blog post http:https://www.smartcard-hsm.com/2015/10/10/Shared_Control_over_Key_Usage.html explains the motivation and gives more background information.

—
Reply to this email directly or view it on GitHub #594 (comment).

Douglas E. Engert [email protected]

[CardContact]

Addressed in #1711

[Viajaz]

#2301