crypto: af_alg - Support symmetric encryption via keyring keys
Subsystems (4)
PATCH 1/1 crypto: af_alg - Support symmetric encryption via keyring keys
We want to leverage keyring to store sensitive keys, and then use those keys for symmetric encryption via the crypto API. Among the key types we wish to support are: user, logon, encrypted, and trusted.
User key types are already able to have their data copied to user space, but logon does not support this. Further, trusted and encrypted keys will return their encrypted data back to user space on read, which does not make them ideal for symmetric encryption.
To support symmetric encryption for these key types, add a new ALG_SET_KEY_BY_KEY_SERIAL setsockopt() option to the crypto API. This allows users to pass a key_serial_t to the crypto API to perform symmetric encryption. The behavior is the same as ALG_SET_KEY, but the crypto key data is copied in kernel space from a keyring key, which allows for the support of logon, encrypted, and trusted key types.
Keyring keys must have the KEY_(POS|USR|GRP|OTH)_SEARCH permission set to leverage this feature. This follows the asymmetric_key type where key lookup calls eventually lead to keyring_search_rcu() without the KEYRING_SEARCH_NO_CHECK_PERM flag set.
---
RFC: https://lore.kernel.org/all/[email protected]/
We have an idea for handling the case of leaking key data with bad algorithms, but asymmetric keys currently have the same problem if any were added as a akcipher type. If KEY_*_SEARCH is not good enough, we thought of possibly implementing a KConfig such that we disable leaky algorithms when selected, or possibly the inverse where if a leaky algorithm is enabled, we don't allow to enable this. The problem there is now there's a list to maintain.
--- Documentation/crypto/userspace-if.rst | 15 ++- crypto/af_alg.c | 135 +++++++++++++++++++++++++- include/uapi/linux/if_alg.h | 1 + 3 files changed, 147 insertions(+), 4 deletions(-)
Documentation/crypto/userspace-if.rst +12 -3
@@ -131,9 +131,9 @@ from the kernel crypto API. If the buffer is too small for the message digest, the flag MSG_TRUNC is set by the kernel. In order to set a message digest key, the calling application must use -the setsockopt() option of ALG_SET_KEY. If the key is not set the HMAC -operation is performed without the initial HMAC state change caused by -the key. +the setsockopt() option of ALG_SET_KEY or ALG_SET_KEY_BY_KEY_SERIAL. If the +key is not set the HMAC operation is performed without the initial HMAC state +change caused by the key. Symmetric Cipher API --------------------
@@ -382,6 +382,15 @@ mentioned optname: - the RNG cipher type to provide the seed +- ALG_SET_KEY_BY_KEY_SERIAL -- Setting the key via keyring key_serial_t. + This operation behaves the same as ALG_SET_KEY. The decrypted + data is copied from a keyring key, and uses that data as the + key for symmetric encryption. + + The passed in key_serial_t must have the KEY_(POS|USR|GRP|OTH)_SEARCH + permission set, otherwise -EPERM is returned. Supports key types: user, + logon, encrypted, and trusted. + - ALG_SET_AEAD_AUTHSIZE -- Setting the authentication tag size for AEAD ciphers. For a encryption operation, the authentication tag of the given size will be generated. For a decryption operation, the
crypto/af_alg.c +134 -1
164 lines not on this page · raw message
include/uapi/linux/if_alg.h +1 -0
@@ -52,6 +52,7 @@ struct af_alg_iv {#define ALG_SET_AEAD_ASSOCLEN 4#define ALG_SET_AEAD_AUTHSIZE 5#define ALG_SET_DRBG_ENTROPY 6 +#define ALG_SET_KEY_BY_KEY_SERIAL 7/* Operations */ #define ALG_OP_DECRYPT 0
Signature · 1 line
2.30.2
Herbert Xu
maintainerQuoted 32 lines · Frederick Lawler
We want to leverage keyring to store sensitive keys, and then use those keys for symmetric encryption via the crypto API. Among the key types we wish to support are: user, logon, encrypted, and trusted.
User key types are already able to have their data copied to user space, but logon does not support this. Further, trusted and encrypted keys will return their encrypted data back to user space on read, which does not make them ideal for symmetric encryption.
To support symmetric encryption for these key types, add a new
ALG_SET_KEY_BY_KEY_SERIALsetsockopt()option to the crypto API. This allows users to pass akey_serial_tto the crypto API to perform symmetric encryption. The behavior is the same asALG_SET_KEY, but the crypto key data is copied in kernel space from a keyring key, which allows for the support of logon, encrypted, and trusted key types.Keyring keys must have the KEY_(POS|USR|GRP|OTH)_SEARCH permission set to leverage this feature. This follows the
asymmetric_keytype where key lookup calls eventually lead tokeyring_search_rcu()without theKEYRING_SEARCH_NO_CHECK_PERMflag set.Signed-off-by Frederick Lawler <[email protected]>---
RFC: https://lore.kernel.org/all/[email protected]/We have an idea for handling the case of leaking key data with bad algorithms, but asymmetric keys currently have the same problem if any were added as a akcipher type. If KEY_*_SEARCH is not good enough, we thought of possibly implementing a KConfig such that we disable leaky algorithms when selected, or possibly the inverse where if a leaky algorithm is enabled, we don't allow to enable this. The problem there is now there's a list to maintain.
Quoted 5 lines
--- Documentation/crypto/userspace-if.rst | 15 ++- crypto/af_alg.c | 135 +++++++++++++++++++++++++- include/uapi/linux/if_alg.h | 1 + 3 files changed, 147 insertions(+), 4 deletions(-)
Patch applied. Thanks.
Signature · 3 lines
Email: Herbert Xu <[email protected]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt