▲

독점 조력자로서의 하드웨어 증명

 (grapheneos.social)
2P by GN⁺ 9시간전 | ★ favorite | 댓글 2개
  • Apple과 Google은 하드웨어 기반 증명 사용을 확대하며 더 많은 서비스의 채택을 유도하고, 장기적으로 승인하지 않은 하드웨어와 OS 경쟁을 배제하는 구조를 강화함
  • Google Play Integrity API와 Apple App Attest API는 유사하게 동작하며, Play Integrity는 strong integrity에서 하드웨어 증명을 요구하고 device integrity에도 이를 단계적으로 요구하는 방향으로 가고 있음
  • Apple Privacy Pass, Google의 취소된 Web Environment Integrity, reCAPTCHA Mobile Verification은 증명 요구를 웹으로 가져오며, iOS 또는 인증된 Android 기기가 없으면 웹 서비스 접근이 차단될 수 있음
  • Play Integrity API는 GrapheneOS가 허용된 대상보다 더 안전하더라도 금지하고, 10년 동안 보안 패치가 없는 기기는 허용해 보안 명분보다 Google Mobile Services 라이선싱과 경쟁 배제 목적이 더 두드러짐
  • 정부와 은행 서비스가 App Attest와 Play Integrity 사용을 점점 더 요구하면서 Apple 기기 또는 Google 인증 Android 기기를 사실상 강제하고, Windows·데스크톱 Linux·FreeBSD 같은 환경의 웹 접근에도 영향을 줄 수 있음

웹으로 확장되는 증명 요구

  • Apple의 Privacy Pass는 자사 하드웨어에서 CAPTCHA 통과를 돕기 위해 하드웨어 증명을 웹으로 가져옴
  • 당시에는 Apple 하드웨어가 아닌 사용자를 차단할 사이트가 많지 않을 것이라는 이유로 무해하게 보는 사람이 많았음
  • Apple과 Google은 모두 더 광범위한 하드웨어 증명을 웹으로 가져올 가능성이 큼
  • 은행과 정부 서비스는 모바일 앱 사용을 점점 더 요구하며, 앱 안에서 증명을 사용해 Apple 또는 Google이 승인한 기기와 OS를 강제할 수 있음
  • Apple의 Privacy Pass, Google의 취소된 Web Environment Integrity, 그리고 reCAPTCHA Mobile Verification은 이러한 흐름을 웹으로 가져오고 있음
  • reCAPTCHA Mobile Verification에 대한 현재 보도는 그 영향과 의미를 제대로 다루지 못함
  • 이 방식은 특정 상황에서 reCAPTCHA를 통과하려면 인증된 스마트폰으로 QR을 스캔하도록 요구해, Windows, 데스크톱 Linux, OpenBSD 등에도 하드웨어 증명 요구를 가져옴
  • Google은 reCAPTCHA에 대한 통제권을 통해 iOS 또는 인증된 Android 기기가 있어야 웹의 막대한 부분을 사용할 수 있게 만들 위치에 있음
  • Google은 Android 인증 요구사항을 정의하며, 여기에는 Google Chrome 번들링 강제 등이 포함됨
  • reCAPTCHA Mobile Verification은 현재 GrapheneOS의 샌드박스된 Google Play와 함께 동작하지만, 하드웨어 증명이 없는 시스템에도 이를 쓰기 시작하기 위한 수단으로 존재함
  • 이 요구가 적용되면 iOS 또는 Android 기기가 없는 사람은 별도 조건 없이도 차단될 수 있음

Play Integrity와 GrapheneOS 배제

  • Google의 Play Integrity API는 GrapheneOS가 허용된 어떤 대상보다 훨씬 더 안전하더라도 GrapheneOS 사용을 금지함
  • Play Integrity API는 다른 대안도 금지하며, 이는 AOSP 기반 OS에만 해당하는 문제가 아님
  • FreeBSD 기반 모바일 OS를 사용해도 이 문제를 피할 수 없고, 더 많이 배제될 뿐임
  • Play Integrity API는 10년 동안 보안 패치가 없는 기기도 허용함
  • device integrity 수준은 스푸핑으로 우회할 수 있지만, Google은 대규모로 사용되기 시작하면 이를 상당히 잘 탐지하고 차단할 수 있음
  • strong integrity 수준을 우회하려면 TEE 또는 SE에서 유출된 키가 필요함
  • Play Integrity API는 매우 안전하지 않고 일시적으로 우회하기가 특별히 어렵지는 않음
  • 소프트웨어 검사를 스푸핑하는 프레임워크가 있고, 하드웨어 증명을 우회하기 위한 유출 키도 구매할 수 있음
  • 다만 우회는 점점 어려워지고 있으며, 유효 기간도 점점 더 짧아지는 중임
  • Play Integrity는 유용한 보안 기능을 제공하지 않지만, 경쟁을 배제하는 데는 매우 잘 작동함
  • Apple App Attest 또는 Google Play Integrity를 요구하는 서비스는 주로 Apple과 Google이 모바일 기기에서 복점을 유지하도록 돕고 있음
  • Play Integrity가 더 중요한 이유는 AOSP가 오픈소스이기 때문임
  • GrapheneOS는 하드웨어 증명으로 검증될 수 있으며, Google이 Play Integrity에서 GrapheneOS를 금지하는 이유는 Google Mobile Services를 라이선스하지 않고 반경쟁적 규칙을 따르지 않기 때문임
  • 해당 규칙은 한국 등에서 이미 불법으로 판단된 바 있음
  • 서비스는 임의의 하드웨어와 운영체제 사용을 금지해서는 안 됨
  • Google이 10년 동안 패치가 없는 기기는 허용하면서 훨씬 더 안전한 OS는 허용하지 않는다는 점에서 보안 명분은 성립하기 어려움
  • 이는 GMS 라이선싱을 통해 독점을 강제하기 위한 것임

정부·은행 서비스와 규제의 역할

  • 정부는 자체 서비스뿐 아니라 상업 서비스에도 Apple App Attest와 Google Play Integrity 사용을 점점 더 의무화하고 있음
  • EU는 디지털 결제, 신원 확인, 연령 확인 등에 이러한 요구사항을 적용하는 흐름을 주도하고 있음
  • 많은 EU 정부 앱은 이미 이러한 요구사항을 갖추고 있음
  • 정부가 Apple과 Google의 심각한 반경쟁 행위를 막는 대신, 자체 서비스를 통해 경쟁 배제에 직접 참여하고 있음
  • 사람들에게 Apple 기기 또는 Google 인증 Android 기기를 요구하는 것은 보안이 아니라 경쟁 제한임
  • 은행·정부 서비스 접근이나 특정 reCAPTCHA 통과를 위해 수정되지 않은 iOS 또는 Google Mobile Services Android 기기가 필요해지는 문제는 GrapheneOS만의 문제가 아님
  • Windows, 데스크톱 Linux, FreeBSD 등에도 같은 영향을 줌
  • Pixel, Android 기기, AOSP 기반 운영체제에 특화된 문제가 아니며, 데스크톱 웹 접근에도 영향을 줄 수 있음

Android 증명 API와 Unified Attestation

  • Android는 검증된 부트 키 지문을 허용해 대체 운영체제를 지원하는 표준 하드웨어 증명 시스템을 제공함
  • Android의 하드웨어 증명은 주로 Google의 신뢰 루트와 원격 키 프로비저닝 서비스를 사용하지만, API 자체는 대체 신뢰 루트를 지원함
  • Android 하드웨어 증명은 특정 하드웨어나 OS를 쓰지 않는 사용자를 배제하는 데 사용되어서는 안 됨
  • 다만 임의의 신뢰 루트와 OS를 허용할 수 있다는 점은 서비스가 더 많은 대상을 허용할 여지를 줌
  • Google이 보안을 목적으로 했다면 같은 시스템을 사용해 Play Integrity에서 GrapheneOS를 허용할 수 있음
  • Unified Attestation은 여러 유럽 기업이 밀고 있는 또 다른 반경쟁적 시스템으로, 임의의 하드웨어와 소프트웨어 사용자를 비슷하게 배제하게 됨
  • Unified Attestation은 해결책이 아니며, Android의 훨씬 더 개방적인 하드웨어 증명 API보다 훨씬 나쁨
  • Volla의 Unified Attestation은 Android의 하드웨어 증명 API 위에 완전히 구축되어 있음
  • Volla의 Unified Attestation은 무엇이 허용되는지를 중앙 권한과 서비스가 통제하도록 만들기 위해 존재함

함께 보면 좋은 글 β

▲
unsure4000 6시간전  [-]

구글이 너무 좋아서 다섯개쯤 있었으면 좋겠어요🥰

답변달기
▲
GN⁺ 9시간전  [-]
Hacker News 의견들

  • EU Digital Identity Wallet(EUDI) 이 Google이나 Apple의 하드웨어 증명을 요구해서, 사실상 EU의 모든 디지털 신원을 미국 양강에 묶어버림
    디지털 주권을 말하면서 이런 결정을 하는 셈이고, 아이들 보호가 주권보다 우선이라는 식으로 보임
    https://gitlab.opencode.de/bmi/eudi-wallet/wallet-developmen...

    • 미국 대통령이 스위치 하나만 뒤집어도 EU의 Digital Identity Wallet을 꺼버릴 수 있다는 뜻임
      애초에 왜 이런 결정을 했는지 이해가 안 됨
    • 이 문제로 EU 담당자에게 메일을 보냈지만, 앱이 오픈소스라 좋다는 식의 훈계조 답변만 받음
      기술 지식이 없는 일반 사용자에게 맞춘 답변이 분명해 보였음
    • 비슷한 생각으로 들어왔음
      주권과 미국 의존 탈피를 중요하게 말하는 사람들이 많은데 왜 더 큰 반대가 없는지 모르겠고, 그냥 무지 때문이라고 봐야 하나 싶음
    • 기기 내 식별자의 큰 문제는 복제 위험 때문에 기기에 강하게 묶여야 한다는 점임
      특히 개인정보 보호형 식별자에서는 더 그렇고, 그래서 기기 증명이 중요해짐
      하드웨어가 사용자의 키 추출을 막는지 확인할 수 없으면 신원 키가 기기에 잠겨 있다고 보장할 수 없음
      최악인 부분은 의욕 있는 범죄자들은 결국 그 키를 추출해 사기에 쓸 방법을 찾을 것이고, 그 결과 오픈소스와 개방형 컴퓨팅이 파괴된다는 점임
    • 보안 신원이 필요하다면 ISO7816이 이미 있고 Big Tech와 완전히 독립적임
      누가 신분증 제시를 요구받아야 하는지는 별개 문제이고, 온라인 전용 상황 대부분에서는 답이 “아니오”라고 보지만, 금융권이 수십 년간 신뢰해 온 해법은 이미 존재함

  • 승인된 실리콘과 소프트웨어를 요구하는 것조차 여기서 가장 큰 문제가 아님
    이들은 영지식 증명이나 블라인드 서명을 쓰지 않음
    그래서 기기로 증명할 때마다 해당 행동을 기기와 연결하는 데 쓸 수 있는 증명 패킷을 남김
    중간 서버에서 정적 기기 ID로 일회성 ID를 받아오는 우회 구조를 넣어 개인정보를 신경 쓰는 척하지만, 그 중간 서버들이 무엇을 하는지 알 수 없으니 모두 기록한다고 봐야 함
    원격 증명 경로만 이렇고, DRM ID 경로는 더 나쁨. 의미 있는 우회가 없어서 모든 라이선스 서버가 실리콘에 새겨진 정적 신원에 접근할 수 있음. Google 계정 경로는 말할 것도 없음
    원격 증명에 블라인드 서명을 쓰자는 제안은 실제로 있었지만, 현재 눈에 띄는 곳에서는 쓰지 않음: <https://en.wikipedia.org/wiki/Direct_Anonymous_Attestation>
    가능한 이유는 몇 가지가 있음. 뻔한 이유는 원할 때 개인정보를 침해할 수 있기를 원하거나 그런 능력을 의무화받았기 때문임
    다른 이유는 특정 기기와 증명을 연결할 수 없으면 악용 완화 수단이 사실상 속도 제한뿐인데, 그들 기준에는 충분하지 않을 수 있다는 점임. 공격자가 기기 농장을 꾸려 각 기기가 악의적 행위자에게 원격 증명을 제공하며 시간당 돈을 벌게 할 수 있음

    • “증명을 특정 기기와 연결할 수 없기 때문에 가능한 악용 완화가 속도 제한뿐”이라는 부분이 여전히 이해되지 않음
      어떤 서비스를 익명으로 유지하면서도 속도 제한을 할 수 있는지 모르겠음
      한 서비스가 두 요청이 같은 주체에서 왔는지 세어볼 수 있다면, 두 서비스도 같은 서비스인 척해서 두 요청이 같은 주체에서 왔는지 알아내고 서로 연관 지을 수 있음
    • 온라인과 기기에서 감시당하는 것을 정상화하는 일을 그만해야 함
      “문제는 하드웨어 증명이 아니라 영지식 증명을 안 쓰는 것” 같은 식으로 말하면 새로운 행동을 정상화하는 것임
      그러면 안 됨. 영지식 증명을 쓰든 최신 보안 기술로 하드웨어 증명을 하든 상관없이, 문제는 하드웨어 증명 자체임
      나이 확인도 마찬가지임. 문제는 나이 확인이 데이터 유출에 취약하다는 게 아니라, 문제 자체가 나이 확인임
    • 이 내용에 대한 정리 글을 읽어보고 싶음
      앱 발표 때부터 대충 이런 구조일 거라고 확신했음
      Graphene 포럼에서도 DRM ID가 보존될 뿐 아니라 프로필 간에도 동일하게 유지된다는 논의를 본 기억이 있음
    • 이런 문제들이 Privacy Pass가 고치려는 종류의 문제인지 궁금함
      그렇다면 무엇이 당근이나 채찍이 되어 도입을 이끌 수 있을까

  • 이 기술이 왜 “열린” 무언가에 문제가 되어 가는지 잘 보여주는 스레드임
    “우리만의 별도 웹을 만들면 된다”는 주장은, 모든 서비스가 Google 승인 또는 Apple 승인 모바일 기기 소유를 강제하는 웹 뒤에 들어가기 전까지만 괜찮음

    • 친구들과 Pacific Northwest의 Cascade Bicycle Club이 주최하는 라이딩에 자전거를 타러 가는 걸 좋아했는데, 참가 등록을 하려면 Google reCAPTCHA를 풀어야 함
      Google은 이미 그걸 완전히 막고 있음
      요구하는 항목을 고르려고 사각형을 클릭하면 무한 반복되고, 오디오 버전을 쓰려고 하면 의심스러운 활동이 있었다며 완전히 차단함
      그래서 요즘은 혼자 타고, 올해는 회원권도 갱신하지 않았음
      마지막으로 비슷한 경험을 한 건 Facebook이 특정 행사 참여의 유일한 경로가 되기 시작했을 때였음. 그때도 그냥 배제된 것으로 받아들이고 시간과 돈을 다른 데 썼음
    • 이런 터무니없는 상황을 만드는 데는 증명조차 필요 없었음
      이미 많은 사업체나 사회 모임이 Facebook, WhatsApp 같은 것 뒤에 있어야만 접근 가능했음
      이건 정말 이상한 사이버펑크 디스토피아처럼 느껴짐. 같은 사설 우편 서비스에 가입한 사람에게만 편지와 소포를 보낼 수 있거나, 내 차 브랜드와 상호 라이선스가 있는 도로에서만 운전할 수 있는 것과 비슷함
    • “유용한 보안 기능을 제공하지 않는다”는 문장은 빼는 편이 낫다고 봄
      설령 보안 기능이 있더라도 Google이나 Apple이 아닌 운영체제를 2등 시민으로 만드는 부수 피해는 그대로이고, 그게 핵심 문제임
    • 그렇다면 그런 서비스들의 별도 복제본도 만들자는 주장이 되지 않을까
      은행이나 정부 상호작용은 현실성이 없겠지만, 그 외 많은 서비스에는 가능하지 않을까 싶음
      다만 무언가를 만드는 작업은 여전히 필요하고, 비용은 더 적은 사람에게 분산되며, 광고 기술을 만들 필요가 없어 복잡도가 낮아지는 장점만으로는 상쇄되지 않을 가능성이 큼
      그래도 일종의 좋은 식재료 같은 문제일 수 있음. 하드웨어는 더 어려울 것임
    • 우리끼리 나라를 운영할 만큼 숫자가 될까
      바보 같은 질문처럼 느껴지지만 진지하게 묻는 것임

  • 1999년에 Intel이 CPU에 소프트웨어로 읽을 수 있는 일련번호를 넣기로 했을 때 엄청난 반대가 있었고, 결국 결정을 철회했음
    그 뒤에도 “보안”과 신뢰 컴퓨팅을 밀어붙이는 권위주의자들은 TPM과 관련 기술을 계속 추진했고, 모바일 담장 친 생태계의 부상에도 기여함
    Windows 11의 TPM 요구사항도 그 목표를 향한 또 다른 단계였음. 여기와 다른 곳에서 그것이 좋은 일이라는 선전이 얼마나 많았는지 충격적이었음
    “보안”이 명분으로 제시되면 상당수 사람들은 무엇이든 쉽게 강요당한다는 사실이 드러남. 그 수가 줄고 있기를 바람
    범용 컴퓨팅과의 전쟁은 계속되고 있고, 계속 싸워야 함
    Stallman은 늘 그렇듯 옳았음. 그의 “Right to Read”를 다시 읽을 때임. 아직 없다면 AI로 만든 단편 영화도 좋은 아이디어일 수 있음
    “안전을 위해 자유를 포기하는 자는 둘 다 누릴 자격이 없다”

    • AI를 꺼내기 전까지는 완전히 동의했음
      AI는 완전히 중앙화되고 독점적인 도구임
    • Intel에 반대했던 사람들이 이제는 서로에게 얼마나 가망 없고 무력한지 말하고 있음
      이 스레드에서도 볼 수 있듯, 이런 문제에 대한 추진력, 분노, 자기조직화된 대응 대신 “아무도 신경 안 쓴다”, “우리가 할 수 있는 건 없다” 같은 절망만 있음
      포기는 지는 가장 확실한 방법임

  • 여기 댓글들은 증명 자체가 나쁘다는 이야기로 읽는 듯하지만, 진짜 주장은 Apple과 Google이 아닌 제공자도 명시적으로 포함될 경로가 있어야 한다는 것에 가까워 보임
    제목은 Apple과 Google이 악하고 독점 고착을 위해 이 일을 하며, 경쟁자인 GrapheneOS가 사람들을 위해 맞선다는 식으로 보임
    하지만 마지막 반론이 자신들도 포함됐어야 한다는 것이고, Google의 Play Integrity API에서 불명확한 이유로 거절당했으며 그 이유가 악의적이라고 주장하는 점을 보면, 이들도 보안적 가치는 인정하는 듯함
    중요한 신원 데이터에는 전체 서명 사슬 증명이 정말 필요함. AI로 사기 신원을 쉽게 만들 수 있는 상황을 피할 수 있는 유일한 방법이기 때문임

  • 특허와 저작권은 원래의 독점 형태였음
    소프트웨어가 오픈소스가 아닌 한, 정의상 독점임

  • GrapheneOS를 후원하는 HN 부자들이 더 많지 않은 게 의외임
    이 문제를 신경 쓰는 부유층과 기술자들의 벤 다이어그램은 꽤 겹칠 것 같은데, Graphene은 결점이 많아도 이 영역에서 많은 기초 작업을 하고 있음

  • 우리 문명은 현대 마이크로전자공학을 제조 후에 수정할 방법이 절실히 필요하고, 최소한 장비가 잘 갖춰진 수리점에서는 쓸 수 있어야 함
    이미 어제 필요했던 수준임
    대안으로는 범용으로 판매되는 컴퓨팅 기기에서 CPU나 SoC의 마스크 ROM에 어떤 종류의 초기 부트로더도 넣어 출하하는 것을 불법화해야 함
    즉 리셋 후 CPU가 실행하는 첫 명령은 CPU 패키지 바깥에 물리적으로 있는 저장장치에서 와야 함

    • 아니면 DRM 우회가 불법인 법을 없애야 함
      참고: https://pluralistic.net/2026/01/01/39c3/
    • 그런 일은 아주 오랫동안 일어나지 않을 가능성이 큼
      비교적 단순한 SoC도 문서화되지 않은 부트 ROM에서 아키텍처상의 리셋 벡터에 도달하기 전 리셋 과정을 돕기 위해 많은 작업을 함
      실수로 지워질 수 없는 부트 ROM에 저수준 DFU 루틴을 넣는 가치도 큼
    • 그것만으로는 도움이 안 됨
      SoC 실리콘은 전원 투입부터 보안 부트 인계 명령어까지 실행된 각 명령을 기록하도록 개정될 수 있음
      상태 조회, 오버플로 여부, 서명 생성 같은 보조 명령어까지 두면 운영체제가 자체 증명을 만들면서 부트 전 변조를 암묵적으로 보고하게 됨
    • 원문은 Pixel 6 이후 모든 Google 휴대폰에 자유롭게 설치할 수 있는 대체 운영체제 개발자들이 쓴 것임
    • 초기 부트로더를 CPU나 SoC의 마스크 ROM에 넣어 출하하는 것을 불법화할 필요는 없음
      부트로더에 하드코딩된 키 자료를 넣고, 그 키로 로드하는 코드를 검증하는 것을 불법화하면 됨

  • Google·Apple 양강이 완전히 무관한 서비스에 누가 접근할 수 있고 없는지를 결정하게 놔두고 있다는 게 놀라움
    반Google 견해 때문에 Google 서비스에서 차단됐는데 은행 계정에도 로그인할 수 없게 되는 상황을 상상해 보라
    정말 Alphabet 분할을 해야 함

  • 이렇게 심각하다는 주제라면 읽기 어려운 스레드보다, 한 페이지짜리로 정리된 논리적인 실제 글이 훨씬 나았을 것 같음

답변달기