Building OpenSC with OpenSSL 3.0.0

[dengert]

Problem Description

OpenSSL version 3.0.0 is now in alpha testing, and will soon be in beta. OpenSC can be built without OpenSSL, but many card drivers depend on some version of OpenSSL.

OpenSC can used multiple versions of OpenSSL by following the 1.1 API and accommodates older versions and LibreSSL with a few #ifdefs and sc-ossl-compat.h which defines some macros and inline code to handle the backward compatibility.

OpenSSL_3.0 makes some major changes. and now includes some backward compatibility features similar to sc-ossl-compat.h and allows for compiling with multiple APIs using CPPFLAGS="-DOPENSSL_API_COMPAT=0x10101000L" for 1.1.1.

The following tests were all run with a modified sc-ossl-compat.h which was easier then I had though it would be:
sc-ossl-compat.c.diff.txt

On Ubuntu 20.04, OpenSSL 3.0.0 was built from git and installed into /opt/ossl-3.0.0
https://www.openssl.org/source/gitrepo.html I used git:https://git.openssl.org/openssl.git

To include the legacy code for SHA1, DES, RIPEMD160 and other code used by OpenSC, /opt/ossl-3.0.0/ssl/openssl.cnf was modified as suggested in: https://wiki.openssl.org/index.php/OpenSSL_3.0#Providers

OpenSC was then built using:

CPPFLAGS="-DOPENSSL_USE_DEPRECATED -DDEBUG -DOPENSSL_API_COMPAT=0x10101000L
CFLAGS=""
LDFLAGS="-Wl,-rpath,/opt/ossl-3.0.0/lib"
../OpenSC/configure --disable-silent-rules --prefix=/opt/ossl-3.0.0 --enable-pcsc \
 --with-completiondir=/opt/ossl-3.0.0/etc/bash_completion.d \
 --with-pcsc-provider=/usr/lib/libpcsclite.so --enable-doc --disable-strict

results in 16 warnings, but ./pkcs11-tool --test --login using PIV demo card works.

Proposed Resolution Questions

What options do we expect distros to use when building OpenSSL 3.0.0 production?

Do we depend on deprecated function and the -DOPENSSL_API_COMPAT=0x10101000L?

If we try and convert to using native 3.0.0 API, what do we do about LiberSSL?

Do we drop all the "legacy" routines?

Do we have cards that depend on any of these?

Steps to reproduce

See above

Logs

[Jakuje]

We are already working on OpenSSL 3.0 for our next RHEL and I was told we do not plan to enable compat nor deprecated functions in these builds so we would be best with migrating off the deprecated functions. I think for example SHA1 is not recommended for quite some time (even thought the alternative is slightly longer).

[vjardin]

+1 it should be updated in order to support the latest APIs from OpenSSL 3.0 while the deprecated ones should be disabled properly.

[dengert]

OpenSSL-3.0.0 splits up the changes for support of Legacy_Algorithms from Low Level APIs (and other changes like "providers" and "engines".)

Based on openssl/providers/legacyprov.c the Legacy_Algorithms are: legacy_digests: MD2. MD4, MDC2, WHIRLPOOL and RIPEMD_160. And legacy_ciphers: CAST5, Blowfish, IDEA, SEED, RC2, RC4, MD5, RC5, DES and DESX(?).
defltprov.c list the default ones which includes DES3 and SHA1. There may be other ways OpenSSL limits the use of SHA1 and DES.

The Deprecated functions include SHA1 and DES and one can also build OpenSSL with any of the defines for OPENSSL_NO_* so there are multiple ways OpenSSL could be built with or without functions/algorithms OpenSC and PKCS11 support. These may include function/algorithms used by some cards that may still be in use.

Building OpenSSC-3.0.0 with deprecated functions and treating then as warnings, I get 269 warnings: Warnings.TMC-d.txt

Right now OpenSC is using the 1.1 API and providing macros and inline routines for older OpenSSL and LibreSSL
with some additional #ifdefs.

The APIs for OpenSSL and LibreSSL are getting further apart.

If we convert to using the OpenSSL-3.0.0 API in OpenSC, do we provides additional code to support older LibreSSL?
Do we drop support for LibreSSL?
Do we expect LibreSSL to provide an OpenSSL-3.0.0 API?

I don't see any use of DES routines other then to manipulate DES3 keys. But SHA1 is used in a number of source files.

[vjardin]

Assuming the OpenSSL 3.0 legacy digests or ciphers are still needed, I think we should have an opensc runtime (getenv() ?, config file ?) feature in order to keep using those legacy. If such opensc "legacy" runtime flag is not set (default), then opensc returns (+stops) on a error with a log statement that "legacy" capabilities cannot be used without an explicit request from the users.

Regarding the src/pkcs11/openssl.c warnings for the use of the ENGINE APIs, how can they be upgraded to OpenSSL 3.0 ?

Who is using LibreSSL with OpenSC ? Can they comment ?

[Jakuje]

AFAIK, LibreSSL already synced up with OpenSSL 1.1 API aside of couple of corner cases, which are not used in OpenSC as far as I know. But there is really no place where LibreSSL would be used aside of OpenBSD:

https://en.wikipedia.org/wiki/LibreSSL#Adoption

So unless there would be somebody interested in maintaining the support for LibreSSL (probably backed by CI), I would really not bother with that. The last Linux, Gentoo, dropped support for this earlier this year according to wiki.

By my last message, I did not mean that our OpenSSL will not have any deprecated functions. These will be in, but they will be marked as deprecated, which will fail the build with -Werror (default).

[dengert]

I am trying some builds of OpenSC master against LibreSSL 3.3.2 from their git repository.
This sets LIBRESSL_VERSION_NUMBER 0x3030200fL and OPENSSL_VERSION_NUMBER 0x20000000L as expected.
(I also want to test it with the changes from @ya-isakov for EdDSA.)

Many /usr/bin/ld: ../../src/libopensc/.libs/libopensc.so: warning: EVP_EncryptFinal is often misused, please use EVP_EncryptFinal_ex and EVP_CIPHER_CTX_cleanup This can easily be fixed.

The others are all in src/tests/p11test EVP_PKEY_new_raw_public_key and `EVP_DigestVerify' which could also be fixed.

So we appear to agree we should convert to using the OpenSSL 3.0.0 API and add to sc_ossl_compat.h any change needed to still use older versions of OpenSSL or LibreSSL.

But as @Jakuje points out only OpenBSD is using LibreSSL, so support for LibreSSL this would be a low priority, and need someone that uses it to do some testing.

In response to @vjardin, On the use of SHA1 for crypto like signatures is not recommended, but it is still used for uniqueness in some places, and it looks like it is not marked as "Legacy".

The OpenSC use of engines is to load support for GOST which is referenced in card-dnie.c, card-rttecp.c and card-rutoken.c

Where things might get trickey is OpenSSL can load the pkcs11 engine, that uses libp11 that loads opensc-pkcs11.so that loads the GOST engine. It works now, but the engine/provider stuff has changed.

The OpenSSL engine has changed a lot and libp11 may need some changes. But libp11 builds with OpenSSL 3.0.0 if deprecated functions are allowed and -DOPENSSL_API_COMPAT=0x10101000L is added. I still need to test it.

For this testing I have be building without -Werror, to see what needs to be changed.

[frankmorgner]

Yes, switching to the non-deprecated APIs should not be too hard. I fact, I appreciate all simplification of sc-ossl-compat.h. However, OpenSSL 1.1.1 will be supported until 2023-09-11, so we should also be compatible with that as well.

[dengert]

sc-ossl-compat.h was introduced in 2016 when OpenSC was still trying to support OpenSSL 0.9.8, 1.0.1, 1.0.2, and Libre-2.5.0.

There are a number of issues to consider:

1. API issues.
2. Algorithms that are no longer considered secure.
3. What will distros provide.
4. OpenSSL support

OpenSSL Release Strategy says: 1.1.0, 1.0.1, 1.0.0 and 0.9.8 are no longer supported and 1.0.2 extended support for security fixes is available. What should OpenSC support? I suggest 1.0.2, 1.1.1 and 3.0.0.

(But note that if OpenSSL is built without no-deprecated can support 1.0.2, 1.1.1 and 3.0.0. )

SHA1 is not deprecated, but the older API calls SHA1() as well as all the other uses of SHA256 can be fixed with EVP_Digest*.
I really comes down to using the EVP_* API everywhere.

As @Jakuje said, RedHat does not plan to enable compat nor deprecated functions. That says OpenSC needs to use the 3.0.0 API and not used and deprecated algorithms. When building OpenSSC 3.0.0 with no-deprecated It also defaulted to adding no-gost. DES is considered deprecated but it did not define no-des, so
OpenSC still tries to uses DES functions but the no-deprecated does not let it compile.

OpenSC has 3 drivers that use GOST: card-dnie.c, card-rtecp.c and card-rutoken.c. I have not looked at these closely.
Do we drop these card drivers, or remove their use of GOST?

OpenSC also still uses a lot of DES and the older DES APIs The use of the EVP_PKEY_* can fix the API, but the DES provider is a legacy and deprecated. The biggest use of the DES API is in the sm and smm directories and cardos-tool.c which do not compile. Does sm and smm really use single DES?

Do we drop support for any card that uses single DES?

Does OpenSC code still support the single DES and GOST, and tell users to compile OpenSSL-3.0.0 if the distros do not allow for legacy and deprecated algorithms?

[vjardin]

Thanks for the insides. Regarding some European eID, this document describes the "secure messaging" standard: http:https://www.informatica.uniroma2.it/upload/2018/TSC/IAS_ECC_v1.0.1_UK.pdf ; just in case, enclosed a copy of the document from this website (IAS_ECC_v1.0.1_UK.pdf).

From the sections 2.2 and 9.5.4, I understand that 3DES seems to be required.

While googling, some other IDs support "Secure Messaging", but I could not find if they use DES or not:

• FINEID - https://dvv.fi/documents/16079645/17324992/S1v40.pdf/371dd739-0962-c6a5-04d9-288ad5183cae/S1v40.pdf

OpenSC gets its implementation into sm-cwa14890.c but it is confusing: can anyone check the CWA 14890 standard ? (I do not have any copy) that specifies the details: according to some web references, it does not use plain DES but "CWA 14890-1 specifies two key triple DES (2KTDES)".

[Jakuje]

This was fixed with #2438. Closing.