¿Cómo se protege TR-369? TLS, extremo a extremo, certificados y roles

El Agente de la ONT de un cliente reinicia el equipo, cambia el Wi-Fi o descarga firmware cuando un Controlador se lo pide. Por eso TR-369 dedica una sección entera a quién es ese Controlador y qué puede tocar. Esta guía recorre cómo USP protege el canal, el mensaje y el modelo de datos, citando el requisito de cada paso.

¿Dónde pone USP su seguridad?

Como USP une componentes que pueden usar protocolos fuera de su alcance, la seguridad debe pensarse de extremo a extremo, y por eso USP trae sus propios mecanismos (§1.6.2). La arquitectura los lista como piezas separadas: la seguridad del MTP, un sistema de confidencialidad, integridad y autenticación de identidad de extremo a extremo, y el control de acceso por elemento (§2). La comunicación entre Endpoints se protege con el MTP, con un Session Context de USP, o con ambos (§2.1), como resume el panorama de TR-369.

1. MTPHandshake TLSEl Agente le exige un certificado X.509 a su par.
2. AutenticaciónCertificado verificadoEl Endpoint ID del certificado debe coincidir con el from_id del Record.
3. AutorizaciónRol determinadoAsignado, heredado de una CA de confianza o untrusted en el primer uso.
4. Cada mensajeRevisión de permisosEl rol debe permitir la acción antes de que el Agente la ejecute.

¿Qué protege TLS en el MTP?

R-MTP.0 exige transporte seguro cuando los mensajes USP cruzan fronteras entre redes, y se espera que los MTP que corren sobre TCP implementen al menos TLS 1.2 (§4.1.2). Tres reglas definen cómo lo usa el Agente:

• El par presenta un certificado. Cuando TLS protege un MTP, el Agente debe exigir un certificado X.509 (R-MTP.1).
• El certificado nombra al Endpoint. Lleva el Endpoint ID en la extensión subjectAltName, y los Records cuyo from_id no coincida no se deben procesar (R-SEC.0a). Explicamos los Endpoint IDs en Agente vs Controlador en USP.
• El reloj importa. Un Agente que puede obtener la hora absoluta debería esperarla antes de establecer TLS. Si se conecta sin ella, debe ignorar las fechas de validez del certificado; con la hora exacta, debe verificarlas (R-MTP.2, R-MTP.3).

La especificación también recomienda que los Agentes cifren todos los MTP, que activen ese cifrado por defecto y que no implementen la opción de desactivarlo (§8.1). Las reglas TLS de cada binding están en transportes USP comparados.

¿Cuándo no basta el cifrado del MTP?

Cuando hay algo en medio. Si la conexión MTP va directa entre Agente y Controlador, el cifrado del MTP basta para lograr cifrado y seguridad de extremo a extremo (§8). Si hay un proxy o un broker entre los dos, se requiere el End to End Message Exchange de la capa USP, o que el intermediario sea una parte confiable del ecosistema de extremo a extremo (§8).

Ese intermediario confiable es un Trusted Broker: verifica que el from_id de cada Record coincida con el certificado o las credenciales del Endpoint, o forma parte de un ecosistema cerrado cuyos Endpoints no falsifican su ID (§1.4). Debe autenticar a cada cliente con un certificado de cliente único y garantizar que su comunicación no pueda reenviarse a terceros (R-SEC.4b). Y no debe inspeccionar las cargas USP que viajan dentro de los USP Records (R-SEC.4c).

Cuando el MTP no protege un Record, quien lo envía igual debe proteger la integridad de sus campos fuera de la carga (R-E2E.29), con una firma ECDSA P-256 o, si ya existe una sesión TLS, con un HMAC basado en SHA-256 (§6.3).

¿Cómo funciona el Secure Message Exchange de extremo a extremo?

Existe por los transportes con broker y los proxies: los bindings solo protegen cada tramo (§6.4). El Endpoint de origen protege la carga antes de segmentarla y enviarla, y el Endpoint receptor la descifra después de reensamblarla (§6.4). El campo payload_security del Record indica cómo: PLAINTEXT o TLS12, que significa TLS 1.2 o superior (§4.1.3.1).

El propio handshake TLS viaja dentro de USP Records, así que los Endpoints que usan TLS12 deben intercambiar Records dentro de un E2E Session Context (R-E2E.41). El Endpoint que inició el Session Context actúa como cliente TLS, y una sesión TLS nueva toma dos viajes de ida y vuelta (§6.4.1.1).

¿Cómo decide un Agente si confía en un Controlador?

Los Controladores se autentican con certificados X.509, o con secretos compartidos en un MTP UNIX domain socket (§8.1). Antes de procesar el mensaje de un Controlador, el Agente debe tener la información del certificado de ese Controlador, o la de un Trusted Broker, y una conexión protegida criptográficamente (R-SEC.0). Después determina su rol:

• Autoridades de certificación de confianza. El Agente puede confiar en una CA solo para responder por la identidad de un Controlador, o también para otorgarle un rol que el Controlador hereda (§8.3, §8.9.2.4). La información guardada de la CA incluye como mínimo una huella (fingerprint) y su algoritmo (R-SEC.2).
• Certificados autofirmados y TOFU. Aceptarlos es política del Agente. Si los permite, el Controlador recibe un rol “untrusted” en el primer uso (R-SEC.6): el Agente confía en el certificado para cifrar, pero restringe mucho lo que ese Controlador puede hacer (§8.5). El Agente debe recordar qué certificado corresponde a qué Endpoint ID; si no, cada uso pasa a ser un primer uso (R-SEC.8, §8.5).
• Challenges (desafíos). Una frase de acceso o un PIN, por ejemplo impreso en la caja, puede elevar el rol de un Controlador. El valor de fábrica debe ser único por Agente, no deducible de lo que este revela, y con intentos limitados (§8.7, R-SEC.14 a R-SEC.16).

Un Agente debe borrar todas las sesiones de cifrado y autorizaciones de rol que tenga en caché cuando se reinicia (R-SEC.21).

¿Cómo autentican los Controladores a los Agentes?

Los Controladores deben autenticar a los Agentes con certificados X.509, con un secreto compartido o con un Trusted Broker que responda por ellos (R-SEC.9). La especificación desaconseja los secretos compartidos que no son únicos por dispositivo, y también un mismo certificado compartido por varios Agentes mediante un Endpoint ID con comodín, que los Controladores no están obligados a soportar (§8.6, R-SEC.11).

Con los certificados autofirmados de los Agentes, la decisión es del Controlador: rechazarlos, dejar que una persona apruebe cada Agente o aceptarlos automáticamente (§8.5).

¿Qué puede hacer un Controlador una vez que es de confianza?

Un rol (Role) es el conjunto de permisos, una lista de control de acceso, que un Agente le otorga a un Controlador sobre su Instantiated Data Model (§1.4). El Agente debe confirmar esos permisos antes de ejecutar cualquier acción de un mensaje (R-SEC.1); si faltan, el error es 7006 “Permission denied” (§7.8).

Los roles se definen en las entradas Device.LocalAgent.ControllerTrust.Role.. Cada entrada Permission indica sus Targets (las rutas que cubre), un Order y cuatro cadenas de permisos: Param, Obj, InstantiatedObj y CommandEvent (§8.9.2.1). Cada cadena tiene cuatro caracteres, siempre en el orden rwxn, por Read, Write, Execute y Notify, con un guion por cada permiso que falta. El ejemplo de la especificación da acceso total y luego retira la configuración de confianza (se muestran las líneas de Param):

Device.LocalAgent.ControllerTrust.Role.1.Permission.1.Order = 1
Device.LocalAgent.ControllerTrust.Role.1.Permission.1.Targets = Device
Device.LocalAgent.ControllerTrust.Role.1.Permission.1.Param = rwxn
Device.LocalAgent.ControllerTrust.Role.1.Permission.2.Order = 2
Device.LocalAgent.ControllerTrust.Role.1.Permission.2.Targets = Device.LocalAgent.ControllerTrust
Device.LocalAgent.ControllerTrust.Role.1.Permission.2.Param = ----

Dentro de un mismo rol, donde los Targets se superponen gana la entrada con el Order mayor. Entre varios roles, los permisos se suman: r--- y ---n dan r--n (§8.9.2.3). Tres roles especiales tienen funciones fijas (§8.9.2.2): UntrustedRole para cualquier Controlador que aún no tiene otro rol autorizado, BannedRole para certificados revocados y SecuredRoles para los Controladores autorizados a leer Parameters protegidos (secured). Cualquier otro Controlador los lee como un valor nulo, por ejemplo una cadena vacía. Los Agentes también deberían exponer el AssignedRole y el InheritedRole de cada Controlador, para que los usuarios detecten Controladores intrusos (R-SEC.1a).