On Thu, Sep 09, 2021 at 02:27:31PM -0700, Aleksander Adamowski wrote: > PKCS#11 API allows us to use opaque keys confined in hardware security > modules (HSMs) and similar hardware tokens without direct access to the > key material, providing logical separation of the keys from the > cryptographic operations performed using them. > > This commit allows using the popular libp11 pkcs11 module for the > OpenSSL library with `fsverity` so that direct access to a private key > file isn't necessary to sign files. > > The user needs to supply the path to the engine shared library > (typically the libp11 shared object file) and the PKCS#11 module library > (a shared object file specific to the given hardware token). The user > may also supply a token-specific key identifier. > > Test evidence with a hardware PKCS#11 token: > > $ echo test > dummy > $ ./fsverity sign dummy dummy.sig \ > --pkcs11-engine=/usr/lib64/engines-1.1/libpkcs11.so \ > --pkcs11-module=/usr/local/lib64/pkcs11_module.so \ > --cert=test-pkcs11-cert.pem && echo OK; > Signed file 'dummy' > (sha256:c497326752e21b3992b57f7eff159102d474a97d972dc2c2d99d23e0f5fbdb65) > OK > > Test evidence for regression check (checking that regular file-based key > signing still works): > > $ ./fsverity sign dummy dummy.sig --key=key.pem --cert=cert.pem && \ > echo OK; > Signed file 'dummy' > (sha256:c497326752e21b3992b57f7eff159102d474a97d972dc2c2d99d23e0f5fbdb65) > OK > > Signed-off-by: Aleksander Adamowski <olo@xxxxxx> > [EB: Avoided overloading the --key option and keyfile field, clarified > the documentation, removed logic from cmd_sign.c that libfsverity > already handles, and many other improvements.] > Signed-off-by: Eric Biggers <ebiggers@xxxxxxxxxx> > --- Applied, thanks. - Eric
|