[Rats] Re: Security considerations of remote attestation (RFC9334)

["lgl island-resort.com" <[e-mail]>]

A detour for the purpose of framing:

The reason attestation is so important for client devices is that end user people are entirely untrustworthy. The person using a mobile phone or a FIDO authenticator is not a security professional, doesn’t want to update their software and can be duped.  Banking services, distributors of important documents and such want to know the device the user is using behaves. They can NOT rely on the user to assure that.

This makes it critical that the attestation key is entirely different from what ever authenticates the end user person. The attestation key has to be associated with the device maker, never the end user person.

I started in this thread thinking the same distinction was important for server/services, but maybe not...



On Jan 5, 2025, at 4:48 AM, Muhammad Usama Sardar <[e-mail]> wrote:


I think we are getting closer. I do appreciate that you want to be inclusive by saying "keying material" to include HMAC-like solutions but just to understand each other better, let's be more precise about the keys - the way we put it in draft can be different. Below I am assuming a remote attestation solution based on digital signatures. At a high level, there are three main keys:

1. Attestation Key (AK): It is used for signing attestation claims.

It also must identify the implementor of the attester so a verifier can decide if they are trustworthy.

draft-fossati-tls-attestation section 1 says:

Attestation [RFC9334] is the process by which an entity produces evidence about itself that another party can use to evaluate the trustworthiness of that entity.

That’s not very good because the entity could be lying. You also need to know the entity is trustworthy. That happens through proved identity and out-of-band information that the identified entity is trustworthy.

2. TLS Identity Key (TIK): Ephemeral Key (EK): It is a key generated within a TEE and its public part is signed by AK. However, the TLS peer (TLS client in my case) has no prior knowledge about this key.

This is an internal part of TLS protocol, right?

3. TLS Identity Key (TIK): Long-term Key (LTK): It is the key bound to the machine's long-term identity (assigned name/FQDN etc.) and it is the key which is typically used to provide "authentication" in standard (non-PSK based) TLS protocol.

For the common public Internet use of TLS, I’d describe this as the https service provider key. If you paid widgets.com and they didn’t send your package of widgets you know who to go after. It’s not really about a machine or even a key because the machines and keys for https://widgets.com will come and go.

I’d say that these keys actually authenticates the legal entity, the people that work there, its business practices and such (e.g. Widgets Inc.). When you decide to pay widgets.com, that’s what you have in mind.

So, yes, we’re reasonably in agreement on keys. :-)



Based on this, please see inline:

On 05.01.25 05:38, lgl island-resort.com wrote:

IIUC you are describing TLS client as attester while I had TLS server as attester in my mind. This is partly because we have done the formal analysis of the latter [1], while only some initial specification work for the former.


Seems like we can do attestation in either (or even both) directions with TLS.

Sure. I am really sorry if it came across wrong. I didn't mean to say that the TLS client as attester as well as mutual attestation are not possible. They are perfectly legitimate cases with TLS. In fact, draft-fossati-tls-attestation includes all these cases.

Absolutely no worries here. It’s a good discussion.


I intended to say that TLS client as attester and mutual attestation are currently work-in-progress from formal verification perspective. I do not expect a major change in results for these cases but I wanted to stick to TLS server as attester for which we do have better understanding as well as results of formal verification. It is also a typical case in confidential computing.

I understand from [1] that there maybe some TLS protocol issues, but what’s interesting to me is the key material of something like RA-TLS. I don’t understand what the thinking is for this yet.


Can you clarify the key material for which of above keys (1, 2 or 3) you were interested in? Also, I suspect you are interested in the Key Derivation Function (KDF) of the key, right?

1 and 3 because I’m interested in the ownership, life cycle and policies for the keys. Pretty sure I’m not interested in the KDF.



I think the purpose of https key material is to authenticate that bigbank.com really is Big Bank Corp and that it is distinct from attestation key material provided by Intel, Qualcomm and such vendors.


Here is my understanding (please correct me if I am wrong):

  *   "https key material" refers to 3 above
  *   "attestation key material" refers to 1 above

Yes


Anyway, trying to map what you said to my scenario: Intel develops an attester (e.g., TDX), installs key pair AK and publishes public key via website. But at the time when this attester leaves Intel factory, neither the location of attester where it will run nor the organization which will control this attester is known. Both may be important for regulatory purposes, such as processing of medical and financial data.


An attester isn’t really an attester until someone controls it, right?

I don't think so. I think there is always someone who can control it. For example, Intel is in full control until some new owner (purchaser) assigns it a new identity.

Right. It is likely always under control of someone, but the policy and semantics may change with an ownership change.


Same as a key pair someone generates. A key pair isn’t interesting or useful until we know who owns the private key and what they will sign with it. Sorting out ownership hand-offs seems complicated. I think Ned was trying to describe what to do.  Seems that this could be difficult to standardize and end up very vendor specific.



For security properties, I am thinking about [2], e.g., Server authentication. The software and hardware can be "attested" but the server "authentication" does not hold because the long-term identity (machine identity: assigned name/FQDN) is never used in the protocol you mentioned. Please correct me if I misunderstood something in your reasoning.


The question I have is whether the https service provider key material for bigbank.com is somehow made to also serve as attestation key material.

Assuming the following (please correct me if wrong):

  *   "https service provider key material" refers to 3 above
  *   "attestation key material" refers to 1 above

Both yes and no :) depending on the protocol, see below

If yes, how?

Depending on what exactly you mean by "also serve as" (please clarify further if I am misinterpreting), two relevant examples are attested CSR [3] and attested TLS [4]. I believe (haven't evaluated formally yet) the former, with passport model, has weak security guarantees. The latter, however, has technical limitations as CertificateVerify message of TLS is not extensible and you can provide proof-of-possession of only one key [5]. So, with [4] you can have either "attestation" or "authentication", but not both.


If no, then what key material is used for attestation?


RA-TLS [1] is an example here. It uses 1 for attestation.

The protocol never uses 3. My point was that such protocols which use only 1 and 2 (and not 3) can only provide "attestation" of software and hardware but cannot provide "authentication" of who is in control of the machine and where it runs. Do you agree?

Yes, I do agree.

This is still thinking-in-progress, but maybe the first thing to be clear about for a given attested TLS design is whether it can support separate keys for 1 and 3. We could define:

Split server-auth and attestation — Does both server auth and attestation and uses a different key for each
Merged server-auth and attestation — Uses the (very common) server auth key to do both attestation and server auth
Attestation-only — Only one key and it does attestation, never server auth

Maybe for the next round of email: a description of the security disadvantages of merging server auth and attestation.

LL




[1] https://ieeexplore.ieee.org/document/10752524

[2] https://datatracker.ietf.org/doc/html/rfc8446#appendix-E.1



[3] https://datatracker.ietf.org/doc/draft-ietf-lamps-csr-attestation/

[4] https://www.ietf.org/archive/id/draft-fossati-tls-attestation-08.html#name-attestation-alongside-x509-

[5] https://github.com/tls-attestation/draft-tls-attestation/issues/73

[6] https://ieeexplore.ieee.org/document/10373038