TPM derived keys

In preparation for implementing TPM derived keys we need to use some new TPM functionality in the kernel, so add relevant constant definitions.

Signed-off-by Ignat Korchagin <[email protected]>

---
 include/linux/tpm.h | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

include/linux/tpm.h +0 -0

index 4ee9d13749ad..5be0808b1b91 100644

include/linux/tpm.h +1 -2

+	TPM2_RS_PW    = 0x40000009,
 };
 
 enum tpm2_capabilities {

@@ -312,9 +317,12 @@ struct tpm_buf {
 };
 
 enum tpm2_object_attributes {
-	TPM2_OA_FIXED_TPM		= BIT(1),
-	TPM2_OA_FIXED_PARENT		= BIT(4),

include/linux/tpm.h enum tpm2_command_codes { · line 235

Quoted 8 lines

include/linux/tpm.h +1 -0

@@ -227,6 +229,7 @@ enum tpm2_command_codes {
 	TPM2_CC_CREATE		        = 0x0153,
 	TPM2_CC_LOAD		        = 0x0157,
 	TPM2_CC_SEQUENCE_UPDATE         = 0x015C,
+	TPM2_CC_SIGN		        = 0x015D,
 	TPM2_CC_UNSEAL		        = 0x015E,
 	TPM2_CC_CONTEXT_LOAD	        = 0x0161,
 	TPM2_CC_CONTEXT_SAVE	        = 0x0162,

Ditto.

include/linux/tpm.h enum tpm2_command_codes { · line 243

Quoted 8 lines

include/linux/tpm.h +1 -0

@@ -234,6 +237,7 @@ enum tpm2_command_codes {
 	TPM2_CC_VERIFY_SIGNATURE        = 0x0177,
 	TPM2_CC_GET_CAPABILITY	        = 0x017A,
 	TPM2_CC_GET_RANDOM	        = 0x017B,
+	TPM2_CC_HASH	        	= 0x017D,
 	TPM2_CC_PCR_READ	        = 0x017E,
 	TPM2_CC_PCR_EXTEND	        = 0x0182,
 	TPM2_CC_EVENT_SEQUENCE_COMPLETE = 0x0185,

Ditto.

Derived keys are similar to user keys, but their payload is derived from the primary TPM seed and some metadata of the requesting process. This way every

application can get a unique secret/key, which is cryptographically bound to

the TPM without the need to provide the key material externally (unlike trusted keys). Also, the whole key derivation process is deterministic, so as long as

the TPM is available, applications can always recover their keys, which may allow for easier key management on stateless systems.

In this implementation the following factors will be used as a key derivation factor:
* requested key length
* requesting process effective user id
* either the application executable path or the application integrity metadata (if available)

Key length is used so requests for keys with different sizes result in keys with different cryptographic material.

User id is mixed, so different users get different keys even when executing the

Quoted 2 lines · Ignat Korchagin

Derived keys are similar to user keys, but their payload is derived from the primary TPM seed and some metadata of the requesting process. This way every

What is exactly "some metadata"?

Quoted 1 line

application can get a unique secret/key, which is cryptographically bound to

What is "cryptographically bound". Please go straight to the point and cut out *all* white paper'ish phrases. We do not need it and will make painful to backtrack this commit once in the mainline.

Quoted 2 lines

the TPM without the need to provide the key material externally (unlike trusted keys). Also, the whole key derivation process is deterministic, so as long as

Why trusted keys is inside braces. It is not important for the point you are trying to make here?

Quoted 2 lines

the TPM is available, applications can always recover their keys, which may allow for easier key management on stateless systems.

Please drop "stateless system" unless you provide a rigid definition what it is. I have no idea what you mean by it. Probably not that important, right?

Quoted 7 lines

In this implementation the following factors will be used as a key derivation factor:
* requested key length
* requesting process effective user id
* either the application executable path or the application integrity metadata (if available)

NAK for path for any possible key derivation. They are racy and and ambiguous.

This should have been in the beginning instead of "some data". What other implementations exist. For me "this implementation" implies that this one competing alternative to multiple implementations of the same thing.

I do not like this science/white paper style at all. Just express short, open code everything right at start when you need and cut extras like "stateless system" unless you can provide exact, sound and unambiguous definiton of it.

Just want to underline how this really needs a complete rewrite with clear and concise explanation :-) This won't ever work.

Quoted 3 lines

Key length is used so requests for keys with different sizes result in keys with different cryptographic material.

What is "key length"? Please refer the exact attribute.

Quoted 2 lines

User id is mixed, so different users get different keys even when executing the

First of all it would be more clear to just s/User id/UID/

And make obvious whether we are talking about ruid or euid and how this interacts with GIDs.

I'll look at the code change next round if the commit message starts making any sense.

Quoted 11 lines

What is "key length"? Please refer the exact attribute.

Quoted 2 lines

User id is mixed, so different users get different keys even when executing the

First of all it would be more clear to just s/User id/UID/

And make obvious whether we are talking about ruid or euid and how this interacts with GIDs.

Quoted 2 lines

I'll look at the code change next round if the commit message starts making any sense.

Right and neither UIDs and GIDs are applicable for key derivation for quite obvious reasons. So NAK for that too.

You can make them point out unlimited different identities...

Quoted 60 lines · Jarkko Sakkinen

Quoted 2 lines · Ignat Korchagin

Derived keys are similar to user keys, but their payload is derived from the primary TPM seed and some metadata of the requesting process. This way every

What is exactly "some metadata"?

Quoted 1 line

application can get a unique secret/key, which is cryptographically bound to

What is "cryptographically bound". Please go straight to the point and cut out *all* white paper'ish phrases. We do not need it and will make painful to backtrack this commit once in the mainline.

Quoted 2 lines

the TPM without the need to provide the key material externally (unlike trusted keys). Also, the whole key derivation process is deterministic, so as long as

Why trusted keys is inside braces. It is not important for the point you are trying to make here?

Quoted 2 lines

the TPM is available, applications can always recover their keys, which may allow for easier key management on stateless systems.

Please drop "stateless system" unless you provide a rigid definition what it is. I have no idea what you mean by it. Probably not that important, right?

Quoted 7 lines

In this implementation the following factors will be used as a key derivation factor:
* requested key length
* requesting process effective user id
* either the application executable path or the application integrity metadata (if available)

NAK for path for any possible key derivation. They are racy and and ambiguous.

This should have been in the beginning instead of "some data". What other implementations exist. For me "this implementation" implies that this one competing alternative to multiple implementations of the same thing.

I do not like this science/white paper style at all. Just express short, open code everything right at start when you need and cut extras like "stateless system" unless you can provide exact, sound and unambiguous definiton of it.

Just want to underline how this really needs a complete rewrite with clear and concise explanation :-) This won't ever work.

Quoted 3 lines

Key length is used so requests for keys with different sizes result in keys with different cryptographic material.

What is "key length"? Please refer the exact attribute.

Quoted 2 lines

User id is mixed, so different users get different keys even when executing the

First of all it would be more clear to just s/User id/UID/

Quoted 5 lines

And make obvious whether we are talking about ruid or euid and how this interacts with GIDs.

I'll look at the code change next round if the commit message starts making any sense.

Right and neither UIDs and GIDs are applicable for key derivation for quite obvious reasons. So NAK for that too.

You can make them point out unlimited different identities...

BR, Jarkko

Quoted 62 lines · Jarkko Sakkinen

Quoted 60 lines · Jarkko Sakkinen

Quoted 2 lines · Ignat Korchagin

Derived keys are similar to user keys, but their payload is derived from the primary TPM seed and some metadata of the requesting process. This way every

What is exactly "some metadata"?

Quoted 1 line

application can get a unique secret/key, which is cryptographically bound to

What is "cryptographically bound". Please go straight to the point and cut out *all* white paper'ish phrases. We do not need it and will make painful to backtrack this commit once in the mainline.

Quoted 2 lines

the TPM without the need to provide the key material externally (unlike trusted keys). Also, the whole key derivation process is deterministic, so as long as

Why trusted keys is inside braces. It is not important for the point you are trying to make here?

Quoted 2 lines

the TPM is available, applications can always recover their keys, which may allow for easier key management on stateless systems.

Please drop "stateless system" unless you provide a rigid definition what it is. I have no idea what you mean by it. Probably not that important, right?

Quoted 7 lines

In this implementation the following factors will be used as a key derivation factor:
* requested key length
* requesting process effective user id
* either the application executable path or the application integrity metadata (if available)

NAK for path for any possible key derivation. They are racy and and ambiguous.

This should have been in the beginning instead of "some data". What other implementations exist. For me "this implementation" implies that this one competing alternative to multiple implementations of the same thing.

I do not like this science/white paper style at all. Just express short, open code everything right at start when you need and cut extras like "stateless system" unless you can provide exact, sound and unambiguous definiton of it.

Just want to underline how this really needs a complete rewrite with clear and concise explanation :-) This won't ever work.

Quoted 3 lines

Key length is used so requests for keys with different sizes result in keys with different cryptographic material.

What is "key length"? Please refer the exact attribute.

Quoted 2 lines

User id is mixed, so different users get different keys even when executing the

First of all it would be more clear to just s/User id/UID/

Quoted 8 lines

Quoted 5 lines

And make obvious whether we are talking about ruid or euid and how this interacts with GIDs.

I'll look at the code change next round if the commit message starts making any sense.

Right and neither UIDs and GIDs are applicable for key derivation for quite obvious reasons. So NAK for that too.

Can you, please, clarify a bit here? Not very obvious for me. I added euid for two reasons:
* an unprivileged user might run a normally privileged application,
for example /usr/sbin/sshd, and depending on the code could "leak" the key
* without it and with unprivileged user namespaces it is possible to
create an unprivileged container with code at the same path as a privileged application

Why do you think UIDs/GIDs are not applicable as mixins?

I did as much clarification as I possibly can.

Also, if you look at confidential computing platforms there's exactly two assets that they use lock into machine:

- Binary
- CPU material

Only carved into stone immutable material for key derivation.

You can use mm_struct->exe_file binary if that will work out for you. I'm done with this version.

Quoted 2 lines · Ignat Korchagin

Derived keys are similar to user keys, but their payload is derived from the primary TPM seed and some metadata of the requesting process. This way every

What is exactly "some metadata"?

Quoted 1 line

application can get a unique secret/key, which is cryptographically bound to

What is "cryptographically bound". Please go straight to the point and cut out *all* white paper'ish phrases. We do not need it and will make painful to backtrack this commit once in the mainline.

Quoted 2 lines

the TPM without the need to provide the key material externally (unlike trusted keys). Also, the whole key derivation process is deterministic, so as long as

Why trusted keys is inside braces. It is not important for the point you are trying to make here?

Quoted 2 lines

the TPM is available, applications can always recover their keys, which may allow for easier key management on stateless systems.

Please drop "stateless system" unless you provide a rigid definition what it is. I have no idea what you mean by it. Probably not that important, right?

Quoted 7 lines

In this implementation the following factors will be used as a key derivation factor:
* requested key length
* requesting process effective user id
* either the application executable path or the application integrity metadata (if available)

NAK for path for any possible key derivation. They are racy and and ambiguous.

This should have been in the beginning instead of "some data". What other implementations exist. For me "this implementation" implies that this one competing alternative to multiple implementations of the same thing.

I do not like this science/white paper style at all. Just express short, open code everything right at start when you need and cut extras like "stateless system" unless you can provide exact, sound and unambiguous definiton of it.

Just want to underline how this really needs a complete rewrite with clear and concise explanation :-) This won't ever work.

Quoted 3 lines

Key length is used so requests for keys with different sizes result in keys with different cryptographic material.

What is "key length"? Please refer the exact attribute.

Quoted 2 lines

User id is mixed, so different users get different keys even when executing the

First of all it would be more clear to just s/User id/UID/

And make obvious whether we are talking about ruid or euid and how this interacts with GIDs.

I'll look at the code change next round if the commit message starts making any sense.

BR, Jarkko

TPM derived keys get their payload from an HMAC primary key in the owner hierarchy mixed with some metadata from the requesting process.

They are similar to trusted keys in the sense that the key security is rooted in the TPM, but may provide easier key management for some use-cases.

One inconvenience with trusted keys is that the cryptographic material should be provided externally. This means either wrapping the key to the TPM on the executing system (which briefly exposes plaintext cryptographic material to userspace) or creating the wrapped blob externally, but then we need to gather and transfer the TPM public key to the remote system, which may be a logistical problem sometimes.

Moreover, we need to store the wrapped key blob somewhere, and if we lose it, the application cannot recover its data anymore.

TPM derived keys may make key management for applications easier, especially on stateless systems as the application can always recreate its keys and the encrypted data is bound to the device and its TPM. They allow the application to wrap/unwrap some data to the device without worrying too much about key management and provisioning. They are similar in a sense to device unique keys present on many mobile devices and some IoT systems, but even better as every application has its own unique device key.

It is also easy to quickly "wipe" all the application keys by just resetting the TPM owner hierarchy.

It is worth mentioning that this functionality can be implemented in userspace as a /sbin/request-key plugin. However, the advantage of the in-kernel implementation is that the derived key material never leaves the kernel space (unless explicitly read into userspace with proper permissions).

I have no idea for what the key created with this is even used, which makes this impossible to review.

Quoted 2 lines · Jarkko Sakkinen

I have no idea for what the key created with this is even used, which makes this impossible to review.

Additionally, there is nothing in Documentation/ for how userspace might use or create them. This includes things like their description format and describing available options.

Quoted 7 lines · Ben Boeckel

Quoted 2 lines · Jarkko Sakkinen

I have no idea for what the key created with this is even used, which makes this impossible to review.

Additionally, there is nothing in Documentation/ for how userspace might use or create them. This includes things like their description format and describing available options.

The whole user story is plain out broken. Documenting a feature that has no provable use case won't fix that part.

So it is better to start with the cover letter. With the *existing* knowledge of the *real* issue I don't think we need this tbh.

Quoted 9 lines · Jarkko Sakkinen

Quoted 7 lines · Ben Boeckel

Quoted 2 lines · Jarkko Sakkinen

I have no idea for what the key created with this is even used, which makes this impossible to review.

Additionally, there is nothing in Documentation/ for how userspace might use or create them. This includes things like their description format and describing available options.

Quoted 5 lines

The whole user story is plain out broken. Documenting a feature that has no provable use case won't fix that part.

So it is better to start with the cover letter. With the *existing* knowledge of the *real* issue I don't think we need this tbh.

As for code I'd suggest the "Describe your changes" part from

https://www.kernel.org/doc/html/latest/process/submitting-patches.html

and most essentially how to split them properly.

My best bet could something along the lines that perhaps there is some issue to be sorted out but I don't honestly believe that this will ever be a solution for any possible problem that exist in this planet.

BR, Jarkko

TPM derived keys attempt to address the above use cases by allowing applications to deterministically derive unique cryptographic keys for their own purposes directly from the TPM seed in the owner hierarchy. The idea is that when an application requests a new key, instead of generating a random key and wrapping it with the TPM, the implementation generates a key via KDF(hierarchy seed, application specific info). Therefore, the resulting keys will always be cryptographically bound to the application itself and the device they were generated on.

On Mon, 2024-05-13 at 18:09 +0100, Ignat Korchagin wrote:
[...]

Quoted 9 lines

TPM derived keys attempt to address the above use cases by allowing applications to deterministically derive unique cryptographic keys for their own purposes directly from the TPM seed in the owner hierarchy. The idea is that when an application requests a new key, instead of generating a random key and wrapping it with the TPM, the implementation generates a key via KDF(hierarchy seed, application specific info). Therefore, the resulting keys will always be cryptographically bound to the application itself and the device they were generated on.

So I think what confuses me is what the expected cryptographic secrecy properties of the derived keys are. I get they're a KDF of seed and deterministic properties, but if those mixing values are well known (as the path or binary checksum cases) then anyone with access to the TPM can derive the key from user space because they can easily obtain the mixing parameters and there's no protection to the TPM keyed hash operation.

Consider the use case where two users are using derived keys on the same system (so same TPM). Assuming they use them to protect sensitive information, what prevents user1 from simply deriving user2's key and getting the information, or am I missing the point of this?

James

Quoted 21 lines · James Bottomley

On Mon, 2024-05-13 at 18:09 +0100, Ignat Korchagin wrote:
[...]

Quoted 9 lines

TPM derived keys attempt to address the above use cases by allowing applications to deterministically derive unique cryptographic keys for their own purposes directly from the TPM seed in the owner hierarchy. The idea is that when an application requests a new key, instead of generating a random key and wrapping it with the TPM, the implementation generates a key via KDF(hierarchy seed, application specific info). Therefore, the resulting keys will always be cryptographically bound to the application itself and the device they were generated on.

So I think what confuses me is what the expected cryptographic secrecy properties of the derived keys are.  I get they're a KDF of seed and deterministic properties, but if those mixing values are well known (as the path or binary checksum cases) then anyone with access to the TPM can derive the key from user space because they can easily obtain the mixing parameters and there's no protection to the TPM keyed hash operation.

Quoted 5 lines

Consider the use case where two users are using derived keys on the same system (so same TPM).  Assuming they use them to protect sensitive information, what prevents user1 from simply deriving user2's key and getting the information, or am I missing the point of this?

You are correct: it is possible, but in practice it would be limited only to privileged users/applications. I remember there was a push to set a 666 mask for the TPM device file, but it is not how it is done today by default.

Also I think the same applies to trusted keys as well, at least
without any additional authorizations or PCR restrictions on the blob (I remember I could manually unwrap a trusted key blob in userspace as root).

It would be fixed if we could limit access to some TPM ops only from the kernel, but I remember from one of your presentations that it is generally a hard problem and that some solution was in the works (was it based on limiting access to a resettable PCR?). I'm happy to consider adopting it here as well somehow.

Quoted 29 lines · Ignat Korchagin

Quoted 21 lines · James Bottomley

On Mon, 2024-05-13 at 18:09 +0100, Ignat Korchagin wrote:
[...]

Quoted 9 lines

TPM derived keys attempt to address the above use cases by allowing applications to deterministically derive unique cryptographic keys for their own purposes directly from the TPM seed in the owner hierarchy. The idea is that when an application requests a new key, instead of generating a random key and wrapping it with the TPM, the implementation generates a key via KDF(hierarchy seed, application specific info). Therefore, the resulting keys will always be cryptographically bound to the application itself and the device they were generated on.

So I think what confuses me is what the expected cryptographic secrecy properties of the derived keys are. I get they're a KDF of seed and deterministic properties, but if those mixing values are well known (as the path or binary checksum cases) then anyone with access to the TPM can derive the key from user space because they can easily obtain the mixing parameters and there's no protection to the TPM keyed hash operation.

Quoted 5 lines

Consider the use case where two users are using derived keys on the same system (so same TPM). Assuming they use them to protect sensitive information, what prevents user1 from simply deriving user2's key and getting the information, or am I missing the point of this?

Quoted 4 lines

You are correct: it is possible, but in practice it would be limited only to privileged users/applications. I remember there was a push to set a 666 mask for the TPM device file, but it is not how it is done today by default.

No, it's 660, but in consequence of that every user of the TPM is a member of the tpm group which, since TPM use from userspace is growing, is everyone, so it might as well have been 666. In other words relying on access restrictions to the TPM itself is largely useless.

Quoted 4 lines

Also I think the same applies to trusted keys as well, at least
without any additional authorizations or PCR restrictions on the blob (I remember I could manually unwrap a trusted key blob in userspace as root).

Well, that's correct, but a TPM key file without policy still has two
protections: the file itself (so the key owner can choose what permissions and where it is) and the key authority (or password) although for the mechanical (unsupervised insertion) use case keys tend not to have an authority.

Quoted 5 lines

It would be fixed if we could limit access to some TPM ops only from the kernel, but I remember from one of your presentations that it is generally a hard problem and that some solution was in the works (was it based on limiting access to a resettable PCR?). I'm happy to consider adopting it here as well somehow.

Well, that was based on constructing a policy that meant only the kernel could access the data (so it requires PCR policy).

In addition to the expected secrecy property question which I don't think is fully answered I did think of another issue: what if the application needs to rotate keys because of a suspected compromise? For sealed keys, we just generate a new one an use that in place of the old, but for your derived keys we'd have to change one of the mixing values, which all look to be based on fairly permanent properties of the system.

James

TPM derived keys get their payload from an HMAC primary key in the owner hierarchy mixed with some metadata from the requesting process.

They are similar to trusted keys in the sense that the key security is rooted in the TPM, but may provide easier key management for some use-cases.

One inconvenience with trusted keys is that the cryptographic material should be provided externally. This means either wrapping the key to the TPM on the

executing system (which briefly exposes plaintext cryptographic material to userspace) or creating the wrapped blob externally, but then we need to gather and transfer the TPM public key to the remote system, which may be a logistical problem sometimes.

Moreover, we need to store the wrapped key blob somewhere, and if we lose it, the application cannot recover its data anymore.

TPM derived keys may make key management for applications easier, especially on stateless systems as the application can always recreate its keys and the encrypted data is bound to the device and its TPM. They allow the application to wrap/unwrap some data to the device without worrying too much about key management and provisioning. They are similar in a sense to device unique keys present on many mobile devices and some IoT systems, but even better as every application has its own unique device key.

It is also easy to quickly "wipe" all the application keys by just resetting the TPM owner hierarchy.

It is worth mentioning that this functionality can be implemented in userspace as a /sbin/request-key plugin. However, the advantage of the in-kernel implementation is that the derived key material never leaves the kernel space (unless explicitly read into userspace with proper permissions).

Current implementation supports two modes (as demonstrated by the keyctl userspace tool):
1. keyctl add derived test '32 path' - will derive a 32 byte key based on the TPM seed and the filesystem path of the requesting application. That is /usr/bin/keyctl and /opt/bin/keyctl would generate different keys.

2. keyctl add derived test '32 csum' - will derive a 32 byte key based on the TPM seed and the IMA measurement of the requesting application. That is /usr/bin/keyctl and /opt/bin/keyctl would generate the same key IFF their code exactly matches bit for bit. The implementation does not measure the requesting binary itself, but rather relies on already available measurement. This means for this mode to work IMA needs to be enabled and configured for requesting applications. For example:
# echo 'audit func=BPRM_CHECK' > \
/sys/kernel/security/integrity/ima/policy

Open questions (apart from the obvious "is this useful?"):
* should any other modes/derivation parameters be considered?
* apparently in checksum mode, when calling keyring syscalls from scripts, we mix in the measurement of the interpreter, not the script itself. Is there any way to improve this?

Ignat Korchagin (2):
tpm: add some algorithm and constant definitions from the TPM spec
KEYS: implement derived keys

 include/linux/tpm.h                     |  16 +-
 security/keys/Kconfig                   |  16 ++
 security/keys/Makefile                  |   1 +
 security/keys/derived-keys/Makefile     |   8 +
 security/keys/derived-keys/derived.c    | 226 +++++++++++++++++++++
 security/keys/derived-keys/derived.h    |   4 +
 security/keys/derived-keys/tpm2_shash.c | 257 ++++++++++++++++++++++++
 7 files changed, 524 insertions(+), 4 deletions(-)
 create mode 100644 security/keys/derived-keys/Makefile
 create mode 100644 security/keys/derived-keys/derived.c
 create mode 100644 security/keys/derived-keys/derived.h
 create mode 100644 security/keys/derived-keys/tpm2_shash.c

--
2.39.2

On Fri, May 3, 2024 at 11:16 PM Ignat Korchagin <[email protected]> wrote:
I would like to point out to myself I was wrong: it is possible to ask the kernel to generate a trusted key inside the kernel locally with "keyctl add trusted kmk "new 32" @u"

Quoted 4 lines · Ignat Korchagin

On Fri, May 3, 2024 at 11:16 PM Ignat Korchagin <[email protected]> wrote:
I would like to point out to myself I was wrong: it is possible to ask the kernel to generate a trusted key inside the kernel locally with "keyctl add trusted kmk "new 32" @u"

Not in a full-time kernel position ATM as I'm working as contract researcher up until beginning of Oct (took some industry break after a startup went down of business), so please, politely asking, write a bit more compact descriptions ;-) I'm trying to find a new position by the beginning of Oct but right now I'd appreciate a bit more thought out text descriptions.

I'm working out a small patch set with James Prestwood to add asymmetric TPM2 keys based on his old patch set [1] but laid out on top of the existing baseline.

I did already the key type shenanigans etc. for it and James P is laying his pre-existing RSA code and new ECDSA on top of that. So this will

give x.509 compatibility [2]. This patch set will be out soon and likely part of 6.11 (or almost guaranteed as most of it is done).

So by plain guess this might be along the lines what you might want?

[1] https://lore.kernel.org/all/[email protected]/
[2] https://datatracker.ietf.org/doc/draft-woodhouse-cert-best-practice/

BR, Jarkko

Quoted 18 lines · Jarkko Sakkinen

Quoted 4 lines · Ignat Korchagin

On Fri, May 3, 2024 at 11:16 PM Ignat Korchagin <[email protected]> wrote:
I would like to point out to myself I was wrong: it is possible to ask the kernel to generate a trusted key inside the kernel locally with "keyctl add trusted kmk "new 32" @u"

Not in a full-time kernel position ATM as I'm working as contract researcher up until beginning of Oct (took some industry break after a startup went down of business), so please, politely asking, write a bit more compact descriptions ;-) I'm trying to find a new position by the beginning of Oct but right now I'd appreciate a bit more thought out text descriptions.

I'm working out a small patch set with James Prestwood to add asymmetric TPM2 keys based on his old patch set [1] but laid out on top of the existing baseline.

Quoted 2 lines

I did already the key type shenanigans etc. for it and James P is laying his pre-existing RSA code and new ECDSA on top of that. So this will

This is great. Perhaps we can finally have ECDSA software signature support as well, which I have been trying to get in for some time now
[1]

Quoted 4 lines

give x.509 compatibility [2]. This patch set will be out soon and likely part of 6.11 (or almost guaranteed as most of it is done).

Quoted 1 line

So by plain guess this might be along the lines what you might want?

I don't think so. I have seen this patchset, but unless the new version is fundamentally different, it looks to me that the asymmetric TPM keys are the same as trusted keys except they are asymmetric instead of being symmetric. That is, they are still of limited use on stateless systems and are subject to the same restrictions I described in my revised cover description.

On top of that I'm not sure they would be widely used as "leaf" keys by applications, maybe more as root/intermediate keys in some kind of key hierarchy. TPMs are slow and I don't see a high-performance web-server, for example, using asymmetric TPM keys for TLS operations. Also, as we learned the hard way operating many TPMs in production, some TPMs are quite unreliable and fail really fast, if you "spam" them with a lot of crypto ops. I understand this is a HW/TPM vendor problem, but in practice we're trying to build systems, where TPM is used to protect/generate other keys, but most of the "leaf" crypto operations are done in software, so we don't make the TPM do too much crypto.

Just to clarify - I'm not arguing about the usefulness of TPM asymmetric keys in the kernel. I would really want to see this building block available as well, but I think it just serves a different purpose/use case from what I'm trying to figure out in this RFC thread.

Quoted 19 lines · Ignat Korchagin

Quoted 18 lines · Jarkko Sakkinen

Quoted 4 lines · Ignat Korchagin

On Fri, May 3, 2024 at 11:16 PM Ignat Korchagin <[email protected]> wrote:
I would like to point out to myself I was wrong: it is possible to ask the kernel to generate a trusted key inside the kernel locally with "keyctl add trusted kmk "new 32" @u"

Not in a full-time kernel position ATM as I'm working as contract researcher up until beginning of Oct (took some industry break after a startup went down of business), so please, politely asking, write a bit more compact descriptions ;-) I'm trying to find a new position by the beginning of Oct but right now I'd appreciate a bit more thought out text descriptions.

I'm working out a small patch set with James Prestwood to add asymmetric TPM2 keys based on his old patch set [1] but laid out on top of the existing baseline.

Quoted 6 lines

Quoted 2 lines

I did already the key type shenanigans etc. for it and James P is laying his pre-existing RSA code and new ECDSA on top of that. So this will

This is great. Perhaps we can finally have ECDSA software signature support as well, which I have been trying to get in for some time now
[1]

Yes exactly both.

Quoted 4 lines

Quoted 4 lines

give x.509 compatibility [2]. This patch set will be out soon and likely part of 6.11 (or almost guaranteed as most of it is done).

Quoted 8 lines

Quoted 1 line

So by plain guess this might be along the lines what you might want?

I don't think so. I have seen this patchset, but unless the new version is fundamentally different, it looks to me that the asymmetric TPM keys are the same as trusted keys except they are asymmetric instead of being symmetric. That is, they are still of limited use on stateless systems and are subject to the same restrictions I described in my revised cover description.

OK, hmm... can you an "apples and oranges" example what would be most trivial use case where these don't cut?

Quoted 12 lines

On top of that I'm not sure they would be widely used as "leaf" keys by applications, maybe more as root/intermediate keys in some kind of key hierarchy. TPMs are slow and I don't see a high-performance web-server, for example, using asymmetric TPM keys for TLS operations. Also, as we learned the hard way operating many TPMs in production, some TPMs are quite unreliable and fail really fast, if you "spam" them with a lot of crypto ops. I understand this is a HW/TPM vendor problem, but in practice we're trying to build systems, where TPM is used to protect/generate other keys, but most of the "leaf" crypto operations are done in software, so we don't make the TPM do too much crypto.

So what about SGX/SNP/TDX?

TPM is definitely not made for workloads :-)

Quoted 5 lines

Just to clarify - I'm not arguing about the usefulness of TPM asymmetric keys in the kernel. I would really want to see this building block available as well, but I think it just serves a different purpose/use case from what I'm trying to figure out in this RFC thread.

Got it :-) NP

BR, Jarkko

For example, a cheap NAS box with no internal storage (disks connected externally via USB). We want:
* disks to be encrypted and decryptable only by this NAS box

* if someone steals one of the disks - we don't want them to see it
has encrypted data (no LUKS header)

Additionally we may want to SSH into the NAS for configuration and we don't want the SSH server key to change after each boot (regardless if disks are connected or not).

Quoted 3 lines · Ignat Korchagin

For example, a cheap NAS box with no internal storage (disks connected externally via USB). We want:
* disks to be encrypted and decryptable only by this NAS box

So how this differs from LUKS2 style, which also systemd supports where the encryption key is anchored to PCR's? If I took hard drive out of my Linux box, I could not decrypt it in another machine because of this.

Quoted 8 lines · Jarkko Sakkinen

Quoted 3 lines · Ignat Korchagin

For example, a cheap NAS box with no internal storage (disks connected externally via USB). We want:
* disks to be encrypted and decryptable only by this NAS box

So how this differs from LUKS2 style, which also systemd supports where the encryption key is anchored to PCR's? If I took hard drive out of my Linux box, I could not decrypt it in another machine because of this.

Maybe you could replace the real LUKS2 header with a dummy LUKS2 header, which would need to be able the describe "do not use this" and e.g. SHA256 of the actual header. And then treat the looked up header as the header when the drive is mounted.

LUKS2 would also need to be able to have pre-defined (e.g. kernel command-line or bootconfig) small internal storage, which would be also encrypted with TPM's PRCs containing an array of LUKS2 header and then look up that with SHA256 as the key.

Without knowing LUKS2 implementation to me these do not sound reaching the impossible engineer problems so maybe this would be worth of investigating...

Quoted 15 lines · Jarkko Sakkinen

Quoted 8 lines · Jarkko Sakkinen

Quoted 3 lines · Ignat Korchagin

For example, a cheap NAS box with no internal storage (disks connected externally via USB). We want:
* disks to be encrypted and decryptable only by this NAS box

So how this differs from LUKS2 style, which also systemd supports where the encryption key is anchored to PCR's? If I took hard drive out of my Linux box, I could not decrypt it in another machine because of this.

Maybe you could replace the real LUKS2 header with a dummy LUKS2 header, which would need to be able the describe "do not use this" and e.g. SHA256 of the actual header. And then treat the looked up header as the header when the drive is mounted.

Quoted 8 lines

LUKS2 would also need to be able to have pre-defined (e.g. kernel command-line or bootconfig) small internal storage, which would be also encrypted with TPM's PRCs containing an array of LUKS2 header and then look up that with SHA256 as the key.

Without knowing LUKS2 implementation to me these do not sound reaching the impossible engineer problems so maybe this would be worth of investigating...

Or why you could not just encrypt the whole header with another key that is only in that device? Then it would appear as random full length.

I.e. unsealing

1. Decrypt LUKS2 header with TPM2 key
2. Use the new resulting header as it was in the place of encrypted stored to the external drive.
3. Decrypt key from the LUK2S header etc.

Quoted 29 lines · Jarkko Sakkinen

Quoted 15 lines · Jarkko Sakkinen

Quoted 8 lines · Jarkko Sakkinen

Quoted 3 lines · Ignat Korchagin

For example, a cheap NAS box with no internal storage (disks connected externally via USB). We want:
* disks to be encrypted and decryptable only by this NAS box

So how this differs from LUKS2 style, which also systemd supports where the encryption key is anchored to PCR's? If I took hard drive out of my Linux box, I could not decrypt it in another machine because of this.

Maybe you could replace the real LUKS2 header with a dummy LUKS2 header, which would need to be able the describe "do not use this" and e.g. SHA256 of the actual header. And then treat the looked up header as the header when the drive is mounted.

Quoted 8 lines

LUKS2 would also need to be able to have pre-defined (e.g. kernel command-line or bootconfig) small internal storage, which would be also encrypted with TPM's PRCs containing an array of LUKS2 header and then look up that with SHA256 as the key.

Without knowing LUKS2 implementation to me these do not sound reaching the impossible engineer problems so maybe this would be worth of investigating...

Or why you could not just encrypt the whole header with another key that is only in that device? Then it would appear as random full length.

Quoted 6 lines

I.e. unsealing

1. Decrypt LUKS2 header with TPM2 key
2. Use the new resulting header as it was in the place of encrypted stored to the external drive.
3. Decrypt key from the LUK2S header etc.

Maybe something like:

1. Asymmetric for LUKS2 (just like it is)
2. Additional symmetric key, which is created as non-migratable and stored to the TPM2 chip. This deciphers the header, i.e. takes the random away.

BR, Jarkko

Quoted 38 lines · Jarkko Sakkinen

Quoted 29 lines · Jarkko Sakkinen

Quoted 15 lines · Jarkko Sakkinen

Quoted 8 lines · Jarkko Sakkinen

Quoted 3 lines · Ignat Korchagin

For example, a cheap NAS box with no internal storage (disks connected externally via USB). We want:
* disks to be encrypted and decryptable only by this NAS box

So how this differs from LUKS2 style, which also systemd supports where the encryption key is anchored to PCR's? If I took hard drive out of my Linux box, I could not decrypt it in another machine because of this.

Maybe you could replace the real LUKS2 header with a dummy LUKS2 header, which would need to be able the describe "do not use this" and e.g. SHA256 of the actual header. And then treat the looked up header as the header when the drive is mounted.

Quoted 8 lines

LUKS2 would also need to be able to have pre-defined (e.g. kernel command-line or bootconfig) small internal storage, which would be also encrypted with TPM's PRCs containing an array of LUKS2 header and then look up that with SHA256 as the key.

Without knowing LUKS2 implementation to me these do not sound reaching the impossible engineer problems so maybe this would be worth of investigating...

Or why you could not just encrypt the whole header with another key that is only in that device? Then it would appear as random full length.

Quoted 6 lines

I.e. unsealing

1. Decrypt LUKS2 header with TPM2 key
2. Use the new resulting header as it was in the place of encrypted stored to the external drive.
3. Decrypt key from the LUK2S header etc.

Quoted 6 lines

Maybe something like:

1. Asymmetric for LUKS2 (just like it is)
2. Additional symmetric key, which is created as non-migratable and stored to the TPM2 chip. This deciphers the header, i.e. takes the random away.

This could work, but you still have the problem of - if the header gets wiped, all the data is lost.
As for storing things on the TPM chip - that doesn't scale. Today you only think about disk encryption, tomorrow there is a new application, which wants to do the same thing and so on. One of the features of derived keys - you don't store anything, just recreate/derive when needed and it scales infinitely.

Quoted 46 lines · Ignat Korchagin

Quoted 38 lines · Jarkko Sakkinen

Quoted 29 lines · Jarkko Sakkinen

Quoted 15 lines · Jarkko Sakkinen

Quoted 8 lines · Jarkko Sakkinen

Quoted 3 lines · Ignat Korchagin

For example, a cheap NAS box with no internal storage (disks connected externally via USB). We want:
* disks to be encrypted and decryptable only by this NAS box

So how this differs from LUKS2 style, which also systemd supports where the encryption key is anchored to PCR's? If I took hard drive out of my Linux box, I could not decrypt it in another machine because of this.

Maybe you could replace the real LUKS2 header with a dummy LUKS2 header, which would need to be able the describe "do not use this" and e.g. SHA256 of the actual header. And then treat the looked up header as the header when the drive is mounted.

Quoted 8 lines

LUKS2 would also need to be able to have pre-defined (e.g. kernel command-line or bootconfig) small internal storage, which would be also encrypted with TPM's PRCs containing an array of LUKS2 header and then look up that with SHA256 as the key.

Without knowing LUKS2 implementation to me these do not sound reaching the impossible engineer problems so maybe this would be worth of investigating...

Or why you could not just encrypt the whole header with another key that is only in that device? Then it would appear as random full length.

Quoted 6 lines

I.e. unsealing

1. Decrypt LUKS2 header with TPM2 key
2. Use the new resulting header as it was in the place of encrypted stored to the external drive.
3. Decrypt key from the LUK2S header etc.

Quoted 6 lines

Maybe something like:

1. Asymmetric for LUKS2 (just like it is)
2. Additional symmetric key, which is created as non-migratable and stored to the TPM2 chip. This deciphers the header, i.e. takes the random away.

Quoted 7 lines

This could work, but you still have the problem of - if the header gets wiped, all the data is lost.
As for storing things on the TPM chip - that doesn't scale. Today you only think about disk encryption, tomorrow there is a new application, which wants to do the same thing and so on. One of the features of derived keys - you don't store anything, just recreate/derive when needed and it scales infinitely.

OK, so now I know the problem at least and that is probably the most important thing in this discussion, right?

So make a better story, now you also probably have better idea, also split the patch properly by subsystem, send the patch set,

and I'll promise to revisit.

Fair enough? :-)

BR, Jarkko

Quoted 56 lines · Jarkko Sakkinen

Quoted 46 lines · Ignat Korchagin

Quoted 38 lines · Jarkko Sakkinen

Quoted 29 lines · Jarkko Sakkinen

Quoted 15 lines · Jarkko Sakkinen

Quoted 8 lines · Jarkko Sakkinen

Quoted 3 lines · Ignat Korchagin

For example, a cheap NAS box with no internal storage (disks connected externally via USB). We want:
* disks to be encrypted and decryptable only by this NAS box

So how this differs from LUKS2 style, which also systemd supports where the encryption key is anchored to PCR's? If I took hard drive out of my Linux box, I could not decrypt it in another machine because of this.

Maybe you could replace the real LUKS2 header with a dummy LUKS2 header, which would need to be able the describe "do not use this" and e.g. SHA256 of the actual header. And then treat the looked up header as the header when the drive is mounted.

Quoted 8 lines

LUKS2 would also need to be able to have pre-defined (e.g. kernel command-line or bootconfig) small internal storage, which would be also encrypted with TPM's PRCs containing an array of LUKS2 header and then look up that with SHA256 as the key.

Without knowing LUKS2 implementation to me these do not sound reaching the impossible engineer problems so maybe this would be worth of investigating...

Or why you could not just encrypt the whole header with another key that is only in that device? Then it would appear as random full length.

Quoted 6 lines

I.e. unsealing

1. Decrypt LUKS2 header with TPM2 key
2. Use the new resulting header as it was in the place of encrypted stored to the external drive.
3. Decrypt key from the LUK2S header etc.

Quoted 6 lines

Maybe something like:

1. Asymmetric for LUKS2 (just like it is)
2. Additional symmetric key, which is created as non-migratable and stored to the TPM2 chip. This deciphers the header, i.e. takes the random away.

Quoted 7 lines

This could work, but you still have the problem of - if the header gets wiped, all the data is lost.
As for storing things on the TPM chip - that doesn't scale. Today you only think about disk encryption, tomorrow there is a new application, which wants to do the same thing and so on. One of the features of derived keys - you don't store anything, just recreate/derive when needed and it scales infinitely.

Quoted 2 lines

OK, so now I know the problem at least and that is probably the most important thing in this discussion, right?

Yes, I think so.

Quoted 2 lines

So make a better story, now you also probably have better idea, also split the patch properly by subsystem, send the patch set,

I'm actually not super clear on this part - I have two patches: one for TPM header definitions and another one for the keyring subsystem? Any other subsystems in play here?

Quoted 1 line

and I'll promise to revisit.

Thanks. Would probably take some time as I want to think more on the open questions I raised in the description, try to address some comments from James B from other replies (key rotation for example) and rebase on recently merged TPM encrypted sessions. But since this is an RFC I would like to continue the discussion and gather opinions from folks here, if there are any more concerns.

Quoted 4 lines

Fair enough? :-)

BR, Jarkko

Quoted 3 lines · Ignat Korchagin

For example, a cheap NAS box with no internal storage (disks connected externally via USB). We want:
* disks to be encrypted and decryptable only by this NAS box

So how this differs from LUKS2 style, which also systemd supports where the encryption key is anchored to PCR's? If I took hard drive out of my Linux box, I could not decrypt it in another machine because of this.

Quoted 2 lines

* if someone steals one of the disks - we don't want them to see it
has encrypted data (no LUKS header)

So what happens when you reconnect?

Quoted 3 lines

Additionally we may want to SSH into the NAS for configuration and we don't want the SSH server key to change after each boot (regardless if disks are connected or not).

Right, interesting use case. Begin before any technical jargon exactly with a great example like this. Then it is easier to start to anchoring stuff and not be misleaded.

BR, Jarkko

Quoted 9 lines · Jarkko Sakkinen

Quoted 3 lines · Ignat Korchagin

For example, a cheap NAS box with no internal storage (disks connected externally via USB). We want:
* disks to be encrypted and decryptable only by this NAS box

So how this differs from LUKS2 style, which also systemd supports where the encryption key is anchored to PCR's? If I took hard drive out of my Linux box, I could not decrypt it in another machine because of this.

It differs with the fact that the disk has a clearly identifiable LUKS2 header, which tells an adversary that this is a disk with some data that is encrypted. With derived keys and plain dm-crypt mode there is no LUKS header, so it is not possible to tell if it is an encrypted disk or a disk with just random data. Additionally, if I accidentally wipe the sector with the LUKS2 header - all my data is lost (because the data encryption key from the header is lost). With derived keys I can always decrypt at least some data, if the disk is available.

  * if someone steals one of the disks - we don't want them to see it has encrypted data (no LUKS header)

Quoted 2 lines · Ignat Korchagin

* if someone steals one of the disks - we don't want them to see it
has encrypted data (no LUKS header)

What is the use case that makes this important? In usual operation over the network, the fact that we're setting up encryption is easily identifiable to any packet sniffer (DHE key exchanges are fairly easy to fingerprint), but security relies on the fact that even knowing that we're setting up encryption, the attacker can't gain access to it. The fact that we are setting up encryption isn't seen as a useful thing to conceal, so why is it important for your encrypted disk use case?

James

Quoted 5 lines · James Bottomley

Quoted 2 lines · Ignat Korchagin

  * if someone steals one of the disks - we don't want them to see it has encrypted data (no LUKS header)

Quoted 8 lines

What is the use case that makes this important?  In usual operation over the network, the fact that we're setting up encryption is easily identifiable to any packet sniffer (DHE key exchanges are fairly easy to fingerprint), but security relies on the fact that even knowing that we're setting up encryption, the attacker can't gain access to it.  The fact that we are setting up encryption isn't seen as a useful thing to conceal, so why is it important for your encrypted disk use case?

In some "jurisdictions" authorities can demand that you decrypt the data for them for "reasons". On the other hand if they can't prove there is a ciphertext in the first place - it makes their case harder.

Quoted 16 lines · Ignat Korchagin

Quoted 5 lines · James Bottomley

Quoted 2 lines · Ignat Korchagin

* if someone steals one of the disks - we don't want them to
see it has encrypted data (no LUKS header)

Quoted 8 lines

What is the use case that makes this important? In usual operation over the network, the fact that we're setting up encryption is easily identifiable to any packet sniffer (DHE key exchanges are fairly easy to fingerprint), but security relies on the fact that even knowing that we're setting up encryption, the attacker can't gain access to it. The fact that we are setting up encryption isn't seen as a useful thing to conceal, so why is it important for your encrypted disk use case?

Quoted 4 lines

In some "jurisdictions" authorities can demand that you decrypt the data for them for "reasons". On the other hand if they can't prove there is a ciphertext in the first place - it makes their case harder.

Well, this isn't necessarily a good assumption: the way to detect an encrypted disk is to look at the entropy of the device blocks. If the disk is encrypted, the entropy will be pretty much maximal unlike every other use case. The other thing is that if the authorities have your

TPM, they already have access to the disk in this derived key scenario.

If *you* still have access to your TPM, you can update the storage seed to shred the data.

James