 So, let's just go on it. All right, so we can start. This is the name of the presentation, how to integrate secure elements. This is gonna be shortened from including secure MCUs and FPGAs because we only have 20 minutes. And, just slides. I'm not a very good Windows user in case you haven't noticed. So, this is Windows. So, we need a definition of secure elements, right? What's a secure element? I wish I could show one, document camera is not working. They're basically the small integrated circuits that lie on a PCB on a printed circuit board and they help us support secure applications. And so, these are some of the identifying factors that define a secure element. If you talk to different people working with them daily, they vary a bit. It's kind of a fuzzy definition. But, we can say that they're usually in an integrated circuit. So, they're a dedicated, separate piece of hardware that may be connected to a microprocessor or a microcontroller. They may store sensitive information. I'm using the word may here because some have secure storage and features like mesh construction so that decapsulation methods and attacks are more difficult and other maybe cheaper or less full-featured secure elements. They don't have secure storage. So, that's why it may store secure information. It may run cryptographic applications, things like algorithms, AES or ECDSA, digital signature algorithms, Diffie Hellman. It all depends on what you're looking at. We'll take a look at a data sheet later on for details. So, what they usually all do is they protect the internal state from things happening outside, the voltages. All of these things are controlled more or less. So, that's kind of our definition. And some of the attacks that they defend against are from, well, I'll stop from the beginning, side-channel attacks, things like voltage measurements, correlation power analysis or CPA. The type of attacks that you might use a chip whisperer to launch against a piece of electronics device. They usually do their best to detect and prevent these type of attacks. Timing, things like oscillating, glitching, and voltage glitching as well. Once again, each secure element is slightly different. Some are more expensive and more full-features than others don't have all of these defenses. Some physical attacks are possible on electronics and general decapsulation with sulfuric acid vapor, ion particle beam, inspection, microscopy. All of these things are physical attacks and secure elements often protect and defend against those in one way or another. So, those are some of the reasons that we implement using secure elements is that they defend against some or all of these attacks. The use cases for secure elements is not surprising, they're usually security-oriented, sometimes critical security, you might have a pacemaker or biometrics application where you need some better security than you would otherwise get from an MCU or some more trivial electronics. Basically, here are some of the, it's actually a short list, but in general authentication, digital signing, mobile payments, cryptocurrency, quite a few wallets, for example, are using secure elements. Life cycle management, how to push authorized firmware onto an IoT device, for example, and some RF as well. Wi-Fi, and I think Laura specifies that encryption takes place when the node is sending data over RF. So, these are all reasons or applications to use secure elements in. And going back to the definition and the application base, here's kind of a block diagram of just one example of how we could implement a hardware circuit using a secure element. Thought I had a laser. No, I'll use, you can't see the pointer. I'll use my finger how about that. So, the secure element is way at the top, you can see it. If it weren't there, we would be implementing the security features on the left in the MCU. And it's certainly practical for some applications, like I say, secure elements are not needed for everything, but if you have something requiring more security, then you could implement using a secure element and then transfer information from the MCU to the secure element over some serial protocol like I squared C, for example. In this example, which I found online, they're doing this in order to probably enable a contactless payment processing application with a reader, a base station, and then not a smartphone, but some kind of small device, a dongle of some kind, with an antenna that can do contactless RF, either RFID or NFC. So, this is kind of one of the nicer arrangements, it's very easy to see what's happening in an overview level. Do you like this as well? Any questions about this? I wonder how many of us are implementing using secure elements. And I did just mention serial protocols for transferring information in and out of the secure element. That usually happens over I squared C and this is another example of the I squared C, what's the name of this UML diagram? It's called a sequence diagram, thank you. So, we have on the right the secure element and the HD on the left, that's the host device, which is sending information back and forth. You can consider this to be an MCU, for example. And this is just the very beginning, it's kind of a handshake, the MCU is trying to decide, do we have one secure element or two, which is the correct address that I'm looking for? This is all coded, of course, so the addresses are known. And this is kind of the traditional way to communicate with a secure element. There are some parts that I want to mention so that we understand how to actually buy one of these or in fact, you can probably get some for free. Yes, for free, if you pick the right, like for example, NXP, I believe will send you, they do it for me, I assume they send it to anybody for free, a few of these secure element ICs, integrated circuits, and they're very small, they're difficult to solder with your hands. I think the largest form factor is a QFN, so that's quad-flattened legs, all of the legs are underneath or the contacts are underneath the chip, so it makes it very difficult to use a typical heat-tipped solder iron, you need some reflow or some hot air solder methods to be able to solder most of these. The admals that I listed here are much easier, they have, I think, SOIC, so you can see the legs of the chip. I'm not sure how familiar we all are with this kind of thing, but at the top here, we have chips that look like, okay, that won't work. Seems like my pen is not working. The pen is not working, great. So, can't draw, but the SOIC chips, they're the ones that you usually see with the legs on the side, you can solder those very easily, and those are the Atmote ones. The NXP is a bit more difficult to infine on Optigas, I believe are like the NXP, they're QFN and under. So these are kind of the things that you might find in very small devices, if you have a smart watch, or I don't even know, the smaller it gets, the less surface area on the board you're allowed to use. That's why not all are committed to SOIC and QFP form factors. This is for integration, I found a few links, I knew that we wouldn't have time to get into the details, but I made them part of the slide deck in case we want to look after the fact. The one thing that is maybe interesting, because we all know what a UB key is, how can I, what's, this is the reason I don't like Windows, so it's here, I believe, and we can't see that there. Okay, forget that. All right, yeah, so it's just a confusion, because what I'm seeing on my screen is different than that. I'm sorry, I can't show the website, because Windows is not that far yet. But if you check this out, so I'm just gonna mutually, how do you say that? I'm just gonna explain what you see in the first UB key blog post. It's like a thousand line document, and they're explaining why some of their source code is closed and proprietary and others are open source. They don't use the word secure element and NDA, but this is usually the reason that people don't publish source code when they're using secure elements. They've made the choice to sign an NDA, a non-disclosure agreement for some certification of the manufacturer of the secure element, and it kind of gets in the way sometimes. The other two here, the DigiKey on the NXP articles are very useful for getting started and collecting information. They actually give you kind of a cookie cutter method to implement a board that's running with the SE secure element into your system. Yeah, so we've already considered non-disclosure agreements, but what are they really? It's basically a contract that you sign with a manufacturer, and after that happens, you get certain privileges. They might send you the chips after you sign the document, or you have the chips, but in order to understand the API, in order to be able to program software or firmware for the chips, you need to sign the document. So it's a big hassle in my opinion. I'm not sure if it's positive for any application, but at one moment or another, everybody talks to a manufacturer basically refusing to reveal information unless you sign the document. I have never signed an NDA, so I can't explain too much about what happens after that, but it does lead to confusion sometimes, and it will possibly mean that if you understand what's in the API, the names of the assembly op codes that the secure element can understand or the I squared C commands, after you sign an NDA, you can't use that information in your source code if it's public. So this is kind of a difficulty, and it's the reason that it's part of this discussion. Right, so we have just a little time left, and there is no way to demonstrate visually with document cameras, because of missing cables and things, but I wanted to at least, I wish I could get this, I have a spare laser here, so let me see if I can, oh, there it is, it's a great freebie so you get a trade fairs, right? You think it'll work? Yeah, it works, okay, that was close. So here, I've actually left them unpopulated, I'm sorry, not the U5, but the U4 and the U3 on this circuit board house two different secure elements. They are DFN, dual flat, no leg packages, so if you can imagine that the black, this is like a black chip, right, that the black chip covers the entire copper area there. Those, these two things, I've left them unpopulated so that you can see them, because if there's a black blob on there, it just makes it more difficult, you don't know how many legs, right? But what happens after you solder those, after you assemble these two secure elements, they're communicating with the MCU over I squared C, which is a serial protocol. So you use the wire library, if you're familiar with Arduino or some other thing for ATML, microchip, NXP, whatever, which one you're using, and then you exchange information with the SEs, for example, you give a command that says, generate a key, it does that inside the secure element, and will never reveal the secret key. There's no way to get it out, or there's what, theoretically there's a way to get it out, but practically there's not. So that's kind of the way it looks when you design a circuit with secure elements. And because I designed this circuit, I think, but I'm not able to, if I turn off the presentation, I can possibly, oh yeah, okay, so now I can possibly show, oh, thank goodness. Finally a normal screen, what's that? Right, so this is what we were just looking at, the schematic, and if we go over here, so the middle of the largest piece is the MCU that we looked at before, and that's the secure element over here, that's one of them, let's say, ATML, AT, ECC, 508, sorry. So this is kind of on the design level, how it all works, because I'm sure there are a few designers here with us, and with that I believe it's gonna be time for questions because I don't think there's any slides left. What do you think, is there? Okay, wait a minute, that's the end, right. Yeah, so we're done unless we have questions about secure elements, please. Hi there, thanks for that. We're in the process of putting a board together, an embedded Linux board, using the SCO 50. So we have that on there as our route of trust, and we're happy that we can use that to authenticate the device in a strong manner, so we have an identifier out of that chip when we onboard to the cloud, and that's great. I can't understand too well, can you speak more clearly? So we have a board that we've been putting together running embedded Linux, and it has an SCO 50 on it as the route of trust, which is great, and so we're happy that we use that to onboard in a strong manner, so the device has an identifier that's cryptographically strong, and we know as long as that chip hasn't been physically removed, which device is the device that we're onboarding to the cloud, that's all great. But as we've been going through this process, the other thing that we need to be able to do is to ensure that the code running on the device is trusted, so this is an NXP-IMX8 series part that we're using. Now, so what we need to do is to, from power on, loading in authenticated, SPL code, bootloader, kernel, file system, right the way through, now it would seem sensible to use this secure element, the route of trust, to underwrite all of that, but we don't seem to be able to. The parts all seem to have their own internal mechanisms, be it eFuses and keys that are stored in the part, and it kind of feels messy that we've got an external secure element designed to be physically tamper resistant to whatever extent, but we're not able to use that to secure the chain of trust in the boot. Now, am I missing something, or is that just the way things are at the minute? Okay, so it's kind of an involved question. I don't think you're missing much. What I can recommend, if you haven't looked at it yet, is where can I write on here? It's not gonna work. So in fact, here though, we're using one. It's a microchip microcontroller called a, somewhere it's here, a CEC-1702. So I'm not asking you to change your architecture, and I wish that you'll be able to make it work with the SE-050 from NXP. The NXP SE has a hardened style of I squared C communication. So theoretically, at least my belief is that you can make the system work as you're describing it. Now, the source code is actually in the boot loaders. I can't remember the architecture of the CEC-1702 is a bit strange, but they have a very good method of encrypting the firmware, even if it's off chip, if it's on SQI's flash or something like that. And you can implement very nice secure boot using the CEC-1702. So that's one alternative that I can suggest in a few seconds. Yeah, I'd be interested if you get it to work to know about it. Any other questions? We have time for one more? Two more questions. Thank you. Thank you for the talk. Also, in the context of embedded Linux specifically, we are currently implementing secure elements, but we're also struggling a bit or interfacing them. Seems to be a problem, or it's very, there's this standard called PKSC11, I think. And that's like a standard API, but it depends a lot on the hardware vendor if they provide a binary that implements that API. So do you have any experience or around this ecosystem or recommendations? Yeah, what it would be nice to have is a library that abstracts all of the various iSports C commands or other style of opcodes and commands that you need to issue to an SE, right? I don't know of something like that. I like to use Platform.io when I'm dealing with open source groups and I'm trying to encourage people to contribute. And I don't think there's anything general like that on Platform.io and it's library, plug-in system. There's no secure element meta library like that. The other thing that you might consider is that, yeah, they're all different. I mean, every manufacturer has their own API, but it's not so uncommon to place more than one secure element on a PCB. In fact, I have, in my latest design, I have three and I'm hoping to, I mean, I assume it will be reduced to two, but you usually have one that's good at secure storage and another that's very easy to use on the API level. That's neither one of those answers, the Platform.io library packaging and the multiple SEs on one board is probably what you're looking for, but maybe that gets you working in the right direction. Thank you. You're welcome. Okay, so it looks like that's it for us. The name of the, so this is what we just saw. And yeah, thanks a lot for coming and any questions later, I'll be outside, probably wandering around. You can find me as well. I didn't put my email address on there, but I have business cards. So come on up if you want more information and we'll talk in another time. Thanks a lot. Thank you.