10.2. 암호화 정책, RHEL 핵심 암호화 구성 요소 및 프로토콜

SHA-1 사용 중단

RHEL 9에서는 암호화에 대한 SHA-1 사용은 DEFAULT 시스템 전체 암호화 정책에서 제한됩니다. HMAC를 제외하고 SHA-1은 TLS, DTLS, SSH, IKEv2, DNSSEC 및 Kerberos 프로토콜에서 더 이상 허용되지 않습니다. RHEL 시스템 전체 암호화 정책에 의해 제어되지 않는 개별 애플리케이션도 RHEL 9에서 SHA-1 해시를 사용하지 않습니다.

시나리오에 SHA-1을 사용하여 기존 또는 타사 암호화 서명을 확인해야 하는 경우 다음 명령을 입력하여 활성화할 수 있습니다. 

# update-crypto-policies --set DEFAULT:SHA1

또는 시스템 전체 암호화 정책을 LEGACY 정책으로 전환할 수 있습니다. LEGACY 는 또한 안전하지 않은 다른 많은 알고리즘을 사용할 수 있습니다. 자세한 내용은 RHEL 9 보안 강화 문서의 Re-enabling SHA-1 섹션을 참조하십시오.

여전히 SHA-1이 필요한 시스템과의 호환성 문제 해결 방법은 다음 KCS 문서를 참조하십시오.

모든 정책 수준에서 사용되지 않는 알고리즘

다음은 RHEL 9와 함께 제공되는 LEGACY,DEFAULT 및 FUTURE 암호화 정책에서 비활성화되는 알고리즘은 다음과 같습니다.

  • 버전 1.2보다 오래된 TLS (RHEL 9 이후의 RHEL 9는 RHEL 8의 1.0)
  • 버전 1.2보다 오래된 DTLS (RHEL 9 이후의 RHEL 9는 RHEL 8에서 < 1.0임)
  • 매개 변수를 사용하는 DH < 2048 비트 (RHEL 9 이후 < 1024 비트)
  • 키 크기가 있는 RSA < 2048비트 이후 RHEL 9는 RHEL 8에서 1024비트임)
  • DSA(RHEL 9 이후의 경우 RHEL 8에서는 1024비트)
  • 3DES (RHEL 9 이후)
  • RC4 (RHEL 9 이후)
  • FFDHE-1024 (RHEL 9 이후)
  • DHE-DSS (RHEL 9 이후)
  • Camellia(RHEL 9 이후)
  • ARIA
  • SEED
  • IDEA
  • 무결성 전용 암호화 제품군
  • SHA-384 HMAC를 사용하는 TLS CBC 모드 암호화 제품군
  • AES-CCM8
  • 모든 ECC 곡선은 europ256k1을 포함한 TLS 1.3과 호환되지 않습니다.
  • IKEv1 (RHEL 8 이후)
  • BIND 구성의 NSEC3DSA (RHEL 9.2 이후)
주의

시나리오에 비활성화된 정책이 필요한 경우 사용자 지정 암호화 정책을 적용하거나 개별 애플리케이션을 명시적으로 구성하여 활성화할 수 있지만 결과 구성은 지원되지 않습니다.

TLS 변경 사항

RHEL 9에서 TLS 구성은 시스템 전체 암호화 정책 메커니즘을 사용하여 수행됩니다. 1.2 미만의 TLS 버전은 더 이상 지원되지 않습니다. DEFAULT,FUTURE 및 LEGACY 암호화 정책은 TLS 1.2 및 1.3만 허용합니다. 자세한 내용은 시스템 전체 암호화 정책 사용을 참조하십시오.

RHEL 9에 포함된 라이브러리에서 제공하는 기본 설정은 대부분의 배포에 충분히 안전합니다. TLS 구현에서는 가능한 경우 또는 기존 클라이언트 또는 서버의 연결을 방지할 수 없는 보안 알고리즘을 사용합니다. 보안 알고리즘 또는 프로토콜을 지원하지 않는 레거시 클라이언트나 서버가 연결되지 않거나 연결할 수 없는 엄격한 보안 요구 사항을 충족하는 환경에서 강화된 설정을 적용합니다.

EUS ( Extended Master Secret TLS Extension)가 FIPS 지원 시스템에서 적용됩니다.

RHSA-2023:3722 권고가 릴리스되면서 TLS 확장 마스터 시크릿 (ECDSA) 확장(RFC 7627)은 FIPS 지원 RHEL 9 시스템에서 TLS 1.2 연결에 필요합니다. 이는 FIPS-140-3 요구 사항에 따라 수행됩니다. TLS 1.3은 영향을 받지 않습니다.

ECDSA 또는 TLS 1.3을 지원하지 않는 레거시 클라이언트는 이제 RHEL 9에서 실행되는 FIPS 서버에 연결할 수 없습니다. 마찬가지로 FIPS 모드의 RHEL 9 클라이언트는 ECDSA 없이 TLS 1.2만 지원하는 서버에 연결할 수 없습니다. 실제로 이러한 클라이언트는 RHEL 6, RHEL 7 및 비 RHEL 레거시 운영 체제의 서버에 연결할 수 없습니다. 이는 OpenSSL의 기존 1.0.x 버전이 ECDSA 또는 TLS 1.3을 지원하지 않기 때문입니다.

RHEL 9에서는 SCP가 지원되지 않음

SCP(Secure Copy Protocol) 프로토콜은 더 이상 지원되지 않으므로 보호하기가 어렵습니다. 이로 인해 이미 보안 문제가 발생했습니다(예: CVE-2020-15778). RHEL 9에서 SCP는 기본적으로 SSH 파일 전송 프로토콜(S SFTP)으로 대체됩니다.

주의

기본적으로 SSH는 RHEL 9 시스템에서 이전 시스템(예: RHEL 6) 또는 이전 시스템에서 RHEL 9로 연결할 수 없습니다. 이전 버전에서 사용된 암호화 알고리즘이 이제 안전하지 않은 것으로 간주되기 때문입니다. 시나리오에 이전 시스템에 연결해야 하는 경우 ECDSA 및 ECDH 알고리즘을 레거시 시스템의 키로 사용하거나 RHEL 9 시스템에서 기존 암호화 정책을 사용할 수 있습니다. 자세한 내용은 RHEL 9에서 RHEL 6 시스템으로의 SSH 솔루션이 작동하지 않고 server-sig-algs 확장을 지원하지 않는 SSH 서버 및 클라이언트와의 연결 실패를 참조하십시오.

OpenSSH root 암호 로그인이 기본적으로 비활성화됨

RHEL 9에서 OpenSSH의 기본 구성은 사용자가 암호를 사용하여 root 로 로그인하지 못하도록 하여 공격자가 암호에 대한 무차별 공격을 통해 액세스할 수 없도록 합니다.

OpenSSH는 SHA-2를 추가로 적용합니다.

암호화 목적으로 덜 안전한 SHA-1 메시지 다이제스트에서 추가로 마이그레이션하려는 노력의 일환으로 OpenSSH에서 다음과 같은 변경이 이루어졌습니다.

  • 시스템에 SHA-1을 사용할 수 있는지 여부를 sshd 시작 시 검사를 추가했습니다. 사용할 수 없는 경우 OpenSSH는 작업에 SHA-1을 사용하지 않습니다. 이렇게 하면 DSS 키가 있을 때 로드가 제거되고 사용 가능한 경우 광고 rsa-sha2 조합도 적용됩니다.
  • SSH 개인 키 변환에서 OpenSSH는 RSA 키를 테스트하는 데 명시적으로 SHA-2를 사용합니다.
  • 서버 측에서 SHA-1 서명을 사용할 수 없는 경우 sshd 는 SHA-2를 사용하여 호스트 키 증명을 확인합니다. 이는 RHEL 8 및 이전 버전의 클라이언트와 호환되지 않을 수 있습니다.
  • 클라이언트 측에서 SHA-1 알고리즘을 사용할 수 없는 경우 OpenSSH는 SHA-2를 사용합니다.
  • 클라이언트 측에서 OpenSSH는 SHA-1이 키 증명 요청에 사용되거나 해시 알고리즘이 지정되지 않은 경우(기본값) SHA-2 기반 키 증명을 허용합니다. 이는 RSA 인증서에 대한 이미 존재하는 예외와 일치하며 지원되는 경우 최신 알고리즘을 사용하여 연결할 수 있습니다.

GnuTLS에는 FIPS 모드에서 TLS 1.2가 있는 ECDSA가 필요합니다.

FIPS-140-3 표준을 준수하기 위해 GnuTLS 서버 및 클라이언트에는 FIPS 모드에서 협상된 모든 TLS 1.2 연결에 대해 Extended Master Secret(ECDSA) 확장(RFC 7627)이 필요합니다. 시나리오에 ECDSA를 지원하지 않는 이전 서버 및 클라이언트와의 호환성을 유지해야 하며 TLS 1.3을 사용할 수 없는 경우 시스템 전체 암호화 하위 정책을 적용할 수 있습니다. 

# update-crypto-policies --set FIPS:NO-ENFORCE-EMS
주의

ECDSA 없이 TLS 1.2 연결을 허용하면 시스템이 더 이상 FIPS-140-3 요구 사항을 충족하지 않습니다.

GnuTLS는 더 이상 TPM 1.2를 지원하지 않습니다.

GnuTLS 라이브러리는 더 이상 신뢰할 수 있는 플랫폼 모듈(TPM) 1.2 기술을 지원하지 않습니다. GnuTLS API를 통해 TPM를 사용하는 애플리케이션은 TPM 2.0을 지원해야 합니다.

GOST에 대한 GnuTLS 지원이 제거되었습니다.

RHEL 8에서는 시스템 전체 암호화 정책을 통해 GOST 암호가 비활성화되었습니다. RHEL 9에서는 이러한 암호에 대한 지원이 GnuTLS 라이브러리에서 제거되었습니다.

Cyrus-sasl 은 Berkeley DB 대신 GDBM을 사용합니다.

이제 Cyrus-sasl 패키지가 libdb 종속성 없이 빌드되고, the sasldb 플러그인은 Berkeley DB 대신 GDBM 데이터베이스 형식을 사용합니다. 이전 Berkeley DB 형식으로 저장된 기존 SASL(Simple Authentication and Security Layer) 데이터베이스를 마이그레이션하려면 다음 구문으로 Cyrus bdb2current 도구를 사용합니다. 

$ cyrusbdb2current <sasldb_path> <new_path>

NSS가 FIPS 모드에서 ECDSA 적용

NSS(Network Security Services) 라이브러리에는 FIPS 140-3 표준에서 요구하는 모든 TLS 1.2 연결에 대해 확장 마스터 보안(ECDSA) 확장(RFC 7627)이 필요한 TLS-REQUIRE- ECDSA 정책이 포함됩니다. 시스템 전체 암호화 정책이 FIPS 로 설정된 경우 NSS는 새 정책을 사용합니다.

시나리오에 ECDSA 또는 TLS 1.3을 지원하지 않고 기존 시스템과 상호 작용해야 하는 경우 NO-ENFORCE- ECDSA 시스템 전체 암호화 하위 정책을 적용할 수 있습니다. 이러한 변경으로 인해 FIPS-140-3 요구 사항이 위반됩니다.

NSS는 더 이상 DBM 및 pk12util 기본값을 지원하지 않습니다

NNSS(Network Security Services) 라이브러리는 더 이상 신뢰 데이터베이스에 대한 DBM 파일 형식을 지원하지 않습니다. RHEL 8에서는 SQLite 파일 형식이 기본 형식이 되어 기존 DBM 데이터베이스가 읽기 전용 모드에서 열리고 SQLite로 자동 변환되었습니다. RHEL 9로 업그레이드하기 전에 DBM에서 SQLite로 신뢰 데이터베이스를 모두 업데이트합니다.

자세한 내용은 DBM에서 SQLite 프로시저로 NSS 데이터베이스 업데이트를 참조하십시오.

NSS pk12util 은 기본적으로 DES-3 및 SHA-1을 더 이상 사용하지 않음

이제 pk12util 툴에서 개인 키를 내보낼 때 기본적으로 DES-3 및 SHA-1 대신 AES 및 SHA-256 알고리즘을 사용합니다.

RHEL 9의 모든 서명에 대해 시스템 전체 암호화 정책에 의해 SHA-1이 비활성화됩니다.

NSS는 1023비트보다 짧은 RSA 키를 더 이상 지원하지 않습니다.

NSS(Network Security Services) 라이브러리의 업데이트는 모든 RSA 작업의 최소 키 크기를 128에서 1023비트로 변경합니다. 즉, NSS는 더 이상 다음 기능을 수행하지 않습니다.

  • RSA 키는 1023bit 미만의 비트를 생성합니다.
  • RSA 키가 1023비트보다 짧은 경우 RSA 서명을 서명하거나 확인합니다.
  • 1023비트보다 짧은 RSA 키를 사용하여 값을 암호화하거나 해독합니다.

FIPS 모드에서 OpenSSL ENGINE 확장 API가 지원되지 않음

레거시 확장 시스템인 ENGINE API는 새로운 공급자 API와 호환되지 않습니다. 따라서 openssl-pkcs11 및 openssl-ibmca 모듈과 같은 OpenSSL 엔진에서 제공하는 기능에 의존하는 애플리케이션은 FIPS 모드에서 사용할 수 없습니다.

제대로 작동하려면 OpenSSL의 FIPS 모드를 활성화해야 합니다.

FIPS 모드가 활성화된 openssl.cnf 구성 파일에서 기본값이 아닌 값을 사용하는 경우 특히 타사 FIPS 공급자를 사용하는 경우 openssl.cnf 파일에 fips=yes 를 추가합니다.

OpenSSL은 FIPS 모드에서 명시적 곡선 매개변수를 허용하지 않습니다.

일반 곡선 암호화 매개변수, 개인 키, 공개 키 및 명시적 곡선 매개변수가 더 이상 FIPS 모드에서 작동하지 않는 인증서입니다. FIPS 승인 곡선 중 하나를 사용하는 ASN.1 오브젝트 식별자로 곡선 매개변수를 지정하면 FIPS 모드에서 계속 작동합니다.

Libreswan 이제 기본적으로 ESN을 요청합니다.

Libreswan에서 설정 옵션 esn= 의 기본값은 no 에서 중 하나로 변경되었습니다. 즉, 연결을 시작할 때 Libreswan은 기본적으로 ESN(Extended Serial Number) 사용을 요청합니다. 특히 하드웨어 오프로드를 사용할 때 이 새로운 동작은 특정 네트워크 인터페이스 카드(NIC)가 ESN을 지원하지 않는 경우 IPsec 연결을 설정하는 것을 방지합니다. ESN을 비활성화하려면 esn= 를 no 로 설정하고 replay_window= 옵션을 32 이하의 값으로 설정합니다. 예를 들면 다음과 같습니다. 

  esn=no
  replay_window=32

replay_window= 옵션은 다른 메커니즘이 32보다 큰 창 크기로 ESN을 사용하기 때문에 필요합니다.