kernel/include/crypto/public_key.h, branch linux-5.1.y

KEYS: Allow the public_key struct to hold a private key [ver #2]

2018-10-26T08:30:46Z

Put a flag in the public_key struct to indicate if the structure is holding a private key. The private key must be held ASN.1 encoded in the format specified in RFC 3447 A.1.2. This is the form required by crypto/rsa.c. The software encryption subtype's verification and query functions then need to select the appropriate crypto function to set the key. Signed-off-by: David Howells Tested-by: Marcel Holtmann Reviewed-by: Marcel Holtmann Reviewed-by: Denis Kenzior Tested-by: Denis Kenzior Signed-off-by: James Morris

KEYS: Provide missing asymmetric key subops for new key type ops [ver #2]

2018-10-26T08:30:46Z

Provide the missing asymmetric key subops for new key type ops. This include query, encrypt, decrypt and create signature. Verify signature already exists. Also provided are accessor functions for this: int query_asymmetric_key(const struct key *key, struct kernel_pkey_query *info); int encrypt_blob(struct kernel_pkey_params *params, const void *data, void *enc); int decrypt_blob(struct kernel_pkey_params *params, const void *enc, void *data); int create_signature(struct kernel_pkey_params *params, const void *data, void *enc); The public_key_signature struct gains an encoding field to carry the encoding for verify_signature(). Signed-off-by: David Howells Tested-by: Marcel Holtmann Reviewed-by: Marcel Holtmann Reviewed-by: Denis Kenzior Tested-by: Denis Kenzior Signed-off-by: James Morris

KEYS: Keyring asymmetric key restrict method with chaining

2017-04-04T21:10:13Z

Add a restrict_link_by_key_or_keyring_chain link restriction that searches for signing keys in the destination keyring in addition to the signing key or keyring designated when the destination keyring was created. Userspace enables this behavior by including the "chain" option in the keyring restriction: keyctl(KEYCTL_RESTRICT_KEYRING, keyring, "asymmetric", "key_or_keyring::chain"); Signed-off-by: Mat Martineau

KEYS: Restrict asymmetric key linkage using a specific keychain

2017-04-04T21:10:13Z

Adds restrict_link_by_signature_keyring(), which uses the restrict_key member of the provided destination_keyring data structure as the key or keyring to search for signing keys. Signed-off-by: Mat Martineau

KEYS: Split role of the keyring pointer for keyring restrict functions

2017-04-03T17:24:56Z

The first argument to the restrict_link_func_t functions was a keyring pointer. These functions are called by the key subsystem with this argument set to the destination keyring, but restrict_link_by_signature expects a pointer to the relevant trusted keyring. Restrict functions may need something other than a single struct key pointer to allow or reject key linkage, so the data used to make that decision (such as the trust keyring) is moved to a new, fourth argument. The first argument is now always the destination keyring. Signed-off-by: Mat Martineau

KEYS: Move the point of trust determination to __key_link()

2016-04-11T21:43:43Z

Move the point at which a key is determined to be trustworthy to __key_link() so that we use the contents of the keyring being linked in to to determine whether the key being linked in is trusted or not. What is 'trusted' then becomes a matter of what's in the keyring. Currently, the test is done when the key is parsed, but given that at that point we can only sensibly refer to the contents of the system trusted keyring, we can only use that as the basis for working out the trustworthiness of a new key. With this change, a trusted keyring is a set of keys that once the trusted-only flag is set cannot be added to except by verification through one of the contained keys. Further, adding a key into a trusted keyring, whilst it might grant trustworthiness in the context of that keyring, does not automatically grant trustworthiness in the context of a second keyring to which it could be secondarily linked. To accomplish this, the authentication data associated with the key source must now be retained. For an X.509 cert, this means the contents of the AuthorityKeyIdentifier and the signature data. If system keyrings are disabled then restrict_link_by_builtin_trusted() resolves to restrict_link_reject(). The integrity digital signature code still works correctly with this as it was previously using KEY_FLAG_TRUSTED_ONLY, which doesn't permit anything to be added if there is no system keyring against which trust can be determined. Signed-off-by: David Howells

KEYS: Move x509_request_asymmetric_key() to asymmetric_type.c

2016-04-11T21:41:28Z

Move x509_request_asymmetric_key() to asymmetric_type.c so that it can be generalised. Signed-off-by: David Howells

KEYS: Generalise system_verify_data() to provide access to internal content

2016-04-06T15:14:24Z

Generalise system_verify_data() to provide access to internal content through a callback. This allows all the PKCS#7 stuff to be hidden inside this function and removed from the PE file parser and the PKCS#7 test key. If external content is not required, NULL should be passed as data to the function. If the callback is not required, that can be set to NULL. The function is now called verify_pkcs7_signature() to contrast with verify_pefile_signature() and the definitions of both have been moved into linux/verification.h along with the key_being_used_for enum. Signed-off-by: David Howells

KEYS: Add identifier pointers to public_key_signature struct

2016-04-06T15:13:33Z

Add key identifier pointers to public_key_signature struct so that they can be used to retain the identifier of the key to be used to verify the signature in both PKCS#7 and X.509. Signed-off-by: David Howells

KEYS: Allow authentication data to be stored in an asymmetric key

2016-04-06T15:13:33Z

Allow authentication data to be stored in an asymmetric key in the 4th element of the key payload and provide a way for it to be destroyed. For the public key subtype, this will be a public_key_signature struct. Signed-off-by: David Howells