OpenCyber Academy
Ingeniería · Capítulo 19 · Español
Código del curso: OCA-135Capítulo 19: OCA-135-C019

Capítulo 19 — Identidad y criptografía

Aprendizaje gratuito y abierto para quienes desean proteger a las personas y la tecnología. No se necesita una cuenta para estudiar ni consultar las respuestas.

Mapa de la lección

Lección 19 publicada. Mapa, ejemplo, EX055.

flowchart TD
  N0["Resultados de aprendizaje"]
  N1["19.1 Identidades para los agentes"]
  N2["19.2 Hashes y manifiestos"]
  N3["19.3 Firmas y procedencia"]
  N4["19.4 Cifrado"]
  N5["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX055"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje"]
  N1["19.1 Identidades para los agentes"]
  N2["19.2 Hashes y manifiestos"]
  N3["19.3 Firmas y procedencia"]
  N4["19.4 Cifrado"]
  N5["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX055"]
[Resultados de aprendizaje]
    |
    v
[19.1 Identidades para los agentes]
    |
    v
[19.2 Hashes y manifiestos]
    |
    v
[19.3 Firmas y procedencia]
    |
    v
[19.4 Cifrado]
    |
    v
[Síntesis del capítulo]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX055]

Resultados de aprendizaje

Usted será capaz de (1) diseñar la identidad y el acceso para usuarios, servicios y agentes de IA; (2) aplicar hashes, firmas y cifrado a los artefactos de IA; (3) verificar la integridad de modelos y conjuntos de datos con manifiestos; y (4) explicar la procedencia y la firma en la cadena de suministro de la IA.

19.1 Identidades para los agentes

Toda acción debe poder atribuirse. Un agente de IA debe actuar en nombre de un usuario, con permisos delegados y de alcance limitado (por ejemplo, tokens OAuth restringidos a ámbitos concretos), y no con una cuenta de servicio poderosa. Las credenciales de corta duración limitan el daño si se filtran; nunca coloque credenciales en los prompts. La delegación significa que el agente nunca puede hacer más de lo que podría hacer el usuario, y los registros muestran a ambos: el usuario en cuyo nombre se ejecutó la acción y el agente que la propuso. Una cuenta de servicio compartida borra esa distinción, de modo que, tras un incidente, nadie puede saber qué conversación causó qué acción. Los tokens que duran minutos en lugar de meses hacen además que una credencial copiada de un registro sea inútil para cuando alguien intente usarla.

19.2 Hashes y manifiestos

Un hash criptográfico como SHA-256 asigna a un archivo un resumen de tamaño fijo; cualquier cambio, aunque sea de un solo bit, produce un resumen distinto. Un manifiesto enumera el resumen esperado de cada artefacto (pesos, tokenizador, configuración). El laboratorio detecta tanto un cambio de un bit en los pesos como una línea añadida a la configuración.

"""Lab H: integrity of model artefacts with SHA-256 manifests (stdlib only).
Creates synthetic 'artefact' bytes, records a manifest, then detects a
one-byte tampering and a swapped file. No real models are involved."""
import hashlib, json
files = {"model.bin": bytes(range(256)) * 40, "tokenizer.json": b'{"vocab": ["a", "b"]}',
         "config.yaml": b"layers: 4\nheads: 8\n"}
manifest = {n: hashlib.sha256(b).hexdigest() for n, b in files.items()}
print(json.dumps({k: v[:16] for k, v in manifest.items()}, indent=1))
received = dict(files)
tampered = bytearray(received["model.bin"]); tampered[5000] ^= 1
received["model.bin"] = bytes(tampered)
received["config.yaml"] = b"layers: 4\nheads: 8\ntrust_remote_code: true\n"
for n, b in sorted(received.items()):
    ok = hashlib.sha256(b).hexdigest() == manifest[n]
    print(f"{n:15s} {'OK' if ok else 'MISMATCH'}")

Salida esperada:

{
 "model.bin": "e96760a87768717b",
 "tokenizer.json": "f63d2ddabc61f2d9",
 "config.yaml": "e5bbb570ca0fcb87"
}
config.yaml     MISMATCH
model.bin       MISMATCH
tokenizer.json  OK

La salida muestra por qué cada archivo necesita su propia entrada: el tokenizador no se tocó y supera la comprobación, mientras que dos cambios distintos en dos archivos se detectan cada uno de forma independiente. Un solo bit invertido en el desplazamiento 5000 basta para cambiar por completo el resumen del archivo de pesos.

19.3 Firmas y procedencia

Un hash prueba que un archivo coincide con un manifiesto; una firma digital sobre el manifiesto prueba quién lo produjo. Firmar los artefactos del modelo y registrar su procedencia (qué datos, código y canalización los produjeron) permite a los consumidores verificar su origen. Esto aborda OWASP LLM03 (cadena de suministro) y los riesgos de puertas traseras en modelos de terceros (Gu et al., arXiv:1708.06733). Las firmas trasladan la cuestión de la confianza a la clave de firma: quién la tiene, cómo se protege y cómo sabe un consumidor qué clave esperar. La procedencia añade un contexto que una firma por sí sola no puede dar, como la versión del conjunto de datos usada, de modo que un consumidor puede juzgar si el modelo es adecuado para su uso y no solo si es auténtico.

19.4 Cifrado

Cifre los datos de entrenamiento y los pesos en reposo y todo el tráfico en tránsito (TLS). El cifrado protege la confidencialidad frente al robo del almacenamiento y la interceptación, pero no frente a una consulta de apariencia legítima que extraiga información del modelo. Las claves deben gestionarse por separado de los datos que protegen; un archivo de pesos cifrado guardado junto a su clave no protege nada. El cifrado tampoco altera el comportamiento del propio modelo. Un usuario con acceso ordinario de consulta puede seguir extrayendo datos de entrenamiento o reconstruir un modelo a través de sus respuestas, así que el cifrado se combina con límites de consultas y controles de las salidas. Los ingenieros registran qué amenazas aborda cada control de cifrado y cuáles no aborda explícitamente.

19.5 Ejemplo resuelto (caso sintético de NRS)

NRS recibe las actualizaciones del modelo de TrackEye de un proveedor de modelos de visión. Sam exigió un manifiesto firmado con resúmenes SHA-256 de cada archivo, verificado en el ordenador del tren de inspección antes de la carga. En una prueba, una configuración modificada que habilitaba la carga remota de código fue rechazada, en coincidencia con el config.yaml MISMATCH del laboratorio. Verificar en el tren y no en el depósito importa porque los archivos podrían alterarse en cualquier punto entre el proveedor y el dispositivo. Primero se comprueba la firma del manifiesto; los hashes de los archivos solo se consideran fiables una vez demostrado que la firma procede de la clave esperada del proveedor.

19.6 Errores y límites

Las cuentas de administración compartidas hacen que cada acción de un agente sea tan poderosa como la tarea más poderosa que necesite cualquier agente. Un hash descargado del mismo servidor que el archivo solo prueba que el servidor es coherente consigo mismo, así que el resumen esperado debe llegar por un canal separado y confiable, como un manifiesto firmado. El cifrado protege los datos en reposo y en tránsito, pero un modelo que responde a consultas aún puede revelar lo que aprendió.

Ejercicios — capítulo 19

Síntesis del capítulo

La identidad hace que las acciones de los agentes sean atribuibles y acotadas; los hashes, las firmas y la procedencia hacen verificables los artefactos de IA. Juntos anclan la confianza en la cadena de suministro de la IA.

Siga estudiando — capítulo 19 de 50

← Capítulo 18 (borrador) · Índice de capítulos del curso · Capítulo 20 (borrador) →

Respuestas desarrolladas

EX055. model.bin falla (un bit invertido en el byte 5000) y config.yaml falla (una línea añadida); tokenizer.json no se modificó, así que su resumen coincide.

EX056. Un atacante que controla el servidor puede sustituir tanto los pesos como el manifiesto. Firme el manifiesto con la clave del proveedor y fije esa clave pública en el verificador, u obtenga los resúmenes por un canal independiente.

EX057. Un token delegado por usuario, limitado a «crear borrador de orden de trabajo» para el depósito del usuario, válido durante minutos, vinculado a la sesión y con cada uso registrado.