Arquitectura de Seguridad

Capas de defensa en profundidad, pipelines criptográficos y mecanismos de protección de datos en el SDK TypeScript de LIOP

El SDK TypeScript de LIOP aplica un modelo de seguridad basado en defensa en profundidad, compuesto por seis capas independientes. Cada capa aborda una superficie de amenaza distinta (desde el análisis estático de código hasta el filtrado de datos post-ejecución), garantizando que ningún punto único de fallo pueda comprometer el sistema.

Las características marcadas con [ROADMAP] están definidas arquitectónicamente pero aún no están disponibles en la versión actual.

---

​

Resumen de las Capas de Seguridad

Capa	Propósito	Momento
Guardian AST	Bloquea importaciones WASM no autorizadas antes de la ejecución	Pre-compilación
WASI Sandbox	Aísla el entorno de ejecución con 25 globales envenenados, congelamiento de prototipos y límites de CPU	Ejecución
IFC Taint Analyzer	Control de flujo de información que previene derivaciones PII y canales laterales por claves computadas	Pre-flight
PII Shield	Previene la fuga de datos mediante validadores algorítmicos y detección NER	Post-ejecución
Aggregation Policy	Impone límites de cardinalidad en la salida de datos a nivel de fila (Aggregation-First)	Post-ejecución
ZK-Receipt	Prueba criptográfica tri-modal de computación honesta: HMAC (v1), Groth16 BN254 (v2) y ML-DSA-65 PQC Híbrido (v2.1)	Post-ejecución

---

​

Capa 1: Guardian AST

El módulo Guardian AST realiza una inspección estática síncrona sobre los módulos WebAssembly antes de su compilación. Utiliza WebAssembly.Module.imports() para enumerar todas las solicitudes de importación dirigidas al host y validarlas contra una lista blanca estricta.

​

Lista Blanca de Funciones WASI

Solo las siguientes 14 funciones de wasi_snapshot_preview1 están permitidas:

fd_write, fd_read, fd_close, fd_seek, fd_prestat_get, fd_prestat_dir_name,
fd_fdstat_get, environ_get, environ_sizes_get, args_get, args_sizes_get,
clock_time_get, proc_exit, random_get

Cualquier importación fuera de este conjunto dispara un error SandboxViolation inmediato. Un tope fijo de 128 importaciones totales por módulo previene el agotamiento de recursos mediante payloads de tipo bomba lógica.

El Guardian AST inspecciona importaciones de módulos WASM, no globales de JavaScript. El bloqueo de APIs peligrosas de JS (require, eval, fetch) es gestionado por la Capa 2 mediante envenenamiento de globales.

---

​

Capa 2: WASI Sandbox

El SDK proporciona un motor de ejecución de doble vía que enruta cada payload al mecanismo de aislamiento apropiado:

Vía	Tecnología	Caso de Uso
WASM Nativo	node:wasi (preview1)	Binarios .wasm pre-compilados
V8 Isolate	node:vm + contexto endurecido	Payloads JavaScript dinámicos

​

Envenenamiento de Globales V8

Veinticinco vectores de ataque son neutralizados asignándoles undefined y sellándolos como no modificables:

const POISONED_GLOBALS = [
  // APIs Core de Node.js / Runtime
  "require", "process", "global", "globalThis",
  "Buffer", "setTimeout", "setInterval", "setImmediate",
  "queueMicrotask", "eval", "Function", "SharedArrayBuffer",
  // Defensa contra Canal Lateral de Tiempo
  "Date", "performance", "Intl",
  // Defensa contra Heap Bomb / Explotación Binaria
  "ArrayBuffer", "Uint8Array", "Int8Array",
  "Uint16Array", "Int16Array", "Uint32Array", "Int32Array",
  "Float32Array", "Float64Array",
  "BigInt64Array", "BigUint64Array", "DataView"
];

El envenenamiento de APIs temporales (Date, performance, Intl, SharedArrayBuffer) previene que la lógica inyectada realice análisis de canal lateral por temporización de alta resolución para inferir la cardinalidad o el valor de registros privados. El envenenamiento de TypedArrays neutraliza ataques DoS de tipo Heap Bomb que alojan buffers binarios masivos para causar el colapso del proceso de trabajo.

Tras la asignación, el contexto completo del sandbox se congela recursivamente mediante Object.freeze(), impidiendo cualquier alteración del entorno aislado en tiempo de ejecución.

​

Defensa contra Contaminación de Prototipos

Dentro del IIFE del sandbox, once prototipos core de JavaScript se congelan antes de que el código de usuario se ejecute para cumplir con las estrictas normativas de aislamiento lógico PCI-DSS e HIPAA:

Object.freeze(Object.prototype);
Object.freeze(Array.prototype);
Object.freeze(String.prototype);
Object.freeze(Number.prototype);
Object.freeze(Boolean.prototype);
Object.freeze(RegExp.prototype);
Object.freeze(Map.prototype);
Object.freeze(Set.prototype);
Object.freeze(Promise.prototype);
Object.freeze(Object.getPrototypeOf(function(){})); // Resuelve y congela Function.prototype
Object.freeze(Error.prototype);

Debido a que Function y otros espacios de nombres globales están explícitamente envenenados (establecidos como undefined) en el ámbito global para eliminar vías de escape de ejecución, no es posible congelar Function.prototype directamente. El SDK lo resuelve dinámicamente mediante Object.getPrototypeOf(function(){}) para aplicar el congelamiento.

Toda la ejecución del huésped se envuelve en un bloque que contiene "use strict";. Por consiguiente, cualquier intento por parte del código inyectado de escribir o asignar propiedades a estos prototipos congelados (ej., Object.prototype.polluted = "leak") arrojará inmediatamente un error duro TypeError, lo que detiene la ejecución y previene vulnerabilidades de contaminación de prototipos.

​

Límites de Consumo de CPU

Parámetro	Valor
Timeout de ejecución	5.000 ms (terminación forzada)
Límite de combustible	1.000.000 unidades
Directorio de trabajo	Efímero (eliminado al finalizar)

​

Defensa contra Evasión de Microtareas

En la ejecución del contexto de V8, las microtareas (como las Promesas resueltas) planificadas durante la evaluación a veces pueden sobrevivir al límite de ejecución del script o eludir las restricciones síncronas simples. Para prevenir esto, el SDK impone:

const context = vm.createContext(sandboxEnv, {
  name: "LIOP Isolate",
  origin: "liop://sandbox",
  microtaskMode: "afterEvaluate",
});

La opción microtaskMode: 'afterEvaluate' le indica a Node.js que ejecute inmediatamente todas las microtareas encoladas por el script antes de retornar. Esto garantiza que ninguna lógica asíncrona sobreviva fuera del límite de ejecución del sandbox de 5.000 ms, neutralizando potenciales evasiones del sandbox mediante bombas lógicas asíncronas.

​

Variables de Entorno Seguras del Host (allowEnv)

Por defecto, el sandbox WASI aísla por completo el entorno del huésped. Si su lógica de negocio requiere estrictamente variables de entorno, puede habilitar la propagación segura de variables del host:

const server = new LiopServer(info, {
  // En las opciones de WasiSandbox
  allowEnv: true
});

Para prevenir vulnerabilidades por inyección de comandos en shell (como Shellshock) y evitar fugas silenciosas de credenciales del host (como AWS_SECRET_ACCESS_KEY o NPM_TOKEN), el SDK filtra las variables de entorno mediante una lista permitida estricta y segura a través de getDefaultEnvironment():

• Lista de Permitidos en Windows: APPDATA, HOMEDRIVE, HOMEPATH, LOCALAPPDATA, PATH, PROCESSOR_ARCHITECTURE, SYSTEMDRIVE, SYSTEMROOT, TEMP, USERNAME, USERPROFILE, PROGRAMFILES.
• Lista de Permitidos en Unix/Linux: HOME, LOGNAME, PATH, SHELL, TERM, USER.

Cualquier variable de entorno que comience con definiciones de función de shell () se rechaza de inmediato para neutralizar vectores de ejecución de código remoto.

​

Limpieza Post-Ejecución

El sandbox destruye todos los artefactos temporales después de cada ciclo de ejecución:

await fs.rm(workingDir, { recursive: true, force: true });

---

​

Capa 3: Control de Flujo de Información (IFC Taint Analyzer)

El IFC Taint Analyzer (TaintAnalyzer) inspecciona el Árbol de Sintaxis Abstracta (AST) de JavaScript generado por Acorn antes de que el código huésped ingrese al isolate V8. Rastrea el flujo de datos sensibles y bloquea cualquier intento de filtrar información confidencial a través de canales computacionales indirectos.

​

Vectores de Ataque Mitigados

Vector de Ataque	Mecanismo	Defensa
Inferencia Booleana	Ramas condicionales if (record.balance > 1000000)	El rastreo estático de ramas previene derivaciones de PII en tiempo de preflight
Derivación de Caracteres	Fuga ASCII vía record.ssn.charCodeAt(0)	El acceso a miembros sobre campos sensibles contamina todas las expresiones derivadas
Colecciones con Alias	const accounts = env.records; accounts.filter(...)	Detección iterativa de fuentes que identifica cadenas de asignación y vincula variables de registro
Claves Computadas Dinámicas	acc[record.accountHolder] = record.balance en .reduce()	Marca los objetos que reciben claves o valores contaminados, deteniendo el preflight
Operadores Spread en Objetos	{ [record.name]: record.id, ...rest }	Las expresiones de propiedades computadas evalúan la contaminación de la clave y bloquean diccionarios dinámicos

​

Defensa contra Claves Computadas Dinámicas

Los atacantes que intentan eludir la Capa 5 (Aggregation-First) transformando datasets en diccionarios dinámicos (ej., usando reduce para generar { [nombre]: saldo }) son interceptados de forma estática en la fase de preflight:

// Payload adversarial bloqueado en preflight:
const accounts = env.records;
const top5 = accounts.slice(0, 5);
return top5.reduce((acc, a) => {
  acc[a.accountHolder] = a.balance; // BLOQUEADO: acc marcado como derivado de PII
  return acc;
}, {});

Cuando propagateTaint detecta una asignación a un MemberExpression donde la propiedad es computada y está contaminada (isExpressionTainted(member.property)), el objeto contenedor se marca permanentemente como contaminado. Cualquier ReturnStatement posterior que intente retornar dicho objeto dispara un rechazo fail-closed:

Preflight policy rejected: PII side-channel detected: output contains values derived from restricted fields. Operation: variable 'acc' is PII-derived

---

​

Capa 4: Escudo de Privacidad (PII Egress Shield)

El escáner PII intercepta toda la salida del sandbox antes de devolver los resultados al llamador. A partir de la v3, opera un pipeline de detección en cuatro etapas que combina análisis estructural, coincidencia de patrones y procesamiento de lenguaje natural. Cada etapa es independiente: el sistema bloquea los datos si cualquier etapa detecta una violación.

​

Pipeline de Detección

Etapa	Mecanismo	Propósito
1. Coincidencia Exacta de Claves	Set<string>.has() (O(1))	Bloquea nombres de campo PII conocidos (ssn, email, password)
2. Coincidencia Difusa de Claves	Regex de contorno + subcadena	Captura aliases y variaciones (patientId, names, fullName)
3. Validadores de Patrones	Regex + verificaciones algorítmicas	Detecta valores PII independientemente del nombre de la clave
4. Escaneo NER de Contenido	Motor NLP compromise	Identifica nombres de personas, lugares y organizaciones en texto libre

​

Etapas 1 y 2: Análisis de Claves

La coincidencia exacta utiliza un Set<string> para búsqueda en tiempo constante O(1) contra una lista configurable de claves prohibidas.

La coincidencia difusa extiende la protección a aliases y variaciones mediante dos algoritmos:

• Tokens cortos (< 4 caracteres, ej. id): Regex con detección de contorno que identifica patientId, record_id, user-id pero permite grid, video, android
• Tokens largos (≥ 4 caracteres, ej. name, phone): Contención por subcadena que detecta firstName, accountName, names

Una lista segura de palabras comunes del inglés y claves internas del protocolo LIOP previene falsos positivos en términos como diagnosis, medication, image_id o timestamp.

​

Etapa 3: Validadores de Patrones

Patrón	Algoritmo	Validación
EMAIL	Regex	Excluye @example.com, @test.com
CREDIT_CARD	Checksum Luhn	Suma de dígitos mod 10 === 0
IP_ADDRESS	Regex + verificación de rango	Excluye 127.x.x.x, valida octetos 0 a 255
PHONE	Regex + verificación de repetición	7 a 15 dígitos, rechaza patrones 1111111
SSN	Validación estructural	Bloquea area=0/666/≥900, grupo=0, serial=0
IBAN	ISO 7064 Mod-97 via BigInt	BigInt(cadenaNumérica) % 97n === 1n
PASSPORT_MRZ	Regex	Zona de Lectura Mecánica TD3 de 44 caracteres

​

Etapa 4: Reconocimiento de Entidades Nombradas (NER)

Cuando enableNerScanning se establece en true, el escáner utiliza la librería NLP compromise para detectar nombres de personas, ubicaciones geográficas y nombres de organizaciones embebidos en los valores de salida, independientemente de la clave utilizada para almacenarlos.

const server = new LiopServer(
  { name: "secure-vault", version: "1.0.0" },
  {
    security: {
      enableNerScanning: true,  // Activa la detección de entidades por NLP
      forbiddenKeys: ["id", "name", "ssn", "email"],
    },
  },
);

El escaneo NER es opt-in durante la fase alpha. Añade aproximadamente 10ms de latencia para tamaños de salida típicos (< 10KB). La librería compromise opera enteramente dentro del proceso sin realizar llamadas a APIs externas.

​

Presets Regionales

El SDK incluye tres conjuntos de patrones preconfigurados, adaptados a los marcos regulatorios más comunes:

PII_PRESETS.GLOBAL_STRICT  // 6 patrones (Excluye SSN)
PII_PRESETS.US_COMPLIANT   // 6 patrones (Incluye SSN, excluye IBAN)
PII_PRESETS.EU_GDPR        // 6 patrones (Incluye IBAN, excluye SSN)

Los presets pueden combinarse con reglas regex personalizadas para cumplir con requisitos de compliance específicos de cada organización. Consulte la guía de configuración de LiopServer para ver ejemplos de uso.

​

Protecciones Anti-Bypass

• Defensa contra JSON Anidado: El análisis recursivo de cadenas con JSON embebido neutraliza la ofuscación mediante envolturas de JSON.stringify()
• Protección contra Referencias Circulares: Un WeakSet de seguimiento previene la recursión infinita en objetos auto-referenciantes
• Política Aggregation-First: Bloquea la exportación de datos crudos a nivel de fila; solo pasan resultados agregados (conteos, promedios, resúmenes)
• Aplicación de Output Schema: Cuando se define un esquema de salida Zod, el modo .strict() se aplica automáticamente, rechazando cualquier clave no permitida explícitamente en el esquema
• Desempaquetado Criptográfico y de Envoltura: Aísla y extrae automáticamente el payload de datos de negocio real de las envolturas de transporte MCP/LIOP y de las respuestas proxied de gRPC (mediante unwrapForAggregationPolicyScan) antes de realizar el escaneo. Esto evita falsos positivos procedentes de metadatos binarios y sellos criptográficos (como las firmas HMAC-SHA256 de los recibos ZK).
• Sanitización Numérica Recursiva en Memoria: Antes de realizar el escaneo, todos los valores numéricos del payload devuelto se procesan de forma recursiva: los números decimales positivos (floats) se redondean a un máximo de 4 decimales, y los valores negativos se acotan de forma segura a 0 (mediante sanitizeOutput()). Esto se ejecuta enteramente en memoria para evitar canales laterales en representaciones de coma flotante y previene conversiones de cadena de caracteres redundantes.
• K-Anonymity en Datasets Pequeños: Para micro-datasets o demos sintéticas (tamaño del dataset < 10), el Escudo de Egreso aplica un filtro estricto de K-Anonymity. Cualquier salida devuelta por el sandbox es rechazada si contiene más de 3 claves escalares (propiedades planas) o si incluye algún array u objeto anidado. Esto bloquea intentos de reconstruir bases de datos registro a registro mediante consultas superpuestas o canales de estructura anidada.

---

​

Privacidad Diferencial y Presupuesto de Consultas de 3 Tiers (NIST SP 800-226)

Para prevenir ataques de reconstrucción y diferenciación estadística (donde un agente realiza múltiples consultas superpuestas para aislar los valores de un único registro), el SDK implementa un sistema de presupuesto de consultas estratificado junto con privacidad diferencial de Laplace.

​

Límites de Sesión del Presupuesto de Consultas de 3 Tiers

Durante una sesión segura negociada por PQC, el SDK rastrea el acceso a los campos de datos. Cumpliendo con las directrices NIST SP 800-226, los campos se clasifican en tres tiers de sensibilidad, cada uno con su propio límite de consultas estricto por sesión:

1. Tier Prohibido (Máx 3 consultas/sesión): Se aplica a campos declarados en forbiddenKeys (ej., ssn, password, email). Cualquier intento de consultar estos campos superando el límite dispara un bloqueo de egreso inmediato.
2. Tier Sensible (Máx 8 consultas/sesión): Se aplica a campos declarados en sensitiveKeys globales o a nivel de herramienta (ej., balance, diagnosis, ticker).
3. Tier Público (Máx 25 consultas/sesión): Se aplica a cualquier campo público no registrado como sensible o prohibido.

Los límites se imponen dinámicamente basándose en el análisis de flujo de información (taint tracking). Si el presupuesto de algún tier se agota, las ejecuciones subsiguientes en el sandbox que intenten acceder a esos campos son bloqueadas.

​

Presupuestos de Consultas Persistentes y Control de Concurrencia

Para mantener los invariantes de seguridad Zero-Trust a través de reinicios o fallas del servidor, o en clústeres multi-instancia (como múltiples procesos puente locales en paralelo), el SDK admite la persistencia de presupuestos de consultas activos en el sistema de archivos:

• Configuración de Persistencia: Los operadores pueden proporcionar la propiedad budgetStorePath de forma global en las opciones del constructor de LiopServer o localmente dentro de una política LogicExecutionPolicy a nivel de herramienta.
• Anclaje de Identidad del Cliente (Anti-Bypass): Los límites de presupuesto están estrictamente vinculados a la identidad criptográfica del cliente (agentDid derivado de su PeerID Ed25519 persistente, o clientId de los tokens JWT autorizados por el servidor Nexus OAuth 2.1). Al auditar la identidad real del cliente en lugar de tokens de transporte efímeros (como el session_token de gRPC), el SDK evita que los adversarios restablezcan sus presupuestos de consultas al iniciar nuevos handshakes o reconectarse.
• Bloqueo Atómico de Archivos: Bajo el capó, el SDK impone la sincronización entre procesos y actualizaciones atómicas en el archivo JSON del presupuesto mediante bloqueos del sistema de archivos (archivos .lock). Esto evita condiciones de carrera donde múltiples peticiones paralelas de un LLM se ejecutan simultáneamente en diferentes hilos o instancias de workers para exceder los límites de presupuesto.
• Tolerancia a Fallos en Memoria: Si fallan los permisos de escritura en el sistema de archivos, si el directorio de almacenamiento es de solo lectura, o si ocurre un deadlock de bloqueo, el SDK reporta automáticamente el error a los logs del sistema y realiza un fallback al rastreo de presupuesto en memoria aislado por sesión, lo que asegura la continuidad del servicio del nodo sin comprometer las políticas de seguridad.

​

Mecanismo de Laplace y Sensibilidad por Campo

Cuando el tamaño del dataset es menor que dpSmallDatasetThreshold (por defecto: 50), el motor de DP aplica ruido Laplace calibrado ($Ruido \sim \text{Laplace}(0, \frac{\Delta s}{\epsilon})$) a todas las salidas numéricas.

El motor calibra la sensibilidad ($\Delta s$) automáticamente basándose en la nomenclatura de los campos:

• Campos de Conteo (count, length, size, num): La sensibilidad se fija en $1.0$.
• Campos de Promedio (avg, mean): La sensibilidad se calcula dinámicamente como $\frac{dpSensitivity}{recordCount}$.
• Campos de Suma y Generales: La sensibilidad se establece según el parámetro dpSensitivity configurado en la herramienta.

---

​

Capa 6: ZK-Receipts (Arquitectura ZK Tri-Modal)

Cada ejecución en el sandbox produce un recibo criptográfico que vincula el resultado computado con la lógica exacta que lo generó, garantizando computación honesta a prueba de manipulaciones. El protocolo implementa una arquitectura tri-modal que cubre tres regímenes criptográficos complementarios:

1. Modo 0 (HMAC_LEGACY, Versión 1): Compromisos criptográficos derivados de la clave compartida de sesión post-cuántica ML-KEM-768.
2. Modo 2 (GROTH16, Versión 2): Pruebas matemáticas de conocimiento cero SNARK sobre la curva elíptica de emparejamiento BN254 con un diario binario de 144 bytes.
3. Modo 3 (GROTH16_PQC_HYBRID, Versión 2.1): Recibos de doble capa con resistencia cuántica que combinan una prueba matemática Groth16 BN254 con una firma digital post-cuántica ML-DSA-65 conforme al estándar NIST FIPS 204.

​

Estructura del Recibo (Binario v2.1: Groth16 + ML-DSA-65 PQC Híbrido)

Los recibos versión 2.1 ofrecen defensa en profundidad frente a manipulaciones algorítmicas y adversarios con capacidad cuántica. El payload empaqueta el diario canónico de ejecución de 144 bytes, la prueba Groth16 y la firma digital ML-DSA-65 en una estructura binaria inmutable para la red (~5.6 KB):

+------+-----------+---------------+---------------+---------------+--------------+---------------+------------------+-------------------+------------------+
| 0x02 | 0x03      | journalLen    | Journal       | proofLen      | Proof        | sigLen        | Signature        | PublicKey         | Checksum         |
| (1B) | (1B)      | (4B BE)       | (144B fixed)  | (2B BE)       | (Variable)   | (2B BE)       | (3309B fixed)    | (1952B fixed)     | (32B SHA-256)    |
+------+-----------+---------------+---------------+---------------+--------------+---------------+------------------+-------------------+------------------+

Campo	Tamaño	Tipo	Descripción
Version	1 byte	0x02	Identificador de versión del protocolo
Proof Type	1 byte	0x03	Discriminador de prueba (0x03 = GROTH16_PQC_HYBRID)
Journal Length	4 bytes	Big-Endian UInt32	Longitud en bytes del diario canónico (144 bytes fijos)
Journal	144 bytes	Binario Fijo	Diario binario de ejecución empaquetado
↳ guest_image_id	32 bytes	Hash binario	Identificador de la imagen del runtime o huésped enclave
↳ logic_digest	32 bytes	Hash binario	Huella SHA-256 de la lógica JavaScript o WASM inyectada
↳ dataset_digest	32 bytes	Hash binario	Huella SHA-256 del dataset al momento de la ejecución
↳ output_digest	32 bytes	Hash binario	Huella SHA-256 de la salida sanitizada post-DP
↳ fuel_consumed	8 bytes	Big-Endian UInt64	Unidades de fuel de cómputo cuantizadas consumidas por el sandbox
↳ execution_timestamp	8 bytes	Big-Endian UInt64	Marca temporal en milisegundos
Proof Length	2 bytes	Big-Endian UInt16	Longitud en bytes de la prueba Groth16
Proof	Variable	Binario	Puntos de curva elíptica Groth16 comprimidos ($A \in G_1, B \in G_2, C \in G_1$)
Signature Length	2 bytes	Big-Endian UInt16	Longitud en bytes de la firma post-cuántica (3.309 bytes fijos)
Signature	3309 bytes	Binario	Firma digital ML-DSA-65 sobre Version + ProofType + Journal + Proof
Public Key	1952 bytes	Binario	Clave pública de verificación ML-DSA-65 del enclave firmante
Checksum	32 bytes	SHA-256	Digest de integridad sobre Version hasta Public Key

​

Estructura del Recibo (Binario v2: Groth16 BN254)

Los recibos versión 2 proporcionan atestación compacta de conocimiento cero sin firmas post-cuánticas, empaquetando el diario binario de 144 bytes y los puntos de la curva en aproximadamente 252 bytes:

Campo	Tamaño	Tipo	Descripción
Version	1 byte	0x02	Identificador de versión del protocolo
Proof Type	1 byte	0x02	Discriminador (0x02 = GROTH16)
Journal	144 bytes	Binario Fijo	Diario binario idéntico a v2.1
Proof Length	4 bytes	Big-Endian UInt32	Longitud en bytes de la prueba Groth16
Proof	Variable	Binario	Puntos de curva Groth16 comprimidos ($A \in G_1, B \in G_2, C \in G_1$)
Checksum	32 bytes	SHA-256	Digest de integridad sobre Version + ProofType + Journal + Proof

​

Estructura del Recibo (Binario v1: HMAC Heredado)

Mantenido para compatibilidad estricta con nodos legados:

Campo	Tamaño	Tipo	Descripción
Version	1 byte	0x01	Identificador de versión del protocolo
Journal Length	2 bytes	Big-Endian UInt16	Longitud del payload JSON
Journal	Variable	Cadena JSON	Contiene image_id, dataset_hash, output_hash, fuel y ts
Seal	32 bytes	HMAC-SHA256	Compromiso criptográfico derivado de la clave ML-KEM-768

​

Políticas de Ejecución ZK en Enclaves

Las herramientas configuran su nivel de atestación mediante la directiva LogicExecutionPolicy:

• zkMode: "none": Modo estándar predeterminado con compromiso de sesión HMAC-SHA256.
• zkMode: "optimistic": Intenta generar un recibo Groth16 v2 mediante @nekzus/liop-zk-native o circuitos R1CS optimizados. Si el probador nativo no está disponible, degrada de forma segura a HMAC sin interrumpir la entrega del resultado.
• zkMode: "required" (ZK_BLOCKING): Obligatorio para enclaves soberanos de Nivel 1 (banca, defensa, registros médicos protegidos). Exige estrictamente una prueba Groth16 válida. Si el probador nativo falta, si se detectan pruebas ficticias simuladas o si la verificación falla, el enclave rechaza la petición con una respuesta formal de error: "[LIOP-ZK] Clearance Tier 1 enclave policy violation: Valid Groth16 zero-knowledge proof required but unavailable."
• pqcSign: true: Instruye al enclave a co-firmar la prueba Groth16 con su clave privada persistente ML-DSA-65, emitiendo un recibo Versión 2.1 GROTH16_PQC_HYBRID.

​

Atestación de Hardware TEE Pre-Vuelo

Para establecer confianza sobre infraestructuras físicas no seguras antes de transmitir payloads de lógica cifrados, el SDK proporciona la función verifyTeeAttestationDetailed. Esta utilidad inspecciona las mediciones de la raíz de confianza de hardware emitidas por máquinas virtuales confidenciales:

import { verifyTeeAttestationDetailed } from "@nekzus/liop";

const result = await verifyTeeAttestationDetailed(
  attestationBytes,
  expectedNonce,
  {
    allowedMeasurements: ["b7f8c..."],
    requireHardwareSigned: true,
  }
);

if (!result.valid) {
  throw new Error(`Atestación TEE rechazada: ${result.reason}`);
}

El verificador soporta dos plataformas principales de computación confidencial:

1. AMD SEV-SNP:

   • Analiza la estructura canónica de datos snp_report_t de 1.184 bytes.
   • Extrae el campo REPORT_DATA de 64 bytes situado en el desplazamiento de bytes 0x50 (80 decimal).
   • Valida que REPORT_DATA coincida con el resumen criptográfico SHA-256(publicKey || nonce) completado con ceros a la derecha.
   • Verifica que el modo de depuración se encuentre inactivo (POLICY.DEBUG === 0) y valida la cadena de firmas del firmware contra las claves VCEK de AMD.

2. AWS Nitro Enclaves:

   • Decodifica el documento de atestación COSE_Sign1 codificado en CBOR.
   • Evalúa los registros de configuración de plataforma (PCR0 para la imagen, PCR1 para el kernel Linux, PCR2 para la aplicación).
   • Comprueba la vinculación criptográfica de la clave pública efímera y el nonce del llamante dentro de user_data.
   • Valida la cadena de certificados X.509 hasta la CA raíz de AWS Nitro Enclaves.

​

Pipeline Criptográfico

1. Generación de ImageID: Un hash SHA-256 del payload de lógica original identifica de forma única el código exacto ejecutado.
2. Hash del Dataset: Un hash SHA-256 del dataset serializado ancla el estado de los datos al momento de la ejecución para auditorías regulatorias.
3. Privacidad Diferencial: El ruido Laplace se aplica a las salidas numéricas antes del compromiso, garantizando que el ZK-Receipt coincida con los datos que el cliente recibe. Soporta modo DDP (PRNG determinista con semilla via dataset_hash + image_id) para reproducibilidad en auditorías.
4. Codificación Binaria del Journal: Un buffer de 144 bytes que empaqueta guest_image_id, logic_digest, dataset_digest, output_digest, fuel_consumed y execution_timestamp.
5. Generación Nativa Groth16: Ejecución R1CS paralelizada con Rayon mediante @nekzus/liop-zk-native generando puntos sobre la curva BN254 en fracciones de segundo en CPU local.
6. Co-Firma Post-Cuántica (Modo 3): Cuando pqcSign está activo, el enclave firma el diario y los puntos de la prueba empleando ML-DSA-65, integrando la firma y la clave pública en el layout wire v2.1.
7. Verificación y Mitigación de Replay: El cliente valida la prueba en tiempo constante mediante emparejamientos bilineales o en el Worker Pool. Para impedir ataques de replay o manipulación de respuestas, el verificador calcula un hash SHA-256 local del resultado recibido y comprueba identidad estricta contra journal.outputDigest.
8. Extractor de Proxy por Llaves Balanceadas: Si la llamada se delegó mediante proxy (__liop_proxy_tool), el verificador ejecuta una máquina de estados para aislar los argumentos originales antes del hashing, evitando falsos positivos cuando capas intermedias agregan metadatos.

El sessionSecret utilizado en modo v1 heredado es la clave compartida negociada mediante Criptografía Post-Cuántica (ML-KEM-768), garantizando resistencia cuántica en todo momento.

---

​

Seguridad de Transporte

​

Encapsulación de Claves Post-Cuántica (ML-KEM-768)

El SDK utiliza el paquete mlkem (compatible con FIPS 203) para la encapsulación de claves:

Parámetro	Valor
Algoritmo	ML-KEM-768 (Kyber)
Tamaño de Clave Pública	1.184 bytes
Tamaño de Texto Cifrado	1.088 bytes
Secreto Compartido	32 bytes
Cifrado Simétrico	AES-256-GCM
Nonce	12 bytes (único por entrada)

​

Aislamiento de Nonce

Cada payload cifrado utiliza un nonce aleatorio fresco de 12 bytes (crypto.randomBytes(12)), antepuesto al texto cifrado. Esto previene la reutilización de nonce en AES-GCM cuando múltiples payloads se cifran bajo la misma clave de sesión.

​

Endurecimiento de TLS en Producción

Si bien la capa PQC de LIOP cifra todos los payloads a nivel de aplicación de extremo a extremo, el cifrado a nivel de transporte (TLS/mTLS) es crítico para prevenir la escucha de metadatos y garantizar la identidad de los nodos.

Para evitar fallos silenciosos en producción, el SDK implementa una verificación estricta a prueba de fallos:

• En entornos de desarrollo/pruebas, la falta o mala configuración de los archivos de certificado genera una advertencia y realiza un fallback elegante a canales gRPC inseguros.
• En producción (process.env.NODE_ENV === 'production'), cualquier fallo al resolver o cargar los certificados TLS configurados (rootCert, certChain o privateKey) lanza un error fatal, lo que fuerza al proceso a detenerse inmediatamente en lugar de degradarse silenciosamente a un canal no cifrado.

​

Autenticación Zero-Trust del Bridge

El LiopStreamBridge aplica autenticación obligatoria mediante token Bearer en todos los endpoints HTTP:

• Si ZERO_TRUST_TOKEN no está configurado, se auto-genera un token efímero seguro vía randomUUID()
• Cada solicitud a /mcp requiere un header válido Authorization: Bearer <token>
• Limitación de tasa por IP en la creación de sesiones (por defecto: 10 sesiones concurrentes)
• Expulsión automática de sesiones inactivas (TTL: 30 minutos)

---

​

Autorización OAuth 2.1 y Control de Acceso Basado en Alcances (RBAC)

LIOP integra una pila completa de autorización Máquina a Máquina (M2M) bajo OAuth 2.1 / OIDC en conformidad con RFC 6749, RFC 8707 (Indicadores de Recursos), RFC 9068 (Perfil JWT) y RFC 9728 (Metadatos de Recursos Protegidos).

​

1. Servidor de Autorización Integrado (createOAuthServer)

Para los nodos coordinadores Nexus, el SDK proporciona un servidor de autorización embebido basado en panva/node-oidc-provider:

import { createOAuthServer } from "@nekzus/liop";

const { provider, jwks } = createOAuthServer({
  issuer: "http://127.0.0.1:15000/oidc",
  clients: [
    {
      client_id: "agent-alpha",
      client_secret: process.env.AGENT_SECRET!,
      grant_types: ["client_credentials"],
      scope: "liop:tools:list liop:tools:call liop:resources:read",
    },
  ],
});

Propiedades técnicas de seguridad:

• Flujo Exclusivo Client Credentials M2M: Los flujos interactivos y con código de autorización quedan bloqueados en el núcleo del motor para eliminar vectores de secuestro de sesión.
• Firma de Tokens con Ed25519 (EdDSA): Los pares de claves asimétricas Ed25519 se generan y firman de forma síncrona sin dependencias de red externas.
• Tokens de Acceso JWT RFC 9068: Los tokens contienen declaraciones verificadas client_id, scope y aud, lo que permite su validación sin estado en nodos distribuidos.

​

2. Alcances del Protocolo (LIOP_SCOPES)

LIOP define cinco alcances granulares de mínimo privilegio asignados a operaciones de MCP y del protocolo:

Alcance	Operaciones Cubiertas	Estándar
liop:tools:list	Listar herramientas anunciadas vía tools/list	NIST SP 800-207 §4.3
liop:tools:call	Ejecución de lógica WASM/JS in-situ vía tools/call	OWASP LLM06
liop:resources:read	Lectura de recursos estáticos vía resources/list, resources/read, resources/templates/list	Mínimo Privilegio
liop:schema:read	Lectura de plantillas de prompts y esquemas vía prompts/list, prompts/get	Minimización de Datos
liop:mesh:query	Consulta de manifiestos DHT entre nodos y resolución de rutas	Gobernanza de Malla

import { LIOP_SCOPES, type LiopScope } from "@nekzus/liop";

​

3. Autorización de Peticiones en Pasarela (authorizeRequest)

Las peticiones JSON-RPC entrantes se validan contra los alcances requeridos antes de ser entregadas a los despachadores del enrutador:

import { authorizeRequest } from "@nekzus/liop";

const result = authorizeRequest("tools/call", authInfo);
if (!result.allowed) {
  // Retorna HTTP 403 / error JSON-RPC con motivo detallado del rechazo
  console.error("Acceso denegado:", result.reason);
}

• Los métodos públicos del ciclo de vida (initialize, ping, server/discover) se ejecutan sin autenticación según la especificación MCP.
• Las llamadas no autenticadas o métodos no reconocidos que requieran alcances protegidos fallan de inmediato de forma cerrada (fail-closed).

​

4. Metadatos de Recursos Protegidos (buildProtectedResourceMetadata)

Permite a los clientes MCP descubrir los endpoints de autorización conforme a RFC 9728:

import { buildProtectedResourceMetadata } from "@nekzus/liop";

const metadata = buildProtectedResourceMetadata(
  "http://127.0.0.1:15000/oidc",
  "urn:liop:enclave:vault"
);
// Expuesto en /.well-known/oauth-protected-resource

​

5. Validación de JWT (JwtValidator)

Los nodos de datos validan tokens portadores sin estado mediante resolución dual de JWKS:

import { JwtValidator } from "@nekzus/liop";

// Resolución remota de JWKS con caché de 10 minutos
const validator = new JwtValidator(
  "http://127.0.0.1:15000/oidc",
  "urn:liop:mesh",
  new URL("http://127.0.0.1:15000/oidc/jwks")
);

const authInfo = await validator.validate(token);
// Retorna: { token, clientId, scopes: string[], expiresAt }

---

​

Seguridad de Red P2P

Componente	Tecnología
Aislamiento de Enclave	@libp2p/pnet (PSK Swarm Key de 256 bits)
Cifrado de Transporte	Protocolo Noise (Ed25519)
Multiplexación de Streams	Yamux
Identidad	Pares de claves Ed25519 persistentes
Descubrimiento	Kademlia DHT con nodos bootstrap públicos
Transportes	TCP + WebSocket

​

Aislamiento de Enclaves Soberanos Tier 1 (PSK Swarm Key de pnet)

Para entornos con exigencias regulatorias críticas (Core Bancario, Registros Médicos y Defensa), LIOP aplica aislamiento físico de malla mediante Redes Privadas de libp2p (@libp2p/pnet):

• Clave Pre-Compartida (PSK): Una clave criptográfica de 256 bits (con encabezado /key/swarm/psk/1.0.0/) se carga en los nodos de enclave (The Bank, The Vault) y en el gateway perimetral autorizado (blg).
• Blindaje a Nivel de Socket de Transporte: La PSK opera antes de cualquier multiplexación de streams o negociación criptográfica (Noise/TLS/Kyber). Toda conexión entrante TCP, WebSocket o QUIC proveniente de un nodo que no posea la clave de enjambre coincidente es abortada inmediatamente en la capa de socket en bruto.
• Defensa Perimétrica: Incluso si un nodo no autorizado descubre la multiaddr o IP del enclave en la misma subred o VPC, no puede establecer una sesión libp2p, enviar envelopes RPC ni participar en la tabla de enrutamiento DHT Kademlia.

---

​

Aislamiento del Worker Pool

Las operaciones criptográficas de alto consumo se despachan a threads del sistema operativo mediante pools de workers Piscina, previniendo el bloqueo del event loop principal de V8:

Worker	Propósito
logic-execution	Instanciación del sandbox, descifrado AES, inspección AST
zk-verifier	Deserialización de recibos, verificación HMAC

Configuración por defecto: 2 a 8 threads (producción), 0 a 1 threads (test), planificación FixedQueue, 5s de timeout por inactividad.

​

Defensa contra Heap Bomb

Cada thread worker está restringido mediante resourceLimits.maxOldGenerationSizeMb de V8 (por defecto: 64 MB, configurable vía workerPool.maxHeapMb o la variable de entorno LIOP_WORKER_MAX_HEAP_MB). Si la lógica inyectada intenta alojar memoria más allá de este límite, el worker se termina inmediatamente con un WorkerPoolError, lo que previene ataques de denegación de servicio que buscan agotar el heap de Node.js.

​

Precalentamiento Asíncrono del Pool de Workers

Para evitar picos iniciales de latencia de CPU y mitigar los arranques en frío (cold-starts) de V8/WASI (~820k unidades de combustible), el SDK incluye una estrategia de precalentamiento asíncrono para el pool de hilos. Durante la inicialización del servidor (o la creación del verificador), se despachan tareas de “precalentamiento” en segundo plano (isWarmup: true o action: "warmup") para precalentar las instancias de workers de Piscina. Esto garantiza que los hilos worker estén inicializados, los contextos de isolate de V8 estén reservados y los handles de WASI estén pre-cacheados antes de procesar payloads reales de clientes.

---

​

Política de Agregación Primero

El SDK impone una heurística de Agregación Primero que bloquea la exportación de datos crudos a nivel de fila desde el sandbox. Esta es la última defensa computacional antes de la capa de ZK-Receipt.

​

Cómo Funciona

Tras la ejecución, la salida se escanea recursivamente buscando arrays que contengan objetos. Si el número de elementos tipo objeto supera el umbral configurado, la respuesta se bloquea:

Parámetro	Por defecto	Descripción
maxOutputRows	10	Número máximo de elementos tipo objeto permitidos en un array
allowPrimitiveArrays	true	Permite arrays que contengan únicamente valores primitivos (números, strings)

server.tool(
  "analyze_data",
  "Análisis agregado",
  { query: z.string() },
  async ({ query }) => { /* ... */ },
  {
    enforceAggregationFirst: {
      maxOutputRows: 5,
      allowPrimitiveArrays: true
    }
  }
);

​

Normalización Condicional de Errores

El SDK implementa reporte de errores consciente del entorno para violaciones de políticas:

Entorno	Comportamiento
development / test	Expone errores de validación Zod detallados, metadatos de discrepancia de esquema y mensajes HINT para habilitar la autocorrección del LLM
production	Devuelve un mensaje genérico [LIOP] Egress Security Violation sin filtrar ningún detalle interno

Esto se controla automáticamente mediante process.env.NODE_ENV. En despliegues de producción, asegúrese siempre de que NODE_ENV=production esté configurado para activar la opacidad total de errores.

Los mensajes de error detallados en modo desarrollo pueden incluir nombres de campos, estructuras de esquemas y extractos de valores rechazados. Nunca exponga la salida de errores en modo desarrollo a clientes no confiables.

---

​

Canales de Directivas Nativos del Protocolo

Para garantizar que los LLM clientes generen código JavaScript compatible que respete los límites del sandbox sin latencia de prueba y error, el SDK difunde instrucciones estructuradas y nativas del protocolo en tres niveles:

1. Metadatos de JSON Schema ($comment): El diccionario de datos inyecta automáticamente un campo $comment que contiene directivas del sandbox directamente en la representación del esquema JSON activo.
2. Recurso de Directivas de Ejecución: Un recurso dinámico (liop://schema/guidelines) detalla los workarounds específicos (como el filtrado de fechas mediante cadenas ISO 8601) y restricciones (reglas de K-Anonymity, sufijos de Laplace) requeridos por el nodo.
3. Prompts de Sistema Multi-IA: El sistema de adaptadores de prompts normaliza las restricciones para diferentes modelos (Claude, OpenAI, Gemini) con el fin de prevenir llamadas a APIs alucinadas.

---

---

​

Criptografía Post-Cuántica y Ciclo de Vida de Sesiones

LIOP combina ML-KEM-768 (Kyber768) para el encapsulamiento de claves resistente a ataques cuánticos con ML-DSA-65 (Dilithium65) para firmas digitales y sellado de manifiestos:

​

Límite Estricto de Expiración de Sesión de 1 Hora

Para mitigar ataques de repetición y minimizar la ventana de vulnerabilidad de las claves simétricas derivadas, todas las sesiones PQC imponen un límite de vida de 1 hora:

• Las sesiones expiran automáticamente a los 3600 segundos tras el intercambio de claves inicial ML-KEM-768.
• Las sesiones vencidas rechazan invocaciones RPC subsiguientes y disparan un re-handshake automático transparente sin interrumpir la conexión P2P subyacente.

​

TLS Mutuo (mTLS) y Recarga en Caliente (CertManager)

Para despliegues empresariales que requieren verificación criptográfica de clientes X.509 en conjunto con PQC, CertManager administra la rotación dinámica de certificados sin reinicios de servicio:

• Monitoriza las rutas de certificados de CA, servidor y cliente en disco.
• Reemplaza automáticamente los contextos TLS en memoria al detectar certificados renovados.
• Rechaza certificados de cliente no confiables durante el handshake de transporte.

---

​

Cumplimiento Industrial y Observabilidad (SOC 2 Tipo II / HIPAA)

​

Pista de Auditoría Inmutable (AuditLogger)

Cada ejecución de lógica, descubrimiento de esquema y rechazo de seguridad se registra en una cadena de bloques hash (Hash-Chain) inmutable y verificable:

$\text{Bloque}_{n}.\text{hash} = \text{SHA-256}(\text{Bloque}_{n-1}.\text{hash} \parallel \text{Timestamp} \parallel \text{PeerID} \parallel \text{ImageID} \parallel \text{Status})$

• Evidencia contra Manipulación: Modificar o eliminar cualquier registro histórico rompe la integridad de la cadena SHA-256, alertando de inmediato a los auditores de cumplimiento.
• Soberanía de Datos: Los registros almacenan resúmenes criptográficos y métricas de consumo de tokens sin persistir jamás datos confidenciales sin procesar.

​

Medición Determinista de Combustible por AST e Invarianza de Temporización (NIST SP 800-53)

Para neutralizar ataques de agotamiento de CPU por bucles ocultos y eliminar canales laterales de temporización, el motor analiza estáticamente el Árbol de Sintaxis Abstracta (AST) de JavaScript mediante calculateAstInstructionFuel:

• Puntuación Estática de Complejidad: Evalúa las operaciones del AST (profundidad de bucles, ramificaciones, llamadas a funciones e iteraciones) antes de ejecutar el código.
• Cuantización en Bloques de 100 Unidades: Cumpliendo con los controles NIST SP 800-53 contra canales laterales de temporización, el valor de combustible calculado se cuantiza a bloques de 100 unidades: $\text{Combustible}_{\text{cuantizado}} = \lceil \frac{\text{CombustibleRaw}}{100} \rceil \times 100$
• Desviación Estándar Cero (stddev = 0): Payloads con la misma estructura sintáctica que evalúan entradas secretas distintas consumen exactamente las mismas unidades de combustible, impidiendo que un adversario deduzca la cardinalidad de registros o valores privados mediante diferencias de temporización o métricas de combustible.

---

​

Control Estático de Flujo de Información (TaintAnalyzer)

La Capa 3 del modelo de defensa en profundidad de LIOP implementa Control de Flujo de Información Estático (IFC) mediante la clase TaintAnalyzer. Construido sobre el analizador sintáctico Acorn ESTree y acorn-walk, inspecciona la lógica JavaScript inyectada dentro del sobre @LIOP{...} antes de la compilación a bytecode o la ejecución en el isolate.

import { TaintAnalyzer } from "@nekzus/liop";

const analyzer = new TaintAnalyzer(
  ["ssn", "credit_card", "email", "password", "medical_record"], // PII prohibida
  ["salary", "account_balance"]                                    // Claves sensibles
);

const violation = analyzer.analyze(sourceCode, recordCount, 50);
if (violation) {
  throw new Error(`Ejecución rechazada por Capa 3 IFC: ${violation.reason} (línea ${violation.line})`);
}

​

Análisis Estático AST en Múltiples Pasadas

El analizador ejecuta un pipeline determinista de 5 pasadas de inspección:

1. Identificación de Variables Ligadas a Registros (Pasada 1): Recorre el AST para identificar variables vinculadas a registros confidenciales individuales dentro de funciones callback de iteración (map, filter, forEach, flatMap, find, some, every y la familia reduce/reduceRight).
2. Propagación de Mancha (Pasada 2): Rastrea los flujos de datos a través de asignaciones de variables, desestructuración de objetos, operaciones aritméticas binarias, concatenaciones de cadenas e invocaciones de métodos. Se marca un conjunto exhaustivo de métodos de extracción de caracteres como propagadores de mancha:
   • Extracción de caracteres: charCodeAt, codePointAt, charAt, at
   • Búsqueda y análisis estructural: indexOf, lastIndexOf, search, startsWith, endsWith, includes
   • Transformaciones: substring, slice, substr, split, match, replace, toLowerCase, trim
3. Fuga en Sentencias de Retorno (Pasada 3): Valida que ninguna variable escalar derivada de un campo PII manchado fluya hacia la sentencia return o el objeto exportado de la función.
4. Guarda de Correlación (Pasada 4 - Mitigación F-01): En conjuntos de datos con menos de 50 registros, detecta múltiples operaciones reduce distintas dirigidas al mismo campo sensible, lo que permitiría a un atacante reconstruir valores exactos mediante sistemas de ecuaciones diferenciales.
5. Compuerta de Extremos Min/Max (Pasada 5 - Mitigación F-02): Intercepta intentos de extracción de registros individuales (como ordenar registros por campos PII o extraer cotas máximas/mínimas en cohortes reducidas) que posibilitan ataques de búsqueda binaria.

​

Clasificación de Sensibilidad de Campos (NIST SP 800-226)

Los campos se evalúan frente a una matriz de clasificación de 3 niveles:

Nivel de Sensibilidad	Comportamiento	Atributos de Ejemplo
forbidden	Exfiltración o derivación directa bloqueada incondicionalmente por la Capa 3	ssn, iban, passport_number, password_hash
sensitive	Permitido únicamente mediante algoritmos de agregación verificados con inyección de ruido DP	balance, transaction_amount, health_diagnosis
public	Agregación y exportación sin restricciones	country_code, currency, timestamp_epoch

---

​

Motor de Privacidad Diferencial (DpEngine)

Para proteger contra ataques de reconstrucción estadística e inferencia de pertenencia en conjuntos de datos pequeños o sensibles, el SDK de LIOP integra un Motor de Privacidad Diferencial de alto rendimiento en conformidad con NIST SP 800-226 y las directrices de la librería Google DP.

import { applyDpToOutput, addLaplaceNoise, type DpConfig } from "@nekzus/liop";

const dpConfig: DpConfig = {
  epsilon: 1.5,                 // Presupuesto de privacidad (menor = más ruido)
  sensitivity: 1000,            // Delta máximo admisible para operaciones SUM
  smallDatasetThreshold: 50,    // Solo inyectar ruido cuando la cohorte n < 50
  seed: "tenant_audit_seed_42"  // Semilla opcional para Privacidad Diferencial Determinista (DDP)
};

const sanitizedResult = applyDpToOutput(rawOutput, dpConfig, datasetSize);

​

Mecanismo de Laplace y Entropía Criptográfica

El motor muestrea ruido a partir de la distribución continua de Laplace $\text{Lap}(0, \lambda)$ con escala $\lambda = \frac{\Delta f}{\varepsilon}$:

$f(x) = \frac{1}{2\lambda} \exp\left(-\frac{|x|}{\lambda}\right)$

​

Decisiones de Seguridad

1. Fuente CSPRNG (crypto.randomBytes): A diferencia de implementaciones genéricas basadas en Math.random() (Xorshift128+), DpEngine genera entropía mediante crypto.randomBytes(4) mapeado a $[-0.5, 0.5)$. Esto elimina ataques de reconstrucción de estado donde un adversario que observe 3 a 5 salidas consecutivas pueda predecir los estados pseudoaleatorios futuros y restar el ruido.
2. Sensibilidad Consciente de la Consulta: La sensibilidad ($\Delta f$) se deriva automáticamente según la semántica de la clave:
   • Consultas COUNT: Sensibilidad fijada en $\Delta f = 1$ (axioma: añadir o eliminar un registro individual altera el recuento en 1 como máximo).
   • Consultas AVG / VARIANCE: La sensibilidad se escala dinámicamente por el tamaño de la cohorte: $\Delta f = \frac{\text{sensitivity}}{n}$.
   • Consultas SUM: Aplica el límite de sensibilidad global configurado por el operador.
3. Piso de Épsilon ($\varepsilon \ge 1.0$): Para cohortes extremadamente pequeñas ($n < 10$), el motor fuerza un piso de $\varepsilon = 1.0$ para evitar la aniquilación de utilidad (aplicar $\varepsilon < 1.0$ en $n < 10$ genera números aleatorios sin utilidad analítica).
4. Privacidad Diferencial Determinista (DDP): Cuando se suministra una seed de auditoría, la entropía se deriva de una secuencia de contadores bajo HMAC-SHA-256. Esto garantiza la reproducibilidad determinista del ZK-Receipt en auditorías de cumplimiento manteniendo la privacidad matemática.
5. Preservación Estructural: Los enteros originales se mantienen como enteros redondeados (Math.round), y los atributos no negativos se restringen a $\ge 0$, respetando los estándares de post-procesamiento TopDown del Censo de EE.UU.

​

Referencia de Configuración (DpConfig)

Propiedad	Tipo	Predeterminado	Propósito
epsilon	number	1.0	Parámetro de pérdida de privacidad $\varepsilon$. Regula el equilibrio entre privacidad y precisión numérica.
sensitivity	number	1.0	Cota de sensibilidad global $\Delta f$ que representa la contribución máxima plausible de un único registro.
smallDatasetThreshold	number	50	Umbral de cardinalidad de registros bajo el cual se activa el ruido DP (alineado con HIPAA Safe Harbor).
seed	string	undefined	Cadena de semilla criptográfica para reproducibilidad determinista en auditorías.

---

​

Hoja de Ruta

Las siguientes capacidades están definidas arquitectónicamente y activas en los canales de publicación del protocolo:

Característica	Estado	Descripción
ZK-VM Nativo	Activo (v2.1)	Pruebas Groth16 BN254 y recibos híbridos post-cuánticos ML-DSA-65 via @nekzus/liop-zk-native
ZK Core Rust	Activo (v2.1)	Circuitos R1CS multi-hilo con Rayon y arkworks para analítica, benchmarks Criterion y guest SP1
TEE Attestation	Activo Pre-Vuelo	Verificación de mediciones de enclaves de hardware (AMD SEV-SNP y AWS Nitro Enclaves)

Las pruebas soberanas de Conocimiento Cero están operativas mediante recibos binarios versión 2 y versión 2.1. Los nodos provistos con @nekzus/liop-zk-native sintetizan pruebas Groth16 sobre la curva BN254, mientras que los clientes ligeros del SDK TypeScript y puentes MCP verifican las atestaciones y firmas post-cuánticas sin requerir dependencias de compilación nativa en el host cliente.