WolfBoot
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 490 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/47220 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
BootingComputer virusProjective planeSoftwareFreewareComputer animation
00:43
System programmingComputer architectureEmbedded systemInformation securityBootingComputer animation
01:10
System programmingComputer architectureEmbedded systemTransport Layer SecurityLibrary (computing)Information securityBootingBitLibrary (computing)MicrocontrollerProduct (business)Business modelCodeCore dumpCryptographyComputer programRepository (publishing)Exception handlingDefault (computer science)Server (computing)Physical systemInternet der DingeComputer animation
03:12
System programmingPoint cloudGateway (telecommunications)Polygon meshTransport Layer SecurityComponent-based software engineeringCryptographyPhysical systemLevel (video gaming)CryptographyStandard deviationComputer hardwareInternet der DingePoint (geometry)Perfect groupComputer animation
04:37
Constraint (mathematics)Power (physics)Resource allocationConnectivity (graph theory)CodeBefehlsprozessorInformation securityPhysical systemAuthenticationLibrary (computing)Transport Layer SecuritySurfaceMechanism designCryptographyDatabaseVulnerability (computing)Point (geometry)FirmwareComputer-generated imageryHeat transferInjektivitätPoint cloudInformation securityPhysical systemBefehlsprozessorTelecommunicationCryptographySoftwareEndliche ModelltheorieAuthenticationVulnerability (computing)Power (physics)CodeMultiplication signSurfaceBitInternetworkingComponent-based software engineeringMereologyVirtual machineMiniDiscLibrary (computing)Primitive (album)MicrocontrollerDataflowCASE <Informatik>Communications protocolPredictabilityNon-volatile memoryOcean currentServer (computing)Context awarenessModule (mathematics)Device driverInternet service providerCore dumpComputer animation
09:50
Vulnerability (computing)Point (geometry)Computer-generated imageryFirmwareHeat transferInjektivitätBootingElectronic signatureMechanism designPhysical systemInformationMicrocontrollerData integrityPower (physics)Constraint (mathematics)AerodynamicsResource allocationError messageFirmwareElectronic signatureOrder (biology)32-bitDevice driverVulnerability (computing)ChainCodeCartesian coordinate systemFunctional (mathematics)Heat transferFlash memoryEncryptionRevision controlMultiplication signBootingField (computer science)Physical systemGroup actionDegree (graph theory)Phase transitionBranch (computer science)BitStack (abstract data type)Position operatorType theoryEntire functionNational Institute of Standards and TechnologyEllipseBootingSemiconductor memoryComputer animation
15:04
BootingMicrocontrollerData integrityConstraint (mathematics)AerodynamicsResource allocationBootingArchitectureAlgorithmArmReduced instruction set computingElectronic program guideRSA (algorithm)KinematicsKey (cryptography)Sign (mathematics)Electronic signatureComputer-generated imageryFirmwareServer (computing)Portable communications deviceIntegrated development environmentAuthenticationPublic-key cryptographyPoint cloudElectronic signatureKey (cryptography)WhiteboardBootingOperator (mathematics)INTEGRALArithmetic meanComputer hardwareSemiconductor memoryPoint (geometry)Goodness of fitOpen sourceCASE <Informatik>AlgorithmFlash memoryFormal verificationBootingRevision controlMereologyArmFirmwareSign (mathematics)Server (computing)BitElectronic mailing listPhysical systemNumberOrder (biology)Process (computing)Branch (computer science)MicrocontrollerPower (physics)Content (media)Partition (number theory)AbstractionFunctional (mathematics)Complete metric spaceSpacetimeComputer animation
20:04
Read-only memoryNon-volatile memoryPartition (number theory)Configuration spaceDuality (mathematics)Computer hardwareMicrocontrollerBootingRevision controlComputing platformReduced instruction set computingComputer architecture32-bitDevice driverDisintegrationSeries (mathematics)Operations researchRepository (publishing)Real-time operating systemSystem programmingMechanism designHeat transferLatent heatWhiteboardCartesian coordinate systemCASE <Informatik>Different (Kate Ryan album)BootingFlash memorySemiconductor memoryMappingFirmwareBootingPartition (number theory)Windows RegistryCombinational logicComputer hardwareMedical imagingTelecommunicationEndliche ModelltheorieBitNormal (geometry)CalculationRepository (publishing)Computing platformOperating systemKinematicsOperator (mathematics)PeripheralComputer animation
24:22
Computer-generated imageryBootingAddress spaceCodePartition (number theory)Linker (computing)Scripting languageSheaf (mathematics)Flash memoryLengthEmailBootingOperating systemPlastikkartePoint (geometry)SpacetimeLinker (computing)Real-time operating systemScripting languageCartesian coordinate systemComputer configurationComputer animation
24:46
BootingPartition (number theory)Factory (trading post)Server (computing)FirmwarePartition (number theory)Type theoryBootingFactory (trading post)Cartesian coordinate systemMedical imagingMultiplication signNilpotente GruppeBootingPublic-key cryptographyCASE <Informatik>Computer animation
25:55
FirmwareData integrityComputer-generated imageryElectronic signatureFormal verificationPartition (number theory)BootingPhysical systemRollback (data management)FirmwareBootingMedical imagingBootingInitial value problemComputer animation
26:30
BenchmarkImplementationBootingAlgorithm2 (number)SoftwarePublic-key cryptographyINTEGRALElliptic curveDiagram
27:24
SoftwareSoftware developerFormal languageBuildingPoint (geometry)Formal languageLevel (video gaming)Near-ringSoftware developerPosition operatorRemote procedure callEmailAddress spaceInformation securityComputer animation
28:32
Open sourcePoint cloud
Transcript: English(auto-generated)
00:06
Hello. Welcome. Thanks for being here. I'm going to talk about Wolf Boots. This is a project I've been working on for a while now. This is me. My name is Daniele LaCamero. Daniele with an E in the end.
00:22
That's because I'm Italian. But I do live in the Netherlands. And I'm in love with free software. And I've been involved in a lot of projects. Also with some of the people here in this room. Especially Maxime, Zubab sometimes, others.
00:41
And I also did write a book. It's called Embedded System Architecture. It's self-promotional. So feel free to check it out. And I work for a company called WolfoSell, which you probably know. Who knows WolfoSell in here? Yeah, yeah. We're popular. Yeah, that's nice.
01:01
And yeah. And I'm basically mostly focused today on secure boots. And that's what I'm talking about today. It's a bit of secure boots. And what's Wolf SSL? Well, most of you know SSL, TLS library.
01:21
Especially for embedded systems and for IoT. We're very popular in IoT. There is no competition from OpenSSL in very small devices. And other libraries don't put the same amount of effort, apparently. And get into the market, especially. We do our core business around SSL-TLS library,
01:45
which is the equivalent, in a way, of bigger SSL libraries in the embedded market. We have a crypto engine that's FIPS 140-3 ready. We do provide other products that are related to the library.
02:03
Wolf TPM, which is a TPM library to communicate with these secure bolt devices. Wolf SSH, which is an SSH server for microcontrollers. Wolf and QTT, which is a MQTT client, which comes with security by default.
02:20
And so it's mostly talks over TLS channel. Everything we do is... And it's also this other program here, which probably some of you have used, that we also maintain because Daniel Steinberg joined the team. Everything is free software.
02:41
Everything I'm talking about is available on GitHub repositories. We don't hide any code. All our code is available under GPL 2 license, well, with the exception of Core, of course. And we do provide proprietary licenses for all our users
03:02
who cannot comply with a copilot restrictions. And that's a bit of our business model. And yes, GitHub. This is what I expect nowadays from IoT systems. Unfortunately, I haven't been able to see much of this today, actually.
03:24
I've seen a lot of HTTP, I've seen a lot of MQTT, but I'm really scared, because I was convinced that I would arrive at this point in time, in this day, and can state that everyone is using the TLS 1.2, TLS 1.3,
03:40
as recommended by ETF. This is certainly not happening very much for what I've seen so far, and it's a bit scary for me. But yeah, let's assume that this is the perfect IoT-embedded systems. And yeah, most of our customers, especially those who are involved in the safety-critical system,
04:03
really care about security, and they do care about reaching the same level of standards for encryption, authentication, integrity, as they are available in the classic IT environment, let's say.
04:25
So, security-embedded systems normally have these features. They do use secure key vault, they use crypto hardware acceleration, where available from the hardware manufacturer. Some of them have particular safety constraints,
04:41
so they must be resistant to power failure. They cannot do any dynamic allocation, so forget your mallocs. They need to have a predictable execution flow in some cases. But this is kind of a corner case of special safety-related systems because that's something we work a lot with.
05:03
In general, what we see more and more is specialized connectivity, so we see low availability due to power harvesting devices or devices that are battery-powered, and they can consume a lot of power communicating all the time, so we heard about long-range LP1 protocols.
05:24
And what we care for sure is about this small code footprint and the fact that the lower CPU clock is sometimes the bottleneck when you are executing cryptography primitives directly on the CPU
05:45
or on the microcontroller. So, our take on the embedded system security, and I hope that this is shared a bit among all the colleagues, they usually need authentication of the remote endpoint,
06:04
so if you're talking to the cloud, you want to validate that the cloud is actually who they say they are. You need secure data at rest, so whenever you store something that's critical, especially now with GPR, and you're collecting data from your sensors,
06:20
you don't want to store them in a non-volatile memory that's not encrypted, right? So, we care about providing security for data at rest. We do provide security for data in motion. Motion means that the data that's moving from one system to the next one, it's our core business to provide end-to-end security in that context,
06:43
so TLS, SSL, as recommended by the standards, we don't invent anything, we just implement what's already recommended to be used for these kind of systems. And, of course, we do know that the security of the system is equal to the security of the least secure of its components.
07:03
So, whenever you are integrating multiple modules in your embedded system, you have to care about the security of your application, of course of your TLS library, the transport you're using, any driver or third-party software that's being provided by other players,
07:23
and that in case you don't have the sources, you need to trust them, which is very hard. And, of course, what we normally do in the IT world, in the world of big computers, of mobile, of Raspberry Pis,
07:42
big servers, et cetera, et cetera, it applies exactly also in IoT in small embedded microcontroller devices. So, when we're shipping a system and we can call it secure, we have to care about fixing any current known vulnerabilities,
08:02
hopefully, because if they are known to us, it's probably known also to a potential attacker. We're keeping the attack surface as small as possible hopefully, but once the system is shipped, we have to do exactly what people in big servers in the cloud do.
08:21
So, be aware at all times if we discover design vulnerabilities after the device has been shipped. Be aware that cryptographic mechanisms that are good today, they won't be tomorrow, and some devices get shipped for a lifetime of ten years. And also be aware of vulnerabilities exposure.
08:45
So, the vulnerabilities that have been discovered while your device was out, is your communication model affected by these kind of vulnerabilities? There's only one way to know. You keep studying your system after you release it.
09:00
But, of course, everything is fine when you have a Linux machine and you can do your disk upgrade or whatever and get the latest and greatest of all the libraries that you're using, and it's less of a concern. When you're talking a system like this, things get a bit harder to manage. So, we saw the need from the market,
09:22
especially from our user, for system updates. System updates is something you can't ship your device that's connected to the internet without thinking about it. So, vulnerabilities will be there, and they need to be identified and fixed. And that's just half of the part of it,
09:40
because then after you fix it, you have to ship it, of course, and you have to transfer, hopefully through a secure connection, your firmware that you want to put in your device, so the new version of the firmware. But the installation itself adds more risks and weak points, and often designing a solution
10:01
for upgrading your device on the field and doing secure boot hides a degree of introducing vulnerabilities and risks that are underestimated in the design phase and takes you a lot of time to get there after a while,
10:20
because you're adding code, right? So, you're also adding bugs. And these are some of the possible bad scenarios that can happen to your device when it's deployed in the field. And so, as usual, we looked at the standard, right? So we said, we have this problem to solve.
10:42
It's probably, it's a known problem, so luckily there is a working group within the IETF that's studying the problem and came out with this standard draft, which is called SUIT, which stands for System Updates for the Internal Things.
11:02
And to summarize this, it's basically going to be an RFC, hopefully, that describes how small devices with very constrained resources
11:22
can actually initiate an update and complete an installing of a new firmware version. So, what they propose, what they mandate, actually, is to have a minimalist bootloader that has a small amount of code that doesn't do much. It just has to manage your update,
11:43
but actually the installation of the update. So, the approach like U-Boot, of taking an entire TCP IP stack and managing the transfer of the images, puts you in a difficult position of having to maintain two TCP IP stacks, and probably your U-Boot one is not going to be updated anyway,
12:02
so it doubles the problem in a way. So, this approach is a bit more sane. You have bootloader, which only manages the update itself, the installation itself, but the update, the application is in charge of transferring the firmware, and this gives you another advantage. If you have a device with a very small flash space,
12:23
unless you start sharing code between your application and your bootloader, in order to access radio devices, for instance, you need twice the same driver used by both transport to communicate with the network, and this problem is not there anymore.
12:43
What they mandate also is that updates must be verified using a public key signature algorithm, which luckily we know about, and it needs to be evaluated also on the basis of its version, because you have to prevent attacks against
13:04
that try to put back a valid image, but in an older version, so that they can use other vulnerabilities in your software, and in most cases, you need a full-back mechanism in place, so that human errors like sending a perfectly valid update,
13:21
but doesn't boot, doesn't break your device forever, and it's probably, we're talking about devices that you cannot reach every day, or just maybe they are deployed in some physically difficult to access place. So, that's why we started WolfBoot. WolfBoot is the secure bootloader for the IoT,
13:43
it is designed for any type of 32-bit microcontrollers, and it's very generic in that sense. The architecture-specific code is limited to a couple functions, which are normally written in assembly.
14:01
The firmware updated secure is done doing digital signature authentication, both using RSA or elliptic curves, so ECC, NIST P1 rather than Edwards. It is power-fail-safe for the way it is implemented,
14:23
the swapping of the two images. It has a very small footprint, so it can run on small Cortex-M0s, for instance, and it is safe in the sense that it's been designed on purpose to be predictable, that all the branches within the bootloader are covered by specific functionalities
14:41
that have to happen in a specific sequence, and there is no dynamic allocation allowed. So, all the memory that is used also for the encryption is allocated at compile time, and this, of course, reduces the attack surface, because this is going to be a critical piece in your secure chain.
15:02
Let's try to be a bit faster here. So, how it works? It's normally relying on two different partitions on the same internal parallel flash, plus a small partition at the beginning that contains the bootloader itself, and a little partition at the end that still has a swap space
15:22
to switch every single sector of the flash whenever you want to swap these two. So, the primary boot is where your current firmware, the running firmware is, and that's what's always going to boot. So, in order to boot an update, the bootloader will have to swap the two partitions,
15:41
the contents of the two partitions, and this operation is failsafe. So, there's always going to be two copies of the same sector, so if you remove power at any time, you are always able to recover from the point where the bootloader will resume the swapping operation from the point left.
16:06
This is a bit of the features that we have implemented so far. This is a list that's growing probably while we speak. The first part was on ARM Cortex-M devices, easiest to find in the market probably what a lot of our users are using right now.
16:25
But, of course, we look into RISC-V, and we did a port on the RV32. That was the first microcontroller available to this kind of job. That was the FE310 from C5. And we are preparing an ARMv8 64-bit port,
16:43
so you'll be able to boot Linux. This is already possible in the branch actually, but we will release this soon, as soon as probably March. These are the public key algorithms we currently support, and those are the digest algorithms that we normally use
17:00
to check the integrity of the firmware updates and the current running firmware. This is a bit of the target that we support. I don't know if this list is complete. For sure there are no ARMv8 devices here yet. For this we prepare a small hardware abstraction layer
17:22
that consists only of six functions that you could write yourself on your own target, because normally everything you have to access on these devices is flash memory for bright access. In a few cases you need an SPI because we do support external SPI memory.
17:41
A very important thing I like to stress about is that secure boot is becoming very popular nowadays, but be careful because it's not all about opening the sources. There are companies that want to make money on your single updates and will bill you to sign each and every one of your single updates
18:01
you send from your cloud to your device. We really don't like this. We believe in no enforced provisioning, which means that there is no third-party signature required. You create your own private key and you own it. That doesn't mean that we cannot integrate it with existing provisioning systems.
18:21
It means that you just own what is supposed to be yours, like the keys for your devices. The work boot includes the public key of the private key you created at compile time. That's done through this tool set run on Python based on WolfCryptPy.
18:45
That's Python tools that can run on almost any system that are used to create the keys and sign the firmware. After you do this, you generate the key. You generate this key pair. The private key is used for signing and the public key is used for verifying.
19:02
WolfBoot will include the public key in its sources in order to be able to verify anything that's being signed by the cloud using the private key or by your server using the private key. The private key signs the firmware. The signing tool also takes the version number for the reasons I was saying before.
19:24
You don't allow downgrades. You only allow updates that contains a newer version. The signed firmware is basically just an image, a bundle, that you can send from your server to the device, hopefully using an encrypted channel, a secure channel,
19:43
not HTTP, not MQTT on port 183, please. From there, this authenticated firmware can finally be verified, the signature of it, by WolfBoot. If it's good firmware, it will be allowed to boot. If it's good firmware and it's a new version,
20:01
it will be swapped with the current running version and your board will boot the new version. As I said, we have external flash support, so in a lot of cases, your flash is not big enough to host twice your application.
20:20
So what we provide is that the upgrade partition, in this case, is living in its own external device. You don't need execution in place on that. So since we are swapping all the time, that's easy. The live image is always going to be in the boot partition.
20:42
Then we do support executing for RAM because it was required by some of the targets we port to due to their specific internal flash configuration, which means that the bootloader can run from RAM. So you can load it from the flash, where it's normally executing in place, to RAM,
21:01
like a normal Linux machine, let's say, and it will start running from there. So the bootloader knows that it's capable of jumping to RAM at any time. This way, we want another fantastic feature, which is the self-update. So we are now able, since a few months, to update the bootloader itself by sending a special signed package.
21:24
We have some other interesting features. This one is hardware specific. It's supported by SCM32F7 and SCM32H7 board. It allows basically to divide your internal flash into two partitions,
21:41
but then just using one bit in one registry to say, okay, now swap their mapping in memory. So basically it's a kind of very primitive virtual memory, which only allows two computations, but it's very handy in our case because basically it saves us the few seconds, 8, 10, 20 seconds,
22:03
that are needed to swap your application in place, and instead it just remaps the two partitions. This is implemented. Okay, RISC-V. We talked about it. We announced that RISC-V workshop in Zurich. I see some familiar faces over here.
22:23
So that was the first non-ARM architecture, and that was the board. It was the i5 board. We both support A and B models. We do support hardware acceleration, of course, because WolfCrypt does, so we inherit that from there. So on kinetics boards, for instance,
22:40
we don't do all the calculation on ECC ourselves using the MCU, but we rather offload it to the external accelerator. The same we do with the newer STM32 devices that support public key acceleration, like they sent it to WB. We're up to speed. We add more and more drivers for this.
23:01
We do have many hardware accelerators supported, including TPM, because you can just swap WolfCrypt, that's the cryptographic engine that does everything in software, with WolfTPM, and in that case, all the operations are done in hardware by the TPM device.
23:22
And then, of course, the bootloader becomes much smaller because it doesn't integrate the cryptographic software itself. It just offloads it using WolfTPM. There is a WolfBoot example repository. We have many different examples. I tried to make a combination of different platforms with different OS
23:45
because we run bare metal as well as real-time operating systems. One worth mentioning maybe is config.us running on Nordic and RF52 that uses the TLS 1.2 over 6LOPAN, over BLE,
24:01
and gets an encrypted transport of the firmware to the device, which is encrypted through TLS 1.2 using state-of-the-art communication channels, for instance, on some OS.
24:22
The only modification needed on your application being a bare metal and a real-time operating system is just moving the entry point to make space for the bootloader itself. This is normally done in a linker script or if you have a very smart operating system like RiotOS,
24:40
you can do it just by passing a makefile option. This is how it works very quickly when it's deployed. Normally, in the factory, or the first time you flash it, you put the bootloader in the first partition and you put your signed factory image in the primary partition.
25:04
At this point, you don't need JTAG anymore because JTAG, you use it when you're developing it. In this case, you can basically burn your JTAG
25:21
or do some kind of other type of protection for readout or just protecting the bootloader partition against writing, it's sufficient to limit tampering with the stored public key in case you're storing the public key in clear.
25:42
The only way to flash it after you've burned your JTAG is basically from inside the device itself. Your application on normal condition will just boot the first partition. When there is a remote firmware update that's been signed and transmitted over the air,
26:02
hopefully again using an encrypted channel, then the update will be verified and the bootloader can swap the two images so now the update becomes the live image only after it's been verified and if it's confirmed at the next boot up, no fallback will be allowed anymore,
26:21
so no downgrade after a successful boot from an actual image. Of course, otherwise there will be a rollback and everything comes back to its initial values. This is just quickly the kind of benchmark we look at. Depending on the algorithm you choose to use for public key authentication,
26:44
Edwards has a very small implementation. We're talking about 10K, but it takes on this device, which is a DNRF52, it takes two seconds and a half to boot and you can go down to less than 150 milliseconds on this device by using elliptic curves or RSA.
27:05
It's the same benchmark on STM32F7, which is slightly faster. The last peak is using the TPM because the TPM has a very slow SHA calculation, but we can make an hybrid that's more or less the same size but still does the integrity check in software.
27:23
And yeah, that's possibly it. Let me spend a few words on this. We are hiring embedded software developers for remote positions. The company is based in Washington State, near Seattle, Washington, but we do have developers all over the world working remote.
27:43
All you need is passion for embedded, passion for security, and of course willing to do things right from the security point of view, that's the most important thing. And we're also hiring for small project-based language ports. We're still missing language ports for Ruby, for Go, for Rust,
28:01
for probably other languages that don't come to mind at this point. So please be in touch with us. There's a few email addresses. We do have a stand, you probably know, building K level 2 at this program, so feel free to go and speak to my colleague. One of them is here.
28:21
So that's it. Thank you. Thank you, Daniele. Daniele will be taking your questions outside. We are moving on to the next talk.