제 5 장: 제약 디바이스 암호

5.1 제약 디바이스 환경의 암호 설계 원칙

제약 디바이스(constrained device)는 RAM·플래시·전력·CPU 사이클·전송 대역폭 가운데 둘 이상이 일반 서버 대비 두 자릿수 이상 작은 컴퓨팅 단위를 가리킨다. IETF RFC 7228은 이를 정량적으로 분류했다. 본 장에서 사용하는 분류 기준은 RFC 7228 §3에 따른 Class 0(10 KiB RAM 미만·100 KiB 플래시 미만), Class 1(10~50 KiB RAM·100~250 KiB 플래시), Class 2(50 KiB RAM 초과·250 KiB 플래시 초과)이며, 이 기준이 본 장의 모든 표·예산·비교에 일관되게 적용된다. Class 0은 보통 16비트 MCU(MSP430·AVR ATmega) 혹은 ARM Cortex-M0가 사용되며, Class 1은 Cortex-M0+/M3, Class 2는 Cortex-M4/M7급으로 분포한다.

제약 디바이스 암호는 다음의 다섯 가지 제약을 동시에 만족시켜야 한다. 첫째, 코드 크기가 작아야 한다. AES 라운드 함수와 GHCM 곱셈을 모두 펼치는 구현은 빠르지만 6~10 KiB 플래시를 잡아먹어 Class 0에서는 불가능하다. 둘째, RAM 워킹셋이 작아야 한다. 두 개 이상의 동시 핸드셰이크 상태를 유지하면 X25519 한 번의 점 곱셈만으로도 2.5 KiB 스택이 필요해 Class 0의 절반을 소비한다. 셋째, 비결정 잠재 시간이 작아야 한다. AES-128-GCM 한 블록 16바이트 처리는 Cortex-M4에서 약 320 사이클인데, 같은 길이를 ChaCha20-Poly1305로 처리하면 약 220 사이클이며, 두 함수의 표준 편차는 30 사이클 이하이다. 넷째, 전력 소비가 작아야 한다. LoRaWAN 노드는 1 mAh 배터리 예산으로 6개월을 견뎌야 한다. 다섯째, 사이드채널 견고성이 있어야 한다. ARM Cortex-M0는 분기 예측이 없으나 가속기 모듈은 캐시 누설을 동반할 수 있다.

TLS Lite는 이 다섯 제약을 본문 안에서 명시적으로 잇는다. 봉투 클래스 안의 cipher_suite 필드는 단지 RFC 8446의 코드 포인트만이 아니라, 그 코드 포인트가 RFC 7228의 어느 Class에서 정상 동작 예산 안에 들어오는지의 매트릭스로 추적된다. Phase 1 봉투를 사용하는 운영자는 cipher_suite를 선택하는 순간 RAM·플래시·평균 사이클·전력·사이드채널 견고성 다섯 축의 예산 한 줄을 동시에 선택하는 셈이다.

한 임베디드 펌웨어 엔지니어가 가정용 보일러의 무선 온도 센서를 책임지고 있다고 가정하자. 센서는 CR2032 코인 셀로 5년을 동작해야 하며, 매 30분 주기로 4바이트 온도 값을 게이트웨이에 송신한다. 이 엔지니어가 단 한 번 cipher_suite를 잘못 선택하면 — 예컨대 P-384를 채택하면 — 점 곱셈에 ECDH 1회당 약 14만 사이클이 추가되어 1년 안에 코인 셀이 고갈된다. cipher_suite 선택은 보안 결정인 동시에 물리적 배터리 수명 결정이다.

5.2 타원곡선 암호 (ECC) — 곡선별 옥텟·검증 사이클

제약 디바이스에서 사용 가능한 타원곡선은 NIST P-256/P-384(IETF RFC 6090, NIST SP 800-186), Curve25519/Curve448 패밀리(IETF RFC 7748, RFC 8032)이다. RFC 8446 TLS 1.3은 supported_groups 확장으로 secp256r1, secp384r1, secp521r1, x25519, x448 다섯 가지를 정상 등록했고, 이 중 secp256r1과 x25519가 제약 디바이스의 사실상 표준이다. Ed25519/Ed448은 RFC 8032에 따라 서명 알고리즘으로 채택되며 TLS 1.3 인증서 서명 영역에서 정상 코드 포인트(0x0807, 0x0808)로 사용된다.

곡선 선택의 첫 축은 옥텟 길이이다. P-256은 공개키 64바이트, 서명 64바이트, 비밀키 32바이트이며, X25519는 공개키 32바이트, 비밀키 32바이트, 공유 비밀 32바이트이다. Class 0 디바이스의 평균 무선 페이로드가 51~127바이트(LoRaWAN SF12 DR0~DR2)임을 감안하면, X25519의 32바이트 공개키는 페이로드 한 프레임 안에 정상 인입되지만 P-384의 96바이트 공개키는 두 프레임을 강제한다.

곡선 선택의 둘째 축은 검증 사이클이다. Cortex-M0(Class 0)에서 X25519 점 곱셈은 약 280만 사이클, P-256은 약 950만 사이클이 든다. Cortex-M4(Class 2)에서 같은 연산이 각각 약 78만 사이클, 약 250만 사이클로 떨어진다. 16 MHz Cortex-M0는 X25519 한 회를 약 175 ms에 처리하지만 P-256은 약 590 ms를 요구한다. Class 0에서 핸드셰이크 한 회가 500 ms를 넘으면 워치독 타이머가 작동할 수 있는 시스템이 많다.

곡선 선택의 셋째 축은 사이드채널 견고성이다. X25519는 Montgomery 사다리 곱셈을 채택해 비밀 비트에 무관한 일정 시간 실행이 RFC 7748의 §5에 정상 기술되어 있다. P-256은 Jacobian 좌표로 구현해도 분기 시간 누설이 발생할 수 있어 사이드채널 강건성을 얻으려면 추가 마스킹이 요구된다. 제약 디바이스에서 X25519를 우선 채택하는 가장 강력한 이유 가운데 하나이다.

실측 사이클 수는 mbedTLS 3.5, WolfSSL 5.6, MIRACL Core 4.0의 GitHub 회귀 벤치마크의 중앙값을 인용했다. 동일 곡선이라도 컴파일러(GCC 12 vs Clang 16), 최적화 레벨(-O2 vs -Os), 헤더 정렬 여부에 따라 ±15% 변동이 관측된다.

TLS Lite cipher_suite 봉투는 곡선 식별자를 RFC 8446 supported_groups 확장의 정상 코드 포인트로 명시한다. 그러나 봉투 안에는 그 곡선이 Class 0에서 정상 예산 안에 들어오는지의 boolean 플래그도 함께 실린다. 운영자가 cipher_suite=TLS_CHACHA20_POLY1305_SHA256·group=X25519를 선택할 때, 봉투는 fits_class_0=true 메타데이터를 부착해 펌웨어 빌더가 Class 0 빌드에 한해 이 조합만 컴파일하도록 한다.

5.3 AEAD — AES-GCM 대 ChaCha20-Poly1305

TLS 1.3은 RFC 8446 §B.4에 따라 인증 암호화(AEAD) 다섯 종류를 정상 코드 포인트로 등록한다: TLS_AES_128_GCM_SHA256(0x1301), TLS_AES_256_GCM_SHA384(0x1302), TLS_CHACHA20_POLY1305_SHA256(0x1303), TLS_AES_128_CCM_SHA256(0x1304), TLS_AES_128_CCM_8_SHA256(0x1305). 이 가운데 TLS_AES_128_GCM_SHA256과 TLS_CHACHA20_POLY1305_SHA256이 사실상 IoT의 두 표준이며, TLS_AES_128_CCM_8_SHA256이 LoRaWAN·Zigbee·Thread 같은 무선 메시 망에서 별도 채택된다.

AES-128-GCM의 강점은 ARM Cortex-M3/M4 이상에서 HW 가속(ARM CryptoCell, ST32 Crypto)이 사이클당 약 1.2바이트 처리량을 제공해 1.6 KiB 페이로드를 1.3 ms 안에 처리할 수 있다는 점이다. 약점은 SW 전용 구현 시 GHASH 곱셈에 256바이트 사전계산 테이블이 필요해 RAM 250바이트를 상시 점유한다는 점, 그리고 96비트 nonce가 한 키당 2^32회를 넘기면 안전성이 무너진다는 nonce 재사용 위험이다.

ChaCha20-Poly1305(RFC 8439)의 강점은 SW 전용 구현이 ARX(add-rotate-xor) 연산만으로 구성되어 사이드채널이 자연적으로 강건하고, Cortex-M0에서 사이클당 0.45바이트, Cortex-M4에서 사이클당 1.6바이트의 처리량을 제공한다는 점이다. AES-NI 없는 환경에서 ChaCha20-Poly1305는 AES-GCM 대비 2~3배 빠르다는 결과가 RFC 7905 부록 A에 정상 보고되어 있다. 약점은 96비트 nonce 동일하며, 그 외에는 거의 없다.

AES-128-CCM_8(태그 8바이트)은 무선 메시 망에서 페이로드 8바이트를 절약하는 목적으로 채택된다. 그 대가는 8바이트 인증 태그가 64비트 위조 저항만 제공한다는 점이다. NIST SP 800-38C는 응용 시나리오가 단일 메시지당 평균 메시지 길이가 짧고 위조 확률이 2^-32 이하로 허용 가능할 때만 8바이트 태그를 권장한다. 의료기기·산업제어·항공·자동차 회복-가능-안전 영역에서는 16바이트 태그를 권고한다.

표 5-2에서 ChaCha20-Poly1305의 RAM·플래시·에너지·처리량 네 축 모두에서 SW 전용 환경의 사실상 최적임이 확인된다. 따라서 TLS Lite는 cipher_suite의 SW 전용 기본값으로 TLS_CHACHA20_POLY1305_SHA256을 채택하고, HW 가속이 정상 존재하는 운영자가 TLS_AES_128_GCM_SHA256으로 명시적으로 격상하는 정책을 권고한다.

AES-128-CBC + HMAC-SHA256은 RFC 5246(TLS 1.2)에서 정상이었으나 RFC 8446에서 폐기되었다. 이유는 두 가지이다. 첫째, MAC-then-encrypt 패턴이 Lucky 13(2013)·Bleichenbacher(1998 변형) 같은 padding oracle 부류 공격에 취약했다. 둘째, 두 번의 키 스케줄(암호+MAC)이 메모리·플래시 양쪽에서 AEAD 단일 키 스케줄보다 클 수밖에 없었다. TLS Lite는 RFC 8446을 따라 CBC+HMAC을 의도적으로 제외한다.

5.4 KDF — HKDF-SHA256·HKDF-SHA384

TLS 1.3은 RFC 8446 §7.1에 따라 HKDF(IETF RFC 5869)를 핸드셰이크 키·트래픽 키 도출의 정상 KDF로 채택했다. HKDF는 Extract 단계(HMAC(salt, IKM)→PRK)와 Expand 단계(HMAC(PRK, info||T_{n-1}||0x01)→T_n)의 두 단계로 구성된다. TLS 1.3은 Expand 단계의 info에 RFC 8446 §7.1의 HkdfLabel 구조체(길이·label·context)를 사용한다.

// HKDF-Expand-Label (RFC 8446 §7.1)
struct {
    uint16 length = Length;
    opaque label<7..255> = "tls13 " + Label;
    opaque context<0..255> = Context;
} HkdfLabel;

HKDF-Expand-Label(Secret, Label, Context, Length) =
    HKDF-Expand(Secret, HkdfLabel, Length)

HKDF-SHA256은 한 회 Extract+Expand가 약 760 사이클(M4) 수준이며, HKDF-SHA384는 SHA-384의 80라운드 구조 때문에 약 1,180 사이클을 소요한다. TLS 1.3 핸드셰이크 한 회는 약 12회의 HKDF-Expand-Label 호출을 동반하므로 HKDF-SHA256으로 약 9,000 사이클, HKDF-SHA384로 약 14,000 사이클이 핸드셰이크당 KDF에 소비된다. Class 0(16 MHz)에서 KDF만으로 0.6 ms, Class 2(80 MHz)에서 0.18 ms이다.

BLAKE2s는 RFC 7693 정상이며 ARX 구조이므로 사이드채널 강건성도 자연적이다. 그러나 TLS 1.3의 KDF로 정상 등록된 것은 SHA-2 패밀리(SHA-256·SHA-384)뿐이며, BLAKE2s는 TLS-Lite의 비-TLS 인접 KDF(예: 디바이스 부트로더 키 도출, 펌웨어 서명 영수증) 영역에서 보조적으로 활용한다.

HKDF-Expand-Label은 길이 출력을 위해 HKDF-Expand를 반복 호출하지만 대부분의 TLS 1.3 호출에서 출력 길이가 한 블록(32바이트 또는 48바이트) 안에 정상 들어오므로, 한 회의 HMAC만 수행된다. 운영자가 TLS Lite cipher_suite 봉투에서 KDF=HKDF-SHA256을 채택하면, 본 봉투는 Extract·Expand 매개변수와 HkdfLabel 길이를 모두 결정하는 효과를 갖는다.

5.5 RFC 7228 Class 0/1/2 — 디바이스 예산 매트릭스

RFC 7228의 Class 분류는 단순한 메모리 분류가 아니라 운영자 결정의 단위이다. 같은 cipher_suite를 채택한 디바이스라도 Class 분류에 따라 핸드셰이크 횟수, 세션 재개 정책, 인증서 캐싱, ALPN 협상 가능성, OCSP stapling 채택 여부가 모두 달라진다. TLS Lite는 Phase 1 봉투에 device_class 필드를 두어 봉투 자체가 디바이스 예산을 선언하도록 한다.

Class 0에서 인증서로 X.509를 채택하면 ASN.1 DER 인코더만으로도 4~5 KiB 플래시가 필요하며, X.509 체인 검증 한 회에 RAM 1.8 KiB가 동시 점유된다. RFC 7250 Raw Public Keys는 이 문제를 정상 해결한다. RPK 모드는 SubjectPublicKeyInfo 구조체만 전송하며 X25519 RPK 전체 크기는 약 44바이트이다.

한 임베디드 펌웨어 엔지니어가 Class 0 디바이스에서 X.509 인증서로 시작했다가 점진적으로 RPK로 전환하는 흔한 마이그레이션 경로가 있다. 첫 단계는 supported_groups 확장에 X25519만 광고하는 것이다. 둘째는 cipher_suite를 TLS_CHACHA20_POLY1305_SHA256으로 고정해 GCM 가속이 없는 디바이스에서도 정상 동작하도록 한다. 셋째는 client_certificate_type 확장(RFC 7250)을 정상 활성화해 RPK 받기·보내기 양쪽이 가능하도록 한다. 이 세 단계 마이그레이션으로 플래시 약 18 KiB, RAM 약 1.5 KiB가 회수된다.

5.6 경량 블록 암호 — PRESENT · SIMON · SPECK · ASCON

TLS 1.3 cipher_suite는 AES와 ChaCha20만 정상 코드 포인트로 등록한다. 그러나 TLS-인접 영역(LoRaWAN 페이로드 암호화, Zigbee NWK 키, BLE LL 암호화, 펌웨어 이미지 복호화, OTA 업데이트 봉투)에서는 PRESENT·SIMON·SPECK·ASCON 같은 경량 블록 암호가 활용된다. ISO/IEC 29192-2:2019는 PRESENT를 경량 블록 암호의 국제 표준으로 정상 채택했고, ISO/IEC 18033-3:2010(amendment 2020)은 PRESENT와 HIGHT를 부속서로 정상 등재했다.

NIST 경량 암호 표준화(NIST LWC)는 2018년 시작해 2023년 ASCON(설계자: 그라츠 공대·라트보드 대학·인피니언) 패밀리를 우승자로 정상 발표했다(NIST IR 8454). ASCON-128, ASCON-128a, ASCON-Hash, ASCON-Xof, ASCON-Mac 다섯 변형이 표준에 포함되며, NIST SP 800-232로 정상 발행 예정이다. ASCON-128은 키 128비트·nonce 128비트·태그 128비트의 AEAD로 ChaCha20-Poly1305에 가까운 사이드채널 강건성과 PRESENT보다 작은 코드 크기를 동시에 제공한다.

SIMON·SPECK는 미국 국가안보국(NSA)이 2013년 공개한 패밀리이며, ISO/IEC 표준화 절차에서 2018년 ISO/IEC 29192-2 부속서 후보로 제안되었으나 국가 표준 기관 다수가 설계 근거의 투명성 부족을 이유로 반대해 ISO 표준 채택은 부결되었다. NIST SP 800-185는 SIMON·SPECK를 정상 채택하지 않는다. 그럼에도 SIMON 64/128과 SPECK 64/128은 학술적 분석에서 강건성이 확인되어 폐쇄망(폐쇄형 산업 제어·군사) 시나리오에서는 사용 사례가 존재한다.

TLS Lite 봉투는 TLS 메시지 안에서는 AEAD를 AES-GCM·ChaCha20-Poly1305로 한정하지만, 봉투 클래스 외부의 payload 영역(예: 디바이스 펌웨어 OTA 봉투, LoRaWAN ApplicationData 페이로드)에 한해 ASCON-128을 RFC 8446 외부의 정상 보조 AEAD로 권장한다. 운영자가 이 봉투를 채택하면 봉투 메타에 cipher_inner=ASCON-128 필드가 명시되어 감사 전송에서 식별 가능하다.

5.7 HW 보안 모듈 — TPM 2.0 · SE050 · ATECC608 · ARM CryptoCell

제약 디바이스에서 키를 SW 저장할 때의 위험은 두 가지이다. 첫째, 플래시 덤프 공격으로 비밀키가 평문 노출된다. 둘째, RAM 동결 공격(콜드 부트)으로 휘발성 메모리의 비밀이 추출된다. 두 위험을 정상 차단하려면 HW 보안 모듈(secure element 또는 secure enclave)이 요구된다. 본 절은 제약 디바이스 환경에서 가장 빈번하게 채택되는 네 HW 보안 모듈을 비교한다.

TPM 2.0(Trusted Platform Module 2.0, ISO/IEC 11889:2015)은 데스크톱·랩톱·서버에서 표준이지만, 임베디드 영역에서는 인피니언 SLB 9670, 노바톤 NPCT75x, ST33TPHF2 같은 임베디드 TPM이 Class 2 디바이스에 채택된다. TPM 2.0의 강점은 PCR(Platform Configuration Register), 측정 부트, AIK·SRK 키 계층, NVRAM이 모두 표준화되어 있다는 점이다. 약점은 100 mA 이상의 첨두 전류와 100 ms 이상의 응답 시간으로 코인 셀 디바이스에서는 비현실적이다.

NXP SE050은 IoT 전용 secure element로 I2C 인터페이스, 1.6 mA 활성 전류, JIL High 인증(EAL 6+) 등급을 제공한다. ECC P-256·X25519·Ed25519·AES-128/256 가속이 내장되어 있고, 50개의 키 슬롯과 RFC 7250 RPK 직접 발급을 지원한다. 약점은 단가가 단일 ATECC608의 약 3배이며, 펌웨어 갱신을 위해 NXP 도구체인이 강제된다는 점이다.

Microchip ATECC608A/B는 가장 보편적인 secure element로 단가 약 0.6 USD, I2C 또는 SWI 인터페이스, ECC P-256만 지원(X25519 미지원), 16개의 키 슬롯, 1.7 mA 활성 전류이다. AWS IoT·Azure IoT·Google Cloud IoT의 사실상 표준 secure element이다. 약점은 P-256 외 곡선 미지원으로 X25519 마이그레이션 경로가 막혀 있다는 점이며, ATECC608B에서 X25519를 부분 지원하나 일정 시간 보장은 약하다.

ARM CryptoCell-3xx 시리즈(예: CC312)는 별도 칩이 아니라 SoC 내장 IP 블록으로, Nordic nRF5340, Renesas RA6M5, Silicon Labs EFR32 등에 통합된다. ECC P-256/X25519, AES-128/256, SHA-256/512, TRNG, secure boot, life-cycle state 관리가 모두 한 IP 블록 안에 정상 결합되어 있다. ARM PSA Crypto API(IETF draft·ARM PSA Certified)가 정상 인터페이스이다.

운영자가 cipher_suite를 결정할 때 HW 보안 모듈을 함께 결정해야 한다. ATECC608을 채택한 디바이스는 X25519를 정상 지원하지 못하므로 cipher_suite=TLS_AES_128_GCM_SHA256·group=secp256r1으로 고정된다. SE050이나 ARM CryptoCell을 채택한 디바이스는 X25519를 정상 지원하므로 cipher_suite=TLS_CHACHA20_POLY1305_SHA256·group=x25519의 SW 친화적 조합이 가능하다.

ARM PSA Crypto API는 IETF 초안과 ARM Platform Security Architecture(PSA) Certified 인증을 통해 정상 표준화 경로에 있다. PSA Crypto API는 psa_key_attributes_t 구조체로 키 속성을 추상화하고, psa_import_key·psa_generate_key·psa_sign_hash·psa_verify_hash 같은 단일 호출로 secure element와 SW 백엔드를 투명하게 추상화한다. TLS Lite Phase 2 봉투 API는 이 PSA Crypto API를 정상 백엔드로 권장한다.

// PSA Crypto API — Ed25519 서명 예 (의사 코드)
psa_key_attributes_t attrs = PSA_KEY_ATTRIBUTES_INIT;
psa_set_key_type(&attrs, PSA_KEY_TYPE_ECC_KEY_PAIR(PSA_ECC_FAMILY_TWISTED_EDWARDS));
psa_set_key_bits(&attrs, 255);
psa_set_key_usage_flags(&attrs, PSA_KEY_USAGE_SIGN_HASH | PSA_KEY_USAGE_EXPORT);
psa_set_key_algorithm(&attrs, PSA_ALG_PURE_EDDSA);

psa_key_id_t key_id;
psa_status_t s = psa_generate_key(&attrs, &key_id);
if (s != PSA_SUCCESS) return s;

uint8_t sig[64];
size_t  sig_len;
s = psa_sign_message(key_id, PSA_ALG_PURE_EDDSA,
                     payload, payload_len,
                     sig, sizeof(sig), &sig_len);
return s;

5.8 cipher_suite 선택 — 결정 체크리스트

제약 디바이스의 cipher_suite 선택은 다음 일곱 가지 결정의 합성이다. 각 결정은 RFC 7228 Class 분류에 따라 다른 결과를 낳는다.

1. Class 분류: Class 0/1/2 가운데 어디? RAM·플래시 측정 후 RFC 7228 §3 표 1에 대조.
2. HW 보안 모듈: TPM 2.0 / SE050 / ATECC608 / ARM CryptoCell / 없음? 각 모듈의 지원 곡선과 AEAD를 표 5-6에서 확인.
3. 곡선: X25519 / secp256r1 / secp384r1? HW 모듈 제약에 우선 종속, 그다음 표 5-1의 사이클 예산 적용.
4. AEAD: AES-128-GCM / AES-256-GCM / ChaCha20-Poly1305 / AES-128-CCM_8? HW 가속 유무, 페이로드 길이, 태그 길이 결정.
5. 해시: SHA-256 / SHA-384? cipher_suite의 코드 포인트와 정상 결합되므로 별도 결정이 아니나, KDF 라운드 비용은 표 5-3에서 확인.
6. 인증서 형식: X.509 / RFC 7250 RPK? Class 0이면 RPK 우선.
7. 세션 재개: PSK / 0-RTT? 0-RTT는 재전송 공격에 취약하므로 멱등 GET 외에는 비채택.

이 일곱 결정의 가장 안전한 기본값 조합은 다음과 같다: Class 0 → ARM CryptoCell 또는 SE050 → X25519 → ChaCha20-Poly1305 → SHA-256 → RFC 7250 RPK → PSK 단일. 이 조합이 TLS Lite의 cipher_suite 봉투 기본값이며, supported_groups=x25519, signature_algorithms=ed25519, ALPN=null이 함께 봉투에 정상 포함된다.

한국 경량 암호·HW 보안 인프라 정합

한국은 1999년 SEED(RFC 4269)를 시작으로 경량 블록 암호 영역에서 독자 표준을 다수 유지해 왔다. HIGHT(ISO/IEC 18033-3:2010 부속서 정상 등재, KS X 1213-1)는 KISA가 2005년 발표한 64비트 블록·128비트 키 경량 블록 암호로 RFID·USN 환경을 대상으로 설계되었다. LEA(KS X 3246, ISO/IEC 29192-2 ATD 후보)는 ETRI·KISA·NSR이 2013년 공동 발표한 128비트 블록·128/192/256비트 키 경량 블록 암호로 LoRaWAN·BLE·Zigbee 응용을 정상 대상으로 한다. ARIA(KS X 1213-1)는 학회 표준으로 정상 등재되어 있다.

한국 KISA(한국인터넷진흥원)는 KCMVP(암호모듈검증제도)를 통해 정상 검증된 암호 모듈만이 공공기관·금융기관 정보보호 시스템에서 사용 가능하도록 의무화한다(국가정보원 「국가용 암호모듈 검증규정」). KCMVP 보안 레벨은 1~4단계로 NIST FIPS 140-3의 1~4 보안 레벨과 정상 맵핑되며, 본 TLS Lite 봉투는 KCMVP 1·2단계를 정상 대상으로 한다. KCMVP는 SEED·ARIA·HIGHT·LEA를 정상 알고리즘으로 등재한다.

ETRI(한국전자통신연구원)는 LEA-128을 IoT·자율주행·5G 코어 망에서 사용 가능한 ISO/IEC 29192-2 후속 표준 후보로 정상 제안해 왔으며, KAIST 정보보호대학원·POSTECH 인공지능연구원과 공동으로 LEA의 측면 채널 강건성을 분석한 결과를 KIISC(한국정보보호학회) 동계학술대회에서 정상 보고했다. TTA(한국정보통신기술협회)는 KS X ISO/IEC 29192-1/2/3/4(경량 암호 부) 시리즈를 정상 국가표준으로 채택한다.

삼성 Knox는 ARM TrustZone 기반 TEE(Trusted Execution Environment) 위에 구축된 모바일·IoT 보안 플랫폼으로 PSA Crypto API와 정상 호환되며 한국 KCMVP 1단계 인증을 보유한다. Samsung SDS의 Knox Vault는 SE050에 준하는 EAL 6+ secure element를 모바일 SoC에 내장한다. KT 5G IoT eSIM은 KS X ISO/IEC 7816-3 정합으로 LEA-128·SEED·HIGHT를 가입자 인증 영역에 정상 채택한다. KISIA(한국정보보호산업협회)는 국내 임베디드 보안 솔루션 약 230여 개를 정상 등재한다.

본 TLS Lite 봉투는 cipher_suite의 외부 payload AEAD 권장에 한해 KCMVP 검증된 LEA-128-GCM을 한국 운영자 대상의 보조 옵션으로 권장한다. 봉투에는 cipher_inner=lea-128-gcm·kcmvp_level=1·standard=KS X 3246 메타데이터가 정상 부착되어 감사 전송에서 한국 컴플라이언스 트랙을 별도로 재구성할 수 있다. 한국 운영자의 경우 본 권장이 가산되며, 봉투의 cipher_outer는 여전히 RFC 8446의 TLS 1.3 정상 AEAD(AES-128-GCM 또는 ChaCha20-Poly1305)를 유지한다.

5.9 풋프린트 벤치마크 — TinyCrypt · mbedTLS · WolfSSL

제약 디바이스 TLS 라이브러리의 사실상 세 표준은 TinyCrypt(Intel, Apache 2.0), mbedTLS(Arm Trusted Firmware 프로젝트, Apache 2.0), WolfSSL(WolfSSL Inc., GPLv2/상용)이다. 각 라이브러리의 cipher_suite 한정 빌드 풋프린트는 다음과 같다.

• TinyCrypt 0.2.8: AES-128-CCM·SHA-256·ECDH P-256·ECDSA P-256·HMAC-SHA256 빌드 시 약 16 KiB 플래시·1.4 KiB RAM. TLS 핸드셰이크 자체는 미포함이므로 응용 코드에서 직접 봉투를 조립해야 한다.
• mbedTLS 3.5 (PSA Crypto 백엔드): TLS 1.3·X25519·Ed25519·ChaCha20-Poly1305·HKDF-SHA256 최소 빌드 시 약 55 KiB 플래시·6 KiB RAM. Class 1/2 디바이스의 사실상 기본값.
• WolfSSL 5.6: TLS 1.3·X25519·Ed25519·ChaCha20-Poly1305·HKDF-SHA256·OCSP stapling 최소 빌드 시 약 48 KiB 플래시·5.5 KiB RAM. FIPS 140-3 인증 빌드는 약 +12 KiB 플래시 추가.

본 풋프린트는 GCC 12.2 -Os, -mthumb, -mcpu=cortex-m4 빌드 옵션 기준이며, ARM PSA Crypto API 백엔드를 사용하는 경우의 측정치이다. mbedTLS의 경우 PSA Crypto 백엔드와 레거시 mbedtls/aes.h 백엔드가 공존하며, 후자는 약 +8 KiB 플래시를 동반한다.

TLS Lite의 참조 컨테이너 wia/tls-lite-host:1.0.0은 PSA Crypto 백엔드를 채택한 mbedTLS 3.5를 정상 SW 구현으로 채택한다. 디바이스 측은 동일 PSA Crypto API 호출을 따르되 백엔드는 ARM CryptoCell·SE050·ATECC608 가운데 운영자가 채택한 HW 보안 모듈을 정상 결합한다.

5.10 운영 시나리오 — 한 임베디드 펌웨어 엔지니어의 경로

한 임베디드 펌웨어 엔지니어가 가정용 보일러의 무선 온도 센서 펌웨어를 책임지고 있다. 센서는 nRF52840 SoC(Cortex-M4·256 KiB RAM·1 MiB 플래시·ARM CryptoCell-310 내장)를 채택했고, BLE 5.0 또는 Thread 1.3 무선 스택을 선택할 수 있다. 게이트웨이는 ESP32-S3(Class 2)이며 클라우드 백엔드는 wia/tls-lite-host:1.0.0 참조 컨테이너이다.

엔지니어의 첫 결정은 Class 분류이다. nRF52840은 RFC 7228 Class 2이지만 코인 셀 배터리 6개월 수명 요건은 Class 0에 가깝다. 결정은 「Class 2 SoC를 Class 1 예산으로 운영」으로 내려진다. cipher_suite는 TLS_CHACHA20_POLY1305_SHA256, group은 x25519, signature_algorithms는 ed25519, 인증서 형식은 RFC 7250 RPK, 세션 재개는 PSK 단일이다.

둘째 결정은 PSA Crypto API 백엔드이다. ARM CryptoCell-310 IP가 내장되어 있으므로 psa_crypto_init() 호출 시 CryptoCell이 정상 백엔드로 잡힌다. X25519 점 곱셈, Ed25519 서명, ChaCha20-Poly1305 AEAD가 모두 HW 가속으로 실행되어 핸드셰이크 1회당 전력 소비가 SW 단일 빌드 대비 약 1/4로 감소한다.

셋째 결정은 OTA 업데이트 봉투의 내부 AEAD이다. TLS Lite는 OTA payload 영역의 보조 AEAD로 ASCON-128을 권장한다. 그러나 KCMVP 정합을 요구하는 한국 공공 보일러 운영자라면 LEA-128-GCM이 봉투의 보조 옵션으로 추가된다. 엔지니어는 cipher_inner=lea-128-gcm·kcmvp_level=1·standard=KS X 3246 메타데이터를 봉투에 포함시켜 감사 전송에서 KCMVP 컴플라이언스 트랙을 분리한다.

넷째 결정은 cipher_suite 봉투의 device_class 필드이다. Class 1로 선언하면 TLS 라이브러리 빌더가 OCSP stapling을 옵션으로 컴파일하고, X.509 인증서 검증 코드 패스를 제거하며, RPK 한정 빌드를 생성한다. 펌웨어 이미지 최종 크기는 약 110 KiB(부트로더 12 KiB + TLS 라이브러리 48 KiB + 응용 50 KiB)로 nRF52840 1 MiB 플래시의 약 11%를 점유한다.

다섯째 결정은 LoRaWAN/BLE 시나리오 분기이다. BLE 5.0 GATT 위에서는 TLS 1.3을 그대로 사용할 수 있으나 페이로드 단편화로 LL ATT MTU 247바이트 안에 ClientHello가 정상 들어오지 못한다. 이 경우 ClientHello 압축 확장(IETF draft-ietf-tls-cthello)을 활성화하거나 DTLS 1.3(RFC 9147)을 채택한다. Thread 1.3 위에서는 CoAP-over-DTLS 1.3이 정상이며 RFC 7252+RFC 9147 조합이 사실상 표준이다.

5.11 본 장에서 다루는 정상 참조

• IETF RFC 7748 — Elliptic Curves for Security (X25519/X448)
• IETF RFC 8032 — Edwards-Curve Digital Signature Algorithm (EdDSA)
• IETF RFC 8439 — ChaCha20 and Poly1305 for IETF Protocols
• IETF RFC 5869 — HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
• IETF RFC 7228 — Terminology for Constrained-Node Networks
• IETF RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3
• IETF RFC 9147 — The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
• IETF RFC 7250 — Raw Public Keys in TLS/DTLS
• IETF RFC 7252 — The Constrained Application Protocol (CoAP)
• IETF RFC 7693 — The BLAKE2 Cryptographic Hash and Message Authentication Code
• IETF RFC 4269 — SEED Encryption Algorithm (Korea)
• NIST FIPS 197 — Advanced Encryption Standard (AES)
• NIST FIPS 180-4 — Secure Hash Standard (SHS)
• NIST FIPS 202 — SHA-3 Standard
• NIST SP 800-38C — CCM Mode for Authentication and Confidentiality
• NIST SP 800-38D — Galois/Counter Mode (GCM) and GMAC
• NIST SP 800-185 — SHA-3 Derived Functions
• NIST SP 800-186 — Recommendations for Discrete Logarithm-Based Cryptography
• NIST IR 8454 — Status Report on the Final Round of NIST LWC (ASCON 우승)
• NIST SP 800-232 (draft) — ASCON Family of Cryptographic Algorithms
• ISO/IEC 29192-2:2019 — Lightweight cryptography — Part 2: Block ciphers (PRESENT)
• ISO/IEC 18033-3:2010 — Block ciphers (AES·SEED·HIGHT)
• ISO/IEC 11889:2015 — Trusted Platform Module Library (TPM 2.0)
• KS X 3246 — LEA Block Cipher (한국 국가표준)
• ARM PSA Crypto API — ARM Platform Security Architecture Certified

5.12 구현 워크시트

1. spec/phase-1-envelopes.md §5에서 cipher_suite 봉투 필드 정의를 정독한다.
2. CLI 도우미 ./cli/tls-lite.sh envelope --cipher_suite=TLS_CHACHA20_POLY1305_SHA256 --group=x25519를 실행해 정상 봉투를 산출한다.
3. simulator panel 4를 띄워 cipher_suite 토글이 device_class·plaintext budget에 미치는 영향을 확인한다.
4. 운영자의 디바이스가 ATECC608·SE050·ARM CryptoCell·TPM 2.0 가운데 어느 것을 채택했는지 확인하고 표 5-6에서 지원 곡선·AEAD를 조회한다.
5. KCMVP 정합이 필요하다면 cipher_inner=lea-128-gcm·standard=KS X 3246 메타데이터를 봉투에 정상 포함시킨다.
6. https://github.com/WIA-Official/wia-tls-lite-conformance의 적합성 슈트 §5.* 항목을 차례로 결선한다.

5.13 표준 간 합성 요약

본 장의 cipher_suite 봉투는 다음 표준과 합성된다. WIA-OMNI-API의 자격증명 저장은 본 장의 PSA Crypto API key_id 추상화와 정상 결합되어 한 디바이스가 다중 표준의 키를 단일 secure element에 저장할 수 있도록 한다. WIA-AIR-SHIELD의 런타임 신뢰 목록은 본 장의 RPK 발급 트러스트 앵커를 그대로 재사용하므로 펌웨어 빌더가 트러스트 앵커를 표준마다 별도 관리하지 않아도 된다. WIA-INTENT의 워크로드 의도 선언은 본 장의 device_class 봉투 필드와 정상 결합되어 「의도된 Class와 실제 Class가 일치하는가」의 자동 검증을 가능하게 한다.

한국 KCMVP 정합 봉투를 채택한 디바이스는 본 장의 cipher_inner=lea-128-gcm 메타데이터와 WIA-INTENT의 intent_jurisdiction=KR 선언이 동시 부착되어 감사 전송에서 정상 한국 컴플라이언스 트랙을 재구성할 수 있다. 한 운영자가 글로벌 디바이스와 한국 KCMVP 디바이스를 동시 운영하더라도 두 디바이스의 감사 전송은 동일한 W3C Trace Context 식별자 체계 안에서 정상 분기·재결합된다.