# Securely Updating Software: The Update Framework

- Link: https://www.agilicus.com/the-update-framework/
- Published: 2021-01-19T06:00:00+00:00
- Author: Don Bowman

Software. You know it will need updating. Every consumer product you have ever bought
the first thing it did was to install the “real” version. How do we securely update
software? Let’s talk about [The Update Framework](https://theupdateframework.io/).

Freshness is one of the battles in the software operations world. It seems like 
every piece of software requires loving hand feeding and care for hourly updates.
Wouldn’t it be great if software could just care for itself and stay up to date?
What’s that you say? You are concerned about auto-updating software? How will that
be secure? Well, pull up a chair and let me tell you the tale of [The Update Framework](https://theupdateframework.io/),
achieving the goal of auto-update and secure together at last.

Nearly all of our software is run in our cloud, by us. We use Dependabot and our
CI and CD to keep it fresh. But one of our [Features](https://www.agilicus.com/anyx-guide/agilicus-connector/)
is a connector that runs on your site. And, we want that to be zero cost to you 
to keep up to date, safely, securely.

The Update Framework is a [CNCF](https://www.cncf.io/) project. It was originally
envisaged for deeply embedded systems such as Automobiles (you can see [Uptane](https://uptane.github.io/)).
In a nutshell you create a set of signing keys:

 * root key: used to sign and rotate the other keys
 * target key: used to sign a new binary (target)
 * snapshot key: used to sign the set of binaries, e.g. “this is version 3, use 
   these 9 files together”.
 * refresh key: used to show the repo itself is being updated

In your software you ship to your customer site you put a library (there are implementations
for several languages of The Update Framework). This periodically polls your online
repo. If it finds there are updates, it pulls and runs them.

For security the signing keys make sure that the clients at the customer site will
ignore any tampering. But, to make this secure, you need to segregate and control
those signing keys above. And this is where it gets complex.

First, the root key, you want this offline only. You want to only access this once
a year or so, when you rotate the other keys. It should be nearly impossible for
a bad-actor to get it. I choose to cipher it with a multi-word passphrase. The passphrase
I used said “Approximate Crack Time: 1,482,947,715,526,880,400 centuries”, so, well,
that probably won’t be the method they get me. The key itself is strong (perhaps
not quantum proof, but certainly strong enough). So the private key, ciphered w/
that passphrase, now we need to protect it. For this I have chosen not to use a 
Hardware Security Module ([HSM](https://en.wikipedia.org/wiki/Hardware_security_module)).
Instead, I’ve placed it on a pair of USB keys which I will place in secure locations.

Now, use the root key to create the target/snapshot/refresh key. These are placed
into [Google Secret Manager](https://cloud.google.com/secret-manager), and then 
we use IAM to indicate who can access these, and when. This provides my audit trail.

Our CI is taught to run a daily refresh job, it will handle the refresh job, we’ll
deal with the target updates manually, when we decide what to publish.

All in all, not too complex. Using the update framework we have obtained high integrity
update chain, fully automatic, low effort for customer, low effort for us, low risk
of tampering.