 Oh, it's too late, so we'll use this. Oh, OK. I don't need it. I don't need it. All right. Hello? Yes, it works. So, our next speaker comes from London. It's Davide Grary. And it will speak about TPM2 on Embedit. Let's upload them. Can I turn off the lights? What are the lights? Sorry. Excuse me. Excuse me. Where is the light switch? Let's... Yeah, otherwise I don't think they... Yeah. There you are. Thank you very much. Good evening. I'm Davide. I'm a production engineer at London. And today I'm going to talk a little bit about TPM2.0 and specifically a practical usage on an embedded platform. By the way, I have the platform with me, so just to show you this. It's real small. And so the agenda is quite short because this is, of course, a lighting talk. We're going to see what is a TPM. This is a very high-level overview of TPMs. And, you know, how to use the TPM on a Minimord Max or Tarbot with a practical example. So we are going to generate a signing key on the TPM embedded in these platforms and sign a document and verifying it with OpenSSL on a different platform. So what's the TPM? TPM stands for Trusted Platform Module. Its specification has been written by the TCG, the Trusted Computing Group. Most members are AMD, Hewlett-Packard, IBM, Intel, and Microsoft. And it has been standardized in an ISO document. This is 2009 TPM 1.2, by the way, and it presently is on most computers platform, including embedded ones. And, by the way, very recently Microsoft has mandated TPM2.0 for Windows Mobile 10 platforms and is recommended for server platforms. So we are going to see these devices more and more in the future. TPM is a cryptographic processor, but it is not an accelerator. This could be shocking. Believe it or not, it's slow by design. One of the reasons, one of the main reasons why it is slow is because of import and export restrictions that are on cryptographic technology. Some countries have these restrictions, like the United States, for instance. So at a very high level, these are the modules that you can find in a TPM. So we have an input-output module, of course, cryptographic processing, non-volatile storage, and general parts post-memory. Basically, we can create objects onto TPM, like signature keys or for symmetric and asymmetric encryption, for instance, and we can make them persistent. Of course, this is limited storage, so not many keys can be stored in it. Main differences, so we have two versions of TPMs, 1.2 and 2.0 are the two existing versions, and TPM 1.2 uses RSA as asymmetric encryption and SHA1 as the hash function. So this is deprecated, although the use of the SHA1 in TPM is not affected by the recent vulnerability they discovered, and while TPM 2.0 has support for electrical cryptography and SHA2, but one of the most interesting characteristics of TPM 2.0 is what is called algorithm agility, so that means that we can add more algorithms without changing the specification, and that means that maybe with a software, with a firmware upgrade from the vendor, you can get more algorithms on your TPM without changing the platform. The main usages, three of the main usages of TPMs are summarized here, so we have platform integrity, so secure boot and trusted boot. This answers the question, is a computer platform in a trusted state, in a trusted condition? That means that we have to measure all the software run from power on to operating system up and running, and basically this is done by creating an hash for each piece of software and storing it in TPM registers. Another typical usage is this encryption, not the TPM that performs the encryption, but rather it just stores the key and controls the access to it, and DRM is another usage. There are three types of TPMs, hardware, firmware and software. The hardware or discrete TPM is a physical component, tamper proof, and it's the most secure, of course, of the three. The firmware TPM is typical on embedded platforms because it relies only on a CPU extensions named trusted execution engine. The last one, software TPMs are used just for development. Of course, they are all in user space and run on top of the operating system. So how can we use a TPM 2.0? For 1.2, the support is pretty good, I would say, but for 2.0, the software is not so mature. So in order to use it on X86 platforms in Linux, we have two options. One is the IBM implementation. The other one is the Intel implementation. There are a few differences between the two. The main summarized here, basically, the IBM implementation doesn't have the resource manager, which is the component described in the TCG specification, responsible for allowing multiple processes to access the same TPM in a time-sharing fashion. So the TSS from Intel do have a resource manager, does have a resource manager, and they are working also in internal resource manager, aimed for the kernel 4.11. Also, the Intel implementation is developed on GitHub, so I would say the development is more open and a bit more modern, maybe. Hardware. So we are talking about embedded platforms. So I have here a MinoBoard Max. So this is what I'm going to show is actually exactly the same on MinoBoard Tarbot, which is a spin-off on the MinoBoard Max. Basically, it's a dual-core Atom that supports the trusted execution environment, and so we can get a firmware TPM. The firmware TPM is not there by, I mean, with the embedded UFI firmware, but you have to refresh the firmware and the restructuring at the end of this slide. There is a link to a post explaining how to do this. It's not too hard. This platform costs around 150 euros. Of course, this is just an example. There are many other platforms that support this. So the firmware TPM in this case. Using TPM 2.0, regardless of the type, in real world is not easy because it doesn't support the tools, they held existing tooling for X86 and Linux, at least the open source one. I'm not aware of, you know, closed source implementation at the moment. It's hard because they don't support interchange format like their or PEM, and so using it with open SSL, it's not possible right away. But both the TPM software stacks provide an API. They implement what is called in the specification the system API, which can be used to build your own CSE plus-plus application. Although the specification is quite hard to digest. So what I'm showing here is pretty hacky, but of course, there are cleaner ways to do that, but I mean, it's not easy. So in order to use the minimum-bored max to do what I'm showing, we need to enable the firmware TPM, as I mentioned. We need to set up a Linux distribution. Any recent distribution will do, but you need a least-scanner 4.4. I believe 4.2 works as well, but anyway 4.4 is better. You need to flash it onto a micro SD card, boot the board from it with it, and install the TPM software stack and the TPM tools from Intel. There are pointers at the end of this presentation, so you can find the software easily. If you're lucky, some distribution like open source already have packages for these two softwares. You need to start the resource manager as a demon, sorry, and then you're right, and you are good to go. So Intel tools are modeled after a security protocol described in the CCG specification, which is focused on TPM 1.2. For 2.0, we have much more flexibility, although the existing tools won't allow you to create a primary key for assigning key as a primary key. So we have to create an endorsement key, and from this key we are going to create an attestation identity key that can be used for assigning something. If you use directly with the CAPI the TPM software stack, you don't need to do this, of course. So this command, if it's not already stored in the Novolatile memory, it will generate a new key, RSA key, 256 bytes long, and we store it in ak.pub. We don't need this key, but as I said, we need to generate another key called attestation identity key from the endorsement key just created. This key will be stored in the file aik.pub, but it can be used directly by OpenSSL because it's basically a dump of a C structure described in the CCG standard. We need to extract the modules from that key, and this is done by skipping the first 102 bytes, and then we need to create a fixed header. This header is fixed, of course, with their header fixed for RSA keys, of course, and a mid-header, which is just metadata describing how the exponent looks like. So basically I'm saying it's a three bytes integer. And then when we have all these bits, we can compose them into a public key which can be used by OpenSSL in that format. You can convert it in PEM format if you like at this point. Then we sign a document and with the exported public key we can verify it, and to do that, we use these two commands. So as usual, we hash a message and then we sign it. In order to do this, you can use these two commands, but there is a sort of, I would say, bug in the Intel tooling which actually requires you to pass the message to the signed command. This is not needed, of course. In the right implementation, you just need to pass the hash. You can see we are using a ticket.bin file. So this is interesting for TPMs 2.0 because it's the way you can offload multiple steps operation. And basically you can sign only objects that are generated inside the TPM. And to prove that what you're passing to the TPM, to the signed command, is something that has been generated by the TPM. You generate this ticket which is an HMAC containing the proof that that specific TPM has generated the hash in this case. And so now we have this signature which is unfortunately not in the right format. So we need to extract to skip again this header described in the TCG standard and we extract the row signature which is 256 bytes long, of course. It's another, say, 2048 bits key that we are using. And then we can, on a different platform, we can verify the signature, for instance, with OpenSSL. So of course this is, as I say, this hacky, but this can be used to verify. Let's say you have a fleet of these devices. You can actually identify any, so every single device in your fleet with this method with a TPM because you can sign something and you can, let's say, announce and you can authenticate your devices in this way with embedded TPM. So thanks for your time and your attention. These are the links I mentioned. Thanks. Thanks for the talk. Do someone have a quick question? If you have any questions, feel free to drop me an email because we just scratched the surface of this. Yes. Hello.