디지털 키 SE 키 라이프사이클: 생성, 프로비저닝, 공유, 취소
차량 디지털 키의 보안은 Secure Element(SE) 안에서 키가 어떻게 만들어지고, 교환되고, 폐기되는지에 달려 있다. 시스템 설계: BLE+UWB 차량 디지털 키에서 전체 동작 흐름을 다뤘다. 이 글은 SE 내부의 키 라이프사이클을 다룬다.
SE 내부 키 생성
SE는 독립된 프로세서와 자체 OS(JavaCard/JCOP)를 가진 칩이다. 키 생성은 SE 내부에서 완결된다.
SE 칩 내부
┌─────────────────────────────────┐
│ JavaCard OS (JCOP) │
│ ┌───────────────────────────┐ │
│ │ CCC Digital Key Applet │ │
│ │ ┌─────┐ ┌───────────┐ │ │
│ │ │TRNG │→│ECC P-256 │ │ │
│ │ │ │ │Key Gen │ │ │
│ │ └─────┘ └─────┬─────┘ │ │
│ │ │ │ │
│ │ ┌────────────┴──┐ │ │
│ │ │ Private Key │ │ │
│ │ │ (절대 외부 노출 X)│ │ │
│ │ └───────────────┘ │ │
│ └───────────────────────────┘ │
│ Secure Storage (tamper-proof) │
└─────────────────────────────────┘- SE의 하드웨어 TRNG(True Random Number Generator)가 난수를 생성한다. 소프트웨어 PRNG가 아니라 물리적 노이즈 소스(열 잡음, 샷 노이즈)에서 추출한다
- TRNG 출력을 시드로 ECC P-256 (NIST) 키 쌍을 생성한다
- 개인키는 SE의 보안 스토리지에 저장된다. SE 외부로 나오지 않는다. 읽기 API가 없다
- 공개키는 X.509 인증서 형태로 외부에 전달된다
SE가 생성하는 키의 종류:
| 키 | 용도 | 생성 시점 |
|---|---|---|
| Instance CA 키 쌍 | OEM별 인증서 체인의 루트. 이 CA 아래에 모든 키가 속한다 | OEM 앱 최초 설치 시 (OEM당 1개) |
| Owner Key 키 쌍 | 차량 소유자의 인증 키 | 프로비저닝 시 |
| Friend Key 키 쌍 | 공유받은 사용자의 인증 키 | 키 공유 수락 시 |
| Ephemeral Key 키 쌍 | Standard Transaction에서 일회용 ECDH | 매 트랜잭션마다 |
인증서 체인
디바이스와 차량이 서로의 공개키를 신뢰하기 위한 구조다. 양쪽이 독립된 체인을 갖는다.
디바이스 측 차량 측
OEM Root CA (차량 생산 시 임베디드)
│ OEM Root CA
└─ OEM External CA │
│ (Apple root PK 포함, └─ Vehicle Identity Cert
│ OEM이 서명) (차량 SE에서 생성)
│
└─ Instance CA (SE에서 생성, OEM당 1개)
│
├─ Owner Key Cert
└─ Friend Key Cert(s)Instance CA가 핵심이다. OEM당 하나가 SE 안에 만들어진다. 이 CA 아래에 해당 OEM의 모든 디지털 키가 속한다.
- Instance CA의 subject name이 OEM 앱과 바인딩된다. BMW 앱으로 만든 Instance CA 아래에 Hyundai 키가 들어가지 않는다
- 디바이스를 초기화(iCloud 로그아웃, 공장 초기화)하면 Instance CA가 삭제된다. 해당 OEM의 모든 키가 자동 무효화된다
- 차량은 OEM Root CA의 공개키만 가지고 있으면 된다. 생산 시 임베디드되어 있다. Apple이나 Google의 루트 인증서를 차량에 넣을 필요 없다
프로비저닝 (최초 등록)
소유자가 차량과 폰을 처음 페어링하는 과정이다. 가장 중요한 단계이며, 여기서 신뢰 관계가 구축된다.
패스워드 전달
프로비저닝의 시작점은 일회용 패스워드다. 전달 방식이 세 가지 있다:
| 방식 | 흐름 | 사용 시점 |
|---|---|---|
| OEM 앱 | 서버가 앱에 패스워드 자동 전달 | 차량 구매 후 앱에서 등록 |
| 이메일 링크 | 딜러가 이메일로 링크 발송 → 앱이 패스워드 추출 | 원격 등록 |
| 차량 디스플레이 | 차량 화면에 코드 표시 → 사용자가 수동 입력 | 현장 등록, 위 방식 불가 시 |
SPAKE2+ → SCP03 → 키 생성
OEM 서버 OEM 앱 폰 SE 차량 NFC 리더
│ │ │ │
│─ 패스워드 ────▶│ │ │
│ │ │── NFC 태그 ─────────▶│
│ │ │ │
│ │ │◀── ① SPAKE2+ ───────▶│
│ │ │ (패스워드 기반 │
│ │ │ 키 교환) │
│ │ │ │
│ │ │ ② SCP03 보안 채널 │
│ │ │ 수립 완료 │
│ │ │ │
│ │ │◀── ③ 차량 인증서 ─────│
│ │ │ 차량 공개키 수신 │
│ │ │ │
│ │ │ ④ ECC 키 쌍 생성 │
│ │ │ (TRNG → P-256) │
│ │ │ │
│ │ │── ⑤ 디바이스 인증서 ──▶│
│ │ │ X.509 + 체인 │
│ │ │ │
│◀──── ⑥ 등록 데이터 (암호화) ──────│ │
│── ⑦ attestation 반환 ──────────▶│ │
│ │ │ Wallet에 키 활성화 │각 단계의 의미:
① SPAKE2+ — Password-Authenticated Key Exchange. 패스워드를 네트워크에 직접 전송하지 않는다. 양쪽이 패스워드를 입력으로 사용해 독립적으로 공유 비밀을 유도한다. 중간에 도청해도 패스워드를 복원할 수 없다. NIST P-256 커브를 사용한다.
② SCP03 — GlobalPlatform Secure Channel Protocol 03. SPAKE2+에서 유도한 키로 AES-128-CBC 암호화 + CMAC 무결성 채널을 수립한다. 이후 모든 데이터가 이 채널로 보호된다.
③ 차량 인증서 — 차량 SE가 자신의 공개키를 X.509 인증서로 전달한다. 폰은 OEM Root CA로 검증한다.
④ 키 생성 — 폰 SE가 TRNG → P-256으로 Owner Key 쌍을 생성한다. 개인키는 SE 안에 남는다.
⑤ 디바이스 인증서 — 생성된 공개키를 Instance CA가 서명해 X.509 인증서 체인으로 차량에 전달한다. 차량은 OEM Root CA → External CA → Instance CA → Owner Key 순서로 체인을 검증한다.
⑥⑦ 서버 등록 — 등록 데이터가 OEM 서버에 암호화 전달된다. 키 추적(KTS: Key Tracking Server) 용도다. Apple/Google 서버는 이 데이터를 복호화할 수 없다. OEM만 가능하다.
키 공유
소유자가 다른 사람에게 디지털 키를 공유하는 과정이다. 핵심은 소유자의 SE가 상대방의 공개키에 서명하는 것이다.
소유자 폰 SE 릴레이 서버 친구 폰 SE 차량
│ │ │ │
│── ① 초대 URL ────────│─────────────────▶│ │
│ (iMessage, 이메일 등) │ │ │
│ │ │ │
│ │◀─ ② 키 생성 요청 ─│ │
│ │ (암호화된 mailbox) │ │
│ │ │ │
│ │ ③ 친구 SE에서 │ │
│ │ Friend Key 생성 │ │
│ │ │ │
│◀─ ④ 인증서 체인 ──────│ │ │
│ │ │ │
│ ⑤ root.PK로 체인 검증│ │ │
│ ⑥ 친구 공개키에 서명 │ │ │
│ │ │ │
│── ⑦ 서명 + 권한 ─────│─────────────────▶│ │
│ (attestation) │ │ │
│ │ │ │
│ │ │── ⑧ 첫 NFC ──▶│
│ │ │ attestation │
│ │ │ 제시 │ ⑨ 소유자 서명 검증
│ │ │ │ → 키 등록 완료릴레이 서버의 역할: 소유자와 친구가 동시에 온라인일 필요가 없다. 프라이버시 보호 mailbox에 암호화된 데이터를 저장한다. Apple/Google 서버는 mailbox의 내용을 복호화할 수 없다.
⑤ 체인 검증: 소유자의 SE에 내장된 root.PK로 친구의 인증서 체인을 검증한다. 친구의 키가 정당한 SE에서 생성되었는지 확인하는 것이다.
⑥ 서명에 포함되는 정보:
| 필드 | 내용 |
|---|---|
| 친구 공개키 | 서명 대상 |
| 권한 등급 | Owner / Driver / Driver(제한) / Access Only |
| 유효 기간 | 시작~종료 시각 (선택) |
| 제한 조건 | 속도 제한, 지오펜스 등 (선택) |
⑧ 첫 사용 시 검증: 친구가 차량에 처음 NFC 태그할 때, 차량은 Fast Transaction 대신 Standard Transaction을 수행하고 추가로 attestation을 읽는다. 소유자의 서명을 검증해 친구 키를 신뢰 목록에 등록한다. 이후부터는 Fast Transaction으로 동작한다.
공유의 제한: 친구는 다시 공유할 수 없다. 소유자의 개인키로 서명해야 하는데 친구는 소유자의 개인키가 없다. 구조적으로 불가능하다.
키 취소: Termination vs Suspension
키를 무효화하는 방법은 두 가지다.
| Termination (종료) | Suspension (정지) | |
|---|---|---|
| 성격 | 영구적 | 임시적 |
| 복구 | 불가. 새로 공유해야 한다 | Resume으로 복원 가능 |
| 사용 시점 | 키를 완전히 회수할 때 | 폰 분실 시 일시 정지 |
Termination 흐름
요청자 폰 SE OEM 서버 차량 SE
│ │ │
│── 취소 요청 ──────────▶│ │
│ (device.SK로 서명) │ │
│ │── 취소 명령 ───────▶│
│ │ │ 신뢰 목록에서 제거
│ │ │
│ SE에서 키 삭제 │ │
│ termination attestation│ │
│ 생성 (삭제 증명) │ │
│── attestation ────────▶│ │
│ │ 서버에서도 삭제 │취소를 요청할 수 있는 주체:
- 키 보유자 본인: 자기 디바이스에서 직접 삭제
- 소유자: 다른 사람에게 공유한 키를 원격 취소
- 차량 내: 차량 디스플레이에서 등록된 키 관리
- OEM 서버: 원격 취소 명령
Termination attestation: SE가 키를 삭제한 후 생성하는 암호화 서명된 증명서다. “이 키가 이 시점에 삭제되었다”는 것을 암호학적으로 증명한다. OEM 서버가 이 attestation을 수신해야 삭제가 완료된 것으로 처리한다.
Suspension (정지)
iPhone의 Lost Mode가 대표적이다. iCloud에서 디바이스를 분실 처리하면:
- SE의 CCC applet이 정지된다
- 모든 NFC/BLE 트랜잭션이 거부된다
- 폰을 찾으면 Lost Mode를 해제해 applet을 재활성화한다
- 키를 새로 만들 필요 없다. 기존 키가 그대로 유효하다
기기 초기화 시 자동 무효화
사용자가 iPhone을 초기화하거나 iCloud에서 로그아웃하면:
- Instance CA가 SE에서 삭제된다
- Instance CA 아래의 모든 키(Owner, Friend)가 자동 무효화된다
- 차량은 다음 인증 시도에서 인증서 체인 검증이 실패하므로 거부한다
- 새 기기에서 프로비저닝을 다시 수행해야 한다
키 라이프사이클 상태 전이
┌──────────────────────────┐
│ │
프로비저닝 ──────▶ Active ──── Suspend ────▶ Suspended
│ (Lost Mode) │
│ │
│ Resume ◀─────────┘
│
│── Terminate ──▶ Terminated
│ │
│ └─▶ attestation 생성
│
└── 기기 초기화 ──▶ Instance CA 삭제
(모든 키 무효화)Active 상태에서 가능한 동작:
- NFC Standard/Fast Transaction
- BLE 상호 인증
- UWB 세션키 유도
- 키 공유 (Owner만)
메모
- SE의 개인키를 읽는 API는 존재하지 않는다. 백업도 불가능하다. 기기를 잃으면 키도 잃는다. 이것이 의도된 설계다
- SPAKE2+는 패스워드를 직접 전송하지 않는다. 오프라인 사전 공격에도 내성이 있다. 일반 Diffie-Hellman과 달리 MITM 공격을 패스워드로 방어한다
- Instance CA가 OEM당 1개인 이유: 한 OEM의 키 취소가 다른 OEM의 키에 영향을 주지 않는다. BMW 키를 삭제해도 Hyundai 키는 유지된다
- Android에서 StrongBox SE가 없으면 TEE로 폴백한다. TEE는 side-channel 공격에 취약하므로 키 유효 기간을 24시간으로 제한하고 서버 갱신을 요구하는 식으로 보완한다
- Termination attestation이 없으면 OEM 서버는 키가 정말 삭제되었는지 알 수 없다. 악의적 사용자가 “삭제했다”고 거짓말할 수 있기 때문에 SE가 암호학적 증명을 제공한다
- SDV에서 디지털 키 구현 구조에서 NFC 인증 프로토콜(Standard/Fast Transaction)과 키 권한 등급의 상세를 다룬다