We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Secure boot, TEEs, different OSes and more

00:00

Formale Metadaten

Titel
Secure boot, TEEs, different OSes and more
Serientitel
Anzahl der Teile
287
Autor
Lizenz
CC-Namensnennung 2.0 Belgien:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
In this talk Marta is going to present a map of the trusted computing landscape, explaining different types hardware support. She is going to put it in a context of implementing secure boot and trusted execution in an embedded distribution, namely Yocto-based Eclipse Oniro project. The trusted computing landscape could be hard to understand for newcomers. Just at the beginning, they encounter a number of abbreviations like TEE, OPTEE, SEV, TF-A, TF-M and many more. In this talk Marta is going to present a map of those technologies, illustrate how they are (or are expected to) be used, which market needs they address. She will show how they could be implemented in practice in an embedded distribution. The example will be the secure boot work in the Eclipse Oniro project, an embedded multi-OS distribution for Internet of Things (IOT) devices. The multi-OS specificity of Oniro will be used how the trusted computing technologies compare on different types of processors running Linux and Zephyr, with different security hardware support.
Diskrete-Elemente-MethodeDiagrammTechnische Zeichnung
Einfach zusammenhängender RaumOpen SourceSoftwareProdukt <Mathematik>EDV-BeratungComputersicherheitRechnernetzCASE <Informatik>BootenComputersicherheitNeuroinformatikOffene MengeProjektive EbeneProdukt <Mathematik>SoftwareentwicklerEinbettung <Mathematik>sinc-FunktionSoftwareComputeranimation
Einfach zusammenhängender RaumBootenPortabilitätNetzbetriebssystemSoftwareentwicklerHardwareSystemplattformDatenfeldBildgebendes VerfahrenSoftwareMalwareDifferenteGruppenoperationDistributionenraumWeb SiteComputersicherheitInternet der DingeMinkowski-MetrikMultiplikationDateiverwaltungGamecontrollerEinfache GenauigkeitJSON
Gebäude <Mathematik>Einfach zusammenhängender RaumEingebettetes SystemPhysikalisches SystemKernel <Informatik>ATMEinfacher RingSystemstartSoftwareMalwareEchtzeitsystemCoprozessorKartesische KoordinatenInformationATMCASE <Informatik>SpeicherschutzHardwareSoftwaretestKernel <Informatik>MAPGraphfärbungMechanismus-Design-TheorieElektronische PublikationPhysikalisches SystemDifferenteSystemplattformElement <Gruppentheorie>HalbleiterspeicherComputersicherheitMultiplikationsoperatorTermBootenEinfacher RingComputeranimation
ComputersicherheitOpen SourceSystemintegrationZufallsgeneratorBootenSystemplattformBimodulInformationsspeicherungSpeicherabzugStandardabweichungZweiSchlüsselverwaltungMinimalflächeMereologieKategorie <Mathematik>AlgorithmusComputeranimation
SpeicherverwaltungChiffrierungSchnelltasteROM <Informatik>Kernel <Informatik>ATMEinfacher RingNetzbetriebssystemHalbleiterspeicherGrenzschichtablösungMaßerweiterungPhysikalisches SystemHardwareATMBitInformationCodeKartesische KoordinatenInverser LimesVerschlingungOrdnung <Mathematik>Computeranimation
Gebäude <Mathematik>Open SourceImplementierungLastCodeSystemplattformUmwandlungsenthalpieARM <Computerarchitektur>MultiplikationsoperatorMereologieStandardabweichungComputerarchitekturComputeranimation
ATMKernel <Informatik>Einfacher RingARM <Computerarchitektur>Gebäude <Mathematik>KryptologieNP-hartes ProblemInformationsspeicherungKartesische KoordinatenInformationsspeicherungDifferenteComputersicherheitSystemplattformATMWeb SiteMultiplikationsoperatorKernel <Informatik>BitMereologieNichtlinearer OperatorÄhnlichkeitsgeometrieTypentheorieStandardabweichungComputeranimation
Einfach zusammenhängender RaumÄhnlichkeitsgeometrieProjektive EbeneChiffrierungARM <Computerarchitektur>MaßerweiterungFirmwareMinkowski-MetrikBitSoftwareSystemplattformVirtualisierungMereologieCoprozessorUmwandlungsenthalpieInformationHardwareHalbleiterspeicherNetzbetriebssystemCodeVerschlingungKartesische KoordinatenMathematikComputersicherheitVirtuelle MaschineComputeranimation
KryptologieIntelGebäude <Mathematik>VariableSystemstartDemoszene <Programmierung>BootenDemoszene <Programmierung>CASE <Informatik>VariableProgrammierumgebungGrenzschichtablösungKryptologieWurzel <Mathematik>SystemstartARM <Computerarchitektur>Kartesische KoordinatenDifferenteFunktionalVirtuelle MaschineInformationsspeicherungVollständigkeitComputeranimation
Gebäude <Mathematik>VerschlingungProjektive EbeneWeb SiteComputersicherheitGarbentheorieQuellcodeComputeranimation
Eingebettetes SystemMultiplikationsoperatorEinfache GenauigkeitTypentheorieHardwareSystemplattformSoftwareGrenzschichtablösungAutorisierungDifferenteBootenComputersicherheitMinimalflächeImplementierungStandardabweichungLeistung <Physik>VirtualisierungInverser LimesFirmwareCASE <Informatik>Gebäude <Mathematik>Computeranimation
VollständigkeitWurzel <Mathematik>SystemplattformZeitzoneImplementierungSpeichermodellSystemstartDivergente ReiheEinfache GenauigkeitPhysikalisches SystemDifferenteHardwareKernel <Informatik>FirmwareBesprechung/InterviewComputeranimation
StrukturgleichungsmodellComputeranimation
Transkript: Englisch(automatisch erzeugt)
Hello everyone, and welcome on the talk on secure boot and making sense of the trusted computing landscape. The case for the embedded distribution, Eclipse on Hero. My name is Marta and I have 20 years of experience in software development in open source,
including 15 in embedded. I have security background, have done a PhD in telecommunications, especially in network security. And during the last years, I've been working in embedded product development and silicon, while now I have moved to distributions.
I'm contributing to the On Hero project since April 21, while consulting for OSTC. This talk includes my personal opinions. So all of them, my opinions are of just now
and I can maybe change them in the future. My motivation for this talk was that when I started working on secure boot in a distribution,
I've met a lot of questions from the developers. And I found out there's a lot of confusion about the security related technologies among developers who are not exactly in the field.
I've received questions like, what's the difference between the TrustZone and the MD-SCV and all those TFA and TFM want that and what's the difference? So I decided to explain all that
for a little bigger group so you can all benefit. I've also found out, I'd rather confirmed that there's a general mistrust for the secure boot and security related hardware accelerated technologies.
There's a fear of lockdown platform. And there's another thing also, there's a fear of complexifying the whole software development. I'm working on Oniro, a distribution that is aiming at defragmenting the embedded IoT space.
A distribution that has a specific feature of supporting multiple operating system. So not just multiple platforms but also multiple operating systems.
And the distribution, so we'd like to have a unified way of handling secure boot or handling T's so that we do not have to have a specific solution for each single hardware platform. As you can imagine, distributions like to have something
that is easy to support. Now, my motivations for the secure boot, and this is again, my personal opinions on this subject. Secure boot is a good way to be able to detect
that a device is running the expected software. That there was no malware that got installed some way and it's now running and taking control on the platform. It's also a way to make sure the device is running the software under control.
For example, you may want to know that it's running software that has been released properly. In embedded space, it's important to be able to update your device. Again, we would like to know that you are updating.
You want to know that you are updating your device with an image that has been verified that is the right image and you haven't been tricked into downloading some malware from some random site. And then in some cases,
device manufacturers want to have encrypted images and encrypted file system for different reasons. Makes sense in my opinion, to have a complete secure boot if you want to have encrypted file systems. In this case, there's less risk
that the data gets stolen by some unexpected software. To start with my explanation, we have to go back in time to look at the traditional platforms. And I would like to show you that in the trusted execution environments,
the trusted term and whom do you trust is one of the most important questions to ask. So let's go back in time and look at the traditional platforms. Traditional platforms like a generic PC
and a traditional embedded design. Let's start from a PC. Of course, I'm simplifying here, but we have only two elements for the presentation. Who do you trust in a traditional PC? In a traditional PC, you have processor hardware
that you are expected to trust. That offers some security features like IOMM or the kernel mode, user mode called often execution rings.
And you have your OS kernel running in the kernel mode. The OS kernel is something that you trust. Then you have applications and those can be untrusted or partially trusted.
Applications come in different shapes and colors. The kernel is using the mechanisms given by the hardware to partially protect the applications from each other and protect applications from the kernel. In such traditional system,
we have some protection, we protect memory. We have also the protection system on the file system, but there are still some ways the applications can interact and some ways the application can work out those protections.
In an embedded system, it's a little bit different. Yet again, traditional embedded system. You have your real-time operating systems and your applications all linked together. Your processor hardware is still trusted.
You may have a memory protection unit, MPU, but it was often an option. You often have pretty simple applications that may be heavy and hard to debug because everything is in the same memory
and you may have memory issues in your application that are pretty hard to debug. Applications are trusted in such case because you really have no other choice altogether. And you try to limit the difficulty
by having simple applications and devices doing just one. And also in some cases, by updating the code, heavy testing. Now, how is the secure boot situation in this case? Well, there are a lot of issues. And if your malicious software,
someone else's malicious software is running or managed to start at the system level especially, it can overwrite everything. It can read everything. In embedded device, it's even worse because it can absolutely control everything.
So you cannot do really a secure boot because the malicious software can overwrite any information maybe for the secure boot. At some point in time, there came the TPMs, trusted platform modules. A trusted platform module is a security core processor,
the device itself. But on the other hand, it's also a standard. From my research, it seems that TPMs started showing up in the news around 2007. They can be a separate chip, they can be firmware, they can be part of the chip,
they can be software. So they come in different types, but typically it's a separate chip. The main news was expected to be system integrity and they made a lot of open source news when they were expected to be used
for enforcing property licenses. But apart from that, a TPM is also a device that offers features like random number generator or something that can accelerate cryptographic algorithms.
And it offers some secure storage. So you could use it to do a secure boot. And I'm proposing you a few links if you're interested to learn more. The second one, for example, shows how to set up SSH keys using a TPM, how to protect your SSH keys using a TPM.
But it's a pretty interesting feature. With a TPM, whom do you trust? Nothing really changes except that you have that separate TPM chip that I've put on the extension of the hardware,
and more in the kernel mode. It's really a separate piece of hardware. It can encrypt and decrypt keys, the separation code bindings, but it has no DMA. So it means it cannot access any memory region in the system.
So it cannot verify what you are running on its own. It relies on what the operating system or the great application tells to the TPM. So it can be used, but there are some limitations and the order of the two links gives you a little bit more information about that.
More or less at the same time in the past came the trusted execution environment, T. A T is a part of a process. It protects loaded code and data and still the definition
covers the device itself, but it also covers a specification, global platform specification and API. Then we have OpT, which is an open source implementation
of the T as the standard, as the standard and API, mostly for ARM TrustZone architectures. Now, what happens on a platform with an ARM-style T? We have our design of the PC
from the previous slides, but there are things showing up in addition, both from the TrustZone and both from the T side. We have the secure and non-secure mode. So the kernel and user mode,
all the kernel and user modes are duplicated, or nearly duplicated on the secure, the site called secure. Instead of one OS kernel, the one you were running previously is now running in so-called non-secure mode. You also have another OS kernel,
this time running in the secure mode, and you have some applications running in the secure mode and applications running in the non-secure mode. In this case, the applications you run in the trusted mode are expected to be trusted.
Please note that there is still a difference between the applications and the OS kernel. They are running in different modes, so you still have the same type of protections that you had with the standard operating system kernel and its applications. What are the similarities and differences
between the TPM and T? Both of them contain cryptoaccelerated, but there are some differences. TPM is typically a separate chip. T is typically a part of a chip. But what is more important is that in TPM,
the operations are hard-coded. You can just access a few registers and put values in them. While T can run applications, you can write applications for the T. A little bit related to this, TPM has a pretty small storage, and T has a way bigger storage.
Of course, it can be storing the application and its data. So both TPM and T you can use to obtain a secure port. Finally, when we are here, TFA and TFM. We were discussing before that the hardware is trusted,
but in the modern processors, part of this hardware is not really hardware. It's software, not firmware. And it's also running on your processor next to the typical software we are talking about.
And in this case, we have TFA that is a reference firmware for the ARM v7 and v8, platform-scaled A-type. And it's working next to OPT-D. It's not replacing. Or any of the T that you may implement.
It's working next to T. And you can get more information about how it works and what is its architecture. On the ARM M-style platforms, you have a similar project, similar platform. You have similar project and similar software called TFM.
Now let's change hardware platforms on the Intel SGX, software-guided extension. It's a possibility to create a specific memory region called enclave. And when you put some code into that specific region,
only the code that is in the enclave can run and can read and write the memory. The host, the operating system itself, all the applications running on the same system,
they cannot access that memory. That gives you some similarities with the MMU configuration, because it's all related. The memory can be also encrypted by hardware needs. And if you are interested in more information about this,
a few articles that you can start with. AMD Secure Encrypted Virtualization, another abbreviation. It's an extension to the virtualization extensions, and it adds encryption for each virtual machine
or for the chosen virtual machines. He's a 100 in the firmware. And the same as in the previous example, the host cannot access that specific memory space. And here again, a little bit of links
about those platforms. So yet again, similarities and differences, what are there between the Ts and the extensions? Now all can be used to create T-like designs, but there are some differences because the SGX and SEV are designed more
for the virtual machine related environments. And they do not contain a separate crypto accelerator. There's usually one that is close, that is related, but they do not have a crypto accelerator as one of their main functions.
Now, how it all relates to the secure boot. We are aiming at unification. So use all technologies in a unified way. What we decide to do is to use Eufy on x86 and MBBR for ARM.
But EBBR, if you are not familiar, it is basically simplified Eufy. And what we have behind the scenes is Opti used to store Eufy variables. That is the work, thanks to Linero.
And what we want to do is a complete root of trust from the bootloader to the eventual application in an enclave if you are interested in such use case. If you're interested in knowing more about our project and details of our security work,
not hesitate to access our website or the source code and you can also access the Eclipse project section for Oniro. Thank you for your attention. And that will be the time to take any questions
you may have. This type of TPMs. So like hardware separate chip or also software solutions.
Do you want to add something to this? Yeah, I'd like to add something because it seems that the author of the question was, it's really in TPMs and has really mentioned all types of different TPMs as you can have. So as for these, for TPMs,
you have different implementations if they follow the same standard. What it means that the power they have and the exact features that they have and the exact limitation will be a little different for one TPM to another. It will be different if you have a hardware TPM,
it will be different if you have a firmware based TPM. And there are different use cases for each of them. For example, in my case, I'm using a software TPM on the QML build. In this case, we do have a TPM
that we normally do not have in a software platform. And then we can do the security boot using that virtual software TPM on a QML platform that everyone can easily install and did not have to start looking
for some specific hardware. So every type of TPM, for this, I haven't seen a simulation, maybe it exists to be able to run it directly.
But every single usage of it, there is a usage of every single type of a TPM. So it was a variable comment that there are different solutions and you can look for one that fits your needs. Yeah, thanks. So we have another question from Mohammed.
Can you elaborate more about the last point, the complete root of trust you were talking about? What is the design that you have used for Oniro? Okay, it's a very good question for the complete root of trust. Having a complete root of trust is a pretty complicated thing to do correctly
because you need to make sure that you start from, if you are running on a physical platform, from a kind of a firmware and then this firmware is verifying your bootloader.
The bootloader verifies your kernel, then your kernel verifies all the steps of the system and every single step of the system is verified. So as we are running on different hardware platforms, we have x86, we have arms, we have RISC-V. We have also bigger platforms like Arm-A
and we have smaller platforms with Arm-M series. It means that we do not have one single design, hardware design of root of trust and we adapt to the hardware platform and we have different implementations for different hardware platforms.
For example, for Arm-A, it's using the trust zone.