--- title: Keep It To Yourself date: '2020-04-02' draft: true words: 1199 collection: ramblings --- 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 **Section 1** 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. 1. [The Master Password(s)](#the-master-password) 2. [Key Management](#key-management) - [GPG Keys](#gpg-keys) - [Smart Cards / Security Tokens](#smart-cards--security-tokens) - [Subkeys](#gpg-keys) - [SSH Keys](#ssh-keys) 3. [Password Management](#slave-password-management) - [`pass`](#pass) - [One-time Passwords](#one-time-passwords) **Section 2** Next, we look at best practices for common kinds of personal information. 1. [General Backups](#backups) 2. [Personal Private Information](#personal-private-information) 3. [Secure Online Communication](#secure-online-communication) --- ### The Master Password(s) - Master Password - PINs ### Key Management 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. #### GPG Keys 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](https://sungo.wtf/2016/11/23/gpg-strong-keys-rotation-and-keybase.html). 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 ##### Subkeys 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: `nixpulvis@`. Each 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. ### Password Management 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 fetch` from 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// -> ├── accounts │   ├── accounts.adafruit.com │   │   └── nixpulvis │   ├── aur.archlinux.org │   │   └── nathan@nixpulvis.com │   ├── bbs.archlinux.org │   │   └── nixpulvis │   ├── cloud.digitalocean.com │   │   ├── sever1 │   │   │   ├── nixpulvis │   │   │   └── root │   │   └── nathan@nixpulvis.com ``` ```sh # Copy Adafruit password into your clipboard. pass -c accounts/accounts.adafruit.com/nixpulvis ``` #### Storage The `.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 `git` 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 --- ### Backups I'll be using [`borg`](https://www.borgbackup.org/) to backup my machines, this data is encrypted using a key and password that should live in `pass`. There are a few types of Borg backups to support: ``` backup/ -> backup//key -> ├── backup │   ├── wd2T │   │   └── key │   └── wd2T ``` **Blue-ray Disk Drive Backup** - `borg` key and `pass` password stored on disk - `keyfile*` - Long term - Long write time - Manual disk drive interaction **Local HDD/SSD Backup** - `borg` key and `pass` password stored on device, if trusted and stored safely - either `repokey*` or `keyfile*` - Short term - Fast - Manual HDD/SSD interaction **Remote Backup (Digital Ocean?)** - `borg` password stored in `pass`, no key stored at all - `repokey*` stored in `pass` - Long term but less trustworthy - Network write time fluctuates - Automatic ### 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 though. Other things can be saved in `pass` too, like tax, healthcare, finance, or any other sensitive information. ``` /* -> ├── 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/ -> ├── contacts │   ├── Nathan Lilienthal │   ├── Bob Smith │   │   ├── Personal │   │   └── Work │   ├── Jane Doe ``` - TODO: Private set of contact names