When a PIN is explicitly provided, use it regardless of secure login flag
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
libp11 (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Jammy |
Fix Released
|
High
|
Unassigned | ||
Kinetic |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[Impact]
If someone uses this library to connect to a hardware security module (HSM) that has PIN entry device (PED) support - aka "secure login" for this library - the library is forced to login with "secure login" even when the client sends a PIN code and needs to perform simple operation like sign/decrypt. This is a bug and version 0.4.12 fix this bug.
All users of this library connecting to HSMs that support PED (most of the big HSMs) can't use versions of the library prior to 0.4.12 (when the fix was first introduced).
[Test Case]
Steps to reproduce the problem (hsm module that support PED):
-------
All the operations with this library to HSMs that support PED with PIN code reproduce the problem. For example:
openssl conf file:
[openssl_init]
engines=
[engine_section]
pkcs11 = pkcs11_section
[pkcs11_section]
engine_id = pkcs11
dynamic_path = /usr/lib/
MODULE_PATH = hsm_module_
init = 0
command:
$ openssl
OpenSSL> req -engine pkcs11 -new -key "pkcs11:
-keyform engine -out req.pem -text -x509 -subj "/CN=Andreas Jellinghaus"
OpenSSL> x509 -engine pkcs11 -signkey "pkcs11:
-keyform engine -in req.pem -out cert.pem
Steps to test regressions:
hsm module that not support PED:
-------
openssl conf file:
[openssl_init]
engines=
[engine_section]
pkcs11 = pkcs11_section
[pkcs11_section]
engine_id = pkcs11
dynamic_path = /usr/lib/
MODULE_PATH = hsm_module_
init = 0
command:
$ openssl
OpenSSL> req -engine pkcs11 -new -key "pkcs11:
-keyform engine -out req.pem -text -x509 -subj "/CN=Andreas Jellinghaus"
OpenSSL> x509 -engine pkcs11 -signkey "pkcs11:
-keyform engine -in req.pem -out cert.pem
softhsm2 module that not support PED:
-------
openssl conf file:
[openssl_init]
engines=
[engine_section]
pkcs11 = pkcs11_section
[pkcs11_section]
engine_id = pkcs11
dynamic_path = /usr/lib/
MODULE_PATH =/usr/lib/
init = 0
command:
$ openssl
OpenSSL> req -engine pkcs11 -new -key "pkcs11:
-keyform engine -out req.pem -text -x509 -subj "/CN=Andreas Jellinghaus"
OpenSSL> x509 -engine pkcs11 -signkey "pkcs11:
-keyform engine -in req.pem -out cert.pem
yubikey token module that not support PED:
-------
openssl conf file:
[openssl_init]
engines=
[engine_section]
pkcs11 = pkcs11_section
[pkcs11_section]
engine_id = pkcs11
dynamic_path = /usr/lib/
MODULE_PATH = /usr/local/
init = 0
command:
$ openssl
OpenSSL> req -engine pkcs11 -new -key "pkcs11:
-keyform engine -out req.pem -text -x509 -subj "/CN=Andreas Jellinghaus"
OpenSSL> x509 -engine pkcs11 -signkey "pkcs11:
-keyform engine -in req.pem -out cert.pem
[Where problems could occur]
The proposed change has been accepted upstream and is part of a release. It is relatively straightforward, but it involves a bit of a code reorganization that can catch one's attention at first glance.
The obvious regression potential has to do with login operations using libp11, since this is the part of the code that's being changed. The reporter has tested the change and verified that it works for the HSM that support secure login, HSM that not support secure login, SoftHSM2 cases, and also for the regular, non-HSM scenarios like Yubikey tokens with pkcs11 library. If there is a regression in the login operations, we can readily revert the changes and investigate the problem with upstream's help.
[More info]
- HSM that has PIN entry device (PED) support ("secure login" for libp11)
- Some operations with HSM required PED (like HSM Administration, Creating keys, delete keys, creatin slots and some operations with HSM required PIN (like sign with existing keys, decrypt with existing keys)
What happens:
1. libp11 asks the HSM which authentications capabilities its hardware supports.
2. The HSM reply contains all the supported capabilities (from high to low).
3. Currently (this is the bug) libp11 chooses the highest and expect the client to use *only* the highest to login even when the HSM expects lower for the required operation.
4. The highest authentication capability (PED/Secure Login) is required only for administration (human involvement) on the client side and not for "normal" operations such sign/decrypt.
5. The bug prevents using libp11 for "normal" operations with HSM that support PED.
5. The bug fix: The client tries to login with the PIN for the required operation and if it succeeds, the operation continues.
In any case, the responsibility to allow login always lies with the HSM and it is the only one who decides whether to allow login with a PIN for the requested operation.
** Expected behaviour and Actual behaviour
Starting position:
- HSM that has PIN entry device (PED) support ("secure login" for libp11)
- Client that want to connect HSM for non PED operations (without human involvement on the client side, like services/micro services)
"expected behaviour":
Client try to login to HSM with PIN code (for operation that required PIN code and not PED) -> Success
"actual behaviour":
Client try to login to HSM with PIN code (for operation that required PIN code and not PED) -> Failed
[Background]
A hardware security module (HSM) is a physical computing device that safeguards and manages digital keys, performs encryption and decryption functions for digital signatures, ensures strong authentication and provides other cryptographic functions.
Due to the critical role they play in securing applications and infrastructure, HSMs and/or the cryptographic modules are typically certified to internationally recognized standards such as Common Criteria or FIPS 140 to provide users with independent assurance that the design and implementation of the product and cryptographic algorithms are sound.
Most of the big companies, banks, governments, and certificate authorities use HSM to keep digital keys, performs encryption and decryption functions.
Since HSM has an important security role, for their management usually special hardware is required on the client side to identify with the HSM (i.e. a PIN entry device, or PED). Using PED requires human involvement on the client side. Services the need HSM can't use actual PED units to do identification so they pass the PIN code so they can use the HSM but just not perform actual administrative operations.
libp11 is popular library that enables use of the pkc11 protocol. Most of the HSM's support pkcs11 protocol.
Most users for such cases use LTS operating systems.
[Original Report]
This bug prevent from using this library with HSM with provided PIN.
Version 0.4.12 fix this bug.
Please update Ubuntu 22.04 to include libp11 0.4.12 because without this fix it's impossible to use this library with HSM (Hardware Security Module) and Ubuntu 22.04 (Jammy).
(https:/
Thanks
summary: |
- When a PIN explicitly provided use a PIN regadless of secure login flag + When a PIN is explicitly provided, use it regardless of secure login + flag |
Changed in libp11 (Ubuntu Jammy): | |
status: | Triaged → In Progress |
description: | updated |
Changed in libp11 (Ubuntu Jammy): | |
status: | Incomplete → Confirmed |
description: | updated |
description: | updated |
Changed in libp11 (Ubuntu Jammy): | |
status: | Confirmed → In Progress |
description: | updated |
description: | updated |
tags: |
added: verification-done verification-done-jammy removed: verification-needed verification-needed-jammy |
tags: | removed: server-todo |
https:/ /github. com/OpenSC/ libp11/ pull/445