독자층: 이 글은 교육부 담당관, 브랜드사 IT 보안 책임자, OEM 프로그램 매니저와 같이 “리딩펜이 어떻게 우리 클라우드와 통신하는지, 프록시와 통신하는 것이 아닌지”라는 질문에 RFP 단계에서 답해야 하는 조달 담당자를 위해 작성되었습니다. SPKI 해시 피닝, 피닝셋 로테이션 주기, 잘못된 엔드포인트로 통신을 시도한 펜을 알려주는 텔레메트리, 그리고 Smart Reading Pen 라인업(B1, B2, F8, K7, KF1, L5, P2, Q6, Q8, T2, Y6) 11개 모델 전부에 적용되는 보안팀의 인시던트 대응 플레이북을 함께 살펴봅니다.
리딩펜은 깨어 있는 시간 중 22%만 온라인 상태입니다. 대기 전류는 0.06 mA이며, 스캔 시, 사용자 버튼 입력 시, OTA 워치독에 의해 깨어납니다. 깨어났을 때 클라우드와 통신하고 상태를 동기화한 뒤 다시 절전으로 돌아가기까지 단 9~16초밖에 확보되지 않습니다. 바로 이 9~16초의 윈도우가 기업의 MITM 프록시가 노리는 구간입니다. 우리는 모든 TLS 핸드셰이크에서 SPKI 해시 피닝으로 채널을 보호합니다. 이 글은 그 기술적 디테일을 다루는 엔지니어링 심층 분석입니다.
구매자 팁: 두 벤더의 “TLS 1.3 지원”을 비교하실 때 그것만으로는 차별화가 되지 않습니다. 두 업체 모두 지원하기 때문입니다. 진짜 차별화는 클라우드 인증서가 예고 없이 변경되었을 때 펜이 연결을 거부하느냐입니다. 운영 환경의 피닝셋 로테이션 주기와 필드 디버그 메뉴 접근 코드를 반드시 요청해 보십시오. 망설이는 업체는 피닝을 적용하지 않은 업체입니다.
1. 임베디드 디바이스에서 표준 TLS만으로는 부족한 이유
리딩펜은 브라우저가 하는 방식으로는 WebPKI를 실행할 수 없습니다. 신뢰 저장소를 자동으로 업데이트하는 채널이 없고, Google CRL 파이프라인도, Apple 푸시 알림도 없습니다. Mozilla CA 번들을 그대로 펜에 탑재하면, 번들에 포함된 140개 루트 중 어느 하나라도 CA가 침해당할 경우 47,000대 이상의 펜을 리콜해야 합니다. 그래서 우리는 CA 번들을 포함하지 않습니다. 대신 핀 세트(pin-set)를 출하합니다. 이는 디바이스가 신원을 증명하는 수단으로 받아들일 SPKI 해시 목록입니다.
펜이 클라우드 MQTT 엔드포인트 mqtt-eu.smartreadingpen.com 에 접속을 시도하면, TLS 핸드셰이크 과정에서 서버 인증서가 반환됩니다. 리딩펜은 해당 인증서의 SubjectPublicKeyInfo(공개키 바이트)에 대한 SHA-256 해시를 계산한 뒤, 보안 요소(Secure Element)에 저장된 피닝셋과 비교합니다. 해시가 일치하면 연결을 진행하고, 일치하지 않으면 연결을 거부하고 해당 이벤트를 로그에 기록합니다.
| 클라우드 엔드포인트 | 인증서 | SPKI 해시(SHA-256, 상위 32바이트) |
|---|---|---|
mqtt-eu.smartreadingpen.com |
Let's Encrypt R3 크로스 사인 | d2 5e 7e 40 6f 4d c6 a5 4b 2a bc d0 f2 a5 8b 80 c8 9b a6 1f 18 b7 81 9e 76 67 50 da 8c e4 0d 3c |
mqtt-us.smartreadingpen.com |
ISRG Root X1 (자체 서명) | 96 bc ec 06 26 49 76 f3 7d 63 75 c2 bb c1 df e6 9c a0 47 b7 6d a3 95 65 4c 6d 4d 6e 5d 2c 21 4b |
ota-eu.smartreadingpen.com |
ISRG Root X1 (자체 서명) | 96 bc ec 06 26 49 76 f3 7d 63 75 c2 bb c1 df e6 9c a0 47 b7 6d a3 95 65 4c 6d 4d 6e 5d 2c 21 4b |
ota-asia.smartreadingpen.com |
DigiCert Global G2 | 15 96 09 49 e3 a8 9c 89 1d 33 0f 9c 2d 1f c8 60 d6 89 d9 d0 1a 04 6c 8a 4c 4f 1d e2 e7 7c ec ff |
해시를 두 개씩 핀 고정하는 패턴은 의도적인 설계입니다. 모든 엔드포인트는 현재 운영 중인 인증서와 다음에 전환할 인증서, 총 두 개의 SPKI 해시에 동시에 핀 고정됩니다. 따라서 인증서를 교체하더라도 현장 리콜이 발생하지 않습니다.
2. 디바이스 내부의 피닝셋 레이아웃
L5 또는 Q8의 일반적인 피닝셋은 NVM에서 다음과 같은 형태입니다.
pin-set[0]= SPKI 해시(주 인증서) = 15 96 09 ...
pin-set[1]= SPKI 해시(백업) = 96 bc ec ...
pin-set[2]= 만료일(에포크 1747) = 2027-01-15
pin-set[3]= 플래그 = PIN_REQUIRED | PIN_LOG_ON_MISS
pin-set[4]= 폐기 목록(CRL) = 1개 항목
pin-set[5]= 체인 최대 길이 = 3
플래그는 운영 레버입니다. PIN_REQUIRED 은 불일치 시 핸드셰이크를 거부합니다. PIN_LOG_ON_MISS 은 해당 SHA-256과 출발지 IP를 다음 동기화 시점을 위해 NVRAM에 기록합니다. PIN_LOG_ONLY 는 연결은 허용하되, 진단을 위해 불일치 사실을 로그로 남깁니다. 모든 SKU에서 기본적으로 PIN_REQUIRED은 모든 SKU에서 기본적으로 활성화되어 있으며, OEM 파트너용으로 PIN_LOG_ONLY 는 QA 빌드 전용으로 예약되어 있습니다.
3. 로테이션 주기
핀은 영원히 유지되지 않습니다. 교체를 결정짓는 두 가지 시계가 있습니다. 하나는 만료 시점(에포크)이고, 다른 하나는 긴급 트리거(CA 침해, 장비 변경)입니다. 현장 리콜을 감당할 수 없기 때문에 교체 주기는 신중하게 잡습니다.
| 피닝셋 | 담당 | 하드 만료 | 소프트 검토 | 긴급 트리거 | 적용 방식 |
|---|---|---|---|---|---|
| 클라우드 MQTT(주 채널) | 클라우드 팀 | 24개월 | 18개월 | CA 침해, MITM 텔레메트리 | 펌웨어 OTA + SE 재플래시 |
| 클라우드 MQTT 백업 | 클라우드 팀 | 24개월 | 18개월 | 해당 없음 (항상 동일 방향 회전) | 펌웨어 OTA |
| OTA 서버 | OTA 팀 | 12개월 | 9개월 | OTA 체인 변조 | 펌웨어 OTA + 보안 요소(SE) |
| OEM 포털 | OEM(Pattern A 전용) | 12개월 | 9개월 | OEM 요청 | OEM HSM 측 |
| 크래시 리포터 | 클라우드 팀 | 36개월 | 24개월 | TLS 인증서 만료 | 펌웨어 OTA |
배포된 47,000개 이상의 펜에 걸쳐 클라우드 MQTT 핀 세트를 세 차례 교체한 적이 있습니다. 2023년 1회(Let's Encrypt 교차 서명), 2024년 1회(ISRG Root X1만), 2025년 1회(DigiCert 중간 인증서). 각 교체는 14일 이내에 99.6%가 적용되었으며, 나머지 펜은 학교 데스크톱 크래들을 통한 오프라인 OTA로 45일 이내에 동기화되었습니다.
4. 필드 텔레메트리: 핀 불일치 발생을 어떻게 아는가
펜은 핀 검사를 조용히 실패하지 않습니다. 모든 불일치는 NVRAM에 다음 항목과 함께 기록됩니다. 타임스탬프(RTC), 시도한 SPKI 해시, 엔드포인트 호스트명, 확인된 IP, 인증서 체인 깊이, 로컬 네트워크 SSID(Wi-Fi 연결 시). 다음 성공적인 부팅 — 일반적으로 9시간 이내 — 에 로그 항목이 기업 텔레메트리 채널을 통해 백엔드로 업로드됩니다.
2026-06으로 끝나는 1년간 배포된 47,000개 이상의 펜에 대한 핀 검사 텔레메트리 요약:
| 이벤트 | 건수 | 펜 전체 비율 | 펜당 중앙값 | 조치 |
|---|---|---|---|---|
| 핸드셰이크 성공 | 1,240만 | 99.85% | 264 | 정상 |
| 핀 불일치 (위반 SPKI 해시) | 18,240 | 0.13% | 0.39 | 검토 완료 |
| 핀 불일치 + 체인형 불일치 | 184 | 0.0014% | 0.004 | 에스컬레이션 |
| 사고 후 강제 교체 | 2 | — | — | 사후 분석 보고서 작성 완료 |
2026-06으로 끝나는 1년간 발생한 체인형 불일치 184건이 흥미로운 사례입니다. 이는 기업 프록시가 통과 중 인증서를 재서명하여 발생했습니다. 이 사례들은 각각 48시간 이내에 학교 IT 부서의 지원 티켓을 생성했습니다. TLS 핸드셰이크가 페이로드가 네트워크를 통과하기 전에 거부되므로 데이터 유출로 이어진 사례는 단 한 건도 없었습니다.
5. 90일 "조용한 교체" 훈련
90일마다 "조용한 교체" 훈련을 수행합니다. 새로운 SPKI 해시로 테스트 MQTT 브로커에 서명하고, 해당 해시를 5,000대의 펜에 백업 핀으로 푸시한 뒤, 테스트 브로커에서 핸드셰이크 성공 여부를 관찰합니다. 5,000대 펜 중 99%가 성공하면 전체 플릿에 대한 교체를 승인합니다.
이 훈련이 99.0% 임계값을 넘지 못한 적은 단 한 번도 없었습니다. 가장 낮았던 사이클은 98.4%의 2026년 3분기였으며, 이는 TLS를 복호화하는 기업 프록시의 펜 32대에서 발생한 것으로, 해당 32대는 디바이스가 아니라 OEM Agreement를 통해 재구성되었습니다.
6. 자체 핀을 원하는 OEM 프로그램
Pattern A OEM 프로그램(T2 및 Y6 전용)의 경우, 수입업체의 HSM이 재서명할 수 있는 OEM 포털 서명 인증서를 인계합니다. 수입 포털은 mTLS를 통해 디바이스를 인증합니다. 핀 세트는 T2/Y6 보안 요소에 보관됩니다.
OEM은 자체 핀 교체 주기를 설정할 수 있습니다. 대부분 12개월을 선택합니다. T2/Y6에서는 온디바이스 재핀이 4,600바이트 OTA이며 1.2초 만에 실행되므로 6개월 주기도 적합합니다. 6개월 미만에서는 OTA 채널에 CR-LATEX-NAGLE 스타일의 압력이 관찰되어 권장하지 않습니다.
| OEM 핀 주기 | 권장 여부 | OTA 페이로드 크기 | Wi-Fi 연결 시간 |
|---|---|---|---|
| 3개월 | 아니요 | 4 600 B | 1.2 s |
| 6개월 | 예 | 4 600 B | 1.2 s |
| 12개월 | 예(기본값) | 4 600 B | 1.2 s |
| 24개월 | 예(클라우드 MQTT) | 4 600 B | 1.2 s |
7. 핀 불일치가 정답일 때 발생하는 일
모든 핀 불일치가 공격인 것은 아닙니다. 학교 IT 팀이 조사해야 할 불일치가 올바른 정책이 작동한 사례가 세 가지 반복됩니다.
- 학교 기업 프록시 — 프록시가 TLS를 재서명하여 핀이 깨집니다. 펜이 거절합니다. OEM 포털을 통해 프록시의 SPKI 해시를 펜에 추가하는 것이 해결책이지만, 프록시가 학교 관리 네트워크에 있는 경우에만 가능합니다.
- 오래된 오프라인 사전 — 24개월 이상 보관된 펜이 로테이션된 인증서에 부딪힙니다. OEM 서비스 센터에서 수동으로 재플래시하는 것이 해결책입니다.
- 위조 클라우드 — 유효한 TLS 체인을 가진 가짜 MQTT 브로커를 누군가 구축했습니다. 핀이 거절합니다. OEM은 체인 불일치 보고서를 통해 알림을 받습니다.
세 가지 모두 모든 OEM 계약에 첨부된 문서화된 핸들링 런북이 함께 제공됩니다. 12 000개 이상의 펜을 운영하는 학교는 2시간 런북 워크스루를 받습니다.
8. 유통사 및 입찰을 위한 결론
인증서 핀은 리딩 펜에서 가장 사후에 보강하기 어려운 부분입니다. 핀을 적용하지 않는 공급업체와 시작하면 하드웨어 개정이 없이는 추가할 수 없습니다. 저희 11개 SKU는 모든 TLS 핸드셰이크에서 핀을 적용하고 검증된 주기로 분기마다 핀 세트를 로테이션합니다. RFP 부속문서에 명시된 "모든 엔드포인트 SPKI 핀 적용, 2개 해시 오버랩 및 24개월 하드 만료"라는 문구를 모든 조달 담당자가 인지할 것입니다.
행동 유도 버튼(CTA)
관련 콘텐츠
- 리딩 펜 TLS 1.2 vs 1.3 및 인증서
- 리딩펜 암호화 및 TrustZone
- 리딩 펜 키 관리 및 HSM
- 리딩 펜 롤백 방지 및 버전 인증
- 리딩 펜 펌웨어 암호화 및 보안 부팅
- 리딩 펜 OTA 펌웨어 업데이트 메커니즘
- 견적 요청