Resumen

  • HPKE Base permite cifrar para quien posee una clave privada KEM receptora. Que Open() funcione prueba una validación criptográfica acotada, no la identidad ni el permiso del remitente.
  • PSK, Auth y AuthPSK prueban posesión de material secreto configurado bajo condiciones concretas. No sustituyen el registro de identidad, el formato del mensaje, el control de orden, la revocación o la política de ejecución.
  • El control serio conserva pruebas de cada relevo: selección de clave, modo y suite, contexto, descifrado, análisis, frescura, autorización y efecto observado.

Un auditor recibe una exportación de eventos. En una fila figura una clave receptora; en otra, un valor encapsulado; en una tercera, open=success. El caso se cierra con una frase cómoda: «la instrucción llegó autenticada».

La frase une hechos que RFC 9180 separa. Hybrid Public Key Encryption define cómo combinar un KEM, un KDF y un AEAD para construir un contexto de cifrado. En modo Base, permite que alguien cifre hacia una clave pública receptora y que el titular de la privada abra el resultado. No incluye autenticación de remitente. Tampoco decide cómo se distribuyó la clave pública, qué envoltorio transporta las piezas, qué significa el texto plano ni qué acto posterior puede desencadenar.

Ese límite no rebaja HPKE: evita que el estándar prometa una autoridad que no puede verificar. El problema aparece cuando una organización completa las partes ausentes con una inferencia. Si un descifrado fue correcto, concluye que el mensaje vino de un socio autorizado. Si una clave está nombrada en un inventario, concluye que su uso estaba vigente. Si el texto contiene un número de cuenta, concluye que el número fue presentado por quien tenía derecho a presentarlo.

Cada conclusión necesita evidencia distinta. El éxito criptográfico es una pieza valiosa de la cadena, no la cadena entera.

La clave receptora no elige al emisor

La suite HPKE reúne tres funciones. El KEM produce un secreto compartido y una encapsulación que el receptor puede procesar; el KDF deriva el material de contexto; el AEAD cifra el texto plano y autentica los datos asociados. La combinación es interoperable porque cada componente tiene interfaces y parámetros definidos.

En Base, el emisor realiza la configuración con la clave pública del receptor, pkR, y con info, una información que aporta la aplicación. El receptor reconstruye el contexto a partir de enc, su clave privada skR y el mismo contexto. La operación final puede devolver el texto plano o fallar.

Lo que una apertura correcta demuestra es preciso: los bytes recibidos fueron aceptados por ese contexto bajo esa suite y esa clave. No demuestra que una parte remota concreta produjo los bytes. Cualquier parte que conociera la clave pública receptora podía crear un cifrado Base compatible. El receptor obtiene confidencialidad hacia su propia clave, no una biografía del emisor.

Esto importa incluso dentro de una red cerrada. Una clave pública puede estar disponible para muchas cargas de trabajo, repositorios de configuración o intermediarios. Puede que todas sean legítimas para cifrar telemetría y que solo una pueda autorizar cambios de producción. Base no distingue los propósitos. La regla que asocia clave, canal, tipo de mensaje y derecho de pedir un cambio debe existir fuera del primitive.

Los datos asociados tampoco inventan esa regla. La aplicación puede enlazar un identificador de cliente, una versión o una ruta al texto cifrado de manera que la verificación falle si los bytes cambian. Pero HPKE no certifica que el identificador sea verdadero ni que el emisor estuviera habilitado para usarlo. La integridad de una afirmación no es prueba de la autoridad para formularla.

Poseer una clave no es ser la identidad que la empresa necesita

Los modos PSK, Auth y AuthPSK añaden garantías que Base no posee. PSK permite que el receptor compruebe la posesión del secreto compartido. Auth relaciona el contexto con la posesión de la clave privada KEM del emisor. AuthPSK combina ambas fuentes.

Hay que conservar la gramática de esas garantías. Son garantías sobre secretos o pares de claves configurados. Una empresa puede asociar el mismo material a un servicio, una cuenta de automatización, una persona, un dispositivo o un equipo entero. Esa asociación depende de alta, custodia, rotación, suspensión y revocación. No emerge de AuthDecap().

RFC 9180 es explícito: Auth y AuthPSK autentican la pareja de claves del emisor y, si una aplicación quiere vincular otra identidad —por ejemplo, un dominio o una dirección— debe incluirla en info. Esto obliga a que el vínculo sea elegido, almacenado y verificado por el protocolo de aplicación. No se debe ocultar en una etiqueta de registro que nadie puede reconstruir.

También hay una reserva técnica. Las variantes DHKEM Auth y AuthPSK especificadas tienen una limitación de impersonación bajo compromiso de clave en las condiciones que señala el RFC. Un éxito de Auth no equivale a una firma universal e irreversible de voluntad humana. Es una propiedad de posesión de clave, en un modelo de amenaza y un momento determinados.

Por eso un panel no debería traducir auth en «aprobado». Para llegar a ese último estado hacen falta, al menos, un vínculo clave-identidad vigente, una política que otorgue alcance a esa identidad y una decisión de la aplicación sobre el contenido. Convertir los tres pasos en una palabra vuelve invisible al responsable de cada uno.

El formato exterior es una frontera de seguridad

HPKE permite información autenticada durante la creación del contexto mediante info y por mensaje mediante AAD; el exportador tiene otro contexto. La división ayuda a no mezclar los datos comunes de una sesión con los de un mensaje individual.

Sin embargo, RFC 9180 no define un formato de cable para mensajes HPKE. La aplicación debe especificar sin ambigüedad cómo contiene enc, el texto o los textos cifrados, su orden y cualquier info no implícito. Si el receptor mantiene más de una clave pública, la propia selección puede tener que viajar en el formato.

Una operación criptográfica no puede compensar un sobre ambiguo. El análisis exterior decide dónde terminan los campos, qué versión se usa, qué suite se espera y qué contexto debe reconstruirse. Antes de abrir una carga, el receptor necesita una gramática que rechace combinaciones inconsistentes; después de abrirla, necesita un esquema que rechace significados impropios.

Considérese una carga que contiene «aprobar». HPKE puede proteger esos caracteres contra modificaciones dentro del contexto. No define si el mensaje es una solicitud, una orden, una simulación o un registro histórico. No dice quién puede aprobar ni qué objeto está siendo aprobado. Esas condiciones pertenecen al validador semántico y al motor de política. Si el sistema ejecuta antes de imponerlas, el defecto no está en la confidencialidad; está en haber concedido autoridad a un descifrado.

Orden, repetición y memoria de las claves

La frescura no se deriva del cifrado. Dentro de un mismo contexto, RFC 9180 exige que los textos se presenten en el orden en que fueron sellados, lo que aporta una protección de repetición limitada. Fuera de ese flujo, HPKE no ofrece otra protección contra replay. Las aplicaciones multimensaje deben imponer orden y detectar pérdida; suelen hacerlo con una secuencia o identificador en el formato y lo unen como datos asociados.

La ventana temporal, el identificador de idempotencia, la expiración y la acción frente a un duplicado son por tanto controles de aplicación. Una instrucción que fue válida hace una hora puede ser descifrada exactamente y estar prohibida ahora. El hecho de que el byte sea auténtico para un contexto no renueva el mandato que quizá contenía.

La selección de algoritmo tampoco se gobierna sola. El RFC presupone acuerdo entre emisor y receptor; según el método de negociación, un intermediario puede empujar algoritmos menos deseables. El identificador de la suite deja evidencia de lo usado, no de que la elección cumpliera la política ni de que la negociación estuviera protegida.

Por último, las claves receptoras dejan una historia. RFC 9180 indica que los textos no tienen secreto hacia adelante frente al compromiso de la clave receptora: quien obtenga después el secreto de largo plazo puede descifrar textos antiguos enviados a esa clave. No describe un incidente concreto. Sí obliga a preguntar cuánto tiempo se conservan mensajes, qué rotación se exige y qué archivos podrían hacerse legibles retrospectivamente.

Un expediente que permite reconstruir la decisión

En la entrada, registre qué clave pública receptora se eligió, por quién fue emitida, qué propósito admite, cómo se distribuyó y cuándo fue retirada. Una clave pública publicada es un destino criptográfico; no es una licencia abierta para todos los tipos de solicitud.

En la preparación, registre modo, suite, fuente de PSK o clave emisora, info, AAD, formato y negociación. En la recepción, registre identificadores o huellas seguras de enc y del texto, la clave receptora y el resultado de contexto y de Open(). Describa el éxito con exactitud y no permita que borre el resultado del parser o de la política.

En la interpretación, añada versión de esquema, tipo de mensaje, identidad asociada, estado de revocación, control de repetición, evaluación de frescura y decisión de política. Una carga válida puede ser rechazada correctamente por tener una clave retirada, un locatario equivocado, una secuencia vieja o una operación fuera de alcance.

En el efecto, conserve por separado lo solicitado, lo autorizado, lo ejecutado y lo observado por otro sistema. Un permiso no asegura ejecución; una ejecución no prueba un resultado seguro. Solo esta cadena permite responder después por qué un conjunto de bytes acabó cambiando algo real.