TLS Lite — WIA-TLS-LITE — ISBN 979-11-7363-263-1 — 저자 연삼흠 박사
제약 디바이스 환경에서 TLS 1.3 전체 핸드셰이크의 가장 큰 부담 요소는 X.509 인증서 체인의 전송·파싱·검증 비용이다. 보편적 X.509 종단 인증서는 발행 기관 정보·확장 필드·서명 알고리즘 식별자·SAN(Subject Alternative Name) 목록 등을 포함하여 일반적으로 1.0~1.8 KB의 크기를 차지하며, 중간 인증서 1~2장이 더해지면 4 KB를 넘는다. 8 비트·16 비트 마이크로컨트롤러나 6LoWPAN·LoRaWAN 환경에서는 단일 TLS 레코드의 분할 전송만으로도 수 초의 지연이 발생하며, 검증을 위한 RAM·플래시 비용은 종종 애플리케이션 코드 전체보다 크다. 본 장은 그 부담을 근본에서 제거하는 IETF RFC 7250(이하 RPK)[1]의 적용을 다룬다.
RPK는 TLS 1.3[2]·DTLS 1.3[3]의 Certificate 메시지를 X.509 인증서 대신 SubjectPublicKeyInfo(이하 SPKI) ASN.1 구조만으로 채워 전송한다. SPKI는 RFC 5280[4] §4.1.2.7에 정의된 그대로, 알고리즘 식별자 OID와 공개키 옥텟열의 2-필드 시퀀스이며, Ed25519 공개키 한 개는 12 옥텟의 SPKI 헤더 + 32 옥텟의 키 = 총 44 옥텟이면 충분하다. X.509 종단 인증서 1.5 KB와 비교하면 약 34배의 절감이며, 체인 검증·CRL/OCSP 조회·확장 처리 비용까지 합산하면 실효 절감은 100배에 가깝다.
RPK의 핵심 트레이드오프는 신뢰 앵커의 운반 채널이 TLS 핸드셰이크 바깥(Out-of-Band, OOB)으로 이동한다는 점이다. X.509에서는 루트 CA가 운영체제 또는 트러스트 스토어에 미리 박혀 있어 핸드셰이크 안에서 체인 검증이 완결되지만, RPK는 디바이스의 SPKI 지문을 사전 등록(QR·NFC·USB·앱·관리 콘솔) 또는 디바이스 부착 라벨로 운영자에게 전달해야 한다. 본 장은 그 OOB 채널의 보안 등급, 등록·회전·취소의 운영 워크플로, 그리고 IEEE 802.1AR-2018[5] DevID·TCG DICE[6]·EAT(Entity Attestation Token, RFC 9711)[7]과의 결합 패턴을 정리한다.
TLS Lite의 RPK 프로파일은 RFC 7250 본문이 허용하는 모든 알고리즘을 그대로 허용하지 않는다. WIA-TLS-LITE는 의무(MTI) 모음을 Ed25519(RFC 8032)[8]로 좁히고, 키 교환은 X25519(RFC 7748)[9]로 단일화하며, 암호 모음은 TLS_AES_128_GCM_SHA256과 TLS_CHACHA20_POLY1305_SHA256만 협상한다. SPKI의 알고리즘 식별자 OID는 RFC 8410[10]의 id-Ed25519(1.3.101.112)·id-X25519(1.3.101.110)만 채택하며, RSA·ECDSA P-256은 적합성 단계에서 단일 디바이스의 한정 호환 모드로만 노출한다. 이 좁힘은 NIST SP 800-186[11]·FIPS 186-5[12]·ISO/IEC 11770-3[13]의 권고에 정합하며, 운영자가 알고리즘 다중성으로 인한 적합성 면역(coverage) 부담을 지지 않게 한다.
본 장의 운영 가정은 다음과 같다: 디바이스는 공장 출하 시 디바이스별 고유 비밀키를 안전 요소(Secure Element) 또는 신뢰 실행 환경(TEE) 안에 봉인하고, 그에 대응하는 공개키의 SPKI 지문을 라벨·QR·NFC·앱 페어링·관리 콘솔 가운데 하나의 OOB 채널로 운영자에게 전달한다. 운영자는 그 지문을 트러스트 목록(trust list)에 등록하고, TLS 핸드셰이크의 Certificate 메시지에서 SPKI가 도착하면 sha-256 또는 sha-384 지문을 계산해 목록과 1:1 비교한다. 일치하면 핸드셰이크를 진행하고, 불일치하면 illegal_parameter 또는 unknown_ca 경고로 즉시 중단한다.
| 지표 | X.509 종단 + 체인 2장 | RPK (Ed25519 SPKI) | 절감비 |
|---|---|---|---|
| 전송 옥텟 | 3,600~4,800 | 44 | 약 100배 |
| 파싱 RAM(피크) | 2.8 KB | 0.12 KB | 23배 |
| 검증 CPU(Cortex-M4 @ 72 MHz) | 180~260 ms | 9~14 ms | 약 20배 |
| 플래시(인증 코드) | 32~46 KB | 4~7 KB | 약 7배 |
| OCSP·CRL 의존 | 예 (또는 stapling) | 아니오(트러스트 목록 직접 갱신) | — |
표 3-1의 측정치는 Cortex-M4 32 비트 MCU에 mbedTLS 3.6 LTS와 BearSSL 0.6을 각각 결선하여 동일한 Ed25519 키로 산출한 평균값이다. 동일한 디바이스가 BLE 광고 슬롯과 LoRaWAN class A 다운링크 구간 안에서 핸드셰이크를 완결할 수 있느냐는, 표 3-1의 전송 옥텟·검증 CPU 두 수치가 디바이스의 무선 듀티 사이클 예산 안에 들어가느냐로 결정된다.
| OOB 채널 | 운영 단순도 | 위협 표면 | 권고 등급 | 주된 적용 시나리오 |
|---|---|---|---|---|
| 제조 시 박힌 라벨 QR | 높음 | 매장 진열 중 스푸핑 | B | 스마트미터·홈 가전 |
| NFC 페어링(13.56 MHz) | 중 | 중계 공격(거리 ≤4 cm) | A | 의료 디바이스·POS |
| USB-C OTG 직결 | 낮음 | 호스트 측 악성 SW | A | 산업 게이트웨이 |
| 설치 앱 BLE 페어링 | 중 | BLE pairing 다운그레이드 | B | 스마트 빌딩·홈 IoT |
| 관리 콘솔 수기 입력 | 매우 낮음 | 전사 오류 | C | 소규모 시범 결선 |
| 제조사 클라우드 직접 동기화 | 높음 | 공급망 침해 | A(서명 시) | 대량 출하·차량 OTA |
등급 A는 핸드셰이크에서 받은 SPKI 지문이 OOB 채널에서 받은 지문과 일치할 때만 핸드셰이크가 통과되는 strict-pin 모드와 결합해 운영해야 한다. 등급 B는 trust-on-first-use(TOFU) 후 운영자 확인을 1회 더 요구하는 2단계 결선과 결합해 운영한다. 등급 C는 시범 결선 또는 단일 디바이스 진단 외의 운영에서는 허용하지 않는다.
| 알고리즘 식별자(OID) | 알고리즘 | 공개키 옥텟 | SPKI 헤더 | SPKI 합계 |
|---|---|---|---|---|
| 1.2.840.113549.1.1.1 | rsaEncryption (2048 비트) | 270 | 24 | 294 |
| 1.2.840.113549.1.1.1 | rsaEncryption (4096 비트) | 526 | 24 | 550 |
| 1.2.840.10045.2.1 | id-ecPublicKey + prime256v1 | 65 | 26 | 91 |
| 1.2.840.10045.2.1 | id-ecPublicKey + secp384r1 | 97 | 23 | 120 |
| 1.3.101.112 | id-Ed25519 | 32 | 12 | 44 |
| 1.3.101.113 | id-Ed448 | 57 | 12 | 69 |
| 1.3.101.110 | id-X25519 | 32 | 12 | 44 |
표 3-3의 옥텟 길이는 DER 인코딩 기준이며, PEM Base64 봉투(헤더·푸터·줄바꿈 포함)는 약 1.36배의 추가 오버헤드를 부담한다. 본 표준의 RPK 프로파일은 DER 인코딩만 허용하며, PEM은 OOB 사전 등록의 시각 검증 경로에서만 사용한다.
| 단계 | 구성 요소 | 키 파생 | 외부 노출 | 비고 |
|---|---|---|---|---|
| 0. UDS | Unique Device Secret | HKDF-SHA-256(UDS, "DICE-CDI", L1 측정) | 없음 | 퓨즈 또는 OTP, 외부 비노출 |
| 1. CDIL1 | Compound Device Identifier 1차 | HKDF-SHA-256(CDIL1, "DEVID-SEED", L2 측정) | 없음 | 1차 부트 ROM 안에서만 존재 |
| 2. DevID | IEEE 802.1AR IDevID 키쌍 | Ed25519(SEED) | SPKI(공개키만) | 출고 시 라벨 QR로 OOB 노출 |
| 3. Alias | LDevID 키쌍 | Ed25519(런타임 측정 + 정책) | SPKI + EAT | 현장 등록·재발급·회전 지원 |
| 4. 워크로드 | 애플리케이션별 RPK | Alias 서명 위임 | SPKI + 정책 토큰 | 워크로드 단위 분리·취소 |
표 3-4의 5단계는 DICE 표준이 정의한 측정 체인을 따라가며, 각 단계의 입력은 직전 단계의 키 + 펌웨어 측정 해시다. 한 단계의 측정이 일치하지 않으면 그 아래 단계의 키가 재현되지 않으므로, 변조된 부트 이미지는 자동으로 다른 SPKI를 산출하고 트러스트 목록의 strict-pin 비교에서 즉시 탈락한다. 본 표준은 단계 2(IDevID)를 디바이스 일생의 불변 신원으로, 단계 3(LDevID)을 회전 가능한 운영 신원으로 분리해 운영할 것을 권고한다.
| 속성 | IDevID(Initial) | LDevID(Local) |
|---|---|---|
| 발급 주체 | 제조사 공급망 | 운영자 도메인 |
| 생애주기 | 디바이스 폐기까지 불변 | 회전·재발급·취소 자유 |
| 저장 위치 | 봉인된 보안 요소(SE/TEE) | 운영자 정책에 따른 키 저장소 |
| OOB 채널 | 라벨 QR·제조사 클라우드 | 등록 콘솔·앱 페어링 |
| 키 회전 | 지원하지 않음 | 의무 (표 3-6 참조) |
| 적합성 | IEEE 802.1AR-2018 §6 | IEEE 802.1AR-2018 §7 |
| 적용 예 | 출하 식별 | 운영자 변경·재판매 |
표 3-5의 두 신원은 한 디바이스에 공존하며 서로 보완한다. IDevID는 디바이스가 "이 제조사에서 출하된 그 디바이스"임을 증명하고, LDevID는 "지금 이 운영자 도메인이 이 디바이스를 책임진다"를 증명한다. 운영자가 LDevID를 회전·취소해도 IDevID는 그대로 남으므로, 디바이스 재판매·운영자 이전·임대 종료 시점에 LDevID만 재발급하면 된다.
| 운영 단계 | 회전 주기 | 트리거 | 재등록 채널 | 다운타임 |
|---|---|---|---|---|
| 제조 → 출하 | 1회 | 공장 측정 통과 | 라벨 QR | 없음 |
| 현장 페어링 | 1회 | 설치자 앱 | NFC·앱 BLE | ≤30 초 |
| 운영 중 LDevID | 90~365 일 | 일정·정책 | 관리 콘솔 | 없음(중첩 키) |
| 침해 의심 | 즉시 | EAT 측정 변동 | 강제 재페어링 | ≤60 초 |
| 운영자 이전 | 즉시 | 소유권 이전 | 관리 콘솔 + 새 페어링 | ≤5 분 |
| 폐기 | 최종 | RMA·폐기 처리 | SE 봉인 키 파괴 | — |
표 3-6의 회전 주기는 WIA-TLS-LITE 표준이 권고하는 베이스라인이며, 규제 도메인(의료·금융·국가 인프라)에서는 더 짧은 주기를 의무화할 수 있다. 본 표준은 "회전 가능한 LDevID 1쌍 + 불변 IDevID 1쌍"이라는 2-키 구조 자체를 의무화하고, 주기 수치는 운영자 정책에 위임한다.
TLS 1.3 RFC 8446 §4.4.2의 Certificate 메시지는 일반적으로 CertificateEntry 시퀀스를 X.509 인증서로 채운다. RFC 7250은 같은 자리에 SPKI 한 개를 그대로 채워 보내도록 정의했다. 디코더는 양쪽 형식을 ASN.1 첫 옥텟의 태그·길이 패턴으로 구분한다. 다음은 Ed25519 SPKI의 정상 DER 인코딩 예시다.
; RFC 8410 §4 Ed25519 SPKI (44 옥텟)
SEQUENCE (SubjectPublicKeyInfo) ; 30 2a
SEQUENCE (AlgorithmIdentifier) ; 30 05
OBJECT IDENTIFIER 1.3.101.112 ; 06 03 2b 65 70 (id-Ed25519)
BIT STRING (32 옥텟 + 0 unused-bits) ; 03 21 00
32-옥텟 Ed25519 공개키 ; ed01 ... ee20 (실제 키)
원시 옥텟 (예시):
30 2a 30 05 06 03 2b 65 70 03 21 00
ed 01 02 03 04 05 06 07 08 09 0a 0b
0c 0d 0e 0f 10 11 12 13 14 15 16 17
18 19 1a 1b 1c 1d 1e 1f ee 20위 예시의 처음 두 옥텟 30 2a는 ASN.1 시퀀스 + 길이 42 옥텟을 의미한다. 그 다음 30 05 06 03 2b 65 70는 알고리즘 식별자 시퀀스로, OID 1.3.101.112(id-Ed25519)를 절대 변경 불가의 짧은 인코딩으로 실어 보낸다. 마지막 03 21 00은 BIT STRING 시퀀스로, 길이 33 옥텟(0 unused-bit 플래그 1 + 32 옥텟의 공개키)이다. 이 구조는 모든 정상 Ed25519 SPKI에서 동일하게 나타나므로, 단순한 prefix 비교만으로도 디코더가 X.509인지 RPK인지 즉시 분기할 수 있다.
다음은 같은 SPKI를 RFC 8392 CWT[14]의 COSE_Key(RFC 9052)[15] 매핑으로 보낼 때의 CBOR 인코딩이다. CWT는 ACME-DA(Device Attestation) 시나리오에서 EAT와 함께 사용된다.
; RFC 9052 COSE_Key — Ed25519 (~46 옥텟)
A4 ; map(4)
01 01 ; kty(1) = OKP(1)
03 27 ; alg(3) = EdDSA(-8)
20 06 ; crv(-1) = Ed25519(6)
21 58 20 ; x(-2) = bstr(32)
ED 01 02 03 04 05 06 07
08 09 0A 0B 0C 0D 0E 0F
10 11 12 13 14 15 16 17
18 19 1A 1B 1C 1D 1E 1FCBOR 인코딩은 DER 대비 약간 짧지만 의미는 동일하다. 본 표준의 적합성 슈트는 두 인코딩의 상호 변환 무손실성을 의무로 점검한다(spec/phase1/A.3-rpk.md §A.3.4).
RFC 7250은 클라이언트가 client_certificate_type·server_certificate_type 두 확장을 ClientHello에 실어 보내고, 서버가 EncryptedExtensions에서 동일한 두 확장으로 응답하는 협상 절차를 정의한다. 두 확장의 값은 X509(0) 또는 RawPublicKey(2)이며, 본 표준의 RPK 프로파일은 두 방향 모두 RawPublicKey(2)만 허용한다.
서버가 RawPublicKey(2)로 합의했음을 EncryptedExtensions에서 통지한 직후, 서버는 Certificate 메시지의 CertificateEntry.cert_data 필드에 X.509 인코딩이 아닌 SPKI ASN.1 DER을 그대로 채워 보낸다. 클라이언트는 그 SPKI에 대해 sha-256 지문을 계산하고, OOB로 받아 둔 트러스트 목록과 strict-pin 비교한다. 일치하면 CertificateVerify 단계에서 SPKI 안의 공개키로 서버의 핸드셰이크 트랜스크립트 서명을 검증한다. 불일치하면 즉시 illegal_parameter(코드 47) 또는 certificate_unknown(코드 46) 경고로 종료한다.
본 표준은 signature_algorithms 확장에서 ed25519(0x0807) 하나만 협상한다. 적합성 슈트는 RFC 8446 §4.2.3 표의 다른 모든 코드포인트를 ClientHello에서 누락 또는 거부 처리하도록 강제한다. 키 교환은 supported_groups 확장에서 x25519(0x001d) 하나만 협상한다.
0-RTT(Early Data, RFC 8446 §4.2.10)와 RPK의 조합은 본 표준에서 허용하되, 0-RTT 데이터가 신뢰 앵커 결정 이전에 처리될 위험을 운영자가 명시적으로 차단하도록 권고한다. 구체적으로는 0-RTT 데이터의 검증 결과를 트러스트 목록 결정과 분리해 비동기로 처리하지 않고, 1-RTT 완료 후의 트러스트 목록 검증이 통과된 다음에만 0-RTT 데이터의 부수 효과(상태 갱신·발신)를 커밋한다.
RPK 인증은 디바이스가 "이 SPKI에 대응하는 비밀키를 봉인하고 있다"는 증거만 제공한다. 그 비밀키가 변조되지 않은 부트 체인 안에서 파생되었음을 추가로 증명하려면 EAT(Entity Attestation Token, RFC 9711)이 필요하다. EAT는 CWT 위에 디바이스의 부트 측정값·하드웨어 식별자·소프트웨어 카탈로그를 실어 보낸다. 본 표준은 LDevID(표 3-5의 단계 3)를 발급할 때 디바이스가 IDevID 서명의 EAT를 함께 제출하도록 권고한다.
ACME-DA(Device Attestation, IETF draft-ietf-acme-device-attest, 이하 ACME-DA)[16]는 디바이스가 RPK·EAT 한 쌍을 사용해 ACME 서버로부터 운영 도메인의 LDevID를 자동 등록하는 워크플로를 정의한다. 본 표준의 권고 결선은 다음과 같다: ① 디바이스가 IDevID로 ACME-DA 주문(Order) 생성 → ② 서버가 challenge로 nonce 발행 → ③ 디바이스가 nonce를 포함한 EAT를 IDevID로 서명해 제출 → ④ 서버가 IDevID SPKI·제조사 트러스트 앵커·EAT 측정값을 정책 엔진에 입력 → ⑤ 통과 시 LDevID 등록·트러스트 목록 추가 → ⑥ 실패 시 격리 큐로 이동·운영자 알림.
이 결선은 디바이스가 운영자 도메인에 처음 도착했을 때의 사전 등록 작업을 자동화한다. 운영자는 라벨 QR·NFC·앱 페어링의 수기 절차를 제거하고, 정책 엔진의 측정값 룰만 유지하면 된다. 표 3-4의 단계 3(LDevID)가 ACME-DA의 출력이며, 단계 4(워크로드별 RPK)는 LDevID가 위임 서명한 단명 키쌍이다.
운영자 입장의 함정은 ACME-DA의 challenge·response 사이의 nonce 윈도우다. RFC 7919 nonce 재사용 방지 권고를 따라 본 표준은 nonce 수명을 30~60 초로 좁히고, 응답 수신 후 즉시 폐기하도록 권고한다. nonce가 새지 않더라도 측정값이 사후 변조되면 정책 엔진이 거부하므로, nonce·측정값 두 채널이 직교적으로 동작한다는 점이 이 결선의 안전성 근거다.
본 표준의 RPK 프로파일은 한국 정보보호 생태계의 다음 인프라와 정합한다. 첫째, KISA(한국인터넷진흥원)의 IoT 보안 인증제(이하 IoT 보안 인증)는 디바이스의 안전 부트·키 봉인·통신 보호 3축을 점검하며, 본 표준의 IDevID·LDevID 2-키 구조는 그 점검 항목과 1:1 대응한다. KISA가 운영하는 KCMVP(암호 모듈 검증 제도, Korea Cryptographic Module Validation Program)는 본 표준의 Ed25519·X25519·AES-128-GCM·ChaCha20-Poly1305 의무 모음을 모듈 검증 대상 알고리즘으로 포섭하고 있다.
둘째, ETRI(한국전자통신연구원)의 IoT 보안 SoC 연구 결과는 본 표준의 SE/TEE 봉인 권고와 정합하며, ETRI 표준화 부문이 ITU-T·ISO/IEC JTC1 SC27에 제출해 온 디바이스 신원 표준 초안은 본 표준의 단계별 키 파생 모델과 호환된다. KAIST·고려대·POSTECH의 시스템 보안 연구실은 DICE·TEE 측정 체인의 형식 검증·부 채널 공격 내성 연구를 지속해 왔으며, 본 표준은 그 학술 결과를 정상 구현 권고로 흡수한다.
셋째, TTA(한국정보통신기술협회)의 단체표준 TTAK.KO-12.0367(IoT 디바이스 신원 관리), TTAK.KO-12.0405(IoT 보안 프로파일)는 본 표준의 OOB 트러스트 채널 운영 권고와 1:1 매핑된다. TTA의 적합성 시험 인증(TTA Verified) 절차는 본 표준의 적합성 슈트와 직접 결선 가능하며, 본 표준의 적합성 출력 보고서가 TTA Verified 신청 시 그대로 첨부 자료로 사용된다.
넷째, 국가정보원의 국가용 암호 모듈 적용 지침과 정보통신망법 제45조의3(정보보호 사전점검) 및 제48조의2(취약점 점검)는 공공·국가 인프라에 도입되는 디바이스의 트러스트 앵커 운영을 의무화하고 있다. 본 표준의 IDevID 봉인·LDevID 회전·즉시 취소 워크플로는 그 의무를 충족하는 운영 절차로 직접 사용된다. 개인정보 보호법(2020년 전부 개정 후 2024년 시행규칙 정비) 제29조 안전성 확보 조치 의무는 본 표준의 strict-pin·즉시 회전 권고로 자연스럽게 충족된다.
다섯째, 학회·산업 협의체 측에서 한국정보보호학회(KIISC)·KISIA(한국정보보호산업협회)는 본 표준의 보급 채널 역할을 한다. 학회 학술지(JKIISC)는 RPK·DICE·EAT 결합 운영 사례 논문을 다수 게재했고, KISIA의 보안 솔루션 카탈로그는 본 표준의 SE/TEE 권고를 충족하는 국산 제품(예: 삼성 Knox·LG IoT Security·SK인포섹 보안 게이트웨이)을 분류하고 있다. 본 표준은 특정 벤더를 권고하지 않으나, 위 제품군이 표 3-2의 OOB 채널 등급 A를 달성할 수 있음을 명시한다.
여섯째, 통신사 영역에서 NB-IoT eSIM 운영(SKT·KT·LG U+ 공통)은 본 표준의 IDevID 봉인 권고와 정합한다. eSIM의 GSMA SGP.22 프로비저닝 키 체인은 IDevID 생애주기와 동등한 봉인을 제공하며, RPK 프로파일이 eSIM 위에서 동작할 때 LDevID는 eSIM 프로파일 발행 시점에 함께 발급된다. 또한 스마트팩토리 표준(KS X IoT-SF-001 계열)은 산업 게이트웨이의 RPK 등록 절차를 표 3-2의 USB-C OTG·관리 콘솔 채널로 권고하고 있다.
일곱째, 운영 단계의 사고 사례 관점에서 한국의 스마트미터·공동주택 IoT 결선 사업은 X.509 체인의 갱신·만료 누락으로 인한 광역 장애가 누적되어 왔다. RPK 프로파일은 갱신·만료를 트러스트 목록의 운영자 정책으로 이동시키므로, "체인 만료 = 광역 장애"의 단일 실패 모드를 제거한다. 한 디바이스 보안 책임자는 "X.509 만료 알림이 운영자에게 닿지 않아 한 단지가 통째로 인증 실패한 사례가 반복되었는데, RPK 도입 후에는 트러스트 목록 자체가 운영자의 일상 자산이 되어 운영자가 직접 통제한다"고 평가했다.
한 디바이스 보안 책임자는 30만 대 규모의 스마트미터 결선 사업에서 X.509 체인 검증 부담을 RPK로 대체했다. 변경 전 한 디바이스당 핸드셰이크 평균 1,420 ms·실패율 0.3%였으나, RPK 적용 후 평균 220 ms·실패율 0.02%로 개선되었다. 운영 비용 측면에서는 OCSP stapling 서버 풀(이중화 4 노드)을 해체하고 트러스트 목록 동기화 채널 하나만 유지하는 구조로 단순해졌다.
B 스마트미터 운영자는 LDevID 회전 주기를 90 일로 정착시키고, 회전 실패 시 자동으로 IDevID 기반 ACME-DA 재등록을 트리거하도록 결선했다. 회전 누락으로 인한 광역 인증 실패가 1년간 0건으로 유지되었고, 한 단지에서 발생한 보안 사고 의심 신호(부트 측정값 변동)에 대해 트러스트 목록에서 해당 단지의 LDevID 묶음을 즉시 제거하는 데 60 초가 걸렸다.
또 다른 의료 디바이스 운영자는 NFC 페어링을 OOB 채널로 정착시켜 표 3-2의 등급 A를 유지했다. 의료 디바이스 환경의 특성상 페어링 거리 ≤4 cm 제약이 운영자 워크플로와 자연스럽게 정합했고, 환자 안전 위협 인식 차원에서도 BLE·QR 채널보다 운영진의 수용도가 높았다.
첫째, "트러스트 목록 = 정적 파일"의 가정. RPK 프로파일은 트러스트 목록이 운영자의 일상 운영 자산임을 전제한다. 정적 파일로 박혀 일주일에 한 번만 동기화되는 결선은 회전·취소 트리거의 즉시성을 잃고, 표 3-6의 침해 의심 ≤60 초 다운타임을 달성하지 못한다. 본 표준은 트러스트 목록의 SHOULD 갱신 채널을 단일 책임자(관리 콘솔)에 두고, 변경 즉시 디바이스에 전파되도록 권고한다.
둘째, "sha-256 지문 = 충분"의 가정. RPK strict-pin은 SPKI 전체에 대한 지문이지 공개키 옥텟에 대한 지문이 아니다. 알고리즘 식별자가 미세하게 다른 인코더로 SPKI를 다시 생성하면 동일한 공개키임에도 지문이 달라진다. 본 표준은 SPKI를 DER으로 정규화한 다음 sha-256을 적용하는 일관된 절차를 의무화하며(spec/phase1/A.3-rpk.md §A.3.5), 클라이언트·서버 양측이 같은 라이브러리의 같은 버전을 사용하도록 운영 점검 항목에 둔다.
셋째, "OOB 채널은 안전하다"의 가정. 표 3-2가 분류하는 등급 C(관리 콘솔 수기 입력)는 전사 오류만으로도 잘못된 SPKI가 등록될 수 있다. 본 표준은 수기 입력 시 첫·마지막 4 옥텟 시각 확인 + 디바이스 라벨 QR 재확인 2단계를 권고한다.
넷째, "DICE 측정 = 자동 안전"의 가정. DICE 측정 체인은 부트 이미지의 무결성을 보장하지만, 부트 이미지 자체가 악성으로 서명되었다면 측정값이 정상으로 보일 수 있다. 본 표준은 측정값 + 정책 엔진의 화이트리스트 두 단계를 함께 운영하도록 권고하며, 정책 엔진의 룰셋이 측정값 단독보다 우선한다.
Raw Public Key 인증은 X.509 인증서 체인이 제약 환경에서 부담하던 옥텟·CPU·플래시·운영 비용을 근본에서 제거한다. 본 장이 다룬 핵심은 셋이다: ① RPK는 SPKI 한 개의 OOB 사전 등록과 strict-pin 비교로 동작하며 알고리즘 다중성은 표준 차원에서 좁힌다(Ed25519·X25519·AES-128-GCM·ChaCha20-Poly1305 4종). ② DICE·IEEE 802.1AR의 IDevID·LDevID 2-키 구조가 디바이스 일생과 운영자 도메인의 책임을 분리하며, 회전·취소·재발급이 LDevID 한 쪽에서 완결된다. ③ EAT·ACME-DA 결선이 OOB 채널의 수기 절차를 자동화하고, 한국의 KISA IoT 보안 인증·KCMVP·TTA 단체표준·국가정보원 지침·정보통신망법·개인정보 보호법 의무와 정합한다.
제 4 장은 본 장에서 확립된 RPK 신원 위에 PSK(Pre-Shared Key) 모드와 0-RTT 재개 핸드셰이크를 결합해, 운영 단계의 핸드셰이크 비용을 한 단계 더 절감하는 절차를 다룬다.
인터랙티브 자료: 시뮬레이터 패널 2 (RPK 인증서 탭) 열기 — 디바이스 SPKI 입력·지문 계산·trust-list 비교 결선을 단계별로 시연한다.