Support CKU_CONTEXT_SPECIFIC PINs

[matthauck]

Currently, if I understand correctly, there are two ways to specify a PIN for a key using pkcs11 engine:

1. Setting the PIN global engine configuration
2. Setting the pin-value on the pkcs11 key URI

This is rather limiting for a situation where one may want to support loading several different keys, each perhaps coming from different slots, each with different passwords. I don't really feel comfortable putting the pin value on the key URI since this is something likely to get printed out to the screen or logged. Setting the global PIN is also not super ideal, since then the application loses control over the lifetime of the PIN living in memory as plain text.

What if libp11 instead offered a configuration option for a PIN_CALLBACK - a function that libp11 would call to grab the pin from the application as a const char*, which it could feed directly into C_Login and not have to manage the lifetime of at all? Seems like this would accomplish both the multiple PIN problem and the password-in-memory problem.

[matthauck]

Though, it looks like you cannot pass a pointer through an engine control command... :disappointed:

I suppose you could do it with the numeric type and cast the function pointer to a long and back to get it through the engine control interface... but that's pretty ugly. :fearful:

[dwmw2]

Please let's not give me an additional case to add to my historical rant at http://www.advogato.org/person/dwmw2/diary/205.html :)

Note that OpenSSL 1.1 is released, and the OpenSSL developers have indicated a willingness to accept something like libp11 into OpenSSL natively "post-1.1". So now is the time we could be starting to line up patches for crypto/p11. Perhaps any new APIs like this should be targeted there first, and then backported to libp11 for the older OpenSSL releases?

I think we want an API like the file-based APIs for loading keys. It just takes a PKCS#11 URI. It can take a a pin_callback option like the PEM code does. EVP_PKEY *key = PKCS11_load_PrivateKey_URI("pkcs11:token=foo;object=bar", pin_cb);

That's what we want applications to be able to use. (In fact, we want a higher-level API which handles all kinds of files transparently, and also PKCS#11 URIs, and the applications only have to pass through the string from the command line or config file without doing any of the heavy lifting to work out what that string is. But we start by providing the underlying functions native to OpenSSL, then proper integration and using them from elsewhere comes next...)

[matthauck]

That may well be the best path forward and the glorious future, and if that API were available, I would certainly use it! However, OpenSSL 1.1 is only very recently released and 1.0.1/1.0.2 will exist and be in use for a considerable time going forward. Are you saying that libp11 is basically obsolete and we should just start working on openssl and stop making feature requests here? If so, I'm not quite sure I buy that.

I still think that the idea has merit. It relieves the p11 engine of the burden of retrieving / managing the password in memory at all and also allows support for multiple PINs.

[dwmw2]

OpenSSL 1.1 is only very recently released and 1.0.1/1.0.2 will exist and be in use for a considerable time going forward. Are you saying that libp11 is basically obsolete and we should just start working on openssl and stop making feature requests here?

Nono. When I said "post-1.1" that means into OpenSSL 1.2, and I'm not even aware of any release plans for that yet. We're going to need libp11 for longer than that — for as long as 1.1 exists and is in use, which is years. Even if we can manage to obsolete it in the "glorious future", that time isn't now. We need to keep working on it.

What I said was that we should target new APIs at native OpenSSL, and then backport them to libp11. Not that we should abandon libp11 completely.

In this case, we have specific requirements for the API in OpenSSL native code, while the separate libp11 can basically do what it wants. So I'm saying that we should look at those requirements, and make something that satisfies them. So that libp11 can match what eventually goes into OpenSSL and applications don't need as much "porting" when OpenSSL 1.2 eventually reaches them.

What I want to do in OpenSSL is a slightly more generic PIN/passphrase callback. OpenSSL desperately needs a function which will just load a certificate/key and "Do The Right Thing" with a string from the user which says where to find it. Applications really shouldn't have to jump through hoops as they do now, working out for themselves what type of file (or PKCS#11 URI) it is and invoking the right OpenSSL functions to use it. They have to check for thsmselves whether the file is PKCS#1, PKCS#8, PKCS#12, or a PKCS#11 URI... and if it's PEM or DER... or even if it's something like the TPM engine's "KEY BLOB" files. So for that SSL_just_bloody_use_this_cert_the_user_gaave_us() API we'll need a callback which specifies what passphrase or PIN it's calling back to ask for.

[matthauck]

FYI. Playing around with this today and it's beginning to take some shape. I will post a PR later at the very least to see if it is going in the right direction.

Some initial rough thoughts:

• Looks like the ENGINE_ctrl_cmd has a more generic interface than I had realized for internal ctrl commands, though some ugly casting still has to happen since the function pointer type (incomprehensibly to me) does not even take the void* as a parameter.
• Looks like the callback will need to pass back the pkcs11 slot pointer instead of the key URI as I had originally imagined, since the login happens at the slot level not the key level.
• I think it will end up being two callbacks instead of just one so that a pin can be marked as "done" and, with sufficient ref-counting, the application can be empowered to (mostly ) keep the pin in non-cleartext.

[matthauck]

So... Looks like we don't need #103 and the libp11 engine specific logic it introduced, and UI_METHOD* provides exactly what I need and a little bit more. =)

One open question: How can we configure libp11 to stop copying/caching the password but instead prompting every time it needs it? In my case, this is not actually prompting the user each time of course, but is prompting the in-memory "protected" version (non-plaintext, using something like windows DPAPI, for example) to unprotect and reveal the password for a moment while in use.

I suppose an engine ctrl command is not going to be desired to accomplish this -- is there a better way?

[mtrojnar]

First, we need to move reading the PIN interactively from the engine to libp11. PKCS11_login should only receive the PIN via the parameter if a PIN was provided via the URI or the "PIN" ctrl. We then need to cache this parameter.

We probably shouldn't cache interactively retrieved PIN values. Please correct me if I'm wrong.

[matthauck]

Sounds good to me.

So, the slot would then cache the previous UI_METHOD* that was used to grab the password and re-prompt it when it needs to re-authenticate later? That does make it tricky for the application to know when it can tear down a particular UI_METHOD since the slot lifetime is easily going to be longer than the key's lifetime.

Maybe the slot should never cache the UI_METHOD*, and only the private key object should cache it (thinking of pkcs11_authenticate)? But even then, I suppose the PKCS11 key may outlive the EVP_PKEY?

[mtrojnar]

Yes, only the key object should cache UI_METHOD *. This is what I meant in https://github.com/OpenSC/libp11/pull/103#issuecomment-246806791

[dwmw2]

The problem with UI_METHOD is that it doesn't give an application anywhere to hang a private data pointer. In the UI itself we can use UI_add_user_data() and UI_get0_user_data() but there's no equivalent in the UI_METHOD. Hm, I meant to fix that in OpenSSL but never quite got round to it...

See the ui_vpninfo static variable (and the big nasty comment in create_openssl_ui() in http://git.infradead.org/users/dwmw2/openconnect.git/blob/v7.07:/openssl.c#l293

Also, some people build with OPENSSL_NO_UI. I know Mac OS X used to, in the days when it used OpenSSL. Not sure if any major instances exist still.

[matthauck]

So far, the UI_add_user_data which gets called with user void* data passed in from ENGINE_load_private_key has been sufficient for me so far -- I've been using that to store the this pointer that has the right context to return the right PIN, so as to avoid nasty global static variables.

I was concerned for a second there when I saw your comment that there may be thread-safety concerns or a global UI object -- but it looks like libp11 calls UI_new each time it queries for the password, so I think hanging the data on the UI* is actually fine...?

[matthauck]

I'm really not sure how an application will know how to manage the lifetime of its UI_METHOD* objects on account of the caching behavior of PKCS11 key objects. The only solution I can see is to make them live forever and never be destroyed...

[matthauck]

I suppose as long as the UI_METHOD* lives as long as the ENGINE, it should be safe; they could be destroyed after ENGINE_finish is called.

[mtrojnar]

Okay. I started implementing it.

[mtrojnar]

https://github.com/OpenSC/libp11/commit/7573c6e800cae3b429ae018c6a6bcdfe61bc1b4b changes the way CKA_ALWAYS_AUTHENTICATE PIN is requested. Does it fix this issue?

[mouse07410]

It breaks the normal functionality (see the referred issue https://github.com/OpenSC/libp11/issues/106), and now requires two PIN prompts to get one signature from the token!

There may be several ways to specify a PIN - but the PIN in question is still one and the same.

[matthauck]

@mtrojnar - Missing from that commit, I think, is the call to PKCS11_set_ui_method from eng_back.c. If one is loading a private key via the engine api (with a passed-in / non-null UI_METHOD*), seems like it would need some special handling. As it stands now, it looks like the UI would get invoked at login time, cached on the private slot context, and then never used again as the UI method get re-invoked each time it wants to pkcs11_authenticate.

Some suggested changes to complete this for the engine api:

1. Call out to some (shared?) code to get the PIN from an UI_METHOD* for pkcs11_login
2. Remember that this PIN was gotten from UI and not manually specified, and thus do not store it on the private slot context.
3. Call PKCS11_set_ui_method on the private key after getting a handle to it, so that when it needs to reprompt later, it will use the ui method.
4. Seems like this should also be modified to look for prev_pin in case an explicit UI_method was not used in specifying the PIN so that that workflow is not broken?

[mtrojnar]

As @dengert wrote in https://github.com/OpenSC/libp11/issues/72#issuecomment-195071206:

We are both using the SIGN key (9C) which has (PKCS#11 CKA_ALWAYS_AUTHENTICATE) PKCS#15 user_consent) NIST 800-73 calls this "PIN Always" "In other words, the PIN or OCC data must be submitted and verified every time immediately before a digital signature key operation."

Using the cached PIN value violated this requirement.

[mouse07410]

The title of this issue is very misleading. There are no "multiple PINs". There could be Global and Applet PINs (aka a PIN for the entire token, and a PIN for the PIV applet, and a PIN for the OpenPGP applet - though so far I have not seen Global ever used, only Applet PINs). Since libp11 deals only with PIV applet, I strongly suggest libp11 need not bother with that PIN multitude. Above all, there definitely is no such thing as a PIN for an individual key in a slot (like an additional PIN for the signing key). So when this commit asks for the "token PIN" and then for the "key PIN" it is wrong. And why would libp11 do anything between the login and the signing key operation that would require another request for the PIN is beyond my understanding.

Your commit 7573c6e talks about "CKA_ALWAYS_AUTHENTICATE PIN". There is no such thing. That flag simply means that there must be no token operation between PIN authentication and private key operation.

As for using cached PIN - in OpenSC this is controlled by the configuration parameter pin_cache_ignore_user_consent = true;. But in the example I gave there shouldn't be any need or cause for that (so the double prompting is wrong):

$ openssl dgst -engine pkcs11 -keyform engine -sha256 -sign "pkcs11:object=SIGN%20key;object-type=private" -out /tmp/derive.16700.text.sig /tmp/derive.16700.text
engine "pkcs11" set.
PKCS#11 token PIN: 
PKCS#11 key PIN: 
Signature is stored in /tmp/derive.16700.text.sig

[dengert]

As I read the NIST 800-73, the intent to require the user to approve each sign operation using the signing key. This a policy they enforce on the card. Any code we produce should try and uphold this policy. Some sites may set a policy to require a PIN PAD reader to be used, so underlying software can never cache a PIN because the PIN is never sent to the host. Any proposed changes must support the use of a PIN PAD reader.

[mouse07410]

@dengert I find this whole issue leading the project astray, as there are no multiple PINs (we don't consider PIN, PUK, etc). The first test/commit shows that it goes the wrong way. Would you recommend dropping 7573c6e and closing this issue? (I would.)

[dengert]

As for @mouse07410 comments, the PIV uses the same PIN to unlock the card for reading some objects and using other keys on the card as it does for the sign key. But other cards may have different PINs for different keys. PKCS#11 does not handle multiple PINs very well, making it very tricky to write generic code that would handle all situations.

A PIV card may have two PINs, Global and Applet PINs. The PIV Discovery object says which one is the default. The OpenSC PIV driver shows this via the PKCS#11 token label, which is either "PIV Card Holder pin (PIV_II)" or "Global PIN (PIV_II)"

[mtrojnar]

@mouse07410 wrote:

Your commit 7573c6e talks about "CKA_ALWAYS_AUTHENTICATE PIN". There is no such thing.

Yes, "CKU_CONTEXT_SPECIFIC PIN" would be better.

[dengert]

No I do not recommend closing this issue. As @matthauck said in the opening comment: "This is rather limiting for a situation where one may want to support loading several different keys, each perhaps coming from different slots, each with different passwords."

A single token may be presented as multiple tokens using multiple slots, each with its own PIN. This can get around some of the limitations of PKCS#11 PIN handling. Maybe the proposed changes need to take this into account some how. OpenSC's PKCS#11 allows each token to have multiple slots.

[mouse07410]

A single token may be presented as multiple tokens using multiple slots, each with its own PIN

What is your recommendation for ensuring that "normal" tokens (99%+ of all the tokens around in the real world?) that have only one PIN are not confused with those "virtualized multi-token multi-slot multi-PIN" monsters? So that, for example, I'm not prompted for a "context-specific PIN" when there is none? Maybe, detecting slots (assuming that one "slot" would have a PIV applet each, with potentially 4 active keys), and dealing with PINs on a slot basis?

The current (pre-7573c6e) code assumed there is one PIV token and therefore one PIN. It may be limiting for some, but it adequately reflected the majority of the use cases (including mine) and worked fine. The 7573c6e seems to live under assumption that every token around has those "context-specific PINs", which became a bother. The question is whether it is possible to address both (single-PIN tokens, and multi-PIN ones). If not - I recommend forking the code, as if the price of supporting multiple PINs (which I don't need) is the user being PIN-prompted at least twice for any signing operation (my users won't like it, and neither would I) or violating the policy (silently using cached PIN, effectively thumbing nose to the CKA_ALWAYS_AUTHENTICATE - I don't want to pay it. Let those for who multi-PIN is worth it have a separate fork/branch, and let those like me with "normal" needs have the "normal" branch with a limited single PIN per physical token.

[dwmw2]

As for @mouse07410 comments, the PIV uses the same PIN to unlock the card for reading some objects and using other keys on the card as it does for the sign key. But other cards may have different PINs for different keys. PKCS#11 does not handle multiple PINs very well, making it very tricky to write generic code that would handle all situations.

I think we need to stop conflating the layers here. Yes, PKCS#11 "doesn't handle multiple PINs very well" — in fact, apart from the SO PIN vs. user PIN, it doesn't handle them at all, does it?

So in the context of libp11 let's not talk about PIV weirdness of having different PINs for different keys. The only way to represent that in PKCS#11, AFAIK, is that you actually expose multiple slots+tokens in your PKCS#11 provider, and each token has a different PIN and contains one key. That is outside the scope of this discussion, as it happens in a layer below the PKCS#11 API.

As far as we're concerned, if we eschew card management and the SO PIN completely, a PKCS#11 token has ONE PIN. That's it. If a key in that token has the CKA_ALWAYS_AUTHENTICATE attribute, then we're often going to need to reauthenticate before using said key. But we don't need to keep track of the last operation we did and then do that preemptively, do we? We can do it only if/when a key operation returns CKR_USER_NOT_LOGGED_IN.

[dengert]

@mouse07410 Deal with PINs on a slot basis. What it sounds like is the current (or proposed code) has lost the ability to associate the prompt and the PIN with a pkcs#11 session, and only assumes one token, one session and one PIN. The pkcs#11 session is associated with a slot.

I believe the underlying PKCS#11 deals with multiple PINs by using multiple slots. I would not fork the code.

[dengert]

@dwmw2 PIV does NOT have different PINs for different keys. PIV is really an applet. The "Global PIN" refers to a Global platform card that may have multiple applets of which one happens to be a PIV applet. Each applet may have its own PIN, or the Global PIN may unlock the PIV applet and other applets too.

And that said, from a PKCS#11 prospective there is only on PIN for the PIV, The SO_PIN for PIV is not supported via PKCS#11, as the user should never know the PUK. Card management for PIV is not supported via PKCS#11. There are other tools.

So for this discussion, a PIV has only one pin and only needs one slot. But @matthauck is not talking about PIV. @mouse07410 keeps seeing the world as if PIV was the only token, and is missing the bigger picture.

It not that a hardware token has only one PIN, its that PKCS#11 can present many slots each with a single PKCS#11 token, and only one user PIN. But the underlying code in the PKCS#11 can present a single hardware device as multiple tokens each in a slot. So as you point out each "a PKCS#11 token has ONE PIN."

So to address @matthauck issue, the libp11 need cache a PIN for each token in a slot. And if he wants to have different pins for different keys the underlying PKCS#11 must present them as different tokens each in its own slot. (And concurrent open sessions to a single hardware device may have its own issues.)

[mtrojnar]

@dwmw2: Please do not edit my comments to suggest I wrote something I did not. See: https://github.com/OpenSC/libp11/issues/101#issuecomment-250071890

[dwmw2]

Um.. that isn't your comment at all, is it? It's entirely my comment, but falsely attributed to you. What happened there?

[mouse07410]

@mouse07410 keeps seeing the world as if PIV was the only token, and is missing the bigger picture

:-) It was hard enough and took enough time to get this (the "PIV world") to work correctly. I'm scared spitless of this "bigger pictures", and of the bugs I'd have to face that this bigger picture would introduce. This one is relatively benign - I suspect those that follow won't be.

[mtrojnar]

@dwmw2 You removed my comment and replaced it with your reply. Actually, my original comment quoted the technical document that required the PIN to be provided by the user for each operation on a key with the CKA_ALWAYS_AUTHENTICATE attribute.

[dwmw2]

@mtrojnar there is strangeness here. Looking at my email notifications I see your original version of that comment, but no email for @mouse07410's subsequent https://github.com/OpenSC/libp11/issues/101#issuecomment-250140868

It is vaguely possible that in a fit of stupidity I managed to edit your comment and then type in my own reply citing it, when I intended to add a new comment of my own. If that happened, I sincerely apologise. I don't think that's a likely explanation though; the user interface flow for adding a new comment is sufficiently different to editing an existing comment (especially the bit where you delete all the existing comment in the textbox) that it's hard to do by accident. I suspect there's something else going on. Anyway, I do have the email notification here for your original comment... do you want me to put it back how it was? I wouldn't normally (deliberately) edit another person's comment but I suspect you didn't get the email notification with a copy of your original text?

[mtrojnar]

I didn't get the notification. I would appreciate restoring my original comment.

[dwmw2]

Done. If that was indeed done in a fit of stupidity on my part, then I most sincerely apologise (again). Here's my reply again...

Using the cached PIN value violated this requirement.

Did it? The PIN must be submitted to the device each time, and it was being submitted to the device. Nobody ever wrote that the PIN MUST be manually typed in by the user every time, did they? Only that it needs to be re-submitted to the PIV device. Further up the stack is none of your business; that's outside the scope of the PIV specifications.

[mtrojnar]

Yes. The PIN must be "submitted" by the user. The next sentence clarifies it even more: "This ensures cardholder participation every time the private key is used for digital signature generation." http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-73-4.pdf

[mouse07410]

the libp11 need cache a PIN for each token in a slot

Please define a "slot" (to make sure it is not confused with 9A, 9C, etc).

[dengert]

In this discussion of PKCS#11 CKU_CONTEXT_SPECIFIC a "slot" is a PKCS#11 slot. In what PIV documentation do you see the PIV key reference numbers 9A, 9C etc referred to as a slot? If it is in OpenSC documentation, that should be modified to not use "slot" for the key reference.

[dengert]

Looking closer at this code, it looks like it should work. The pkcs11_authenticate is only called if the key to be used has the CKA_ALWAYS_AUTHENTICATE == TRUE. and

197 PKCS11_SLOT slot = KEY2SLOT(key); 198 PKCS11_CTX ctx = KEY2CTX(key); 199 PKCS11_KEY_private kpriv = PRIVKEY(key); 200 PKCS11_SLOT_private spriv = PRIVSLOT(slot);

make everything available to the code.

There are a few things that look strange: C_SignInit is called before pkcs11_authenticate in both p11_ec.c and -11_rsa.c Should they be reversed?

In p11_rsa.c pkcs11authenticate may be called twice! 96 /* Try signing first, as applications are more likely to use it / 105 /_ OpenSSL may use it for encryption rather than signing */

The pkcs11_authenticate 357 if (!UI_add_input_string(ui, "PKCS#11 key PIN: ", 358 UI_INPUT_FLAG_DEFAULT_PWD, pin, 1, MAX_PIN_LENGTH)) { 359 UI_free(ui);

This does not tell the user anything about which PIN is being requested. It always uses the same prompt. Does it need to specify more information that could be from the slot or tokenInfo?

[mtrojnar]

@dengert I highly recommend reading the specification before commenting on the accuracy of implementation. In this case the specification is https://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/os/pkcs11-base-v2.40-os.html

The CKA_ALWAYS_AUTHENTICATE attribute can be used to force re-authentication (i.e. force the user to provide a PIN) for each use of a private key. “Use” in this case means a cryptographic operation such as sign or decrypt. This attribute may only be set to CK_TRUE when CKA_PRIVATE is also CK_TRUE.

Re-authentication occurs by calling C_Login with userType set to CKU_CONTEXT_SPECIFIC immediately after a cryptographic operation using the key has been initiated (e.g. after C_SignInit). In this call, the actual user type is implicitly given by the usage requirements of the active key. If C_Login returns CKR_OK the user was successfully authenticated and this sets the active key in an authenticated state that lasts until the cryptographic operation has successfully or unsuccessfully been completed (e.g. by C_Sign, C_SignFinal,..). A return value CKR_PIN_INCORRECT from C_Login means that the user was denied permission to use the key and continuing the cryptographic operation will result in a behavior as if C_Login had not been called. In both of these cases the session state will remain the same, however repeated failed re-authentication attempts may cause the PIN to be locked. C_Login returns in this case CKR_PIN_LOCKED and this also logs the user out from the token. Failing or omitting to re-authenticate when CKA_ALWAYS_AUTHENTICATE is set to CK_TRUE will result in CKR_USER_NOT_LOGGED_IN to be returned from calls using the key. C_Login will return CKR_OPERATION_NOT_INITIALIZED, but the active cryptographic operation will not be affected, if an attempt is made to re-authenticate when CKA_ALWAYS_AUTHENTICATE is set to CK_FALSE.

[dengert]

Well, I was asking questions. Thanks for the response.

[mtrojnar]

The one question not directly answered by the PKCS#11 specification is whether libp11 prompt should include some information about the key selected for operation. In my opinion the answer is "no": PKCS#11 defines quite a few key selectors, and it is hard to guess which of them was used by the invoking application. It is the invoking application that should make it clear which key is about to be used. Including complete key information in the prompt would clutter the user interface of the invoking application.

[martinpaljak]

Please keep in mind that during all this PIN handling, a nice design validation comes from using a pinpad. And a card that requires a PIN entry per operation. And a card that has two PIN codes (very common in Europe)

And CKA_ALWAYS_AUTHENTICATE is a hint to the application that "it makes sense to C_Login before signing" instead of doing the "try to sign, user not logged in result, okay, login, then try to sign again" roundtrip.

[mtrojnar]

I currently don't have a pinpad hardware. I highly appreciate any testing/PRs for it.

My understanding was that a PKCS#11 module should not report CKA_ALWAYS_AUTHENTICATE to the invoking application (or libp11 in our case) if the authentication is supposed to be performed with an internal pinpad. Please correct me if I'm wrong.

[dwmw2]

The use of an internal pinpad maps to the CKF_PROTECTED_AUTHENTICATION_PATH flag. You are still expected to call C_Login() in that case, but just with a NULL PIN. I'm not sure why it would be mutually exclusive with CKA_ALWAYS_AUTHENTICATE.

[dwmw2]

And note that by if what you mean by "don't have a pinpad hardware" is that you _"don't have a PKCS#11 token which sets `CKF_PROTECTED_AUTHENTICATIONPATH".... on a Linux box you'll typically have the GNOME keyring module which does exactly that.

Probably wouldn't be hard to hack SoftHSM to support either or both of CKA_ALWAYS_AUTHENTICATE and CKF_PROTECTED_AUTHENTICATION_PATH too. The latter purely by not needing a PIN (or spawning ssh-askpass, if you must).

[martinpaljak]

No, CKA_ALWAYS_AUTHENTICATE and CKF_PROTECTED_AUTHENTICATION_PATH do not relate directly.

I can send you a Gemalto reader like this one: https://pood.telia.ee/productInfo/54/id-kaardi-lugeja-gemalto-pinpad-ct710/3700060102047 drop me an e-mail if you're interested.

[mtrojnar]

Thank you. I have never used the GNOME keyring PKCS#11 module.

Logically, invoking C_login with CKU_SO or CKU_USER and a NULL PIN makes sense to explicitly initiate a user interaction needed to access private objects. With CKU_CONTEXT_SPECIFIC, which is used during private key operations, the application just does not need to be aware of the user interaction.

Anyway, I will add support for it.

[dwmw2]

the application just does not need to be aware of the user interaction.

It might want to be aware of it. A well-behaved application will want to make sure the user is aware that they need to look at the pinpad. This might be especially true for the CKU_CONTEXT_SPECIFIC login where it's perhaps less likely to be triggered by a specific user action, and they might never notice that the pinpad is waiting for input.

Any callback mechanism we design for key loading should definitely include a notification up to the application when we trigger a pinpad login, and again when it's complete.

[mtrojnar]

I (mostly) agree. Please bear in mind the idea of libp11 is to have a simple interface to PKCS#11, which means that we will loose some of its flexibility.

Currently we have:

unsigned char secureLogin;

in the public interface, but:

CK_BBOOL always_authenticate;

in the private interface only. What about making it public in the PKCS11_KEY structure?