When a PIN is explicitly provided, use it regardless of secure login flag

https://github.com/OpenSC/libp11/pull/445

Hi Gil,

Thanks for pointing to the specific change needed for this issue, I've attached it to this bug.

As Andreas mentioned in LP: #1982011, comment #11, Ubuntu policy does not permit backports of full upstream releases, except under certain exceptional circumstances. So the preference would be to backport just the discrete fixes to the particular issues having specific impacts on users.

There's three parts needed for an SRU. First is the fix, which you've indicated. Second is an 'impact statement' that explains why users need the fix for justification; I think we can figure this out but would love to hear your elaboration on what makes this important. Third is steps to reproduce the problem - this is remaining piece we need. Can you help define the steps to trigger the problem? I'm gather it needs configured for secure login and a secure pin is specified; can you suggest the config file snippets or command-line options needed? Thanks ahead of time.

Thanks for the detailed answer. I will try to give answers.
A hardware security module (HSM) is a physical computing device that safeguards and manages digital keys, performs encryption and decryption functions for digital signatures, strong authentication and 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, certificate authorities use HSM to keep digital keys, performs encryption and decryption functions.
Since the HSM has an important security role, for their management usually special hardware is required on the client side to identify with the HSM (PED).
Using PED required human in the client side.
Services the need HSM can't use PED to identify so they use PIN code and they can use the HSM but not admin operations.
libp11 is popular library that help to use pkc11 protocol. most of the HSM support pkcs11 protocol.
Most of uses of for such cases use LTS operating systems.

The bug:
If someone use this library to connect to HSM that support PED ("secure login" for this library) the library force to login with "secure login" even the client send PIN code and need to perform simple operation like sign/decrypt. This is a bug and version 0.4.12 fix this bug.

Impact:
All the users that use this library to connect HSMs that support PED (most of the big HSMs) can't use the library without the fix!

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

Thanks for providing the requested information, Gil.

After reading the discussion on bug #1982011, I'm curious to know if you can confirm that the fix from https://github.com/OpenSC/libp11/pull/445 is all that is needed in order to address this bug.

I can prepare a PPA with the patch applied so that you can test this issue, if possible.

Thanks from me as well Gil.

Meanwhile, I've copied your provided explanations into the SRU template in the bug description. I've done some copyediting to the text for clarity. Hopefully I haven't altered any meaning incorrectly in the process; if I have please either let me know in a comment, or go ahead and edit the bug description directly. Either way the Impact statement now looks pretty solid, and the steps to reproduce look straightforward.

Thanks!
I can confirm that the fix from https://github.com/OpenSC/libp11/pull/445 is all that is needed in order to address this bug.
The updated SRU template bug description is clear and correct.

Thanks, Gil.

As promised, here is the PPA containing a build of libp11 for Jammy with the patch included:

https://launchpad.net/~sergiodj/+archive/ubuntu/libp11

Please let us know when you have the chance to test it, and how it goes. I think we are OK to proceed with the upload once we verify that this is the correct fix.

Thanks again.

Thanks, Sergio
Why the debian files are with name 0.4.11 and not 0.4.12?

Hi Gil,

That's because this is a backport of the patch that fixes the issue. That's how we fix things in Ubuntu packages that are part of a released series: we backport the necessary patches on top of the version that's currently packaged.

Updating the software to 0.4.12 is a much harder process because we are not supposed to introduce new features into Ubuntu series that were already released.

Thanks Sergio,
I tested it and it's perfect and the new build fix the problem.
(I tested only amd64)

Thanks,
Gil

Hi Sergio,
Thanks for the fix. I tested it and it's working and it's solved the
problem.

On Thu, Sep 15, 2022 at 5:46 PM Sergio Durigan Junior <
<email address hidden>> wrote:

> Hi Gil,
>
> That's because this is a backport of the patch that fixes the issue.
> That's how we fix things in Ubuntu packages that are part of a released
> series: we backport the necessary patches on top of the version that's
> currently packaged.
>
> Updating the software to 0.4.12 is a much harder process because we are
> not supposed to introduce new features into Ubuntu series that were
> already released.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1987938
>
> Title:
> When a PIN is explicitly provided, use it regardless of secure login
> flag
>
> Status in libp11 package in Ubuntu:
> Fix Released
> Status in libp11 source package in Jammy:
> In Progress
> Status in libp11 source package in Kinetic:
> Fix Released
>
> 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).
>
> [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:
>
> op...

On Saturday, September 17 2022, Gil Weis wrote:

> Thanks Sergio,
> I tested it and it's perfect and the new build fix the problem.
> (I tested only amd64)

Thanks, Gil.

In this case, let's proceed with the SRU process. I will upload the
package, set this bug to "In Progress", and we will then have to wait
for someone from the SRU team to review the upload. Once they do, and
if they accept it, you will receive a notification saying that they
expect this fix to be verified by someone. We will rely on your help to
verify it, because you have the required hardware.

--
Sergio
GPG key ID: E92F D0B3 6B14 F1F4 D8E0 EB2F 106D A1C8 C3CB BF14

Uploaded:

$ dput libp11_0.4.11-1ubuntu0.22.04.1_source.changes
Trying to upload package to ubuntu
Checking signature on .changes
gpg: /home/sergio/work/libp11/libp11_0.4.11-1ubuntu0.22.04.1_source.changes: Valid signature from 106DA1C8C3CBBF14
Checking signature on .dsc
gpg: /home/sergio/work/libp11/libp11_0.4.11-1ubuntu0.22.04.1.dsc: Valid signature from 106DA1C8C3CBBF14
Uploading to ubuntu (via ftp to upload.ubuntu.com):
  Uploading libp11_0.4.11-1ubuntu0.22.04.1.dsc: done.
  Uploading libp11_0.4.11-1ubuntu0.22.04.1.debian.tar.xz: done.
  Uploading libp11_0.4.11-1ubuntu0.22.04.1_source.buildinfo: done.
  Uploading libp11_0.4.11-1ubuntu0.22.04.1_source.changes: done.
Successfully uploaded packages.

Thanks a lot!

Please could you complete a regression analysis? See "Where things could go wrong" at https://wiki.ubuntu.com/StableReleaseUpdates#Procedure.

Also, while upstream are in the best position to choose appropriate behaviour for a new release, this seems to be a deliberate change in behaviour in a stable release to allow the PIN to be entered from userspace rather than requiring it from the HSM (if I understand what you're fixing correctly?). Is this something that some security professionals would see as a regression, rather than something they want? For example, perhaps they want this behaviour to prevent users from routinely leaking their PINs to userspace? If so, then for them would this SRU be the wrong thing to do?

The test case is unclear to me: please could you add explicit "expected behaviour" and "actual behaviour" sections?

Sorry, I should have noticed that the "Where problems could occur" section is missing from the SRU template.

Gil, could you please address Robie's concerns before we can proceed with the SRU process? Thanks in advance.

Thanks Robie,
I updated the SRU description.
I hope that now it's clear that this is a bug and not a change in behaviour.
Currently the client with libp11 failed to login for operations that the
HSM required a PIN and not a PED. This is definitely a bug!

I added to SRU:

[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

On Wed, Sep 21, 2022 at 7:30 PM Robie Basak <email address hidden>
wrote:

> Please could you complete a regression analysis? See "Where things could
> go wrong" at https://wiki.ubuntu.com/StableReleaseUpdates#Procedure.
>
> Also, while upstream are in the best position to choose appropriate
> behaviour for a new release, this seems to be a deliberate change in
> behaviour in a stable release to allow the PIN to be entered from
> userspace rather than requiring it from the HSM (if I understand what
> you're fixing correctly?). Is this something that some security
> professionals would see as a regression, rather than something they
> want? For example, perhaps they want this behaviour to prevent users
> from routinely leaking their PINs to userspace? If so, then for them
> would this SRU be the wrong thing to do?
>
> The test case is unclear to me: please could you add explicit "expected
> behaviour" and "actual behaviour" sections?
>
> ** Changed in: libp11 (Ubuntu Jammy)
> Status: In Progress => Incomplete
>
> --
> You received this bu...

Hello Gil, or anyone else affected,

Accepted libp11 into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/libp11/0.4.11-1ubuntu0.22.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Performing the verification for Jammy.

First, creating RSA keys for:
- softhsm2
- yubikey5
- lunahsm

Creating openssl configuration files:

openssl_softhsm.cnf:
...
[engine_section]
pkcs11 = pkcs11_section

[pkcs11_section]
engine_id = pkcs11
dynamic_path = /usr/lib/x86_64-linux-gnu/engines-3/libpkcs11.so
MODULE_PATH = /usr/lib/softhsm/libsofthsm2.so
PIN = $ENV::engine_pin
init = 0

openssl_yubikey.cnf:
...
[engine_section]
pkcs11 = pkcs11_section

[pkcs11_section]
engine_id = pkcs11
dynamic_path = /usr/lib/x86_64-linux-gnu/engines-3/libpkcs11.so
MODULE_PATH = /usr/lib/x86_64-linux-gnu/libykcs11.so
PIN = $ENV::engine_pin
init = 0

openssl_lunahsm.cnf:
...
[engine_section]
pkcs11 = pkcs11_section

[pkcs11_section]
engine_id = pkcs11
dynamic_path = /usr/lib/x86_64-linux-gnu/engines-3/libpkcs11.so
MODULE_PATH = /usr/safenet/lunaclient/lib/libCryptoki2_64.so
PIN = $ENV::engine_pin
init = 0

reproducing the issue:
======================

$ apt policy libengine-pkcs11-openssl
libengine-pkcs11-openssl:
  Installed: 0.4.11-1build3
  Candidate: 0.4.11-1build3
  Version table:
 *** 0.4.11-1build3 500
        500 http://archive.ubuntu.com/ubuntu jammy/universe amd64 Packages
        100 /var/lib/dpkg/status

test with softhsm:
export SOFTHSM2_CONF=~/.config/softhsm2/softhsm2.conf
engine_pin=1234 OPENSSL_CONF=~/conf/yubikey/openssl_engine_softhsm.cnf \
 openssl req -new -batch -engine pkcs11 -keyform engine -key "pkcs11:token=Key pairs;object=aaa;object-type=private" -out /tmp/mytest_softhsm.csr
==> OK

test with yubikey:
engine_pin=123456 OPENSSL_CONF=~/conf/yubikey/openssl_engine_yubikey.cnf \
 openssl req -new -batch -engine pkcs11 -keyform engine -key "pkcs11:token=YubiKey PIV #13334408;object=Private key for Digital Signature;object-type=private" -out /tmp/mytest_yubikey.csr
==> OK

test with lunahsm:
engine_pin=123456 OPENSSL_CONF=~/conf/yubikey/openssl_engine_lunahsm.cnf \
 openssl req -new -batch -engine pkcs11 -keyform engine -key "pkcs11:token=Key pairs;object=aaa;object-type=private" -out /tmp/mytest_lunahsm.csr
==> FAIL

confirming that the new package fixes the bug:
==============================================

$ apt policy libengine-pkcs11-openssl
libengine-pkcs11-openssl:
  Installed: 0.4.11-1ubuntu0.22.04.1
  Candidate: 0.4.11-1ubuntu0.22.04.1
  Version table:
 *** 0.4.11-1ubuntu0.22.04.1 500
        500 http://archive.ubuntu.com/ubuntu jammy-proposed/universe amd64 Packages
        100 /var/lib/dpkg/status
     0.4.11-1build3 500
        500 http://archive.ubuntu.com/ubuntu jammy/universe amd64 Packages

test with softhsm:
export SOFTHSM2_CONF=~/.config/softhsm2/softhsm2.conf
engine_pin=1234 OPENSSL_CONF=~/conf/yubikey/openssl_engine_softhsm.cnf \
 openssl req -new -batch -engine pkcs11 -keyform engine -key "pkcs11:token=Key pairs;object=aaa;object-type=private" -out /tmp/mytest_softhsm.csr
==> OK

test with yubikey:
engine_pin=123456 OPENSSL_CONF=~/conf/yubikey/openssl_engine_yubikey.cnf \
 openssl req -new -batch -engine pkcs11 -keyform engine -key "pkcs11:token=YubiKey PIV #13334408;object=Private key for Digital Signature;object-type=private" -out /tmp/mytest_yubikey.csr
==> OK

test with lunahsm:
engine_pin=123456 OP...

This bug was fixed in the package libp11 - 0.4.11-1ubuntu0.22.04.1

---------------
libp11 (0.4.11-1ubuntu0.22.04.1) jammy; urgency=medium

  * d/p/0001-When-a-PIN-explicitly-provided-use-a-PIN-regadless-o.patch:
    Use a PIN when explicitly provided regardless of the security
    login flag. (LP: #1987938)

 -- Sergio Durigan Junior <email address hidden> Wed, 14 Sep 2022 19:28:16 -0400

The verification of the Stable Release Update for libp11 has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.