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

2 days ago 5

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은 무엇이 허용되는지를 중앙 권한과 서비스가 통제하도록 만들기 위해 존재함