Keep It To Yourself 1360 words drafted on April 02, 2020.
Keeping yourself secure in the modern age of digital computers and the internet is a daunting task. While I like to think I’m somewhat sophisticated in this regard, surely there are flaws in my approach, begging to be exploited and abused. This is somewhat unavoidable, so as a general rule of thumb, don’t be malicious. The following is my current best practices for things that involve information security.
Table of Contents
First we define our master password(s), then we build up a GPG key structure, finally we use the GPG keys to secure a secret database of other passwords, keys, and anything else.
- The Master Password(s)
- Key Management
- Password Management
Next, we look at best practices for common kinds of personal information.
The Master Password(s)
- Master Password
Key management through PGP is the main security concern, from which we can build the rest somewhat easily. Luckily SmartCards can be purchased easily these days, and make some of this much more trustworthy than it may have been in the past.
At the heart of my setup lies PGP (Pretty Good Privacy), a suite of encryption technology with well supported CLI and hardware applications. PGP allows creating key-pairs with sub-keys (more on this later). GPG (the GNU implementation of PGP) is used to encrypt data and manage authentication. We’ll create a new key-pair with 4096 bits. Entropy will be generated by doing the most unusual of things to my computer in the process, you know, for security.
The primary private GPG key itself must be stored safely somewhere, like on a keychain, and rotated from time to time.
NOTE: Rotating keys requires syncing gpg data, which requires all machines to receive a copy of the local data. This is cumbersome, but seemingly needed.
Smart Cards / Security Tokens
I own both a YubiKey 5C and 5C Nano, each with a distinct physical use case. The traditional 5C fits onto my keychain (like with my house keys), and I can use it to plug in and out of computers to authenticate. Meanwhile, the 5C Nano is small enough to stay in a device, making it good for removable secure enclave for your private keys. If you host a personal server, or simply don’t want to think about plugging in your keys then this may be your primary key. I personally feel like the primary key shouldn’t be left in the device, but rather carried on your person. So, I keep the YubiKey 5C around as my primary key, and leave my 5C Nano in a safe place, as a backup. They are each distinct keys, so care must be taken to ensure data allows either key as needed.
- TODO: YubiKey setup process
In addition to SmartCard keys, conventional GPG keys can be generated and used.
- TODO: How to create these, and when to use them?
- TODO: Sub-key structure.
SSH (Secure Shell) Keys
SSH keys should named, with the following format:
key will be saved by name in a
pass directory called
SSH. This way we can
control access to individual hosts.
- TODO: Implement this.
- TODO: Note it’s stored in
pass, more on below.
Once we have our key management taken care of and our master password(s) /
PIN(s) are memorized, we can rely on
pass for managing various other
passwords and other secret data. Both our primary GPG key, and a backup will be
used for this password store. These passwords are generally generated, and
therefor not memorized. Some kinds of accounts may be best to memorize
still, just make sure they aren’t the same password as the master passwords
from our key management.
- TODO: Backup (stored in clear in a safe?) GPG key
pass stores it’s data in a plain ol’ folder, making it work perfectly with
git. In fact
pass git ... can be used to perform arbitrary commands from
anywhere on the system. We currently store user ids in the folder name, so the
repo must be private. I’m currently only storing this repo on devices and
syncing with either SSH, or a USB drive.
- TODO: How to use SSH to
git fetchfrom another device.
- TODO: How to use a USB drive as a git remote.
pass shows each record like a file within the directory tree
~/.password-store by default).
accounts/<url>/<username> -> <password> ├── accounts │ ├── accounts.adafruit.com │ │ └── nixpulvis │ ├── aur.archlinux.org │ │ └── firstname.lastname@example.org │ ├── bbs.archlinux.org │ │ └── nixpulvis │ ├── cloud.digitalocean.com │ │ ├── sever1 │ │ │ ├── nixpulvis │ │ │ └── root │ │ └── email@example.com
# Copy Adafruit password into your clipboard. pass -c accounts/accounts.adafruit.com/nixpulvis
.password-store data will live on each machine, an encrypted USB drive
and a private repo hosted somewhere good and encrypted.
Remember that the contents of
pass are in an unprotected
repository. So, while the data under each entry is protected with our keys,
someone with access to the repo can, for example, run
git log on the changes
made to the password store. Bee careful to avoid manual commit messages that
leak information, or other non-standard
pass practices. It’s best to simply
avoid storing the password store anywhere in the clear.
- TODO: Master (in the head) passwords, re: smartcard backup
I’ll be using
borg to backup my machines, this
data is encrypted using a key and password that should live in
are a few types of Borg backups to support:
backup/<device> -> <password> backup/<device>/key -> <borg_key> ├── backup │ ├── wd2T │ │ └── key │ └── wd2T
Blue-ray Disk Drive Backup
passpassword stored on disk
- Long term
- Long write time
- Manual disk drive interaction
Local HDD/SSD Backup
passpassword stored on device, if trusted and stored safely
- Short term
- Manual HDD/SSD interaction
Remote Backup (Digital Ocean?)
borgpassword stored in
pass, no key stored at all
- Long term but less trustworthy
- Network write time fluctuates
Personal Private Information
PII (Personally Identifiable Information) like my SSN, healthcare IDs and other
various sensitive information should be included in
pass and nowhere else…
well, at least digitally, of course the original documents should be stored in
a safe/wallet or something.
In a system of cryptographically ensured ownership semantics (QM?), it’d be
very cool to ensure these values “lived”, for lack of a better word, in my
pass repo. I have no idea what an implementation of this would look like
Other things can be saved in
pass too, like tax, healthcare, finance, or any
other sensitive information.
<note>/* -> <note> ├── health │ └── ... └── taxes ├── 2017 └── 2018
Other people’s contact information is private. We can store both public names with their fingerprints (or other potentially private information):
contacts/<name> -> <gpg_fingerprint> ├── contacts │ ├── Nathan Lilienthal │ ├── Bob Smith │ │ ├── Personal │ │ └── Work │ ├── Jane Doe
- TODO: Private set of contact names