# 독일 eIDAS 전자신원 지갑, Apple·Google 계정 기반 기기 보안 검증 구조 > Clean Markdown view of GeekNews topic #28229. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=28229](https://news.hada.io/topic?id=28229) - GeekNews Markdown: [https://news.hada.io/topic/28229.md](https://news.hada.io/topic/28229.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-04-05T23:33:21+09:00 - Updated: 2026-04-05T23:33:21+09:00 - Original source: [bmi.usercontent.opencode.de](https://bmi.usercontent.opencode.de/eudi-wallet/wallet-development-documentation-public/latest/architecture-concept/06-mobile-devices/02-mdvm/) - Points: 1 - Comments: 1 ## Topic Body - 독일 **National EUDI Wallet**은 모바일 기기의 **보안 취약점 관리(MDVM)** 체계를 통해 전자 신원 인증의 무결성을 유지함 - MDVM은 **운영체제와 하드웨어 키 저장소(HKS)** 의 취약점을 탐지하고, 위험이 높을 경우 **인증 키 사용을 차단**함 - Android에서는 **Google Play Integrity API**와 **KeyAttestation**, iOS에서는 **Apple DeviceCheck·AppAttest**를 이용해 기기 무결성을 검증함 - 이러한 구조로 인해 **전자신원 기능 사용 시 Apple 또는 Google 계정 기반 검증 절차**가 필수적으로 작동함 - 전체 시스템은 **공격자에 의한 키 복제·오용 방지**와 **높은 보증 수준의 eID 인증 유지**를 목표로 설계됨 --- ### 모바일 기기 취약점 관리 개념 (Mobile Device Vulnerability Management, MDVM) - **MDVM**은 독일 **National EUDI Wallet** 아키텍처 내에서 사용자 기기의 보안 취약점을 지속적으로 감시하고 인증 수단의 무결성을 유지하는 체계 - **HKS(하드웨어 키 저장소)** 및 **운영체제(OS)** 의 알려진 취약점을 탐지해, 공격 위험이 높은 경우 **RWSCA/RWSCD 키 사용을 차단** - 이를 통해 **전자 신원 확인(eID)** 과정에서 높은 보증 수준을 유지하고, **공격자에 의한 키 복제·오용을 방지** - MDVM은 기기 및 앱의 보안 상태 검증, 기기 클래스 식별, 취약점 검증, 사용 결정의 네 가지 기능으로 구성 --- ### 동기 - Wallet Unit은 **공개/비공개 키 쌍**을 통해 여러 신원 수단(PID 등)에 연결되는 인증 수단을 제공 - PID 발급 시 **WB(Wallet Backend)** 는 **PP(Provider Party)** 에 대해 해당 키가 일정 수준의 공격 저항성을 갖춘 인증 수단에 의해 제어됨을 **OpenID4VCI Key Attestation**으로 확인 - **ISO/IEC 18045** 및 **EU 규정 2015/1502**에 따라 높은 보증 수준의 전자 신원 확인에는 강력한 인증 수단이 요구됨 - 인증 수단은 두 가지 보증을 제공 1. **키 저장소 복제 및 변조 방지** 2. **사용자 인증 메커니즘 공격 방지** - 첫 번째 보증은 **HSM 기반 RWSCD**로 구현 가능하며, 사용자 기기와 독립적으로 달성 - 두 번째 보증은 **사용자 기기 보안**에 의존하며, **소유 요소(HKS 기반)** 와 **지식 요소(비밀번호 등)** 로 구성 - 모바일 기기의 HKS나 OS는 사전 취약점 분석·인증이 현실적으로 불가능하며, 과거에도 다수의 취약점이 보고됨 - 따라서 **운영 중 취약점 모니터링 체계(MDVM)** 를 통해 공격 가능성을 줄이고, 보안이 불충분한 기기에서는 **RWSCA/RWSCD 키 사용을 차단** --- ### MDVM의 주요 기능 | 기능 | 설명 | | --- | --- | | **기기/앱 보안 상태 검증** | 기기 및 Wallet 앱의 무결성과 진위 여부를 검증하며, 플랫폼 보안 기능과 **RASP(Runtime Application Self-Protection)** 을 활용 | | **기기 클래스 식별** | 기기 모델, OS 버전 및 패치 수준, HKS 정보를 검증된 방식으로 식별 | | **기기 클래스별 취약점 검증** | OS 및 HKS의 최신 취약점 정보를 확인 | | **기기/앱 사용 결정** | 보안 상태와 취약점 정보를 기반으로, 보안이 불충분한 기기에서는 **OpenID4VCI Key Attestation** 확인 및 **RWSCD 키 사용을 차단** | --- ### 수집 신호 - 수집된 신호는 **위협 대응**, **기기 클래스 식별**, **합리성 검증(plausibility check)** 에 사용 - 주요 신호 출처: **KeyAttestation**, **PlayIntegrity**, **DeviceCheck**, **RASP**, **LPADB**, **DCVDB** - ## 개요 | 신호 출처 | 대응 위협 | 시너지 | 비고 | | --- | --- | --- | --- | | **KeyAttestation** | 루팅, 부트로더 해제, 커스텀 ROM, 앱 변조, 복제, 에뮬레이션, 리플레이 공격 등 | LPADB, RASP | DCVDB 입력으로 사용 | | **PlayIntegrity** | 앱 변조, 리플레이, 루팅, 커스텀 ROM, 구글 백엔드 기반 MDVM 판정, 자격 증명 탈취 도구, 오버레이 공격 등 | KeyAttestation, RASP | 부트로더 상태 확인 필요 | | **iOS DeviceCheck** | 리플레이, 인증서 변조, 프록시 공격, 앱 변조 | RASP | 기기 무결성 보증 부족 | | **LPADB** | 공개된 KeyAttestation 키를 이용한 루팅 은폐 | KeyAttestation | - | | **DCVDB** | 알려진 취약점 기반의 불안전한 기기 탐지 | KeyAttestation, RASP | 기기 클래스 식별 정확도 중요 | | **RASP** | 앱 후킹, 디버깅, 루팅, 에뮬레이션 탐지 | - | 실행 중 무결성 지속 감시 | - --- ### Android KeyAttestation 신호 - **HKS 기반 하드웨어 검증 정보**를 통해 기기 모델, OS 버전, 패치 수준, 부트로더 상태 등을 식별 - 주요 신호 항목 - **SecurityLevel**: HKS 유형 식별 (TrustedEnvironment, StrongBox) - **attestationIdModel/Product/Device**: 기기 모델 식별 - **osVersion / osPatchLevel**: OS 버전 및 보안 패치 수준 - **RootOfTrust**: 부트로더 및 Verified Boot 상태 - **AttestationApplicationId**: 앱 패키지명, 버전, 서명 인증서 해시 - **Google의 Key-Attestation 인증서 폐기 목록**은 업데이트가 느려 **공개 유출된 키**가 여전히 사용 가능함 - 일부 기기에서 특정 식별 필드가 누락될 수 있어 세 필드를 모두 평가해야 함 --- ### Android PlayIntegrity Verdict 신호 - **Google Play Integrity API**를 통해 앱 및 기기 무결성을 검증 - 주요 신호 항목 - **appRecognitionVerdict**: 앱이 원본인지 여부 - **deviceRecognitionVerdict**: 기기 신뢰 수준 (예: MEETS_STRONG_INTEGRITY) - **appLicensingVerdict**: PlayStore 설치 여부 - **playProtectVerdict**: Play Protect 위험 평가 - **MEETS_STRONG_INTEGRITY**는 최근 12개월 내 보안 패치 적용을 요구 - 신호 신뢰 확보를 위해 **서명 검증 및 복호화** 필요 - Google 백엔드의 내부 평가 방식은 공개되지 않음 --- ### Android RASP - 구체적 솔루션은 아직 확정되지 않았으며, 요구 기능 정의 단계 - 탐지 기능 - **App Hooking/Debugging**: 동적 조작 탐지 (Frida, Xposed 등) - **App Repackaging/Tampering**: 앱 변조 및 재서명 탐지 - **UD Rooting/Emulation**: 루팅, 가상화, 자동화 환경 탐지 - **RASP는 실행 중 무결성 감시**를 제공하며, **Google의 폐기 목록과 별도의 블록리스트**를 유지해 유출된 키 기반 공격을 방지 --- ### iOS DCDeviceCheck.AppAttest Attestation - **Secure Enclave**와 **Apple 서버**를 통한 앱 인증 구조 - 주요 신호 - **attestationObject**: App Attest 키가 Secure Enclave에서 생성되었음을 증명 - **credentialId**: App Attest 키 식별자 - **RP ID**: 앱의 App ID prefix + Bundle ID - **Apple의 위험 지표(receipt metric)** 는 프록시 공격 탐지에 활용 가능하나, 명확한 기준 부재 및 **Apple 서버와의 통신으로 인한 개인정보 노출 위험** 존재 - iOS는 **기기 모델, OS 버전/패치 수준의 하드웨어 기반 정보 제공 불가**, OS 질의로만 확인 가능 --- ### iOS DCDeviceCheck.AppAttest Assertions - **App Attest 키**로 생성된 서명 기반 검증 구조 - 주요 신호 - **assertionObject**: 챌린지에 대한 서명 포함 - **keyId**: App Attest 키 식별자 - **counter**: 서명 횟수, 단조 증가해야 함 - **카운터 값의 급격한 증가**는 프록시 공격 가능성, **감소는 리플레이 공격** 가능성 시사 --- ### iOS RASP - Android와 유사한 탐지 기능 요구 - **App Hooking/Debugging**, **App Repackaging**, **App Tampering**, **UD Rooting**, **UD Emulation** - Apple의 **App Sandbox**, **Code Signing**, **System Integrity Protection**은 설치 시점 보호만 제공하며, **루팅·후킹·런타임 조작 탐지 기능은 없음** - RASP는 실행 중 무결성 감시를 통해 이를 보완 - Apple 문서에 따르면 **App Attest**는 “정상 기기에서 실행되는 변조 앱은 유효한 assertion을 생성할 수 없다”고 명시 --- ### 결론 - MDVM은 **기기 보안 상태를 실시간 평가**하고 **공격 가능성이 높은 환경에서 인증 키 사용을 차단**함으로써 **전자 신원 인증 체계의 신뢰성 유지** - Android와 iOS 모두 **플랫폼 보안 기능과 RASP 기반 동적 보호**를 결합해 **기기 무결성 검증 체계**를 구성 - **Google 및 Apple의 백엔드 검증 체계에 대한 의존성**이 존재하며, **공개되지 않은 내부 평가 방식**은 잠재적 불확실성 요인으로 남음 ## Comments ### Comment 54703 - Author: neo - Created: 2026-04-05T23:33:21+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47644406) - eIDAS 2.0 명세는 특정 하드웨어를 요구하지 않음 단지 **검증 가능한 자격 증명**과 암호학적으로 서명된 증명서들을 저장하는 구조임 독일 구현팀이 “사용자가 Wallet Unit의 진위를 검증할 수 있는 메커니즘을 구현해야 한다”는 조항을 회피하려는 **게으름**처럼 보임 관련 문서는 [EUDI Architecture and Reference Framework](https://eudi.dev/latest/architecture-and-reference-framework)에서 확인 가능함 - 참고 구현체를 보면, 유지보수자들이 **Google 의존성**을 제거하지 않으려 함 이유가 명확하지 않은데, 이유 없이 지속되는 건 결국 이유가 있는 법임 [GitHub 저장소](https://github.com/eu-digital-identity-wallet/eudi-app-android) 참고 - 5.4절의 Attestation Rulebooks와 Attestation Schemes 부분을 보면 관련 규칙이 명시되어 있음 - 독일 구현자로서, eIDAS 시행령에 따라 **attestation 메커니즘**을 사용해야 함 이는 운영체제의 지원 없이는 작동하지 않음 현재 Google/Android에 한정된 것은 최선이 아님을 알고 있으며, GrapheneOS 등 다른 OS 지원도 계획 중임 단지 지금은 **우선순위의 문제**일 뿐, 문제를 인식하지 못하는 것은 아님 - 두 개의 미국 기업 제품에 의존하는 것은 “좋지 않다” 수준이 아니라 **심각한 문제**임 계정 잠금 사례가 많고, 이런 의존성은 오히려 하지 않는 편이 나음 - 접근성 및 eIDAS 정신 위반 측면에서 **불법적 요소**도 있음 결국 모든 시민이 Google·Apple의 약관에 종속되며, 계정 정지 시 eID 서비스 접근이 불가능해짐 기술적으로 대안이 존재하므로, 그런 해결책을 찾는 것이 당신의 **책임**임 - 독일 시민으로서 묻고 싶음. 모든 시민에게 작동하지 않을 걸 알면서 왜 진행하는가? 나는 Google Play 없는 AOSP 기반 Android에서 Ubuntu Touch로 옮겼고, 향후 postmarketOS로 전환할 예정임 - Google 계정 접근을 잃는 건 너무 쉬움. 복구도 불가능함 이런 상황과 **지정학적 리스크**를 고려하면, 특정 기업 의존은 정당화될 수 없음 “임시방편은 가장 영구적인 해결책”이라는 개발자 경험상 교훈도 있음 - eIDAS 1의 **Mobile-ID**(SIM 기반)나 **Smart-ID**(서버 측 키 관리)로 이미 해결된 문제를 왜 굳이 Wallet 모델로 바꾸는지 의문임. 두 미국 기업의 백엔드에 의존할 이유가 없음 - **attestation 자체를 폐지**해야 함 앱이 어떤 기기에서 실행되는지 알아서는 안 됨 사용자가 자신의 기기를 스스로 보호하면 되고, 개발자는 권장사항만 제시하면 충분함 GrapheneOS, 루팅, 에뮬레이터, Linux 호환 계층 등 어떤 환경에서도 실행 가능해야 함 - 맞음, 내 기기니까 내가 원하는 대로 써야 함 앱이 미국 빅테크의 “인증” 여부를 자동으로 검사하는 건 불필요함 - **기기 신뢰** 개념 자체가 허상임 루팅된 콘솔과 폰의 역사를 보면, 어떤 보안도 완벽하지 않음 사용자가 원하면 자신의 신원을 기기에 묶을 수 있도록 **선택적 옵션**으로 두는 게 바람직함 - 물론 루팅이나 수정은 자유지만, 그 결과도 감수해야 함 앱이 자체 무결성을 검증할 수 없으면 일부 기능은 **보안상 불가능**함 물리적 신분증도 형태나 크기 등 제한이 있듯, 일정한 제약은 필요함 - 현대 컴퓨팅의 **원죄**는 ‘보안 요소’가 사용자보다 제조사를 위해 설계된 것임 NGSCB 시절 이런 요소를 법적으로 금지하지 않은 게 문제의 시작이었음 - 만약 Google/Apple 계정을 잃는다면? 국제형사재판소 판사처럼 제재 대상이 되면 eIDAS 접근이 불가능해짐 유럽 사회가 여전히 미국 기업 의존 구조를 유지하는 건 **모순적 현실**임 - 유명 인사가 아니더라도, 자동화된 계정 정지로 사회적 배제 상태가 될 수 있음 두 외국 기업이 **감시와 통제 권한**을 가지는 건 위험함 - “유럽의 수도가 워싱턴에 있다면” 이런 일은 당연한 일일지도 모름 - 그럼 Waymo도 탈 수 없게 됨 - 이런 정책에 대한 **대중의 반대가 적다는 게 충격적**임 부모로서 아이들의 인터넷 사용을 통제할 필요는 이해하지만, 결국 부모가 해야 할 일을 국가가 대신하며 **자유와 프라이버시**를 잃고 있음 - 대부분의 사람들은 이게 자신의 삶에 어떤 영향을 미치는지 **추상적으로만** 이해함 “정부가 내 WhatsApp 메시지를 읽는다”처럼 구체적 위협이 아니면 반응하지 않음 - 독일은 속도 제한 논쟁 같은 **소모적 이슈**로 관심이 분산됨 정치권은 이런 혼란을 이용해 본질적 문제를 가림 - 오히려 많은 부모들은 온라인 접근 제한에 찬성함 아이들이 거대 기업의 **주의력 착취**로부터 보호받길 원함 현실 세계에 연령 제한이 있듯, 온라인도 예외일 수 없음 - 사람들은 자신만의 **필터 버블**에 갇혀 이런 이슈를 듣지도 못함 민주주의의 미래를 생각하면 매우 우려스러움 - EU는 사실상 **로비 플랫폼**으로 작동함 시민 로비는 가능하지만 비용과 조율이 필요해 대기업이 주도함 최근 EU 디지털 인프라가 해커 그룹에 침해당한 사건도 있었음 [관련 기사](https://cyberalert.com.pl/articles/shinyhunters-eu-europa-br...) - 특정 하드웨어·소프트웨어 요구는 **비합리적**임 모든 시민이 원하는 컴퓨터를 사용해야 함 인증은 비밀번호나 키쌍만으로 충분하고, 원하면 **TOTP나 보안키**를 추가하면 됨 스마트폰 외의 컴퓨터도 존재한다는 사실을 잊은 듯함 - EU가 VISA·MasterCard 독립 결제 시스템을 만든다지만, 결국 **앱스토어 의존**임 Apple·Google 계정 없이는 디지털 유로 결제도 불가능함 정치인과 은행이 두세 단계 앞을 내다보지 못하는 게 놀라움 - EU 정책은 “사용자 자율적 위험 평가”가 아니라, 서비스 제공자가 사용자를 보호해야 한다는 방향으로 가고 있음 결과적으로 **지원 플랫폼 제한**이 불가피함 - “모든 컴퓨터에서 실행 가능해야 한다”는 건 비현실적임 법적으로 Apple II에서도 돌아가야 한다는 뜻은 아니니까 - 제재 대상자나 특정 그룹은 Play Store 접근이 불가능하므로 eIDAS 앱 설치 자체가 불가능할 수 있음 - 계정이 필요하다면 그렇겠지. 최근 **정치적 반대자 계정 삭제** 사례를 보면, 일부 당국에겐 오히려 반가운 일일 수도 있음 - 하지만 개인 키 보호가 핵심임 스마트카드 같은 **보안 장치**가 필요하므로, 완전히 개방된 환경은 위험함 “대체 Android를 쓰고 싶다”는 건 이해하지만, 그건 **비보안 환경**임을 알아야 함 - EU가 이런 시스템에 **얼마나 많은 예산을 낭비**할지 의문임 과연 누가 이걸 필요로 하는지 모르겠음 - **Self Sovereign Identity(SSI)** 만이 진정한 해결책임 개인의 신원이 어떤 기관이나 기업에 종속되어서는 안 됨 신원은 그저 ‘나 자신’이어야 함 Google ID나 Apple ID가 아닌, **자기 주권적 정체성**이 필요함 - 하지만 “나는 그냥 나다”는 건 현실적 신원 확인이 아님 술집에서 신분증 대신 그렇게 말할 수는 없음 사회적 계약 속에서 **기능적 신원 확인**은 필요함 - EU는 이미 2019년에 **ESSIF(European Self-Sovereign Identity Framework)** 를 만들었음 7년 전부터 인프라가 존재하는데, 정부가 무능하다고만 할 수는 없음 - “디지털 판 라이히스타크 방화 사건”이 일어날 때가 된 듯함 독일은 언제쯤 **역사를 반복하는 습관**을 멈출 것인지 묻고 싶음