MCUboot is a bootloader for microcontrollers. It has a fairly long history and has been under development for a number of years. Over the years, it has gained some significant functionality, and is used as the bootloader for a number of projects (TF-M and Zephyr coming to mind). MCUboot is somewhat unique as an embedded application in that it tends to be fairly isolated. There are a lot of other projects that make use of MCUboot itself, but MCUboot itself does not have a large number of dependencies.

I have been asked several times about whether the log4j vulnerability affects Zephyr. There is kind of a tendency to give a glib answer “Zephyr is an embedded RTOS, and doesn’t run Java.” Although this is true, it is important to understand that Zephyr doesn’t live alone, especially as devices become more connected, and evaluating this vulnerability should still be done. The first place to look is indeed the source code to the Zephyr project itself.

My blog has been stale since 2018. There have been several reasons behind this. One is that with upgrades to Hugo, my site was no longer rendering. I have since created a new site directory, and copied the content from the old site to the new. In addition, the Ubuntu image running the server has started to feel fragile, and I’ve been concerned about making any changes to it. I have since set this new site up using NixOS, which among other features, allows me to specify the entire configuration of the machine in a fairly simple, small file.

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.

Security analysis of Cloud IoT services Below is my analysis of Google’s “Cloud IoT Core” and Amazon’s “AWS IoT Core”, from a security perspective. The “Core” service from both of these providers is very similar, and consists of a message broker that supports a publish/subscribe model. In both cases, it is possible for an external host to subscribe to messages, as well as to have messages sent to various compute resources within the respective provider’s cloud offerings.

This is a bit unusual of a post, as it is more of a brain dump than a nicely written prose. I may fill this in over time. TLS and why it is hard Introduction In an ideal magical world, TLS is a thing you drop into a connection and it becomes secure. Both parties just communicate as if they were read/write send/recv packets, but everything is secured. The problem is that, although the communication is “secure”, it is crucial that you know who you are talking to.

Recently, I’ve been looking at using Amazon Glacier for some of my off-site backup needs. I already have a small amount of my data being stored in s3, and the lower cost of Glacier ($0.004/GB-month) make it a possibility for backing up even more data. Since I intend for these backups to be fairly long time, I wanted to do a little analysis, comparing it with something like LTO-6. A LTO-6 tape drive looks to cost about $3000.

My regular job has me working, from time to time, with both Go and Rust. Both of these languages have a good following, and strong communities behind them, and there are things I enjoy about both languages. For the most part, if I am writing a utility for personal purposes, I will choose one of these two languages (notably, not Python). Several of my projects, I find myself maintaining in both Go and Rust, because I can’t make up my mind as to which I prefer, or which is a better fit for the problem.

I have been paying for an Adobe Creative Cloud subscription for around a year now. In order to help justify this expense, I’ve given myself a goal to learn the other programs in the suite that I don’t yet use (I primarily use Illustrator, Photoshop and Acrobat). I started with Premiere. Coming from Final Cut (before the “X” version which seems to have turned it into a toy), the user interface initially felt very different.