Messages in this thread |  | | From | "Kim, David" <> | Subject | Re: [PATCH v2] drivers: misc: Add support for nCipher HSM devices | Date | Thu, 9 Jan 2020 09:23:52 +0000 |
| |
> > 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.
|  |