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 Several preconfigured policies (DEFAULT, LEGACY, FUTURE, and FIPS) and
22 subpolicies are included in the crypto-policies(7) package. System
23 administrators or third-party vendors can define custom policies and
24 subpolicies.
25
26 The recommended way to modify the effective configuration is to apply a
27 custom subpolicy on top of a predefined policy. This allows
28 configuration to evolve with future updates of the predefined policies
29 keeping desired modification in place. Modifying effective
30 configuration by defining a fully custom policy prevents the
31 configuration from evolving with future updates of the predefined
32 policies. The syntax to define custom policies and subpolicies is
33 described in the CRYPTO POLICY DEFINITION FORMAT section below.
34
35 For rationale, see RFC 7457 for a list of attacks taking advantage of
36 legacy crypto algorithms.
37
39 Crypto-policies apply to the configuration of the core cryptographic
40 subsystems, covering TLS, IKE, IPSec, DNSSec, and Kerberos protocols;
41 i.e., the supported secure communications protocols on the base
42 operating system.
43
44 Once an application runs in the operating system, it follows the
45 default or selected policy and refuses to fall back to algorithms and
46 protocols not within the policy, unless the user has explicitly
47 requested the application to do so. That is, the policy applies to the
48 default behavior of applications when running with the system-provided
49 configuration but the user can override it on an application-specific
50 basis.
51
52 The policies currently provide settings for these applications and
53 libraries:
54
55 • BIND DNS name server daemon (scopes: BIND, DNSSec)
56
57 • GnuTLS TLS library (scopes: GnuTLS, SSL, TLS)
58
59 • OpenJDK runtime environment (scopes: java-tls, SSL, TLS)
60
61 • Kerberos 5 library (scopes: krb5, Kerberos)
62
63 • Libreswan IPsec and IKE protocol implementation (scopes: libreswan,
64 IPSec, IKE)
65
66 • NSS TLS library (scopes: NSS, SSL, TLS)
67
68 • OpenSSH SSH2 protocol implementation (scopes: OpenSSH, SSH)
69
70 • OpenSSL TLS library (scopes: OpenSSL, SSL, TLS)
71
72 • libssh SSH2 protocol implementation (scopes: libssh, SSH)
73
74 • sequoia PGP implementation, for usage outside of rpm-sequoia
75 (scopes: sequoia)
76
77 • rpm-sequoia RPM Sequoia PGP backend (scopes: rpm, rpm-sequoia)
78
79 Applications using the above libraries and tools are covered by the
80 cryptographic policies unless they are explicitly configured otherwise.
81
83 LEGACY
84 This policy ensures maximum compatibility with legacy systems; it
85 is less secure and it includes support for TLS 1.0, TLS 1.1, and
86 SSH2 protocols or later. The algorithms DSA and 3DES are allowed,
87 while RSA and Diffie-Hellman parameters are accepted if larger than
88 1024 bits. This policy provides at least 64-bit security.
89
90 • MACs: all HMAC with SHA-1 or better + all modern MACs (Poly1305
91 etc.)
92
93 • Curves: all prime >= 255 bits (including Bernstein curves)
94
95 • Signature algorithms: with SHA1 hash or better (DSA allowed)
96
97 • TLS Ciphers: all available >= 112-bit key, >= 128-bit block
98 (including 3DES, excluding RC4)
99
100 • Non-TLS Ciphers: same as TLS ciphers with added Camellia
101
102 • Key exchange: ECDHE, RSA, DHE
103
104 • DH params size: >= 1024
105
106 • RSA keys size: >= 1024
107
108 • DSA params size: >= 1024
109
110 • TLS protocols: TLS >= 1.0, DTLS >= 1.0
111
112 DEFAULT
113 The DEFAULT policy is a reasonable default policy for today’s
114 standards. It allows the TLS 1.2, and TLS 1.3 protocols, as well as
115 IKEv2 and SSH2. The Diffie-Hellman parameters are accepted if they
116 are at least 2048 bits long. This policy provides at least 112-bit
117 security with the exception of allowing SHA-1 signatures in DNSSec
118 where they are still prevalent.
119
120 • MACs: all HMAC with SHA-1 or better + all modern MACs (Poly1305
121 etc.)
122
123 • Curves: all prime >= 255 bits (including Bernstein curves)
124
125 • Signature algorithms: with SHA-224 hash or better (no DSA)
126
127 • TLS Ciphers: >= 128-bit key, >= 128-bit block (AES, ChaCha20,
128 including AES-CBC)
129
130 • non-TLS Ciphers: as TLS Ciphers with added Camellia
131
132 • key exchange: ECDHE, RSA, DHE (no DHE-DSS)
133
134 • DH params size: >= 2048
135
136 • RSA keys size: >= 2048
137
138 • TLS protocols: TLS >= 1.2, DTLS >= 1.2
139
140 NEXT
141 The NEXT policy is just an alias to the DEFAULT policy.
142
143 FUTURE
144 A conservative security policy that is believed to withstand any
145 near-term future attacks at the expense of interoperability. It may
146 prevent communication with many commonly used systems that only
147 offer weaker security. This policy does not allow the use of SHA-1
148 in signature algorithms. The policy also provides some (not
149 complete) preparation for post-quantum encryption support in form
150 of 256-bit symmetric encryption requirement. The RSA and
151 Diffie-Hellman parameters are accepted if larger than 3071 bits.
152 This policy provides at least 128-bit security.
153
154 • MACs: all HMAC with SHA-256 or better + all modern MACs
155 (Poly1305 etc.)
156
157 • Curves: all prime >= 255 bits (including Bernstein curves)
158
159 • Signature algorithms: with SHA-256 hash or better (no DSA)
160
161 • TLS Ciphers: >= 256-bit key, >= 128-bit block, only
162 Authenticated Encryption (AE) ciphers
163
164 • non-TLS Ciphers: same as TLS ciphers with added non AE ciphers
165 and Camellia
166
167 • key exchange: ECDHE, DHE (no DHE-DSS, no RSA)
168
169 • DH params size: >= 3072
170
171 • RSA keys size: >= 3072
172
173 • TLS protocols: TLS >= 1.2, DTLS >= 1.2
174
175 BSI
176 A security policy based on recommendations by the german government
177 agency BSI (Bundesamt fuer Sicherheit in der Informationstechnik,
178 translated as "agency for security in software technology") in its
179 ruleset BSI TR 02102 (TR - technical recommendation). The BSI TR
180 02102 standard is updated in regular intervals.
181
182 This policy does not allow the use of *SHA-1* in signature algorithms
183 (except *DNSSEC* and *RPM*).
184
185 The policy also provides some (not complete) preparation for
186 post-quantum encryption support in form of 256-bit symmetric encryption
187 requirement.
188
189 The *RSA* parameters are accepted if larger than 2047 bits, and
190 *Diffie-Hellman* parameters are accepted if larger than 3071 bits.
191
192 This policy provides at least 128-bit security, excepting the transition
193 of *RSA*.
194
195 • MACs: all HMAC with SHA-256 or better + all modern MACs
196
197 • Curves: all prime >= 255 bits (including Bernstein curves)
198
199 • Signature algorithms: with SHA-256 hash or better (no DSA)
200
201 • TLS Ciphers: >= 256-bit key, >= 128-bit block, only
202 Authenticated Encryption (AE) ciphers
203
204 • non-TLS Ciphers: same as TLS ciphers with added non AE ciphers
205
206 • key exchange: ECDHE, DHE (no DHE-DSS, no RSA)
207
208 • DH params size: >= 3072
209
210 • RSA keys size: >= 2048 (until end of 2023, then it will switch
211 to 3072)
212
213 • TLS protocols: TLS >= 1.2, DTLS >= 1.2
214
215 Note that compared to others profiles *Chacha20* and *Camellia* are not
216 recommended by the BSI.
217
218 FIPS
219 A policy to aid conformance to the FIPS 140 requirements. This
220 policy is used internally by the fips-mode-setup(8) tool which can
221 switch the system into the FIPS 140 mode. This policy provides at
222 least 112-bit security.
223
224 • MACs: all HMAC with SHA1 or better
225
226 • Curves: all prime >= 256 bits
227
228 • Signature algorithms: with SHA-256 hash or better (no DSA)
229
230 • TLS Ciphers: >= 128-bit key, >= 128-bit block (AES, including
231 AES-CBC)
232
233 • non-TLS Ciphers: same as TLS Ciphers
234
235 • key exchange: ECDHE, DHE (no DHE-DSS, no RSA)
236
237 • DH params size: >= 2048
238
239 • RSA params size: >= 2048
240
241 • TLS protocols: TLS >= 1.2, DTLS >= 1.2
242
243 EMPTY
244 All cryptographic algorithms are disabled (used for debugging only,
245 do not use).
246
248 The crypto policy definition files have a simple syntax following an
249 INI file key = value syntax with these particular features:
250
251 • Comments are indicated by # character. Everything on the line
252 following the character is ignored.
253
254 • Backslash \ character followed immediately with the end-of-line
255 character indicates line continuation. The following line is
256 concatenated to the current line after the backslash and
257 end-of-line characters are removed.
258
259 • Value types for integer options can be decimal integers (option =
260 1).
261
262 • Multiple-choice options can be specified by setting them to a list
263 of values (option = value1 value2). This list can further be
264 altered by prepending/omitting/appending values (option = prepended
265 -omitted appended). A follow-up reassignment will reset the list.
266 The latter syntax cannot be combined with the former one in the
267 same directive. Setting an option to an empty list is possible with
268 option =.
269
270 • Asterisk sign can be used for wildcard matching as a shortcut for
271 specifying multiple values when setting multiple-choice options.
272 Note that wildcard matching can lead to future updates implicitly
273 enabling algorithms not yet available in the current version. If
274 this is a concern, do not use wildcard-matching outside of
275 algorithm-omitting directives.
276
277 • In order to limit the scope of the directive and make it affect
278 just some of the backends, the following extended syntax can be
279 used: option@scope = ..., option@{scope1,scope2,...} = ....
280 Negation of scopes is possible with option@!scope /
281 'option@{scope1,scope2,...}. Scope selectors are case-insensitive.
282
283 The available options are:
284
285 • mac: List of allowed MAC algorithms
286
287 • group: List of allowed groups or elliptic curves for key exchanges
288 for use with other protocols
289
290 • hash: List of allowed cryptographic hash (message digest)
291 algorithms
292
293 • sign: List of allowed signature algorithms
294
295 • cipher: List of allowed symmetric encryption algorithms (including
296 the modes) for use with other protocols
297
298 • key_exchange: List of allowed key exchange algorithms
299
300 • protocol: List of allowed TLS, DTLS and IKE protocol versions; mind
301 that some backends do not allow selectively disabling protocols
302 versions and only use the oldest version as the lower boundary.
303
304 • min_dh_size: Integer value of minimum number of bits of parameters
305 for DH key exchange
306
307 • min_dsa_size: Integer value of minimum number of bits for DSA keys
308
309 • min_rsa_size: Integer value of minimum number of bits for RSA keys
310
311 • sha1_in_certs: Value of 1 if SHA1 allowed in certificate
312 signatures, 0 otherwise (Applies to GnuTLS back end only.)
313
314 • arbitrary_dh_groups: Value of 1 if arbitrary group in
315 Diffie-Hellman is allowed, 0 otherwise
316
317 • ssh_certs: Value of 1 if OpenSSH certificate authentication is
318 allowed, 0 otherwise
319
320 • etm: ANY/DISABLE_ETM/DISABLE_NON_ETM allows both EtM
321 (Encrypt-then-Mac) and E&M (Encrypt-and-Mac), disables EtM, and
322 disables E&M respectively. (Currently only implemented for SSH, do
323 not use without @SSH scope.)
324
325 Full policy definition files have suffix .pol, subpolicy files have
326 suffix .pmod. Subpolicies do not have to have values set for all the
327 keys listed above.
328
329 The effective configuration of a policy with subpolicies applied is the
330 same as a configuration from a single policy obtained by concatenating
331 the policy and the subpolicies in question.
332
333 Policy file placement and naming:
334
335 The policy files shipped in packages are placed in
336 /usr/share/crypto-policies/policies and the subpolicies in
337 /usr/share/crypto-policies/policies/modules.
338
339 Locally configured policy files should be placed in
340 /etc/crypto-policies/policies and subpolicies in
341 /etc/crypto-policies/policies/modules.
342
343 The policy and subpolicy files must have names in upper-case except for
344 the .pol and .pmod suffix as the update-crypto-policies command always
345 converts the policy name to upper-case before searching for the policy
346 on the filesystem.
347
349 update-crypto-policies(8)
350 This command manages the policies available to the various
351 cryptographic back ends and allows the system administrator to
352 change the active cryptographic policy.
353
354 fips-mode-setup(8)
355 This command allows the system administrator to enable, or disable
356 the system FIPS mode and also apply the FIPS cryptographic policy
357 which limits the allowed algorithms and protocols to these allowed
358 by the FIPS 140 requirements.
359
361 Known notable exceptions
362
363 • Go-language applications do not yet follow the system-wide policy.
364
365 • GnuPG-2 application does not follow the system-wide policy.
366
367 In general only the data-in-transit is currently covered by the
368 system-wide policy.
369
370 If the system administrator changes the system-wide policy with the
371 update-crypto-policies(8) command it is advisable to restart the system
372 as the individual back-end libraries read the configuration files
373 usually during their initialization. The changes in the policy thus
374 take place in most cases only when the applications using the back-end
375 libraries are restarted.
376
377 Removed cipher suites and protocols
378
379 The following cipher suites and protocols are completely removed from
380 the core cryptographic libraries listed above:
381
382 • DES
383
384 • All export grade cipher suites
385
386 • MD5 in signatures
387
388 • SSLv2
389
390 • SSLv3
391
392 • All ECC curves smaller than 224 bits
393
394 • All binary field ECC curves
395
396 Cipher suites and protocols disabled in all predefined policies
397
398 The following ciphersuites and protocols are available but disabled in
399 all predefined crypto policies:
400
401 • DH with parameters < 1024 bits
402
403 • RSA with key size < 1024 bits
404
405 • Camellia
406
407 • RC4
408
409 • ARIA
410
411 • SEED
412
413 • IDEA
414
415 • Integrity only ciphersuites
416
417 • TLS CBC mode ciphersuites using SHA-384 HMAC
418
419 • AES-CCM8
420
421 • all ECC curves incompatible with TLS 1.3, including secp256k1
422
423 • IKEv1
424
425 Notable irregularities in the individual configuration generators
426
427 • OpenSSL and NSS: Disabling all TLS and/or all DTLS versions isn’t
428 actually possible. Trying to do so will result in the library
429 defaults being applied instead.
430
431 • OpenSSL: The minimum length of the keys and some other parameters
432 are enforced by the @SECLEVEL value which does not provide a fine
433 granularity. The list of TLS ciphers is not generated as an exact
434 list but by subtracting from all the supported ciphers for the
435 enabled key exchange methods. For that reason there is no way to
436 disable a random cipher. In particular all AES-128 ciphers are
437 disabled if the AES-128-GCM is not present in the list; all AES-256
438 ciphers are disabled if the AES-256-GCM is not present. The CBC
439 ciphers are disabled if there isn’t HMAC-SHA1 in the hmac list and
440 AES-256-CBC in the cipher list. To disable the CCM ciphers both
441 AES-128-CCM and AES-256-CCM must not be present in the cipher list.
442
443 • GnuTLS: The minimum length of the keys and some other parameters
444 are enforced by min-verification-profile setting in the GnuTLS
445 configuration file which does not provide fine granularity.
446
447 • GnuTLS: PSK key exchanges have to be explicitly enabled by the
448 applications using them.
449
450 • GnuTLS: HMAC-SHA2-256 and HMAC-SHA2-384 MACs are disabled due to
451 concerns over the constant-timedness of the implementation.
452
453 • OpenSSH: DH group 1 is always disabled on server even if the policy
454 allows 1024 bit DH groups in general. The OpenSSH configuration
455 option HostKeyAlgorithms is set only for the SSH server as
456 otherwise the handling of the existing known hosts entries would be
457 broken on client.
458
459 • Libreswan: The key_exchange parameter does not affect the generated
460 configuration. The use of regular DH or ECDH can be limited with
461 appropriate setting of the group parameter.
462
463 • Sequoia: only hash_algorithms, symmetric_algorithms and
464 asymmetric_algorithms are controlled by crypto-policies.
465 asymmetric_algorithms is not controlled directly, but deduced from
466 sign and group.
467
468 • NSS: order of group values is ignored and built-in order is used
469 instead.
470
472 The ECDHE-GSS and DHE-GSS algorithms are newly introduced and must be
473 specified in the base policy for the SSH GSSAPI key exchange methods to
474 be enabled. Previously the legacy SSH GSSAPI key exchange methods were
475 automatically enabled when the SHA1 hash and DH parameters of at least
476 2048 bits were enabled.
477
478 Before the introduction of the custom crypto policies support it was
479 possible to have an completely arbitrary crypto policy created as a set
480 of arbitrary back-end config files in
481 /usr/share/crypto-policies/<POLICYNAME> directory. With the
482 introduction of the custom crypto policies it is still possible but
483 there must be an empty (possibly with any comment lines)
484 <POLICYNAME>.pol file in /usr/share/crypto-policies/policies so the
485 update-crypto-policies command can recognize the arbitrary custom
486 policy. No subpolicies must be used with such an arbitrary custom
487 policy. Modifications from local.d will be appended to the files
488 provided by the policy.
489
490 The use of the following historaically available options is
491 discouraged:
492
493 • min_tls_version: Lowest allowed TLS protocol version (recommended
494 replacement: protocol@TLS)
495
496 • min_dtls_version: Lowest allowed DTLS protocol version (recommended
497 replacement: protocol@TLS)
498
499 The following options are deprecated, please rewrite your policies:
500
501 • ike_protocol: List of allowed IKE protocol versions (recommended
502 replacement: protocol@IKE, mind the relative position to other
503 protocol directives).
504
505 • tls_cipher: list of allowed symmetric encryption algorithms for use
506 with the TLS protocol (recommended replacement: cipher@TLS, mind
507 the relative position to other cipher directives).
508
509 • ssh_cipher: list of allowed symmetric encryption algorithms for use
510 with the SSH protocol (recommended replacement: cipher@SSH, mind
511 the relative position to other cipher directives).
512
513 • ssh_group: list of allowed groups or elliptic curves for key
514 exchanges for use with the SSH protocol (recommended replacement:
515 group@SSH, mind the relative position to other group directives).
516
517 • sha1_in_dnssec: Allow SHA1 usage in DNSSec protocol even if it is
518 not present in the hash and sign lists (recommended replacements:
519 hash@DNSSec, sign@DNSSec).
520
521 • ssh_etm: Value of 1 if OpenSSH EtM (encrypt-then-mac) extension is
522 allowed, 0 otherwise. Use etm@SSH instead.
523
525 /etc/crypto-policies/back-ends
526 The individual cryptographical back-end configuration files.
527 Usually linked to the configuration shipped in the crypto-policies
528 package unless a configuration from local.d is added.
529
530 /etc/crypto-policies/config
531 A file containing the name of the active crypto-policy set on the
532 system.
533
534 /etc/crypto-policies/local.d
535 Additional configuration shipped by other packages or created by
536 the system administrator. The contents of the
537 <back-end>-file.config is appended to the configuration from the
538 policy back end as shipped in the crypto-policies package.
539
540 /usr/share/crypto-policies/policies
541 System policy definition files.
542
543 /usr/share/crypto-policies/policies/modules
544 System subpolicy definition files.
545
546 /etc/crypto-policies/policies
547 Custom policy definition files as configured by the system
548 administrator.
549
550 /etc/crypto-policies/policies/modules
551 Custom subpolicy definition files as configured by the system
552 administrator.
553
554 /usr/share/crypto-policies/<'POLICYNAME'>
555 Pre-generated back-end configurations for policy POLICYNAME.
556
558 update-crypto-policies(8), fips-mode-setup(8)
559
561 Written by Tomáš Mráz.
562
563
564
565crypto-policies 11/13/2023 CRYPTO-POLICIES(7)