휴대전화 기반 디지털 운전면허(mDL)를 통합하는 데 어려운 점은 신원 검증 API를 호출하는 데 있지 않다. 그 인터페이스 뒤에서 무슨 일이 일어나는지 이해하는 데 있다. 자격 증명은 어디에 저장되는가? 누가 기기 키를 보호하는가? 신뢰 인증서는 어떻게 관리되는가? 네트워크가 끊기거나 서비스 제공업체가 장애를 일으켰을 때 무엇이 계속 작동하는가? InfoQ에 게재된 이 글은 ISO/IEC 18013-5 표준에 따라 구축된 mDL 시스템의 아키텍처 구상을 제시하며, 제공업체, SDK, 지갑 플랫폼 또는 검증 서비스를 선택하는 기관을 대상으로 한다.
신원 증명과 자격 증명 발급의 분리
제안된 프레임워크는 신원 수명 주기에서 서로 다른 두 단계를 분리하는 것에서 시작한다. 신원 증명 단계에서 사용자는 실물 운전면허증 사진과 생체 인식 검증을 위한 동영상을 촬영한 뒤, 증거와 추출된 데이터를 검증 시스템으로 전송한다. 차량관리국과 같은 담당 기관은 이러한 증거를 자동 또는 수동으로 검토한 후 승인 또는 거부 결정을 내린다.
승인 후에는 프로비저닝 단계가 시작된다. 기기는 Secure Enclave 또는 보안 요소 내부에서 비대칭 키를 생성하고, 공개 키와 인증서, 신원 증명 절차 참조 정보를 발급 기관으로 전송한다. 발급 기관은 서명된 Mobile Security Object 내부에서 운전면허 데이터를 해당 키와 연결한 다음, 자격 증명 패키지를 암호화하여 하드웨어 지원 저장 공간에 보관하는 지갑으로 전송한다.
기관이 이러한 단계를 직접 수행해야 하는 것은 아니지만, 각 단계의 책임 주체와 그 결과로 생성되는 신뢰 결정을 소유하는 주체를 정해야 한다.
제공업체의 인터페이스 뒤에서 무엇을 점검해야 하는가?
이 글은 verifyCredential() 또는 requestPresentation()과 같은 기능을 호출하는 파일럿 경험의 성공만으로는 제공업체를 평가하기에 충분하지 않다고 본다. 점검은 다음과 같이 서로 연관된 여섯 가지 축을 포함해야 한다.
- 암호화 아키텍처: 키 생성 및 보호, 기기 인증, 알고리즘, 키 수명 주기.
- 신뢰 및 공개 키 인프라: 신뢰 앵커, Document Signer 인증서, 신뢰 목록 및 폐기 목록.
- 개인정보 보호와 데이터 최소화: 선택적 공개, 원격 측정, 프레젠테이션 데이터 보존, 거래 간 연결 위험.
- 오프라인 작동: 캐시된 자료, 오래된 폐기 상태, 네트워크 중단 중 시스템 동작.
- 상호운용성: ISO/IEC 18013-5 준수 및 독립적인 지갑과 검증자와 상호작용할 수 있는 능력.
- 운영 탄력성: 제공업체 장애의 영향, 자격 증명의 지속성, 복구 메커니즘 및 장애 처리.
암호화와 인증서는 구현 세부 사항이 아니다
이 글은 RFC 9180에 따른 Hybrid Public Key Encryption을 사용해 온라인 전송과 API 교환을 보호할 것을 제안하며, DHKEM(P-256, HKDF-SHA256), HKDF-SHA256, AES-128-GCM을 포함한 매개변수를 지정한다. 그러나 제시된 프레임워크에 따르면 암호화를 신뢰 모델과 분리된 기능으로 취급해서는 안 된다. 암호화가 어디에서 시작되고 끝나는지, 누가 키를 생성하고 보호하는지, 키를 어떻게 교체하는지, 제공업체의 신뢰 경계 안에 어떤 구성 요소가 있는지를 알아야 한다.
지갑 서버, 발급 플랫폼 및 검증 시스템 간 통신에도 명확한 인증서 구조를 통한 상호 TLS 인증이 필요하다. 이 글은 오프라인 하드웨어 보안 모듈에 저장된 신뢰 루트부터 단기 유효 Document Signer 인증서, mTLS 인증서, 기기 키 인증 인증서에 이르기까지 서로 다른 인증서 역할을 제시한다. 핵심 문제는 여전히 책임의 분배다. 어떤 인프라를 제공업체가 관리하는가? 어떤 인프라가 기관의 통제 아래 있는가? 어떤 신뢰 관계가 발급 기관의 통제에 남아 있는가?
서비스가 중단되면 실제로 무엇이 달라지는가?
설계는 검증 중 발생하는 동기식 작업, 예를 들어 NFC를 통한 데이터 교환이나 API를 통한 직접 검증과, 백그라운드에서 수행할 수 있는 비동기식 작업, 예를 들어 신원 증명 검토, 자격 증명 프로비저닝, 키 교체 및 신뢰 목록 동기화를 구분한다.
이러한 분리를 통해 정책이 허용하는 경우 기존 자격 증명을 제시하고 오프라인에서 검증할 수 있으며, 신뢰 목록 동기화나 폐기 업데이트는 나중으로 미룰 수 있다. 이 글은 네트워크 없이 제시 및 검증하기, 만료된 자격 증명, 오래된 폐기 목록, 기기 시계 편차, 연결 복구, 제공업체 장애 중 시스템 동작을 테스트할 것을 제안한다. 모든 검증에 백엔드 서비스 연결이 필요하다면, 높은 가용성을 제공하는 제공업체에 의존하더라도 단일 장애 지점이 될 수 있기 때문이다.
선택적 공개와 제공업체 종속 방지
필요한 데이터는 상황에 따라 다르다. 공항 검문소는 이름, 사진, 생년월일, 문서 번호 및 발급 기관을 요구할 수 있지만, 상점은 이름, 주소 또는 문서 번호 없이 사용자의 연령이 21세를 초과한다는 논리적 진술과 사진만으로 충분할 수 있다. 따라서 단일 시나리오로 제공업체를 테스트하는 것만으로는 부족하며, 기관의 정책과 실제 거래 유형을 기준으로 평가해야 한다.
이 글은 비즈니스 로직을 제공업체의 인프라와 독립적으로 유지할 것을 제안한다. 애플리케이션이 시스템 전반에 제공업체별 데이터 구조를 배포하는 대신, 21세 초과 증명을 요청하는 것과 같은 정책을 표현하도록 하는 방식이다. CBOR 시퀀싱, APDU 메시지 구성, 암호화 라이브러리 호출과 같은 세부 사항은 숨길 수 있지만, 신뢰 앵커, 발급 기관의 신원, 공개된 속성, 인증서 및 폐기 상태, 제공업체 의존성, 오프라인 작동 능력은 기관이 볼 수 있어야 한다.
certi.news의 시각
이 글이 강조하는 실질적인 변화는 mDL 평가를 SDK 기능 테스트에서 전체 신뢰 시스템 검토로 전환하는 것이다. 이러한 접근 방식은 보안, 신원 및 조달팀에 유용하다. 무엇을 구매할 수 있고 무엇이 기관의 거버넌스 아래 남아 있어야 하는지를 정의하기 때문이다. 지갑 구현, NFC 프로토콜 및 암호화 라이브러리는 구매할 수 있지만, 공개, 권한 부여 및 감사 정책과 키·인증서 관리, 개인정보 보호, 가용성 및 상호운용성 거버넌스는 구축해야 한다.
그러나 이 프레임워크만으로는 현지 규정 준수 요건이나 발급 기관과 검증자 간 거버넌스 모델과 같은 문제를 해결할 수 없다. 또한 시스템이 과도한 기록을 보존하거나 프레젠테이션 작업을 사용자와 연결한다면, 서명의 유효성을 보장하는 것만으로 개인정보 보호가 보장되지는 않는다. 따라서 추적 가능성, 개인정보를 보호하는 폐기, 제공업체 장애 발생 시 책임과 관련된 문제는 운영 환경으로 전환하기 전에 기관 및 규제 차원의 결정이 필요한 과제로 남는다.