▲

독일 eIDAS 전자신원 지갑, Apple·Google 계정 기반 기기 보안 검증 구조

 (bmi.usercontent.opencode.de)
1P by GN⁺ 5시간전 | ★ favorite | 댓글 1개
  • 독일 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의 백엔드 검증 체계에 대한 의존성이 존재하며, 공개되지 않은 내부 평가 방식은 잠재적 불확실성 요인으로 남음

함께 보면 좋은 글 β

▲
GN⁺ 5시간전  [-]
Hacker News 의견들

  • eIDAS 2.0 명세는 특정 하드웨어를 요구하지 않음
    단지 검증 가능한 자격 증명과 암호학적으로 서명된 증명서들을 저장하는 구조임
    독일 구현팀이 “사용자가 Wallet Unit의 진위를 검증할 수 있는 메커니즘을 구현해야 한다”는 조항을 회피하려는 게으름처럼 보임
    관련 문서는 EUDI Architecture and Reference Framework에서 확인 가능함

    • 참고 구현체를 보면, 유지보수자들이 Google 의존성을 제거하지 않으려 함
      이유가 명확하지 않은데, 이유 없이 지속되는 건 결국 이유가 있는 법임
      GitHub 저장소 참고
    • 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 디지털 인프라가 해커 그룹에 침해당한 사건도 있었음
      관련 기사

  • 특정 하드웨어·소프트웨어 요구는 비합리적임
    모든 시민이 원하는 컴퓨터를 사용해야 함
    인증은 비밀번호나 키쌍만으로 충분하고, 원하면 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년 전부터 인프라가 존재하는데, 정부가 무능하다고만 할 수는 없음

  • “디지털 판 라이히스타크 방화 사건”이 일어날 때가 된 듯함
    독일은 언제쯤 역사를 반복하는 습관을 멈출 것인지 묻고 싶음

답변달기