Re: [PATCH v2] drivers: misc: Add support for nCipher HSM devices

["Kim, David" <david.kim@ncipher.com>]

> > A cryptographic accelerator uses key material which is stored on, and managed
> > by, the host machine. Hardware security modules, such as nCipher’s Solo
> > products, retain key material (i.e. secrets) within the secure boundary of the
> > device, and implement various forms of access control to restrict use of that
> > key material.
> > 
> > nCipher's product range started, in the early 1990s, as cryptographic
> > accelerators.  The series of hardware security modules served by this driver
> > still does do cryptography but their main function is the generation, management
> > and use of keys within a secure boundary.
> > 
> > The driver doesn't do any cryptography. It provides the link between the
> > userspace software and the HSM's firmware. Cryptography is done within the HSM's
> > secure boundary.
> 
> So this should tie into the correct crypto/key apis that the kernel has
> and not create a brand new user/kernel api, right?
> 
> Please work with the crypto kernel developers to get this right, I can't
> take this until they agree that this code and api is correct.


Although it is technically possible for us to use the linux crypto APIs, that
doesn't fit in with how our hardware is meant to be used. Please see the
explanation below from Ian, one of our architects. If you feel that our driver
should instead be targeted to drivers/crypto, I can resubmit our patch to the
crypto list and we'll discuss with the crypto maintainers.

Thanks,
Dave

Ian's reply:

The Linux Kernel Crypto API
(https://www.kernel.org/doc/html/latest/crypto/intro.html) allows callers to
apply cryptographic transformations to input data. There is a socket-based
interface (https://www.kernel.org/doc/html/latest/crypto/userspace-if.html )
which makes these available to user-space. The documentation also mentions the
libkcapi library (http://www.chronox.de/libkcapi.html) which is a C wrapper
round the socket interface.

The basic mode of operation for all of these is: (a) create a transformation
object (or handle), (b) call a “set key” function to supply key data, (c) call
an encrypt or decrypt function to apply the transformation.

This interface is appropriate when the caller has the key data itself available.
In the user-space case, key data is supplied via the ALG_SET_KEY option passed
to setsockopt(). For the in-kernel interface, this is via various setkey()
function pointers in structures defined in include/linux/crypto.h.

The nCipher Solo device is a “Hardware Security Module”, the purpose of which is
to protect key data in various ways; its functionality goes beyond simply
providing implementations of cryptographic algorithms. In other words, the user
of an HSM doesn’t generally possess the key data itself, but requests access to
it via the HSM interface. Key data itself remains within the (physical and
logical) “security boundary” of the HSM, and access to it is subject to various
checks and policies. For instance, a smartcard which allows a digital signature
to be made when the user has correctly entered a PIN is acting as a simple
hardware security module.

Our customers use Solo HSMs where they have a need (often legally mandated) to
keep key data protected by a separate subsystem. Many require compliance with
the FIPS 140 standard
(https://csrc.nist.gov/publications/detail/fips/140/2/final) or the eIDAS
regulations (https://ec.europa.eu/futurium/en/eidas-observatory). So, while it
would be possible to implement a “set key” function to deliver key material to
the HSM in order to perform an operation, this would not meet the protection
requirements of these standards, and would be of no use to customers.