La atestación de hardware como asistente exclusivo
(grapheneos.social)- Apple y Google están ampliando el uso de la atestación basada en hardware, impulsando su adopción en más servicios y reforzando a largo plazo una estructura que excluye la competencia de hardware y sistemas operativos no aprobados
- La Play Integrity API de Google y la App Attest API de Apple funcionan de forma similar; Play Integrity exige atestación de hardware en
strong integrityy avanza gradualmente hacia exigirla también endevice integrity - El Privacy Pass de Apple, la cancelada Web Environment Integrity de Google y
reCAPTCHA Mobile Verificationllevan los requisitos de atestación a la web, y el acceso a servicios web puede quedar bloqueado si no se tiene un dispositivo iOS o Android certificado - La Play Integrity API bloquea a GrapheneOS aunque sea más seguro que los objetivos permitidos, y permite dispositivos sin parches de seguridad durante 10 años, por lo que su propósito de licenciamiento de Google Mobile Services y exclusión de competencia resalta más que cualquier argumento de seguridad
- A medida que los servicios gubernamentales y bancarios exigen cada vez más App Attest y Play Integrity, en la práctica fuerzan el uso de dispositivos Apple o Android certificados por Google, y esto también puede afectar el acceso web desde entornos como Windows, Linux de escritorio o FreeBSD
Requisitos de atestación que se extienden a la web
- El Privacy Pass de Apple lleva la atestación de hardware a la web para ayudar a pasar CAPTCHAs desde su propio hardware
- En ese momento, muchas personas lo veían como algo inofensivo porque creían que no habría muchos sitios bloqueando a quienes no usaran hardware de Apple
- Es muy probable que tanto Apple como Google lleven una atestación de hardware más amplia a la web
- Los bancos y servicios gubernamentales exigen cada vez más el uso de apps móviles, y dentro de esas apps pueden usar atestación para imponer dispositivos y sistemas operativos aprobados por Apple o Google
- El Privacy Pass de Apple, la cancelada Web Environment Integrity de Google y reCAPTCHA Mobile Verification están llevando esta tendencia a la web
- La cobertura actual sobre reCAPTCHA Mobile Verification no aborda correctamente su impacto ni sus implicaciones
- Este método exige, en ciertas situaciones, escanear un QR con un smartphone certificado para poder pasar reCAPTCHA, llevando así los requisitos de atestación de hardware también a Windows, Linux de escritorio, OpenBSD y otros entornos
- Gracias a su control sobre reCAPTCHA, Google está en posición de hacer que se necesite un dispositivo iOS o Android certificado para usar una parte enorme de la web
- Google define los requisitos de certificación de Android, entre ellos la obligación de incluir Google Chrome
- reCAPTCHA Mobile Verification actualmente funciona con Google Play en sandbox de GrapheneOS, pero existe como una vía para empezar a aplicar esto también en sistemas sin atestación de hardware
- Si este requisito se aplica, las personas sin dispositivos iOS o Android podrían ser bloqueadas incluso sin condiciones adicionales
Play Integrity y la exclusión de GrapheneOS
- La Play Integrity API de Google prohíbe el uso de GrapheneOS aunque GrapheneOS sea mucho más seguro que cualquier objetivo permitido
- La Play Integrity API también bloquea otras alternativas, y esto no es un problema exclusivo de los sistemas operativos basados en AOSP
- Incluso usar un sistema operativo móvil basado en FreeBSD no evita este problema; solo implica una exclusión aún mayor
- La Play Integrity API permite dispositivos sin parches de seguridad durante 10 años
- El nivel
device integritypuede eludirse con spoofing, pero Google puede detectarlo y bloquearlo bastante bien si empieza a usarse a gran escala - Eludir el nivel
strong integrityrequiere claves filtradas desde un TEE o SE - La Play Integrity API no es especialmente segura y, de forma temporal, no es especialmente difícil de eludir
- Existen frameworks para falsear verificaciones de software y también se pueden comprar claves filtradas para saltarse la atestación de hardware
- Aun así, eludirla se está volviendo cada vez más difícil y la validez de esos métodos dura cada vez menos
- Play Integrity no ofrece funciones de seguridad útiles, pero sí funciona muy bien para excluir a la competencia
- Los servicios que exigen Apple App Attest o Google Play Integrity principalmente ayudan a Apple y Google a mantener un duopolio en dispositivos móviles
- Play Integrity es más importante porque AOSP es de código abierto
- GrapheneOS puede verificarse mediante atestación de hardware, y la razón por la que Google lo bloquea en Play Integrity es que no licencia Google Mobile Services ni sigue reglas anticompetitivas
- Esas reglas ya han sido consideradas ilegales en lugares como Corea del Sur
- Los servicios no deberían prohibir el uso de hardware y sistemas operativos arbitrarios
- Dado que Google permite dispositivos sin parches durante 10 años mientras no permite sistemas operativos mucho más seguros, es difícil sostener un argumento de seguridad
- Esto busca imponer un monopolio a través del licenciamiento de GMS
Servicios gubernamentales y bancarios, y el papel de la regulación
- Los gobiernos están exigiendo cada vez más el uso de Apple App Attest y Google Play Integrity no solo en sus propios servicios, sino también en servicios comerciales
- La UE está liderando una tendencia a aplicar estos requisitos a pagos digitales, verificación de identidad, verificación de edad y más
- Muchas apps gubernamentales de la UE ya incluyen estos requisitos
- En lugar de frenar las graves prácticas anticompetitivas de Apple y Google, los gobiernos están participando directamente en la exclusión de la competencia mediante sus propios servicios
- Exigir a las personas dispositivos Apple o Android certificados por Google no es seguridad, sino una restricción de la competencia
- El problema de necesitar un dispositivo iOS sin modificar o un Android con Google Mobile Services para acceder a servicios bancarios o gubernamentales, o para superar ciertos reCAPTCHAs, no es algo exclusivo de GrapheneOS
- También afecta a Windows, Linux de escritorio, FreeBSD y otros entornos
- No es un problema específico de Pixel, de dispositivos Android ni de sistemas operativos basados en AOSP; también puede afectar el acceso web desde computadoras de escritorio
APIs de atestación de Android y Unified Attestation
- Android ofrece un sistema estándar de atestación de hardware que admite sistemas operativos alternativos al permitir huellas digitales de claves de arranque verificadas
- La atestación de hardware de Android usa principalmente la raíz de confianza de Google y el servicio de aprovisionamiento remoto de claves, pero la API en sí misma admite raíces de confianza alternativas
- La atestación de hardware de Android no debería usarse para excluir a personas que no utilicen hardware o sistemas operativos específicos
- Aun así, el hecho de que permita raíces de confianza y sistemas operativos arbitrarios deja margen para que los servicios permitan más opciones
- Si Google realmente actuara por seguridad, podría usar el mismo sistema para permitir GrapheneOS en Play Integrity
- Unified Attestation es otro sistema anticompetitivo promovido por varias empresas europeas, que excluiría de forma similar a usuarios de hardware y software arbitrarios
- Unified Attestation no es una solución y es mucho peor que la API de atestación de hardware de Android, que es mucho más abierta
- Unified Attestation de Volla está construida completamente sobre la API de atestación de hardware de Android
- Unified Attestation de Volla existe para hacer que una autoridad central y los servicios controlen qué está permitido
2 comentarios
Me gusta tanto Google que ojalá hubiera como cinco🥰
Comentarios en Hacker News
EU Digital Identity Wallet (EUDI) exige la atestación de hardware de Google o Apple, atando de facto toda la identidad digital de la UE al duopolio estadounidense
Es una decisión contradictoria para quienes hablan de soberanía digital, y da la impresión de que proteger a los niños se pone por encima de la soberanía
https://gitlab.opencode.de/bmi/eudi-wallet/wallet-developmen...
De entrada no entiendo por qué tomaron esta decisión
Claramente parecía una respuesta pensada para usuarios sin conocimientos técnicos
Hay mucha gente que habla de soberanía y de dejar de depender de EE. UU., así que no entiendo por qué no hay más oposición; me hace pensar si simplemente es por ignorancia
Eso es aún más cierto en identificadores orientados a la privacidad, y por eso la atestación del dispositivo se vuelve importante
Si no puedes verificar que el hardware impide extraer las claves del usuario, no puedes garantizar que la clave de identidad esté realmente bloqueada al dispositivo
La peor parte es que los criminales suficientemente motivados igual encontrarán una forma de extraer esas claves para cometer fraude, y el resultado será la destrucción del código abierto y la computación abierta
Quién debería verse obligado a mostrar identificación es otra discusión, y en la mayoría de los escenarios exclusivamente en línea yo diría que la respuesta es “no”, pero la solución en la que el sector financiero ha confiado durante décadas ya existe
Ni siquiera exigir silicio y software aprobados es el problema más grande aquí
No usan pruebas de conocimiento cero ni firmas ciegas
Así que cada vez que demuestras algo con tu dispositivo, dejas un paquete de prueba que puede usarse para vincular esa acción con el equipo
Meten una arquitectura de rodeo donde obtienen un ID de un solo uso a partir de un ID de dispositivo estático en un servidor intermedio, para aparentar que les importa la privacidad, pero como no sabemos qué hacen esos servidores intermedios, hay que asumir que registran todo
Esto solo aplica a la ruta de atestación remota; la ruta del ID de DRM es peor. No hay una evasión significativa, así que todos los servidores de licencias pueden acceder a una identidad estática grabada en el silicio. Y la ruta de la cuenta de Google ni se diga
Sí hubo propuestas para usar firmas ciegas en atestación remota, pero no se usan en ningún lugar visible actualmente: <https://en.wikipedia.org/wiki/Direct_Anonymous_Attestation>
Hay varias razones posibles. La obvia es que quieren poder violar la privacidad cuando les convenga, o están obligados a tener esa capacidad
Otra razón es que, si no puedes vincular una prueba con un dispositivo específico, la mitigación de abuso en la práctica se reduce al límite de velocidad, y quizá eso no les parezca suficiente. Un atacante podría montar una granja de dispositivos donde cada uno proporcione atestación remota a actores maliciosos a cambio de dinero por hora
No me queda claro cómo se puede mantener anónimo un servicio y al mismo tiempo aplicar rate limiting
Si un servicio puede contar si dos solicitudes vienen del mismo sujeto, entonces dos servicios también podrían hacerse pasar por el mismo servicio para averiguar si esas dos solicitudes vienen del mismo sujeto y vincularlas entre sí
Decir cosas como “el problema no es la atestación de hardware, sino no usar pruebas de conocimiento cero” normaliza una nueva conducta
Eso no debería pasar. Da igual si usan pruebas de conocimiento cero o si hacen atestación de hardware con la tecnología de seguridad más moderna: el problema es la atestación de hardware en sí
Lo mismo con la verificación de edad. El problema no es que sea vulnerable a filtraciones de datos; el problema es la verificación de edad misma
Desde que anunciaron la app estaba casi seguro de que la arquitectura sería algo así
También recuerdo haber visto en el foro de Graphene una discusión sobre que el ID de DRM no solo se conserva, sino que además sigue siendo el mismo entre perfiles
Si es así, ¿qué sería la zanahoria o el garrote que impulsaría su adopción?
Este hilo muestra muy bien por qué esta tecnología se está volviendo un problema para cualquier cosa “abierta”
La idea de “hagamos nuestra propia web aparte” funciona solo hasta que todos los servicios queden detrás de una web que obliga a tener un dispositivo móvil aprobado por Google o Apple
Google ya me bloquea eso por completo
Si hago clic en los cuadros para elegir lo que pide, entra en un ciclo infinito, y si intento usar la versión de audio me bloquea del todo diciendo que hubo actividad sospechosa
Así que ahora salgo solo a rodar y este año ni renové mi membresía
La última vez que tuve una experiencia parecida fue cuando Facebook empezó a convertirse en el único camino para participar en ciertos eventos. En ese momento simplemente acepté que me estaban excluyendo y dediqué mi tiempo y dinero a otra cosa
Ya había muchos negocios o reuniones sociales a los que solo se podía acceder detrás de Facebook, WhatsApp y similares
Esto realmente se siente como una distopía cyberpunk extrañísima. Como si solo pudieras enviar cartas y paquetes a gente suscrita al mismo servicio de correo privado, o solo pudieras manejar por carreteras con licencia recíproca para la marca de tu coche
Aunque sí ofreciera alguna función de seguridad, el daño colateral de convertir en ciudadanos de segunda a los sistemas operativos que no son de Google o Apple seguiría ahí, y ese es el problema central
Con bancos o interacciones con el gobierno quizá no sea realista, pero para muchos otros servicios sí podría serlo
Aun así, sigue haciendo falta el trabajo de construir algo, y es probable que el costo repartido entre menos personas no se compense solo con la ventaja de una menor complejidad por no tener que crear tecnología publicitaria
De todos modos, podría ser una especie de problema de buenos ingredientes. El hardware sería más difícil
Suena a pregunta tonta, pero lo digo en serio
En 1999, cuando Intel decidió meter en la CPU un número de serie legible por software, hubo una oposición enorme y al final dieron marcha atrás
Después de eso, los autoritarios que siguieron empujando la “seguridad” y la computación confiable continuaron promoviendo el TPM y tecnologías relacionadas, y también contribuyeron al auge de los jardines amurallados móviles
El requisito de TPM en Windows 11 fue otro paso en esa dirección. Me impactó cuánta propaganda hubo aquí y en otros lados diciendo que eso era algo bueno
Queda claro que si se usa la “seguridad” como justificación, a muchísima gente se le puede imponer casi cualquier cosa con facilidad. Ojalá ese número esté bajando
La guerra contra la computación de propósito general sigue, y hay que seguir peleándola
Stallman, como casi siempre, tenía razón. Ya es momento de releer su “Right to Read”. Si todavía no existe, hasta un cortometraje hecho con IA podría ser una buena idea
“Quien renuncia a la libertad por seguridad no merece ninguna de las dos”
La IA es una herramienta completamente centralizada y monopolística
Como se ve también en este hilo, en lugar de impulso, indignación o una respuesta autoorganizada ante estos problemas, solo hay desesperanza de “a nadie le importa” y “no hay nada que podamos hacer”
Rendirse es la forma más segura de perder
Los comentarios aquí parecen leer esto como si dijera que la atestación en sí es mala, pero el argumento real parece estar más cerca de que debe existir una vía que incluya explícitamente también a proveedores que no sean Apple y Google
El título da la impresión de que Apple y Google son malvados y hacen esto para afianzar su monopolio, mientras un competidor como GrapheneOS lucha por la gente
Pero la última objeción es que ellos también deberían haber sido incluidos, y al ver que alegan que la API Play Integrity de Google los rechazó por razones poco claras y que esas razones fueron maliciosas, da la impresión de que también reconocen el valor de seguridad
Para datos de identidad importantes, realmente se necesita una prueba de toda la cadena de firmas. Es la única manera de evitar una situación en la que la IA permita crear identidades fraudulentas con facilidad
Las patentes y el copyright fueron la forma original del monopolio
Mientras el software no sea código abierto, por definición es monopólico
Me sorprende que no haya más ricos de HN patrocinando GrapheneOS
El diagrama de Venn entre la gente con dinero y los técnicos que se preocupan por este tema debería tener bastante superposición, y Graphene, con todos sus defectos, está haciendo mucho trabajo fundamental en esta área
Nuestra civilización necesita con urgencia una forma de modificar la microelectrónica moderna después de fabricada, y como mínimo eso debería estar al alcance de talleres de reparación bien equipados
Era algo que ya necesitábamos desde ayer
La alternativa sería prohibir que los dispositivos de cómputo de propósito general vendidos al público salgan de fábrica con cualquier tipo de bootloader inicial en la mask ROM del CPU o SoC
Es decir, que la primera instrucción que ejecute el CPU después de un reset tenga que venir de un almacenamiento físicamente externo al encapsulado del CPU
Referencia: https://pluralistic.net/2026/01/01/39c3/
Incluso SoC relativamente simples hacen mucho trabajo desde una boot ROM no documentada para ayudar en el proceso de reset antes de llegar al vector de reset arquitectónico
También tiene mucho valor contar con rutinas de DFU de bajo nivel en una boot ROM que no pueda borrarse por accidente
El silicio del SoC podría rediseñarse para registrar cada instrucción ejecutada desde el encendido hasta la instrucción de transferencia a secure boot
Si además tuviera instrucciones auxiliares para consultar estado, ver si hubo overflow o generar firmas, el sistema operativo podría crear su propia atestación mientras reporta implícitamente cualquier manipulación previa al arranque
Basta con prohibir que el bootloader incluya material de claves hardcodeado y que use esas claves para verificar el código que carga
Sorprende que estemos dejando que el duopolio Google-Apple decida quién puede y quién no puede acceder a servicios totalmente ajenos a ellos
Imagínate que te bloqueen de los servicios de Google por tus posturas anti-Google y que, por eso mismo, ya no puedas entrar a tu cuenta bancaria
De verdad hay que dividir Alphabet
Para un tema así de serio, habría sido mucho mejor un texto real, lógico y condensado en una página que este hilo difícil de leer