Microsoft SDL 암호화 권장 사항

아티클
05/24/2024

Microsoft에서 자체 제품 및 서비스에 필요한 것과 동일한 API, 알고리즘, 프로토콜 및 키 길이를 사용하도록 제품을 디자인할 때 이 정보를 참조로 사용합니다. 콘텐츠의 대부분은 보안 개발 수명 주기를 만드는 데 사용되는 Microsoft의 내부 보안 표준을 기반으로 합니다.

비 Windows 플랫폼의 개발자는 이러한 권장 사항을 활용할 수 있습니다. API 및 라이브러리 이름은 다를 수 있지만 알고리즘 선택, 키 길이 및 데이터 보호와 관련된 모범 사례는 플랫폼 간에 유사합니다.

보안 프로토콜, 알고리즘 및 키 길이 권장 사항

TLS/SSL 버전

제품 및 서비스는 암호화된 보안 버전의 TLS/SSL을 사용해야 합니다.

TLS 1.3을 사용하도록 설정해야 합니다.
TLS 1.2를 사용하도록 설정하여 이전 클라이언트와의 호환성을 향상시킬 수 있습니다.
TLS 1.1, TLS 1.0, SSL 3 및 SSL 2를 사용하지 않도록 설정해야 합니다.

대칭 블록 암호화, 암호화 모드 및 초기화 벡터

암호화 차단

대칭 블록 암호화를 사용하는 제품의 경우:

AES(Advanced Encryption Standard)를 사용하는 것이 좋습니다.
암호화에 사용되는 경우 3DES(Triple DES/TDEA) 및 RC4를 포함한 다른 모든 블록 암호화를 교체해야 합니다.

대칭 블록 암호화 알고리즘의 경우 최소 키 길이는 128비트이지만 256비트 키를 지원하는 것이 좋습니다. 새 코드에 권장되는 유일한 블록 암호화 알고리즘은 AES입니다(AES-128, AES-192 및 AES-256은 모두 허용되며, AES-192는 일부 프로세서에서 최적화하는 데 충분하지 않음).

암호화 모드

대칭 알고리즘은 다양한 모드에서 작동할 수 있으며, 대부분은 일반 텍스트 및 암호 텍스트의 연속 블록에 대한 암호화 작업을 함께 연결합니다.

대칭 블록 암호화는 다음 암호화 모드 중 하나로 사용해야 합니다.

암호화 블록 체인(CBC)
CTS(암호 텍스트 가로채기)
XTS(암호 텍스트 가로채기를 사용하는 XEX 기반 Tweaked-Codebook)

다음과 같은 일부 다른 암호화 모드에는 잘못 사용될 가능성이 더 높아진 구현 문제가 있습니다. 특히 ECB(전자 코드 북) 작업 모드는 피해야 합니다. CTR과 같은 "스트리밍 암호화 모드"에서 블록 암호화와 동일한 IV(초기화 벡터)를 다시 사용하면 암호화된 데이터가 표시될 수 있습니다. 아래 모드를 사용하는 경우 추가 보안 검토가 권장됩니다.

출력 피드백(OFB)
암호화 피드백(CFB)
카운터(CTR)
앞의 "권장" 목록에 없는 다른 항목

초기화 벡터(IV)

또한 모든 대칭 블록 암호는 암호화가 강력한 난수와 함께 초기화 벡터로 사용해야 합니다. 초기화 벡터는 상수 또는 조건자 값이 되어서는 안 됩니다. 암호화된 강력한 난수 생성에 대한 권장 사항은 난수 생성기를 참조하세요.

여러 암호화 작업을 수행할 때 초기화 벡터를 다시 사용하면 안 됩니다. 재사용은 특히 OFB(출력 피드백) 또는 카운터(CTR)와 같은 스트리밍 암호화 모드를 사용하는 경우 암호화되는 데이터에 대한 정보를 표시할 수 있습니다.

AES-GCM 및 AES-CCM 권장 사항

AES-GCM(Galois/카운터 모드) 및 AES-CCM(CBC-MAC 카운터)은 널리 인증된 암호화 모드로 사용됩니다. 기밀성과 무결성 보호를 결합하여 보안 통신에 유용합니다. 그러나, 그들의 취약성은 nonce 재사용에 있다. 동일한 nonce(초기화 벡터)를 두 번 사용하면 치명적인 결과를 초래할 수 있습니다.

NIST SP 800-38D, 블록 암호화 작업 모드에 대한 권장 사항: GCM(Galois/Counter Mode) 및 GMAC에 설명된 대로 nonce 지침을 따르는 것이 좋습니다. 최대 호출 수와 관련하여 섹션 8.3에 특히 주의해야 합니다.

또 다른 옵션은 암호화되는 모든 메시지에 대해 고유한 AES-GCM/CCM 키를 생성하여 최대 호출 수를 1로 효과적으로 제한합니다. 이 방법은 미사용 데이터를 암호화하는 데 권장됩니다. 여기서 카운터를 사용하거나 지정된 키에 대한 최대 호출 수를 추적할 수 있는지 확인하는 것은 실용적이지 않습니다.

미사용 데이터를 암호화하기 위해 암호화 및 MAC에 별도의 키를 사용하도록 하여 MAC(메시지 인증 코드)과 함께 AES-CBC를 암호화 후 MAC 스키마를 사용하는 대안으로 사용할 수도 있습니다.

무결성 확인

암호화는 기본적으로 기밀성과 무결성 보증을 모두 제공한다는 일반적인 오해입니다. 많은 암호화 알고리즘은 검사 무결성을 제공하지 않으며 변조 공격에 취약할 수 있습니다. 보내기 전과 수신 후에 데이터의 무결성을 보장하기 위해 추가 단계를 수행해야 합니다.

AES-GCM과 같은 AEAD(연결된 데이터)와 함께 인증된 암호화 알고리즘을 사용할 수 없는 경우 암호화 및 MAC에 대해 별도의 키를 사용하도록 하여 MAC(메시지 인증 코드)을 사용하여 무결성의 유효성을 검사하는 것이 대안입니다.

암호화 및 MAC에 대해 별도의 키를 사용하는 것이 중요합니다. 두 키를 저장할 수 없는 경우 유효한 대안은 KDF(적합한 키 파생 함수)를 사용하여 기본 키에서 두 개의 키를 파생하는 것입니다. 하나는 암호화용이고 다른 하나는 MAC용입니다. 자세한 내용은 SP 800-108 Rev. 1, Pseudorandom 함수를 사용하여 키 파생에 대한 권장 사항 | CSRC(nist.gov).

비대칭 알고리즘, 키 길이 및 패딩 모드

RSA

RSA는 암호화, 키 교환 및 서명에 사용할 수 있습니다.
RSA 암호화는 OAEP 또는 RSA-PSS 패딩 모드를 사용해야 합니다.
기존 코드는 호환성을 위해서만 PKCS #1 v1.5 패딩 모드를 사용해야 합니다.
null 패딩은 사용하지 않는 것이 좋습니다.
최소 2048비트 키 길이를 권장하지만 3072비트 키 길이를 지원하는 것이 좋습니다.

ECDSA 및 ECDH

ECDH 기반 키 교환 및 ECDSA 기반 서명은 세 가지 NIST 승인 곡선(P-256, P-384 또는 P521) 중 하나를 사용해야 합니다.
P-256에 대한 지원은 최소값으로 간주되어야 하지만 P-384를 지원하는 것이 좋습니다.

정수 디피 헬만

키 길이 >= 2048비트가 권장됩니다.
그룹 매개 변수는 잘 알려진 명명된 그룹(예 : RFC 7919)이거나 신뢰할 수 있는 당사자에 의해 생성되고 사용하기 전에 인증되어야 합니다.

키 수명

모든 키에 대한 cryptoperiod 를 정의합니다.
- 예를 들어 데이터 암호화 키 또는 DEK라고도 하는 데이터 암호화에 대한 대칭 키는 데이터를 암호화하는 데 최대 2년의 사용 기간을 가질 수 있습니다( 발신기 사용 기간이라고도 함). 수신자 사용 기간이라고도 하는 3년 이상의 암호 해독에 유효한 사용 기간이 있음을 정의할 수 있습니다.
제한된 활성 수명을 달성하기 위해 메커니즘을 제공하거나 키를 교체하는 프로세스가 있어야 합니다. 활성 수명이 종료된 후에도 키는 새 데이터(예: 암호화 또는 서명)를 생성하는 데 사용되지 않아야 하지만 여전히 데이터를 읽는 데 사용될 수 있습니다(예: 암호 해독 또는 확인).

난수 생성기

임의성이 필요한 경우 모든 제품 및 서비스는 암호화된 보안 난수 생성기를 사용해야 합니다.

CNG

BCRYPT_USE_SYSTEM_PREFERRED_RNG 플래그와 함께 BCryptGenRandom을 사용합니다.

Win32/64

레거시 코드는 커널 모드에서 RtlGenRandom을 사용할 수 있습니다.
새 코드는 BCryptGenRandom 또는 CryptGenRandom을 사용해야 합니다.
C 함수 Rand_s()도 권장됩니다(Windows에서는 CryptGenRandom을 호출).
Rand_s()는 Rand()를 안전하고 성능이 좋은 대체입니다.
Rand()는 암호화 애플리케이션에 사용할 수 없습니다.

.NET

RandomNumberGenerator를 사용합니다.

PowerShell

Get-SecureRandom(PowerShell)을 사용합니다.

Windows 스토어 응용 프로그램

Windows 스토어 앱은 CryptographicBuffer.GenerateRandom 또는 CryptographicBuffer.GenerateRandomNumber 를 사용할 수 있습니다.

Linux/macOS

디바이스는 /dev/urandom 시스템 호출과 마찬가지로 임의 데이터의 암호화된 강력한 원본을 getrandom(2) 제공합니다.

권장하지 않음

난수 생성과 관련된 안전하지 않은 함수는 rand, System.Random(.NET), GetTickCount, GetTickCount64 및 Get-Random(PowerShell cmdlet)입니다.
이중 타원 곡선 난수 생성기("DUAL_EC_DRBG") 알고리즘의 사용은 허용되지 않습니다.

Windows 플랫폼 지원 암호화 라이브러리

Windows 플랫폼에서는 운영 체제에 기본 제공되는 암호화 API를 사용하는 것이 좋습니다. 다른 플랫폼에서 개발자는 사용할 플랫폼이 아닌 암호화 라이브러리를 평가하도록 선택할 수 있습니다. 일반적으로 플랫폼 암호화 라이브러리는 애플리케이션과 번들로 제공되는 것이 아니라 운영 체제의 일부로 제공되므로 더 자주 업데이트됩니다.

플랫폼 및 플랫폼이 아닌 암호화와 관련된 사용량 결정은 다음 요구 사항에 따라 결정해야 합니다.

라이브러리는 알려진 보안 취약성이 없는 현재 지원 중인 버전이어야 합니다.
최신 보안 프로토콜, 알고리즘 및 키 길이가 지원되어야 합니다.
(선택 사항) 라이브러리는 이전 버전과의 호환성을 위해서만 이전 보안 프로토콜/알고리즘을 지원할 수 있어야 합니다.

네이티브 코드

암호화 기본 형식: 릴리스가 Windows에 있는 경우 가능한 경우 CNG를 사용합니다.
코드 서명 확인: WinVerifyTrust 는 Windows 플랫폼에서 코드 서명을 확인하는 데 지원되는 API입니다.
인증서 유효성 검사(코드 서명 또는 SSL/TLS/DTLS에 대한 제한된 인증서 유효성 검사에 사용됨): CAPI2 API; 예를 들어 CertGetCertificateChain 및 CertVerifyCertificateChainPolicy입니다.

관리 코드(.NET)

암호화 기본 형식: System.Security.Cryptography 네임스페이스에 정의된 API를 사용합니다.
사용 가능한 최신 버전의 .NET을 사용합니다.

키 파생 함수

키 파생은 공유 비밀 또는 기존 암호화 키에서 암호화 키 자료를 파생시키는 프로세스입니다. 제품은 권장 키 파생 함수를 사용해야 합니다. 사용자가 선택한 암호에서 키를 파생하거나 인증 시스템의 스토리지에 대한 암호를 해시하는 것은 이 지침에서 다루지 않는 특별한 경우입니다. 개발자는 전문가와 상의해야 합니다.

다음 표준은 사용하기 위해 권장되는 KDF 함수를 지정합니다.

NIST SP 800-108(수정 버전 1): 의사 함수를 사용하는 키 파생에 대한 권장 사항입니다. 특히 HMAC를 의사 정의 함수로 사용하는 카운터 모드의 KDF
NIST SP 800-56A(수정 버전 3): 불연속 로그 암호화를 사용하는 쌍별 키 설정 체계에 대한 권장 사항입니다.

기존 키에서 키를 파생하려면 알고리즘 중 하나와 함께 BCryptKeyDerivation API를 사용합니다.

BCRYPT_SP800108_CTR_HMAC_ALGORITHM
BCRYPT_SP80056A_CONCAT_ALGORITHM

공유 비밀(키 계약의 출력)에서 키를 파생하려면 다음 알고리즘 중 하나와 함께 BCryptDeriveKey API를 사용합니다.

BCRYPT_KDF_SP80056A_CONCAT
BCRYPT_KDF_HMAC

인증서의 유효성 검사

TLS 또는 DTLS를 사용하는 제품은 연결하는 엔터티의 X.509 인증서를 완전히 확인해야 합니다. 이 프로세스에는 인증서의 다음 부분에 대한 확인이 포함됩니다.

Do기본 이름입니다.
유효 날짜(시작 날짜와 만료 날짜 모두).
해지 상태
사용량(예: 서버의 경우 "서버 인증", 클라이언트의 경우 "클라이언트 인증")
신뢰 체인 - 인증서는 플랫폼에서 신뢰하거나 관리자가 명시적으로 구성한 루트 CA(인증 기관)에 연결해야 합니다.

이러한 확인 테스트 중 하나라도 실패하면 제품에서 엔터티와의 연결을 종료해야 합니다.

"자체 서명된" 인증서를 사용하지 마세요. 자체 서명은 기본적으로 신뢰, 지원 해지 또는 키 갱신을 전달하지 않습니다.

암호화 해시 함수

제품은 SHA-2 해시 알고리즘(SHA-256, SHA-384 및 SHA-512)의 SHA-2 제품군을 사용해야 합니다. 보안을 위해 128비트 미만으로 암호화 해시를 잘리는 것은 허용되지 않습니다. SHA-256 사용은 최소이지만 SHA-384를 지원하는 것이 좋습니다.

MAC/HMAC/키 해시 알고리즘

MAC는 받는 사람이 비밀 키를 사용하여 보낸 사람의 신뢰성과 메시지 무결성을 모두 확인할 수 있도록 메시지에 연결되는 정보입니다.

모든 기본 해시 또는 대칭 암호화 알고리즘도 사용하는 것이 좋습니다. 현재 여기에는 HMAC-SHA256, HMAC-SHA384 및 HMAC-SHA512 함수가 포함됩니다. HMAC-SHA256 사용은 최소이지만 HMAC-SHA384를 지원하는 것이 좋습니다.

HMAC를 128비트 미만으로 잘림하는 것은 권장되지 않습니다.

디자인 및 운영 고려 사항

필요에 따라 암호화 키를 바꾸기 위한 메커니즘을 제공해야 합니다. 활성 수명이 끝나거나 암호화 키가 손상되면 키를 교체해야 합니다.
- 인증서를 갱신할 때마다 새 키로 갱신해야 합니다.
암호화 알고리즘을 사용하여 데이터를 보호하는 제품에는 향후 다른 알고리즘으로 마이그레이션할 수 있도록 해당 콘텐츠와 함께 충분한 메타데이터가 포함되어야 합니다. 이 메타데이터에는 사용된 알고리즘, 키 크기 및 패딩 모드가 포함되어야 합니다.
- 암호화 민첩성에 대한 자세한 내용은 암호화 민첩성 문서를 참조하세요.
사용 가능한 경우 제품은 서명 형식(예: 표준 기존 형식 사용)을 포함하여 다시 설치하는 대신 플랫폼 제공 암호화 프로토콜을 설정하여 사용해야 합니다.
최종 사용자에게 암호화 작업 실패를 보고하지 마세요. 원격 호출자(예: 클라이언트-서버 시나리오의 웹 클라이언트 또는 클라이언트)에 오류를 반환하는 경우 일반 오류 메시지만 사용합니다.
- 범위를 벗어난 오류 또는 잘못된 길이 오류를 직접 보고하는 것과 같은 불필요한 정보를 제공하지 마세요. 자세한 정보 로깅을 사용하는 경우에만 서버에서 자세한 정보 표시 오류를 기록합니다.
다음 항목을 통합하는 모든 디자인에는 추가 보안 검토가 권장됩니다.
- 보안에 주로 초점을 맞춘 새 프로토콜(예: 인증 또는 권한 부여 프로토콜)
- 새로운 방식으로 또는 비표준 방식으로 암호화를 사용하는 새 프로토콜입니다. 고려 사항의 예는 다음과 같습니다.
  - 프로토콜을 구현하는 제품에서 프로토콜 구현의 일환으로 암호화 API 또는 메서드를 호출하나요?
  - 프로토콜은 인증 또는 권한 부여에 사용되는 다른 프로토콜에 따라 달라지나요?
  - 프로토콜에서 키와 같은 암호화 요소에 대한 저장 형식을 정의하나요?
자체 서명된 인증서는 권장되지 않습니다. 원시 암호화 키 사용과 같이 자체 서명된 인증서를 사용하는 것은 기본적으로 사용자 또는 관리자에게 신뢰 결정을 내릴 수 있는 근거를 제공하지 않습니다.
- 반면, 신뢰할 수 있는 인증 기관에 기반한 인증서를 사용하면 연결된 프라이빗 키에 의존하기 위한 근거를 명확히 하고 보안 오류가 있는 경우 해지 및 업데이트를 사용할 수 있습니다.

다음을 통해 공유