Code-Signing Tool – HSM. Has anyone built it successfully?

[WILBURCOLACO]

Hi

I'm trying to used the code signing tool (CST) with a HSM. I'm following instructions from "Code-Signing Tool – HSM User’s Guide Rev. 3.0.1 May 2018".

When I try running "make all" after copying 'libfrontend.a' to current working directory I get a curious error

ubuntu@GHFL71X2E:~/cst/release_3_3_0/code/back_end-hsm/src$ make all
$ARCH is []
gcc -std=c99 -D_POSIX_C_SOURCE=200809L -Wall -Werror -g -Wall -o cst libfrontend.a libbackend.a -L./lib -I/../openssl/include -mno-ms-bitfields -L/../openssl/lib -lssl -lcrypto -ldl -lpthread -lconfig -fno-builtin -fno-strict-aliasing -fno-common -DREMOVE_ENCRYPTION -Wl,--allow-multiple-definition
libfrontend.a(openssl_helper.o): In function `EVP_MD_CTX_free':
/opt/cst-repo/cst/cst-build/code/obj.linux64/../../code/common/src/openssl_helper.c:115: undefined reference to `EVP_MD_CTX_cleanup'
libfrontend.a(openssl_helper.o): In function `openssl_initialize':
/opt/cst-repo/cst/cst-build/code/obj.linux64/../../code/common/src/openssl_helper.c:182: undefined reference to `ERR_load_crypto_strings'
/opt/cst-repo/cst/cst-build/code/obj.linux64/../../code/common/src/openssl_helper.c:183: undefined reference to `OPENSSL_add_all_algorithms_noconf'
libfrontend.a(openssl_helper.o): In function `sign_data':
/opt/cst-repo/cst/cst-build/code/obj.linux64/../../code/common/src/openssl_helper.c:251: undefined reference to `EVP_MD_CTX_create'
/opt/cst-repo/cst/cst-build/code/obj.linux64/../../code/common/src/openssl_helper.c:275: undefined reference to `EVP_MD_CTX_destroy'
/opt/cst-repo/cst/cst-build/code/obj.linux64/../../code/common/src/openssl_helper.c:286: undefined reference to `EVP_MD_CTX_destroy'
/opt/cst-repo/cst/cst-build/code/obj.linux64/../../code/common/src/openssl_helper.c:303: undefined reference to `EVP_MD_CTX_destroy'
collect2: error: ld returned 1 exit status
Makefile:77: recipe for target 'all' failed
make: *** [all] Error 1

This is curious because openssl_helper.c is a file common to the backend as well, but it isn't flagged there

Any suggestions?

[Yuri]

    Below are a few points that might come useful for others:
- In AN12812, section 3.3, back_end-engine compilation does not work until you build the libfrontend static
   library and copy it to $OSTYPE/lib/ folder, since it is not pre-compiled in latest release of the cst.
 - In AN12812, item 6 of section 3.4.1.2 (Using in systems without p11-kit) should also be done in systems with p11-kit available.
 - On Ubuntu 16.04, packages opensc & opensc-pkcs11 are available in outdated versions that do not work with the SmartCard HSM.
    Up to date releases are available for download here: https://github.com/Nitrokey/opensc-build

[Yuri]

Hello,

   I've sent You directly some information.

Have a great day,

Yuri.

-------------------------------------------------------------------------------

Note:

- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored

Please open a new thread and refer to the closed one, if you have a related question at a later point in time.

[c_hahn]

Hi Yuri,

it looks like I ran into the same issue. Could you please provide the information for me as well ?

Best Regards

Cajus

[Yuri]

c.hahn 

Hello,

    To build the backend for CST 3.3.0 you need OpenSSL 1.0.2 as stated in the

release/code/back_end-hsm/README.md file.

The CST-HSM backend depends on:

- OpenSSL 1.0.2x

Regards,

Yuri.

[c_hahn]

Hello,

yes, I saw that, but the "normal" CST seems to work with openSSL 1.1.1 as well.

The 64bit Linux version does, the 32 bit Linux version does not!

The linux32/bin/cst depends explicitly on libcrypto-1.0, which belongs to openSSL 1.0x.

This is not the case for linux64/bin/cst. Confusing.

openSSL 1.0.2 is depreciated and outdated. Every newer Linux distribution uses 1.1.1x.

It is not possible to have 1.0 and 1.1 on the same host at the same time (at least not the development files)

I am even more confused about the fact that my linker error comes form libfrontend.a(openssl_helper.o) and not from libbackend.a (which I built from code/back-end-hsm)! The libfrontend.a is from the linux64/lib directory (as described in the documentation) and I would expect runtime issues if this library was used for building the linux64/bin/cst.

Is there really no way to make it working under openSSL 1.1.1x?

cajus@linux:~/cst-3.3.0/code/back_end-hsm/src> make all
$ARCH is []
gcc   -std=c99  -D_POSIX_C_SOURCE=200809L -Wall -Werror -g -Wall -o cst  libfrontend.a libbackend.a -L./lib  -I/../openssl/include -mno-ms-bitfields -L/../openssl/lib -lssl -lcrypto -ldl -lpthread -lconfig -fno-builtin -fno-strict-aliasing -fno-common -DREMOVE_ENCRYPTION -Wl,--allow-multiple-definition
/usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/bin/ld: libfrontend.a(openssl_helper.o): in function `EVP_MD_CTX_free':
/opt/cst-repo/cst/cst-build/code/obj.linux64/../../code/common/src/openssl_helper.c:115: undefined reference to `EVP_MD_CTX_cleanup'
/usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/bin/ld: libfrontend.a(openssl_helper.o): in function `openssl_initialize':
/opt/cst-repo/cst/cst-build/code/obj.linux64/../../code/common/src/openssl_helper.c:182: undefined reference to `ERR_load_crypto_strings'
/usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/bin/ld: /opt/cst-repo/cst/cst-build/code/obj.linux64/../../code/common/src/openssl_helper.c:183: undefined reference to `OPENSSL_add_all_algorithms_noconf'
/usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/bin/ld: libfrontend.a(openssl_helper.o): in function `sign_data':
/opt/cst-repo/cst/cst-build/code/obj.linux64/../../code/common/src/openssl_helper.c:251: undefined reference to `EVP_MD_CTX_create'
/usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/bin/ld: /opt/cst-repo/cst/cst-build/code/obj.linux64/../../code/common/src/openssl_helper.c:275: undefined reference to `EVP_MD_CTX_destroy'
/usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/bin/ld: /opt/cst-repo/cst/cst-build/code/obj.linux64/../../code/common/src/openssl_helper.c:286: undefined reference to `EVP_MD_CTX_destroy'
/usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/bin/ld: /opt/cst-repo/cst/cst-build/code/obj.linux64/../../code/common/src/openssl_helper.c:303: undefined reference to `EVP_MD_CTX_destroy'
collect2: error: ld returned 1 exit status
make: *** [Makefile:77: all] Error 1

Best Regards

Cajus

P.S. I just saw that you can also compile the frontend!

cajus@linux:~/cst-3.3.0/code/cst> OSTYPE=linux64 make

This will build a new libfrontend.a. With this lib my backend compiles without errors, but I'll need to check if it runs as expected......

Edit: 9th June:

The back_end-hsm code does not run as expected :-(

It stuck in the backend in some ENGINE_ call, no error message, nothing.

Besides that I found out, that the back_end-hsm code requires a HSM that has the capability of writing and downloading private keys from the HSM stick.

Downloading a private key from a HSM is a secutiry issue and not supported by many HSMs.

The normal way would be to to create a private/public key pair inside the HSM and download the public key.

The private key will never leave the HSM, thats what makes it safe.

To certify your data you need to push the data through the HSM and get the certificate out.

This is not supported by the current back_end-hsm implementation.

[cheuschkel]

@c_hahn  Did you have any luck working around this? It's upsetting that I have poured hours into implementation just to get to this same point. When I was running the CST-3.1.0, it appeared I was getting stuck in some ENGINE call as well. I did not run the hab4pki scripts; I generated the full PKI on my Nitrokey HSM and was trying to use that. I have all the certs locally, but did not want to expose the private keys (nor do I think there is an ability to). I have no idea how NXP is actually testing this; maybe they are only using HSMs capable of exporting private keys?