MozillaWiki

Security/Guidelines/Key Management

< Security‎ | Guidelines
Revision as of 21:57, 23 October 2014 by Gdestuynder (talk | contribs) (→‎PGP/GnuPG)

The goal of this document is to help operational teams with the handling and management of cryptographic material. All Mozilla sites and deployment should follow the recommendations below. The Operations Security (OpSec) team maintains this document as a reference guide for operational teams.

Document Status Major Versions
DRAFT
  • Version 1: kang/ulfr: creation
OpSec.png

Data Classification

Key material

Key material identifies the cryptographic secrets that compose a key. All key material must be treated as restricted data, meaning that only individual with specific training and need-to-know should have access to key material. Key material must be encrypted on transmission. Key material can be stored in clear text, but with proper access control.

Public certificates

Public certificates are public and do not require specific access control or encryption.

Algorithms by security levels

This section organizes algorithms and key sizes for a given validity period that represent the level of security provided. While 10 years validity may be a requirement for very static keys, such as Root CAs, we do recommend preferring 2 years keys and implementing reliable key rotation, instead of trying to keep key material for long periods of time.

10 years

Type Algorithm and key size Bits of security
Asymmetric encryption RSA 4096 bits 144 bits
Asymmetric encryption ECDSA 384 bits 192 bits
Symmetric encryption AES-GCM 192 bits 192 bits
Hash & HMAC SHA-384 192 bits
Hash & HMAC SHA3-384 192 bits

2 years

Type Algorithm and key size Bits of security
Asymmetric keys RSA 2048 bits 112 bits
Asymmetric keys ECDSA 224 or 256 bits 112 bits
Symmetric encryption AES-CBC 128 bits 128 bits
Hash & HMAC SHA-256 128 bits
Hash & HMAC SHA3-256 128 bits

Legacy, not recommended

The following algorithms and sizes are still widely used but do not provide sufficient security for modern services and should be deprecated as soon as possible, unless backward compatibility is a requirement.

Type Algorithm and key size Bits of security
Asymmetric encryption RSA 1024 bits and below 80 bits
Asymmetric encryption ECDSA 160 bits and below 80 bits
Symmetric encryption 3DES 112 bits
Symmetric encryption RC4
Hash & HMAC SHA-1 80 bits
Hash & HMAC MD5 64 bits

Handling

X509 Certificates and Keys

SSH

Generation

$ ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_mozilla_$(date +%Y-%m-%d) -C "Mozilla key for xyz"

# ECDSA keys are only compatible with OpenSSH 5.7+
$ ssh-keygen -t ecdsa -b 384 -f ~/.ssh/id_rsa_mozilla_$(date +%Y-%m-%d) -C "Mozilla key for xyz"

Protection of User Keys

As SSH keys are rarely renewed the minimum recommended settings are higher than other keys. If you follow a strict key renewal period of less than 2 years, it is reasonable to use RSA 2048 bits or ECDSA 224 bits keys.

  • Protected by strong passphrase.
  • Never copied to another system than your own workstation/personal physical disks/tokens.
  • Use SSH forwarding or SSH tunneling if you need to jump between hosts. DO NOT maintain unnecessary agent forwarding when unused.

SSH Agent Forwarding

ATTENTION
SSH Agent forwarding exposes your authentication to the server you're connecting to. By default, an attacker with control of the server (i.e. root access) can communicate with your agent and use your key to authenticate to other servers without any notification (i.e. impersonate you).
For this reason, one must be careful when using SSH agent forwarding. Defaulting to always forwarding the agent is strongly discouraged.
Note also that while the attacker can use your key as long as the agent is running and forwarded, he cannot steal/download the key for offline/later use.

SSH forwarding allows you to jump between hosts while keeping your private key on your local computer. This is accomplished by telling SSH to forward the authentication requests back to the ssh-agent of your local computer. SSH forwarding works between as many hosts as needed, each host forwarding new authentication request to the previous host, until the ssh-agent that holds the private key is reached.

 

On each host, two environment variables are declared for the user enabling ssh-agent:

  • $SSH_AUTH_SOCK declares the location of the unix socket that can be used to forward an authentication request back to the previous host.(ex: /tmp/ssh-NjPxtt8779/agent.8779). Only present if using SSH agent forwarding.
  • $SSH_CONNECTION shows the source IP and port of the previous host, as well as the local IP and port. (ex: 10.22.248.74 44727 10.8.75.110 22).

To use ssh-agent, add the flag -A to your ssh commands: 

$ ssh -A user@ssh.mozilla.com

Alternatively, you can set the following configuration parameter in your local ssh configuration at ~/.ssh/config. 

Host ssh.mozilla.com
    ForwardAgent yes

Alternative to SSH agent forwarding (safer)

It is possible to directly forward ports for single jumps instead of forwarding the agent. This has the advantage of never exposing your agent to the servers you're connecting to.

For example, you can add these lines to your ~/.ssh/config 

Host *.mozilla.com
ProxyCommand ssh ssh.mozilla.com -W %h:%p

This will automatically forward the SSH connection over ssh.mozilla.com when you connect to a mozilla.com SSH server.

Protection of Machine Keys

When SSH keys are necessary for automation between systems, it is reasonable to use passphrase-less keys.

  • The recommended settings are identical to the user keys.
  • The keys must be accessible only by the admin user (root) and/or the system user requiring access.

Usage of machine keys should be registered in an inventory (a wiki page, ldap, an inventory database), to allow for rapid auditing of key usage across an infrastructure.

PGP/GnuPG

$ gpg --gen-key
(1) RSA and RSA (default)
[...]
Your selection? 1
[...]
What keysize do you want? (2048)
[...]
Key is valid for? (0) 2y
[...]

Protection of user keys

  • Protected by strong passphrase.
  • Never copied to another system than your own workstation/personal physical disks/tokens.

Protection of machine keys

  • Storing the key material in a hardware token or HSM is preferred over simply using a strong passphrase.
  • The keys must be accessible only by the admin user (root) and/or the system user requiring access.

Usage of machine keys should be registered in an inventory (a wiki page, LDAP, an inventory database), to allow for rapid auditing of key usage across an infrastructure.

Choice of algorithm

Expiration of keys

As GnuPG trust model belongs to your master key, some may decide to not expire their master key. This is reasonable if the master key is very well protected, and a separate sub-key (or sub-keys) are used for day to day signing and encryption. For example, the master key could be stored offline and never copied or used on an online system.

Note: It is possible to change the expiration of a key, however all clients must fetch updates on a key server or will see your key as expired.

GnuPG settings

By default, GnuPG may use deprecated hashing algorithms such as SHA1 when used for signing. These settings ensure a more modern selection of hashing algorithms.

File: ~/.gnupg/gpg.conf 

personal-digest-preferences SHA256
cert-digest-algo SHA256
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed

Definitions

Bits of security

Security Bits estimate the computational steps or operations (not machine instructions) required to solve a cryptographic problem (i.e. crack the key/hash).

For a more detailed definition, see http://en.wikipedia.org/wiki/Key_size and http://www.cryptopp.com/wiki/Security_Level#Security_Bits.

Retrieved from "https://wiki.mozilla.org/index.php?title=Security/Guidelines/Key_Management&oldid=1027751"