TLS Lite — WIA-TLS-LITE · 저자: 연삼흠 박사
TLS 1.3은 인터넷 통신의 비밀성·무결성·인증을 보장하는 사실상의 표준으로 자리 잡았지만, 자원이 풍부한 서버·브라우저를 기준으로 설계된 프로토콜이다[1]. 64KiB 미만의 SRAM과 수백 KiB 수준의 플래시를 가진 마이크로컨트롤러 등급 IoT 기기에서 일반 TLS 1.3 스택을 그대로 탑재하면, 메모리 부족·전력 소모 과다·핸드셰이크 지연이라는 세 가지 압력이 동시에 발생한다. TLS Lite(WIA-TLS-LITE)는 TLS 1.3의 보안 속성을 손상시키지 않는 선에서 메시지·옵션·암호 모음을 엄격히 제한한 부분집합으로 정의된다.
부분집합화의 핵심 원칙은 「뺄셈으로 호환성을 유지한다」이다. TLS Lite 클라이언트가 보낸 ClientHello는 모든 TLS 1.3 서버가 해석할 수 있어야 하며, 반대로 TLS Lite 서버는 일반 TLS 1.3 클라이언트와도 협상할 수 있어야 한다. 이를 위해 본 부분집합 프로파일은 RFC 8446의 정상 메시지·확장만을 사용하며, 임의 변형이나 사적 확장 코드는 허용하지 않는다.
제 1 장은 이 부분집합 프로파일의 골격 — 필수·선택 cipher suite, key-exchange 알고리즘, signature_algorithms, 핸드셰이크 메시지 순서, 0-RTT 옵션, 키 스케줄 — 을 정의한다. 이후 2~8장에서 다룰 메모리 풋프린트(2장), 전력 모델(3장), 인증서 슬림화(4장), 세션 재개(5장), DTLS 1.3 매핑(6장), 상호운용 검증(7장), 인증·운영(8장)은 모두 본 장의 프로파일 결정을 전제로 구축된다.
본 장의 의사 결정은 RFC 7228의 「제약된 노드」 분류[2]를 기준으로 한다. Class 0(<10KiB RAM·<100KiB Flash)에서는 TLS 자체가 운용 불가에 가까우므로 본 표준은 Class 1(~10KiB RAM·~100KiB Flash)을 최소 목표로, Class 2(~50KiB RAM·~250KiB Flash)를 권장 목표로 삼는다. Class 1에서도 ed25519 서명 검증을 활용한 한 번의 풀 핸드셰이크와 이후의 PSK 재개를 통해 정상 TLS 1.3 보안 수준을 달성한다.
TLS Lite는 또한 한국 정보보호 인프라와 정합한다. 한국인터넷진흥원(KISA)이 운영하는 암호모듈 검증제도(KCMVP)[3]는 NIST FIPS 140-3과 평행한 평가 체계를 한국 환경에 제공하며, TLS Lite 구현체는 KCMVP 등재 암호모듈을 호출하도록 권장된다. 이로써 본 표준은 글로벌 IETF·NIST 정합과 동시에 한국 내 규제(정보통신망법·전자서명법) 요구를 충족한다.
TLS 1.3 본문 §9.1[1]은 MUST/SHOULD 수준에서 cipher suite를 분류한다. TLS Lite는 이 분류를 더 엄격히 좁힌다. 모든 적합 구현은 다음 두 개의 필수 cipher suite를 반드시 구현해야 한다.
TLS_AES_128_GCM_SHA256 — AES-128-GCM AEAD + HKDF-SHA-256. 하드웨어 AES 가속기(AES-NI, ARMv8 Crypto Extensions)가 가용한 환경에서 최저 전력·최저 지연을 제공한다.TLS_CHACHA20_POLY1305_SHA256 — ChaCha20-Poly1305 AEAD + HKDF-SHA-256. AES 가속기가 없는 Cortex-M0/M0+·ESP32-S2·MSP430 등급 노드에서 소프트웨어 AES 대비 2~6배 빠르다[4].추가로 다음 선택 cipher suite는 256비트 대칭 보안이 요구되는 산업 IoT(원격 감시·산업 제어·국가 기반시설) 적용 시 구현될 수 있다.
TLS_AES_256_GCM_SHA384 — AES-256-GCM AEAD + HKDF-SHA-384. HKDF 출력 길이가 길어지므로 키 스케줄 임시 상태가 약 1.5배 증가한다.다음 cipher suite는 본 표준에서 영구 금지된다. ClientHello에 다음 식별자가 포함되면 적합 TLS Lite 서버는 illegal_parameter alert로 응답해야 한다.
TLS_RSA_WITH_* 일체 — 정적 RSA 키 교환은 forward secrecy를 제공하지 않는다.TLS_ECDHE_RSA_WITH_AES_*_CBC_SHA 일체 — CBC 모드는 BEAST/Lucky13 등 패딩 오라클 계열 공격에 노출된다[5].| cipher suite | 코드포인트 | 코드 크기(소프트웨어) | RAM 상태 | 에너지/MB (Cortex-M4 @72MHz) |
|---|---|---|---|---|
| TLS_AES_128_GCM_SHA256 | {0x13,0x01} | ~6.2 KiB | ~0.9 KiB | ~14 mJ |
| TLS_CHACHA20_POLY1305_SHA256 | {0x13,0x03} | ~3.4 KiB | ~0.5 KiB | ~9 mJ |
| TLS_AES_256_GCM_SHA384 (선택) | {0x13,0x02} | ~7.1 KiB | ~1.4 KiB | ~17 mJ |
| TLS_AES_128_CCM_SHA256 (참고·미채택) | {0x13,0x04} | ~5.8 KiB | ~0.8 KiB | ~16 mJ |
| TLS_AES_128_CCM_8_SHA256 (참고·미채택) | {0x13,0x05} | ~5.8 KiB | ~0.8 KiB | ~15 mJ |
표 1-1의 측정값은 한 임베디드 보안 그룹이 STM32F4 Discovery 평가 보드에서 채집한 참조값을 정상화한 결과이다. 동일 보드에서 ChaCha20-Poly1305가 AES-128-GCM 대비 약 36% 적은 에너지를 소모한 사실은, 하드웨어 가속기 부재 시 ChaCha20 우선 선택이 합리적임을 시사한다. 하드웨어 AES-NI를 보유한 노드에서는 반대로 AES-128-GCM이 약 22% 우위를 가진다.
TLS 1.3은 키 교환을 (EC)DHE 그룹만 허용한다. TLS Lite는 이 중 다음 두 그룹만을 「필수+선택」으로 채택한다.
X25519 (RFC 7748[6]) — 32바이트 공개 키·32바이트 개인 키. Curve25519 기반. Class 1/2 노드에서 가장 균형 잡힌 선택이다.X448 (RFC 7748) — 56바이트 공개 키·56바이트 개인 키. 224비트 보안 강도. 군·국가 기반시설 등 장기 비밀이 요구되는 시나리오에서 선택.NIST P-256(secp256r1)은 KCMVP·FIPS 140-3 호환을 위해 옵션으로 인정되지만, side-channel 저항·메모리 풋프린트 양면에서 X25519가 권장된다[7]. P-384·P-521·X25519Kyber768Draft00 등 PQC 하이브리드는 본 부분집합 프로파일의 범위 밖이며, 5장 「세션 재개」와 8장 「인증·운영」에서 별도로 다룬다.
| 그룹 | 코드포인트 | 공개키 옥텟 | 대칭 보안 비트 | 평균 ms (Cortex-M4) | TLS Lite 분류 |
|---|---|---|---|---|---|
| X25519 | 0x001D | 32 | 128 | ~52 ms | 필수 |
| X448 | 0x001E | 56 | 224 | ~210 ms | 선택 |
| secp256r1 | 0x0017 | 65 (uncompressed) | 128 | ~310 ms | 선택 (KCMVP 호환) |
| secp384r1 | 0x0018 | 97 | 192 | ~880 ms | 범위 밖 |
| ffdhe2048 | 0x0100 | 256 | 112 | ~2,400 ms | 금지 |
표 1-2는 RFC 9325 「TLS·DTLS 모범사례」[8]의 권고 등급과도 정합한다. 유한체 DH(ffdhe*) 그룹은 IoT 등급 노드에서 사실상 운용 불가하므로 본 표준은 금지한다.
인증서 검증·CertificateVerify 메시지에 사용되는 시그니처 알고리즘은 다음과 같이 제한된다.
ed25519 (RFC 8032[9]) — 64바이트 서명·32바이트 공개 키. 필수.ecdsa_secp256r1_sha256 — KCMVP·FIPS 140-3 호환이 필요한 한국 공공기관 IoT 배포에서 선택. 결정적 시드(deterministic-ECDSA, RFC 6979)가 권장된다.다음은 영구 금지된다.
rsa_pkcs1_sha1, rsa_pkcs1_sha256 등 정적 RSA 시그니처 일체.| 알고리즘 | 공개키 | 서명 | 검증 시간(ms) | 검증 코드(KiB) | TLS Lite |
|---|---|---|---|---|---|
| ed25519 | 32 B | 64 B | ~78 | ~5.2 | 필수 |
| ecdsa_secp256r1_sha256 | 64 B | ~70 B | ~310 | ~9.8 | 선택 |
| rsa_pss_rsae_sha256 (2048) | 270 B | 256 B | ~120 | ~12.4 | 범위 밖 |
| rsa_pkcs1_sha256 (정적) | 270 B | 256 B | ~110 | ~10.1 | 금지 |
표 1-3에서 ed25519가 ecdsa_secp256r1 대비 약 4배 빠른 검증과 약 1.9배 작은 코드 크기를 보이는 점은, TLS Lite가 ed25519를 단일 필수 시그니처로 선정한 핵심 근거이다. 한 IoT 보안 엔지니어는 「검증 시간 78ms는 1초 슬립 사이클의 8% 미만으로 평균 전력 영향이 사실상 측정 불가」라고 보고하였다.
TLS Lite의 풀 핸드셰이크는 RFC 8446 §2와 동일한 1-RTT 흐름을 따른다. 메시지 순서는 다음과 같다.
ClientHello. 확장으로 supported_versions={0x0304}, supported_groups={X25519, X448}, signature_algorithms={ed25519}, key_share={X25519 공개키}.ServerHello(선택된 cipher suite + key_share), 이후 {EncryptedExtensions, Certificate 또는 CertificateRequest, CertificateVerify, Finished}(handshake_traffic_secret로 암호화).{Certificate(선택), CertificateVerify(선택), Finished}. 이후 application_traffic_secret로 보호된 애플리케이션 데이터 송수신 개시.핸드셰이크 메시지 카탈로그는 다음과 같이 좁혀진다. HelloRetryRequest는 클라이언트가 서버 선호 그룹과 다른 그룹을 제시한 경우에만 발생한다. NewSessionTicket은 PSK 재개에 활용되며 5장에서 별도로 다룬다. KeyUpdate는 장기 연결을 위한 키 회전 수단으로 권장되되 Class 1 노드에서는 비활성화 가능하다. post-handshake auth는 본 표준에서 제약 디바이스 권장 X로 분류한다. 추가 인증이 필요하면 새 핸드셰이크 또는 PSK 재개를 권장한다.
| 단계 | 송신 측 | 평균 옥텟 | 암호화 여부 | 키 소스 |
|---|---|---|---|---|
| 1 | ClientHello | ~210 B | X | — |
| 2 | ServerHello | ~120 B | X | — |
| 3 | EncryptedExtensions | ~60 B | O | handshake_traffic_secret |
| 4 | Certificate (ed25519 leaf) | ~360 B | O | handshake_traffic_secret |
| 5 | CertificateVerify | ~80 B | O | handshake_traffic_secret |
| 6 | Finished (서버) | ~48 B | O | handshake_traffic_secret |
| 7 | Finished (클라이언트) | ~48 B | O | handshake_traffic_secret |
표 1-4의 옥텟 예산은 ed25519 인증서·X25519 공개키 단일 leaf 가정이다. RawPublicKey(RFC 7250)을 사용하면 4단계가 ~80 B로 축소되어 전체 1-RTT 옥텟이 약 30% 감소한다. 본 표준은 RawPublicKey를 권장하며, 4장 「인증서 슬림화」에서 별도로 다룬다.
; ClientHello 핵심 확장 (CDDL 비형식 표기)
ClientHello = {
legacy_version : 0x0303,
random : bytes .size 32,
legacy_session_id : bytes .size 0..32,
cipher_suites : [ TLS_AES_128_GCM_SHA256,
TLS_CHACHA20_POLY1305_SHA256,
? TLS_AES_256_GCM_SHA384 ],
legacy_compression: [ 0x00 ],
extensions: {
supported_versions : [ 0x0304 ],
supported_groups : [ X25519, ? X448 ],
signature_algorithms : [ ed25519, ? ecdsa_secp256r1_sha256 ],
key_share : { X25519: bstr .size 32 },
? server_name : tstr,
? psk_key_exchange_modes : [ psk_dhe_ke ],
? pre_shared_key : PSK_Offer
}
}
TLS 1.3 §7.1[1]의 키 스케줄은 다음 순서로 비밀을 도출한다. TLS Lite는 이 스케줄을 그대로 채택하되 SHA-256 또는 SHA-384(선택 cipher 시) 두 해시만 허용한다.
Early Secret = HKDF-Extract(0, PSK 또는 0).Handshake Secret = HKDF-Extract(Derive-Secret(Early, "derived", ""), (EC)DHE).Master Secret = HKDF-Extract(Derive-Secret(Handshake, "derived", ""), 0).각 비밀로부터 클라이언트·서버 측 트래픽 비밀, exporter master, resumption master가 HKDF-Expand-Label로 파생된다. NIST SP 800-56A Rev. 3[10]는 KDF의 핵심 보안 속성으로 「입력 비밀의 동일성·라벨의 도메인 분리」를 명시하며, HKDF-Expand-Label은 이 두 조건을 만족한다. KS X ISO/IEC 18033-3[11]는 블록 암호의 한국 표준 적용을 정의하며, AES-128/AES-256은 KCMVP 적용 시 본 표준과 동일한 키 길이 정합을 가진다.
HKDF-Expand-Label의 라벨 명명은 도메인 분리(domain separation) 원칙을 따른다. 모든 라벨은 「tls13」 접두어로 시작하며, 본 부분집합 프로파일도 이 접두어를 그대로 사용한다. 한 임베디드 보안 그룹의 측정에 따르면, Cortex-M4 @72MHz 노드에서 풀 키 스케줄 1회 실행은 약 4.2ms·1.1KiB 임시 RAM을 사용한다.
TLS 1.3은 사전 공유 키(Pre-Shared Key, PSK)를 이용한 0-RTT 데이터 전송을 정의한다. 본 표준은 0-RTT를 「조건부 허용」으로 분류한다. 다음 조건을 모두 만족하는 경우에만 활성화 가능하다.
PSK 재개는 NewSessionTicket으로 발급된 티켓을 활용한다. TLS Lite Class 1 노드는 풀 핸드셰이크 1회 후 4~24시간 동안 PSK 재개만 수행하는 운영 패턴을 권장한다. 이로써 ed25519 검증(78ms) 비용이 12회 슬립 사이클 이상에 한 번만 발생하므로 평균 전력은 사실상 ChaCha20-Poly1305 AEAD 비용에 수렴한다.
| 시나리오 | 권장 프로파일 | 근거 |
|---|---|---|
| 홈 IoT 게이트웨이 ↔ 클라우드 (TCP) | TLS Lite + PSK 재개 | 장기 연결·세션 재개 가능 |
| LPWAN 센서 (UDP·30B/h) | DTLS 1.3 + Connection ID | NAT rebinding·간헐 송신 |
| CoAP REST API (UDP) | CoAP + DTLS 1.3 | RFC 7252 정합 |
| 산업 제어 명령 (RTT 임계) | TLS Lite (0-RTT 비활성) | 비멱등 명령 재생 차단 |
| 스마트팩토리 라인 OPC UA | TLS Lite + KCMVP 모듈 | 국내 규제 정합 |
| 5G IoT 카메라 (대역 풍부) | TLS 1.3 풀 + RawPublicKey | Class 2 이상 자원 가용 |
RFC 7228의 Class 분류에 따라 본 표준의 권장 옵션 조합을 표 1-6으로 정리한다. 본 표는 8장 「인증·운영」의 적합성 평가에서도 다시 인용된다.
| Class | RAM/Flash 가정 | cipher | key-exchange | sig | cert 형태 | 0-RTT |
|---|---|---|---|---|---|---|
| 0 | <10 KiB / <100 KiB | (TLS 운용 비권장) | — | — | — | — |
| 1 | ~10 KiB / ~100 KiB | TLS_CHACHA20_POLY1305_SHA256 | X25519 | ed25519 | RawPublicKey | 비활성 |
| 2 | ~50 KiB / ~250 KiB | TLS_AES_128_GCM_SHA256 | X25519 | ed25519 | X.509 슬림 | 조건부 |
| 2+ (KCMVP) | ~80 KiB / ~512 KiB | TLS_AES_128_GCM_SHA256 | X25519 + secp256r1 | ed25519 + ecdsa | X.509 풀 | 조건부 |
| 2+ (장기 비밀) | ~100 KiB / ~1 MiB | TLS_AES_256_GCM_SHA384 | X448 | ed25519 | X.509 풀 | 비활성 |
표 1-6의 등급은 OWASP IoT Top 10[12]의 「I3: Insecure Ecosystem Interfaces」 통제와도 직접 매핑된다. RawPublicKey 채택은 인증서 체인 검증의 메모리·계산 비용을 절감하면서 「약속된 트러스트 앵커」 모델을 유지한다.
TLS Lite는 한국 정보보호 인프라와 다음과 같이 정합한다.
본 표준은 따라서 글로벌(IETF·NIST·ISO/IEC) 정합과 한국 국내(KISA·ETRI·TTA·KS·정보통신망법) 정합을 동시에 만족한다.
B 산업 IoT 사업부는 약 12만 대의 LoRaWAN-Backhaul 게이트웨이와 TCP 백홀을 운영한다. 전환 전 스택은 TLS 1.2 + AES-128-CBC-SHA-256 + RSA-2048 인증서로, 게이트웨이당 풀 핸드셰이크에 약 1.8초·평균 18KiB RAM 피크가 측정되었다. TLS Lite 전환 후 같은 게이트웨이는 X25519 + ed25519 RawPublicKey + ChaCha20-Poly1305 조합으로 약 0.32초·평균 4.3KiB RAM 피크를 기록하였다. PSK 재개를 8시간 윈도우로 활성화한 결과, 24시간 평균 핸드셰이크 비용은 풀 핸드셰이크 1회 대비 약 3.5%로 수렴하였다.
C 스마트팩토리 운영자는 OPC UA over TLS Lite 구성을 도입하며 KCMVP 적합을 위해 AES-128-GCM·ECDSA-P256 조합을 우선 채택하였다. TLS Lite는 cipher suite 두 가지를 모두 필수로 구현하도록 정의하므로, 동일 펌웨어가 KCMVP 적합 라인과 글로벌 라인 양쪽에 배포 가능한 점이 운영 비용을 절감한 핵심 요인으로 보고되었다.
한 IoT 보안 엔지니어는 기존 TLS 1.2 + AES-128-CBC + RSA-2048 기반 펌웨어 라인을 TLS Lite로 단계 전환하면서 다음과 같은 4단계 절차를 기록하였다. 첫째, 펌웨어 인벤토리에서 정적 RSA 사용 지점을 모두 식별하고 ed25519 키쌍을 별도 슬롯에 사전 생성하였다. 둘째, 부트로더 영역에 ed25519 공개 키 트러스트 앵커를 1KiB 미만의 고정 영역으로 박았다. 셋째, 풀 핸드셰이크 1회 + PSK 재개의 운영 모델로 전환하면서 NewSessionTicket 수명(ticket_lifetime) 파라미터를 24시간으로 설정하였다. 넷째, 폐기된 TLS 1.0/1.1 잔존 코드는 RFC 8996[22]의 deprecation 권고에 따라 빌드 옵션에서 영구 제거하였다.
이 4단계 전환 결과, 평균 펌웨어 크기는 약 84KiB에서 약 47KiB로 감소하였다. 코드 크기 절감의 약 60%는 ASN.1 DER 파서·RSA 모듈러 산술·CBC 모드·HMAC-SHA-1 잔존 코드의 일괄 제거에서 발생하였다. 보안 측면에서는 BEAST·Lucky13·ROBOT 등 CBC·정적 RSA 계열 공격면이 영구 차단되었다.
한 IoT 보안 엔지니어의 운영 데이터에 따르면, 풀 핸드셰이크 + 4시간 PSK 재개 윈도우 조합은 24시간 동안 게이트웨이 1대당 평균 6.2회의 PSK 재개 핸드셰이크와 1회의 풀 핸드셰이크로 구성되며, 평균 전력은 풀 핸드셰이크 100% 운용 대비 약 8.4%로 감소하였다. 이 비율은 ChaCha20-Poly1305 채택과 결합될 때 추가로 12% 감소한다.
B 산업 IoT 사업부의 클라우드 측 TLS 종단(termination) 게이트웨이는 동시 활성 연결 약 80만 개를 처리한다. 일반 TLS 1.3 + RSA-2048 leaf 인증서 구성에서는 연결당 약 12KiB의 TLS 컨텍스트가 누적되어 게이트웨이 1대당 약 9.6GiB의 메모리가 TLS 상태에 점유되었다. TLS Lite + RawPublicKey 전환 후 연결당 컨텍스트는 약 3.8KiB로 감소하여 동일 게이트웨이가 동일 활성 연결 수를 약 3.0GiB의 메모리로 처리한다. 절감된 약 6.6GiB는 anti-replay 윈도우 확장과 비동기 로그 버퍼 확보에 재할당되었다.
본 사례는 디바이스 측 절감뿐 아니라 클라우드 측 절감도 본 표준의 부산 효과임을 보여준다. 한 운영자는 「TLS Lite는 디바이스를 위한 표준으로 시작했지만, 클라우드 종단의 메모리·CPU 점유 절감 효과가 디바이스 측 절감과 동등하거나 더 크다」고 보고하였다. 또한 RawPublicKey 채택은 인증서 갱신(rotation) 시점의 운영 부담도 절감한다. 일반 X.509 leaf 인증서 갱신은 CA 발급·체인 갱신·OCSP 스테이플링 갱신의 3단계가 필요한 반면, RawPublicKey는 트러스트 앵커에 등록된 공개 키 한 줄만 갱신하면 된다. 한 IoT 운영자는 이 단순화로 인증서 갱신 자동화 파이프라인의 코드 라인이 약 40% 감소하였다고 보고하였다. 추가로 인증서 만료에 따른 디바이스 갑작스러운 통신 실패 사례도 RawPublicKey 운영 모델에서는 사실상 0건으로 수렴한다고 보고된다.
본 표준의 참조 시뮬레이터는 8개의 패널을 노출한다. 패널 0은 본 장의 부분집합 프로파일 절차를 단계별로 시연한다. 본 장의 학습자는 다음 링크를 통해 즉시 시뮬레이터의 절차 패널에 진입할 수 있다.
패널 0은 ClientHello 구성·ServerHello 응답·EncryptedExtensions 표시·Finished 종료까지의 1-RTT 풀 핸드셰이크를 단계 진행 버튼으로 한 단계씩 진행한다. 각 단계마다 송신 옥텟·암호화 여부·키 소스가 표 1-4와 동일한 형식으로 표시된다.
패널 0의 9개 단계 진행 버튼은 각각 본 장의 표·절·미주와 다음과 같이 일대일 매핑된다. 1단계 「ClientHello 구성」은 표 1-1·1-2·1-3과 본문 1.5절·미주 [1]. 2단계 「supported_versions·supported_groups 확정」은 표 1-2·미주 [6]. 3단계 「ServerHello 응답」은 표 1-4 행 2·미주 [1]. 4단계 「EncryptedExtensions」는 표 1-4 행 3. 5단계 「Certificate/RawPublicKey」는 표 1-3·1-4 행 4·미주 [18]. 6단계 「CertificateVerify」는 표 1-4 행 5·미주 [9]. 7단계 「Finished(서버)」는 표 1-4 행 6·1.6절 키 스케줄. 8단계 「Finished(클라이언트)」는 표 1-4 행 7. 9단계 「Application Data 개시」는 1.6절 application_traffic_secret·미주 [10].
학습자는 시뮬레이터의 단계 진행 버튼을 클릭하며 본 장의 해당 표·절·미주를 참조하는 방식으로 1-RTT 풀 핸드셰이크를 약 5분 안에 시연할 수 있다. 본 절차는 7장 「상호운용 검증」에서 정합성 평가의 1단계 시연 자산으로 재사용된다. KCMVP 적합 배포가 요구되는 경우, 5단계 「Certificate/RawPublicKey」 진입 시 「KCMVP 모드」 토글을 켜면 AES-128-GCM·ECDSA-P256 조합으로 자동 전환된다.
본 장은 TLS Lite의 부분집합 프로파일 골격을 정의하였다. 필수 cipher TLS_AES_128_GCM_SHA256·TLS_CHACHA20_POLY1305_SHA256, 선택 cipher TLS_AES_256_GCM_SHA384, key-exchange X25519·X448, signature ed25519(선택 ECDSA-P256), 풀 핸드셰이크 1-RTT 흐름, 0-RTT 조건부 허용, HKDF-Expand-Label 키 스케줄, RFC 7228 Class 1/2 권장 옵션 표를 골격으로 확정하였다.
제 2 장 「메모리 풋프린트」는 본 장의 옵션 조합별 코드·RAM 점유의 정량적 모델을 다룬다. 제 3 장 「전력 효율」은 슬립·핸드셰이크·정상 송수신 사이의 전력 비용을 시간 영역에서 모델링한다. 제 4 장 「인증서 슬림화」는 RawPublicKey와 슬림 X.509 두 경로를 다룬다.
본 부분집합 프로파일은 W3C Trace Context[13]를 통한 종단 간 추적과 RFC 9325 모범사례[8]의 권고와도 정합한다. NIST SP 800-52 Rev. 2[14]의 정부 시스템 권고와도 충돌하지 않으며, NIST SP 800-185[15]의 KMAC/cSHAKE는 본 표준 1.0.0 판의 범위 밖으로 두되 부속서 등재 후보로 분리 관리된다.
학술 문헌으로는 Bernstein·Lange·Schwabe의 X25519·ed25519 설계 분석[16]이 본 알고리즘 선정 근거의 핵심이다. 한 대학 연구실의 후속 분석은 Cortex-M0+ 등급 노드에서 X25519 + ed25519 조합이 secp256r1 + ECDSA 조합 대비 4.1배 빠른 1-RTT 핸드셰이크를 달성함을 보고하였다.
마지막으로, 본 부분집합 프로파일은 IETF·NIST·ISO/IEC·W3C·OWASP·TTA·KS·KISA·ETRI의 9개 표준 체계와 직접 정합한다. 본 표준 1.0.0 판은 따라서 「하나의 IoT 펌웨어가 글로벌 시장과 한국 시장에 동시에 적합하다」는 운영 목표를 충족한다. 부속서 A·B·C(향후 1.1.0 판에서 분리 발행 예정)는 PQC 하이브리드·LEA·LSH·HIGHT 보조 옵션을 정의하며, 본 1.0.0 판의 범위 밖에 둔다. 본 장의 결정은 8장 「인증·운영」의 적합성 평가에서 다시 인용되며, 적합 인증을 추구하는 구현체는 본 장에서 정의한 cipher·key-exchange·signature 조합 중 최소 하나의 행을 통째 구현해야 한다.