You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Cryptographic requirements at Unity are heavily influenced by NIST's *Cryptographic Standards and Guidelines (CSRC)* documentation. Below are our condensed recommendations.
> NOTE: Where possible, we recommend Elliptic Curve Cryptography (ECC / ECDH), with Curve25519 (for signatures and key exchange)
3
+
<fontsize="-1">*Brandon Caldwell Jan 2019*</font>
12
4
13
-
### Usage Recommendations
14
-
##### TLS - Cipher Suites
5
+
## Overview
15
6
16
-
_Minimum TLS version = TLS1.2._
7
+
This document provides guidelines for how utilize encryption to protect data in transit and at rest. Cryptographic requirements at [COMPANY_NAME] are heavily influenced by NIST's Cryptographic Standards and Guidelines (CSRC) documentation.
17
8
18
-
All cipher suites below should be compatible with version >= TLS 1.2 . SSL 3.0 and below are not allowed.
9
+
## Recommendations
19
10
20
-
Accepted TLS Cipher suites:
11
+
### Store the Cryptographic Hash of a Password
21
12
22
-
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
23
-
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
24
-
- TLS_ECDHE_ECDSA_WITH_AES_128_CCM
25
-
- TLS_ECDHE_ECDSA_WITH_AES_256_CCM
26
-
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
27
-
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
28
-
- TLS_AES_128_GCM_SHA256
29
-
- TLS_AES_256_GCM_SHA384
30
-
- TLS_AES_128_CCM_SHA256
13
+
User passwords should be stored as cryptographic hashes. Cleartext or encrypted password storage are not permitted. For more information on the reasons behind this, check out [this article](https://auth0.com/blog/hashing-passwords-one-way-road-to-security/) by Auth0. Most services at Unity should never have to worry about storing a password as for 99% of the cases this is what Genesis, Okta, and GCP OAuth are for. In the rare case a password storage mechanism is needed, **use an algorithm like BCrypt, PBKDF2, or Argon2**; these should be used with a decent work-factor. Hashed passwords should be salted with at least a 32-bit random salt. Remember that hashing algorithms are intentionally slow by design. The slower they are, the longer they take to crack.
31
14
32
-
##### Hash Algorithms
15
+
##### Hash Algorithms for other user cases:
33
16
34
17
- Language Agnostic
35
18
- SHA-512
@@ -46,20 +29,131 @@ Accepted TLS Cipher suites:
46
29
- SHA256CryptoServiceProvider (FIPS compliant)
47
30
- SHA384CryptoServiceProvider (FIPS compliant)
48
31
49
-
###### Random Number Generators (RNG)
50
-
-**CNG**: BCryptGenRandom(use of the BCRYPT_USE_SYSTEM_PREFERRED_RNG flag recommended unless the aller might run at any IRQL greater than 0 [that is, PASSIVE_LEVEL])
32
+
### Encrypt Sensitive Data At Rest
33
+
34
+
#### Symmetric Encryption Standard
35
+
36
+
Sensitive data should be encrypted when stored and then decrypted when accessed. Examples:
37
+
38
+
- Credentials intended to be used by the backend on behalf of the user (e.g., webhook credentials, VCS API tokens)
39
+
- Personally Identifiable Information (PII)
40
+
- Medical Records
41
+
- Payment information
42
+
43
+
Maintained, trustworthy implementations of industry approved cryptographic algorithms, ciphers, and modes should be used to accomplish this. Writing your own cryptography is strongly discouraged.
44
+
45
+
**The Security Team recommends using AES-256 GCM as the algorithm and key-size for symmetric encryption**. Keep in mind that encryption standards are constantly changing, so it is important to keep your encryption and decryption functionality customizable and upgradable. If you are unsure if your data needs to be encrypted, consult with the Unity Governance and Compliance team or the Unity Legal team for help making that determination.
46
+
47
+
#### Authentication
48
+
49
+
Use a strong algorithm in AEAD (Authenticated Encryption with Associated Data) mode to encrypt sensitive data at rest. AEAD is a form of encryption that performs integrity checks on both the encrypted data and the contextual data associated with the cipher text. These checks protect encrypted data against chosen cipher text attacks. In order to prevent tampering of encrypted data, use AES-256 GCM (Galois/Counter Mode). GCM automatically performs authentication using the same key. If GCM is not used, use an HMAC (Hash-Based Message Authentication) to authenticate the AES encryption result.
50
+
51
+
A symmetric encryption flow should look roughly like:
52
+
53
+
AES -> HMAC -> Final Blob
54
+
55
+
#### Initialization-Vectors (IV) and Nonces
56
+
57
+
Most well known encryption libraries like Bouncy Castle and Conceal handle IV generation properly. If you need to manually generate an IV or nonce, make sure to use a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG). Nonces should be at least 64 bits in length. The same IV or nonce should only be used once with a given symmetric key. See the "Secure Random Number Generation" recommendation below for a list of secure functions by language.
58
+
59
+
### Encrypt Data In Transit
60
+
61
+
#### Asymmetric Encryption Standard
62
+
63
+
Encryption should be used for any network communication between client-to-service and service-to-service communications.
64
+
65
+
Maintained, trustworthy implementations of industry approved cryptographic algorithms, ciphers, and modes should be used to accomplish this. Writing your own cryptography is strongly discouraged.
66
+
67
+
RSA-4096 should be used for asymmetric encryption and store the private keys in a secure location outside of your codebase. If it is found that RSA-4096 becomes too resource intensive, it is acceptable to lower this to RSA-2048; this should only be a problem in very high-load environments.
68
+
69
+
Enforce certificate verification in all HTTP clients.
70
+
71
+
#### Usage Guidance
72
+
73
+
##### TLS - Cipher Suites
74
+
75
+
*Minimum TLS version = TLS 1.2.*
76
+
77
+
All cipher suites below should be compatible with version >= TLS 1.2. SSL is not allowed. TLS 1.0 and 1.1 are legacy protocols that lack modern security features like AEAD. Additionally, using TLS v1.0 violates PCI-DSS requirements. Modern browsers have deprecated TLS v1.0 and TLS v1.1 as of January 2020.
78
+
79
+
When organizing your server's list of ciphers, prioritize AEAD (GCM) modes and PFS (Perfect Forward Secrecy) (ECDHE) cipher suites.
-[Qualys SSL/TLS Server Test](https://www.ssllabs.com/ssltest/)
111
+
112
+
> NOTE: Where possible, we recommend Elliptic Curve Cryptography (ECC / ECDH), with Curve25519 (for signatures and key exchange)
113
+
114
+
### Facilitate and Exercise Key Rotation
115
+
116
+
All encryption keys have a lifetime. The longer they are actively used to encrypt data the higher the chance that the key will be leaked and data will be compromised. To protect against this, keys should be rotated at least every year and in highly sensitive environments like PCI it should occur every six months.
117
+
118
+
In order to support periodic and on-demand (e.g., security incident) key rotation, your application should support reconfiguration of your encryption or hashing implementation. It should also facilitate m
119
+
120
+
When rotating keys it is often necessary for previous keys to stay around for a time to decrypt past data. A previous key should never be used to encrypt data once it is no longer the primary key. It should only be used to decrypt the data it was used to encrypt. When the data is ready to be stored again it should then be encrypted with the current key and stored.
121
+
122
+
### Secure Random Number Generation
123
+
124
+
125
+
126
+
#### Recommended Cryptographically Secure Pseudo-Random Number Generators (CSPRNG)
127
+
128
+
-**C:** getrandom(2)
129
+
-**CNG**: BCryptGenRandom(use of the BCRYPT*USE*SYSTEM*PREFERRED*RNG flag recommended unless the aller might run at any IRQL greater than 0 [that is, PASSIVE_LEVEL])
51
130
-**CAPI**: cryptGenRandom
52
-
-**Win32/64**: RtlGenRandom (new implementations should use BCryptGenRandom or CryptGenRandom) * and_s * SystemPrng (for kernel mode)
53
-
-**.NET** RNGCryptoServiceProvider or RNGCng
131
+
-**Win32/64**: RtlGenRandom (new implementations should use BCryptGenRandom or CryptGenRandom) *and_s* SystemPrng (for kernel mode)
-**Windows Store Apps**: Windows.Security.Cryptography.CryptographicBuffer.GenerateRandom or GenerateRandomNumber
55
-
-**Apple OS X**_(10.7+)/iOS(2.0+)_: int SecRandomCopyBytes (SecRandomRef random, size_t count, int8_t *bytes)
56
-
-**Apple OS X**_(<10.7)_: Use /dev/random to retrieve random numbers
57
-
-**Java**_(including Google Android Java code)_- java.security.SecureRandom class. Note that for Android 4.3 (Jelly Bean), developers must follow the Android recommended workaround and pdate their applications to explicitly initialize the PRNG with entropy from /dev/urandom or dev/random
141
+
-**Objective-C (Apple OS X \*(10.7+)/iOS(2.0+))\***: int SecRandomCopyBytes (SecRandomRef random, size*t count, int8*t *bytes )
142
+
-**Apple OS X***(<10.7)*: Use /dev/random to retrieve random numbers
143
+
-**Java***(including Google Android Java code)*- java.security.SecureRandom class. Note that for Android 4.3 (Jelly Bean), developers must follow the Android recommended workaround and pdate their applications to explicitly initialize the PRNG with entropy from /dev/urandom or dev/random
### Store Private and Symmetric Keys in a Secure Location
148
+
149
+
Private and symmetric keys should be stored in a secret storage solution that makes sense for your application. See our Secrets Management guidance for specific recommendations.
0 commit comments