Software Validation

by Ben Kenobi (PGP Fingerprint: EE5F 99EB E8A8 89AE 1BAF ED64 C9D6 A901 0E89 A3D8)

"You need tech, because yes there always will be bad actors, but you need policy because policy can always subvert tech.  And nothing will be perfect, but I am trying to build a resilient system that is hard to subvert from either direction."

  --- Bruce Schneier - NSA Surveillance and What to Do About It.

1.)  There is no such thing as a perfectly secure computer.

2.)  There are ways to operate within a reasonably secure environment.

Software validation is a tricky thing.

At some point you have to determine an origin of trust.  The procedures I have outlined in this article are not here for the purpose of protecting your data.  Not directly, anyway.

In the realm of security, one of the most dangerous mentalities is that of assuming you are safe or secure.  After this comes the paranoia which could put you at unnecessary risk or, at the very least, forces you to waste your time looking over your shoulder.

Keep It Simple

Your origin of trust must be simple.  A rack of read-only CD media doubles as a source of validation.  Keep this core trust-model simple.

The Operating System

Put your attention on a clean and simple installation, and start from there.

In the spirit of keeping things simple, you will probably want to stick with some flavor of an open-source, UNIX-like operating system.

Having the ability to validate all of your static files is a moot point if they can be subverted while running in memory.  Enable features that randomize memory allocation, and use XOR'd memory tables.  An XOR-style memory table does not allow write and execute permissions to a region of memory at the same time.

The operating system you choose should have some sort of RAM disk kernel, or a method for building one.  Do a bit of research and find out.  It is strongly recommended you use full-disk encryption.  This also provides a reasonable level of validation.

Assemble your tools.

You will need a program which allows you to create public and private keypairs.  You will need a way to create checksums of files, preferably SHA-256 or even SHA-512.  You will also need to have a way to create listings of files in a directory structure, including nested directories.

The Tools

You could do all of this with a few UNIX tools including:

• mtree
• find
• shasum
• sha256
• gnupg
• openssl
• signify

This is not an exhaustive list, and just serves as a jumping point.

While mtree is the Swiss Army knife of directory tree specifications, rsync can also perform checksum validation for a path of files.

Read the man pages for these commands, and experiment with the options they provide.

The Files

Select which files are critical to running a trusted operating system.

It's a good idea to validate the kernel, /etc, /sbin, /bin, /usr, /usr/X11R6, /usr/lib, and so on.

With some tools, there is an option to not go beyond a physical partition or slice.  You can create a directory tree specification for each of these paths.  However, it's probably best to limit yourself to files which will not change over time.  Do not include things like random seeds, many items in /var, cache files, and configuration files in /etc which you regularly modify.  Creating false alarms just results in forming a habit of ignoring alarms.

Once you have a listing of your files in a good state, you need to cryptographically sign those lists with something like GnuPG, or some other asynchronous keypair system.

Anyone with security experience would suggest that you keep the private key off the system to be validated.  It's a great idea to store it on an air-gapped machine.  Air-gapped means that it is never connected to any network or other computer.  Wi-Fi, Bluetooth, and Ethernet should all be disabled.  A USB stick can be reasonably trusted to shuttle data to and from this air-gapped system so long as it does not contain any auto-play or auto-load features.

You could also destroy the private key after signing.  You will never need this private key again.  If your system has legitimately changed, simply verify the legacy items, generate a new keypair, and create a new file validation structure.  Delete that private key, too.

You can leave the public keys on your system for quick verification but you should not consider this a method of ultimate trust.  You can implement tools like chflags or chattr to make these keys virtually impermeable.

To gain ultimate trust in your files, you should validate the public keys themselves, boot from read-only media, and even go so far as to use statically-linked tools.

You can validate your public keys by keeping them on read-only media, and by writing them down on a piece of paper.

Examples

Here's an example of common shell tools doing the labor:

$ find /dir1 -type f -exec sha256 {} ';' > trusted files.txt $ find /dir2 -type f -exec sha256 {} ';' > questionable_files.txt $ diff -u trusted_files.txt questionable_files.txt

Here's an example using tools available in the default install of OpenBSD:

# Create your keypair $ signify -Gn -c 'signing key'-p signing.pub -s signing.sec # Create your mtree specification files $ mtree -cx -K sha256digest -p /etc | signify -Ses signing.sec -x etc.mtree.sig -m - # Delete the private key $ rm -Pf signing.sec # Store the public key in /etc/signify $ mv signing.pub /etc/signify # Validate a directory using this file $ signify -Vqex etc.mtree.sig -p /etc/signify/signing.pub -m - | mtree -xp /etc

Advice

Keep in mind the caveat that you have decided to trust your hardware and the operating system itself, or at least the base install of that operating system.

From there, it is possible to create a method for restoring implicit trust in your data without having to run everything off a LiveDisk or some other form of read-only media.

Hope this helps.