This is the first in what I hope to be a series of posts about the MCUboot bootloader from a security perspective. Please note that although I work in security, I am by no means a cryptographer. I appreciate any feedback on any and all flaws in my analysis. The MCUboot project The MCUboot Project is …a secure bootloader for 32-bit MCUs. The goal of MCUboot is to define a common infrastructure for the bootloader, system flash layout on microcontroller systems, and to provide a secure bootloader that enables easy software upgrade.
On Hacker News, user jgrahamc writes: If you take a narrow focus on a particular cryptographic event (such as your encryption of a string with an RSA public key) then you miss the greater story about encryption: it’s not just the individual cryptographic primitive that needs to be implemented correctly, it’s everything else. I recently have been involved in putting a demo together of using Arm’s TrustZone for Microcontrollers This is based around putting “secure” operations within a trusted firmware app.
This post summarizes the relevant RFCS (and other standards) related to cryptography and, specifically, relevant to MCUboot. I intend to update this post with more RFCs as I refer to them in my work. Last update: 2018-05-31 Cryptography The following documents describe protocols and encodings relevant to digital signatures. RFC3447: Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1 RFC4279: Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)
Update: After a little digging, I understand where the leading 0x00 comes from on the EC public key. I’ve recently been working on the MCUboot project. A key feature of this bootloader is its use of digital signatures to verify images both before performing upgrades, and optionally, also before running them. The code currently supports RSA and ECDSA signatures, and we are working on adding support for EdDSA signatures (specifically Ed25519).