Re: [Rats] draft-chen-rats-tee-identification-01 and IDevID

["[e-mail]" <[e-mail]>]

Hello LL,
        Like I said "If the TEE resource is sufficient, the whole network stack and EAP-TLS client could be involved in TEE". But if the TEE resource is restricted like IoT devices, there may have a demand to identify a device's ID in minimum cost and in trustworthiness. IDevID is a module for ID generation and storage, and it suggests to use EAP-TLS as authentication protocol. But IDevID cannot protect the EAP-TLS protocol during processing. In another word, if an ID was sent out from IDevID and used for identification, the REE environment may steal this ID and use it for replay or spoofing attack.
        In the Annex B.1 of document IEEE Std 802.1AR™-2018 also illustrate the use of IDevID with EAP-TLS, and I think it is different from this draft.
        Thank you for your comment, welcome to cooperate and talk about this topic in any way.  : )



BR
Penglin Yang
China  Mobile

 
From: Laurence Lundblade
Date: 2021-08-04 03:25
To: yangpenglin
CC: rats; chenmeiling; 粟栗
Subject: Re: [Rats] draft-chen-rats-tee-identification-01 and IDevID
Hello,

My primary observation is that the goals of the two protocols are very similar. I didn’t know whether you had looked at IDevID or not.

Also, I think an implementation of IDevID could be put in a TEE. Then your security goals would be met, I think.

This is just to offer a few thoughts and ideas. :-)

LL




On Aug 2, 2021, at 7:51 PM, [e-mail] wrote:

Hello there，as one of the authors, thank you very much for your advice, and it helps a lot. I made a comparison below to make a clarification about the difference and the meaning of TEE identification.
Architecture of IDevID
<CatchA81D.jpg>


Architecture of TEE Identification
<Catch04E1.jpg>
    In figure 1，the identity of IDevID will be exposed during the interface which is shown in arrow. In another word, there is no trusted binding between the ID and EAP-TLS server. If the attestation device is compromised, the attackers could obtain the ID and use it in other authentication scenarios.
In figure 2, all the ID related data will be encrypted by EAP-TLS handshake keys. The Inner middle layer could only export the handshake secret key encrypted certificate after verifying the credentials of EAP-TLS server. Since the EAP-TLS server will generate a random during every connection, so this architecture could also prevent replay attack.
The above is the fundamental distinction of these two architectures. This TEE identification architecture also indicates that this draft mostly focuses on the Inner middle layer and external middle layer design to provide a mechanism that could build a trusted connection between TEE and EAP-TLS Server. 
In the webinar there is a question about which identity should be supported in the architecture. Because of time limitation we cannot communicate very well. I think that the draft doesn’t restrict the type of identities since it can use X509 or RPK to identify during the process of EAP-TLS establishment. Or other identities could be sent out as encrypted application layer data after the EAP-TLS establishment.
AS a summary, the meaning of this architecture is to build a trusted authentication procedure with EAP-TLS server when the TEE resource is restricted. (If the TEE resource is sufficient, the whole network stack and EAP-TLS client could be involved in TEE.) And based on the protection of TEE, the sensitive data like IDs, keys will never be exposed in REE as plaintext.   




BR 

Penglin Yang 
China Mobile

 
From: Laurence Lundblade
Date: 2021-07-31 06:33
To: rats
CC: chenmeiling; suli
Subject: [Rats] draft-chen-rats-tee-identification-01 and IDevID
This is just to note that draft-chen-rats-tee-identification-01 seems conceptually similar to IDevID which is described in 
IEEE Std 802.1ARTM-2018, the title of which is "Secure Device Identity”.
 
LL