|
|
| (28 intermediate revisions by 3 users not shown) |
| Line 1: |
Line 1: |
| 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.
| | This page can now be found at https://infosec.mozilla.org/guidelines/key_management |
| The Operations Security (OpSec) team maintains this document as a reference guide for operational teams.
| |
| | |
| <table><tr>
| |
| <td><div style="float:left;" class="toclimit-3">__TOC__</div></td>
| |
| <td valign="top">
| |
| {| class="wikitable"
| |
| |-
| |
| ! Document Status !! Major Versions
| |
| |-
| |
| | <span style="color:orange;">'''DRAFT'''</span> ||
| |
| * Version 1: kang/ulfr: creation
| |
| |}
| |
| [[File:OpSec.png|right|300px]]
| |
| </td>
| |
| </tr></table>
| |
| | |
| = 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 ==
| |
| {| class="wikitable"
| |
| |-
| |
| ! 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 ==
| |
| {| class="wikitable"
| |
| |-
| |
| ! 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.
| |
| {| class="wikitable"
| |
| |-
| |
| ! 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 ===
| |
| <source code="bash">
| |
| $ ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_mozilla_$(date +%Y-%m-%d) -C "Mozilla key for xyz"
| |
| | |
| $ ssh-keygen -t ecdsa -b 384 -f ~/.ssh/id_rsa_mozilla_$(date +%Y-%m-%d) -C "Mozilla key for xyz"
| |
| </source>
| |
| === Protection ===
| |
| ==== User Key ====
| |
| ==== Machine Key ====
| |
| 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.
| |
| When non-user keys are generated, a copy of their fingerprint and a description of their usage should be recorded in your team's inventory (e.g. a wiki page, Mozilla inventory, etc.)
| |
| == PGP/GnuPG ==
| |
| | |
| = 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.
| |