2

When using a (PKCS#11) based HSM (for S/Mime or PGP) the public key operations for signing or decryption is done by the HSM so that the key has to never leave the protected environment. The bulk part of those operations (for signing this is the digest creation and for encryption this is the symmetric cipher) can be done by the host.

However I noticed that most PKCS#11 implementations (even slow smart cards) do also offer symmetric ciphers and even hashing. I can see reasons for that:

  • by using the crypto interface and hardware implementation one can claim (hardened) FIPS compliance
  • by sending all byes instead of an attacker based raw digest to the component it reduces attacks with known ciphertexts (for RSA)
  • by letting the HSM generate or derive the session key it is never exposed (if this is actually supported?)
  • taking advantage of hardware random number sources for key generation

However there are a few things to that which do not really make sense, so I wonder what best practice is (mostly to define what configurability I should offer):

  • I have not seen a "encrypt random session key with RSA and use it to AES" operation in PKCS#11, so this expected protection does not exist. Or am I missing something?
  • I think for signing the hash can be offloaded, but it looks like most HSM do not allow me to close the 'raw digest' attack and have no way to restrict a signing key to a safe RSA (padding) operation.
  • while HSMs claim hardware enhanced performance especially for the bulk operations most cannot keep up with modern general purpose CPUs (especially if the data has to be transferred over the network interface with secure messaging to the HSM, only co-processors or PCI solutions can be faster). So there is seldomly a speed advantage.

So I wonder, with HSMs, is it common to allow to specify two providers or make it configurable to fall back to local bulk operations? I checked some tools and most of them allow me to configure the crypto engine for the whole application or operation (like "hash+sign"). I hardly ever have seen a config file where I can say "for RSA use X and for SHA use y". I suspect most will fall back to default (local) hash if a non-hashing mechanism is selected? Are people happy with that?

eckes
  • 962
  • 8
  • 19
  • I don't quite understand your last paragraph. What exactly is "my application" and what do you mean by "dual config"? – mat Jul 21 '17 at 11:15
  • My application is a crypto-using application and dual config means I configer the crypto provider seperate for bulk and assymetric ciphers. For example RSA in the HSM but SHA2 in (Java) JCE with AES-NI intrinsics. – eckes Jul 21 '17 at 16:19

1 Answers1

3

I have not seen a "encrypt random session key with RSA and use it to AES" operation in PKCS#11, so this expected protection does not exist. Or am I missing something?

No, there is no such operation in PKCS#11. If you want to do that, you need to construct it from the basic function calls yourself: Generate a symmetric key (on the HSM to use its entropy source), wrap the symetric key with an asymetric key, do the bulk encryption.

I think for signing the hash can be offloaded, but it looks like most HSM do not allow me to close the 'raw digest' attack and have no way to restrict a signing key to a safe RSA (padding) operation.

PKCS#11 devices support a list of mechanisms which specify how the input data is treated. The most common ones are CKM_RSA_PKCS_PSS and CKM_RSA_PKCS for singing and CKM_RSA_PKCS_OAEP or CKM_RSA_PKCS for encryption (plus CKM_RSA_X_509 for raw RSA).

There is no way to restrict a key to a certain mechanism short of disabling a mechanism completely for the token. If you need that, you will have to do it on a lower level and access the device via PC/SC directly (if possible).

while HSMs claim hardware enhanced performance especially for the bulk operations most cannot keep up with modern general purpose CPUs (especially if the data has to be transferred over the network interface with secure messaging to the HSM) – so there is no speed advantage

There is no real answer for that, the term HSM encompasses a very broad range of devices from two digit to five digit € numbers. Small scale crypto tokens or smartcards will definitely be slower when doing AES than a modern CPU but there are definitely devices out there, which are a lot faster (check the "SSL accelerator" category)

schroeder
  • 123,438
  • 55
  • 284
  • 319
mat
  • 1,243
  • 7
  • 14
  • The problem with "construct it yourself" means the session key leaves the HSM, right? Or can I have HSM produce a random key, keep it with a handle and then reference that handle as input for the RSA? It seems to work for Key wrapping. – eckes Jul 21 '17 at 16:22
  • If I understand the PKCS11 api correctly CKM_RSA_PKCS (and CKM_RSA_X_509 and _PSS) expect the (padded) digest value, which means I can/must digest myself (and this opens some attacks as I can hand it chosen integers, right?). The difference would be CKM_SHA256_RSA_PKCS which is safer (but PKCS11 does not allow me to limit a key to those variants?). – eckes Jul 21 '17 at 16:41
  • 1) Well, you want to send the session key anyway, so it leaving the HSM is a must. But if you execute the "wrap" operation, it won't leave it unencrypted which is just what you want. 2) CKM_RSA_PSS does the padding/armoring by itself. Otherwise, it would just be a raw signature 3) CKM_SHA256_RSA_PKCS is just PKCS#1 v1.5 but with SHA-256 instead of SHA-1 – mat Jul 21 '17 at 19:15
  • 1 - yes encrypted. 2 - but not the digest 3) yes but CKM_SHA1_RSA* is different from CKM_RSA* as it does thendigesting and the other only fhe sign part. – eckes Jul 22 '17 at 00:13