Check PIN for logged-in sessions

[bal-e]

pkcs11::pool::PoolConnection::ensure_logged_in() does not check the provided PIN if the PKCS#11 session has already been logged into. This is a security vulnerability; once a KMIP client provides the right PIN, no future clients need to provide it again.

Regarding the fix:

• It is probably not possible to repeat the PKCS#11 login operation safely. The spec allows it in one particular case, but we can't depend on that. It may also impose a performance burden. Instead, we should store the PIN in memory ourselves and verify it.
• We could store a salted hash of the PIN, or store the raw value ourselves. If an attacker knows the format of the PIN (e.g. 6-digit code), they could probably derive it from the hash. We should take care to secure the containing memory in either case.
• There are some OS-specific mechanisms for securing that memory; on Linux, I know of:
  • memfd_secret(2) (protect from most kernel access, and being swapped to disk)
  • mlock(2) (protect from being swapped to disk)
  • mprotect(2) (for establishing guard pages)
• Ideally, we would erase the stored PIN from memory when the system suspends, then log out and log back into PKCS#11. But AFAICT, there's no good (portable or even Linux-specific) way to detect when a suspend is occurring.

The simplest achievable solution would be to hash the password and do our best to store it in memory securely, wiping it periodically (after 5s idle or just every 5s) and on Drop.

[Philip-NLnetLabs]

Would it be possible to have PKCS#11 sessions be tied to KMIP sessions? That would solve this issue. It also makes sure that if a KMIP session gets a PKCS#11 session in a weird state there is less risk that other KMIP sessions will be affected.

[bal-e]

We would need a separate Pkcs11 context for every KMIP session ... but given our current thread model, you'd need a separate context for every KMIP session + worker thread. It's not clear whether all PKCS#11 libraries would handle this well (I don't think they always consider support for multiple Pkcs11 contexts on the same thread), and it would likely add memory/performance overhead. I'd prefer reusing PKCS#11 contexts across sessions and checking the PIN ourselves.

[Philip-NLnetLabs]

It seems to me that we have enough resources on any modern computer that we can have a number of worker threads per KMIP session. No need for sessions to share threads.

[ximon18]

• Instead, we should store the PIN in memory ourselves and verify it.

I have the feeling that this won't work for cases where the PIN is provided externally, e.g. via a pin entry pad. E.g. the OpenDNSSEC 1.4 documentation says:

The HSM PIN can now be omitted from the conf.xml file and entered via the 'ods-hsmutil login' command instead for increased security.

This refers to the code in the following locations:

• https://github.com/opendnssec/opendnssec/blob/b7b69f7090e0180354a342bc54449e065987f3f6/libhsm/src/bin/hsmutil.c#L694
• https://github.com/opendnssec/opendnssec/blob/2.1/develop/libhsm/src/lib/libhsm.c#L2328
• https://github.com/opendnssec/opendnssec/blob/b7b69f7090e0180354a342bc54449e065987f3f6/libhsm/src/lib/pin.c#L228

We could alternatively require KMIP Device Credentials (using the Password field for the PIN for initial PKCS#11 login and the Device Identifier field for subsequent verification) or TLS client certificates to authenticate the client.

[bal-e]

Ohhh... that's a good point, @ximon18. Device Identifier sounds useful, and there is also Ticket authentication (at least in KMIP 2.1). But we need to carefully check whether this would cause compatibility issues (i.e. that Cascade does not need to special-case kmip2pkcs11, and (slightly less importantly) non-Cascade clients will be able to use kmip2pkcs11).

Also, I'm glad this is moving us to omit the username and password from every single KMIP request. There's some needless network overhead there.