Seguridad, cifrado y MFA con passkeys

Arquitectura de seguridad

Evercore está diseñado con una arquitectura sin estado y centrada en la seguridad. Nunca entra texto en claro en la infraestructura de Evercore — el cifrado se aplica antes de que cualquier dato salga de tu entorno.

El ciclo de vida de la solicitud es:

1. El cliente cifra la carga útil usando AES-256-GCM con una clave que controlas 2. El cifrado se transmite a la API de Evercore sobre TLS 1.3 3. Evercore valida la solicitud, aplica etiquetas de Arweave y reenvía el cifrado a la red de Arweave 4. El ID de la transacción de Arweave se devuelve al cliente 5. No se conserva texto en claro ni material de claves en ningún momento

Estándares de cifrado

Datos en reposo

Todos los datos almacenados en Arweave se cifran con AES-256-GCM antes de la subida:

• Algoritmo: AES-256-GCM (NIST SP 800-38D) • IV: nonce aleatorio de 96 bits generado por archivo • Auth Tag: etiqueta de autenticación GCM de 128 bits, almacenada en cadena como metadato • Material de clave: derivado mediante PBKDF2-SHA256 (mínimo 310.000 iteraciones) o Argon2id cuando esté disponible

El IV de cifrado y la etiqueta de autenticación se almacenan como etiquetas de transacción de Arweave (visibles públicamente), pero el material de clave nunca se almacena en ningún lugar por Evercore.

Datos en tránsito

• TLS 1.3 es obligatorio para todos los endpoints de la API de Evercore — las conexiones TLS 1.2 se rechazan • Se recomienda el pinning de certificados para integraciones móviles y de CLI • Las comunicaciones con el gateway de Arweave van cifradas con TLS y validación de certificados

Gestión de claves

Evercore sigue un modelo estricto de conocimiento cero respecto a las claves de cifrado:

• Las claves se derivan del lado del cliente y nunca se transmiten ni se almacenan en Evercore • Las claves API usadas para autenticación se almacenan como hashes bcrypt — nunca se conserva el texto plano • Los JWK de wallets de Arweave se gestionan mediante secretos de Encore.dev y se cifran en reposo en el almacén de secretos • Las políticas de rotación de claves se aplican a todas las credenciales internas del servicio

Seguridad de infraestructura

Evercore se ejecuta sobre infraestructura gestionada por Encore.dev con los siguientes controles:

• Aislamiento de red: los servicios se comunican por canales privados y autenticados • Principio de mínimo privilegio: cada componente del servicio solo tiene los permisos que necesita • Análisis de dependencias: escaneo automático de vulnerabilidades en cada compilación • Endurecimiento de contenedores: imágenes base mínimas sin paquetes innecesarios • Gestión de secretos: todas las credenciales se gestionan mediante el almacén cifrado de secretos de Encore.dev — no hay archivos .env en producción • Rate limiting: límites por IP y por clave API aplicados en la capa de gateway de la API

Consideraciones específicas de Arweave

Como Arweave es un libro mayor público e inmutable, aplican las siguientes consideraciones:

• Los IDs de transacción y las etiquetas son visibles públicamente — no incluyas metadatos sensibles en etiquetas en texto plano • El cifrado es público pero ilegible sin la clave de descifrado • Una vez confirmados en cadena, los datos no pueden eliminarse — elige con cuidado lo que subes • Los nodos gateway de Arweave son operados por terceros; usa solo gateways HTTPS • Se admite redundancia multi-gateway para evitar un único punto de fallo en la recuperación

Control de acceso

Autenticación de API: • Se requieren claves API para todos los endpoints no públicos • Las claves se limitan a operaciones específicas (lectura, escritura, admin) • Las claves comprometidas pueden revocarse al instante desde el panel • Todo uso de claves se registra con IP, marca temporal y endpoint

Autenticación de wallet: • Las transacciones firmadas por el usuario usan ArConnect o firmas compatibles de wallets de Arweave • Evercore verifica la propiedad de la wallet sin mantener nunca claves privadas • La gestión del pool de wallets está protegida detrás de claves API de nivel admin

Autenticación multifactor (Passkey)

Evercore admite autenticación multifactor basada en WebAuthn/Passkey para claves API administrativas. Esto añade una segunda capa de verificación usando biometría (Face ID, Touch ID), autenticadores de plataforma (Windows Hello) o llaves físicas de seguridad (YubiKey).

Cómo funciona

La MFA se vincula a claves API individuales, no a sesiones del navegador:

• Las passkeys se registran mediante el estándar WebAuthn (FIDO2) • La clave privada del autenticador nunca sale del dispositivo — solo la clave pública se almacena en el servidor • Cada autenticación produce una respuesta firmada al desafío que verifica el servidor • En caso de éxito, se emite un token MFA de corta duración (TTL de 15 min, firmado con HMAC) • El token se envía mediante el encabezado X-Evercore-MFA para operaciones de elevación • La prueba está vinculada criptográficamente a la IP y al dispositivo solicitante — un token capturado no puede reutilizarse desde otra red o navegador

Autenticación de elevación

La elevación es un control opcional que activas por clave API desde tu perfil. Cuando está activa, las acciones más sensibles exigen un toque de passkey reciente (una prueba emitida en los últimos 2 minutos), no solo una sesión válida:

• Borrado GDPR — crear, aprobar y ejecutar (crypto-shred irreversible) • Creación, revocación y rotación de claves API • Cambios de wallet de Arweave y de credenciales del operador Hedera • Emisión y revocación de credenciales S3 • Creación/revocación de transferencias cifradas y cambios en controles de cumplimiento

Los agentes autónomos actúan con tu clave API, así que mientras la elevación esté activa no pueden ejecutar estas acciones — reciben una denegación explícita para que un humano las complete. Desactivar la elevación también exige un toque reciente.

Propiedades de seguridad

• Detección de autenticador clonado: se rechazan regresiones del contador de firma • Protección contra replay: las pruebas se vinculan a IP + dispositivo y se verifican contra hashes almacenados • Rate limiting: limitación por solicitud más un bloqueo de 30 minutos tras 5 intentos fallidos • Validación de origen: el RP ID y el origen se verifican estrictamente para evitar phishing • Códigos de recuperación: 10 códigos de un solo uso para recuperar acceso sin passkey • Enrolamiento obligatorio (opcional): los despliegues pueden exigir una passkey antes de cualquier acceso • Múltiples credenciales: hasta 10 passkeys por clave API para redundancia de dispositivos • Sin secretos compartidos: WebAuthn usa criptografía de clave pública — sin semillas TOTP ni códigos compartidos

Cumplimiento y certificaciones

La arquitectura sin estado y el cifrado de Evercore ayudan al cumplimiento de:

• HIPAA: el cifrado AES-256-GCM satisface el safe harbor de cifrado de HIPAA para PHI. Evercore no almacena PHI. Los clientes que necesiten un BAA deben contactarnos. • GDPR: el diseño sin estado significa que Evercore conserva muy pocos datos personales. Consulta la Política de privacidad para detalles sobre los derechos de los interesados. • SOC 2 (en progreso): estamos trabajando para obtener la certificación SOC 2 Type II. Contáctanos para la documentación actual de nuestra atestación de seguridad. • ISO 27001: las políticas de seguridad de infraestructura se alinean con los controles ISO 27001.

Nota: El cumplimiento es una responsabilidad compartida. Los clientes deben implementar controles apropiados en sus propios entornos.

Divulgación de vulnerabilidades

Nos tomamos muy en serio las vulnerabilidades de seguridad. Si descubres un problema de seguridad en Evercore, repórtalo de forma responsable.

Cómo reportar: • Email: {{email}} • Clave PGP disponible bajo solicitud para comunicaciones cifradas • Incluye: componente afectado, pasos de reproducción, impacto potencial

Nuestro compromiso: • Confirmaremos la recepción en 48 horas • Proporcionaremos una evaluación inicial en 7 días • Las vulnerabilidades críticas se corregirán y divulgarán en 90 días • No emprenderemos acciones legales contra investigadores de buena fe que sigan esta política

Actualmente no ofrecemos programa de bug bounty, pero los hallazgos relevantes se reconocerán en nuestro changelog.