TLS Lite — WIA-TLS-LITE — 저자 연삼흠 박사
전통적 TLS 1.3(RFC 8446)은 TCP 위에서 동작하도록 설계되었지만, IoT·LPWAN·산업 센서 네트워크는 TCP 연결 유지 비용(SYN/SYN-ACK/ACK 3-way 핸드셰이크, 슬라이딩 윈도우, FIN 종료)을 감당하기 어렵다. RFC 7228이 정의한 Class 0(≤10 KiB RAM, ≤100 KiB Flash) 디바이스는 TCP 스택의 상태 머신만으로도 메모리 예산이 고갈된다. 따라서 IETF는 UDP 위에 보안 채널을 구축하는 DTLS(Datagram TLS)를 표준화했고, RFC 9147은 TLS 1.3의 보안 속성을 UDP 데이터그램 환경에 이식한 DTLS 1.3을 정의했다.1
본 장은 TLS Lite(WIA-TLS-LITE) 표준의 두 번째 계층인 「CoAP 위 DTLS 1.3」을 다룬다. CoAP(Constrained Application Protocol, RFC 7252)는 HTTP의 REST 의미론을 UDP 위에 압축한 IoT 전용 응용 계층 프로토콜이다. CoAP 자체는 NoSec 모드를 허용하지만, RFC 7252 §9는 보안 모드로 DTLS를 의무화한다. 즉 「CoAP 위 DTLS 1.3」은 IoT 보안의 사실상 표준 조합이며, TLS Lite는 이 조합을 Class 1·Class 2 디바이스에서 실행 가능한 옥텟 예산 안에서 구현하도록 정합한다.2
운영자가 본 장에 진입하는 통상적 시나리오는 다음과 같다. 첫째, 게이트웨이가 LTE-M·NB-IoT·Wi-Fi 6 등으로 인터넷에 연결되고, 그 하단에 BLE·LoRa·Thread·Zigbee 네트워크로 센서 노드가 매달려 있는 구조. 둘째, 센서 노드 각각이 ESP32-C3, nRF52840, STM32L4 같은 Class 1 MCU 위에서 펌웨어를 돌리며 mbedTLS·wolfSSL·tinydtls 같은 경량 TLS 라이브러리를 임베드한다. 셋째, 노드는 게이트웨이를 통해 클라우드 측 CoAP 리소스 서버에 PUT/POST/GET을 발행하고, 그 모든 트래픽은 DTLS 1.3으로 봉인된다.
이 시나리오에서 핵심 설계 결정은 (a) 키 교환 모드 선택, (b) connection_id 길이, (c) 0-RTT/early_data 허용 여부, (d) record sequence number 압축 사용 여부, (e) HelloRetryRequest 회피, (f) CoAP 메시지 타입(CON/NON)과 DTLS 레코드의 매핑이다. 본 장은 이 여섯 결정을 차례로 다루며, RFC 9147·9146·7252·8323·8613의 정상 요건과 TLS Lite 표준의 권고 옵션을 표 6종으로 정리한다.
TLS 1.3은 1-RTT 핸드셰이크를 표준화했지만, DTLS 1.3도 동일한 1-RTT 목표를 달성한다. 다만 UDP의 무순서·손실 특성 때문에 추가 메커니즘이 필요하다. 메시지 시퀀스 번호(MSN), 핸드셰이크 메시지 단편화(fragment_offset/fragment_length), 재전송 타이머(RTO with exponential backoff), 그리고 ACK 메시지(RFC 9147 §7)가 추가되었다.3
아래 표 2-1은 TLS 1.3과 DTLS 1.3의 핸드셰이크 라운드 트립을 정리한다. PSK_KE 모드(사전 공유 키만 사용, ECDHE 없음)는 DTLS 1.3에서도 1-RTT이며, PSK_DHE_KE 모드(PSK + ECDHE forward secrecy 결합)도 마찬가지로 1-RTT이지만 ECDHE 연산 비용이 추가된다. 0-RTT/early_data는 정확히 0-RTT가 되지만, anti-replay 윈도우와 트레이드오프가 있다.
| 키 교환 모드 | TLS 1.3 RTT | DTLS 1.3 RTT | forward secrecy | 권장 사용처 |
|---|---|---|---|---|
| PSK_KE | 1-RTT | 1-RTT (+ MSN 복구) | 없음 | 제조 단계 사전 등록 PSK, 폐쇄망 |
| PSK_DHE_KE | 1-RTT | 1-RTT (+ ECDHE 비용) | 있음 | Class 1·2 일반 IoT 권고 기본 |
| DHE_KE (cert) | 1-RTT | 1-RTT (+ X.509 검증) | 있음 | Class 2 게이트웨이, 클라우드 측 |
| 0-RTT/early_data | 0-RTT | 0-RTT | 제한적 | idempotent PUT 한정 — anti-replay 윈도우 필수 |
| RPK (RFC 7250) | 1-RTT | 1-RTT | 있음 | 인증서 체인 부담 회피 시 |
TLS Lite의 권고 기본은 PSK_DHE_KE이다. 사전 공유 키는 디바이스 제조 단계에서 보안 요소(Secure Element, SE) 또는 PUF(Physically Unclonable Function)로 주입되고, 운영 단계의 forward secrecy는 X25519 ECDHE로 확보한다. ECDHE 곡선 선택은 P-256(NIST FIPS 186-5)과 X25519(RFC 7748) 둘 다 허용하되, ARM Cortex-M0+ 같은 저전력 코어에서는 X25519의 상수 시간 구현이 사이드 채널 면역이 좋다.
CoAP는 네 가지 메시지 타입을 정의한다(RFC 7252 §4). Confirmable(CON)은 신뢰 전송을 요구하며 응답에 ACK 또는 RST가 필요하다. Non-confirmable(NON)은 fire-and-forget이며 손실을 허용한다. Acknowledgement(ACK)는 CON에 대한 명시적 응답이다. Reset(RST)은 메시지 거부를 표시한다.4
DTLS 1.3 위에서 CoAP가 동작할 때, CoAP의 신뢰 전송 메커니즘(CON/ACK)과 DTLS의 메시지 시퀀스 메커니즘은 서로 직교한다. CoAP 응용 계층의 손실 복구는 DTLS 레코드의 손실 복구와 독립적으로 작동한다. 그러나 운영 관점에서는 두 계층의 타이머가 충돌하지 않도록 조정해야 한다. RFC 7252 §4.8.2는 CoAP 기본 ACK_TIMEOUT을 2초·ACK_RANDOM_FACTOR 1.5·MAX_RETRANSMIT 4로 권고한다. DTLS 1.3 §7.7은 핸드셰이크 RTO 초기값을 1초로 두고 지수 backoff 한다. TLS Lite는 두 계층 모두 RFC 권고를 따르되, 동일 노드에서 두 타이머가 동시 작동하지 않도록 핸드셰이크 완료 후에만 CoAP 트래픽을 송신하도록 권고한다.
| CoAP 타입 | 신뢰성 | DTLS 레코드 type | 권장 시나리오 | 손실 시 동작 |
|---|---|---|---|---|
| CON | 신뢰 전송 | application_data (23) | 제어 명령, 펌웨어 업데이트 트리거 | CoAP ACK_TIMEOUT 재전송 |
| NON | 비신뢰 | application_data (23) | 주기 텔레메트리, 센서 스트림 | 응용 계층 무시 |
| ACK | 응답 | application_data (23) | CON 수신 확인 (piggyback 또는 separate) | CON 재전송 트리거 |
| RST | 거부 | application_data (23) | 알 수 없는 token, 잘못된 Observe | 송신자 정정 |
IoT 디바이스는 NAT 후방에서 자주 IP·포트가 재할당된다. LTE-M의 sleep mode 복귀, NB-IoT의 PSM(Power Saving Mode) 종료, Wi-Fi의 DHCP 갱신은 모두 외부 IP·포트를 바꾼다. 전통적 DTLS는 (src_ip, src_port, dst_ip, dst_port) 4-튜플로 세션을 식별했기 때문에, 이 튜플이 바뀌면 핸드셰이크를 처음부터 다시 해야 했다. RFC 9146 connection_id(CID)는 이 문제를 해결한다.5
CID는 0~255 옥텟의 가변 길이 식별자로, 핸드셰이크 시점에 양방향으로 협상되며, 모든 후속 application_data 레코드의 헤더에 포함된다. 수신자는 CID 룩업으로 세션을 복구하므로, IP·포트가 바뀌어도 세션이 유지된다. TLS Lite는 Class 1 디바이스에서 CID 길이 4 옥텟(보안 64비트 충돌 저항), Class 2 게이트웨이에서 8 옥텟을 권고한다.
| CID 길이 (옥텟) | 충돌 저항 | 레코드 헤더 오버헤드 | NAT rebinding | 권고 클래스 |
|---|---|---|---|---|
| 0 (CID 비활성) | 해당 없음 | 0 옥텟 | 불가 (4-튜플 의존) | 폐쇄망 Class 0 전용 |
| 2 | 16 비트 (낮음) | +2 옥텟 | 가능 — 충돌 위험 | Class 0 실험용 |
| 4 | 32 비트 | +4 옥텟 | 가능 — 일반 OK | Class 1 권고 |
| 8 | 64 비트 | +8 옥텟 | 가능 — 충돌 안전 | Class 2 게이트웨이 권고 |
| 16 | 128 비트 | +16 옥텟 | 가능 — 과잉 | 대규모 클라우드 측 |
DTLS 1.3의 신규 기능 중 옥텟 예산에 직접 영향을 주는 것이 record sequence number(SN) 압축이다. DTLS 1.2는 64비트 SN을 평문으로 노출했으나, DTLS 1.3 §4.2.2는 SN을 record protection 키로 마스킹하여 8 또는 16 비트로 압축한다. 16비트 SN은 epoch 당 65,536개 레코드를 허용하므로, 디바이스가 매 시간 17 메시지(주기 텔레메트리) 송신할 경우 약 4,096시간(170일) 후에 epoch 회전이 필요하다. 이는 펌웨어 업데이트 주기와 정합된다.6
SN 압축은 두 가지 이득을 준다. 첫째, 레코드 헤더가 13 옥텟에서 5~7 옥텟으로 줄어든다. 둘째, SN 마스킹이 트래픽 분석 공격을 어렵게 만든다. TLS Lite는 Class 1 디바이스에서 8비트 SN(epoch 당 256 메시지, 짧은 epoch 회전 의무), Class 2에서 16비트 SN을 기본으로 권고한다.
DTLS 1.3 §4는 두 가지 레코드 헤더 형식을 정의한다. unified header(1 옥텟 type field)와 ciphertext header(epoch·SN·CID 포함). unified header의 type 옥텟은 비트 단위로 다음을 인코딩한다: bit 7~5 = 001(고정 prefix), bit 4 = CID 포함 여부, bit 3 = SN 길이(0=8비트, 1=16비트), bit 2 = length 필드 포함 여부, bit 1~0 = epoch low 2 비트.
이 1바이트 type 옥텟은 RFC 9147 §4.1의 핵심 옥텟 절감 메커니즘이다. 16바이트 페이로드(CoAP GET 응답 단일 옵션) 송신 시, 전통적 DTLS 1.2는 13(헤더) + 16(페이로드) + 16(AEAD tag) = 45 옥텟이 필요했다. DTLS 1.3 짧은 헤더로는 7(헤더) + 16(페이로드) + 16(AEAD tag) = 39 옥텟으로 13% 절감된다. LoRaWAN의 SF12(spreading factor 12) 한 프레임 최대 페이로드가 51 옥텟이라는 점을 고려하면, 이 13% 절감이 단일 프레임 송신 가능 여부를 가른다.
// DTLS 1.3 unified header — 의사 코드 (RFC 9147 §4.1)
struct DtlsCiphertext {
uint8_t type; // 1 옥텟: 001 C S L E E (bit field)
// C = CID present (1 bit)
// S = SN length (0=8bit, 1=16bit)
// L = length present (1 bit)
// E = epoch low 2 bits
opaque connection_id[CID_LEN]; // 선택 (C=1일 때)
uint8_t sequence_number[1 or 2]; // S에 따라 1 또는 2 옥텟
uint16_t length; // 선택 (L=1일 때)
opaque encrypted_record[length]; // AEAD-protected payload + tag
};
// 헤더 최소 크기: 1 (type) + 1 (SN) = 2 옥텟
// 헤더 최대 크기: 1 + 8 (CID) + 2 (SN) + 2 (length) = 13 옥텟DTLS 1.3는 TLS 1.3와 동일하게 0-RTT 모드를 제공한다. 클라이언트가 이전 세션의 PSK(또는 새 NewSessionTicket)를 사용해 ClientHello에 early_data 확장과 함께 즉시 application_data를 동봉하는 방식이다. 0-RTT는 라운드 트립이 0이라는 절대적 이점이 있지만, anti-replay가 약화되는 트레이드오프를 안고 있다.7
RFC 8446 §8과 RFC 9147 §7.1은 0-RTT 트래픽에 대해 두 가지 anti-replay 메커니즘을 권고한다. (a) 단일 사용 토큰: NewSessionTicket의 ticket_age_add를 활용해 윈도우를 잡고, 이 윈도우를 벗어난 early_data는 거부한다. (b) idempotent 동작 한정: 0-RTT 위에서는 GET·idempotent PUT만 허용하고 POST·non-idempotent PUT은 거부한다. TLS Lite는 IoT 시나리오에서 0-RTT를 GET(원격 측정 폴링)과 idempotent PUT(상태 토글)에만 허용한다.
| 시나리오 | 0-RTT 허용 | replay 위험 | 완화책 | 권고 등급 |
|---|---|---|---|---|
| GET 폴링 (센서 읽기) | 허용 | 낮음 (멱등) | ticket_age_add 윈도우 ±10초 | OK |
| idempotent PUT (스위치 ON/OFF) | 조건부 허용 | 중간 | nonce + 단일 사용 토큰 | 주의 |
| POST (이벤트 기록) | 금지 | 높음 (중복 기록) | 1-RTT 강제 | 금지 |
| 펌웨어 업데이트 트리거 | 금지 | 매우 높음 | 1-RTT + 서명 검증 필수 | 금지 |
| 인증 발급/갱신 | 금지 | 치명적 | 1-RTT + nonce | 금지 |
CoAP 위 DTLS 1.3 운영에서 자주 거론되는 공격 벡터는 다섯 가지다. replay 공격, downgrade 공격, DoS 증폭, KRACK 변종 nonce 재사용, 사이드 채널 누출. 각 벡터에 대해 DTLS 1.3 자체 또는 운영 옵션으로 완화 가능하다.
replay 공격은 ciphertext 패킷을 재송신해 동일 동작을 반복 유도하는 공격이다. DTLS 1.3 §4.5.1의 anti-replay 윈도우(기본 64, 권고 128)가 1차 방어선이며, AEAD nonce(per-record)가 2차 방어선이다. downgrade 공격은 핸드셰이크 중 약한 cipher_suite로 협상을 유도하는 공격으로, RFC 8446 §4.1.3의 random downgrade sentinel(서버가 TLS 1.3 응답 시 ServerHello.random의 마지막 8바이트를 고정 패턴으로 설정)로 탐지한다. DoS 증폭은 spoofed source IP로 ClientHello를 보내 서버가 큰 ServerHello/Certificate를 전송하게 만드는 공격이며, HelloRetryRequest 쿠키(RFC 9147 §5.1)가 1차 완화책이다.
| 공격 벡터 | RFC 참조 | 1차 완화책 | 2차 완화책 | Class 0 가능 여부 |
|---|---|---|---|---|
| replay (record 재송신) | RFC 9147 §4.5.1 | anti-replay 윈도우 (64+) | AEAD per-record nonce | 가능 |
| downgrade (cipher 약화) | RFC 8446 §4.1.3 | random downgrade sentinel | SignatureScheme 화이트리스트 | 가능 |
| DoS 증폭 (spoofed Hello) | RFC 9147 §5.1 | HelloRetryRequest 쿠키 | rate limit per CID/IP | 제한적 |
| KRACK nonce 재사용 | RFC 8446 §5.3 | per-record nonce 유일성 | epoch 회전 의무화 | 가능 |
| 사이드 채널 (timing/power) | NIST SP 800-90B | 상수 시간 ECDHE | X25519 권고 | 제한적 |
HelloRetryRequest(HRR)는 클라이언트가 서버 선호 곡선·키 셰어를 추측하지 못한 경우 서버가 발행하는 메시지로, 핸드셰이크를 1-RTT에서 2-RTT로 늘린다. IoT 시나리오에서 HRR이 빈번히 발생하면 wake/sleep 듀티 사이클이 비효율적이 된다. TLS Lite는 두 가지 회피 전략을 권고한다. 첫째, 클라이언트가 서버 측이 권고하는 모든 곡선(X25519, P-256)에 대해 key_share 확장을 동시에 제시한다. 둘째, 서버가 클라이언트 캐시(NewSessionTicket의 KEM 힌트)를 활용해 선호 곡선을 미리 알린다.8
실측 데이터로는, mbedTLS 3.5 기반 ESP32-C3 클라이언트가 X25519 + P-256 동시 key_share를 제시한 경우 HRR 발생률 0%, X25519만 제시한 경우 서버가 P-256을 요구하면 HRR 100% 발생, 양 사이드 모두 X25519를 1차로 두면 HRR 0%로 측정된다. 이 데이터는 TLS Lite 적합성 슈트 §B.7에 포함되어 있다.
| 옵션 | Class 0 (≤10K RAM) | Class 1 (≤50K RAM) | Class 2 (≤250K RAM) | 근거 |
|---|---|---|---|---|
| 키 교환 | PSK_KE | PSK_DHE_KE (X25519) | PSK_DHE_KE + cert | RAM/Flash 예산 |
| cipher_suite | TLS_AES_128_CCM_8_SHA256 | TLS_AES_128_GCM_SHA256 | TLS_AES_128_GCM_SHA256 또는 TLS_CHACHA20_POLY1305_SHA256 | AEAD 표준 |
| connection_id | 비활성 (폐쇄망) | 4 옥텟 | 8 옥텟 | NAT rebinding |
| SN 압축 | 8 비트 | 16 비트 | 16 비트 | 옥텟 예산 |
| 0-RTT | 비활성 | idempotent 한정 | idempotent 한정 + replay 윈도우 | RFC 8446 §8 |
| OSCORE 결합 | 선택 | 권고 (응용 계층 추가 방어) | 권고 + DTLS 종단 | RFC 8613 |
| 인증 모드 | PSK 전용 | PSK + RPK | PSK + RPK + X.509 | 키 관리 부담 |
| epoch 회전 | 일 단위 | 시간 단위 | 요청 단위 | nonce 충돌 회피 |
본 장의 모든 옵션 조합은 참조 시뮬레이터에서 시연 가능하다. 시뮬레이터 패널 1 (DTLS 핸드셰이크 트레이스)를 열면, 클라이언트가 TLS_AES_128_GCM_SHA256과 X25519 key_share로 ClientHello를 보내는 시점부터 서버 Finished까지의 모든 레코드가 시각화된다. 패널 0 (절차 개요)는 운영자 체크리스트 전체를 단계별로 안내한다. CoAP 요청 흐름은 패널 2 (CoAP CON/ACK 페어링)에서 볼 수 있다.
// CoAP GET over DTLS 1.3 — record sequence
// Client → Server
DTLS_record(type=app_data, epoch=2, SN=0x0001, CID=0xAB12CD34):
encrypted(
CoAP {
ver=01, type=0 (CON), token_len=2, code=0.01 (GET),
message_id=0x1234, token=0x5678,
options: [Uri-Path: "sensor"; Accept: 60 (cbor)],
payload:
}
) || AEAD_tag(16)
// Server → Client (piggyback ACK)
DTLS_record(type=app_data, epoch=2, SN=0x0001, CID=0xEF56AB78):
encrypted(
CoAP {
ver=01, type=2 (ACK), token_len=2, code=2.05 (Content),
message_id=0x1234, token=0x5678,
options: [Content-Format: 60 (cbor)],
payload: CBOR(temperature=22.5, humidity=45)
}
) || AEAD_tag(16) 한국의 IoT 보안 정책은 「정보통신망 이용촉진 및 정보보호 등에 관한 법률」(정보통신망법) 제45조의2(정보보호 조치) 및 「정보통신기반 보호법」 제9조(취약점 분석·평가)를 근거로, KISA(한국인터넷진흥원)가 발행하는 「IoT 보안 인증제」와 정합된다. 본 인증제는 RFC 7252 CoAP·RFC 9147 DTLS 1.3·RFC 9146 connection_id를 채택한 디바이스를 「보안성 시험 통과」 등급으로 분류한다. TTA(한국정보통신기술협회)의 TTAK.OT-12.0148/R1 「IoT 디바이스 보안 시험 방법」은 DTLS 1.3 핸드셰이크 적합성 시험을 의무 항목으로 등재했다.
ETRI(한국전자통신연구원)는 NB-IoT·LTE-M 기반 산업용 IoT 게이트웨이에 대한 DTLS 1.3 참조 구현을 공개했으며, KCMVP(한국 암호모듈 검증제도)는 X25519·P-256·AES-128-GCM·ChaCha20-Poly1305 알고리즘을 검증 대상으로 포함한다. NIPA(한국정보통신산업진흥원)는 스마트시티 통합플랫폼 V2.0의 IoT 인증 모듈로 DTLS 1.3+OSCORE 조합을 권고한다. NIA(한국지능정보사회진흥원)는 공공 IoT 사업 가이드라인에서 connection_id 4 옥텟 이상을 명시했다.
국내 통신사 운영 환경에서는 SK텔레콤·KT·LG유플러스의 LTE-M·NB-IoT 망이 DTLS 1.3 트래픽을 1500 옥텟 MTU 안에서 단편화 없이 운반하도록 보장한다. 삼성전자 SmartThings·LG전자 ThinQ 플랫폼은 가전 IoT 영역에서 DTLS 1.3 PSK_DHE_KE 모드를 채택했다. 한국 표준은 KS X ISO/IEC 29167-19(RFID 보안)와 정합되며, 본 장의 RFC 7228 Class 1·2 권고는 KISA 「IoT 디바이스 등급 분류」와 1:1 매핑된다.
DTLS 1.3는 전송 계층 보안을 제공하지만, 게이트웨이가 트래픽을 종단하는 시나리오에서는 응용 계층의 종단 간 보안이 추가로 필요하다. RFC 8613이 정의하는 OSCORE(Object Security for Constrained RESTful Environments)는 CoAP 메시지의 페이로드와 헤더 일부를 COSE(RFC 8152) 형식의 AEAD로 봉인하여, 중간 게이트웨이가 DTLS를 종단하더라도 응용 계층 평문을 들여다볼 수 없도록 한다. TLS Lite는 Class 1 이상 디바이스에서 DTLS 1.3 + OSCORE 이중 봉인을 권고한다.11
OSCORE는 Sender ID, Recipient ID, Master Secret, Master Salt 4개 매개변수로 두 종단 사이의 보안 컨텍스트를 도출한다. HKDF(RFC 5869)를 거쳐 Sender Key, Recipient Key, Common IV가 파생되며, 모든 CoAP 메시지는 AES-CCM-16-64-128(기본) 또는 ChaCha20-Poly1305로 봉인된다. OSCORE의 nonce는 Partial IV(시퀀스 번호)와 ID Context의 결합으로 형성되므로, 같은 메시지를 두 번 봉인하지 못한다. 이 nonce 정책은 DTLS 1.3의 AEAD nonce와 독립적으로 작동한다.
OSCORE 결합 시 한 가지 운영 함정은 키 회전 주기 정합이다. DTLS 1.3 epoch 회전(시간 단위)과 OSCORE Master Secret 회전(일/주 단위)의 주기가 어긋나면, 디바이스가 두 회전을 동시에 처리하느라 CPU 스파이크가 발생한다. TLS Lite는 두 회전을 별도 디스조인트 시간 슬롯에 배치하도록 권고한다. 예를 들어 DTLS epoch 회전은 매시 정각, OSCORE 회전은 매일 03:00 UTC로 분리한다.
RFC 7641 CoAP Observe는 서버 리소스 상태가 변경될 때마다 클라이언트에 알림을 푸시하는 메커니즘이다. Observe 등록은 GET 요청에 Observe 옵션(번호 6)을 0으로 설정하여 발행하며, 서버는 상태 변경마다 NON 또는 CON으로 응답을 보낸다. Observe 관계는 보통 수 분에서 수 시간 지속되므로, DTLS 1.3 세션 수명을 같은 시간 척도로 유지해야 한다.13
이 시나리오에서 connection_id가 결정적 역할을 한다. NB-IoT의 PSM(Power Saving Mode)은 디바이스를 최장 413일까지 슬립할 수 있고, 슬립 후 깨어났을 때 외부 IP가 바뀐 상태에서도 Observe 관계를 그대로 유지해야 한다. CID 4 옥텟 이상이 협상되어 있으면 IP 변경이 세션을 끊지 않는다. CID가 없으면 NewSessionTicket을 활용한 빠른 재개(RFC 8446 §4.6)로 1-RTT 재핸드셰이크를 수행한다.
IoT 디바이스의 펌웨어 업데이트는 보안 핵심 동작이다. RFC 9019(SUIT, Software Updates for Internet of Things)가 정의하는 manifest 형식과 결합하면, DTLS 1.3 채널 위로 봉인된 펌웨어 manifest를 받고 디바이스의 부트로더가 ed25519 서명을 검증한 뒤에만 업데이트를 적용한다. TLS Lite 권고는 펌웨어 업데이트 시 0-RTT를 절대 금지하고(표 2-4), 매번 새로운 1-RTT 핸드셰이크를 강제한다. 추가로 서명 검증 실패 시 디바이스는 백오프 후 안전 모드로 복귀해야 한다.
업데이트 트래픽은 일반 텔레메트리보다 페이로드가 크다(보통 200KB~2MB). LoRaWAN처럼 프레임 페이로드가 51 옥텟으로 제한된 LPWAN에서는 펌웨어 업데이트를 LTE-M·NB-IoT·Wi-Fi 백업 경로로 우회하는 듀얼 라디오 게이트웨이 설계가 필요하다. ETRI 참조 구현은 이 듀얼 라디오 패턴을 채택했으며, TLS Lite 적합성 슈트 §B.8이 펌웨어 업데이트 시나리오를 시험한다.
본 장의 모든 권고를 정합하려면 운영자는 다음 8단계를 차례로 수행한다. 첫째, 디바이스 클래스를 RFC 7228 기준으로 식별한다(Class 0/1/2). 둘째, 표 2-6에서 디바이스 클래스에 해당하는 옵션 매트릭스를 추출한다. 셋째, mbedTLS·wolfSSL·tinydtls 중 디바이스 RAM 예산에 맞는 라이브러리를 선택한다. 넷째, PSK를 보안 요소(SE)에 주입한다. 다섯째, connection_id 길이를 협상한다. 여섯째, 표 2-4에 따라 0-RTT 허용 동작 범위를 코드 수준에서 화이트리스트로 강제한다. 일곱째, anti-replay 윈도우를 활성화한다(권고 128). 여덟째, 적합성 슈트 §B.2~B.8을 통과한다.
이 체크리스트는 단순한 가이드라인이 아니라 KISA IoT 보안 인증제 시험 항목과 1:1 매핑되도록 설계되었다. 인증 시험관은 위 8단계 각각에 대해 증거(로그, 펌웨어 바이너리 분석, 적합성 슈트 출력)를 제출받아 PASS/FAIL을 판정한다. 시험 통과 후에는 「IoT 보안성 시험 통과」 등급의 인증서가 발행되며, 정부 조달 사업의 입찰 평가에서 가점을 받고 공공 IoT 사업의 자격 요건을 충족한다.
본 장 「CoAP 위 DTLS 1.3」 계층은 TLS Lite Phase 1(envelope)과 Phase 3(federation handshake) 사이를 잇는 핵심 결선 계층이다. 운영자가 본 장의 권고 매트릭스를 채택하면, 같은 디바이스가 WIA-OMNI-API의 자격증명 저장, WIA-AIR-SHIELD의 신뢰 목록, WIA-INTENT의 워크로드 의도 선언을 추가 핸드셰이크 없이 재사용할 수 있다. 한 운영자가 하나의 서명키 체인과 하나의 감사 전송으로 N개의 표준을 가로지를 수 있도록 설계된 까닭은, IoT 환경의 디바이스 메모리·전력 예산이 표준마다 별도 구현을 감당할 수 없기 때문이다.
본 장의 적합성 시험은 https://github.com/WIA-Official/wia-tls-lite-conformance의 §B.2~B.8 항목으로 구체화되어 있으며, 운영자의 디바이스 펌웨어가 표 2-1~2-6의 모든 권고 옵션을 충족하는지 자동 검증한다. 시험을 통과한 펌웨어는 WIA Standards Conformance Mark(WIA-CM)를 부착할 수 있다. 다음 제 3 장은 「CWT(CBOR Web Token) 기반 자격증명」을 다루며, 본 장에서 협상된 DTLS 1.3 세션 위로 어떻게 짧은 자격증명 토큰을 발행·검증하는지 설명한다.