Protección de clave sellada (SKP)
En dispositivos Apple compatibles con Protección de datos, la clave de encriptación de claves (KEK) se protege (o se sella) mediante mediciones del software del sistema y se vincula al UID disponible únicamente desde Secure Enclave. En un Mac con chip de Apple, la protección de la clave de encriptación de claves (KEK) se refuerza con la incorporación de información sobre la política de seguridad en el sistema, puesto que macOS admite cambios críticos en la política de seguridad (por ejemplo, desactivar el arranque seguro o la SIP) que no se permiten en otras plataformas. En un Mac con chip de Apple, esta protección abarca claves de FileVault, ya que FileVault se implementa mediante Protección de datos (clase C).
La clave resultante de intrincar la contraseña del usuario, la clave SKP a largo plazo y la clave 1 de hardware (el UID de Secure Enclave) se denomina clave derivada de la contraseña. Esta clave se usa para proteger el repositorio de claves del usuario (en todas las plataformas compatibles) y la KEK (solo en macOS), y activar a continuación el desbloqueo biométrico o el desbloqueo automático con otros dispositivos, como el Apple Watch.
El monitor de arranque de Secure Enclave captura la medición del sistema operativo de Secure Enclave que se carga. Cuando la ROM de arranque del procesador de aplicaciones mide el manifiesto Image4 conectado al LLB, ese manifiesto contiene una medición del resto del firmware enlazado por el sistema que también se carga. El archivo LocalPolicy contiene las configuraciones de seguridad principales de macOS que se cargan. LocalPolicy también incluye el campo nsih, que es un hash del manifiesto Image4 de macOS. El manifiesto Image4 de macOS contiene tanto mediciones del firmware enlazado con macOS y objetos de arranque troncales de macOS, como la colección de kernel de arranque o el hash raíz del volumen del sistema firmado (SSV).
Si un atacante es capaz de cambiar inesperadamente cualquiera de los componentes anteriormente medidos del firmware, el software o la configuración de seguridad, se modifican las mediciones almacenadas en los registros de hardware. La modificación de las mediciones hace que la clave raíz de la medición del sistema (SMRK) derivada del criptohardware derive en un valor diferente, lo que rompe el sello de la jerarquía de claves. Esto provoca que la clave de dispositivo de la medición del sistema (SMDK) sea inaccesible, lo que a su vez hace que la KEK y, por lo tanto, los datos sean igualmente inaccesibles.
Sin embargo, cuando el sistema no es atacado, debe tener en cuenta las actualizaciones de software legítimas que modifican las mediciones del firmware y el campo nsih de LocalPolicy para apuntar a nuevas mediciones de macOS. En otros sistemas que intentan incorporar mediciones del firmware, pero que no tienen una fuente de verdad conocida, el usuario está obligado a desactivar la seguridad, actualizar el firmware y, a continuación, volver a activarla para que se pueda capturar una nueva línea base de medición. Esto aumenta significativamente el riesgo de que un atacante pueda alterar el firmware durante una actualización de software. El hecho de que los manifiestos Image4 contengan todas las mediciones necesarias ayuda al sistema. El hardware que desencripta el SMDK con el SMRK cuando las mediciones coinciden durante un arranque normal también puede encriptar el SMDK a un futuro SMRK propuesto. Al especificar las mediciones que se esperan después de una actualización de software, el hardware puede encriptar un SMDK que sea accesible en un sistema operativo actual y que lo siga siendo en un sistema operativo futuro. Del mismo modo, cuando un cliente cambia legítimamente sus ajustes de seguridad en LocalPolicy, el SMDK debe encriptarse en el futuro SMRK en función de la medición de LocalPolicy que el LLB calcula en el siguiente arranque.