Autorización Soberana de Cuvex
Una capa de confianza independiente sobre la custodia.
La custodia y la autorización son dominios de seguridad distintos.
Arquitectura de referencia
01 · Dominio de custodia
Wallets · MPC/HSM · Asset Keys · Blockchain Signing · Execution
Propuesta de transacción
Límite de confianza independiente de Cuvex
02 · Connector
Autenticación del proveedor · Adquisición de la transacción · Correlación
03 · Normalizador
Representación del proveedor → intención de transacción canónica
04 · PSTT-I
Objeto canónico de autorización institucional
05 · Política offline
Verificación independiente fuera del plano de control original
06 · Verificación humana
Activo · red · importe · destino · política · quórum
07 · Autorización criptográfica
Evidencia de autorización independiente
Retorno al dominio de custodia
08 · El custodio continúa
Firma nativa en blockchain · ejecución
FIREBLOCKS-FIRST.
VENDOR-NEUTRAL BY DESIGN
OFFLINE HUMAN VERIFICATION
CRYPTOGRAPHIC TRANSACTION BINDING
Lección arquitectónica · BYBIT 2025
Seguridad de las claves ≠ seguridad del contexto de autorización.
El incidente demuestra por qué una cold wallet, un esquema multisig y unos firmantes legítimos no eliminan necesariamente el riesgo de que el contexto en el que se autoriza una transacción pueda verse comprometido.
Verifica de nuevo la intención de la transacción, fuera del plano de control original.
Objetivos de seguridad
01
Vinculación de la transacción
La autorización (A) no puede autorizar la transacción (B).
02
Verificación independiente
Reconstruye la operación efectiva fuera del sistema de origen.
03
Intención verificable por una persona
Muestra el efecto económico de la operación, no un identificador abstracto.
04
Aplicación obligatoria
Los flujos protegidos requieren el quórum configurado en Cuvex.
05
Bloqueo seguro
Ante fallos
Una operación protegida no puede reducir silenciosamente su nivel de seguridad.
06
Fallo seguro
Verifica la evidencia criptográfica, no solo el estado registrado en una base de datos.
Modelo de amenazas.
Asume que el entorno online
Puede fallar.
COMPONENTE
SUPUESTO
PROPIEDAD REQUERIDA
Estación de trabajo del operador
Potencialmente comprometida
No puede redefinir silenciosamente la intención autorizada
Gateway
Potencialmente comprometido
No puede falsificar una autorización offline
Cordinator
Intermediario no confiable
Solo transporte
Transporte USB
No confiable
Validación independiente
Metadatos del proveedor
No confiables hasta su validación
Determinar la operación real
Capa 01 · Connector
El Connector conoce al custodio. El Core de Cuvex no.
authenticate()
fetch_transaction() verify_vendor_source() obtain_transaction_data()
normalize()
correlate()
submit_authorization()submit_rejection()
get_execution_status()
Capa 02 · Normalización
No confíes en la etiqueta. Determina el efecto real.
UNTRUSTED DESCRIPTION
"Send 10M USDC
to Treasury B"
DERIVEDINTENT
chain_id
token_contract
sourcedes
tination
amount
nonce
call
data
operation_type
Neutral respecto al proveedor por diseño
TU ÚLTIMA AUTORIDAD NO DEBERÍA ESTAR ATADA A TU CUSTODIO.
Capa 03 · PSTT-I
Un único lenguaje canónico de autorización.
Capa 03 · PSTT-I
Un único lenguaje canónico de autorización.
Modelo conceptual de objetos
Vincula lo que importa.
header
authorization_id
institution_id
environment
created_at
expires_at
security_epoch
subject
operation_type
chain_id
asset_contract
source destination
amount
calldata_hash
vendor_binding
vendor_id
external_transaction_id
vendor_payload_hash
policy_context policy_id
policy_version
policy_hash
required_quorum
required_roles
Compromiso de visualización
Lo que ves es lo que autorizas.
La intención de la máquina y lo que se muestra al usuario deben describir la misma operación crítica.
Online policy
¿Esta operación debería requerir Cuvex?
IF amount >
5M REQUIRE CUVEX
Offline policy
¿Este dispositivo está autorizado para autorizarla?
chain == ETHEREUMasset == APPROVED_USDCamount <= 20Msecurity_epoch >= 10role == TREASURY
Separación criptográfica
Dos dominios.
Dos claves.
Dos responsabilidades.
DOMINIO DE AUTORIZACIÓN
Credencial institucional de Cuvex
Objetivo arquitectónico: ML-DSA-65.
DOMINIO DE ACTIVOS
MPC / HSM del custodio
Firma de transacciones nativa de blockchain.
Límite físico de confianza
CUVEX BIT
No Bluetooth or NFC hardware. USB-C acts as a file bridge. There is no live App - Device operational session.
Transporte = mensajero no confiable.
Flujo de procesamiento del dispositivo offline
Recibir una solicitud no confiable
Decodificación estricta + validación del esquema
Recalcular el ID de autorización
Verificar la vinculación con el proveedor
Recalcular el compromiso de visualización
Aplicar la política offline
Representar la intención de forma confiable
Confirmación física por parte del usuario
Generar la autorización criptográfica
Borrado seguro
Segregación de funciones
Quórum de autorización. No multisig de blockchain.
AUTHORIZERS
CFO
CISO
TREASURY
POLICY A
2 OF 3
POLICY B
1 TREASURY
+
1 SECURITY
ALL AUTHORIZE THE SAME
authorization_id
Integración de referencia con Fireblocks
Diseñado primero para Fireblocks. No depende de Fireblocks.
Integración de referencia con Fireblocks
Diseñado primero para Fireblocks. No depende de Fireblocks.
Transparencia del despliegue
Diseñado para Fireblocks, pero no depende de Fireblocks.
Level 0
Observar
La autorización (A) no puede autorizar la transacción (B).
Level 1
Control del cliente
Reconstruye la operación efectiva fuera del sistema de origen.
Level 2
Control nativo del custodio
Muestra el efecto económico de la operación, no un identificador abstracto.
Level 3
Defensa en profundidad
Control del custodio + Cuvex + restricciones on-chain.
Semántica de fallos
Fallo seguro.
IF policy == CUVEX_REQUIRED
AND valid_quorum == FALSE
THEN
PROTECTED_EXECUTION = BLOCKED
Requisitos de seguridad del PoC
No demuestres funcionalidades. Demuestra resistencia ante fallos.
ATAQUE
MUTATCIÓN
RESULTADO ESPERADO
Sustitución del destino
A → B
La autorización original deja de ser válida
Sustitución del importe
1M → 10M
Se requiere una nueva autorización
Reutilización de la transacción del proveedor
Tx A → Tx B
La vinculación con el proveedor no coincide
Repetición
Reutilización de un paquete ya completado
Rechazo
Firmante duplicado
Misma credencial utilizada dos veces
No se alcanza el quórum
Quórum insuficiente
1 de los 2 requeridos
No se ejecuta la operación protegida
Reglas de diseño
-
Asume que el host puede mentir.
-
Asume que el transporte está comprometido.
-
Recalcula lo que importa.
-
Muestra la intención real.
-
Vincula la autorización.
-
bloquea la operación de forma segura.