 Hello, this is Akira Tsukamoto. I am going to talk about TIP, Trusted Execution Environment Provisioning, Implementation on the Risk 5 Key Zone and Arm Trust Zone. I have talked about similar topics at the Risk 5 Global Summit. Today, I am going to add recent activities of TIP protocol discussion at IEDF in the details. This is today's agenda. First, I am going to start from explaining what is TIP and Trusted Application and how the TIP handles on the Risk 5 CPU. Then, I will explain TIP protocol discussion at IEDF. IEDF is Internet Engineering Task Force, which is a standardizing Internet protocol. Next, I am going to talk about how we implement TIP on ARM Cortex-A first and then how moved on to Risk 5 and then recent activity on IEDF regarding TIP discussion. And at the last, I am going to show the details of the TIP message. Now I am starting from introduction of TEE. We are running critical application on any kind of device or any kind of product and what is critical application here is I am going to explain details in the later slide. We do not want to run critical application when having many vulnerabilities and we do not want to have vulnerabilities on running critical application. The reason behind the hardware is getting faster and faster and the software and operating system is having more feature and feature and all both getting complicated. So how are we going to mitigate the current trend of issue? TEE kicks in. TEE is the way to isolate running critical application from regular OS such as Linux, Windows, embedded OS. And what is critical application? In this slide, it is mostly called Trusted Application or Enclave. The word Trusted Application mostly seen on ARM related documentation and Enclave is mostly used on Intel. Most of the popular CPU architecture starting to provide TEE hardware, Intel SGX, AMD SCV, ARM Trust Zone and also RISCava has PMP extension. What is the requirement of TEE? On this hardware, hardware must have feature to isolate or partitioning between running regular OS and critical applications and also there must be API to run critical application with software support. What is critical application which I have been keep repeating is application of secure sensitive operations or operating on sensitive data. For example, payment, DRM, watching movies, authentication for example, insurance on the device or surveillance camera. So TEE makes it possible to run trusted application inside isolated execution environments. This is enumeration of TEEs on RISC5 CPU. First one is Multisone from Higgs 5, Sanctum by MIT, Timber 5 from Graz University of Technology, MI6 from MIT, it's different group from MIT and Keystone from UC Berkeley. We chose Keystone as a base to implement or deep. The reason is it's open source project and also it's actively developed. Not all open source projects are active so it's important choosing an active project. In our use case we need Linux, something which requires MMU on the CPU and also the design was modular design easy to add or deep on top of Keystone. This is how Keystone works inside RISC5, it's led by UC Berkeley. The link is on the left below, they are doing a great job, please see the detail at the link. So on the left side is showing how does Keystone boots trusted application called Enclave here on RISC5. So first, when the CPU pours on, executes binary inside the boot ROM called ZSBL here and then reads FSB from the flash which contains secure monitor and then change the privilege mode from the highest machine mode to the lower privilege mode and go to the boot loader and boot Linux. On the Linux, there will be client application called trussetup1 and trussetup2 going to be executed. These client app for the Enclave or called trusset application whatever you call it. So when the trussetup1 is executed then Keystone hands over through the Linux device driver and go through the secure monitor and start executing trussetup1 which is Enclave or trusset application inside the TEE. It's same for the trussetapp2, when the trussetapp2 starts goes through Linux device rubber, go to the secure monitor and then trussetapp2 is going to be executed on the TEE side. On the right side, it's how the hardware supporting the TEE. So RISC5 has PNP, there's a PNP entry from 8 to 16 on RISC5 and what PNP does is every single entry is able to separate physical memory address and limit access to specified region. So on the example here, trussetup1 in the pink color is only able to read physical memory address inside trussetapp1 region. Cannot read Linux region, cannot read secure monitor region, cannot read trussetapp2 region. And trussetapp2 only could read inside their own physical memory address. Cannot read Linux partition, cannot read trussetapp1 region, cannot read secure monitor region. PNP have many features, it's not that simple but if I really simplify the explanation, this is how it is. Now I would like to explain how the trusset application used and why we need it. For the beginning, the target devices are smartphone, IOT or H devices. For example, network attached storage, NAS, H router, Wi-Fi router, automotive refurtenment unit which is in the dashboard, setup box from cable company or Chromecast or Apple TV is one of the setup box from internet setup box and surveillance camera, multifunction printer which is combination with scanning feature, copying feature and printer. Another target device is datacenter which is running many guest OS. Most of the use case of the trusset applications related to payment, DRM, authentication For example, credit card app, PayPal, Netflix, cable TV setup box, mobile phone from operator, automotive feature, authentication, for example paying extra you will get quick charge, insurance terminal and others. And another very frequent use case is secure firmware update, none of the device want to be compromised from the vendor or service provider. So trusset application uses as a firmware update from the server. And here that slide is time server, it's going to explain the later slides. And another thing is datacenter cloud computing. Many customer of the datacenter who is hosting their web server or their service on the datacenter as a guest OS, they started to asking the datacenter vendor having a feature that technically it's impossible for the datacenter vendor is not able to read inside the guest OS. This kind of requirement is getting popular, but I am going to focus on each devices in this presentation. Well, why we would need deep standard way of managing TA from the first place. The devices which has trusset application installed at assembly line entirely use the device until the device is no longer required or until the service is discontinued and reaches end of the life. This kind of device already existed from the past. However, if you see all the use cases in the previous slide, all the devices and the server is connected to internet right now. All the features, all the critical operation is done talking device and the server through the internet. And this kind of use cases, we need T because the new use cases are updating the trusset application for the security update or adding the new feature on the application, supporting new media, new camera device or service vendor would like to install their own application to the new device. To achieve this, it requires device side and server side to cooperate each other on uniform way between many device vendor, many trusset application vendor, many service vendor. So this is the reason T is discussed at the IETF. These are three paragraphs extracted from tip draft at IETF, explaining the objective of the tip. The first sentence, managing life cycle of the trusset application, what managing means install, execute and delete. And the second paragraph is enforce the trusset application in isolated TE and cannot be tampered. And detect when the device or trusset application is tampered. And the third paragraph is what trusset application does, application components performing security sensitive operations or operating on sensitive data, as I explained in the previous slide. What would be good to have T? For example, the device vendor could be all different company, all the could be different vendors and TA developer or service vendor could all different companies, organizations and individually developing many devices and individually developing many different TAs. For example, devices in the home, surveillance camera or smart lock or devices and automotive. Many different TA developer could add new codec, new feature, security update or adding new authentication with new insurance system or feature upgrade of the device itself. And to ensure all devices and all trusset application developed by different organization, company individually to achieve secure way to install and delete and manage them. This is the benefit of the TEAP. I will explain how each component interact each other with simplified TEAP diagram. There's a server and the device. Server is called TAM, trusset application management server. In the device, there are untrusted area and the trusset area. Trusset area is TEE. Trusset area will have a TEAP agent which handles TAs. In untrusted area, normally it's running Linux or operating system and has a TEAP broker and client app here in this example, client app one and client app two. This TA client app will be installed from Apple Store or manufacturer of the device at the assembly line or service vendor bring with the USB device, store the app one to the device or for example, card dealer who is authorized to manage the device will install the app. And app one and app two is developed by different company. They're going to communicate with TAM server through a TEAP broker. And today's explanation, I'm going to talk as if TAM is initiating the procedure. However, in TEAP, all the triggers happen from the device. So honestly, it's the device sends the first packet to the server. But today's explanation, I'm going to talk as the server is initiating the event to simplify the explanation. So first how it does is app one in the device will require your own TA in trusted area. So app one will contact with the TEAP broker and then TEAP broker will talk to TAM server and then TAM server will provide the binary of the TA one through TEAP broker and through the hardware and TA going to the TEAP agent and then TA will be installed to the trusted area. For the end updating is the same procedure. When the device will not require to have the TA installed, then for example, user have finished subscribing the service or the device vendor will like to terminate the feature in the device or TAM server have finished their service on particular device or would like to update the TA, then it will notify the server from app one talking to TEAP broker to the TAM for the deletion. To grasp entire discussion at IETF among TEAP, it's spread many working group and many draft. When somebody inside the IETF internally participating the discussion required to explain entire picture, I will start from the right side of the slide. There's many working group and there's three working group related to TEAP. TEAP working group and SUIT working group and RAT working group. So pink portion is SUIT working group. SUIT working group is defined in manifest of the trusted application. The trusted application is binary whether it's application from the TA vendor or data or personal information from the service vendor. TA must be trusted or verified by the TA developer or service vendor. So that's the pink portion. What SUIT working group is discussing and defining and engineering. And the blue portion is RAT working group. Service vendor will not like hardware being tampered. So hardware vendor will like to attestate hardware is not tampered and also TEAP side is not tampered. And that is how to conduct the authenticity of the TEAP device is discussed in RAT group. Next is TEAP working group. TEAP working group has three drafts right now. On the left side, yellow one is TEAP architecture draft, blue one is TEAP protocol draft and green one is TEAP over HTTP draft. So what each does is yellow portion defines each component in the server and the device the role and what they do and requirements. So the SAM server is a yellow and inside the device untrusted area has a TEAP broker and app one, TA clad and the TEAP side, TEAP agent and TA one. So requirements of all these yellow components is defined in the TEAP architecture draft. And the blue draft, TEAP protocol draft only defining the message format between the TEAP broker and time server. So that's only it does. And another thing is TEAP message is encapsulated on the HTTP packet on top of TCP. So that's defined in the green draft, TEAP over HTTP draft. So when starting reading each draft it's almost impossible to understand entire picture. So this slide, this page is very important to understand entire scope and discussion inside the IETF. Finally I'm going to talk about initial prototyping of TEAP on ARM Cortex-A. And this prototype implementation was done in old TEAP architecture draft. So some of the word is different but I'm going to explain the differences in this slide and next slide. TEAP basically use asymmetric cryptographic algorithm. So TA developer in this slide it's called service provider. The service provider is the old word for the TA developer and TA developer already the name is changed in recent draft but I'm going to just stick on as a TA developer. What create public key and private key and also have a UUID to identify the TA. In this slide it's called SPA public key and UUID is handover to the time server. In the device inside the TE world it has a SPI private key and those who manage the time server will generate a private key and public key pair and then time server itself has a private key and the device inside the TE side will have time route certificate. Now I'm going to explain how the device work. The device on the Linux side TA client has a UUID which TA he needs. So conduct his application. So TA client will handover the UUID to OTRP broker. OTRP broker is the TEAP broker now and the difference between TEAP and OTRP is going to be explained in different slide. And OTRP broker will talk with the time server and then time server will handover the TA binary and the TA binary is prepared by encrypting TA by SPI public key. See the binary is encrypted by private key but in this draft it was using public key. So the binary is encrypted by SPI public key and then it was signed by TA time private key so it has a time signature. So this binary will be handover to OTRP broker and OTRP broker will handover the binary through the opti implementation of the SMC and go to the other side of the TE and OTRP TA will receive the TA binary. OTRP TA and recent draft will be TEAP agent. So TEAP agent OTRP TA will check the signature with the time route CA and if its verification is success and then decrypt the binary with SPI private key. So it will assure the binary is from genuine service provider and it was communicating with correct time server. Then the TA will be stored in secure storage. Once its TA is installed when the TA client is executed device user or running automatically in the device will execute the TA inside the TE for example handling payment or decoding video. That's how the entire scope runs in our initial prototyping. Finally, finally, finally, this is ongoing or current TEAP implementation on RISC file. It took a very long time to get to this slide. The slide itself looks similar to the previous page however some of the words is adopted to recent ITF draft. And another point I'm going to talk here in this slide is how we adopt our implementation on other CPU for example on ARM and honestly in this slide it says GPAPI but I'm going to explain what is GPAPI later. First we implemented the GPAPI on Intel ARM RISC 5. So we could have uniform implementation on all three different kind of CPU. The green portion is under development by AIC and Tragil and the orange portion is developed by Secom. Isobesan is also attending ITF and TAM is open sourced by Secom on the GitHub. The name is called TAM Proto and green portion is not open sourced we would like to but not yet. Moving to the details of the green components on the untrusted side which is running Linux is TAPE broker and Hello app and the TE side it's provided by Keystone project is running TAPE agent and Hello TA. Hello TA is a sample TA just printing out Hello TA that's all it does in prototyping. Before I go to the further explanation left side explains the changes in the graph from last year to this year. Initially all the message format between the TAPE broker app and the TAM server was JSON. JSON is widely used on many internet web server web browser and supported by many library however the TAPE graph have moved to using only seabor message. The reason behind is seabor could make the message size much smaller compared to JSON. JSON is text space message it's easy to understand especially at the hackathon bringing your own device and other people bringing the TAM server and if you talk each other and something doesn't go well then it's easy to debug it because it's text format with ethereal it's not ethereal now it's a wire shark. There's 4 important message one is query request query response install TA and delete TA and later the draft also install TA and delete TA is changed but I'm just going to explain what it is right now. Query request and query response some of the JSON packet was after encryption and after signature it was sometime it's more larger than 1.5k MTU size so packet might be separated to two packets. However seabor it's a equivalent message it's only about something similar to 30 bytes or 40 bytes and what is seabor? Seabor is similar to ASN1 binary text converting format it's much newly designed binary and text format definition. Another benefit of seabor is implementing seabor parser and decoder it's more lightweight from the implementer perspective. Explaining seabor is not this simple but I'm going to end it here. In nutshell seabor is designed to to adopt on edge devices which the resources of the device and the internet is constrained. I'm going to move on the implementation inside a device and the device tip broker app and tip agent is playing a big role and however underneath the tip broker app and tip agent TA is all different for Intel ARM and RISC 5 and IETF when designing and discussing and engineering and writing draft to standardizing specification if it's only going to usable on only particular CPU then the draft and the specification and all the discussion and effort is not going to be used in the world all the effort is not going to be rewarded. Now designing all the specification to be able to run on all different kind of a CPU architecture is very important and our design we already had an implementation of tip broker app and tip agent on ARM which was running on Opti and which Opti was providing global platform API. Global platform API is widely used on smartphone right now. Initially it was implemented for the setup box but it's widely used for many up trusted application is running on global platform API or global platform API like interface. So completely having a different kind of API again for the every different CPU is not optimal for any kind of R&D activity or business or service division. So when we started this project we first selected about 30 subset of the global platform API and poured it on Intel ARM and RISC 5 and then we put tip agent TA and hello TA on top of it. This is the reason on the green box it has GP API box underneath both of them. If you look the specification of the global platform API there's about more than 200 APIs more specifically global platform internal API documentation and we do not really need all the 200 API if you're going to use it for the new CPU architecture or on new tip protocol and on tip usage. The reason of having 200 is keep historical backward compatibility so global platform API could not delete old API and new APIs was keep added so that that's the reason it became over 200. What we really need is opening TA, running TA, closing TA, something a candling TA, random function, hash function and also symmetric crypto API and asymmetric crypto functions API for read write save for the TA personal data. So that's about it and about 30 API extracted and ported tip agent TA perfectly fine on top of RISC 5 Keystone. Now I'm going to dive a little more further. On the bottom it says RISC 5 RV64 GC and honestly it's SV39 is hidden and what RV64 means it's RISC 5 which has a 64-bit instruction set and SV39 means it has an MMU on it. So this implement this is running on 64-bit RISC 5 with MMU on it. Above it's written SM Keystone. It's a secure monitor which is customized with the Keystone project. Secure monitor itself for the RISC 5 has open source as a reference implementation. Keystone project customize the reference implementation so Linux side is able to hand over secure way with using PNP with the tip agent TA and hello TA separately. That's why it's not just a regular reference implementation of the secure monitor. And above that on the right side it has a Keystone runtime. This is what Keystone project make it easier for us. Keystone runtime is replaceable so in our implementation we use GP API wrapper and implement a tip on top of it but you could just replace this layer and run well-known secure OS sell for on Keystone. Another important aspects here is component design. Tip agent TA and hello TA has a dot vertical line because it's separate with the PNP. That means if you're using property license software if you have a GPL license software it does not affect each other between the PNP which has a context switching through SM. This is very important because most of the business usage for example payment application video decoding application likely to have closed source application. I will explain how the discussion is happening at IE diff. My understanding is historically IE diff had about three meetings in a year and also have a mailing list. Those places are the main discussion places. When you want to talk face to face talk at IE diff meeting and everything else is going to be discussed at the mailing list. Mading is a public mailing list and recently IE diff meeting started to have a hackathon at the same time. For example in an RTIP working group we brought TIP device R implementation of a TIP device and they've data from Microsoft, Hannes from ARM, Isobesan from Sycom is bringing their time server and conducting talking device and time server each other and finding the issues or improvement item and reflect to the discussion and reflect to the draft and recently we have a very convenient to GitHub all the draft of the TIP to move to GitHub and using as a communication tools. I would like to show the communication in the mailing list. In this slide the bottom portion is the discussion at the mailing list. In the center is my email posting CDL format of the TIP message proposing would this be okay for the draft. Discussion at the mailing is purely technical. The culture of the mailing is an open source is pretty similar. Bringing my experience of the open source mailing list culture to the IE diff mailing list worked pretty well for me. These are example on the GitHub. For the TIP working group all three drafts have moved to GitHub in this year. It's becoming similar to open source project when you have a question or discussion file as an issue and iterate the discussion until get to the conclusion and make a pull request to revise the draft and if it's okay it's going to be applied. This is how the draft is updated right now. On the left side of the slide is my pull request fixing the hex decimal representation of the seabor message. I was converting text message to hex decimal by hand assembling and made a little bit of mistake revising many format and recent activity. My experience long time ago hand assembling and disassembling paying off right now. On the right side is a pull request adding seabor message examples. In TIP protocol originally TIP message had six message query request query response install delete success era and this was the pull request to add exact seabor text format and binary format in the draft and that's something I am going to talk in the next slide. This is my fun part. This is exact seabor expression in the binary and text. On the bottom right side is a hex decimal representation. Higgs decimal is starting from 0x8 then it's RA. If it's 0x8 it's a map. If the number is smaller than 0x17 then it's integer. If you repeating hand assembling and disassembling started to memorize the contents by reading the hex decimal. I don't know it's a good thing or not but yeah. On the left side seabor diagnostic notation it's it's meant to make it similar to JSON in human readable format. The left side is perfectly in text format. However you may know this but reading the left side of the text format itself is not that easy to understand meaning of the number on how to construct the seabor message. So on the top is concise data definition language CDDL and this is the format mostly used on the dietiff draft. It's easier to implement the tip message on seabor. This is my procedure. Reading CDDL, writing an imagination in my brain of the seabor diagnostic notation and then hand assemble hex decimal on the paper. Try the implementation. After converting to hex decimal you might find improvement in the draft. Something is missing. Something is not easy to understand. Some entry is not used and then you're going to the mailings or github suggest the improvement and making the tip draft better. This is how improving the tip draft. Alright this is the last slide. So this is the summary of the recent update around dietiff 1.0 i in November. We had a hackathon and we changed a lot. 1, 2, 3, 4, 5, 6 is 6 summary I picked up. So the first one is adding a seabor representation and binary example in the draft. When implementing the device and the time server and the communication does not work as expected it's really difficult to debug with only text expression in the draft. Having a binary is very crucial to nail down mismatch and improve the compatibility. Second one is yes. Entirely, entirely today's all the talk I have explaining that critical application the name is trust application trusted application suddenly changed the trusted components. The reason behind this any binary we see from the time server to the device does not always contain application only. Sensitive data only is perfectly fine. To make more intuitive to have the only data message itself the name have changed trusted component. So TA is going to become TC from on. Well it's technically reasonable. Having a ID for the TA I know that TA became the TC in the tip draft but I'm I going to talk as a TA in this presentation. TA needs the ID so the device side and time server side could distinguish which TA binary is required in the device. We had many discussion as a temporary solution I was using new ID and our implementation to distinguish the TA. However, now we officially came to the conclusion that we're going to use a suit component identifier from the suit manifest. Inside a suit manifest we're going using suit digest as a suit component identifier and here it's component ID which was TA ID. In the initial design of the tip message was when time server send the message and reply come from the device distinguishing the which message came from which device will use token. That was the basic design. However, one of the message in the tip message where request likely to be the same for the all devices which time is interested to handle. Then the token in the response message is useless because only makes sense if the sending message is different for each devices. So it's valid suggestion. It was suggested from Isobesan from Secom. It's not only not necessary if the person who is just reading the tip message draft and was not participating the discussion at IETF or reading other draft may misuse the token for the other purpose. For example, using a token for the TA ID which is a bad practice for the security reason. Always decided to change the token as an option entry instead of mandatory entry. And next is the all situation the TA is not needed. TC is not required in the device anymore. Server service might end it. User of the device decided to stop using the feature or the TA is outdated. When device notifying the time server which TA or TC going to be deleted, there wasn't entry to notifying to the server. We wasn't clear how to notify the TA to delete in the device to notify to the time server. So now we have the conclusion we're going to use unneeded TC list to delete the TA, TC. And the last is, suit manifest is embedded inside the tip message. However, initial draft was having a separate binary entry for the each manifest entry. This is the suggestion from the Repitam working with us for the implementing the tip device. And combining all the suit manifest and one binary string B string and the C bore format is much reasonable and much easier. We decided to use B string C bore for the SIP manifest list. This is the summary. I introduced basic TE concept and importance of TE for critical applications and operation of sensitive data. Modern CPU architecture supports TE. And how TE on Risk 5 with Keystone works? ITF is designing and standardizing tip for unified way of controlling TA on different devices and servers. Relationship of three tip drafts and three different working groups. Status of current development of tip on Risk 5 and having GP API made porting tip from ARM to Risk 5 easy for us. And the way of ITF discussion style, C bore representations and binaries and recent changes. To whoever would like to deep dive, please click the link. I really appreciate any kind of feedback on tip draft or tip related working group from the today's presentation. Thank you.