| 2022-08-27 11:29:26 |
Gil Weis |
bug |
|
|
added bug |
| 2022-08-30 02:14:57 |
Bryce Harrington |
attachment added |
|
use_provided_pin.patch https://bugs.launchpad.net/ubuntu/+source/libp11/+bug/1987938/+attachment/5612467/+files/use_provided_pin.patch |
|
| 2022-08-30 02:15:14 |
Bryce Harrington |
nominated for series |
|
Ubuntu Jammy |
|
| 2022-08-30 02:15:14 |
Bryce Harrington |
bug task added |
|
libp11 (Ubuntu Jammy) |
|
| 2022-08-30 02:15:14 |
Bryce Harrington |
nominated for series |
|
Ubuntu Kinetic |
|
| 2022-08-30 02:15:14 |
Bryce Harrington |
bug task added |
|
libp11 (Ubuntu Kinetic) |
|
| 2022-08-30 02:15:25 |
Bryce Harrington |
libp11 (Ubuntu Kinetic): status |
New |
Fix Released |
|
| 2022-08-30 02:15:38 |
Bryce Harrington |
tags |
|
server-todo |
|
| 2022-08-31 20:38:41 |
Sergio Durigan Junior |
bug |
|
|
added subscriber Sergio Durigan Junior |
| 2022-08-31 23:41:43 |
Bryce Harrington |
description |
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://bugs.launchpad.net/ubuntu/+source/libp11/+bug/1982011)
Thanks |
[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).
[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.
[Test Case]
Steps to reproduce the problem:
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
[engine_section]
pkcs11 = pkcs11_section
[pkcs11_section]
engine_id = pkcs11
dynamic_path = /usr/lib/ssl/engines/libpkcs11.so
MODULE_PATH = hsm_module.so
init = 0
command:
$ openssl
OpenSSL> req -engine pkcs11 -new -key "pkcs11:object=test-key;type=private;pin-value=XXXX" \
-keyform engine -out req.pem -text -x509 -subj "/CN=Andreas Jellinghaus"
OpenSSL> x509 -engine pkcs11 -signkey "pkcs11:object=test-key;type=private;pin-value=XXXX" \
-keyform engine -in req.pem -out cert.pem
[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://bugs.launchpad.net/ubuntu/+source/libp11/+bug/1982011)
Thanks |
|
| 2022-08-31 23:45:13 |
Bryce Harrington |
libp11 (Ubuntu Jammy): status |
New |
Triaged |
|
| 2022-08-31 23:45:21 |
Bryce Harrington |
libp11 (Ubuntu Jammy): importance |
Undecided |
High |
|
| 2022-08-31 23:47:55 |
Bryce Harrington |
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 |
|
| 2022-09-13 14:21:06 |
Gil Weis |
libp11 (Ubuntu Jammy): status |
Triaged |
In Progress |
|
| 2022-09-15 16:21:30 |
Sergio Durigan Junior |
bug |
|
|
added subscriber Ubuntu Server |
| 2022-09-21 16:22:59 |
Robie Basak |
libp11 (Ubuntu Jammy): status |
In Progress |
Incomplete |
|
| 2022-09-23 07:00:36 |
Gil Weis |
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).
[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.
[Test Case]
Steps to reproduce the problem:
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
[engine_section]
pkcs11 = pkcs11_section
[pkcs11_section]
engine_id = pkcs11
dynamic_path = /usr/lib/ssl/engines/libpkcs11.so
MODULE_PATH = hsm_module.so
init = 0
command:
$ openssl
OpenSSL> req -engine pkcs11 -new -key "pkcs11:object=test-key;type=private;pin-value=XXXX" \
-keyform engine -out req.pem -text -x509 -subj "/CN=Andreas Jellinghaus"
OpenSSL> x509 -engine pkcs11 -signkey "pkcs11:object=test-key;type=private;pin-value=XXXX" \
-keyform engine -in req.pem -out cert.pem
[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://bugs.launchpad.net/ubuntu/+source/libp11/+bug/1982011)
Thanks |
[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).
[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.
[Bug description]
- 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's happens:
1. libp11 asks the HSM which authentications capabilities its hardware supports.
2. The HSM response all the capabilities (from high to low).
3. Currently (this is the bug) libp11 choose the highest and expect the client to use *only* the highest to login even the HSM expect lower for the required operation.
4. The highest authentications capability (PED/Secure Login) required only for administration that human involvement on the client side and not for "normal" operations such sign/decrypt.
5. The bug prevent using libp11 for "normal" operations with HSM that support PED.
5. The bug fix: The client try to login with the PIN for the required operation and if it succeed, continue to run.
In any case, the responsibility to allow login always lies with the HSM and he is the only one who decides whether to allow login with a PIN for the requested operation.
[Where problems could occur]
Any HSM client that use libp11 library to connect HSM that support PED for non PED operations will fail because this bug.
["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
[Test Case]
Steps to reproduce the problem:
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
[engine_section]
pkcs11 = pkcs11_section
[pkcs11_section]
engine_id = pkcs11
dynamic_path = /usr/lib/ssl/engines/libpkcs11.so
MODULE_PATH = hsm_module.so
init = 0
command:
$ openssl
OpenSSL> req -engine pkcs11 -new -key "pkcs11:object=test-key;type=private;pin-value=XXXX" \
-keyform engine -out req.pem -text -x509 -subj "/CN=Andreas Jellinghaus"
OpenSSL> x509 -engine pkcs11 -signkey "pkcs11:object=test-key;type=private;pin-value=XXXX" \
-keyform engine -in req.pem -out cert.pem
[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://bugs.launchpad.net/ubuntu/+source/libp11/+bug/1982011)
Thanks |
|
| 2022-09-24 22:04:35 |
Bryce Harrington |
libp11 (Ubuntu Jammy): status |
Incomplete |
Confirmed |
|
| 2022-10-12 09:08:06 |
Gil Weis |
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).
[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.
[Bug description]
- 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's happens:
1. libp11 asks the HSM which authentications capabilities its hardware supports.
2. The HSM response all the capabilities (from high to low).
3. Currently (this is the bug) libp11 choose the highest and expect the client to use *only* the highest to login even the HSM expect lower for the required operation.
4. The highest authentications capability (PED/Secure Login) required only for administration that human involvement on the client side and not for "normal" operations such sign/decrypt.
5. The bug prevent using libp11 for "normal" operations with HSM that support PED.
5. The bug fix: The client try to login with the PIN for the required operation and if it succeed, continue to run.
In any case, the responsibility to allow login always lies with the HSM and he is the only one who decides whether to allow login with a PIN for the requested operation.
[Where problems could occur]
Any HSM client that use libp11 library to connect HSM that support PED for non PED operations will fail because this bug.
["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
[Test Case]
Steps to reproduce the problem:
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
[engine_section]
pkcs11 = pkcs11_section
[pkcs11_section]
engine_id = pkcs11
dynamic_path = /usr/lib/ssl/engines/libpkcs11.so
MODULE_PATH = hsm_module.so
init = 0
command:
$ openssl
OpenSSL> req -engine pkcs11 -new -key "pkcs11:object=test-key;type=private;pin-value=XXXX" \
-keyform engine -out req.pem -text -x509 -subj "/CN=Andreas Jellinghaus"
OpenSSL> x509 -engine pkcs11 -signkey "pkcs11:object=test-key;type=private;pin-value=XXXX" \
-keyform engine -in req.pem -out cert.pem
[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://bugs.launchpad.net/ubuntu/+source/libp11/+bug/1982011)
Thanks |
[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).
[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.
[Bug description]
- 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's happens:
1. libp11 asks the HSM which authentications capabilities its hardware supports.
2. The HSM response all the capabilities (from high to low).
3. Currently (this is the bug) libp11 choose the highest and expect the client to use *only* the highest to login even the HSM expect lower for the required operation.
4. The highest authentications capability (PED/Secure Login) required only for administration that human involvement on the client side and not for "normal" operations such sign/decrypt.
5. The bug prevent using libp11 for "normal" operations with HSM that support PED.
5. The bug fix: The client try to login with the PIN for the required operation and if it succeed, continue to run.
In any case, the responsibility to allow login always lies with the HSM and he is the only one who decides whether to allow login with a PIN for the requested operation.
[Where problems could occur]
login-related operations with this library.
["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
[Test Case]
Steps to reproduce the problem:
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
[engine_section]
pkcs11 = pkcs11_section
[pkcs11_section]
engine_id = pkcs11
dynamic_path = /usr/lib/ssl/engines/libpkcs11.so
MODULE_PATH = hsm_module.so
init = 0
command:
$ openssl
OpenSSL> req -engine pkcs11 -new -key "pkcs11:object=test-key;type=private;pin-value=XXXX" \
-keyform engine -out req.pem -text -x509 -subj "/CN=Andreas Jellinghaus"
OpenSSL> x509 -engine pkcs11 -signkey "pkcs11:object=test-key;type=private;pin-value=XXXX" \
-keyform engine -in req.pem -out cert.pem
[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://bugs.launchpad.net/ubuntu/+source/libp11/+bug/1982011)
Thanks |
|
| 2022-10-14 19:18:10 |
Sergio Durigan Junior |
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).
[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.
[Bug description]
- 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's happens:
1. libp11 asks the HSM which authentications capabilities its hardware supports.
2. The HSM response all the capabilities (from high to low).
3. Currently (this is the bug) libp11 choose the highest and expect the client to use *only* the highest to login even the HSM expect lower for the required operation.
4. The highest authentications capability (PED/Secure Login) required only for administration that human involvement on the client side and not for "normal" operations such sign/decrypt.
5. The bug prevent using libp11 for "normal" operations with HSM that support PED.
5. The bug fix: The client try to login with the PIN for the required operation and if it succeed, continue to run.
In any case, the responsibility to allow login always lies with the HSM and he is the only one who decides whether to allow login with a PIN for the requested operation.
[Where problems could occur]
login-related operations with this library.
["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
[Test Case]
Steps to reproduce the problem:
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
[engine_section]
pkcs11 = pkcs11_section
[pkcs11_section]
engine_id = pkcs11
dynamic_path = /usr/lib/ssl/engines/libpkcs11.so
MODULE_PATH = hsm_module.so
init = 0
command:
$ openssl
OpenSSL> req -engine pkcs11 -new -key "pkcs11:object=test-key;type=private;pin-value=XXXX" \
-keyform engine -out req.pem -text -x509 -subj "/CN=Andreas Jellinghaus"
OpenSSL> x509 -engine pkcs11 -signkey "pkcs11:object=test-key;type=private;pin-value=XXXX" \
-keyform engine -in req.pem -out cert.pem
[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://bugs.launchpad.net/ubuntu/+source/libp11/+bug/1982011)
Thanks |
[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:
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
[engine_section]
pkcs11 = pkcs11_section
[pkcs11_section]
engine_id = pkcs11
dynamic_path = /usr/lib/ssl/engines/libpkcs11.so
MODULE_PATH = hsm_module.so
init = 0
command:
$ openssl
OpenSSL> req -engine pkcs11 -new -key "pkcs11:object=test-key;type=private;pin-value=XXXX" \
-keyform engine -out req.pem -text -x509 -subj "/CN=Andreas Jellinghaus"
OpenSSL> x509 -engine pkcs11 -signkey "pkcs11:object=test-key;type=private;pin-value=XXXX" \
-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 case, and also for the regular, non-HSM scenarios. 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://bugs.launchpad.net/ubuntu/+source/libp11/+bug/1982011)
Thanks |
|
| 2022-10-14 19:18:54 |
Sergio Durigan Junior |
libp11 (Ubuntu Jammy): status |
Confirmed |
In Progress |
|
| 2022-10-14 20:12:01 |
Gil Weis |
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:
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
[engine_section]
pkcs11 = pkcs11_section
[pkcs11_section]
engine_id = pkcs11
dynamic_path = /usr/lib/ssl/engines/libpkcs11.so
MODULE_PATH = hsm_module.so
init = 0
command:
$ openssl
OpenSSL> req -engine pkcs11 -new -key "pkcs11:object=test-key;type=private;pin-value=XXXX" \
-keyform engine -out req.pem -text -x509 -subj "/CN=Andreas Jellinghaus"
OpenSSL> x509 -engine pkcs11 -signkey "pkcs11:object=test-key;type=private;pin-value=XXXX" \
-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 case, and also for the regular, non-HSM scenarios. 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://bugs.launchpad.net/ubuntu/+source/libp11/+bug/1982011)
Thanks |
[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
[engine_section]
pkcs11 = pkcs11_section
[pkcs11_section]
engine_id = pkcs11
dynamic_path = /usr/lib/ssl/engines/libpkcs11.so
MODULE_PATH = hsm_module_that_support_PED.so
init = 0
command:
$ openssl
OpenSSL> req -engine pkcs11 -new -key "pkcs11:object=test-key;type=private;pin-value=XXXX" \
-keyform engine -out req.pem -text -x509 -subj "/CN=Andreas Jellinghaus"
OpenSSL> x509 -engine pkcs11 -signkey "pkcs11:object=test-key;type=private;pin-value=XXXX" \
-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
[engine_section]
pkcs11 = pkcs11_section
[pkcs11_section]
engine_id = pkcs11
dynamic_path = /usr/lib/ssl/engines/libpkcs11.so
MODULE_PATH = hsm_module_without_support_PED.so
init = 0
command:
$ openssl
OpenSSL> req -engine pkcs11 -new -key "pkcs11:object=test-key;type=private;pin-value=XXXX" \
-keyform engine -out req.pem -text -x509 -subj "/CN=Andreas Jellinghaus"
OpenSSL> x509 -engine pkcs11 -signkey "pkcs11:object=test-key;type=private;pin-value=XXXX" \
-keyform engine -in req.pem -out cert.pem
yubikey token module that not support PED:
-------------------------------------------------------------
openssl conf file:
[openssl_init]
engines=engine_section
[engine_section]
pkcs11 = pkcs11_section
[pkcs11_section]
engine_id = pkcs11
dynamic_path = /usr/lib/ssl/engines/libpkcs11.so
MODULE_PATH = /usr/local/lib/libykcs11.so
init = 0
command:
$ openssl
OpenSSL> req -engine pkcs11 -new -key "pkcs11:object=test-key;type=private;pin-value=XXXX" \
-keyform engine -out req.pem -text -x509 -subj "/CN=Andreas Jellinghaus"
OpenSSL> x509 -engine pkcs11 -signkey "pkcs11:object=test-key;type=private;pin-value=XXXX" \
-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://bugs.launchpad.net/ubuntu/+source/libp11/+bug/1982011)
Thanks |
|
| 2022-10-14 20:16:27 |
Gil Weis |
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
[engine_section]
pkcs11 = pkcs11_section
[pkcs11_section]
engine_id = pkcs11
dynamic_path = /usr/lib/ssl/engines/libpkcs11.so
MODULE_PATH = hsm_module_that_support_PED.so
init = 0
command:
$ openssl
OpenSSL> req -engine pkcs11 -new -key "pkcs11:object=test-key;type=private;pin-value=XXXX" \
-keyform engine -out req.pem -text -x509 -subj "/CN=Andreas Jellinghaus"
OpenSSL> x509 -engine pkcs11 -signkey "pkcs11:object=test-key;type=private;pin-value=XXXX" \
-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
[engine_section]
pkcs11 = pkcs11_section
[pkcs11_section]
engine_id = pkcs11
dynamic_path = /usr/lib/ssl/engines/libpkcs11.so
MODULE_PATH = hsm_module_without_support_PED.so
init = 0
command:
$ openssl
OpenSSL> req -engine pkcs11 -new -key "pkcs11:object=test-key;type=private;pin-value=XXXX" \
-keyform engine -out req.pem -text -x509 -subj "/CN=Andreas Jellinghaus"
OpenSSL> x509 -engine pkcs11 -signkey "pkcs11:object=test-key;type=private;pin-value=XXXX" \
-keyform engine -in req.pem -out cert.pem
yubikey token module that not support PED:
-------------------------------------------------------------
openssl conf file:
[openssl_init]
engines=engine_section
[engine_section]
pkcs11 = pkcs11_section
[pkcs11_section]
engine_id = pkcs11
dynamic_path = /usr/lib/ssl/engines/libpkcs11.so
MODULE_PATH = /usr/local/lib/libykcs11.so
init = 0
command:
$ openssl
OpenSSL> req -engine pkcs11 -new -key "pkcs11:object=test-key;type=private;pin-value=XXXX" \
-keyform engine -out req.pem -text -x509 -subj "/CN=Andreas Jellinghaus"
OpenSSL> x509 -engine pkcs11 -signkey "pkcs11:object=test-key;type=private;pin-value=XXXX" \
-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://bugs.launchpad.net/ubuntu/+source/libp11/+bug/1982011)
Thanks |
[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
[engine_section]
pkcs11 = pkcs11_section
[pkcs11_section]
engine_id = pkcs11
dynamic_path = /usr/lib/ssl/engines/libpkcs11.so
MODULE_PATH = hsm_module_that_support_PED.so
init = 0
command:
$ openssl
OpenSSL> req -engine pkcs11 -new -key "pkcs11:object=test-key;type=private;pin-value=XXXX" \
-keyform engine -out req.pem -text -x509 -subj "/CN=Andreas Jellinghaus"
OpenSSL> x509 -engine pkcs11 -signkey "pkcs11:object=test-key;type=private;pin-value=XXXX" \
-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
[engine_section]
pkcs11 = pkcs11_section
[pkcs11_section]
engine_id = pkcs11
dynamic_path = /usr/lib/ssl/engines/libpkcs11.so
MODULE_PATH = hsm_module_without_support_PED.so
init = 0
command:
$ openssl
OpenSSL> req -engine pkcs11 -new -key "pkcs11:object=test-key;type=private;pin-value=XXXX" \
-keyform engine -out req.pem -text -x509 -subj "/CN=Andreas Jellinghaus"
OpenSSL> x509 -engine pkcs11 -signkey "pkcs11:object=test-key;type=private;pin-value=XXXX" \
-keyform engine -in req.pem -out cert.pem
softhsm2 module that not support PED:
-------------------------------------------------------------
openssl conf file:
[openssl_init]
engines=engine_section
[engine_section]
pkcs11 = pkcs11_section
[pkcs11_section]
engine_id = pkcs11
dynamic_path = /usr/lib/ssl/engines/libpkcs11.so
MODULE_PATH =/usr/lib/x86_64-linux-gnu/softhsm/libsofthsm2.so
init = 0
command:
$ openssl
OpenSSL> req -engine pkcs11 -new -key "pkcs11:object=test-key;type=private;pin-value=XXXX" \
-keyform engine -out req.pem -text -x509 -subj "/CN=Andreas Jellinghaus"
OpenSSL> x509 -engine pkcs11 -signkey "pkcs11:object=test-key;type=private;pin-value=XXXX" \
-keyform engine -in req.pem -out cert.pem
yubikey token module that not support PED:
-------------------------------------------------------------
openssl conf file:
[openssl_init]
engines=engine_section
[engine_section]
pkcs11 = pkcs11_section
[pkcs11_section]
engine_id = pkcs11
dynamic_path = /usr/lib/ssl/engines/libpkcs11.so
MODULE_PATH = /usr/local/lib/libykcs11.so
init = 0
command:
$ openssl
OpenSSL> req -engine pkcs11 -new -key "pkcs11:object=test-key;type=private;pin-value=XXXX" \
-keyform engine -out req.pem -text -x509 -subj "/CN=Andreas Jellinghaus"
OpenSSL> x509 -engine pkcs11 -signkey "pkcs11:object=test-key;type=private;pin-value=XXXX" \
-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://bugs.launchpad.net/ubuntu/+source/libp11/+bug/1982011)
Thanks |
|
| 2022-10-17 13:15:17 |
Timo Aaltonen |
libp11 (Ubuntu Jammy): status |
In Progress |
Fix Committed |
|
| 2022-10-17 13:15:19 |
Timo Aaltonen |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2022-10-17 13:15:21 |
Timo Aaltonen |
bug |
|
|
added subscriber SRU Verification |
| 2022-10-17 13:15:24 |
Timo Aaltonen |
tags |
server-todo |
server-todo verification-needed verification-needed-jammy |
|
| 2022-10-20 20:58:55 |
Gil Weis |
tags |
server-todo verification-needed verification-needed-jammy |
server-todo verification-done verification-done-jammy |
|
| 2022-10-25 08:17:20 |
Launchpad Janitor |
libp11 (Ubuntu Jammy): status |
Fix Committed |
Fix Released |
|
| 2022-10-25 08:17:24 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2022-11-24 09:02:16 |
Miriam España Acebal |
tags |
server-todo verification-done verification-done-jammy |
verification-done verification-done-jammy |
|
