Posts

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)

• RFC5208: Public-Key Cryptography Standards (PKCS) #8: Private-Key Information Syntax Specification Version 1.2 (obsolete)

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. As long as I stick with one particular implementation, I can probably get reasonable results.
  • Jekyll is written in Ruby, and Hugo in Go. There seems to be a lot of influence of Rails’ convention over configuration in Jekyll. I found it more difficult to do things differently than the particular conventions it was set up for. To me, this also has the advantage that Hugo compiles to a single executable, and doesn’t require an external environment manager (bundle) to be able to run the tool. I can copy the built executable to other machines and just run it.
  • Using Jekyll for blog-style writing only seems to work with a small subset of the themes. It seems that the blog support is more a feature of particular themes than of Jekyll itself.
  • Themes in Jekyll are managed through gem dependencies. This restricts the themes available within Github pages (basically one blogging theme). In Hugo, the themes are in a subdirectory, and are typically brought in through a git submodule.
• Disadvantages of Hugo
  • The BlackFriday Markdown parser in Hugo is, unfortunately, strict about requiring 4 spaces for indentation of nested lists. This tends to look weird in the input source, and two character indented lists get flattened. Apparently, the creator of Markdown thought tabs were 4-spaces (they are not), and that lists should be indented with tabs.
• Advantages of Hugo
  • Hugo also supports Emacs org mode as a markup format. I have not experimented with this, but it may be useful for rendering data that is primarily list oriented.
  • Hugo seems to be a bit better at typography. For example, it converts plain ASCII quotation marks into typography quotes, as in “This is quoted”. It recognizes two hyphens as an n-dash: 5–7; three hyphens as an m-dash—such as this.
  • There seem to be a lot more support for things built-in to Hugo. Perhaps these are available as extensions to Jekyll. I will perhaps investigate using LaTeX style math if I ever need that.

I’ll perhaps update this post a bit as I discover other things I like or dislike about Hugo.

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). However, with increased connectivity, we are starting to see more and more security problems with the code in these devices.

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]({% post_url 2017-09-10-backups %}), I describe how I’m doing that, and even testing it. Then things would roughly following the following steps:

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:

1. 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.
2. Accident recovery. When something is accidentally erased or modified, how can I recovery that file or directory in a state it was in in the past.

These scenarios place different demands on the backup system. They also combine in interesting ways. For example, if after a disaster recovery, how can an older version of a file be restored.