데이터그램 전송 계층 보안 DTLS 개념 이해

데이터그램 전송 계층 보안 DTLS(Datagram Transmission Layer Security)

DTLS(Datagram Transmission Layer Security)는 도청, 변조 또는 메시지 위조를 방지하기 위해 고안된 방식으로 통신함으로써 데이터 그램 기반 애플리케이션에 대한 보안을 제공하는 통신 프로토콜입니다. DTLS 프로토콜은 경향 지향 전송 계층 보안(TLS) 프로토콜에 기초하며 유사한 보안 보장을 제공하기 위한 것입니다.

DTLS 프로토콜 데이터 그램은 기본 전송의 의미들을 저장합니다. 애플리케이션은 경향 프로토콜과 관련된 지연을 겪지 않지만 UDP를 사용하므로 애플리케이션은 패킷 재배열, 데이터 그램 손실 및 데이터 그램 네트워크 패킷 크기보다 더 큰 데이터를 처리해야 합니다. DTLS는 TCP가 아닌 UDP를 사용하기 때문에 VPN 터널을 만드는 데 사용될 때 'TCP 용해 문제'를 피합니다.

DTLS(데이터그램 전송 계층 보안)

  DTLS

TLS는 네트워크 트래픽을 보장하기 위해 가장 널리 배치된 프로토콜입니다. IMAP 및 POP와 같은 웹 트래픽 보호 및 전자 메일 프로토콜에 널리 사용됩니다. TLS의 주요 장점은 투명한 연결 지향 채널을 제공하는 것입니다. 따라서 응용 계층과 전송 계층 사이에 TLS를 삽입함으로써 응용 프로토콜을 쉽게 확보할 수 있습니다. 그러나 TLS는 신뢰할 수 있는 전송 채널, 즉 일반적으로 TCP를 통해 실행되어야 합니다.

따라서 신뢰할 수 없는 데이터 그램 트래픽을 보장하는 데 사용할 수 없습니다.

 

그러나 UDP 전송을 이용한 응용 계층 프로토콜은 지난 몇 년 동안 설계되었습니다. 세션 개시 프로토콜(SIP) 및 전자 게임 프로토콜과 같은 프로토콜은 특히 점점 더 인기를 끌고 있습니다. 이러한 애플리케이션의 설계자들은 다양한 불만족스러운 선택에 직면해 있습니다.

첫째, IPsec를 사용할 수 있습니다. 그러나 몇 가지 이유로 여러 응용 프로그램에만 적합합니다. 둘째, 사용자 지정 응용 프로그램 계층에 대한 보안 프로토콜을 설계할 수 있습니다. 예를 들어, SIP는 트래픽을 보장하기 위해 S/MIME의 하위 집합을 사용합니다. 그러나 애플리케이션 계층 보안 프로토콜은 일반적으로 우수한 보안 속성(ex. MIME의 S/end-to-end 보안)을 제공하기 위해 사용되지만, 일반적으로 TLS를 통해 프로토콜을 실행하는 데 필요한 비교적 작은 노력과는 달리 설계에 많은 노력이 필요합니다. 

 

종종 클라이언트 / 서버 응용 프로그램을 확보하는 가장 바람직한 방법은 TLS를 사용하는 것입니다. 그러나 데이터 그램 의미론에 대한 요구 사항은 TLS의 사용을 자동으로 금지합니다. 따라서 보안 프로토콜을 기술하고 코드와 인프라의 재사용을 극대화하기 위해 TLS와 유사하게 설계된 DTLS(Datagram Transport Layer)가 제안되었습니다.

 

DTLS 1.0은 TLS 1.1을 기반으로 하며 DTLS 1.2는 TLS 1.2를 기반으로 합니다. DTLS 1.1은 없습니다. 버전 번호를 건너뛰어 TLS와 버전 번호를 조화시킵니다.

 

 

 

  DTLS 특징 

 

- 손실에 민감한 메시징

TLS(TLS 레코드 계층이라고 함)의 트래픽 암호화 계층에서 손실 마취 메시지는 레코드와 독립적이지 않으며, 두 유형의 레코드 사이에는 의존성이 있습니다.

1. 암호화 컨텍스트(CBC state, stram cryptographic keystream)는 상기 레코드들 사이에 체인화됩니다.

2. 반 재생 및 메시지 재주문 보호는 시퀀스 번호를 포함하는 MAC에 의해 제공되지만 시퀀스 번호는 레코드에 동봉됩니다. 

이 두 가지 문제에 대한 해결책은 IPsec ESPEasy이며 ESP에서 잘 알려져 있습니다. TLS 1.1은 이미 TLS 레코드에 명시적인 CBC 상태를 추가하였습니다. DTLS는 명시적 시퀀스 번호를 추가하기 위해 메커니즘을 빌립니다. 

 

- 핸드 셰이크에 대한 신뢰성 제공

TLS 핸드 셰이크는 잠금 단계 암호 셰이크 입니다. 메시지는 정의된 순서로 보내고 받아야 하며 다른 주문은 오류입니다. 분명히 이것은 메시지의 재주문 또는 손실과 호환될 수 없습니다. 또한 TLS 핸드 셰이크 메시지는 주어진 데이터 그램보다 잠재적으로 커 단편화 문제를 유발합니다. DTLS는 이 두 가지 문제에 대한 해결책을 제공합니다.

 

- 패킷 손실

DTLS는 패킷 손실을 처리하기 위해 간단한 재전송 타이머를 사용합니다. 

DTLS 패킷 손실 처리

클라이언트가 Client Hello 메시지를 보내는 경우 Hello Verify Request가 나타날 것으로 예상합니다. 그러나 서버의 메시지가 손실되면 클라이언트는 Client Hello 또는 Client Verify Request가 분실되고 분개했다는 것을 알고 있습니다. 서버가 재전송을 수신하면 재전송할 것임을 알고 서버는 재전송 타이머를 유지하고 타이머가 만료되면 재전송합니다.

 

- 재주문

DTLS에서 각 핸드 셰이크 메시지는 핸드 셰이크 내에서 특정 시퀀스 번호를 할당받습니다. 피어가 핸드 셰이크 메시지를 수신하면 메시지가 다음 메시지인지 아닌지를 신속하게 결정할 수 있습니다. 그렇다면 해당 메시지가 처리됩니다. 그렇지 않은 경우 이전 메시지가 모두 수신되면 이후 처리를 위해 대기열에 배치합니다.

 

- 메시지 크기

TLS와 DTLS에 대한 핸드 셰이크 메시지는 상당히 클 수 있습니다.(이론적으로 최대 2^24-1바이트, 실제로는 많은 킬로바이트) 이와는 대조적으로, 단편화가 바람직하지 않으면 UDP 데이터그램은 종종 1500바이트로 제한됩니다. 이러한 한계를 보완하기 위해 DTLS 핸드셰이크 메시지는 여러 개의 DTLS 레코드에 대해 단편화될 수 있으며, 각 DTLS 핸드셰이크 메시지는 짧은 오프셋과 짧은 길이를 모두 포함하고 있습니다. 따라서, 핸드셰이크 메시지의 모든 바이트를 소유한 수신자는 원래의 조각되지 않은 메시지를 재조립할 수 있습니다.

 

- 재생 검출

DTLS는 레코드 재생 탐지를 선택적으로 지원합니다. 사용된 기술은 수신된 레코드의 비트맵 윈도를 유지함으로써 IPsec AH / ESP와 같습니다. 너무 오래되어 창에 맞지 않는 레코드와 이전 레코드는 조용히 폐기됩니다. 패킷 복제는 반드시 악의적인 것은 아니지만, 라우팅 오류로 인해 재생 탐지가 선택 사항입니다. 응용 프로그램은 중복된 패킷을 탐지하고 데이터 전송 전략을 변경할 수 있습니다.