Cómo funciona

Seguridad y modelo de amenazas

Qué ataques mitiga Accesly, cuáles quedan en manos del usuario y por qué el backend jamás ve la llave privada. Lectura obligatoria si vas a integrar Accesly en un producto financiero.

Premisa fundacional

La regla dura del diseño: la llave privada del usuario nunca sale del dispositivo del usuario en forma reconstruible. Ni Accesly como empresa, ni AWS como cloud provider, ni el integrador que usa el SDK, pueden reconstruir la llave privada de un usuario sin cómplice el usuario mismo (con su biométrico o passphrase).

Esa premisa se refleja en 5 propiedades técnicas concretas:

  1. El backend guarda ciphertext, nunca plaintext de fragmentos.
  2. Las llaves de cifrado se derivan del biométrico del usuario, no de secretos del backend.
  3. El backend no tiene 2 de 3 fragmentos accesibles al mismo tiempo. F2 y F3 usan llaves de cifrado distintas.
  4. La firma de transacciones ocurre en el navegador del usuario. Nunca se manda seed al backend.
  5. La rotación de signers on chain requiere firma con la seed vieja, que solo el usuario puede reconstruir.

Matriz de amenazas

Ataque Impacto Mitigación
Robo del dispositivo desbloqueado Alto: atacante puede firmar Timeout de sesión, spending limit por rule, MFA opcional
Robo del dispositivo bloqueado Bajo: sin biométrico no hay PRF Passkey exige unlock del OS antes de responder
Compromiso del backend Accesly (DynamoDB dump) Nulo: solo ciphertext, sin llaves F2 wrapped en KMS, F3 protegido por passphrase del usuario
Compromiso de KMS de AWS Bajo: descifra F2 wrap pero F2 sigue cifrado con llave del user Dos capas de cifrado: KMS wrap + AES con PRF derivada
Phishing de passphrase Medio: si además roban device, comprometen wallet Passphrase nunca se pide fuera del flow de recovery
Malware en el device Alto si tiene acceso a memoria del browser Zeroize post firma, WebAuthn con userVerification required
Man in the middle en transporte Nulo: session key ECDH + HTTPS + JWT F2 se envuelve en session key X25519 efímera
Ingeniería social a Accesly Core Nulo: no tenemos las llaves No podemos entregar lo que no tenemos
Rug pull del integrador que usa el SDK Nulo: la wallet vive on chain, el integrador solo hostea UI Usuario mantiene control de su seed via recovery flow
Compromiso del contrato Smart Account Crítico: puede robar fondos 6 audits Almanax internos, timelock 48h en upgrades, plan de audit externo pre GA
Bug en Soroban runtime Fuera de nuestro control Confiamos en Stellar core team + validators

Por qué el backend jamás puede firmar

Un examen granular del scenario "atacante tiene control total del backend Accesly (Lambdas + DynamoDB + KMS)":

  1. El atacante puede leer todas las rows de user_fragments. Ve fragmentF2Wrapped (base64 KMS ciphertext).
  2. El atacante puede pedir a KMS Decrypt con el fragmentsKey. Obtiene el fragmentF2Encrypted plaintext (que sigue siendo ciphertext AES).
  3. Para descifrar ese AES ciphertext necesita la F2Key = HKDF(PRFoutput, encryptionSalt, "accesly-f2-encryption").
  4. El PRFoutput viene del passkey privkey del user. Vive en el Secure Enclave del device. El atacante no tiene forma de reproducirlo sin el device físico + biométrico del user.
  5. Sin F2 plaintext, el atacante tiene 1 de 3 fragmentos (F3 en email_fragments, protegido por PBKDF2(passphrase)). Con 1 fragmento no puede reconstruir la seed. Necesitaría también F1 (del device del user) o crackear PBKDF2 600k del F3, lo cual computacionalmente es prohibitivo si el usuario tiene una passphrase decente.

Conclusión: incluso con control total del backend, el atacante no llega a los fondos. Necesita comprometer ADEMÁS el device del usuario.

✓
Comparativa

Wallets custodiales (Coinbase Exchange, Kraken) guardan seeds en HSM administrados por ellos. Si su HSM se compromete, los fondos de todos los usuarios están expuestos. Accesly no tiene ese single point of failure porque nunca centraliza seeds.

Qué queda en manos del usuario

El modelo no custodial mueve ciertos riesgos del custodio al usuario. Es un trade off explícito y hay que comunicarlo honestamente.

Defensa en profundidad

Además de la separación arquitectural, hay varias capas defensivas:

Cifrado en tránsito

HTTPS es tabla obligatoria. Sobre HTTPS, F2 viaja envuelto en un session key efímero (X25519 ECDH por request), así aunque un atacante rompiera TLS solo vería un doble ciphertext.

Cifrado at rest doble

F2 en DynamoDB tiene dos capas de cifrado:

  1. Interior: AES GCM con llave derivada del PRF del user. Esta es la llave "real" que solo el user puede reproducir.
  2. Exterior: KMS wrap con el fragmentsKey de Accesly. Esta capa está para cumplir compliance de encryption at rest en cloud providers regulados.

Idempotencia de operaciones críticas

recovery/finalize, createWallet, y otras ops que mueven state usan Idempotency-Key header. Un attacker que reenvía el mismo request no lo procesamos dos veces. Los idempotency keys se guardan 24h con TTL en DDB.

Rate limiting

OTP recovery: máximo 3 por hora por email hash. Verify OTP: máximo 5 intentos antes de invalidar. API general: WAF con reglas por IP y por identidad Cognito.

Timelock en upgrades

Para cambiar el WASM del contrato Smart Account se requiere el upgrade-rule, que aplica timelock de 48 horas. Cualquier intento de upgrade se anuncia on chain con anticipación. Si vemos un upgrade sospechoso, hay ventana para reaccionar.

Audit trail

Todas las operaciones sensibles se loguean en audit_logs DDB table con TTL 90 días. Retention más largo para compliance disponible bajo request. Cada log tiene userId, action, result, metadata, timestamp e IP.

Estado de auditorías

Los 6 contratos Soroban tienen review interno hecho por Almanax. Zero findings críticos o high abiertos al día de hoy.

Audit externo con firma independiente (OtterSec, Runtime Verification o similar) planeado antes de subir el cap de valor por wallet más allá de mil dólares. Hasta ese punto operamos con cap conservador y beta acotada.

Divulgación responsable

Si encontrás una vulnerabilidad, escribinos a security@accesly.xyz con detalle técnico. No abras issue público en GitHub. Respondemos en 48 horas para triage.

Publicamos hall of fame de reporters responsables. Bugs críticos elegibles para bug bounty (montos anunciados post GA en un programa formal Immunefi o HackerOne).

Compliance y regulación

Accesly opera como proveedor de infraestructura tecnológica. No custodiamos fondos. La responsabilidad regulatoria del custodio queda en el integrador que decide qué features exponer a sus usuarios.

Siguientes pasos