암호 스위트

Cipher suite

암호 스위트는 네트워크 연결을 보호하는 데 도움이 되는 알고리즘 세트입니다.스위트에서는 일반적으로 Transport Layer Security(TLS; 트랜스포트층 보안) 또는 현재는 폐지된 이전 버전의 Secure Socket Layer(SSL; Secure 소켓층)를 사용합니다.암호 스위트에는 보통 키 교환 알고리즘, 벌크 암호화 알고리즘 및 메시지 인증 코드([1]MAC) 알고리즘이 포함됩니다.

키 교환 알고리즘은 2개의 디바이스 간에 키를 교환하기 위해 사용됩니다.이 키는 두 대의 머신 간에 전송되는 메시지를 암호화 및 복호화하기 위해 사용됩니다.대량 암호화 알고리즘은 전송되는 데이터를 암호화하는 데 사용됩니다.MAC 알고리즘은 송신된 데이터가 전송 중에 변경되지 않도록 데이터 무결성 체크를 제공합니다.또한 암호 스위트에는 서버 및 클라이언트 인증에 도움이 되는 시그니처 및 인증 알고리즘이 포함될 수 있습니다.

전체적으로 이들 알고리즘의 다른 조합을 포함하는 수백 개의 다른 암호 스위트가 있습니다.일부 암호 스위트는 다른 암호 스위트보다 보안이 우수합니다.

암호 스위트 개념의 구조와 사용은 TLS 표준 [2]문서에 정의되어 있습니다.TLS 1.2는 TLS의 가장 일반적인 버전입니다.다음 버전의 TLS(TLS 1.3)에는 암호 스위트에 대한 추가 요건이 포함되어 있습니다.TLS 1.3은 최근에 표준화되었으며 아직 널리 사용되고 있지 않습니다.TLS 1.2에 대해 정의된 암호 스위트는 정의에 달리 명시되어 있지 않는 한 TLS 1.3 또는 그 반대로 사용할 수 없습니다.

명명된 암호 스위트의 참조 목록은 TLS 암호 스위트 [3]레지스트리에 제공됩니다.

역사

암호화 사용은 SSL(Secure Socket Layer) 전송 프로토콜의 일부입니다.SSL은 대부분의 경우 TLS에 의해 계승되고 있습니다.그러나 SSL의 원래 초안에는 Cipher Suite라는 이름이 사용되지 않았습니다.대신 클라이언트와 서버가 연결을 보호하기 위해 작은 암호 집합에서 선택하는 기능을 Cipher-Choice라고 [4][5]했습니다.SSL v3(SSL의 마지막 버전)에서야 Cipher Suite라는 이름이 [6]사용되었습니다.이후 모든 버전의 TLS는 표준화에 Cipher Suite를 사용했습니다.Cipher Suite의 개념과 목적은 이 용어가 처음 만들어진 이후로 변경되지 않았습니다.이 알고리즘은 2대의 머신이 접속을 보호하기 위해 사용할 알고리즘을 결정하기 위해 머신이 지원하는 알고리즘을 기술하는 구조로서 사용되고 있습니다.변경된 것은 암호 스위트에서 지원되는 알고리즘 버전입니다.각 버전의 TLS에서는 보다 강력한 버전의 알고리즘에 대한 지원이 추가되어 안전하지 않은 것으로 식별된 알고리즘 버전에 대한 지원이 삭제되었습니다.

TLS 1.3은, 머신간의 암호 스위트 조정 방법의 변경을 나타내고 있습니다.사용하는 2개의 통신 머신에 대해 선택된 암호 스위트는 핸드쉐이크 프로세스에 의해 결정됩니다.송신할 필요가 있는 메시지의 수를 삭감하기 위해서, 핸드쉐이크 프로세스에 대한 TLS 1.3 의 변경이 행해졌습니다.이것에 의해, 이전 버전의 TLS에 비해, 처리의 삭감, 패킷 트래픽의 삭감, 효율의 향상을 실현할 수 있습니다.

명명 방식

각 암호 스위트에는 암호 스위트를 식별하고 암호 스위트의 알고리즘 내용을 설명하는 데 사용되는 고유한 이름이 있습니다.암호 스위트 이름의 각 세그먼트는 서로 다른 알고리즘 또는 프로토콜을 나타냅니다.암호 스위트 이름의 예를 다음에 나타냅니다.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

이 이름의 의미는 다음과 같습니다.

  • TLS는 이 암호 스위트의 대상 프로토콜을 정의합니다.일반적으로 TLS입니다.
  • ECDHE는 사용되는 키 교환 알고리즘을 나타냅니다.
  • 핸드쉐이크 중 RSA 인증 메커니즘
  • AES 세션 암호
  • 암호용 128 세션 암호 키 크기(비트).
  • GCM 타입의 암호화(암호 블록 의존관계 및 추가 옵션).
  • SHA(SHA2) 해시 함수.다이제스트 256 이상일 경우.시그니처 메커니즘메시지 인증에 사용되는 메시지 인증 알고리즘을 나타냅니다.
  • 256 다이제스트사이즈(비트).

풀 핸드쉐이크: 암호 스위트 조정

암호 스위트를 사용하려면 클라이언트와 서버가 메시지 교환에 사용하는 특정 암호 스위트에 동의해야 합니다.클라이언트와 서버 모두 합의된 암호 스위트를 지원해야 합니다.클라이언트와 서버가 암호 스위트에 동의하지 않으면 연결이 [7]확립되지 않습니다.이 선택 프로세스는 TLS 핸드쉐이크 프로토콜 중에 수행됩니다.TLS 1.3에는 과거 및 현재 버전의 TLS/SSL과 비교하여 다른 TLS 핸드쉐이크 프로토콜이 포함되어 있습니다.

사용하는 암호 스위트를 조정한 후에도 서버와 클라이언트는 현재 핸드쉐이크 또는 새로운 핸드쉐이크로 ChangeCipherSpec 프로토콜을 사용하여 조정된 암호를 변경할 수 있습니다.

서버가 지원하는 TLS 암호를 테스트하려면 SSL/TLS 스캐너를 사용할 수 있습니다.[1]

TLS 1.0 – 1.2 핸드쉐이크

TLS 1.2에서 동작하는 클라이언트와 서버가 사용하는 암호 스위트를 조정하는 방법을 시각적으로 나타냅니다.

이 클라이언트는 클라이언트를 전송하여 프로세스를 시작합니다.사용 중인 TLS 버전 및 클라이언트 기본 설정 순서대로 암호 스위트 목록을 포함하는 서버에 대한 Hello 메시지입니다.이에 응답하여 서버는 선택한 암호 스위트와 세션 ID를 포함하는 serverHello 메시지를 보냅니다.다음으로 서버는 디지털 증명서를 송신하고, 그 ID를 클라이언트에 확인합니다.서버는, 필요에 따라서 클라이언트의 디지털 인증을 요구할 수도 있습니다.

클라이언트와 서버가 사전 공유 키를 사용하지 않는 경우 클라이언트는 서버에 암호화된 메시지를 발송하여 클라이언트와 서버가 교환 중에 사용하는 개인 키를 계산할 수 있도록 합니다.

서버의 인증을 확인하고 필요에 따라 개인 키를 교환한 후 클라이언트는 핸드쉐이크 프로세스가 완료되었음을 알리는 완료 메시지를 보냅니다.이 메시지를 수신하면 서버는 핸드쉐이크가 완료되었음을 확인하는 완료 메시지를 발송합니다.이것으로 클라이언트와 서버는 서로 통신하기 위해 어떤 암호 스위트를 사용할지 합의했습니다.

TLS 1.3에서 동작하는 클라이언트와 서버가 사용하는 암호 스위트를 조정하는 방법을 시각적으로 나타냅니다.

TLS 1.3 핸드쉐이크

2대의 머신이 TLS 1.3에 대응하고 있는 경우는, TLS 1.3 핸드쉐이크 프로토콜을 사용해 사용하는 암호 스위트를 조정합니다.TLS 1.3의 핸드쉐이크는 이전 버전의 TLS/SSL에서 필요했던2개의 라운드 트립에 비해 1개의 라운드 트립으로 압축되었습니다.

먼저 클라이언트가 클라이언트를 보냅니다.지원되는 암호 목록을 클라이언트의 기본 설정 순서대로 포함하고 있으며, 필요한 경우 공유하기 위해 비밀 키를 보낼 수 있도록 사용되는 키 알고리즘을 추측하는 서버에 대한 Hello 메시지입니다.

어떤 키 알고리즘을 사용하고 있는지 추측함으로써 라운드 트립을 배제합니다.고객 접수 후Hello 서버는 키, 증명서, 선택된 암호 스위트 및 완료된 메시지를 사용하여 serverHello를 전송합니다.

클라이언트가 서버의 완료 메시지를 수신한 후 사용할 [8]암호 스위트의 서버와 연계됩니다.

지원되는 알고리즘

TLS 1.0~1.2의 경우

TLS 1.0~1.2 암호 스위트로 지원되는 알고리즘
키 교환/계약 인증 블록/스트림 암호 메시지 인증
RSA RSA RC4 해시 기반 MD5
디피-헬만 DSA 트리플 DES SHA 해시 함수
ECDH ECDSA AES
SRP 아이디어
PSK DES
동백
차차20

TLS 1.0~1.2 로 서포트되고 있는 알고리즘의 상세한 것에 대하여는, 다음의 항도 참조해 주세요.트랜스포트층 보안 »어플리케이션 및 도입

TLS 1.3

TLS 1.3에서는 이전 버전의 TLS에서 지원되던 많은 레거시 알고리즘이 프로토콜을 [9]보다 안전하게 하기 위해 삭제되었습니다.또한 모든 암호화 및 인증 알고리즘은 인증된 암호화와 관련 데이터(AED) 암호화 알고리즘으로 결합됩니다.HMAC 기반 키 파생(HKDF)[10]에서도 해시 알고리즘을 사용해야 합니다.AEAD 이외의 암호는 모두 취약점 또는 취약성으로 인해 삭제되었으며 암호는 모든 [11]교환에 대해 새로운 키쌍이 생성되도록 ephemeral key 교환 알고리즘을 사용해야 합니다.

암호 스위트를 사용하는 DTLS

Datagram Transport Layer Security(DTLS; 데이터그램 트랜스포트층 보안)는 TLS를 기반으로 하지만 TCP 연결 대신 UDP 연결에 특히 사용됩니다.DTLS는 TLS를 기반으로 하기 때문에 TLS에 대해 기술된 대부분의 암호 스위트를 사용할 수 있습니다.DTLS에서 TLS 암호 스위트를 사용할 때는 특별한 경우를 고려해야 합니다.DTLS는 스트림 암호 RC4를 지원하지 않습니다.즉, RC4를 사용하는 TLS 암호는 DTLS에서 [12]사용할 수 없습니다.

TLS 암호 스위트가 DTLS와 호환되는지 여부를 확인하는 것은 도움이 되지 않습니다.각 TLS 암호 스위트는 이름에 TLS 식별자 공간을 계속 포함합니다.다음은 예를 제시하겠습니다.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.대신 모든 TLS 파라미터 레지스트리에 DTLS-OK 플래그가 포함되어 암호 스위트가 DTLS를 [13]지원하는지 여부를 나타냅니다.

취약성

암호 스위트는 포함된 알고리즘만큼 안전합니다.암호 스위트의 암호화 또는 인증 알고리즘 버전이 기존의 취약성을 가지고 있는 경우 암호 스위트와 TLS 연결이 취약할 수 있습니다.따라서 TLS 및 암호 스위트에 대한 일반적인 공격은 다운그레이드 공격이라고 불립니다.TLS 다운그레이드는 최신 클라이언트가 이전 버전의 TLS 또는 SSL을 사용하는 레거시 서버에 연결할 때 발생합니다.

핸드쉐이크를 시작할 때 최신 클라이언트는 지원되는 최고의 프로토콜을 제공합니다.연결이 실패하면 서버에서 핸드쉐이크가 성공할 때까지 TLS 1.0이나 SSL 3.0과 같은 하위 프로토콜을 사용하여 자동으로 다시 시도합니다.다운그레이드의 목적은 새로운 버전의 TLS가 이전 버전과 호환되도록 하는 것입니다.단, 공격자가 이 기능을 이용하여 클라이언트가 취약한 보안 및 [14]취약성으로 알려진 알고리즘을 사용하여 암호 스위트를 지원하는 TLS 또는 SSL 버전으로 자동으로 다운그레이드되도록 할 수 있습니다.이로 인해 POODLE 등의 공격이 발생하고 있습니다.

이 보안 결함을 방지하는 한 가지 방법은 서버 또는 클라이언트가 SSL 3.0으로 다운그레이드할 수 있는 기능을 비활성화하는 것입니다.이 수정의 단점은 일부 레거시 하드웨어는 새로운 하드웨어에서 액세스할 수 없다는 것입니다.레거시 하드웨어에 SSL 3.0 지원이 필요한 경우 악의적인 의도로 [15]다운그레이드가 트리거되지 않았는지 확인하는 승인된 TLS_FALLBACK_SCSV 암호 스위트가 있습니다.

제약이 있는 디바이스용 암호 스위트

암호화, 키 교환 및 인증 알고리즘에는 보통 대량의 처리 능력과 메모리가 필요합니다.처리 능력, 메모리, 배터리 지속 시간이 한정되어 있는 디바이스(사물의 인터넷에 전력을 공급하는 디바이스 등)에 보안을 제공하기 위해 특별히 선택된 암호 스위트가 있습니다.다음 두 가지 예가 있습니다.

  1. TLS_PSK_WITH_AES_128_CCM_8(사전 공유 키)[16]
  2. TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8(원시 공개키)

이러한 암호 스위트는 각각 처리 능력과 메모리에 제약이 있는 디바이스에서 실행되도록 구현되어 있습니다.둘 다 오픈 소스 프로젝트 TinyDTLS에서 구현됩니다.이러한 제약이 있는 디바이스에서 작업할 수 있는 이유는 경량화 방법으로 구현할 수 있기 때문입니다.사전 공유 키 암호 스위트 구현에서는 1889바이트의 RAM과 38266의 플래시 ROM만을 사용했습니다.이는 대부분의 암호화 [17]및 보안 알고리즘에 비해 리소스에 매우 민감합니다.이러한 메모리 사용량이 적은 것은 이러한 암호 스위트가 안전성이 입증된 효율적인 알고리즘을 사용했기 때문입니다.그러나 리소스가 필요한 알고리즘만큼 안전하지 않을 수 있습니다.exp: 128비트 암호화와 256비트 암호화를 사용합니다.또한 사전 공유 키 또는 원시 공개 키를 사용하기 때문에 기존 공개 키 인프라스트럭처(PKIX)[18]에 비해 메모리 용량과 처리 능력이 적게 필요합니다.

프로그래밍 참조

프로그래밍에서 암호 스위트는 복수의 형식과 비복수 형식의 양쪽 모두를 참조한다.각각 다른 정의를 가지고 있습니다.

CipherSuite cipher_suites
클라이언트가 [19]지원하는 암호화 옵션 목록입니다.핸드쉐이크 프로세스에서 보통 cipher_suites가 사용되는 예를 다음에 나타냅니다.
   구조 {        Protocol Version(프로토콜 버전) client_version;        랜덤 랜덤;        세션 ID 세션 ID;        CipherSuite cipher_module(암호)< >2..2^16-2>;        압축 방식 compression_compression_displicate< >1..2^8-1>;        선택한다. (내선번호_존재합니다.) {            사례. 거짓의:                구조 {};            사례. 진실의:                내선 확장 기능< >0..2^16-1>;        };    } 클라이언트 헬로;
CipherSuite cipher_suite
서버에 의해 클라이언트의 cipher_set에서 선택된 암호 스위트.[20]핸드쉐이크 프로세스에서 보통 cipher_suite가 사용되는 예를 다음에 나타냅니다.
      구조 {           Protocol Version(프로토콜 버전) server_version;           랜덤 랜덤;           세션 ID 세션 ID;           CipherSuite cipher_module(암호);           압축 방식 compression_compression_displicate;           선택한다. (내선번호_존재합니다.) {               사례. 거짓의:                   구조 {};               사례. 진실의:                   내선 확장 기능< >0..2^16-1>;           };       } 서버 헬로;

「 」를 참조해 주세요.

레퍼런스

  1. ^ "Cipher Suites in TLS/SSL (Schannel SSP) (Windows)". docs.microsoft.com. Retrieved 2018-07-02.
  2. ^ RFC 5246
  3. ^ TLS 암호 스위트 레지스트리
  4. ^ "The SSL 0.2 Protocol". www-archive.mozilla.org. Retrieved 2017-12-07.
  5. ^ "draft-hickman-netscape-ssl-00". tools.ietf.org. Retrieved 2017-12-07.
  6. ^ "SSL 3.0 Specification". www.freesoft.org. Retrieved 2017-12-07.
  7. ^ Villanueva, John Carl. "An Introduction To Cipher Suites". Retrieved 2017-10-25.
  8. ^ Valsorda, Filippo (23 September 2016). "An overview of TLS 1.3 and Q&A". The Cloudflare Blog. Retrieved 1 September 2020.
  9. ^ "TLS 1.3 Protocol Support wolfSSL Embedded SSL/TLS Library". wolfSSL. Retrieved 2017-10-26.
  10. ^ E. Rescorla (November 4, 2016). "The Transport Layer Security (TLS) Protocol Version 1.3". Retrieved 2016-11-11.
  11. ^ Sullivan, Nick (11 August 2018). "A Detailed Look at RFC 8446 (a.k.a. TLS 1.3)". The Cloudflare Blog. Retrieved 11 August 2020.
  12. ^ N., Modadugu; E., Rescorla. "Datagram Transport Layer Security". tools.ietf.org. Retrieved 2017-10-25.
  13. ^ Eric, Rescorla; Nagendra, Modadugu. "Datagram Transport Layer Security Version 1.2". tools.ietf.org. Retrieved 2017-10-25.
  14. ^ Bodo, Moeller; Adam, Langley. "TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks". tools.ietf.org. Retrieved 2017-10-25.
  15. ^ Bodo, Moeller; Adam, Langley. "TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks". tools.ietf.org. Retrieved 2017-10-25.
  16. ^ Daniel, Bailey; David, McGrew. "AES-CCM Cipher Suites for Transport Layer Security (TLS)". tools.ietf.org. Retrieved 2017-10-26.
  17. ^ Perelmen, Vladislav (June 29, 2012). "Security in IPv6-enabled Wireless Sensor Networks: An Implementation of TLS/DTLS for the Contiki Operating System" (PDF): 38. Archived from the original (PDF) on August 29, 2017. Retrieved December 7, 2017. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  18. ^ Samuel, Weiler; John, Gilmore; Hannes, Tschofenig; Tero, Kivinen; Paul, Wouters. "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)". tools.ietf.org. Retrieved 2017-12-07.
  19. ^ RFC 5246, 페이지 41
  20. ^ RFC 5246, 페이지 42~43, 64