Subject: Re: [Teep] clarification questions on draft-ietf-teep-architecture-14

From: Daniel Migault <[email-masked]>
Date: Tue, 13 Jul 2021 19:00:54 -0400

Hi,

I am wondering if someone from Intel could address my comments / questions
related to SGX. I would like to better understand the mapping between the
proposed architecture and SGX.

Yours,
Daniel

On Sun, Mar 21, 2021 at 11:04 PM Daniel Migault <[email-masked]> wrote:

> Hi,
>
> I have been through the latest version of the teep architecture document
> (draft-ietf-teep-architecture-14) and have a few clarifying questions. I
> must say that most of these clarification questions are related to SGX.
>
> Yours,
> Daniel
>
>
>      Trusted Execution Environment Provisioning (TEEP) Architecture
>                     draft-ietf-teep-architecture-14
>
> 1.  Introduction
>
> [...]
>
> <mglt>
>
>    TEEs use hardware enforcement combined with software protection to
>    secure TAs and its data.  TEEs typically offer a more limited set of
>    services to TAs than is normally available to Untrusted Applications.
>
> Reading these sentences with SGX in
> mind, I am reading that "software
> protection" is the actual SGX software
> implementation. Is that the correct
> interpretation of "software protection"
> ?
>
> From the sentence above, "TEE offers a
> limited set of services", I am reading
> that some code running in REE will not
> be able to run in a TEE. It is unclear
> in term of services what these
> limitations are at least in a SGX
> context.  Of course in context switch
> may be different in TEE as it is in REE,
> and these limitations (may) impact the
> performances of the TA.  I am wondering
> if I am missing something or if the text
> has been written with some TEE that are
> not SGX ?
>
> </mglt>
>
> [...]
>
> <mglt>
>    To simplify the life of TA developers interacting with TAs in a TEE,
>
> I am tempted to say that TA always run
> in TEE, in which case "in a TEE" may be
> redundant or may suppose that some TA
> are not running in a TEE.  Note that it
> appears at several different places in
> the text.
>
> </mglt>
>
>    an interoperable protocol for managing TAs running in different TEEs
>    of various devices is needed.
> <mglt>
>    This software update protocol needs to
>    make sure that compatible trusted and untrusted components (if any)
>    of an application are installed on the correct device.  In this TEE
>    ecosystem, there often arises a need for an external trusted party to
>    verify the identity, claims, and rights of TA developers, devices,
>    and their TEEs.  This trusted third party is the Trusted Application
>    Manager (TAM).
>
> I am reading "this software update
> protocol" as limiting the ability to
> upgrade an already installed
> application.  I have the impression that
> installation of a software is in scope
> and that in this case, installation will
> only be permitted depending on the TEE
> version.  If this is included in the
> term "software upgrade" I have the
> impression these tasks are beyond a
> software upgrade.
>
> </mglt>
>
>    The Trusted Execution Environment Provisioning (TEEP) protocol
>    addresses the following problems:
>
>    -  An installer of an Untrusted Application that depends on a given
>       TA wants to request installation of that TA in the device's TEE so
>       that the Untrusted Application can complete, but the TEE needs to
>       verify whether such a TA is actually authorized to run in the TEE
>       and consume potentially scarce TEE resources.
>
> <mglt>
>    -  A TA developer providing a TA whose code itself is considered
>       confidential wants to determine security-relevant information of a
>       device before allowing their TA to be provisioned to the TEE
>       within the device.  An example is the verification of the type of
>       TEE included in a device and that it is capable of providing the
>       security protections required.
>
> My first question reading this paragraph
> concerns the TA developer versus the TA
> manager or device manager.  I am tempted
> to see these as two different roles, but
> I would say the responsibility to
> install a TA with a certain level of
> version of the TEE is more likely to be
> the responsibility of the TAM or a
> Device Manager than the TA developer.
> This may not exclude that TAM and TA
> developer have a specific agreement and
> some conditions are provided by the TA
> developer.
>
> I am reading this text as a TA developer
> or manager evaluates the trustworthiness
> of the REE, but I would tempted to
> consider such information as unlikely to
> be reliable, so I am wondering if there
> is anything I am missing.
>
> I understand that the TEE version and
> associated level of security are defined
> in SGX by the CPUSVN.  If that is the
> case and unless I am missing something,
> I only see CPUSVN as being mentioned in
> the REPORT, which includes an
> attestation process, in which case, a TA
> or TA installer may already have been
> instantiated. So I am wondering if I am
> not missing anything.  To sum up, I am
> wondering if - in an SGX environment -
> CPUSVN is in scope to be checked before
> installing a TA, and if so if that are
> any other way to get the value than by
> proceeding to an attestation.
>
> While not related to the code itself,
> but some sort of secret credentials
> associated to the TA, I believe that a
> TA Manager may check the level of trust
> of the TEE before provisioning the TA
> with secrets.  I am wondering if that is
> part of TEEP with Personalization Data
> or if such instantiation is always
> delegated to the TA. More specifically,
> the TA sets a trusted communication with
> the TAM that pushes the secret
> credentials.
> Now that I have read the full spec, it
> seems that the bundle description
> somehow addresses this, but I think that
> mentioning the configuration of a TA in
> the introduction or overview section
> would ease the reading.
>
> </mglt>
>
>
> <mglt>
>
>    -  A TEE in a device wants to determine whether an entity that wants
>       to manage a TA in the device is authorized to manage TAs in the
>       TEE, and what TAs the entity is permitted to manage.
>
> With SGX in mind, the "TEE wants to
> determine looks strange" as I see TEE as
> a platform that manages TAs.  I
> understand the text willing to ensure
> that only authorized TAM access
> authorized TAs. Unless I am missing
> something, the wording seems a bit
> complex.
>
> </mglt>
>
>    -  A Device Administrator wants to determine if a TA exists (is
>       installed) on a device (in the TEE), and if not, install the TA in
>       the TEE.
>
>    -  A Device Administrator wants to check whether a TA in a device's
>       TEE is the most up-to-date version, and if not, update the TA in
>       the TEE.
>
>    -  A Device Administrator wants to remove a TA from a device's TEE if
>       the TA developer is no longer maintaining that TA, when the TA has
>       been revoked or is not used for other reasons anymore (e.g., due
>       to an expired subscription).
>
>    For TEEs that simply verify and load signed TA's from an untrusted
>    filesystem, classic application distribution protocols can be used
>    without modification.  The problems in the bullets above, on the
>    other hand, require a new protocol, i.e., the TEEP protocol, for TEEs
>    that can install and enumerate TAs in a TEE-secured location and
>    where another domain-specific protocol standard (e.g., [GSMA],
>    [OTRP]) that meets the needs is not already in use.
>
> <mglt>
> I think it would be better to move this
> text above to say in specific TEE's
> environment we do have the following
> restrictions as opposed to list some
> issues and then say that this issues
> only concerns some specific environment.
>
> From this text, I also understand that
> the architecture and TEEP is not needed
> for SGX.  It is however unclear to me
> whether all problems can be addressed by
> these classic application distribution
> can be used.  As mentioned above, it is
> unclear to me how the CPUSVN can be
> returned.
>
> I think that additional clarifications
> might be needed to mention whether the
> TEE that do not have the problems
> mentioned in the bullets - in I assume
> SGX is one of these - could use TEEP.
> In this case TEEP could be used as a
> standard protocol for any TEE platforms.
> To sum up I would like to understand:
> Whether there is a need or an advantage
> in implementing TEEP for SGX or whether
> TEEP and SGX are somehow orthogonal.
>
> </mglt>
>
> [...]
>
> 4.  Architecture
>
> 4.1.  System Components
>
> [...]
>
> <mglt>
>       A Trusted Component Signer or Device Administrator chooses a
>       particular TAM based on whether the TAM is trusted by a device or
>       set of devices.  The TAM is trusted by a device if the TAM's
>       public key is, or chains up to, an authorized Trust Anchor in the
>       device.  A Trusted Component Signer or Device Administrator may
>       run their own TAM, but the devices they wish to manage must
>       include this TAM's public key or certificate, or a certificate it
>       chains up to, in the Trust Anchor Store.
>
> The definition of Trust Anchor Store
> implicitly seems to say the TAS is in
> the TEE.  If that is the case, it might
> worth being mentioned explicitly.
>
>
> </mglt>
>
> [...]
>
> <mglt>
>    -  TEEP Broker: A TEEP Broker is an application component running in
>       a Rich Execution Environment (REE) that enables the message
>       protocol exchange between a TAM and a TEE in a device.  A TEEP
>       Broker does not process messages on behalf of a TEE, but merely is
>       responsible for relaying messages from the TAM to the TEE, and for
>       returning the TEE's responses to the TAM.  In devices with no REE
>       (e.g., a microcontroller where all code runs in an environment
>       that meets the definition of a Trusted Execution Environment in
>       Section 2), the TEEP Broker would be absent and instead the TEEP
>       protocol transport would be implemented inside the TEE itself.
>
> I am wondering if in the case of SGX the
> TEEP Broker is the untrusted application
> itself.  If so this might worth being
> specified explicitly.
>
> </mglt>
>
> [...]
>
> 4.2.  Multiple TEEs in a Device
>
> <mglt>
>    Some devices might implement multiple TEEs.  In these cases, there
>    might be one shared TEEP Broker that interacts with all the TEEs in
>    the device.  However, some TEEs (for example, SGX [SGX]) present
>    themselves as separate containers within memory without a controlling
>    manager within the TEE.  As such, there might be multiple TEEP
>    Brokers in the REE, where each TEEP Broker communicates with one or
>    more TEEs associated with it.
>
> I do not see the controlling manager
> being defined in the architecture, so
> unless that is a component we need to
> introduce I am wondering if mentioning
> that "some TEEs (for example, SGX [SGX])
> present themselves as separate
> independent containers or enclaves"
> might not be clearer.
>
> From the text I also understand that for
> SGX, each enclave is thought as a TEE.
> In my perspective I would have seen the
> enclave as a TA and TEE being the SGX
> platform, in which case I would have
> been tempted to say that SGX only have
> one TEE.
>
> There is one Agent per TEE, but it seems
> to me that having one per enclave or one
> for the platform would be implemented as
> a service provided by the platform, that
> is a specific enclave. I am wondering if
> this is how the TEEP agent is enjoined
> to be implemented in SGX ?
>
> If that is the case, and multiple TEEP
> agent could be instantiated with TA's
> selecting one of these  Agent, we could
> lean to have one agent per enclave and
> so having a TEE being an enclave could
> be appropriated. However, an enclave
> could also have more than one Agent
> which does not seem to be considered.
> Though I am not sure this really
> matters. but it seems to me clearer to
> have the Agent as part of the SGX
> platform. The Agent be whatever the TA
> has selected to complete the Agent
> function.
>
> If the TEE designates the enclave I
> would like to understand where SGX is
> represented as well as what am I
> missing.
>
> </mglt>
>
> <mglt>
>    It is up to the REE and the Untrusted Applicat ions how they select
>    the correct TEEP Broker.  Verification that the correct TA has been
>    reached then becomes a matter of properly verifying TA attestations,
>    which are unforgeable.
>
> Untrusted Applications is misspelt.
>
> I think I see the Broker as being the
> untrusted application in SGX. I am
> wondering if that makes sense and if
> there are other ways.
>
> I would also be happy to understand how
> the broker can ensure the correct TA is
> being reached.
> If "correct" has anything related to
> authentication. I would think of local
> attestation between two enclaves, but
> that seems to defy the purpose of the
> broker being a REE.
>
> </mglt>
>
> [...]
>
>
> 4.4.  Untrusted Apps, Trusted Apps, and Personalization Data
>
> [...]
>
> <mglt>
>    There are three possible cases for bundling of an Untrusted
>    Application, TA(s), and Personalization Data:
>
>    1.  The Untrusted Application, TA(s), and Personalization Data are
>        all bundled together in a single package by a Trusted Component
>        Signer and either provided to the TEEP Broker through the TAM, or
>        provided separately (with encrypted Personalization Data), with
>        key material needed to decrypt and install the Personalization
>        Data and TA provided by a TAM.
>
> I suppose that in this case the
> termination point of the TAM
> communication is the broker, and the
> broker is then responsible to dispatch
> the TA and Personalization data to the
> TEE and the Untrusted Application to the
> REE.  I believe the reason for
> encrypting the Personalization Data is
> to perform end to end communication
> between the TAM and the Agent.  I
> believe the clarification would help the
> reading. I also assume that the TAM will
> use the public key of the Agent.
> Overall I believe that this scenario
> multiplexes two sort of end to end
> communications. Some communications
> between the TAM and Broker are related
> to untrusted world while TAM or
> developer - Agent are related to the
> trusted worlds.
> I would like to clarify between
> Untrusted App, TA, and Personalization
> Data what is the final destination, what
> is encrypted and what key material is
> used.
> </mglt>
>
>
> 4.4.1.  Example: Application Delivery Mechanisms in Intel SGX
>
> [...]
>
> <mglt>
> This
>    installation is complex because the Untrusted Application decrypted
>    inside the TEE must be passed out of the TEE to an installer in the
>    REE which would install the Untrusted Application; this assumes that
>    the Untrusted Application package includes the TA code also, since
>    otherwise there is a significant problem in getting the SGX enclave
>    code (the TA) from the TEE, through the installer, and into the
>    Untrusted Application in a trusted fashion.
>
>
> At this point it seems the TAM
> terminates the session to the Agent to
> which the full bundle is provided.  As
> exposed in the section above the bundle
> may be composed of different pieces some
> of them are forwarded to the Agent
> others are left to the REE. In that
> sense the bundle could be seen as
> multiplexing different communications.
>
> I am wondering why such scenario could
> not be considered in SGX.
>
> </mglt>
>
> Finally, the
>    Personalization Data would need to be sent out of the TEE (encrypted
>    in an SGX enclave-to-enclave manner) to the REE's installation app,
>    which would pass this data to the installed Untrusted Application,
>    which would in turn send this data to the SGX enclave (TA).  This
>    complexity is due to the fact that each SGX enclave is separate and
>    does not have direct communication to other SGX enclaves.
>
>    As long as signed files (TAs and/or Personalization Data) are
>    installed into an untrusted filesystem and trust is verified by the
>    TEE at load time, classic distribution mechanisms can be used.
>
> <mglt>
> Some
>    uses of SGX, however, allow a model where a TA can be dynamically
>    installed into an SGX enclave that provides a runtime platform.  The
>    TEEP protocol can be used in such cases, where the runtime platform
>    could include a TEEP Agent.
>
> I am not familiar with the term runtime
> platform, but I suppose that the Agent
> would be an Intel specific enclave.
> If that is correct, I suppose this
> enclave would be shared by all TAs. I am
> wondering if that is what is meant by
> the text ?
>
> </mglt>
>
> [...]
>
> 4.5.  Entity Relations
>
> [...]
>
> <mglt>
>    At step 3, a user will go to an Application Store to download the
>    Untrusted Application (where the arrow indicates the direction of
>    data transfer).
>
> The arrow direction might be indicated
> in the figure or with the first arrow
> being represented.  In that case this
> may correspond to the certificate
> provisioning.  It seems to me - unless I
> have missed it
> - that certificates provisioning is
> missing. If so this is clearly a nits.
>
> </mglt>
>
>    At step 4, since the Untrusted Application depends on the TA,
>    installing the Untrusted Application will trigger TA installation by
>    initiating communication with a TAM.
>
> <mglt>
> The TEEP Agent will interact
>    with TAM via a TEEP Broker that faciliates communications between a
>    TAM and the TEEP Agent in TEE.
>
> facilite maybe that is facilitate. This
> is a nits.
>
> </mglt>
>
> [...]
>
> 5.  Keys and Certificate Types
>
> [...]
>
> <mglt>
>    Figure 4 summarizes the relationships between various keys and where
>    they are stored.  Each public/private key identifies a Trusted
>    Component Signer, TAM, or TEE, and gets a certificate that chains up
>    to some trust anchor.  A list of trusted certificates is then used to
>    check a presented certificate against.
>
> I have the impression so far that TEE
> has not been involved into any
> authentication.  I suspect that TEE and
> TEEP Agent represent the same entity. If
> that is correct I think that would worth
> some clarification why we can use one
> for the other and why we need to have
> two distinct entities that share the
> same identity.
>
> </mglt>
>
> [...]
>
>
> <mglt>
>
> 5.2.  Trust Anchors in a TEE
>
>    A TEE determines whether TA binaries are allowed to execute by
>    verifying whether their signature can be verified using
>    certificate(s) or raw public key(s) in the TEE's Trust Anchor Store.
>    The list is typically preloaded at manufacturing time, and can be
>    updated using the TEEP protocol if the TEE has some form of "Trust
>    Anchor Manager TA" that has Trust Anchors in its configuration data.
>    Thus, Trust Anchors can be updated similar to updating the
>    Personalization Data for any other TA, as discussed in Section 5.1.
>
>
> I am wondering if the current SGX does
> not have ANY key in its Trust Anchor
> Store as it simply validates the
> signature of the code at the
> instantiating (EINIT).
>
> It is a bit confusing - at least to me -
> at that point what are the roles of the
> Agent versus the TEE. It might be a
> consequence of the previous questions I
> asked myself that confused me.
>
> </mglt>
>
> [...]
>
> 6.2.  TEEP Broker Implementation Consideration
>
> [...]
>
> <mglt>
>                            Model:    A      B      C     ...
>
>                                     TEE    TEE    TEE
>         +----------------+           |      |      |
>         |      TEEP      |     Agent |      |      | Agent
>         | implementation |           |      |      |
>         +----------------+           v      |      |
>                  |                          |      |
>         +----------------+           ^      |      |
>         |    TEEP/HTTP   |    Broker |      |      |
>         | implementation |           |      |      |
>         +----------------+           |      v      |
>                  |                   |             |
>         +----------------+           |      ^      |
>         |      HTTP      |           |      |      |
>         | implementation |           |      |      |
>         +----------------+           |      |      v
>                  |                   |      |
>         +----------------+           |      |      ^
>         |   TCP or QUIC  |           |      |      | Broker
>         | implementation |           |      |      |
>         +----------------+           |      |      |
>                                     REE    REE    REE
>
>                        Figure 5: TEEP Broker Models
>
> I am wondering if TLS could be included
> into the TEE.  It is correct that I do
> not envision TCP being in the TEE.
>
> </mglt>
>
> [...]
>
> 6.2.1.  TEEP Broker APIs
>
>    The following conceptual APIs exist from a TEEP Broker to a TEEP
>    Agent:
>
>    1.  RequestTA: A notification from an REE application (e.g., an
>        installer, or an Untrusted Application) that it depends on a
>        given Trusted Component, which may or may not already be
>        installed in the TEE.
>
> <mglt>
>    2.  UnrequestTA: A notification from an REE application (e.g., an
>        installer, or an Untrusted Application) that it no longer depends
>        on a given Trusted Component, which may or may not already be
>        installed in the TEE.  For example, if the Untrusted Application
>        is uninstalled, the uninstaller might invoke this conceptual API.
>
> I understand Unrequest as being
> equivalent to undo, or remove or
> uninstall. If that is correct, I am
> wondering if there are any reasons for
> non calling it remove or uninstall ?
>
> </mglt>
>
> [...]
>
> 7.  Attestation
>
>    Attestation is the process through which one entity (an Attester)
>    presents "evidence", in the form of a series of claims, to another
>    entity (a Verifier), and provides sufficient proof that the claims
>    are true.
>
> <mglt>
> Different Verifiers may require different degrees of
>    confidence in attestation proofs and not all attestations are
>    acceptable to every verifier.
>
> the last verifier should be Verifier in
> my opinion. If that is correct the nits
> appears at multiple locations. This is a
> nit.
>
> </mglt>
>
>
> [...]
>
> 9.  Security Considerations
>
> 9.2.  Data Protection
>
> [...]
>
> <mglt>
>
>    The protocol between TEEP Agents and TAMs similarly is responsible
>    for securely providing integrity and confidentiality protection
>    against adversaries between them.  Since the transport protocol under
>    the TEEP protocol might be implemented outside a TEE, as discussed in
>    Section 6, it cannot be relied upon for sufficient protection.  The
>    TEEP protocol provides integrity protection, but confidentiality must
>    be provided by payload encryption, i.e., using encrypted TA binaries
>    and encrypted attestation information.  See [I-D.ietf-teep-protocol]
>    for more discussion.
>
> There is also the case where a session
> is established between the TAM and the
> Agent.  If used this would require HTTP
> to be in the TEE.
>
> </mglt>
>
> --
> Daniel Migault
> Ericsson
>

-- 
Daniel Migault
Ericsson