Seguridad Zero-Trust

Arquitectura de defensa multicapa que protege la red LIOP

En un ecosistema donde agentes de IA inyectan y ejecutan lógica en nodos de datos de forma autónoma, la seguridad perimetral tradicional (VPNs, firewalls, contraseñas) es insuficiente.

El Logic-Injection-on-Origin Protocol (LIOP) asume que la red es hostil por defecto e implementa una arquitectura Zero-Trust integral. Cada capa integra protecciones criptográficas y de aislamiento avanzadas.

The Shield: Pipeline de Seguridad Zero-Trust en Seis Capas

​

1. Cifrado de Transporte (P2P & PQC)

LIOP utiliza el Noise Protocol Framework para el establecimiento de conexiones P2P; de este modo suprime la dependencia de Autoridades de Certificación (CAs) centralizadas y añade Criptografía Post-Cuántica:

• Identidades Ed25519: Cada Agente y Nodo de Datos genera un par de claves. Tu Clave Pública es tu identidad (Peer ID) en la red.
• Autenticación Mutua: Las conexiones se autentican de forma bilateral instantánea. Ambos extremos saben exactamente con quién están transaccionando mediante pruebas de posesión de clave.
• Acuerdo de Clave Post-Cuántica (ML-KEM-768): LIOP emplea Kyber768 (ML-KEM-768) para el intercambio de claves y AES-256-GCM para el cifrado del payload, lo que protege contra ataques cuánticos (“Harvest Now, Decrypt Later”).
• Firmas Digitales Post-Cuánticas (ML-DSA-65): Manifiestos, capacidades y recibos de revocación se firman mediante Dilithium65 (ML-DSA-65).
• Límite Estricto de Sesión de 1 Hora: Las claves simétricas derivadas vencen automáticamente a los 3600 segundos para minimizar ventanas de exposición y mitigar repeticiones.
• TLS Mutuo con CertManager: Permite autenticación corporativa X.509 de clientes con recarga de certificados en caliente sin interrupciones.

​

2. Inspección de Carga (Guardián AST y Analizador de Taint)

Antes de que el Nodo de Datos permita la ejecución del código inyectado, este se somete a un análisis estático profundo del Árbol de Sintaxis Abstracta (AST), tanto a nivel binario como de script.

El Módulo Guardián inspecciona el Árbol de Sintaxis Abstracta (AST) de WebAssembly. Como WebAssembly es verificable sin ejecución, el servidor valida que el binario no contenga instrucciones malformadas, recursividad infinita no autorizada o intentos de importar funciones del sistema prohibidas.

Para scripts interpretados (como payloads en JavaScript), el Taint Analyzer ejecuta una inspección estática de Control de Flujo de Información (IFC). Este módulo analiza el AST para asegurar que las variables que contienen datos PII no se filtren hacia salidas escalares.

Protección contra Evasión por Generadores e Iteradores: Para prevenir intentos de bypass que utilicen generadores o iteradores (function* / yield) para extraer registros evadiendo los escaneos estándar de propiedades, el Taint Analyzer realiza un análisis estático profundo de los ámbitos de función:

• Rastreo de YieldExpression: El motor evalúa recursivamente los argumentos de yield para certificar que los valores derivados de PII queden marcados incluso si se encapsulan en yields de generadores.
• Contaminación (Tainting) del Scope de Funciones: Las funciones locales (FunctionDeclaration, FunctionExpression, ArrowFunctionExpression) que retornan o hacen yield de campos con taint son marcadas permanentemente como tainted.
• Cadenas de Métodos de Iteración: Al invocar una función contaminada (gen()), el iterador resultante y sus llamadas subsiguientes (como .next().value) heredan el taint, lo que propaga la restricción a través del árbol de expresiones y neutraliza la exfiltración por generadores.

Esto neutraliza patrones evasivos e importaciones no autorizadas de forma estática antes de iniciar la ejecución.

​

3. Filtro Anti-Exfiltración (Egress Filter)

Si un módulo inyectado intentara emitir datos no autorizados fuera de los límites del sandbox, el Servidor LIOP aplica un Filtro de Egreso (Egress Filter) antes de transmitir la respuesta a través del canal seguro.

Este filtro inspecciona dinámicamente el buffer de salida buscando información sensible (PII, claves o campos restringidos). Si se detectan violaciones de privacidad, la respuesta se bloquea y el payload se descarta.

Defensa contra Ofuscación JSON: Los agentes podrían intentar evadir escáneres estáticos mediante doble serialización. Para neutralizar esto, el PiiScanner implementa parsing profundo recursivo. Si un string devuelto contiene estructuras JSON internas, el filtro las deserializa para exponer su contenido, lo que neutraliza los intentos de evasión basados en serialización anidada.

Política de Agregación Primero: Más allá del escaneo PII, el Filtro de Egreso impone una heurística de Agregación Primero que bloquea la exportación masiva de datos a nivel de fila. Si la salida del sandbox contiene arrays con más elementos tipo objeto que el umbral configurado (por defecto: 10), la respuesta se rechaza. Solo se transmiten resultados agregados (conteos, promedios o resúmenes), lo que evita la exfiltración masiva de datos incluso cuando los registros individuales carecen de PII.

Desempaquetado Criptográfico y de Envolturas: Para evitar falsos positivos causados por las firmas HMAC-SHA256 de los recibos ZK, envolturas JSON-RPC o respuestas proxied de herramientas gRPC (como { content: [{ type: "text", text: "..." }] }), el Escudo de Egreso realiza su escaneo estrictamente sobre el payload de negocio desempaquetado (mediante unwrapForAggregationPolicyScan). Esto garantiza que los sellos criptográficos y los metadatos de enrutamiento no interfieran con las políticas de seguridad.

Opacidad Condicional de Errores: En entornos de producción (NODE_ENV=production), todas las violaciones de Egreso devuelven un mensaje genérico [LIOP] Egress Security Violation sin ningún detalle interno. En entornos de desarrollo/test, se exponen errores de validación de esquema detallados y sugerencias correctivas para habilitar la iteración rápida y la autocorrección del LLM.

​

4. Sandboxing (WASI)

Como se detalla en Sandboxing con WASI, la ejecución está aislada por las restricciones de CPU y memoria del runtime; de esta manera impide cualquier acceso no autorizado a recursos del host.

​

5. Aislamiento por Hardware y Atestación Remota (TEEs)

El aislamiento de software puro no resulta suficiente frente a amenazas persistentes avanzadas que explotan vulnerabilidades del hipervisor o escaladas de privilegios en el kernel. Por este motivo, LIOP integra aislamiento físico por hardware con atestación criptográfica previa al vuelo para Entornos de Ejecución Confiable (TEEs), incluyendo AMD SEV-SNP y AWS Nitro Enclaves.

Antes de autorizar la inyección de cualquier módulo computacional en un enclave confidencial, el cliente o el enrutador de frontera ejecuta verifyTeeAttestationDetailed:

• Reportes AMD SEV-SNP: Valida reportes binarios de 1,184 bytes, verificando la firma del silicio y comprobando que el campo REPORT_DATA en el desplazamiento 0x50 coincida rigurosamente con SHA-256(publicKey || nonce).
• AWS Nitro Enclaves: Analiza documentos COSE_Sign1 comprobando los registros de arranque medido (PCR0, PCR1, PCR2) y confirmando la presencia de la clave pública del enclave en user_data.
• Enclaves Sintéticos: Acepta sobres prefijados con TEES exclusivamente en entornos de desarrollo y pruebas.

Este mecanismo asegura que ni los operadores de infraestructura en la nube ni un administrador con privilegios root en el sistema operativo anfitrión puedan inspeccionar la memoria RAM, sustraer claves o manipular conjuntos de datos durante la ejecución.

​

6. Integridad Computacional (zk-VM y Recibos Híbridos Post-Cuánticos)

En flujos de trabajo con agentes autónomos descentralizados, el cliente necesita comprobar matemáticamente que el nodo remoto ejecutó la lógica solicitada de forma íntegra, sin omitir registros ni adulterar las salidas. LIOP resuelve esta garantía mediante una arquitectura graduada tri-modal de pruebas de conocimiento cero:

1. Modo 0 (HMAC_LEGACY, 0x00): Compromiso simétrico ligero derivado del secreto de sesión ML-KEM-768. Ofrece una latencia inferior a 0.05 milisegundos y un consumo computacional mínimo, concebido para microcontroladores perimetrales y dispositivos IoT con restricciones de batería.
2. Modo 2 (GROTH16, 0x02): Prueba no interactiva de conocimiento cero sobre la curva BN254 combinada con un journal binario inmutable de 144 bytes. Genera pruebas compactas de 252 bytes verificables de forma nativa en contratos inteligentes de la EVM mediante el precompilado ecPairing a muy bajo coste de gas (aproximadamente 200,000 gas).
3. Modo 3 (GROTH16_PQC_HYBRID, 0x03): Recibo híbrido resistente a computación cuántica que combina la prueba Groth16 sobre BN254 con una firma digital post-cuántica ML-DSA-65 (NIST FIPS 204) de 3,309 bytes calculada sobre el digest SHA-256(journal || proof). Este modo es obligatorio en enclaves de Nivel 1 (banca y expedientes clínicos), garantizando que las pruebas no puedan falsificarse aun cuando se resuelva el problema del logaritmo discreto clásico mediante el algoritmo de Shor.

El protocolo incluye adicionalmente el Scaffold Invitado SP1 zkVM (crates/liop-sp1-guest), el cual compila el intérprete determinista WebAssembly (wasmi) a la arquitectura riscv32im-succinct-zkvm-elf para respaldar pruebas universales basadas en STARKs.

Ancla de Integridad de Datos: Cada recibo incorpora el campo dataset_digest (un hash SHA-256 del conjunto de datos al momento del cálculo). Este ancla criptográfica permite a los clientes verificar que el conjunto de datos se mantuvo inalterado entre consultas consecutivas, separando el ruido legítimo de Privacidad Diferencial de cualquier mutación no autorizada en el origen.

Validación Asíncrona sin Bloqueo: La verificación del recibo (verifyZkReceipt) se ejecuta fuera del hilo principal mediante hilos dedicados (zk-verifier.ts). Aquellas herramientas configuradas con zkMode: "required" (PROOF_MODE_ZK_BLOCKING) rechazan de manera determinista cualquier prueba ausente o defectuosa, impidiendo ataques de degradación de suites criptográficas.

​

7. Motor de Privacidad Diferencial (Mecanismo de Laplace)

Cuando el sandbox WASI ejecuta lógica inyectada sobre datasets pequeños (por debajo del umbral configurable smallDatasetThreshold, por defecto: 50 registros), las salidas numéricas sin proteger podrían revelar información a nivel individual mediante ataques de diferenciación (ejecutar la misma consulta antes y después de agregar un registro) o ataques de búsqueda binaria (iterar umbrales de filtro para aislar un registro único).

LIOP mitiga esto con un Mecanismo de Laplace calibrado que inyecta ruido matemáticamente acotado en todos los campos numéricos de la salida antes del egreso.

​

Fuente de Ruido CSPRNG

Todo el ruido se genera mediante crypto.randomBytes() del módulo crypto de Node.js (respaldado por el pool de entropía del sistema operativo), nunca Math.random(). Esto previene ataques de reconstrucción de estado donde un adversario podría predecir valores futuros de ruido observando 3-5 salidas ruidosas, según lo exige NIST SP 800-226.

​

Modo de Auditoría Determinista (DDP)

Para escenarios de auditoría SOX/PCI-DSS que requieran Recibos ZK reproducibles, el motor soporta Privacidad Diferencial Determinista (DDP). Cuando se activa, el generador de ruido Laplace inicializa un PRNG basado en SHA-256 con semilla dataset_hash + image_id, lo que produce ruido idéntico para consultas idénticas sobre datasets inmutables. Esto restaura la verificabilidad completa del Recibo ZK sin violar la garantía matemática de privacidad, dado que la semilla permanece criptográficamente impredecible para observadores externos que no tengan acceso tanto al dataset como a la lógica inyectada.

​

Sensibilidad Query-Aware

En lugar de aplicar una sensibilidad global única a todos los campos de salida, el motor detecta automáticamente el tipo de consulta a partir del nombre del campo:

Tipo de Consulta	Patrón de Clave	Sensibilidad	Justificación
COUNT	count, length, size, num, total_records	Siempre 1	Agregar/eliminar un registro cambia el conteo como máximo en 1
AVERAGE	avg, mean, average	sensibilidadGlobal / n	Contribución acotada por registro
SUM	Cualquier otra clave numérica	sensibilidadGlobal	Valor máximo plausible configurado por el operador

Esto refleja la arquitectura de la librería de Privacidad Diferencial de Google, que utiliza CountParams, SumParams y MeanParams separados, cada uno con calibración de sensibilidad independiente.

​

Piso de Epsilon

Para datasets con menos de 10 registros, el motor impone un epsilon mínimo de 1.0, independientemente de la configuración del operador. Esto previene la destrucción catastrófica de utilidad donde el ruido sobrepasa completamente la señal. La categoría más sensible de Apple (Datos de Salud) utiliza ε=2.0 sobre millones de registros; usar ε < 1.0 en datasets diminutos produce resultados matemáticamente absurdos.

​

Invariantes de Post-Procesamiento

Siguiendo el Algoritmo TopDown del Censo de EE.UU. 2020, el motor impone dos restricciones de post-procesamiento que son gratuitas bajo el teorema de post-procesamiento de DP (no consumen presupuesto de privacidad adicional):

1. Enteros no-negativos: Todos los campos de conteo se redondean y restringen a ≥ 0.
2. Preservación de tipo: Las entradas enteras producen salidas enteras; las entradas no-negativas permanecen no-negativas.

​

8. Presupuesto de Consultas Estratificado (NIST SP 800-226)

Incluso con la adición de Privacidad Diferencial, un atacante podría teóricamente evadir las protecciones del ruido Laplace ejecutando la misma consulta miles de veces a través de la malla y computando el promedio estadístico para reconstruir los datos originales.

Para evitar esta reconstrucción diferencial, LIOP implementa un Motor de Presupuesto de Consultas Estratificado (Query Budget) alineado con las directrices de NIST SP 800-226.

​

Presupuestos Aislados por Cliente y Persistentes por Sesión

• Aislamiento y Persistencia de Sesión (Anti-Bypass): Los presupuestos se rastrean por cliente utilizando la identidad criptográfica (agentDid derivado de su PeerID Ed25519 persistente, o clientId de los tokens JWT autorizados por el servidor Nexus OAuth 2.1) verificada durante el handshake PQC (negotiateIntent). Bajo el capó, estos presupuestos se pueden escribir en el disco a través de un archivo JSON compartido (budgetStorePath). Esto evita que los límites se omitan mediante reconexiones, el inicio de un nuevo intent gRPC o el reinicio del servidor, ya que el presupuesto se ancla a la identidad criptográfica persistente del cliente en lugar de a tokens de transporte efímeros (como el session_token de gRPC).
• Concurrencia y Bloqueo de Archivos: Para evitar ataques de diferenciación estadística en los que se envían múltiples solicitudes paralelas simultáneamente para evadir los presupuestos, el motor sincroniza el acceso utilizando bloqueos a nivel de archivo (archivos .lock). Las actualizaciones son atómicas, lo que garantiza que ninguna solicitud pueda eludir las comprobaciones de validación en entornos multiproceso o distribuidos.
• Validación en Pre-Vuelo (Preflight): El TaintAnalyzer decodifica y escanea el AST de la lógica inyectada antes de instanciar el sandbox. Extrae todos los campos consultados, tanto los anidados en bucles de generadores como los accesos directos por índice. Si el conteo acumulado de consultas de un campo (cargado dinámicamente desde el archivo de presupuestos) supera el límite de su tier, la petición se aborta inmediatamente en el preflight y devuelve un error limpio a la IA.
• Tolerancia a Fallos (Fallback): Si las restricciones de permisos o deadlocks impiden el bloqueo o escritura en el sistema de archivos, el motor emite una advertencia en los logs y recurre de manera dinámica a un rastreo en memoria; esto mantiene la seguridad de los datos activa en todo momento.

​

Tiers de Sensibilidad

LIOP clasifica los campos en tres tiers de sensibilidad y aplica límites de consulta específicos por sesión:

Tier de Sensibilidad	Campos Objetivo	Límite de Consultas / Sesión	Descripción y Rationale
FORBIDDEN (Tier 3)	SSN, contraseña, nombre completo, email, credenciales	3 consultas	Identificadores directos. Altamente restringidos; se bloquean tras 3 peticiones.
SENSITIVE (Tier 2)	Balance bancario, tipo de cuenta, diagnóstico médico	8 consultas	Propiedades críticas del dominio. Semi-restringidos para prevenir inferencia estadística.
PUBLIC (Tier 1)	Edad, divisa de transacción, precio, metadatos	25 consultas	Campos de baja sensibilidad. Límite estándar.

Nota: Para compatibilidad con sistemas heredados, se puede configurar un límite uniforme mediante queryBudgetPerField, el cual sobrescribe los tiers y aplica un límite único para todos los campos.

​

9. Alineación con Metodologías de Modelado de Amenazas de Privacidad (LINDDUN y PLOT4ai)

Para garantizar el cumplimiento regulatorio e industrial (como GDPR, HIPAA, y la Ley de IA de la UE), los controles de seguridad del protocolo LIOP están sistemáticamente alineados con los estándares de modelado de amenazas de privacidad de la industria.

​

Mapeo con LINDDUN

LIOP mitiga matemática y estructuralmente las siete categorías de amenazas del framework LINDDUN:

• Linkability (L) e Identifiability (I) (Enlazabilidad e Identificabilidad): Neutralizadas por el Motor de Privacidad Diferencial de Laplace calibrado que perturba las salidas numéricas, un Taint Analyzer a nivel de AST que detecta exfiltraciones basadas en la extracción de caracteres y un estricto umbral de K-Anonymity ($n < 10$) que bloquea respuestas sobre datasets diminutos.
• Non-repudiation (N) (No repudio): Resuelto mediante ZK-Receipts (compromisos HMAC-SHA256 y recibos de ejecución criptográficos) vinculados a firmas de identidad de nodo persistentes con claves Ed25519, lo que proporciona una prueba de ejecución inalterable.
• Detectability (D) (Detectabilidad): Mitigada al normalizar las métricas de consumo de combustible de CPU en buckets discretos de 100 unidades y al utilizar un CSPRNG (crypto.randomBytes()) seguro para el ruido de Laplace; esta salvaguarda neutraliza ataques laterales de temporización y de reconstrucción de estado del generador.
• Data Disclosure (D) (Divulgación de datos): Impedida estructuralmente por el paradigma central Logic-on-Origin (trasladar la lógica al dato en vez del dato a la inteligencia), reforzada por el Escudo Egress PII de múltiples capas y la Política Aggregation-First que bloquea la exportación de filas de datos en bruto.
• Unawareness (U) y Non-compliance (N) (Falta de conciencia e Incumplimiento): Resuelto a través de recursos dinámicos de instrucciones de esquemas (liop://schema/guidelines) que guían a los agentes sobre las restricciones activas en tiempo real, diseñados nativamente para cumplir con las guías de NIST SP 800-226 y OWASP DLP 2025.

​

Alineación con PLOT4ai

Para riesgos específicos del dominio de Inteligencia Artificial, LIOP se alinea directamente con las categorías de PLOT4ai (Privacy Library Of Threats for AI):

• Data & Data Governance (Gobernanza de Datos): Garantizada por una malla de enrutamiento descentralizada basada en Kademlia DHT; los datos permanecen locales, seguros y bajo la soberanía exclusiva del nodo de origen.
• Cybersecurity & Safety (Ciberseguridad y Seguridad): Asegurada por un Sandbox WASI con congelación de prototipos en tiempo de ejecución (conforme a PCI-DSS) y cifrado de transporte con Criptografía Post-Cuántica (handshakes con ML-KEM-768).
• Accountability & Transparency (Responsabilidad y Transparencia): Soportada por modos de auditoría deterministas (DDP) y verificación criptográfica de los hashes de imágenes WASM dentro de Entornos de Ejecución Seguros (TEEs).