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).
I’ve now been using an Amazon “t2.nano” EC2 instance for my web hosting. These are designed to allow “Burstable Performance”. Amazon has a few different descriptions from the simplistic: T2 instances accrue CPU Credits when they are idle, and use CPU credits when they are active. to a much more detailed explanation. The later document says that the credits are processed at millisecond resolution. But, the free monitoring tools only sample at 5-minute granularity, so it is difficult to see anything of finer granularity than that.
This post is going to be a bit technical, as I will describe in some detail the final setup for hosting for davidb.org. Most of the steps that I follow come from Digital Ocean’s article How To Secure Nginx with Let’s Encrypt on Ubuntu 16.04. The only step not necessary from these instructions was Step 3 on Updating the Firewall. The AWS Ubuntu images do not have an active firewall, as their networking configuration has a fairly aggressive firewall already in place.
I have completed the migration of this site from Jekyll to Hugo. After using Jekyll for a few days, I quickly discovered many of its limitations, and felt it would be useful to provide a bit of a comparison. Common Both are static site generators, and use fairly similar configuration formats. Both prefer Markdown for page markup. Both also contain specific implementations of Markdown, and so will likely differ slightly in their interpretation of the poorly-defined ill-conceived “specification” of Markdown.
Last night, I finally got all of the pieces together for hosting of this site. Here, I will summarize what solution I ended up going with, and a little about my future plans. Static site After convincing myself that Markdown is only terrible (instead of utterly terrible), and that it would be ok for short postings like I intend to make here. I got this site set up with Jekyll for static site generation.
This post is going to focus on some particular security issues in the embedded space (the IoT space, if you will). I regularly work with microcontrollers (MCUs) based on variants of the Cortex-M architecture. These are ARM processors that typically have a small amount of ROM (½–1 MiB) and an even smaller amount of RAM (16–128 KiB). Traditionally, security has not been much of a focus on these types of devices (think toasters, washing machines, and the likes).
Today, I migrated my primary Ubuntu 17.04 development machine to put the root volume onto a thinly provisioned volume. There was a bit of a comedy of errors, so I want to outline what I should have done, vs what actually happened. What I should have done As in anything like this, it is important to start with known good backups. In my backup post, I describe how I’m doing that, and even testing it.
For my first post, I’d like to discuss some of my strategy that I use for backups. Backups are one of those things that most people realize are important, yet most people don’t really do them consistently. Aside from that, I’ve found that very few people test their backups. There are two scenarios that backups are important for: Disaster recovery. After a hard disk crash or other failure, how can I recovery a machine to the state it was in before the crash.