Contenidos del archivo LocalPolicy en computadoras Mac con Apple Chip

Transferencia de propiedad entre sistemas operativos

El acceso a la clave de identidad del propietario (OIK) se denomina “Propiedad”. Esta propiedad es necesaria para permitir que los usuarios renuncien a LocalPolicy después de realizar cambios en la política o el software. La OIK está protegida con la misma jerarquía de claves que se describe en Protección de claves selladas (SKP) y por la misma clave de encriptación de claves (KEK) que la clave de encriptación del volumen (VEK). Esto significa que normalmente está protegida tanto por la contraseña del usuario como las medidas del sistema operativo y la política. Sólo hay una OIK para todos los sistemas operativos de la Mac, por lo que, al instalar un segundo sistema operativo, se requiere el consentimiento explícito de los usuarios del primer sistema operativo para transferir la Propiedad a los usuarios del segundo sistema operativo. Sin embargo, los usuarios aún no existen para el segundo sistema operativo cuando el instalador se ejecuta desde el primer sistema operativo. Normalmente, los usuarios de los sistemas operativos no se generan hasta que se inicia el sistema operativo y se ejecuta el asistente de configuración. Por lo tanto, se requieren dos nuevas acciones al instalar un segundo sistema operativo en una Mac con Apple Chip:

• Crear un archivo LocalPolicy para el segundo sistema operativo

• Preparar un “Usuario de instalación” para transferir la Propiedad

Cuando se ejecuta un asistente de instalación y se orienta la instalación para un volumen en blanco secundario, un mensaje le pregunta al usuario si quiere copiar un usuario del volumen actual para que sea el primer usuario del segundo volumen. Si el usuario dice que sí, el “Usuario de instalación” que se crea es, en realidad, una KEK que se deriva de la contraseña y las claves de hardware del usuario seleccionado, que luego se utiliza para encriptar la OIK a medida que se entrega al segundo sistema operativo. Después, desde el asistente de instalación del segundo sistema operativo, se solicita la contraseña de ese usuario para permitir el acceso a la OIK en el Secure Enclave para el nuevo sistema operativo. Si un usuario elige no copiar un usuario, el “Usuario de instalación” se crea de la misma manera, pero se usa una contraseña vacía en lugar de la contraseña de un usuario. Este segundo flujo existe para ciertos escenarios de administración del sistema. Sin embargo, los usuarios que quieran tener varias instalaciones de volúmenes y deseen realizar la transferencia de Propiedad de la manera más segura deben optar siempre por copiar un usuario del primer sistema operativo al segundo.

LocalPolicy en una Mac con Apple Chip

En el caso de las Mac con Apple Chip, el control de la política de seguridad local se ha delegado a una aplicación que se ejecuta en el Secure Enclave. Este software puede usar las credenciales del usuario y el modo de arranque del CPU principal para determinar quién puede cambiar la política de seguridad y desde cuál entorno de arranque. Esto ayuda a evitar que el software malicioso utilice los controles de la política de seguridad contra el usuario al reducir la seguridad para obtener más privilegios.

Propiedades del manifiesto de LocalPolicy

El archivo LocalPolicy contiene algunos 4CC arquitectónicos que se encuentran en la mayoría de los archivos Image4, como el ID de modelo o tarjeta (BORD) que indica un chip de Apple en particular (CHIP), o un identificador de chip exclusivo (ECID). Sin embargo, los siguientes 4CC se centran sólo en las políticas de seguridad que los usuarios pueden configurar.

Hash de valor único de LocalPolicy (lpnh)

• Tipo: OctetString (48)

• Entornos mutables: 1TR, recoveryOS, macOS

• Descripción: el lpnh se utiliza para evitar la reproducción de LocalPolicy. Es un hash SHA384 del valor único de LocalPolicy (LPN) que está guardado en el componente de almacenamiento seguro y que se puede acceder mediante la ROM de arranque del Secure Enclave o el Secure Enclave. El valor sin procesar de antirreproducción nunca es visible para el procesador de aplicaciones, sólo lo es para el sepOS. Un atacante que intente convencer a LLB de que un LocalPolicy previo que se capturó era válido debería colocar un valor en el componente de almacenamiento seguro que tiene el mismo valor lpnh que se encuentra en el LocalPolicy que quiere volver a reproducir. Normalmente, sólo hay un LPN válido en el sistema, excepto durante las actualizaciones de software, donde hay dos válidos de forma simultánea para permitir la posibilidad de tener un respaldo y arrancar el software anterior en caso de un error en la actualización. Cuando cambia un LocalPolicy para cualquier sistema operativo, todas las políticas se vuelven a firmar con el nuevo valor lpnh correspondiente al nuevo LPN que se encuentra en el componente de almacenamiento seguro. Este cambio ocurre cuando el usuario modifica la configuración de seguridad o crea nuevos sistemas operativos con un nuevo LocalPolicy para cada uno.

Hash de valor único de la política remota (rpnh)

• Tipo: OctetString (48)

• Entornos mutables: 1TR, recoveryOS, macOS

• Descripción: el rpnh tiene el mismo comportamiento que el lpnh, pero sólo se actualiza cuando lo hace la política remota, tal como cuando se cambia el estado de registro de Encontrar. Este cambio ocurre cuando el usuario modifica el estado de Encontrar en su Mac.

Hash de valor único de recoveryOS (ronh)

• Tipo: OctetString (48)

• Entornos mutables: 1TR, recoveryOS, macOS

• Descripción: el ronh tiene el mismo comportamiento que el lpnh pero sólo se encuentra en el LocalPolicy de recoveryOS y sólo se actualiza cuando lo hace el volumen recoveryOS del sistema, por ejemplo cuando hay una actualización de software. Se usa un valor de antirreproducción separado de lpnh y rpnh para que cuando Encontrar ponga un dispositivo en un estado desactivado, los sistemas operativos existentes puedan desactivarse (al eliminar su LPN y RPN del componente de almacenamiento seguro), mientras que se permite el arranque con el recoveryOS del sistema. De esta manera, los sistemas operativos se pueden volver a activar cuando el propietario del sistema demuestra su control sobre el sistema al ingresar su contraseña de iCloud que utiliza para la cuenta de Encontrar. Este cambio ocurre cuando un usuario actualiza el recoveryOS del sistema o crea nuevos sistemas operativos.

Hash del manifiesto Image4 de siguiente etapa (nsih)

• Tipo: OctetString (48)

• Entornos mutables: 1TR, recoveryOS, macOS

• Descripción: el campo nsih representa un hash SHA384 de la estructura de datos del manifiesto Image4 que describe el arranque de macOS. El manifiesto de Image4 de macOS contiene mediciones para todos los objetos de arranque tales como iBoot, la caché de confianza estática, el árbol de dispositivos, la colección del kernel de arranque y el hash raíz del volumen de sistema firmado (SSV). Cuando se le instruye a LLB que arranque un macOS específico, se asegura de que el hash del manifiesto de Image4 del macOS adjunto a iBoot coincida con lo capturado en el campo nsih de LocalPolicy. De esta forma, el nsih captura la intención del usuario sobre cuál es el sistema operativo para el que se creó un LocalPolicy. Los usuarios cambian implícitamente el valor de nsih cuando realizan una actualización de software.

Hash del manifiesto de Image4 de Cryptex1 (spih)

• Tipo: OctetString (48)

• Entornos mutables: 1TR, recoveryOS, macOS

• Descripción: el campo spih representa un hash SHA384 de la estructura de datos del manifiesto Image4 de Cryptex1. Este manifiesto contiene mediciones de sus criptexs, los sellos de su sistema de archivos y su caché de confianza asociada. Cuando se inicia macOS, el kernel XNU y la capa de protección de página se aseguran de que el hash del manifiesto de Image4 de Cryptex1 coincida con lo que iBoot publicó en el campo spih de LocalPolicy. Los usuarios cambian implícitamente el valor de spih cuando instalan una respuesta rápida de seguridad o realizan una actualización de software. El hash del manifiesto de Image4 de Cryptex1 puede actualizarse de forma independiente del hash del manifiesto Image4 de siguiente etapa.

Generación de Cryptex1 (stng)

• Tipo: entero de 64 bits sin firmar

• Entornos mutables: 1TR, recoveryOS, macOS

• Descripción: el campo stng es un valor de contador que representa cuándo se actualizó por última vez el hash del manifiesto Image4 de Cryptex1 en un LocalPolicy. Proporciona un valor de antirreproducción en lugar de lpnh durante la evaluación de la capa de protección de página de la política local para aplicar el criptex entrante. Los usuarios aumentan implícitamente el valor de stng cuando instalan una respuesta rápida de seguridad o una actualización de software.

Hash de la política (auxp) de la colección del kernel auxiliar (AuxKC)

• Tipo: OctetString (48)

• Entornos mutables: macOS

• Descripción: el auxp es un hash SHA384 de la política de la lista de kexts autorizadas por el usuario (UAKL). Esto se utiliza al momento de generar la AuxKC para ayudar a garantizar que sólo se incluyan kexts autorizadas por el usuario en la AuxKC. smb2 es un requisito previo para configurar este campo. Los usuarios cambian el valor auxp de forma implícita cuando cambian la UAKL al aprobar una kext desde el panel Privacidad y seguridad en Configuración del Sistema (macOS 13 o versiones posteriores) o el panel Seguridad y privacidad de Preferencias del Sistema (macOS 12 o versiones anteriores).

Hash del manifiesto Image4 (auxi) de la colección del kernel auxiliar (AuxKC)

• Tipo: OctetString (48)

• Entornos mutables: macOS

• Descripción: después de que el sistema verifica que el hash de la UAKL coincide con lo que se encuentra en el campo auxp de LocalPolicy, solicita que la AuxKC esté firmada por la aplicación de procesador del Secure Enclave, que es responsable de la firma de LocalPolicy. Posteriormente, se coloca en LocalPolicy un hash SHA384 de la firma del manifiesto Image4 de AuxKC para evitar la posibilidad de mezclar y coincidir una AuxKC previamente firmada con un sistema operativo en el momento del arranque. Si iBoot encuentra el campo auxi en LocalPolicy, intenta cargar la AuxKC desde el disco y valida su firma. Después, verifica también que el hash de Image4 adjunto a la AuxKC coincida con el valor encontrado en el campo auxi. Si la AuxKC no se puede cargar por cualquier motivo, el sistema continúa con el arranque sin este objeto de arranque y, por lo tanto, sin las kexts de terceros. El campo auxp es un requisito previo para configurar el campo auxi en LocalPolicy. Los usuarios cambian el valor auxi de forma implícita cuando cambian la UAKL al aprobar una kext desde el panel Privacidad y seguridad en Configuración del Sistema (macOS 13 o versiones posteriores) o el panel Seguridad y privacidad de Preferencias del Sistema (macOS 12 o versiones anteriores).

Hash de recepción (auxr) de la colección del kernel auxiliar (AuxKC)

• Tipo: OctetString (48)

• Entornos mutables: macOS

• Descripción: el auxr es un hash SHA384 de la recepción de AuxKC que indica el conjunto exacto de kexts incluidas en la AuxKC. La recepción de AuxKC puede ser un subconjunto de la UAKL, debido a que las kexts se pueden excluir de la AuxKC, incluso si están autorizadas por el usuario, si se sabe que se utilizan para ataques. Además, algunas kexts que se pueden usar para romper el límite usuario-kernel podrían causar una disminución en la funcionalidad, tal como la incapacidad de usar Apple Pay o de reproducir contenido 4K y HDR. Los usuarios que desean tener estas funcionalidades deberían elegir una inclusión de AuxKC más restrictiva. El campo auxp es un requisito previo para configurar el campo auxr en LocalPolicy. Los usuarios cambian el valor auxr de forma implícita cuando crean una nueva AuxKC desde el panel Privacidad y seguridad de Configuración del Sistema (macOS 13 o versiones posteriores) o el panel Seguridad y privacidad de Preferencias del Sistema (macOS 12 o versiones anteriores).

Hash del manifiesto de Image4 de CustomOS (coih)

• Tipo: OctetString (48)

• Entornos mutables: 1TR

• Descripción: el coih es un hash SHA384 del manifiesto de Image4 de CustomOS. iBoot (en lugar del kernel XNU) utiliza la carga útil de ese manifiesto para transferir el control. Los usuarios cambian el valor de coih implícitamente cuando usan la herramienta de línea de comandos kmutil configure-boot en 1TR.

UUID del grupo de volúmenes APFS (vuid)

• Tipo: OctetString (16)

• Entornos mutables: 1TR, recoveryOS, macOS

• Descripción: el vuid indica el grupo de volúmenes que el kernel debe usar como raíz. Este campo es principalmente informativo y no se usa para restricciones de seguridad; y el usuario configura el vuid de forma implícita al crear una instalación de sistema operativo nueva.

UUID de grupo (kuid) de la clave de encriptación clave (KEK)

• Tipo: OctetString (16)

• Entornos mutables: 1TR, recoveryOS, macOS

• Descripción: el valor kuid indica el volumen que se arrancó. La clave de encriptación clave se ha usado generalmente para la protección de datos. Para cada LocalPolicy, se utiliza para proteger la clave de firma de LocalPolicy, y el usuario configura el kuid de forma implícita al crear una instalación de sistema operativo nueva.

Medición de la política de arranque confiable (TBPM) del recoveryOS enlazado

• Tipo: OctetString (48)

• Entornos mutables: 1TR, recoveryOS, macOS

• Descripción: una medición de la política de arranque confiable (TBPM) del recoveryOS enlazado es un cálculo del hash SHA384 iterativo especial sobre el manifiesto Image4 de un LocalPolicy, sin incluir los valores de antirreproducción, que proporciona una medición constante a lo largo del tiempo (ya que los valores de antirreproducción como lpnh se actualizan frecuentemente). El campo prot se encuentra sólo en cada LocalPolicy de macOS, y proporciona un enlace para indicar el LocalPolicy de recoveryOS que corresponde al de macOS.

Política local de recoveryOS firmada por el Secure Enclave (hrlp)

• Tipo: booleano

• Entornos mutables: 1TR, recoveryOS, macOS

• Descripción: hrlp indica si el valor de prot (arriba) es o no la medición de un LocalPolicy de recoveryOS firmado por el Secure Enclave. Si no lo es, el LocalPolicy de recoveryOS se firma mediante el servidor de firmas en línea de Apple, que firma cosas como archivos Image4 de macOS.

Versión del sistema operativo local (love)

• Tipo: booleano

• Entornos mutables: 1TR, recoveryOS, macOS

• Descripción: el parámetro love indica la versión del sistema operativo para la cual se crea la política local, LocalPolicy. La versión se obtiene del siguiente manifiesto de estado durante la creación de LocalPolicy, y se utiliza para aplicar las restricciones de vinculación de recoveryOS.

Arranque múltiple seguro (smb0)

• Tipo: booleano

• Entornos mutables: 1TR, recoveryOS

• Descripción: si el smb0 está presente y es verdadero, LLB permite que el manifiesto Image4 de siguiente etapa tenga una firma global en lugar de requerir una firma personalizada. Los usuarios pueden cambiar este campo mediante Utilidad de Seguridad de Arranque o bputil para cambiar a Seguridad reducida.

Arranque múltiple seguro (smb1)

• Tipo: booleano

• Entornos mutables: 1TR

• Descripción: si el smb1 está presente y es verdadero, iBoot permite que objetos tales como la colección del kernel personalizada se firmen mediante el Secure Enclave con la misma clave que LocalPolicy. La presencia de smb0 es un requisito previo para la presencia de smb1. Los usuarios pueden cambiar este campo con las herramientas de línea de comandos tales como csrutil o bputil para cambiar a Seguridad permisiva.

Arranque múltiple seguro (smb2)

• Tipo: booleano

• Entornos mutables: 1TR

• Descripción: si el smb2 está presente y es verdadero, iBoot permite que la colección del kernel auxiliar se firme mediante el Secure Enclave con la misma clave que LocalPolicy. La presencia de smb0 es un requisito previo para la presencia de smb2. Los usuarios pueden cambiar este campo mediante Utilidad de Seguridad de Arranque o bputil para cambiar a Seguridad reducida y activar las kexts de terceros.

Arranque múltiple seguro (smb3)

• Tipo: booleano

• Entornos mutables: 1TR

• Descripción: si el smb3 está presente y es verdadero, indica que un usuario en el dispositivo ha activado el control mediante administración de dispositivos móviles (MDM) en su sistema. La presencia de este campo hace que la aplicación del procesador del Secure Enclave que controla el archivo LocalPolicy acepte la autenticación MDM en lugar de requerir una autenticación de usuario local. Los usuarios pueden cambiar este campo con Utilidad de Seguridad de Arranque o bputil para activar el control administrado sobre las actualizaciones de software y las kexts de terceros. En macOS 11.2 o versiones posteriores, la solución MDM también puede iniciar una actualización a la versión más reciente de macOS si el modo de seguridad actual es Máxima seguridad.

Arranque múltiple seguro (smb4)

• Tipo: booleano

• Entornos mutables: macOS

• Descripción: si el smb4 está presente y es verdadero, indica que el dispositivo ha activado el control mediante MDM del sistema operativo usando Apple School Manager, Apple Business Manager o Apple Business Essentials. La presencia de este campo hace que la aplicación del Secure Enclave que controla el archivo LocalPolicy acepte la autenticación MDM en lugar de requerir una autenticación de usuario local. La solución MDM cambia este campo cuando detecta que el número de serie de un dispositivo aparece en cualquiera de esos tres servicios.

Protección de la integridad del sistema (sip0)

• Tipo: entero de 64 bits sin firmar

• Entornos mutables: 1TR

• Descripción: el valor sip0 contiene los bits de la política de protección de la integridad del sistema (SIP) que anteriormente estaban almacenados en la NVRAM. Los nuevos bits de la política SIP se agregan aquí (en lugar de usar los campos del archivo LocalPolicy como se muestra a continuación) si sólo se usan en macOS y no los utiliza LLB. Los usuarios pueden cambiar este campo con csrutil desde 1TR para desactivar la SIP y cambiar a Seguridad permisiva.

Protección de la integridad del sistema (sip1)

• Tipo: booleano

• Entornos mutables: 1TR

• Descripción: si el valor sip1 está presente y es verdadero, iBoot permite fallos para verificar el hash raíz del SSV. Los usuarios pueden cambiar este campo usando csrutil o bputil desde 1TR.

Protección de la integridad del sistema (sip2)

• Tipo: booleano

• Entornos mutables: 1TR

• Descripción: si el valor sip2 está presente y es verdadero, iBoot no bloqueará el registro de hardware de la región de sólo lectura de texto configurable (CTRR) que marca la memoria del kernel como no escribible. Los usuarios pueden cambiar este campo usando csrutil o bputil desde 1TR.

Protección de la integridad del sistema (sip3)

• Tipo: booleano

• Entornos mutables: 1TR

• Descripción: si el valor sip3 está presente y es verdadero, iBoot no aplicará su lista autorizada integrada para la variable NVRAM boot-args, que de otra forma filtraría las opciones pasadas al kernel. Los usuarios pueden cambiar este campo usando csrutil o bputil desde 1TR.

Certificados y RemotePolicy

Como se describe en Administración y creación de claves de firmas para LocalPolicy, el Image4 de LocalPolicy también contiene el certificado de identidad de propietario (OIC) y el RemotePolicy incrustado.