¿Existe alguna documentación sobre cómo funciona exactamente la Protección de Restablecimiento de Fábrica (FRP)?

Creo que mucho de esto se mantiene intencionadamente "en secreto"... al investigar yo mismo algo de esto hace un tiempo, esto es lo máximo que pude encontrar "en detalle".

https://github.com/intel/kernelflinger/blob/master/doc/FRP.md

Política del cargador de arranque y protección del restablecimiento de fábrica La especificación de arranque verificado de Google (GVB) y la protección de restablecimiento de fábrica de Google (FRP) para AndroidTM definen un conjunto de protocolos de seguridad para garantizar la integridad del sistema y desincentivar el robo del dispositivo, respectivamente.

Hay razones legítimas para desbloquear el bootloader sin conocer el PIN de desbloqueo de la pantalla; específicamente las RMA. Un centro de procesamiento de RMA debe ser capaz de desbloquear las restricciones de flasheo del dispositivo en Fastboot y devolver el dispositivo a un estado prístino de fábrica sin requerir que el usuario revele su PIN de desbloqueo de la pantalla o que potencialmente abra sus datos de usuario a un compromiso.

Esta documentación describe la solución para definir un dispositivo de clase A y un mecanismo que permite desbloquear un dispositivo para RMA independientemente del estado de FRP o de la clase A. Cumple con los requisitos de seguridad de Google FRP al garantizar que no haya una única llave maestra para desbloquear los dispositivos si se implementan todas las consideraciones de seguridad. También permite aprovisionar los dispositivos para que la entidad con autoridad de desbloqueo pueda ser el vendedor, el OEM, el ODM, un operador o una organización empresarial.

Experiencia del usuario del dispositivo El usuario arranca el dispositivo en Fastboot El usuario obtiene un desafío de acción fastboot oem get-action-nonce force-unlock El usuario da el desafío al agente de autorización de acción y recibe un archivo de token de autorización de acción (detalles más adelante) El usuario muestra el token de autorización de la acción fastboot flash acción-autorización archivo_token Fastboot realiza la acción autorizada Implementación El protocolo de autorización de acciones OEM es una simple respuesta de desafío en la que el Fastboot del dispositivo genera un nonce de una sola vez, el agente de autorización de acciones OEM firma el nonce y la acción aprobada utilizando su clave de autorización privada (OAK) para generar un token de autorización, y luego el Fastboot del dispositivo valida el token de autorización de la acción y ejecuta la acción.

Clave de autorización de anulación La clave de autorización de anulación (OAK) es una clave pública que se establece en el dispositivo durante la fabricación y que se utiliza para validar los tokens de autorización de acción. Si no se establece una OAK, todas las funciones de autorización de acciones se deshabilitan y se aplica el comportamiento predeterminado del cargador de arranque y del Fastboot especificado en GVB y FRP. Dado que la OAK es capaz de anular las políticas de clase A y FRP, es importante asegurarse de que no puede ser modificada por código no autorizado, lo que cambiaría la identidad de quién puede anular la política.

La OAK puede actuar como un certificado root de validación si el atributo de autoridad del certificado es "true", es decir, la gestión estándar de certificados X.509v3. Esto significa que el OAK puede utilizarse para emitir certificados que también pueden firmar tokens de autorización de acciones. Este es el método preferido para establecer el OAK en los casos en que varias entidades necesitan la capacidad de emitir tokens de autorización de acciones sin tener acceso a una única clave.

OAK se almacena como la variable EFI autenticada basada en el tiempo OAK bajo el GUID de Fastboot de 1ac80a82-4f0c-456b-9a99-debeb431fcc1. El contenido de esta variable es la suma SHA256 del certificado OAK.

Máscara de política del cargador de arranque La máscara de política del gestor de arranque (BPM) es un conjunto de 64 indicadores de política booleanos. Si no se establece un BPM, Fastboot utiliza por defecto una política que coincide con un valor BPM de cero. Si se establece un valor BPM, un bit de uno indica que la política correspondiente está activa.

El BPM se ajusta en el dispositivo durante la fabricación.

Política Nombre Bit(s) Descripción CLASS_A_DEVICE 0 Si se establece, el gestor de arranque aplica el comportamiento definido por GVB para los dispositivos de clase A. MIN_BOOT_STATE 1-2 Estado de arranque mínimo requerido para arrancar el dispositivo (0 para rojo, 1 para naranja, 2 para amarillo y 3 para verde) BPM se almacena como la variable EFI autenticada basada en el tiempo BPM bajo el GUID de Fastboot de 1ac80a82-4f0c-456b-9a99-debeb431fcc1.

Generación del nonce de acción única El nonce de autorización de acción única tiene la forma "::<id de acción de 8 bits>:<16 bytes aleatorios de cliente>" con todos los campos codificados en hexadecimal. Se genera cuando se utiliza el comando fastboot oem get-action-nonce. Fastboot guarda el valor durante un tiempo limitado antes de que expire. Cada vez que se ejecuta el comando se genera un nuevo valor y se sobrescribe el anterior. El valor no se almacena de forma persistente. Si Fastboot se reinicia, el nonce anterior ya no es válido.

Se definen las siguientes acciones.

Nombre Acción ID Descripción Force unlock 0x00 Hace que Kernelfliner ejecute el comando de desbloqueo de Fastboot como si la opción de desarrollador "enable oem unlock" estuviera activada. Se aplican todas las propiedades estándar de GVB, incluyendo el borrado seguro de la partición de datos del usuario. El campo de la versión es un valor de un byte. Debe ser cero para la versión actual.

Creación de un token de autorización de acción Un token de autorización de acción se genera firmando el nonce de autorización de acción con el OAK. El token es un documento firmado PKCS #7, cuyo cuerpo tiene la forma "::<id de acción de 8 bits>:<16 bytes aleatorios del cliente>:<16 bytes aleatorios del agente de autenticación>" con todos los campos codificados en hexadecimal. Los bytes aleatorios del agente de autenticación que se añaden al crear la autorización son para evitar que un atacante monte un ataque suministrando valores de texto plano conocidos.

El token debe contener todos los certificados necesarios para validar la cadena de firmas del token.

El agente de autorización de la acción debe verificar que el nonce tiene exactamente el formato prescrito.

El agente de autorización de la acción debe verificar que el ID de la acción en el nonce es un valor reconocido.

Si es posible, el agente de autorización de la acción debe verificar que el número de serie es válido.

Cómo hacer que el Token de Autorización de la Acción se active El token de autorización se envía a Fastboot utilizando el objetivo especial de flasheo "action-authorization". Fastboot verifica que el token es válido, invalida el actual one-time-nonce, y ejecuta la acción autorizada.

Fastboot debe validar que no hay datos extra después de analizar el token.

Fastboot debe verificar que el certificado de la firma se encadena con el OAK establecido en la fabricación.

Fastboot debe verificar que todos los valores en el cuerpo del token tienen los valores prescritos.

Fastboot debe verificar que el valor devuelto por el comando "oem get-action-nonce " coincide con el valor del cuerpo del token y que el nonce no ha caducado.