Information security

Here are some information security tips. This list is a work in progress.

Checklist

CIA model:

  • Confidentiality
  • Integrity
  • Availability

Practical tips

Privacy

Privacy Not Included

Maps

Travel

Before travelling

  • Make a backup of all important data.
  • Install the latest security updates.
  • Encrypt all devices that contain sensitive data. Merely having a login password does not prevent an attacker from extracting data from the device.
  • Enable biometric authentication only when used as a part of a multi-factor authentication. Many countries have legislation that permits the authorities to force one to perform biometric authentication, whereas in the western world passwords often fall under the self-incrimination protection.
  • Have a verified boot chain on all of your devices to prevent tampering. On PCs this means enabling Secure Boot, protecting the UEFI/BIOS with a password and enabling UEFI/BIOS rollback protection. On Android one should preferably have a locked bootloader.
  • To ensure that your laptop will not be tampered with, put a bit of nail polish on one of the laptop screws. Preferably use a nail polish with e.g. glitter that creates unique patterns. Take a picture of these patterns.

When travelling

  • Do not connect untrusted peripherals or cables. Even a regular-looking USB cable (such as the O.MG cable) can contain a chip that can infect a computer, or even wireless connectivity for remote control! The only exception to this are monitors over display cables (HDMI, DisplayPort, DVI, VGA), as their capabilities for transferring anything else than video is rather limited. However, connecting a monitor with USB-c is not safe!
  • Do not plug your devices to untrusted USB ports. Only charge your USB devices using trusted chargers. This includes laptops.
  • Do not leave your laptop unattended, even in the hotel room. Even the safe in your hotel room is not safe, as the hotel personnel can access it.
  • If you are dealing with sensitive data, do not connect your devices to high-risk networks such as public Wi-Fi. Buy a local cell phone / data plan instead.

Securing a Windows desktop

  • Keep Windows updated
  • Keep apps updated
  • Enable Secure Boot and TPM
  • Enable BitLocker

Disk encryption

Securing cloud services

Securing a Linux desktop

  • Enable LUKS disk encryption when installing the OS.
  • Keep software updated: apt-get, snap, flatpak etc.
  • Enable firewall
  • Enable Secure Boot

Disk encryption

Securing a Linux server

  • Disable SSH password authentication and use keyfiles instead
  • Keep software updated: apt-get, snap, flatpak etc.
  • Enable firewall
  • Enable Secure Boot
  • Restrict physical access
    • Lock the case
    • Put the server in a locked rack
    • Attach the case or rack to the building with a lock

Firewall

Enabling the firewall

sudo ufw default deny
sudo ufw enable

Allowing a program to receive connections:

sudo ufw allow <port_number> comment "My program"

Securing an Android device

  • Keep the firmware (aka. Android version) up to date
    • Every month several vulnerabilities are discovered in Android and fixed. Therefore a device that is not up to date will most likely have well-known critical vulnerabilities waiting to be exploited.
    • If your device no longer receives security updates from the manufacturer, you should switch to an alternative firmware such as LineageOS or buy a new phone.
  • Install only the apps that you need
    • Even a single malicious app is enough to compromise a phone.
  • Reduce the permissions given to apps
  • Keep Bluetooth disabled if you don’t need it

Securing a router

The most important thing about securing a router is keeping it up to date. Most manufacturers are notoriously poor in providing security updates for their devices, and if they do, it’s often only for a few years. If a router no longer receives security updates, you should not connect it to the internet! Depending on the latest security updates it received, you may be able to repurpose it as e.g. an additional Wi-Fi access point within your own network, though.

Many old devices also lack important settings and features such as 802.11w management frame protection that protects from deauth jamming, and countermeasures for the KRACK attacks. However, it should be noted that old client devices may not be compatible with these protections. If you are still using such devices, you should create a separate Wi-Fi SSID for them so that you don’t have to reduce the security for the rest of your devices.

OpenWRT is perhaps the most feature-rich and well-maintained custom firmware, and it’s also open source. Please see whether your device is compatible with OpenWRT. If it’s not, please see whether it’s compatible with some other notable custom firmware, such as:

For further details on the firmware compatibility, please see my purchase guide.

These alternative firmwares include:

Please see the purchase guide on instructions for purchasing a router.

  • When buying a new router, I recommend choosing a model that is supported by one or more of these, as it will help ensuring that the router will have a long lifespan and not just the year or two that manufacturers typically provide security updates for.

DNSSEC

DNS is the protocol that connects human-readable urls such as “google.com” to addresses that routers know to send traffic to, such as “216.58.210.174”. By default this is done without any kind of validation, and is relatively trivial to spoof. DNSSEC is a method for validating the authenticity of this information, preventing malicious modifications. You can test whether you have DNSSEC enabled with this DNSSEC test. If you don’t please switch to a secure DNS provider such as one of those in the following section.

DNS over TLS

By default, DNS queries are sent without any kind of encryption. This means that anyone snooping on the connection can see the names of the websites you are visiting. You can avoid this by using DNS over TLS (DoT).

DNS providers

The DNS provider can see the names of all websites you visit. Therefore, it is important to choose a provider that respects your privacy. Some DNS providers can also filter out ads and malware. When choosing a DNS provider, you should ensure that they support at least DNSSEC and DNS over TLS. My recommendations are:

OpenVPN

I’ve found that these settings work well enough. Please let me know if there’s something to be improved.

  • Server mode: Remote Access (SSL/TLS)
    • This is more secure than a shared key or user auth.
  • Device mode: tun - Layer 3 Tunnel Mode
    • In most use cases there’s no need for tap (OSI layer 2).
  • Protocol: UDP IPv4 and IPv6 on all interfaces (multihome)
  • Local port: preferably the default of 1194. If you have multiple servers, just increment the port number.
  • TLS configuration: Use a TLS Key, and automatically generate it.
  • Peer Certificate Authority: see the cryptography section
  • DH Parameter Length: ECDH only
  • ECDH Curve: See the cryptography section
  • Data Encryption Algorithms
    • AES-256-GCM
    • CHACHA20-POLY1305
    • If you want better performance, also add AES-128-GCM
  • Fallback Data Encryption Algorithm: AES-256-CBC
  • Auth Digest Algorithm
  • Hardware Crypto
    • “When left unspecified, OpenVPN will choose automatically based on what is available in the operating system to accelerate ciphers OpenVPN wants to use.”
    • “In most common deployments this setting is unnecessary as the automatic behavior of OpenVPN is correct.”
    • AES-NI is enabled automatically regardless of this setting.
  • Certificate depth: One (Client+Server), unless you have some fancy PKI setup.
  • Client Certificate Key Usage Validation: yes
  • Allow Compression: Refuse any non-stub compression (Most secure)
  • Duplicate Connection: yes if multiple devices use the same client certificate
  • Dynamic IP: yes
    • This is necessary to allow the clients to switch e.g. from mobile data to Wi-Fi without interrupting connectivity
  • DNS Server enable: yes if you want the clients to access e.g. Active Directory
  • Block Outside DNS: yes to ensure that local domain names are queried from the local DNS servers
  • Force DNS cache update: yes
  • UDP Fast I/O: Enable. I’ve had no trouble with this.
  • Send/Receive Buffer: change this from the default value according to the instructions on the config page

Hardware security keys

Services that support YubiKey/WebAuthn, including:

Services that will support YubiKey/WebAuthn in the future

Resetting a YubiKey

ykman fido reset
ykman oath reset
ykman openpgp reset
ykman otp delete 1
ykman otp delete 2
ykman piv reset

Configuring a YubiKey

Verify on this page that the YubiKey is genuine.

ykman fido access change-pin

Setting up SSH authentication

Check that your clients and servers have OpenSSH 8.2 or later:

ssh -V

Create the SSH key (Yubico instructions). Use ed25519-sk instead of ecdsa-sk, as the latter is difficult to implement without side-channel vulnerabilities. See the cryptography section for details.

ssh-keygen -t ed25519-sk -O resident -O verify-required

Support has been requested for

SSH authentication with TPM

If you want to use SSH without having to touch a physical security key, you can store the SSH keys on a TPM instead.

Windows

On Windows you can use the TPM for SSH with the SSH client included in Git. You can install Git with my installer script or with the command below. The parameter /GitAndUnixToolsOnPath enables the SSH client included in Git for the terminal. The parameter /WindowsTerminalProfile is optional.

choco upgrade git.install -y --force --params "/GitAndUnixToolsOnPath /WindowsTerminalProfile"

Now you can create the SSH key with:

ssh-keygen -t ed25519-sk

If your device does not support the ed25519 algorithm, you can create an ECDSA key with:

ssh-keygen -t ecdsa-sk

Linux

On Linux you can set up SSH keys on a TPM with the commands below. These instructions are based on the instructions in Gentoo wiki

sudo apt-get install libtpm2-pkcs11-1 libtpm2-pkcs11-tools
sudo usermod -a -G tss "${USER}"
# Log out and back in for the group membership to be applied.
# If this command does not work without sudo, reboot the computer.
tpm2_ptool init
# Create long random PINs and write them down in e.g. your password manager software
tpm2_ptool addtoken --pid=1 --label=ssh --userpin=MySecretPassword --sopin=MyRecoveryPassword
# See the list of supported algorithms. If ed25519 is there, use it. (As of 2023, it's not yet supported.)
tpm2_ptool addkey --help
# If you get an error, try rsa2048 instead
tpm2_ptool addkey --label=ssh --userpin=MySecretPassword --algorithm=rsa4096
# Retrieve the public key from the TPM
# https://github.com/tpm2-software/tpm2-pkcs11/issues/792
TPM2_PKCS11_LOG_LEVEL=0 ssh-keygen -D /usr/lib/x86_64-linux-gnu/libtpm2_pkcs11.so.1
# Load the stored key into the SSH agent
ssh-add -s /usr/lib/x86_64-linux-gnu/libtpm2_pkcs11.so.1

Use RSA instead of ECDSA, since ECDSA is difficult to implement without side-channel vulnerabilities. Such vulnerabilities have already been found in TPMs. ED25519 is in the TPM specification and support for it has been requested for tpm2-pkcs11, but TPM manufacturers will first have to implement the algorithm in their devices. As of 2023, no TPM manufacturer has yet done so.

YubiKey with KeePassXC

Setting up PGP

These instructions are a work in progress.

Change the user and admin PINs

gpg --change-pin

Require touch for using the YubiKey

ykman openpgp keys set-touch aut on
ykman openpgp keys set-touch enc on
ykman openpgp keys set-touch sig on

Feed entropy from the YubiKey to the system pseudorandom number generator (PRNG)

echo "SCD RANDOM 512" | gpg-connect-agent | sudo tee /dev/random | hexdump -C

Generate the master key

gpg --expert --full-gen-key
  • Do not set an expiry date

TODO

Verify that the sub-keys have been moved to the YubiKey

gpg -K

Bluetooth

  • Bluetooth versions prior to 4.2 are fundamentally broken.
    • Bluetooth 4.0 and 4.1 key exchange is broken, allowing an attacker to decrypt the traffic, sometimes in less than a second.
  • Bluetooth 4.2 introduces the LE Secure Connections (LESC), which improves the security significantly.
    • LESC has four security levels
      • Level 1: no encryption
      • Level 2: AES-CMAC (aka. AES-128, RFC 4493, FIPS-compliant), no pairing required
      • Level 3: encryption and with pairing requirement
      • Level 4: ECDHE authentication with the P-256 curve
        • P-256 is one of the NIST curves and notoriously difficult to implement. Therefore, I won’t be surprised if and when vulnerabilities are found in the implementations.
    • LESC also has four security modes
      • Mode 1: no signing
      • Mode 2: signing for both paired and unpaired connections
      • Mixed security mode: support for both mode 1 and 2
  • When purchasing Bluetooth keyboards, ensure that they support at least Bluetooth 4.2, preferably Bluetooth 5.0 or above.
  • Most devices prior to 2018 are vulnerable to the KNOB attack.
  • Bluetooth 4.2 - 5.4 are vulnerable to BLUFFS MITM attack.

Cryptography

See this site for the key length recommendations of various organizations.

RSA

  • Use key sizes of at least 2048 bits, and 4096 bits for CAs.
  • Note that many hardware devices, such as TPMs, cannot store keys longer than 2048 bits.
  • With TLS and OpenVPN, the key sizes affect the performance of only the negotiation handshake at the start of the connection and during renegotiation, which for OpenVPN happens once per hour.

Diffie-Hellman parameters

Elliptic Curve Diffie-Hellman (ECDH)

Hashing