]>

cfm@acm.org

hannes.tschofenig@gmx.net

Usable Formal Methods Proposed Research Group This draft follows the invitation of to propose another sample problem for demonstration, training, and evaluation of formal methods in IETF work. It draws on recent work from the Software Updates for the Internet of Things and Trusted Execution Environment Provisioning working groups to define a sample modeling problem for a novel rather than a familiar IETF protocol. About This Document Status information for this document may be found at . Discussion of this document takes place on the Usable Formal Methods Research Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction In this draft we take the Trusted Execution Environment Provisioning protocol to be a good domain from which to draw a sample modeling problem for slightly different reasons than those proposed in .

1. TEEP is a proposed standard under active development, at working-group consensus as of this writing. Formal modeling, even for demonstration or training purposes, can therefore increase familiarity with the TEEP protocol, including outside of the SUIT and TEEP working groups directly involed in its development.
2. The TEEP protocol is expressly concerned with security, so it has security properties amenable to formal description, modeling, and analysis. Any findings may have valuable security implications.
3. The TEEP protocol has well-defined use cases and includes a number of options for flexibility, including provisions for constrained environments. Modeling the entire protocol, including all its options, is a reasonable challenge for a learning or training exercise. By contrast, limits itself to just the SEARCH command of .
4. The TEEP protocol follows a typical protocol design in the IETF where various already-standardized technologies are reused. In this case, protocols from the Software Updates for Internet of Things (SUIT) architecture and the Remote Attestation Procedures (RATS) architecture are incorporated into the design.
5. The architecture of the TEEP protocol is also representative for IETF protocol development since more than two parties are involved in the protocol communication even in a single, self-contined deployment. Whether a formal model must consider all parties or can limit itself to a subset is a worthwhile question about the scope of this sample problem.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

The Trusted Execution Environment Provisioning (TEEP) Protocol The Trusted Execution Environment Provisioning protocol specifies communication between a Trusted Application Manager (TAM) and a TEEP Agent. Importantly, this communication is relayed by an untrusted TEEP Broker . Two security-sensitive payloads are communicated via the TEEP protocol, namely:

• Trusted Applications (TAs) and Trusted Components (TCs) ; and
• attestation evidence.

A Trusted Application is an application (or, in some implementations, an application component) that runs in a TEE. A Trusted Component is a set of code and/or data in a TEE that is managed as a unit by a TAM. Trusted Applications and Personalization Data are thus managed by being included in Trusted Components. TCs are provided by developers or authors, which TEEP calls "Trusted Component Signers" . SUIT manifests protect TCs' integrity and may optionally protect their confidentiality as well. Neither the TAM nor the TEEP Broker should be able to modify TCs. TEEP Agents only install TCs from sources they trust. Attestation evidence is typically communicated from the TEEP Agent to the TAM, although there is the option to offer attestation capabilities in both directions. In the description below, we focus only on attestation of the Device containing the TEEP Agent to the TAM, rather than attestation in the other direction. The description below illustrates the basic communication interaction, with details of the TEEP protocol abstracted away.

NonceRequest/NonceRespone Verifier: NonceRequest TAM <- Verifier: NonceResponse Nonce ]]>

QueryRequest TEEP Agent: QueryRequest {token, challenge, supported-teep-cipher-suites, supported-suit-cose-profiles, data-item-requested(trusted-components, attestation)}SK_TAM ]]>

• The challenge is a random number provided by the Verifier . It is used to demonstrate the freshness of the attestation evidence.
• The token is a random number that is used to match the QueryRequest against the QueryResponse.
• supported-teep-cipher-suites and supported-suit-cose-profiles offer cipher-suite negotation.
• data-item-requested(X) indicates the functionality that the TAM requests the TEEP Agent perform.
• {_}SK_TAM indicates a digital signature over the payload of the message using a private (or secret) key that is only known to the TAM.

EvidenceRequest/EvidenceResponse Attester: EvidenceRequest challenge TEEP Agent <- Attester: EvidenceResponse {challenge, claims}SK_ATTESTER ]]>

• {challenge, claims}SK_ATTESTER represents the evidence, which is signed by the Attester using its private key SK_ATTESTER. In addition to the inclusion of the Challenge, the random number provided by the Verifier, it also includes further (unspecified) claims. While those claims are important for the overall system, they are not in scope of this analysis.

QueryResponse

• selected-teep-cipher-suite indicates the selected cipher suite.
• attestation-payload-format(EAT) indicates the format of the attached attestation evidence.
• tc-list conveys the list of Trusted Components installed on the Device.
• attestation-payload(_) contains the evidence provided by the Attester in the previous step.
• {_}SK_AGENT indicates a digital signature over the payload of the message using a private (or secret) key that is only known to the Agent.

SoftwareUpdate TAM: SoftwareUpdate {manifest, sequence_nr, TC}SK_AUTHOR ]]>

• The manifest contains instructions for how to install the software.
• sequence_nr, as the name indicates, allows the TEEP Agent to distingush this update from earlier versions of the software.
• TC is the Trusted Component to be installed. This could be a binary, configuration data, or both.
• {_}SK_AUTHOR indicates a digital signature over the payload of the message using a private (or secret) key that is only known to the author, i.e. the Trusted Component Signer.

Update The TAM transmits an update to the TEEP Agent containing the previously obtained payload provided by the author. TEEP Agent: Update {token2, {manifest, sequence_nr, software}SK_AUTHOR}SK_TAM ]]>

• token2 is a new random number, which is again used by the TAM to match requests against responses.
• {_}SK_TAM indicates a digital signature over the payload of the message using a private (or secret) key that is only known to the TAM.

Success The TEEP Agent returns this message when the software installation was successful.

• {_}SK_AGENT indicates a digital signature over the payload of the message using a private (or secret) key that is only known to the Agent.

Security Properties In addition to the integrity and authentication properties, an important aspect is replay protection. At the meeting, the following editorial addition was proposed in TEEP's security consideration ():

• The TEEP protocol supports replay protection as follows. The transport protocol under the TEEP protocol might provide replay protection, but may be terminated in the TEEP Broker which is not trusted by the TEEP Agent and so the TEEP protocol does replay protection itself. If attestation of the TAM is used, the attestation freshness mechanism provides replay protection for attested QueryRequest messages. If non-attested QueryRequest messages are replayed, the TEEP Agent will generate QueryResponse or Error messages, but the REE can already conduct Denial of Service attacks against the TEE and/or the TAM even without the TEEP protocol. QueryResponse messages have replay protection via attestation freshness mechanism, or the token field in the message if attestation is not used. Update messages have replay protection via the suit-manifest-sequence-number (see Section 8.4.2 of [I-D.ietf-suit-manifest]). Error and Success messages have replay protection via SUIT Reports and/or the token field in the message, where a TAM can detect which message it is in response to.

Any formal model of TEEP should be able to prove this replay protection. While confidentiality protection is possible for attestation evidence as well as for Trusted Components, it is not mandatory functionality.

Security Considerations This document has no security considerations of its own, although it may contribute indirectly to the development of new security considerations for the TEEP protocol.

IANA Considerations This document has no IANA actions.

References Normative References Broadcom Amazon Microsoft ALAXALA Networks Corp. This document specifies a protocol that installs, updates, and deletes Trusted Components in a device with a Trusted Execution Environment (TEE). This specification defines an interoperable protocol for managing the lifecycle of Trusted Components. Vulnerabilities in Internet of Things (IoT) devices have raised the need for a reliable and secure firmware update mechanism suitable for devices with resource constraints. Incorporating such an update mechanism is a fundamental requirement for fixing vulnerabilities, but it also enables other important capabilities such as updating configuration settings and adding new functionality. In addition to the definition of terminology and an architecture, this document provides the motivation for the standardization of a manifest format as a transport-agnostic means for describing and protecting firmware updates. In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References IETF IETF Trinity College, Dublin This draft provides reasoning as to why the Usable Formal Methods research group might benefit from having an IETF-relevant sample problem and describes one such (IMAP search). This is just an initial draft aiming to help move discussion forward so may be dropped or replaced by other drafts or the research group may prefer some non I-D format, or the research group may decide that sample problems aren't sufficiently useful. Early days, basically! The Internet Message Access Protocol Version 4rev2 (IMAP4rev2) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev2 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev2 also provides the capability for an offline client to resynchronize with the server. IMAP4rev2 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; removing messages permanently; setting and clearing flags; parsing per RFCs 5322, 2045, and 2231; searching; and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev2 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev2 does not specify a means of posting mail; this function is handled by a mail submission protocol such as the one specified in RFC 6409. A Trusted Execution Environment (TEE) is an environment that enforces the following: any code within the environment cannot be tampered with, and any data used by such code cannot be read or tampered with by any code outside the environment. This architecture document discusses the motivation for designing and standardizing a protocol for managing the lifecycle of Trusted Applications running inside such a TEE.