Bug 202577 - Cannot read payload of an encrypted key rooted in a trusted key
Summary: Cannot read payload of an encrypted key rooted in a trusted key
Status: NEW
Alias: None
Product: Other
Classification: Unclassified
Component: Other (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: other_other
Depends on:
Reported: 2019-02-14 02:41 UTC by Salah Coronya
Modified: 2019-02-14 02:41 UTC (History)
0 users

See Also:
Kernel Version: 4.14.83
Tree: Mainline
Regression: No


Description Salah Coronya 2019-02-14 02:41:07 UTC
In the file Documentation/security/keys-trusted-encrypted, an example is shown for to create an encrypted key rooted in trusted key. Basically, the following should work:

KMK_KEY=$(keyctl add trusted kmk "new 32" @u)
keyctl pipe $KMK_KEY > ~/kmk-trusted.blob
EVM_KEY=$(keyctl add encrypted evm "new default trusted:kmk 32" @u)
keyctl pipe $EVM_KEY > ~/evm-trusted.blob

But the last command does not work. It reports "keyctl_read_alloc: Operation not supported"

strace shows this:

keyctl(KEYCTL_READ, 404204492, NULL, 0) = 185
keyctl(KEYCTL_READ, 404204492, 0x557a43f66260, 185) = -1 EOPNOTSUPP (Operation not supported) 

I've tried this on kernel 4.4.163, 4.14.83, and 4.20.6, on a machine with real TPM, and a virtual TPM in a VM, both versions 1.2 and 2.0 and none of the cases work. 

"Trusted" keys are encrypted as a module and "Encrypted" keys are compiled into the kernel.

I think i found the problem in /usr/src/linux/security/keys/encrypted-keys/encrypted.h: 

#if defined(CONFIG_TRUSTED_KEYS) || \
extern struct key *request_trusted_key(const char *trusted_desc,
                                       const u8 **master_key, size_t *master_keylen);
static inline struct key *request_trusted_key(const char *trusted_desc,
                                              const u8 **master_key,
                                              size_t *master_keylen)
        return ERR_PTR(-EOPNOTSUPP);

The #if is false if CONFIG_TRUSTED_KEYS_MODULE && CONFIG_ENCRYPTED_KEYS. If I compile both "trusted" and "encrypted" keys in the kernel the problem goes away and it works normally. I have'nt tested both as module but I presume that would work too - basically any combination except the one I have.

Note You need to log in before you can comment on or make changes to this bug.