SDV에서 디지털 키 구현 구조

IoTBLEUWBNFC

디지털 키는 스마트폰으로 차량을 잠금 해제하고 시동을 거는 기술이다. CCC(Car Connectivity Consortium)가 표준을 정의하며, Apple, Google, BMW, Hyundai 등이 참여한다.

CCC 표준 버전

버전연도기술핵심
Release 2.02020NFC탭으로 잠금해제/시동
Release 3.02021NFC + BLE + UWB핸즈프리 패시브 엔트리. UWB 정밀 측위
Release 4.02025NFC + BLE + UWBiOS ↔ Android 크로스 플랫폼 키 공유

Release 3.0부터 NFC, BLE, UWB 세 가지 라디오를 함께 사용한다. 각각의 역할이 다르다.

세 가지 라디오의 역할

라디오역할언제 사용하는가
NFC인증 + 시동폰을 리더에 태그할 때. 배터리 소진 시 백업
BLE근접 감지 + 인증 채널차량 접근 시 자동 감지 (10~30m)
UWB정밀 위치 측정BLE 인증 후 위치 기반 잠금해제

BLE는 “누가 가까이 왔는가”를 감지하고, UWB는 “정확히 어디에 있는가”를 측정한다. NFC는 물리 접촉이 필요한 상황(시동, 배터리 부족)의 폴백이다.

패시브 엔트리 동작 흐름

사용자가 폰을 꺼내지 않고 차에 다가가면 자동으로 잠금이 해제되는 과정이다.

폰 (주머니)              차량                Secure Element
    │                     │ BLE 광고 중            │
    │── ① BLE 감지 ──────▶│                        │
    │── ② BLE 인증 ──────▶│                        │
    │                     │     ③ UWB 레인징 키 유도 │
    │── ④ UWB 측위 시작 ──▶│                        │
    │                     │                        │
    │                     │ Welcome (5~10m) → 조명  │
    │                     │ Unlock  (1~2m)  → 해제  │
    │                     │ Cabin   (실내)  → 시동  │

UWB 가상 존

UWB 앵커 3~4개가 차량 주변에 배치되어 폰의 3D 위치를 추적한다. 위치에 따라 차량이 다른 동작을 수행한다.

거리동작
Welcome5~10m웰컴 라이트, 공조 사전 작동
Unlock1~2m (문 근처)문 잠금 해제
Cabin실내시동 버튼 활성화

“문 근처 1m”와 “실내”를 구분해야 하므로 cm 단위 정밀도가 필요하다. BLE RSSI(1~5m 오차)로는 불가능하고 UWB ToF(10~30cm 오차)가 필요한 이유다.

UWB가 릴레이 공격을 막는 원리

릴레이 공격은 두 명의 공격자가 중계 장비로 폰과 차량 사이의 신호를 전달해, 멀리 있는 폰이 가까이 있는 것처럼 속이는 공격이다.

BLE (RSSI)UWB (ToF)
측정 대상신호 세기비행 시간
정밀도1~5m10~30cm
릴레이 공격신호를 증폭하면 RSSI가 정상으로 보임중계 시 지연 발생 → 거리가 늘어남
PHY 보안없음STS (AES-128 기반 타임스탬프 시퀀스)

신호 세기는 속일 수 있지만, 빛의 속도는 속일 수 없다. 어떤 중계 장치라도 전파 지연을 추가하며, UWB ToF 측정은 이를 “거리 증가”로 감지한다.

IEEE 802.15.4z STS

UWB 레인징 패킷에는 **STS(Scrambled Timestamp Sequence)**가 포함된다. AES-128 카운터 모드로 생성된 의사난수 시퀀스로, 키를 모르면 예측하거나 재생할 수 없다. 레인징 키는 BLE 인증 과정에서 Secure Element가 유도하며, 최대 12시간 유효하다.

보안 구조

Secure Element (SE)

디바이스와 차량 양쪽에 하드웨어 Secure Element가 있다. SE는 독립된 프로세서와 자체 OS(JavaCard/JCOP)를 가진 칩으로, 메인 프로세서와 물리적으로 분리되어 있다.

Secure ElementTEE (Trusted Execution Environment)
하드웨어별도 칩메인 SoC 내 격리 영역
OS 침해 시영향 없음. 독립 실행같은 SoC이므로 side-channel 위험
인증Common Criteria 인증제조사 자체 검증
물리 공격tamper-resistant (전압/온도/레이저 방어)보호 없음

Apple은 SE만 사용한다. Google은 StrongBox(SE)가 있으면 사용하고, 없으면 TEE로 폴백한다.

SE가 수행하는 작업:

  • ECC 키 쌍 생성 및 저장 (개인키는 SE 밖으로 나오지 않는다)
  • NFC 트랜잭션의 챌린지-응답 서명
  • UWB 레인징 키 유도 (세션당 생성, 최대 12시간 유효)
  • 키 공유 시 상대방 공개키 서명

차량 측 SE (예: NXP NCJ38A)도 동일한 역할을 한다. 차량의 ECC 키 쌍을 저장하고, 디바이스 인증 시 챌린지에 서명한다. Zone Controller의 MCU와 SPI로 연결된다.

인증서 체인

디바이스와 차량이 각각 독립된 인증서 체인을 갖는다. 최초 등록(프로비저닝) 시 공개키를 교환해 상호 신뢰를 구축한다.

디바이스 측                         차량 측
Apple/Google Root CA                OEM Root CA
  └─ Instance CA (SE에서 생성)        └─ OEM External CA
      └─ Owner Key Cert                  └─ Vehicle Identity Cert
      └─ Friend Key Cert(s)

Instance CA는 SE 내부에서 생성된다. 디바이스를 초기화(iCloud 로그아웃, 기기 초기화)하면 Instance CA가 삭제되어 모든 키가 무효화된다.

NFC 인증 프로토콜

NFC 트랜잭션은 두 가지 모드가 있다.

Standard Transaction (시동, 최초 사용):

차량 NFC 리더                      폰 SE
   │                                │
   │── SELECT (CCC DK Applet) ────▶│
   │◀── 프로토콜 버전 ──────────────│
   │                                │
   │── AUTH0 (차량 ephemeral PK) ──▶│
   │◀── AUTH0 (디바이스 ephemeral PK)│
   │                                │
   │── AUTH1 (차량 서명) ──────────▶│  차량이 먼저 자신을 증명
   │◀── AUTH1 (디바이스 서명) ──────│  디바이스가 응답으로 증명
   │                                │
   │   상호 인증 완료                 │
   │   대칭키 유도 → Fast Transaction용│

양쪽이 각각 임시 ECC 키 쌍(ephemeral key)을 생성하고, 자신의 장기 개인키(long-term secret key)로 서명해 교환한다. 상호 인증(mutual authentication)이다. 차량도 자신이 정당한 차량임을 증명해야 한다.

Fast Transaction (문 잠금해제):

  • Standard에서 유도된 대칭키를 사용한다
  • 차량이 디바이스만 인증한다 (단방향)
  • 속도 최적화: 문 손잡이 터치 시 즉시 응답
  • 디바이스 식별자를 암호화해서 전송한다. 등록된 차량만 복호화할 수 있으므로, 제3자가 NFC 통신을 도청해도 어떤 폰인지 알 수 없다

Apple의 Express Mode가 이 Fast Transaction을 사용한다. Face ID/패스코드 없이 즉시 동작한다.

키 프로비저닝 (최초 등록)

OEM 서버        제조사 앱       폰 SE          차량 NFC
   │               │             │               │
   │─ 패스워드 ───▶│             │               │
   │               │             │─ NFC 태그 ───▶│
   │               │             │◀─ SPAKE2+ ───▶│ 암호화 채널 수립
   │               │             │◀─ 차량 인증서 ─│
   │               │             │ ECC 키 쌍 생성  │
   │               │             │─ 디바이스 인증서▶│
   │◀──── 등록 데이터 (암호화) ───│               │
   │─── attestation 반환 ───────▶│               │
   │               │             │ Wallet 활성화   │

SPAKE2+로 수립한 채널은 SCP03(Secure Channel Protocol 03) 위에서 동작한다. 패스워드를 직접 전송하지 않고 양쪽이 독립적으로 세션키를 유도한다.

프라이버시

  • Apple/Google 서버는 차량 사용 시점이나 위치를 알 수 없다. NFC 트랜잭션은 완전 오프라인으로 동작한다
  • Fast Transaction에서 디바이스 식별자는 등록된 차량에만 복호화 가능한 형태로 전송된다
  • OEM 추적 서버에 저장되는 식별자는 Instance CA 식별자(변경 가능)뿐이다. 디바이스 고유 ID가 아니다
  • 등록 데이터는 KTS(Key Tracking Server) 프라이버시 암호화 공개키로 암호화된다. Apple 서버는 복호화할 수 없다

키 공유

소유자가 다른 사람에게 키를 공유할 수 있다. 소유자의 SE가 상대방의 공개키에 서명해 인증 체인을 구성한다.

소유자 폰                    친구 폰                  차량
   │                           │                      │
   │── 초대 (Messages) ──────▶│                      │
   │                           │ 새 키 생성 (SE)       │
   │◀── 인증서 체인 반환 ──────│                      │
   │ 소유자 개인키로 서명        │                      │
   │── 서명된 attestation ───▶│                      │
   │                           │── 첫 NFC 트랜잭션 ──▶│
   │                           │   attestation 제시    │ 소유자 서명 검증
   │                           │                      │ 키 등록 완료

차량은 소유자의 서명을 검증해 친구 키를 수락한다. 오프라인에서도 동작한다.

권한가능한 동작
Owner전체 제어 + 키 공유 + 키 취소
Driver잠금해제 + 시동. 공유 불가
Driver (제한)속도 제한, 지오펜싱 등 제약 적용
Access Only입장만 가능. 시동 불가

받은 사람은 다시 공유할 수 없다. 소유자만 키를 발행하고 취소할 수 있다.

키 취소

  • 소유자가 앱 또는 차량 UI에서 키를 취소하면 즉시 무효화된다
  • 오프라인 상태에서도 동작한다. SE의 secure mailbox에 취소 토큰이 저장되어 있다
  • iPhone 분실 시 iCloud의 Lost Mode로 SE 앱렛을 일시 정지시킬 수 있다
  • 기기 초기화 시 Instance CA가 삭제되어 해당 기기의 모든 키가 자동 무효화된다

SDV에서의 변화

전통 아키텍처에서 디지털 키는 전용 ECU에 하드와이어링된 단독 시스템이다. SDV에서는 소프트웨어 서비스가 된다.

┌─ Central HPC (AUTOSAR Adaptive / Linux) ─────────────────────┐
│                                                               │
│  Digital Key Service ──SOME/IP──▶ Body Control Service        │
│    - 인증                         - 문 잠금/해제              │
│    - 위치 판정                     - 웰컴 라이트              │
│                                                               │
│  Digital Key Service ──SOME/IP──▶ User Profile Service        │
│                                   - 시트/미러 프리셋 로드     │
│                                                               │
│  Digital Key Service ──SOME/IP──▶ Powertrain Service          │
│                                   - 이모빌라이저 해제         │
└───────────────────────────────────────────────────────────────┘
       │ Automotive Ethernet

┌─ Zone Controller (AUTOSAR Classic) ──────────────────────────┐
│  NFC/BLE/UWB 라디오 드라이버 + Secure Element (NCJ38A)       │
└──────────────────────────────────────────────────────────────┘

Digital Key가 서비스로 분리되면서 생기는 차이:

  • OTA 업데이트: 보안 패치나 프로토콜 업그레이드를 하드웨어 교체 없이 배포
  • 서비스 조합: 키 인증 결과를 시트/공조/미러 프리셋 로딩에 연결
  • 동적 키 관리: 렌터카, 카셰어링에서 키를 실시간 발급/회수
  • API 노출: 서드파티 앱(카셰어링, 발렛)이 차량 API를 통해 키를 관리

하드웨어 보안(SE)은 Zone Controller에 남아 있으므로, 소프트웨어 서비스화가 보안 수준을 낮추지는 않는다.

메모

  • NFC는 iPhone 배터리가 거의 없을 때도 동작한다(Power Reserve 모드). UWB/BLE는 배터리가 필요하므로, NFC 백업은 필수다
  • BLE만으로 패시브 엔트리를 구현하면(Tesla 초기 모델) 릴레이 공격에 취약하다. UWB 없이는 정밀 거리 검증이 불가능하다
  • Bluetooth 6.0의 Channel Sounding이 BLE로 10cm 정밀도를 달성할 수 있다고 하지만, 멀티패스 환경에서의 성능은 UWB보다 열위다
  • CCC 4.0부터 iOS ↔ Android 간 키 공유가 표준화되었다. 이전에는 같은 플랫폼끼리만 공유 가능했다
  • 차량 측 SE(예: NXP NCJ38A)와 디바이스 측 SE는 독립적이다. 양쪽 SE가 각각 키를 생성하고, 공개키만 교환한다