systemd v262 reescribe el anclaje de los NvPCR para tapar un fallo en el TPM
Los TPM de serie solo ofrecen 24 PCR y el sistema operativo se queda con ocho. Los NvPCR llegaron en la v259 para ampliar sitio; la v262 cambia cómo se anclan porque el diseño anterior se podía romper arrancando otro sistema.
Cualquier TPM conforme al estándar trae veinticuatro PCR, y systemd se estaba quedando sin sitio. La respuesta llegó en la v259 con los NvPCR, registros con la misma semántica que una PCR pero alojados en la memoria no volátil del TPM, y la v262 ha reescrito su anclaje porque la versión anterior se podía romper arrancando otro sistema operativo.
Por qué faltan PCR
De esas veinticuatro, las ocho primeras (0-7) las usa el firmware para medir el arranque UEFI. La 16 es de depuración y se puede resetear, así que no sirve para guardar nada. Las 17 a 22 están reservadas para el Dynamic Root of Trust for Measurement y la 23 para soporte de aplicaciones. Al sistema operativo le quedan las PCR 8 a 15: ocho ranuras para todo.
Eso bastaría si las PCR solo se usaran para atestación remota. El verificador puede tirar del log de eventos y reconstruir qué se midió hasta llegar al valor final. Pero no es el único uso. Las PCR son también aquello contra lo que se sellan secretos locales, y eso exige valores predecibles: cada evento que entra en una PCR tiene que conocerse de antemano o la política de desbloqueo se cae. Hay eventos que por definición no se pueden predecir, como el firmware cerrado de cada placa o un login de usuario. Y ahí está el conflicto: interesa meter ese login en la quote de atestación, pero el disco raíz tiene que seguir descifrándose solo después de que alguien haya entrado. Los NvPCR resuelven eso dando a los eventos ruidosos su propio registro, fuera del camino de las PCR de las que dependen los desbloqueos.
El fallo del anclaje anterior
Hasta la v262, cada NvPCR se anclaba con un secreto aleatorio sellado contra la PCR 11 y guardado en disco. El atacante tenía dos caminos: arrancar otro sistema operativo que reprodujera los valores esperados de la PCR 11 para desellar el secreto, o directamente sustituir el secreto del disco por uno que él conociera. Con el rediseño de la v262 ese anclaje ya no depende de un fichero que el atacante controla.
El análisis original viene con un recorrido práctico que reconstruye un NvPCR desde cero contra un TPM en software, usando swtpm y tpm2-tools. La parte que merece la pena es el índice NV que hace de registro: se define en la jerarquía del owner con un handle propio, un algoritmo de hash para el nombre y atributos de lectura y escritura. El nombre no es el handle. Se calcula como el algoritmo concatenado con el hash de la estructura pública serializada del índice, de modo que cualquier cambio en sus propiedades cambia el nombre.
Para quien despliega flotas con disco cifrado y arranque medido, el detalle importa. Si el anclaje falla, el desbloqueo automático deja de ser una comodidad y pasa a ser una puerta trasera. La v262 lo corrige, pero conviene revisar qué mediciones propias se estaban colgando de la PCR 11 y si el esquema nuevo cubre ese caso.
