TEEP BoF Chairs introduced themselves. Hannes began an overview. Background covered various form of isolation. Software environments would receive additional code reviews. TEs that sit along rich execution environments 10,000 foot view includes Rich OS/Linux in the REE and trusted apps and oses in the TEE all sitting atop a hardware platform. The terminology comes from other organizations (The Global Platform) Example: a banking application would want to have access to certain certificates. Maybe there is a "trusted UI". This is in home routers and even in the Raspberri Pi This is a bit more than just a smart card function The concept extends to the bus and peripherals. There is a defined message passing interface as an API to transition internally within the CPU and software stacks to get between different environments It is this transition that is particularly important for this BoF The concepts have been worked out, and hardware manufacturers have developed chips that support this architecture. But provisioning software in this environment is done today using proprietary techniques. There is some fragmentation in the market. The uptake of this technology that could be used for different use cases has been somewhat limited. Wouldn't it be great if we had a standard way to install, update, and delete software? We might just need a bit of security around such a process. And so the specification has a number of security aspects Mohit: applications have to be provisioned into the TEE. I'm a developer sitting in a basement. Is it only trusted applications that can have access and what makes an application trusted? Hannes: defer to later, but it depends on the hardware. Raspberri pi is completely open. Other environments can be locked down, IETF work TBD: A protocol on the sreen is a slide containing the various entities that are reflected in the Open Trust Protocol (OTrP) using JSON/JOSE there is a bit of back and forth because the TEE needs to authenticate that it is talking to the right trust application manager. The grey arrow in the strawman uses a JSON-based encoding and that is what we are trying to define here. Kent Watson: typically an application might bundle a firmware image. Would that work here? Hannes: target market is mobile phones and tablets, because there is a lot of hardware in the field. Kent Watson: why couldn't use existing mechanisms? Chair: defer to conversation later, please. Dapeng Liu: only portions of an application are trusted, and so sometimes it is useful to update each component separately. Hannes: we'll discuss this more later Envisioned User Experience App developer uploads the app to the Google store and the trusted app to the "TAM" (trusted application manager?) The system only updates from the TAM when the hardware is there. And there is authorization involved in step 3 and 4. Hannes then moved on to the ARM TrustZone Different profiles for different use case. The BoF is mainly for high power processors, not for light weight stuff ARM then has its own terminology for some of the terms David M Wheeler (Intel) next presented remotely TEE Variations TEEs are there to provide some form of protection that is not available in the rich o/s side. As the TCB grows there's less and less trust Otherwise we would use other protections. There are reasons to want to separate particularly sensitive operations into a separate container He then ran through the list on the slides How do you prove to other parties that your code is trusted? type and capability of root of trust does it attest to just firmware or also code? Can the TEE be used to derive keying materials? Anonymity There are different types of anonymous protocols and algorithms And then David provided a list of environments they support. SGX Instead of having a secure world, you have the ability to set aside some memory, and then you have the ability through CPU instructions to establish a TEE. And it's in the same process space as the process that launched it. Intel supports the concept of delivering app along with the trusted piece. DaL Dynamic Application Loader uses a cryptoprocessor that's on the same dye as the CPU. If your code is signed by the proper key you can load applets to that environments, but unlike SGX the apps are not tied to a single application environments. Then on to the obligatory picture diagram But he nicely summarized this page without delving into detail Differences between SGX and TrustZone - load on demand via special instructions - launching process is verified by the launcher. And the launcher operates, in effect, as the "TSM". Current architecture has an external TSM. In SGX we use the root of trust to derive keys for an enclave. This creates the ability to bind secrets to both the platform and the trusted app, Sometimes one needs a small O/S to arbitrate between apps. SGX provides that separation by default. Certain protocols are required in order enable sharing between enclaves. The point is that there are very different models that we might wish to acccomodate with this work Attestation can provide complete anonymity to the application being attested. Then what of the charter? Supporting different types of TEES as well as multiple both cooperating and non-cooperating TEEs. Privacy is important Must support validation of TEE trust by cryptographic means There may not be a need to have an outside manager. Eliot Lear asks David: there may or may not be a need for external services, can you expand on that? David: in the case of SGX, trusted app can be embedded in the untrusted application and delivered as one group to a platform, current infrastructure and protocols from today can be used For certain other TEEs a trust protocol may be helpful. Even though we can point out cases where a protocol ISN'T necessary, having the uniform protocol is still a benefit. Dapeng Liu Use cases Use case 1: Payment In China there are a lot of mobile payment applications. The banks provide the apps and the users can just use their phones. 3rd party payment providers may also have autopay services that run on the user's phone. We need better and more secure ways. We're looking for ways to use the user's fingerprint in a secure way. Why not use phone applet? We need a standard protocol that can operating between different layers of the ecosystem and can address different types of the TEE technology. Part of this use case involves a secure keyboard application. Enterprise Authentication BYOD is very popular, but some enterprise applications may be sensitive, that include credentials. How to provide isolation in this case? Enterprises need a simple way to install/update/delete the trusted applications without the help of OEMs. TEEP Architecture Mingliang Pei (Symantec) Starts off by asking who has seen the draft. A few hands Then a nice marketing slide intended to describe the ecosystem. There are a few high level decisions: - Use a PKI (manufacturer-provided kesys and trust anchors) - Start with JSON because it is "light weight" and standardized. - We introduce an OTrP Agent in REE to relay messages through a standard API. Device has a single TEE only Then an architectural overview diagram Who gets to update the trusted environment? User gets to decide or ... Next slide Messages are signed and encrypted end-to-end We only need to define trust establishment information; how messages are delivered via a network between rich and TAM is not necessary to standardize. Next a slide on keys What keys and certs are needed in which part of the solution. Different regions may use different CAs for for different SPs The protocol specifically defines trusted messages Relationship diagram Protocol flow with a swimming lane diagram 3 phase diagram Flows allow for signing and encrypting of applications. Creates a secured domain for a given service provider Device decrypts, verifies images, and installs the app. ++++++++ Ben Kaouk: TE and TSMs have private applications where the user can't see what's going on. That leaves open the possibility for a privacy risk. Mingliang: Trusted Application Manager has the scheme to deal with this and privacy was an important part in the protocol design. PHB: All I want is the ability to do a private key operation. Going beyond that doesn't get me much? Doesn't want a full Turing machine Mingliang: Good point [on no need of Turing machine and lightweight trusted application types]. there needs trust apps, and types of trust apps doesn't need to be a complete heavy application as Dapeng mentioned earlier in the use cases. Hannes, responding to Ben: these privacy concerns show up at different levels. Attestation releases information by design. There are mechanisms to avoid linkability, but there are some pros and cons for each mechanism. We should discuss more on the list. To PHB's point: we have come up with these technologies because there is a demand for features more powerful than a SIM card. For example: trusted display, trusted input. These were specific hardware components that people have demanded. In the IETF we don't work on hardware, but having an understanding of the purpose and limitations of the hardware is useful. Yaron Schaffer: how viable is this? Google and others want to have very tight control on your device. Mingliang: there are multiple app stores, and there are some trusted applications. There are already existing practice by some TAM vendors who distribute trusted apps outside of Google app store. Hannes: we are working with some companies to prove that this is not just a research exercise. There may also be some networking use cases, maybe with (for example) I2NSF. Erik Nordmark: the various documents should be openly available. Mingliang: protocol is a draft. Erik: are there other things that people would need to have access to to implement this? Hannes: for specific hardware you might want some additional code and documents, and he pointed to some of the documents. One would probably use a [device specific] SDK. Erik: but we might need the information in order to properly design the protocol. Erik: what is unique about this protocol that could be used to updating TEEs versus other enviroments? Would it be capable of updating other environments? Hannes: could be used for IoT firmware update, and we need an application layer security mechanism. Attestation doesn't quite match with some of the other cases. Hannes: we replace the whole image. Hannes: looked at linux distribution mechanisms, but no attestation concepts. Chris Nasio, CMU: a lot of shared concepts from TPM. I've never seen a CA that validated my TPM chip? Who's going to do that? Mingliang: that's a provider question. This defines a scheme, not who plays the roles. Lots of talk about Qualcomm Chris Nasio: you are asking for a substantial financial commitment associated with CA management. Has anyone signed up to write the check? Hannes: we are recommending even to our IoT vendors to use secure credentials that we recommend in general Mingliang: this is a best practice. You need a root of trust. Markus from NCSA: question around the mobile use case: might overlap with FIDO alliance that is addressing a similar problem. This is somewhat wider. Hannes: folk from FIDO should speak up ???: From the developer perspective it makes sense to lower the threshold to develop such applications. From the smartphone vendors' perspectives will it increase security strength to the users? AND the Mics are closed Tero, as chair: Does the group understand the work to be done? More people hummed yes than no but it was only by a bit. Not convincing. How many people are interested in working on this? about 14-15 people. Kathleen: We'll continue on the list.