The first mode that I implemented for my keyboard was a QWERTY mode. I needed this, because I already know how to type on QWERTY (and fairly quickly at that, over 100WPM). However, one of the goals of the more compact keyboards is to reduce the amount of reaching that is needed to access all of the keys normally. Traditionally, this is done through multiple layers, with things like numbers and symbols mapped to these other layers.

For the past year and a bit, I have been designing and builging my own keyboard. The current iteration, the proto3, is my daily driver, and I like it enough that I bring it with me when I travel. It supports several input modes, that are in different states of completion: QWERTY: This is the closest layout to a traditional desktop keyboard. The next post will summarize how I fit a fairly standard QWERTY keyboard into just 42 keys, while still being able to type nearly everything I could on a regular keyboard.

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.