Trusted Execution Environment Provisioning (TEEP) Architecture
draft-ietf-teep-architecture-06

Pei, et al.              Expires August 11, 2020               [Page 23]
Internet-Draft              TEEP Architecture              February 2020

7.1.  Information Required in TEEP Claims

   -  Device Identifying Info: TEEP attestations may need to uniquely
      identify a device to the TAM and TA developer.  Unique device
      identification allows the TAM to provide services to the device,
      such as managing installed TAs, and providing subscriptions to
      services, and locating device-specific keying material to
      communicate with or authenticate the device.  In some use cases it
      may be sufficient to identify only the class of the device.  The
      security and privacy requirements regarding device identification
      will vary with the type of TA provisioned to the TEE.

   -  TEE Identifying info: The type of TEE that generated this
      attestation must be identified, including version identification
      information such as the hardware, firmware, and software version
      of the TEE, as applicable by the TEE type.  TEE manufacturer
      information for the TEE is required in order to disambiguate the
      same TEE type created by different manufacturers and resolve
      potential assumptions around manufacturer provisioning, keying and
      support for the TEE.

   -  Freshness Proof: A claim that includes freshness information must
      be included, such as a nonce or timestamp.

   -  Requested Components: A list of zero or more components (TAs or
      other dependencies needed by a TEE) that are requested by some
      depending app, but which are not currently installed in the TEE.

8.  Algorithm and Attestation Agility

   RFC 7696 [RFC7696] outlines the requirements to migrate from one
   mandatory-to-implement algorithm suite to another over time.  This
   feature is also known as crypto agility.  Protocol evolution is
   greatly simplified when crypto agility is considered during the
   design of the protocol.  In the case of the TEEP protocol the diverse
   range of use cases, from trusted app updates for smart phones and
   tablets to updates of code on higher-end IoT devices, creates the
   need for different mandatory-to-implement algorithms already from the
   start.

   Crypto agility in TEEP concerns the use of symmetric as well as
   asymmetric algorithms.  Symmetric algorithms are used for encryption
   of content whereas the asymmetric algorithms are mostly used for
   signing messages.

   In addition to the use of cryptographic algorithms in TEEP, there is
   also the need to make use of different attestation technologies.  A
   device must provide techniques to inform a TAM about the attestation

Pei, et al.              Expires August 11, 2020               [Page 24]
Internet-Draft              TEEP Architecture              February 2020

   technology it supports.  For many deployment cases it is more likely
   for the TAM to support one or more attestation techniques whereas the
   device may only support one.

9.  Security Considerations

9.1.  Broker Trust Model

   The architecture enables the TAM to communicate, via a TEEP Broker,
   with the device's TEE to manage TAs.  Since the TEEP Broker runs in a
   potentially vulnerable REE, the TEEP Broker could, however, be (or be
   infected by) malware.  As such, all TAM messages are signed and
   sensitive data is encrypted such that the TEEP Broker cannot modify
   or capture sensitive data.

   A TEEP Agent in a TEE is responsible for protecting against potential
   attacks from a compromised TEEP Broker or rogue malware in the REE.
   A rogue TEEP Broker might send corrupted data to the TEEP Agent, or
   launch a DoS attack by sending a flood of TEEP protocol requests.
   The TEEP Agent validates the signature of each TEEP protocol request
   and checks the signing certificate against its Trust Anchors.  To
   mitigate DoS attacks, it might also add some protection scheme such
   as a threshold on repeated requests or number of TAs that can be
   installed.

9.2.  Data Protection at TAM and TEE

   The TEE implementation provides protection of data on the device.  It
   is the responsibility of the TAM to protect data on its servers.

9.3.  Compromised REE

   It is possible that the REE of a device is compromised.  If the REE
   is compromised, several DoS attacks may be launched.  The compromised
   REE may terminate the TEEP Broker such that TEEP transactions cannot
   reach the TEE.  However, while a DoS attack cannot be prevented, the
   REE cannot access anything in the TEE if it is implemented correctly.
   Some TEEs may have some watchdog scheme to observe REE state and
   mitigate DoS attacks against it but most TEEs don't have have such
   capability.

   In some other scenarios, the compromised REE may ask a TEEP Broker to
   make repeated requests to a TEEP Agent in a TEE to install or
   uninstall a TA.  A TA installation or uninstallation request
   constructed by the TEEP Broker or REE will be rejected by the TEEP
   Agent because the request won't have the correct signature from a TAM
   to pass the request signature validation.

Pei, et al.              Expires August 11, 2020               [Page 25]
Internet-Draft              TEEP Architecture              February 2020

   This can become a DoS attack by exhausting resources in a TEE with
   repeated requests.  In general, a DoS attack threat exists when the
   REE is compromised, and a DoS attack can happen to other resources.
   The TEEP architecture doesn't change this.

   A compromised REE might also request initiating the full flow of
   installation of TAs that are not necessary.  It may also repeat a
   prior legitimate TA installation request.  A TEEP Agent
   implementation is responsible for ensuring that it can recognize and
   decline such repeated requests.  It is also responsible for
   protecting the resource usage allocated for TA management.

9.4.  Compromised CA

   A root CA for TAM certificates might get compromised.  Some TEE Trust
   Anchor update mechanism is expected from device OEMs.  TEEs are
   responsible for validating certificate revocation about a TAM
   certificate chain.

   If the root CA of some TEE device certificates is compromised, these
   devices might be rejected by a TAM, which is a decision of the TAM
   implementation and policy choice.  TAMs are responsible for
   validating any intermediate CA for TEE device certificates.

9.5.  Compromised TAM

   Device TEEs are responsible for validating the supplied TAM
   certificates to determine that the TAM is trustworthy.

9.6.  Malicious TA Removal

   It is possible that a rogue developer distributes a malicious
   Untrusted Application and intends to get a malicious TA installed.
   It's the responsibility of the TAM to not install malicious trusted
   apps in the first place.  The TEEP architecture allows a TEEP Agent
   to decide which TAMs it trusts via Trust Anchors, and delegates the
   TA authenticity check to the TAMs it trusts.

   It may happen that a TA was previously considered trustworthy but is
   later found to be buggy or compromised.  In this case, the TAM can
   initiate the removal of the TA by notifying devices to remove the TA
   (and potentially the REE or device owner to remove any Untrusted
   Application that depend on the TA).  If the TAM does not currently
   have a connection to the TEEP Agent on a device, such a notification
   would occur the next time connectivity does exist.

Pei, et al.              Expires August 11, 2020               [Page 26]
Internet-Draft              TEEP Architecture              February 2020

   Furthermore the policy in the Verifier in an attestation process can
   be updated so that any evidence that includes the malicious TA would
   result in an attestation failure.

9.7.  Certificate Renewal

   TEE device certificates are expected to be long lived, longer than
   the lifetime of a device.  A TAM certificate usually has a moderate
   lifetime of 2 to 5 years.  A TAM should get renewed or rekeyed
   certificates.  The root CA certificates for a TAM, which are embedded
   into the Trust Anchor store in a device, should have long lifetimes
   that don't require device Trust Anchor update.  On the other hand, it
   is imperative that OEMs or device providers plan for support of Trust
   Anchor update in their shipped devices.

9.8.  Keeping Secrets from the TAM

   In some scenarios, it is desirable to protect the TA binary or
   configuration from being disclosed to the TAM that distributes them.
   In such a scenario, the files can be encrypted end-to-end between a
   TA developer and a TEE.  However, there must be some means of
   provisioning the decryption key into the TEE and/or some means of the
   TA developer securely learning a public key of the TEE that it can
   use to encrypt.  One way to do this is for the TA developer to run
   its own TAM so that it can distribute the decryption key via the TEEP
   protocol, and the key file can be a dependency in the manifest of the
   encrypted TA.  Thus, the TEEP Agent would look at the TA manifest,
   determine there is a dependency with a TAM URI of the TA developer's
   TAM.  The Agent would then install the dependency, and then continue
   with the TA installation steps, including decrypting the TA binary
   with the relevant key.

10.  IANA Considerations

   This document does not require actions by IANA.

11.  Contributors

   -  Andrew Atyeo, Intercede (andrew.atyeo@intercede.com)

   -  Liu Dapeng, Alibaba Group (maxpassion@gmail.com)

12.  Acknowledgements

   We would like to thank Nick Cook, Minho Yoo, Brian Witten, Tyler Kim,
   Alin Mutu, Juergen Schoenwaelder, Nicolae Paladi, Sorin Faibish, Ned
   Smith, Russ Housley, Jeremy O'Donoghue, and Anders Rundgren for their
   feedback.

Pei, et al.              Expires August 11, 2020               [Page 27]
Internet-Draft              TEEP Architecture              February 2020

13.  Informative References

   [GPTEE]    GlobalPlatform, "GlobalPlatform Device Technology: TEE
              System Architecture, v1.1", GlobalPlatform GPD_SPE_009,
              January 2017, <https://globalplatform.org/specs-library/
              tee-system-architecture-v1-1/>.

   [I-D.ietf-rats-architecture]
              Birkholz, H., Thaler, D., Richardson, M., and N. Smith,
              "Remote Attestation Procedures Architecture", draft-ietf-
              rats-architecture-01 (work in progress), February 2020.

   [I-D.ietf-suit-manifest]
              Moran, B., Tschofenig, H., and H. Birkholz, "A Concise
              Binary Object Representation (CBOR)-based Serialization
              Format for the Software Updates for Internet of Things
              (SUIT) Manifest", draft-ietf-suit-manifest-03 (work in
              progress), February 2020.

   [I-D.ietf-teep-otrp-over-http]
              Thaler, D., "HTTP Transport for Trusted Execution
              Environment Provisioning: Agent-to- TAM Communication",
              draft-ietf-teep-otrp-over-http-03 (work in progress),
              November 2019.

   [RFC6024]  Reddy, R. and C. Wallace, "Trust Anchor Management
              Requirements", RFC 6024, DOI 10.17487/RFC6024, October
              2010, <https://www.rfc-editor.org/info/rfc6024>.

   [RFC7696]  Housley, R., "Guidelines for Cryptographic Algorithm
              Agility and Selecting Mandatory-to-Implement Algorithms",
              BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
              <https://www.rfc-editor.org/info/rfc7696>.

Authors' Addresses

   Mingliang Pei
   Symantec

   EMail: mingliang_pei@symantec.com

   Hannes Tschofenig
   Arm Limited

   EMail: hannes.tschofenig@arm.com

Pei, et al.              Expires August 11, 2020               [Page 28]
Internet-Draft              TEEP Architecture              February 2020

   Dave Thaler
   Microsoft

   EMail: dthaler@microsoft.com

   David Wheeler
   Intel

   EMail: david.m.wheeler@intel.com

Pei, et al.              Expires August 11, 2020               [Page 29]