1CRYPTO-POLICIES(7) CRYPTO-POLICIES(7)
2
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 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 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 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 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 The policies currently provide settings for these applications and
44 libraries:
45 • BIND DNS name server daemon
47 • GnuTLS TLS library
49 • OpenJDK runtime environment
51 • Kerberos 5 library
53 • Libreswan IPsec and IKE protocol implementation
55 • NSS TLS library
57 • OpenSSH SSH2 protocol implementation
59 • OpenSSL TLS library
61 • libssh SSH2 protocol implementation
63 Applications using the above libraries and tools are covered by the
65 cryptographic policies unless they are explicitly configured not to be
66 so.
67
69 LEGACY
70 This policy ensures maximum compatibility with legacy systems; it
71 is less secure and it includes support for TLS 1.0, TLS 1.1, and
72 SSH2 protocols or later. The algorithms DSA, 3DES, and RC4 are
73 allowed, while RSA and Diffie-Hellman parameters are accepted if
74 larger than 1023 bits. The level provides at least 64-bit security.
75 • MACs: all HMAC with SHA-1 or better + all modern MACs (Poly1305
77 etc.)
78 • Curves: all prime >= 255 bits (including Bernstein curves)
80 • Signature algorithms: with SHA1 hash or better (DSA allowed)
82 • TLS Ciphers: all available >= 112-bit key, >= 128-bit block
84 (including RC4 and 3DES)
85 • Non-TLS Ciphers: same as TLS ciphers with added Camellia
87 • Key exchange: ECDHE, RSA, DHE
89 • DH params size: >= 1023
91 • RSA keys size: >= 1023
93 • DSA params size: >= 1023
95 • TLS protocols: TLS >= 1.0, DTLS >= 1.0
97 DEFAULT
99 The DEFAULT policy is a reasonable default policy for today’s
100 standards. It allows the TLS 1.2, and TLS 1.3 protocols, as well as
101 IKEv2 and SSH2. The Diffie-Hellman parameters are accepted if they
102 are at least 2048 bits long. The level provides at least 112-bit
103 security with the exception of allowing SHA-1 signatures in DNSSec
104 where they are still prevalent.
105 • MACs: all HMAC with SHA-1 or better + all modern MACs (Poly1305
107 etc.)
108 • Curves: all prime >= 255 bits (including Bernstein curves)
110 • Signature algorithms: with SHA-224 hash or better (no DSA)
112 • TLS Ciphers: >= 128-bit key, >= 128-bit block (AES, ChaCha20,
114 including AES-CBC)
115 • non-TLS Ciphers: as TLS Ciphers with added Camellia
117 • key exchange: ECDHE, RSA, DHE (no DHE-DSS)
119 • DH params size: >= 2048
121 • RSA keys size: >= 2048
123 • TLS protocols: TLS >= 1.2, DTLS >= 1.2
125 NEXT
127 The NEXT policy is just an alias to the DEFAULT policy.
128 FUTURE
130 A conservative security level that is believed to withstand any
131 near-term future attacks. This level does not allow the use of
132 SHA-1 in signature algorithms. The level also provides some (not
133 complete) preparation for post-quantum encryption support in form
134 of 256-bit symmetric encryption requirement. The RSA and
135 Diffie-Hellman parameters are accepted if larger than 3071 bits.
136 The level provides at least 128-bit security.
137 • MACs: all HMAC with SHA-256 or better + all modern MACs
139 (Poly1305 etc.)
140 • Curves: all prime >= 255 bits (including Bernstein curves)
142 • Signature algorithms: with SHA-256 hash or better (no DSA)
144 • TLS Ciphers: >= 256-bit key, >= 128-bit block, only
146 Authenticated Encryption (AE) ciphers
147 • non-TLS Ciphers: same as TLS ciphers with added non AE ciphers
149 and Camellia
150 • key exchange: ECDHE, DHE (no DHE-DSS, no RSA)
152 • DH params size: >= 3072
154 • RSA keys size: >= 3072
156 • TLS protocols: TLS >= 1.2, DTLS >= 1.2
158 FIPS
160 A level that conforms to the FIPS 140-2 requirements. This policy
161 is used internally by the fips-mode-setup(8) tool which can switch
162 the system into the FIPS 140-2 compliance mode. The level provides
163 at least 112-bit security.
164 • MACs: all HMAC with SHA1 or better
166 • Curves: all prime >= 256 bits
168 • Signature algorithms: with SHA-256 hash or better (no DSA)
170 • TLS Ciphers: >= 128-bit key, >= 128-bit block (AES, including
172 AES-CBC)
173 • non-TLS Ciphers: same as TLS Ciphers
175 • key exchange: ECDHE, DHE (no DHE-DSS, no RSA)
177 • DH params size: >= 2048
179 • RSA params size: >= 2048
181 • TLS protocols: TLS >= 1.2, DTLS >= 1.2
183 EMPTY
185 All cryptographic algorithms are disabled (used for debugging only,
186 do not use).
187
189 The crypto policy definiton files have a simple syntax following an INI
190 file key = value syntax with these particular features:
191 • Comments are indicated by # character. Everything on the line
193 following the character is ignored.
194 • Backslash \ character followed immediately with the end-of-line
196 character indicates line continuation. The following line is
197 concatenated to the current line after the backslash and
198 end-of-line characters are removed.
199 • Value types can be either decimal integers, arbitrary strings, or
201 lists of strings without whitespace characters separated by any
202 number of whitespaces.
203 The allowed keys are:
205 • mac: List of allowed MAC algorithms
207 • ssh_group: Optional; list of allowed groups or elliptic curves for
209 key exchanges for use with the SSH protocol. If absent, the value
210 is derived from group.
211 • group: List of allowed groups or elliptic curves for key exchanges
213 for use with other protocols
214 • hash: List of allowed cryptographic hash (message digest)
216 algorithms
217 • sign: List of allowed signature algorithms
219 • tls_cipher: Optional; list of allowed symmetric encryption
221 algorithms (including the modes) for use with the TLS protocol. If
222 absent, the value is derived from cipher.
223 • ssh_cipher: Optional; list of allowed symmetric encryption
225 algorithms (including the modes) for use with the SSH protocol. If
226 absent, the value is derived from cipher.
227 • cipher: List of allowed symmetric encryption algorithms (including
229 the modes) for use with other protocols
230 • key_exchange: List of allowed key exchange algorithms
232 • protocol: List of allowed TLS and DTLS protocol versions (ignored
234 by OpenSSL and NSS back ends)
235 • ike_protocol: List of allowed IKE protocol versions
237 • min_tls_version: Lowest allowed TLS protocol version (used only by
239 OpenSSL a and NSS back ends)
240 • min_dtls_version: Lowest allowed DTLS protocol version (used only
242 by NSS back end)
243 • min_dh_size: Integer value of minimum number of bits of parameters
245 for DH key exchange
246 • min_dsa_size: Integer value of minimum number of bits for DSA keys
248 • min_rsa_size: Integer value of minimum number of bits for RSA keys
250 • sha1_in_certs: Value of 1 if SHA1 allowed in certificate
252 signatures, 0 otherwise (Applies to GnuTLS back end only.)
253 • sha1_in_dnssec: Value of 1 if SHA1 allowed in DNSSec protocol even
255 if it is not present in the hash and sign lists, 0 otherwise
256 (Applies to BIND back end only.)
257 • arbitrary_dh_groups: Value of 1 if arbitrary group in
259 Diffie-Hellman is allowed, 0 otherwise
260 • ssh_certs: Value of 1 if OpenSSH certificate authentication is
262 allowed, 0 otherwise
263 • ssh_etm: Value of 1 if OpenSSH EtM (encrypt-then-mac) extension is
265 allowed, 0 otherwise
266 The full policy definition files have suffix .pol, the policy module
268 definition files have suffix .pmod. The policy module files do not have
269 to have values set for all the keys listed above.
270 The lists as set in the base (full policy) are modified by the lists
272 specified in the module files in following way:
273 • -list-item: The list-item is removed from the list specified in the
275 base policy.
276 • +list-item: The list-item is inserted at the beginning of the list
278 specified in the base policy. The inserts are done in the order of
279 appearance in the policy module file so the actual order in the
280 final list will be reversed.
281 • list-item+: The list-item is appended to the end of the list
283 specified in the base policy.
284 To completely override a list value in a module file just use
286 list-items without any sign. Combining list-items with and without
287 signs in a single list value assignment is not allowed however an
288 existing list value can be modified in multiple further assignments.
289 Non-list key values in the policy module files are simply overriden.
291 The keys marked as Optional can be omitted in the policy definition
293 files. In that case, the values will be derived from the base keys.
294 Note that, this value propagation only applies to the policy definition
295 files. In the policy module files, each key that needs modification
296 must be explicitly specified.
297 Policy file placement and naming:
299 The policy files shipped in packages are placed in
301 /usr/share/crypto-policies/policies and the policy modules in
302 /usr/share/crypto-policies/policies/modules.
303 The locally configured policy files are placed in
305 /etc/crypto-policies/policies and the policy modules in
306 /etc/crypto-policies/policies/modules.
307 The policy and policy module files must have names in upper-case except
309 for the .pol and .pmod suffix as the update-crypto-policies command
310 always converts the policy name to upper-case before searching for the
311 policy on the filesystem.
312
314 update-crypto-policies(8)
315 This command manages the policies available to the various
316 cryptographic back ends and allows the system administrator to
317 change the active cryptographic policy level.
318 fips-mode-setup(8)
320 This command allows the system administrator to enable, or disable
321 the system FIPS mode and also apply the FIPS cryptographic policy
322 level which limits the allowed algorithms and protocols to these
323 allowed by the FIPS 140-2 requirements.
324
326 Exceptions
327 • Go-language applications do not yet follow the system-wide policy.
329 • GnuPG-2 application does not follow the system-wide policy.
331 In general only the data-in-transit is currently covered by the
333 system-wide policy.
334 If the system administrator changes the system-wide policy level with
336 the update-crypto-policies(8) command it is advisable to restart the
337 system as the individual back-end libraries read the configuration
338 files usually during their initialization. The changes in the policy
339 level thus take place in most cases only when the applications using
340 the back-end libraries are restarted.
341 Removed cipher suites and protocols
343 The following cipher suites and protocols are completely removed from
345 the core cryptographic libraries listed above:
346 • DES
348 • All export grade cipher suites
350 • MD5 in signatures
352 • SSLv2
354 • SSLv3
356 • All ECC curves smaller than 224 bits
358 • All binary field ECC curves
360 Cipher suites and protocols disabled in all policy levels
362 The following ciphersuites and protocols are available but disabled in
364 all crypto policy levels. They can be enabled only by explicit
365 configuration of individual applications:
366 • DH with parameters < 1024 bits
368 • RSA with key size < 1024 bits
370 • Camellia
372 • ARIA
374 • SEED
376 • IDEA
378 • Integrity only ciphersuites
380 • TLS CBC mode ciphersuites using SHA-384 HMAC
382 • AES-CCM8
384 • all ECC curves incompatible with TLS 1.3, including secp256k1
386 • IKEv1
388 Notable irregularities in the individual configuration generators
390 • OpenSSL: The minimum length of the keys and some other parameters
392 are enforced by the @SECLEVEL value which does not provide a fine
393 granularity. The list of TLS ciphers is not generated as an exact
394 list but by subtracting from all the supported ciphers for the
395 enabled key exchange methods. For that reason there is no way to
396 disable a random cipher. In particular all AES-128 ciphers are
397 disabled if the AES-128-GCM is not present in the list; all AES-256
398 ciphers are disabled if the AES-256-GCM is not present. The CBC
399 ciphers are disabled if there isn’t HMAC-SHA1 in the hmac list and
400 AES-256-CBC in the cipher list. To disable the CCM ciphers both
401 AES-128-CCM and AES-256-CCM must not be present in the cipher list.
402 • GnuTLS: The minimum length of the keys and some other parameters
404 are enforced by min-verification-profile setting in the GnuTLS
405 configuration file which does not provide fine granularity.
406 • OpenSSH: DH group 1 is always disabled on server even if the policy
408 allows 1024 bit DH groups in general. The OpenSSH configuration
409 option HostKeyAlgorithms is set only for the SSH server as
410 otherwise the handling of the existing known hosts entries would be
411 broken on client.
412 • Libreswan: The key_exchange parameter does not affect the generated
414 configuration. The use of regular DH or ECDH can be limited with
415 appropriate setting of the group parameter.
416
418 The ECDHE-GSS and DHE-GSS algorithms are newly introduced and must be
419 specified in the base policy for the SSH GSSAPI key exchange methods to
420 be enabled. Previously the legacy SSH GSSAPI key exchange methods were
421 automatically enabled when the SHA1 hash and DH parameters of at least
422 2048 bits were enabled.
423 Before the introduction of the custom crypto policies support it was
425 possible to have an completely arbitrary crypto policy created as a set
426 of arbitrary back-end config files in
427 /usr/share/crypto-policies/<POLICYNAME> directory. With the
428 introduction of the custom crypto policies it is still possible but
429 there must be an empty (possibly with any comment lines)
430 <POLICYNAME>.pol file in /usr/share/crypto-policies/policies so the
431 update-crypto-policies command can recognize the arbitrary custom
432 policy.
433
435 /etc/crypto-policies/back-ends
436 The individual cryptographical back-end configuration files.
437 Usually linked to the configuration shipped in the crypto-policies
438 package unless a configuration from local.d is added.
439 /etc/crypto-policies/config
441 The active crypto-policies level set on the system.
442 /etc/crypto-policies/local.d
444 Additional configuration shipped by other packages or created by
445 the system administrator. The contents of the
446 <back-end>-file.config is appended to the configuration from the
447 policy back end as shipped in the crypto-policies package.
448 /usr/share/crypto-policies/policies
450 System policy definition files.
451 /usr/share/crypto-policies/policies/modules
453 System subpolicy module definition files.
454 /etc/crypto-policies/policies
456 Custom policy definition files as configured by the system
457 administrator.
458 /etc/crypto-policies/policies/modules
460 Custom subpolicy module definition files as configured by the
461 system administrator.
462 /usr/share/crypto-policies/<'POLICYNAME'>
464 Pre-generated back-end configurations for policy POLICYNAME.
465
467 update-crypto-policies(8), fips-mode-setup(8)
468
470 Written by Tomáš Mráz.
471crypto-policies 02/13/2021 CRYPTO-POLICIES(7)