crypto-policies - Man Page

system-wide crypto policies overview

Description

The security of cryptographic components of the operating system does not remain constant over time. Algorithms, such as cryptographic hashing and encryption, typically have a lifetime, after which they are considered either too risky to use or plain insecure. That means, we need to phase out such algorithms from the default settings or completely disable them if they could cause an irreparable problem.

While in the past the algorithms were not disabled in a consistent way and different applications applied different policies, the system-wide crypto-policies followed by the crypto core components allow consistently deprecating and disabling algorithms system-wide.

Several preconfigured policies (DEFAULT, LEGACY, FUTURE, and FIPS) and subpolicies are included in the crypto-policies(7) package. System administrators or third-party vendors can define custom policies and subpolicies.

The recommended way to modify the effective configuration is to apply a custom subpolicy on top of a predefined policy. This allows configuration to evolve with future updates of the predefined policies keeping desired modification in place. Modifying effective configuration by defining a fully custom policy prevents the configuration from evolving with future updates of the predefined policies. The syntax to define custom policies and subpolicies is described in the Crypto Policy Definition Format section below.

For rationale, see RFC 7457 for a list of attacks taking advantage of legacy crypto algorithms.

Covered Applications

Crypto-policies apply to the configuration of the core cryptographic subsystems, covering TLS, IKE, IPSec, DNSSec, and Kerberos protocols; i.e., the supported secure communications protocols on the base operating system.

Once an application runs in the operating system, it follows the default or selected policy and refuses to fall back to algorithms and protocols not within the policy, unless the user has explicitly requested the application to do so. That is, the policy applies to the default behavior of applications when running with the system-provided configuration but the user can override it on an application-specific basis.

The policies currently provide settings for these applications and libraries:

Applications using the above libraries and tools are covered by the cryptographic policies unless they are explicitly configured otherwise.

Provided Policies

LEGACY

This policy ensures maximum compatibility with legacy systems; it is less secure and it includes support for TLS 1.0, TLS 1.1, and SSH2 protocols or later. The algorithms DSA and 3DES are allowed, while RSA and Diffie-Hellman parameters are accepted if larger than 1024 bits. This policy provides at least 64-bit security.

  • MACs: all HMAC with SHA-1 or better + all modern MACs (Poly1305 etc.)
  • Curves: all prime >= 255 bits (including Bernstein curves)
  • Signature algorithms: with SHA1 hash or better (DSA allowed)
  • TLS Ciphers: all available >= 112-bit key, >= 128-bit block (including 3DES, excluding RC4)
  • Non-TLS Ciphers: same as TLS ciphers with added Camellia
  • Key exchange: ECDHE, RSA, DHE
  • DH params size: >= 1024
  • RSA keys size: >= 1024
  • DSA params size: >= 1024
  • TLS protocols: TLS >= 1.0, DTLS >= 1.0
DEFAULT

The DEFAULT policy is a reasonable default policy for today’s standards. It allows the TLS 1.2, and TLS 1.3 protocols, as well as IKEv2 and SSH2. The Diffie-Hellman parameters are accepted if they are at least 2048 bits long. This policy provides at least 112-bit security with the exception of allowing SHA-1 signatures in DNSSec where they are still prevalent.

  • MACs: all HMAC with SHA-1 or better + all modern MACs (Poly1305 etc.)
  • Curves: all prime >= 255 bits (including Bernstein curves)
  • Signature algorithms: with SHA-224 hash or better (no DSA)
  • TLS Ciphers: >= 128-bit key, >= 128-bit block (AES, ChaCha20, including AES-CBC)
  • non-TLS Ciphers: as TLS Ciphers with added Camellia
  • key exchange: ECDHE, RSA, DHE (no DHE-DSS)
  • DH params size: >= 2048
  • RSA keys size: >= 2048
  • TLS protocols: TLS >= 1.2, DTLS >= 1.2
NEXT

The NEXT policy is just an alias to the DEFAULT policy.

FUTURE

A conservative security policy that is believed to withstand any near-term future attacks. This policy does not allow the use of SHA-1 in signature algorithms. The policy also provides some (not complete) preparation for post-quantum encryption support in form of 256-bit symmetric encryption requirement. The RSA and Diffie-Hellman parameters are accepted if larger than 3071 bits. This policy provides at least 128-bit security.

  • MACs: all HMAC with SHA-256 or better + all modern MACs (Poly1305 etc.)
  • Curves: all prime >= 255 bits (including Bernstein curves)
  • Signature algorithms: with SHA-256 hash or better (no DSA)
  • TLS Ciphers: >= 256-bit key, >= 128-bit block, only Authenticated Encryption (AE) ciphers
  • non-TLS Ciphers: same as TLS ciphers with added non AE ciphers and Camellia
  • key exchange: ECDHE, DHE (no DHE-DSS, no RSA)
  • DH params size: >= 3072
  • RSA keys size: >= 3072
  • TLS protocols: TLS >= 1.2, DTLS >= 1.2
FIPS

A policy to aid conformance to the FIPS 140-2 requirements. This policy is used internally by the fips-mode-setup(8) tool which can switch the system into the FIPS 140-2 mode. This policy provides at least 112-bit security.

  • MACs: all HMAC with SHA1 or better
  • Curves: all prime >= 256 bits
  • Signature algorithms: with SHA-256 hash or better (no DSA)
  • TLS Ciphers: >= 128-bit key, >= 128-bit block (AES, including AES-CBC)
  • non-TLS Ciphers: same as TLS Ciphers
  • key exchange: ECDHE, DHE (no DHE-DSS, no RSA)
  • DH params size: >= 2048
  • RSA params size: >= 2048
  • TLS protocols: TLS >= 1.2, DTLS >= 1.2
EMPTY

All cryptographic algorithms are disabled (used for debugging only, do not use).

Crypto Policy Definition Format

The crypto policy definition files have a simple syntax following an INI file key = value syntax with these particular features:

The available options are:

Full policy definition files have suffix .pol, subpolicy files have suffix .pmod. Subpolicies do not have to have values set for all the keys listed above.

The effective configuration of a policy with subpolicies applied is the same as a configuration from a single policy obtained by concatenating the policy and the subpolicies in question.

Policy file placement and naming:

The policy files shipped in packages are placed in /usr/share/crypto-policies/policies and the subpolicies in /usr/share/crypto-policies/policies/modules.

Locally configured policy files should be placed in /etc/crypto-policies/policies and subpolicies in /etc/crypto-policies/policies/modules.

The policy and subpolicy files must have names in upper-case except for the .pol and .pmod suffix as the update-crypto-policies command always converts the policy name to upper-case before searching for the policy on the filesystem.

Commands

update-crypto-policies(8)

This command manages the policies available to the various cryptographic back ends and allows the system administrator to change the active cryptographic policy.

fips-mode-setup(8)

This command allows the system administrator to enable, or disable the system FIPS mode and also apply the FIPS cryptographic policy which limits the allowed algorithms and protocols to these allowed by the FIPS 140-2 requirements.

Notes

Known notable exceptions

In general only the data-in-transit is currently covered by the system-wide policy.

If the system administrator changes the system-wide policy with the update-crypto-policies(8) command it is advisable to restart the system as the individual back-end libraries read the configuration files usually during their initialization. The changes in the policy thus take place in most cases only when the applications using the back-end libraries are restarted.

Removed cipher suites and protocols

The following cipher suites and protocols are completely removed from the core cryptographic libraries listed above:

Cipher suites and protocols disabled in all predefined policies

The following ciphersuites and protocols are available but disabled in all predefined crypto policies:

Notable irregularities in the individual configuration generators

History

The ECDHE-GSS and DHE-GSS algorithms are newly introduced and must be specified in the base policy for the SSH GSSAPI key exchange methods to be enabled. Previously the legacy SSH GSSAPI key exchange methods were automatically enabled when the SHA1 hash and DH parameters of at least 2048 bits were enabled.

Before the introduction of the custom crypto policies support it was possible to have an completely arbitrary crypto policy created as a set of arbitrary back-end config files in /usr/share/crypto-policies/<POLICYNAME> directory. With the introduction of the custom crypto policies it is still possible but there must be an empty (possibly with any comment lines) <POLICYNAME>.pol file in /usr/share/crypto-policies/policies so the update-crypto-policies command can recognize the arbitrary custom policy. No subpolicies must be used with such an arbitrary custom policy. Modifications from local.d will be appended to the files provided by the policy.

The use of the following historaically available options is discouraged:

The following options are deprecated, please rewrite your policies:

Files

/etc/crypto-policies/back-ends

The individual cryptographical back-end configuration files. Usually linked to the configuration shipped in the crypto-policies package unless a configuration from local.d is added.

/etc/crypto-policies/config

A file containing the name of the active crypto-policy set on the system.

/etc/crypto-policies/local.d

Additional configuration shipped by other packages or created by the system administrator. The contents of the <back-end>-file.config is appended to the configuration from the policy back end as shipped in the crypto-policies package.

/usr/share/crypto-policies/policies

System policy definition files.

/usr/share/crypto-policies/policies/modules

System subpolicy definition files.

/etc/crypto-policies/policies

Custom policy definition files as configured by the system administrator.

/etc/crypto-policies/policies/modules

Custom subpolicy definition files as configured by the system administrator.

/usr/share/crypto-policies/<'POLICYNAME'>

Pre-generated back-end configurations for policy POLICYNAME.

See Also

update-crypto-policies(8), fips-mode-setup(8)

Author

Written by Tomáš Mráz.

Referenced By

gsissh_config(5), gsisshd_config(5), ssh_config(5), sshd_config(5), update-crypto-policies(8).

08/24/2022