An improvised weeknight mole using roasted poblanos and fresnos, with peanut butter and cocoa for depth — no tomato, no added salt.

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. Accessing these, is then done with additional shift-type keys that access 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.
• Steno: This is a strict chord keyboard (multiple keys are pressed together and released) built around 23 keys (plus two extra in my design). On the proto3, this uses the top two rows, and the thumb keys. The lower finger row is treated entirely as the number bar, except that it isn’t in the right place, and ends up not being particularly useful. Instead, I use what are affectioniately known as “thumber” keys–the keys to the outside of the traditional vowel keys. My theory, Phoenix, does not require the number bar, so this works out. I have started incorporating number shifts into my shortcuts I use for programming language constructs.
• Local Steno: Intended as the same use as the above steno mode, but instead of sending the raw strokes over a special protocol on an CDC/ACM USB endpoint, the dictionary lookups and translations are done locally on the keyboard. This is incomplete. The dictionary lookup is implemented, but I need to work through all of the rules for stitching text together, while supporting an undo stroke.
• Taipo: The last layout, and the subject of this post.

Taipo, is a slightly chorded keyboard. When I first looked at Taipo, it just looked like another variant of something like Artsey, but with use of two thumb keys making for less state, and no holding down of keys.

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. It needs the ability to run as an early application on the target, operate on the flash device, and perform some cryptographic operations. It optionally can support some types of logging to help with debugging and development.

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. For the most part, Zephyr targets small embedded CPUs (microcontrollers) that frequently have memory sizes that are measured in tens or hundreds of kilobytes, with megabytes being available in a large system. A simple glance at the latest Apache log4j shows that the core jar file is 1.8 megabytes itself. Just the jarfile alone is larger than the memory on the targets that Zephyr supports.

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. As the internals of these provider’s implementations are not available, this document makes no attempt to analyze the security within the provider’s network, but to evaluate the security concerning the communication between the individual devices and the service.

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. Without this, the encrypted part of the communication is completely meaningless, as you may be communicating with your adversary.