 Hello, this is Akira Tsukamoto. I'm going to talk about the TIPA protocol to provide a software supply chain, not only for software supply chain, but one of the use cases is software supply chain. And this consists with some of the few working group in IETF, so that I'm going to start from mini background. But the main reason I'm talking today and now I was, today is the, I was able, or we were able to upload the implementation on the GitHub and the right side. This is the documentation and which is generated from Turkish Gen and the left side is implementation. So there's the implementation it has all the procedure for the how to get the sources and how to build and how to run it. So if you have any problem, please let me know and how to run the implementation has two ways. One is using a Docker, which is easy and it's use the QMU, so you don't have to have any special hardware other than your laptop or PC. And another one is using a real hardware development board for the Intel ARM and RISC-5. And also it has a wiki page explaining some of the pages which I'm going to talk today. And this is my microphone, okay? Yeah, I think I need to hold it like this. Wiki page, so if you, other than there's more documentation on the wiki page, so if you would like to see the link in the later time or something, please go to the wiki page. So now this is the introduction of the TIP protocol at the IETF activity. This is the overall diagram and which is something I'm going to explain today. And what is IETF is it's engineering organization for making us doing engineering activity and making a standard for the internet protocols. For example, historically TCP, UDP, whatever it's using on the current web browser, it was related to IETF or W3C, our organization. And recent famous protocol was the HTTP3 at IETF which used to be called QUIC. Initially, they started as a called QUIC. And today I to talk about IETF, the problem is TIP consists of other working group activities. So I have to talk about SUIT and RATS. So TIP is the abbreviation of a trusted execution environment provisioning and SUIT is called software update for internet of things and RATS is a remote attestation procedure. And who is the audience of these working group activities? It's not only this, but the one it's easy to explain for me is the vendor who developed the product with a CPU or SOC which requires software update or customization which is a typical embedded company or there's a use case for the data center or for the cloud computing, but that's going to be covered somewhere here. And how it's different or what it's doing at IETF is going to be explained in later slides, but basically there's a server maintaining the software and data in the device, target device and how it provides it is by before sending any of the binary from the server to the embedded device or IOT device or whatever you call it is checks whether the device is compromised or not and if it's okay, then it will install the binary to the target. And confidential computing, I'm not going to talk about this much, but it's also, it's recently going to be important for the data center who is the company or user who wants to have your virtual machine hosted to the data center, but you do not want the data center host machine to be able to read inside the guest machine. And okay, so what's the difference between TPSU rats? This is, yeah, I'm going to explain this in later here, so and how it's related to, with the software supply chain itself is software supply chain, many have different kind of the, many people have their own definition. So when I started engineering like 2002 or 2001, software supply chain is typically it's a package maintaining like DAB or IPM and you have a version number and if one of the packages have a bug, you need to replace it with a new Debian package or RTAT or RPM. And you could do this with the TIP, but it's more, the TIP is as a how to send the binary between the server and the devices with the secure manner. With the people who is talented with the internet protocol, with the cryptography and the security subject. So in the skip, there's another working group called SKIT and it's a user rats and Kosei working group activity and defining format for the SKIT working group. And it's difficult to sometime it's how, what's the use cases without just reading it's draft. So I just listed some of the list I came up. So trusted application is typically kind of payment application like a credit card application used on the tablet or app iPhone or automotive or on the dashboard or DRM like Netflix. And some of the Intel SGX implementation was the BD player on the Intel machine and also it's the conducting former update. And personalization data is just basically both as just the binary and the tech for the engineering point of view. But it's a yes, like a device authentication or unlock unlocking the hardware feature which is already installed with the hardware but you just need to unlock the feature then you need some serial code coming from the server to the device. And yes, and yeah, too many ITF acronyms. So the format of the suit is using called CBOAR. And CBOAR is concise binary object representation which is and how to use that format for the authentication and encryption is called COSE. So CBOAR is like signing and encryption. So signing and encryption is using with the CBOAR. And what's the difference in the path is in the internet protocol, there's two type of the packet. Whether it's tech space or binary based. Tech space is like similar to HTTP or JSON. The famous one is JSON. And there's a binary one is typically it was like zero to 13 bit resist representation with the binary is one of the way of the used in the internet. But another one is ASN.1, the format anybody remember ASN.1, it's still widely used for the certificate. And the ASN.1 is tend to, the CBOARs tend to be replacing JSON expression in the binary. So that's the simplest way of the explanation. So it's very similar to JSON for the programmer, but it's converted from tech space to the binary. Okay. And yes, now, and then I need to explain many things, but there's a verifier is a component which handles the remote attestation in the rats working group, which is going to check whether this device is compromised or not by hacker or intentionally or unintentionally. And time is the server who is maintaining the software and data inside the device. And honestly, in this example, it says TE in which is called hardware is expecting to have a TE hardware, which the famous one is inter-SGX, recently is TDX and another one is ARM trust zone and risk five has PNP and also World Guard. But honestly, the protocol what we define in the IETF does not regard hardware implementation. It works on any of the implementation if it's similar features, is they able to implement in this hardware or software, it does not matter by reading the draft. And so this is something I'm going to come back later, but basically, yes, the hardware itself is you could run Intel ARM or risk five and make the implementation simpler for my project. I made a wrapper implemented called TRF and then implement the deep protocol inside as a deep device project. So now it's going to explain the interaction. Is my time okay? Yeah, it's about 12 minutes after. So this is the interaction between the embedded or the target device and then the server and the verifier. So it goes down a few sequence with the packets. So initially device will send up the HTTP or HTTPS packet with no information inside. And the server time will receive the packet and will recognize that device is willing to accept the new software or new data. And the time will ask to the device, what is your, typically what is going to ask is what is the device information? For example, is it a phone or whether it's a BD player or whether it's a real IoT machine or which company, which version or in which hardware and also ask what kind of software you already have and what kind of version you already have. So the server could destroy with whether you need update or you're missing some of the software you want in the device. And another important information going to be send it from the devices. It's called evidence in the rats working group. It's a boot log of all the secure boot hash and the single signed history. And that will be sent with the packet with a three and then that inside the packet three only the evidence will be passed to the verifier. And verifier is typically owned by the vendor company who developed the device. We'll check the hash value and also the order and whether all the binary which was booted on the device was successfully verify the signature or not. And if it's everything is looks okay, then they will reply as AR is called attestation report or result. And that will be telling the time server whether you could trust this device with it's not being hacked or not. If it's okay, then the server will send the software or data in the binary format and the suit format to the device and then they're going to conduct install, install update and then reply the result. So that's very easy way of explaining about the T protocol procedure in like two minutes. But I'm honest, if you try to understand this by reading all the internet drafts it going to take like two days or something. So like just listen to this. It's what two minutes is very good. And I think I already explained this here. Well, as if, as you know in this previous slide many of the information or specification is in scatter all over the places like in tip working group and suit working group and rats working group. So you have to read a few other drafts to understand this. Well, it's trying to just trying to make it easy to explain in this project for the presentation. And this is the, I don't think I don't, I think I'm going to go deep dive here for the explanation, but this is the one of the implementation and our implementation how we implement the T protocol on the, this is on the risk five CPU and this is for the ARM CPU. So many people here might understand that ARM trust zone and it has one of the open source implementation on trust zone is OPTI from providing by maintain, maintain and develop by Leonardo now. It's a, it has a Linux running on this side and secure world running on this side. And to make the implementation simpler, I will we implement the tip protocol as a tip agent T trusted application here. And if you, and if the server wants to install the application, this example is installing dummy trusted application just print out hello world, hello tip. And another one is Intel SGX. This is, yeah, Intel SGX, it has a special kernel SGX driver and it has a SGX runtime. And then we to make it easier to implement to run the same hello TA, TA source code, we made a wrapper application, a wrapper layer here. It's talk about almost identical API as the what OPTI provides, which is a subset of the global platform for the R usage. And then it's going to execute hello tip TA here. And pretty much the same for the risk five, it's, yeah. And there's two, 13 minutes. And on, so another question I frequently being asked is propriety almost identical procedure is done even the Windows update and also Nintendo switch or game console or television or like Google TV or something. And why you need to make a standard at IETF or something. And so, so, yes, at IETF, like for example, yeah, it's listing four or five example here, but basically if you listed, make some standard in one particular organization, which is everybody's using on the internet because most of the devices being connected to the internet recently, then everybody could do the cross vendor service with the same protocol. And also it makes it easier to not to get into the pitfall for missing some of the implementation and missing some of the security hole or something overall design feature. You just, we're listing from all the people's expert and in the organization with their expertise to fix and improve stuff. And yes, I think I'm going to skip here in the details, but basically some of the assumption is on the implementation and also on the draft is assuming some of the other stuff is done by yourself in the device, for example, Secuboot, and also has equivalent library for the signing and the verification and also encryption for if it's servers or PC, you could use OpenSSL or Embed TLSL or Wolf FSSL or equivalent feature in the device, okay? And this is another slide with the use cases. This is, I guess this is automotive one. So yeah, what kind of the application and data is done by TEEP and RATS and SUIT and SKIT is, yeah, OTA, entirely updating this firmware is one way if you want to do it that way. What it's possible doing by sending one RPM or one device, one Debian package, but for a small device is doing with OTA probably the way what's typically happening and unlocking hardware feature or remote monitoring or remote telemetry acquisition. And use case for the network equipment, for example, most of the company, what Cisco, Juniper and those company work is periodically they need to update the CE certificate and also you need to update the device firmware and it's very critical for those devices it's not being compromised with a hacker. So they do care about the device not being compromised and if it's due, then they need to take some of the action. One of the way is just stop working, which is easy to implement, but most of the time require a little bit more of the imagination. And this is home security. This is some of the home, like easy example is home surveillance camera. Typically contracting the security company and the service person come to your home and set up the camera and stuff and then install the software and then activate the device is you could do that with the tip. And also if it's, if somebody is compromising the surveillance camera or something it's good to be it's being non-functioning anymore. And these are similar way with the power plant and with the similar way with the drone and the confidential computing is, yeah, it's if the VM is, if the VM is with a hacker hardware feature from the CPU, typically it requires a CPU. If it's the hard version machine, guess always it's not able to read from the host machine. Yes, it's possible with the tip protocol. Honestly, this is only written as a use cases, one of the use cases in the draft and nobody really have done the implementation yet. So if anybody wants to help, we really welcome. And this is the status at ITF. Most of the activity for the engineering on the tip draft is almost pretty much finished. However, as I explained this, like starting the draft starting from rats and suit and also it depends on the course and other draft, it's almost there but it's not completely finished. But it's expected to be reasonably, it's already reasonably stable situation status of the draft. So if you're really, if you're going to read the draft right now and you think it's going to be worth it because it's going to be being updated hugely in the future, no it's not. Probably it's more, pretty much it's stable. So if you're going to read the draft based on the explanation from this slide, pretty much it shouldn't matter much. And here from really engineering stuff. I hope it's not too deep dive but it's one of the difficulty why I was working on this project was the new text to binary and binary to text conversion format called CBOAR because I knew how to do it with it. Jason, you really do not have any conversion with the text format and HTTP was easy like two or two okay or four something 200 okay or four or four error or something. And now it's CBOAR it's then I started where it's a little bit of a old history for me when I was dealing with ASN.1. I did not have a good image of the ASN.1 as implementer's perspective but it's easy to make a mistake and have a buffer overflow and making a security bug. And how, so I, most of the energy I spent in 2020 when in 21 was understanding CBOAR because when I read the draft on the CBOAR draft, yes I'm not a compiler person, I'm a programmer so. And so this is some of the knowledge I picked up. So there's a CD deal is the description. It's written how to write the Jason like description. And from the CD deal, if you, before you make a binary packet, you need to write it down to CBOAR diagnosis notation and then pass it to the CBOAR parser. Then they will become a binary. And how does it go is, yeah I took from a little old slide so it's some of the few little bit of Japanese here but pretty much I wrote it down, wrote it in English here. So this is the CD deal. It says query request format going to have a type and the option is the this, what do you call it, method or lines or something. Token, selected Cypher suit, selected version and et cetera. And how to write it is the type is written on the right side and each of these whatever token or is in this example here is using 20 as a token and Cypher suit is selecting, putting five one in the here and zero for the selected version and something. And this side is a diagnostic notation which is you need to find from CBOAR draft but in this, when I first write this draft I was converting by hand but there is a website. It's able to convert it from this number in the JSON like format to the binary. But how to understand is if it's 20 and the hex decimal representation is going to be, oh yeah, token in the binary size and this is, I don't know how much was, I think this was 16 bytes or something. Where's the 20 is the map of the describing that this is the token. That's how you read it. I think I talked too much too quick but yeah. If anybody have a question of a CBOAR please ask me later. And so this is the binary and binary you could decode if you would like. So if it starts from 82 it's array and if it's two means probably two is a deep query request number two is probably here, yeah, two type of request. And if it's five it's a map and they have a map, contents of the map here, list it here. And so if you purely convert this text format to the binary with the regular string it will be similar to 266 bytes or something like that. And if you use, if it's CBOAR it will be, in this example it's about 36 bytes. Good thing is binary is smaller but the bad thing is if you doing the debugging the development, typically people use the wire shark or ether rear or something. And JSON is easier to more debugging because it's just text plain. And this one, yeah, there is a plugin for the wire shark right now but I think so but initially I thought it was to just capturing this and then hand the decoding here and then read it. But yeah, old school people have a way to do this when they, some of the people who experienced the 80 binary hand assembling. And these are the examples. So deep message, so CDD expression, no, there's no notation, for example, 120 and 11 or 30 or three. It's a typical, it's a JSON format. It's going to be like this in the CBOAR presentation. And the suit, yes, I didn't explain much about suit. Suit is, TEEP is explaining about how the server and the device or the target machine or target PC to interact each other in the internet protocol and how, but TEEP suit is defining the binary format. So the most of the format written on the TEEP is from suit message format. And this is how, like for example, signing explanation and this is the binary representation. And is that all? Yeah, I think that's all. So I think about 10 minutes for the questions. Anybody, anybody question, yeah. Mike? So you mentioned earlier that there are a lot of reasons not to use existing like commercial offerings that are closed source. But there are also offerings from this, from Linux Foundation projects that are open source community projects, widely used that have stronger security models than a lot of the building blocks you use here. Is there a reason why you're using like protocols that have weaker security that are IETF as opposed to using things that are in the Linux Foundation? Honestly, IETF and Linux founders is not competing each other or anything. So if you will, IETF, please, if it's, if you see something is anything is weaker and security or something, please give us a feedback then we could improve the draft. And also IETF itself is not against proprietary implementation or try to overrun everything with the open standard or anything. Because use case, some of the use case, if it's already working, if you really don't need to change it, or then it's fine. So if you, some company is, or some new product, if you want to focus on multivander supporting to the across the inside the boundary of the company or specification, then that's easier to refer the deep protocol and suit and rats. And even some of the, I don't know in our Western company, when I was working in Japanese company, they have many division which do not talk each other. So going to the upper external organization and sharing the information was easier to make a product. So that was one of the use case. So if there's not a question, I think I need to talk a little bit more about the secure boot hash here, here, on some of the example. So magically just sending some of the data to the verifier from this example will not easy to check whether the device is compromised or not by hacking, by intentionally or unintentionally. So what we really need is when the device boots on, typically boots from the start from embedded device, typically boots from ROM. So ROM will verify whatever the binary, it's inside, typically it's SPI North Flash and verify that binary with the, typically it's a symmetric key in the beginning. And then if it's that, the binary is safe, then checks the binary of the boot loader and that binary is confirmed, it's not compromised with the verification. Then typically from somewhere from boot loader, it starts to use a symmetric algorithm and then loading the kernel and doing the same and then going all the way up. And those chain must be stored as a file or it doesn't have to be a file as a format and then in describe in the rats format and then send it as an evidence to the verifier. Then the verifier will be understand whether the exact version of the OS or hardware or the application on top of the OS or if it, even the device which does not have an operating system, then still it's going to be able to match whether this needs little missing some of the feature to customize the device or install the new feature or the version in the devices need to be updated. And yeah, and also some of the many of the CPU and currently in the market do not have the TE capability. So if you, it's fine using adding the HSM or TPM chip and doing the similar information sending all the way to the verifier from the TPM chip. I have a one question. Yes, thank you. What organization or companies involved this IEGF activity? Yes, Microsoft initially was Intel and then ARM and mostly I was doing from for the risk five part. Yes. Okay, thank you. And Symantec and Rotocone. Yeah. So this might be slightly unrelated which, are there any like physical risk five boards that have keystone? We did running keystone on the, I think it was sci-fi and matched or I don't unleash or whichever I don't really remember but it's in the, it's in the, wait a minute, if you have the board, it should be buildable and runnable, but if it doesn't, please let me know. Thank you. Yeah. So I've heard it said that when you do like attestations over the code you're running as you go through the process you described of attesting the parts of the firmware and everything else that that only is useful if there are no bugs in any of that software and there's no issues or problems. Do you think that there are operating system kernels and other things like this that have no bugs out there? And if not then what guarantees do you really get? So yes, very, very important. So this honestly, what really talk in the IETF draft is how to interact, what kind of information you're going to pass each other and these entities. So it is possible even the operating system or whatever it is already compromised and then completely writing fake information above the fake the verifier. So, but that's something this is, it's in the draft it does not mandate how you implement it, it's the feature. So this kind of the example implementation is not we knew the person who is writing a draft this is not the only way it's the same. So you need the knowledge how to make it more secure in this implementation especially, I slightly wrote it in the draft but yes. So then the company who have visiting to IETF and talk to each other or you have an expert in the private company who could provide a better consulting, it's fine, perfectly fine. I think that's it, thank you very much.