1CRYPTO-POLICIES(7) CRYPTO-POLICIES(7)
2
3
4
6 crypto-policies - system-wide crypto policies overview
7
9 The security of cryptographic components of the operating system does
10 not remain constant over time. Algorithms, such as cryptographic
11 hashing and encryption, typically have a lifetime, after which they are
12 considered either too risky to use or plain insecure. That means, we
13 need to phase out such algorithms from the default settings or
14 completely disable them if they could cause an irreparable problem.
15
16 While in the past the algorithms were not disabled in a consistent way
17 and different applications applied different policies, the system-wide
18 crypto-policies followed by the crypto core components allow
19 consistently deprecating and disabling algorithms system-wide.
20
21 The individual policy levels (DEFAULT, LEGACY, FUTURE, and FIPS) are
22 included in the crypto-policies(7) package. In the future, there will
23 be also a mechanism for easy creation and deployment of policies
24 defined by the system administrator or a third party vendor.
25
26 For rationale, see RFC 7457 for a list of attacks taking advantage of
27 legacy crypto algorithms.
28
30 Crypto-policies apply to the configuration of the core cryptographic
31 subsystems, covering TLS, IKE, IPSec, DNSSec, and Kerberos protocols;
32 i.e., the supported secure communications protocols on the base
33 operating system.
34
35 Once an application runs in the operating system, it follows the
36 default or selected policy and refuses to fall back to algorithms and
37 protocols not within the policy, unless the user has explicitly
38 requested the application to do so. That is, the policy applies to the
39 default behavior of applications when running with the system-provided
40 configuration but the user can override it on an application-specific
41 basis.
42
43 The policies currently provide settings for these applications and
44 libraries:
45
46 · BIND DNS name server daemon
47
48 · GnuTLS TLS library
49
50 · OpenJDK runtime environment
51
52 · Kerberos 5 library
53
54 · Libreswan IPsec and IKE protocol implementation
55
56 · NSS TLS library
57
58 · OpenSSH SSH2 protocol implementation
59
60 · OpenSSL TLS library
61
62 Applications using the above libraries and tools are covered by the
63 cryptographic policies unless they are explicitly configured not to be
64 so.
65
67 LEGACY
68 This policy ensures maximum compatibility with legacy systems; it
69 is less secure and it includes support for TLS 1.0, TLS 1.1, and
70 SSH2 protocols or later. The algorithms DSA, 3DES, and RC4 are
71 allowed, while RSA and Diffie-Hellman parameters are accepted if
72 larger than 1023 bits. The level provides at least 64-bit security.
73
74 · MACs: all HMAC with SHA-1 or better + all modern MACs (Poly1305
75 etc.)
76
77 · Curves: all prime >= 255 bits (including Bernstein curves)
78
79 · Signature algorithms: with SHA1 hash or better (DSA allowed)
80
81 · TLS Ciphers: all available >= 112-bit key, >= 128-bit block
82 (including RC4 and 3DES)
83
84 · Non-TLS Ciphers: same as TLS ciphers with added Camellia
85
86 · Key exchange: ECDHE, RSA, DHE
87
88 · DH params size: >= 1023
89
90 · RSA keys size: >= 1023
91
92 · DSA params size: >= 1023
93
94 · TLS protocols: TLS >= 1.0, DTLS >= 1.0
95
96 DEFAULT
97 The DEFAULT policy is a reasonable default policy for today’s
98 standards. It allows the TLS 1.0, TLS 1.1, TLS 1.2, and TLS 1.3
99 protocols, as well as IKEv2 and SSH2. The Diffie-Hellman parameters
100 are accepted if they are at least 1023 bits long. The level
101 provides at least 80-bit security.
102
103 · MACs: all HMAC with SHA-1 or better + all modern MACs (Poly1305
104 etc.)
105
106 · Curves: all prime >= 255 bits (including Bernstein curves)
107
108 · Signature algorithms: with SHA-1 hash or better (no DSA)
109
110 · TLS Ciphers: >= 128-bit key, >= 128-bit block (AES, ChaCha20,
111 including AES-CBC)
112
113 · non-TLS Ciphers: as TLS Ciphers with added Camellia
114
115 · key exchange: ECDHE, RSA, DHE (no DHE-DSS)
116
117 · DH params size: >= 1023
118
119 · RSA keys size: >= 2048
120
121 · TLS protocols: TLS >= 1.0, DTLS >= 1.0
122
123 NEXT
124 The NEXT policy is a policy prepared for the upcoming release of
125 the operating system so it can be easily tested. It allows the TLS
126 1.2 and TLS 1.3 protocols, as well as IKEv2 and SSH2. The RSA and
127 Diffie-Hellman parameters are accepted if larger than 2047 bits.
128 The level provides at least 112-bit security with the exception of
129 SHA-1 signatures needed for DNSSec and other still prevalent legacy
130 use of SHA-1 signatures.
131
132 · MACs: all HMAC with SHA-1 or better + all modern MACs (Poly1305
133 etc.)
134
135 · Curves: all prime >= 255 bits (including Bernstein curves)
136
137 · Signature algorithms: with SHA-1 hash or better (no DSA)
138
139 · TLS Ciphers: >= 128-bit key, >= 128-bit block (AES, ChaCha20,
140 including AES-CBC)
141
142 · non-TLS Ciphers: as TLS Ciphers with added Camellia
143
144 · key exchange: ECDHE, RSA, DHE (no DHE-DSS)
145
146 · DH params size: >= 2048
147
148 · RSA keys size: >= 2048
149
150 · TLS protocols: TLS >= 1.2, DTLS >= 1.2
151
152 FUTURE
153 A conservative security level that is believed to withstand any
154 near-term future attacks. This level does not allow the use of
155 SHA-1 in signature algorithms. The level also provides some (not
156 complete) preparation for post-quantum encryption support in form
157 of 256-bit symmetric encryption requirement. The RSA and
158 Diffie-Hellman parameters are accepted if larger than 3071 bits.
159 The level provides at least 128-bit security.
160
161 · MACs: all HMAC with SHA-256 or better + all modern MACs
162 (Poly1305 etc.)
163
164 · Curves: all prime >= 255 bits (including Bernstein curves)
165
166 · Signature algorithms: with SHA-256 hash or better (no DSA)
167
168 · TLS Ciphers: >= 256-bit key, >= 128-bit block, only
169 Authenticated Encryption (AE) ciphers
170
171 · non-TLS Ciphers: same as TLS ciphers with added non AE ciphers
172 and Camellia
173
174 · key exchange: ECDHE, DHE (no DHE-DSS, no RSA)
175
176 · DH params size: >= 3072
177
178 · RSA keys size: >= 3072
179
180 · TLS protocols: TLS >= 1.2, DTLS >= 1.2
181
182 FIPS
183 A level that conforms to the FIPS 140-2 requirements. This policy
184 is used internally by the fips-mode-setup(8) tool which can switch
185 the system into the FIPS 140-2 compliance mode. The level provides
186 at least 112-bit security.
187
188 · MACs: all HMAC with SHA1 or better
189
190 · Curves: all prime >= 256 bits
191
192 · Signature algorithms: with SHA-256 hash or better (no DSA)
193
194 · TLS Ciphers: >= 128-bit key, >= 128-bit block (AES, including
195 AES-CBC)
196
197 · non-TLS Ciphers: same as TLS Ciphers
198
199 · key exchange: ECDHE, DHE (no DHE-DSS, no RSA)
200
201 · DH params size: >= 2048
202
203 · RSA params size: >= 2048
204
205 · TLS protocols: TLS >= 1.2, DTLS >= 1.2
206
207 EMPTY
208 All cryptographic algorithms are disabled (used for debugging only,
209 do not use).
210
212 update-crypto-policies(8)
213 This command manages the policies available to the various
214 cryptographic back ends and allows the system administrator to
215 change the active cryptographic policy level.
216
217 fips-mode-setup(8)
218 This command allows the system administrator to enable, or disable
219 the system FIPS mode and also apply the FIPS cryptographic policy
220 level which limits the allowed algorithms and protocols to these
221 allowed by the FIPS 140-2 requirements.
222
224 Exceptions:
225
226 · Go-language applications do not yet follow the system-wide policy.
227
228 · Libssh applications do not yet follow the system-wide policy.
229
230 · GnuPG-2 application does not follow the system-wide policy.
231
232 In general only the data-in-transit is currently covered by the
233 system-wide policy.
234
235 If the system administrator changes the system-wide policy level with
236 the update-crypto-policies(8) command it is advisable to restart the
237 system as the individual back-end libraries read the configuration
238 files usually during their initialization. The changes in the policy
239 level thus take place in most cases only when the applications using
240 the back-end libraries are restarted.
241
242 Removed cipher suites and protocols
243
244 The following cipher suites and protocols are completely removed from
245 the core cryptographic libraries listed above:
246
247 · DES
248
249 · All export grade cipher suites
250
251 · MD5 in signatures
252
253 · SSLv2
254
255 · SSLv3
256
257 · All ECC curves smaller than 224 bits
258
259 · All binary field ECC curves
260
261 Cipher suites and protocols disabled in all policy levels
262
263 The following ciphersuites and protocols are available but disabled in
264 all crypto policy levels. They can be enabled only by explicit
265 configuration of individual applications:
266
267 · DH with parameters < 1024 bits
268
269 · RSA with key size < 1024 bits
270
271 · Camellia
272
273 · ARIA
274
275 · SEED
276
277 · IDEA
278
279 · Integrity only ciphersuites
280
281 · TLS CBC mode ciphersuites using SHA-384 HMAC
282
283 · AES-CCM8
284
285 · all ECC curves incompatible with TLS 1.3, including secp256k1
286
287 · IKEv1
288
290 /etc/crypto-policies/back-ends
291 The individual cryptographical back-end configuration files.
292 Usually linked to the configuration shipped in the crypto-policies
293 package unless a configuration from local.d is added.
294
295 /etc/crypto-policies/config
296 The active crypto-policies level set on the system.
297
298 /etc/crypto-policies/local.d
299 Additional configuration shipped by other packages or created by
300 the system administrator. The contents of the
301 <back-end>-file.config is appended to the configuration from the
302 policy back end as shipped in the crypto-policies package.
303
305 update-crypto-policies(8), fips-mode-setup(8)
306
308 Written by Tomáš Mráz.
309
310
311
312crypto-policies 05/27/2019 CRYPTO-POLICIES(7)