Subject: [Teep] draft-tschofenig-teep-otrp-v2-00

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 9 Jul 2019 08:46:42 +0000

Hi all,

We put together a draft about what I would call version 2 of the OTrP protocol. Why version 2?

As you know, there is some work in Global Platform standardizing the version we have been working on so far in the group.
However, based on the design decisions made so far we are breaking backwards compatibility. We need to distinguish the two versions somehow.

Did we just create a problem with this approach? Not really! We are trying to cover a much broader set of use cases than envisioned with the initial version of OTrP.
When the work on OTrP started the primary use case was about mobile phones and tablets. We added other types of TEEs, such as SGX and at the last hackathon people talked about RISC-V-based TEEs. We now also want to cover IoT scenarios.
Technology has also evolved with the work by Microsoft on their Open Enclave SDK and with TrustZone for v8-M. The IETF has also started various standardization activities, which we are leveraging.

So, what's in that new draft - an individual submission at this point in time:

  *   Removal of the security domain management concept (although this can be added as an extension)
  *   Encoding agnostic description using CDDL (although it focuses on CBOR/COSE because of my limited understanding of CDDL)
  *   Added CBOR/COSE encoding (the earlier version of OTrP only supported JSON/JOSE)
  *   Terminology alignment with the TEEP architecture draft
  *   Support of attestation via the RATS/EAT specification
  *   Support for software management via the SUIT manifest
  *   Added better extension management
  *   Removed a lot of redundant text (the text is already in the architecture document and there is no point in repeating it again)

Re-using other IETF specifications and removing features and optimizations made this new version much simpler. I also believe it will be much, much easier to implement.

There are some questions that surfaced during the work on this draft, such as whether we want to support multiple encodings for this protocol. I plan to discuss these topics at the upcoming IETF meeting (if I get a presentation slot)

I hope you find this interesting and I am looking forward to see your feedback!

Ciao
Hannes
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 9 Jul 2019 15:56:51 +0200

> However, based on the design decisions made so far we are breaking backwards compatibility. We need to distinguish the two versions somehow.

A wise decision!  BTW, I never understood the point making an IETF copy (it was?) of another standard.

<snip>
> There are some questions that surfaced during the work on this draft, such as whether we want to support multiple encodings for this protocol. I plan to discuss these topics at the upcoming IETF me…

I have said it before and I say it again: By separating the API from the Protocol and rather use a session-based scheme you get a cleaner and more powerful system [*] in the end.  Yeah, the initial task will be 30-50% bigger but that difference is zeroed out when you have both protocol encodings in place.

"Executive Level" description: https://cyberphone.github.io/doc/research/session-based-remote-attestation.pdf

> I hope you find this interesting and I am looking forward to see your feedback!

It was indeed quite interesting :-)

Anders

*] The long-term plan with the mentioned SKS/KeyGen2 (API/Protocol) scheme is making remotely provisioned cryptographic keys first class OS objects similar to Users, Files, Processes, etc.

> _______________________________________________
> TEEP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teep
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 9 Jul 2019 13:59:31 +0000

Hi Anders,

> A wise decision!  BTW, I never understood the point making an IETF copy (it was?) of another standard.

Actually, it was the other way around.

Certainly a good point but I fear that it is not really design a secure system when the protocol does not terminate the secure world.

Ciao
Hannes

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Tue, 9 Jul 2019 14:19:45 +0000

Hi all,

On 9 Jul 2019, at 09:46, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
We put together a draft about what I would call version 2 of the OTrP protocol. Why version 2?

Given the loss of backward compatibility with OTrP v1, I wonder whether it makes sense to change the name. I don’t believe it serves anyone well to have two rather different standards (hence non-interoperable based on them) under the OTrP name.

Given that IETF is trying to achieve something quite different than GlobalPlatform with Teep (and very successfully, to judge by progress so far), I believe there would be benefit in differentiating the Tee work product from existing standards.

Best regards
Jeremy

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 9 Jul 2019 16:26:12 +0200

> Actually, it was the other way around.

Thanx, I didn't know that.

> Certainly a good point but I fear that it is not really design a secure system when the protocol does not terminate the secure world.

Every step of the protocol is supposed to be secured through MAC signatures.  If the protocol doesn't obey the API (which is running in the secure world [*]), the session terminates and the accumulated operations are rolled back.

Verifying my claims regarding the security of this scheme is non-trivial but it is not entirely different to TLS which you are an expert on.

Regards,
Anders

*] potentially extending into a security processor doing all cryptographic operations based on encrypted key material.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 9 Jul 2019 14:35:08 +0000

Hi Jeremy,

using a different name (instead of a different version number) is also an option, indeed.

Ciao
Hannes

From: Jeremy O'Donoghue <[email-masked]>
Sent: Dienstag, 9. Juli 2019 16:20
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]
Subject: Re: [Teep] draft-tschofenig-teep-otrp-v2-00

Hi all,

Best regards
Jeremy

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 9 Jul 2019 14:41:16 +0000

Let's look at a specific example, the QueryRequest message:

   QueryRequest = (
        TYPE : int,
        TOKEN : bstr,
        REQUEST : [+data_items],
        ? CIPHER_SUITE : [+suite],
        ? NONCE : bstr,
        ? VERSION : [+version],
        ? OCSP_DATA : bstr,
        * $$extensions
   )

What does it mean to separating the API from the protocol?
I believe the NONCE, the OCSP_DATA, the TOKEN, the REQUEST and the CIPHER_SUIT need to be made available to the OTrP Agent running inside the secure world to make some meaningful decisions. This data has to be encoded somehow.

In that list the only item that is missing is the TYPE and it would have to be mapped into an API to make sense.

The issue is: there is not much of a protocol left in the current design that can be terminated outside the secure world without making the computations in the secure world meaningless.

Ciao
Hannes

-----Original Message-----
From: Anders Rundgren <[email-masked]>
Sent: Dienstag, 9. Juli 2019 16:26
To: Hannes Tschofenig <[email-masked]>; [email-masked]
Subject: Re: [Teep] draft-tschofenig-teep-otrp-v2-00

Regards,
Anders

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 9 Jul 2019 17:48:39 +0200

On 2019-07-09 16:41, Hannes Tschofenig wrote:
> Let's look at a specific example,

That's the way to go :-)

> the QueryRequest message:
> 
>     QueryRequest = (
>          TYPE : int,
>          TOKEN : bstr,
>          REQUEST : [+data_items],

It would not make much sense doing a direct translation because in the session based scheme lots of data is exchanged in the initialization phase and does not need to be repeated.

The (not shown) Msg_AuthEnc_Wrapper would for example become redundant.

> What does it mean to separating the API from the protocol?

It for example means that you can aggregate API calls protocol-wise.  In my particular case it also enables the provisioning proxy running in the REE to perform some additional tasks but that probably does not apply to TEEP scenarios.

> I believe the NONCE, the OCSP_DATA, the TOKEN, the REQUEST and the CIPHER_SUIT need to be made available to the OTrP Agent running inside the secure world to make some meaningful decisions.
Most likely TOKEN, CIPHER_SUITE, NONCE and VERSION would not be needed because they are already better dealt with during session creation.

 > This data has to be encoded somehow.

Right, all data needs to be encoded but the API would only bother about a single encoding which I believe would be binary and CBOR-encoded blobs in most cases.  MACs only operate on the raw API data.

> In that list the only item that is missing is the TYPE and it would have to be mapped into an API to make sense.

Yes, TYPE is the API method.

> The issue is: there is not much of a protocol left in the current design that can be terminated outside the secure world without making the computations in the secure world meaningless.

Well, the intent at least is not terminating any secure operation outside the secure world.

Anyway, a transformation of a static scheme into a session-based ditto certainly isn't something you can do in one day since it might spill back on the architecture as well.

I leave it there, but anybody is free pinging me anytime on this topic.  Session-based provisioning rocks!

Best
Anders