Nitrokey Pro with OpenSSL 1.1.1, TLS 1.3, and RSA-based certificates

I’m trying to set up OpenVPN with a Nitrokey Pro for client-side authentication as per the subject line. Notwithstanding the endless nettlesome quirks and bugs that needed to be overcome, I’ve arrived at the conclusion that it’s not possible because:

  1. TLS 1.3 mandates PSS padding when using RSA-based certificates. Since the Nitrokey Pro only supports PKCS padding, it therefore cannot be used directly (or at all - see #2 for more details).
  2. The OpenSSL function called by OpenVPN will perform software PSS padding and pass the result to the pkcs-helper library with request for a raw (aka “unpadded”) signature (when using the latest git version of OpenVPN and pkcs-helper - older versions will croak at OpenSSL’s request for an unpadded signature). Presumably, the choice of software padding was made for compatibility reasons, since cards are more likely to support unpadded over PSS signatures. Since the Nitrokey Pro does not support RSA-X-509 (i.e. raw/unpadded), this operation returns with “CKR_MECHANISM_NOT_SUPPORTED,” as expected.

As the token supports neither raw nor PSS RSA signatures, it seems pretty obvious to me that the subject-line setup is fundamentally impossible. Even if we fall back to TLS 1.2, we would simultaneously need to revert to an earlier version of OpenSSL to avoid the raw padding scenario. Neither of these actions are especially appealing from a security perspective. Are there any plans to implement RSA-X-509? Or RSA-PSS? I know this departs from the OpenPGP standard, but it would make the card more functional without any real sacrifice in security.

1 Like

Hi @dominic.schaub!

Incidentally at OpenSC there is already a discussion about it, with a possible solution. Please take a look at the link below, and let me know whether it works for you:

Hi!

Has there maybe been any progress on this issue?
I also planned on using my Pro2 to authenticate OpenVPN, but the TLS handshake fails miserably.
I’m assuming this is due to the same PSS padding issue pointed out by @dominic.schaub:

Mon Apr 20 14:19:32 2020 OpenVPN 2.4.9 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 19 2020
Mon Apr 20 14:19:32 2020 library versions: OpenSSL 1.1.1d 10 Sep 2019, LZO 2.10
Mon Apr 20 14:19:32 2020 PKCS#11: Adding PKCS#11 provider ‘/usr/lib/x86_64-linux-gnu/pkcs11/opensc-pkcs11.so’
Mon Apr 20 14:19:36 2020 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mon Apr 20 14:19:36 2020 Outgoing Control Channel Encryption: Cipher ‘AES-256-CTR’ initialized with 256 bit key
Mon Apr 20 14:19:36 2020 Outgoing Control Channel Encryption: Using 256 bit message hash ‘SHA256’ for HMAC authentication
Mon Apr 20 14:19:36 2020 Incoming Control Channel Encryption: Cipher ‘AES-256-CTR’ initialized with 256 bit key
Mon Apr 20 14:19:36 2020 Incoming Control Channel Encryption: Using 256 bit message hash ‘SHA256’ for HMAC authentication
Mon Apr 20 14:19:36 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]X.X.X.X:1194
Mon Apr 20 14:19:36 2020 Socket Buffers: R=[212992->212992] S=[212992->212992]
Mon Apr 20 14:19:36 2020 UDP link local: (not bound)
Mon Apr 20 14:19:36 2020 UDP link remote: [AF_INET]X.X.X.X:1194
Mon Apr 20 14:19:36 2020 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Mon Apr 20 14:19:36 2020 TLS: Initial packet from [AF_INET]X.X.X.X:1194, sid=13e0f274 7c5915f7
Mon Apr 20 14:19:36 2020 VERIFY OK: depth=1, CN=debca
Mon Apr 20 14:19:36 2020 VERIFY KU OK
Mon Apr 20 14:19:36 2020 Validating certificate extended key usage
Mon Apr 20 14:19:36 2020 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Mon Apr 20 14:19:36 2020 VERIFY EKU OK
Mon Apr 20 14:19:36 2020 VERIFY OK: depth=0, CN=server
Mon Apr 20 14:19:36 2020 OpenSSL: error:141F0006:SSL routines:tls_construct_cert_verify:EVP lib
Mon Apr 20 14:19:36 2020 TLS_ERROR: BIO read tls_read_plaintext error
Mon Apr 20 14:19:36 2020 TLS Error: TLS object → incoming plaintext read error
Mon Apr 20 14:19:36 2020 TLS Error: TLS handshake failed

@szszszsz I wasn’t able to find a solution on that thread.

I’m running debian with opensc-pkcs11=0.20.0, openvpn=2.4.9, libengine-pkcs11-openssl=0.4.10
The key and certificate were generated and imported as described here, minus the -config and and -extension flags.

Hi @mihp!

I do not see any progress the OpenSC issue ticket unfortunately.

@nitroalex Could you take a look? It seems to be linked with your ticket.

I try next week, I am sorry.