Seal: app para que tu familia abra tus secretos cuando mueras

Por qué no puedes dejar tus contraseñas en el testamento

Cuando alguien muere en Estados Unidos, su testamento pasa por un juzgado y termina indexado en registros públicos: cualquier persona puede consultarlo. Por eso, según el repositorio oficial de Seal, "la contraseña del banco, la frase que abre tu wallet, dónde está la llave de la caja fuerte, la combinación, lo que nunca le contaste a nadie" no debería ir en él.

Seal es una app gratuita para iPhone y iPad que resuelve ese hueco: permite escribir "sobres" digitales (cartas, fotos, audios, vídeos, archivos o secretos) y configurar reglas para que personas de tu confianza los abran solo cuando pase cierto tiempo de silencio. El proyecto es código abierto bajo Mozilla Public License 2.0, de un único desarrollador (Jason Epage), sin empresa, sin ronda de inversión y sin servidor propio: los sobres cifrados viven en CloudKit, la nube pública de Apple, en un contenedor que no es tu iCloud personal.

Cómo funciona el protocolo: X25519, ML-KEM-768 y Shamir

El detalle técnico que separa a Seal de un gestor de contraseñas convencional es su jerarquía de claves, descrita en su docs/SDS.md:

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Identidad: WebAuthn sobre P-256 ECDSA con SHA-256, mediante passkey o llave de seguridad. Sin email, sin contraseña y sin código de recuperación. Face ID es suficiente.
Claves de dispositivo: P-256 dentro del Secure Enclave, no exportables, respaldadas por la identidad.
Envolvimiento (wrapping): X25519 ECDH combinado con ML-KEM-768 (el estándar post-cuántico del NIST, FIPS 203) a través de HKDF-SHA256. Sobre iOS 26, el wrap usa ambos algoritmos; en versiones anteriores cae a X25519 solo, y el envoltorio registra cuál de los dos se aplicó.
Contenido: AES-256-GCM con AAD separado por dominio (estate, epoch, propósito).
División de clave: Shamir sobre GF(256), validado contra vectores independientes en Python.
Tiempo: tokens RFC 3161 sobre check-ins, cancelaciones, reclamos, taps, liberaciones y salidas, además de un "primer avistamiento" que clampa cada reclamo al día en que el teléfono lo vio por primera vez — nadie puede retroceder fechas más allá de las advertencias.

Según publicó 9to5Mac el 22 de mayo de 2026, Apple abrió al público su repositorio corecrypto con las implementaciones de ML-KEM y ML-DSA verificadas formalmente, junto con el paper Formal Verification for Apple corecrypto y herramientas para reproducir las pruebas. Ese trabajo sostiene los componentes de CryptoKit que Seal aprovecha sin reinventar nada. El proyecto reusa CryptoKit y AuthenticationServices de Apple; "nada implementado a mano" es un principio explícito del repositorio.

La regla por defecto: dos de tres, 90 días de silencio, 21 de aviso, 14 de calma

Cada sobre tiene su propia regla. Por defecto: dos de tres poseedores de la clave, 90 días sin check-in, seguidos de 21 días de advertencias diarias y 14 días de calma. Una carta médica puede abrirse en días mientras el resto espera meses. Quien quiera puede fijar los cuatro números.

El "check-in" es la única tarea continua: abrir la app de vez en cuando. Cuando alguien deja de hacerlo, los tenedores de clave pueden iniciar un reclamo. El usuario recibe un aviso cada día durante semanas; un solo toque cancela todo y ese toque no necesita la llave de hardware, porque "una persona viva que perdió su llave no debe ser declarada muerta por su propio software". Solo después del proceso completo se desbloquean los sobres — y cada uno se abre en el teléfono del destinatario original. Nadie lee los sobres ajenos, ni siquiera quienes autorizaron la liberación.

Comparables: dónde encaja Seal en el mercado de herencia digital

El concepto que Seal implementa no es nuevo: en ingeniería se llama dead man's switch y se lleva usando desde locomotoras y cortacéspedes. Su salto al mundo digital, según explica Ever Legacy, combina tres piezas: payload cifrado, monitor de inactividad y canal de entrega.

La mayoría de servicios comerciales (Ever Legacy, Google Inactive Account Manager, Apple Digital Legacy) cubren el caso con entrega por correo, verificación por email o portales web. Seal se diferencia en tres puntos verificables desde su código:

Sin servidor propio: los ciphertext viven en el CloudKit público de Apple; cualquier app firmada puede validar eventos pero no descifrar.
Verificador independiente: tools/verify_capsule.py es un único archivo Python sin dependencias y sin acceso a red; comprueba endosos WebAuthn, digests y firmas, encadenamiento de eventos, commitments por epoch, taps contra desafíos y tokens RFC 3161 (con openssl también verifica sus firmas).
Cápsula exportable: cualquier parte del expediente puede exportar un JSON con el registro firmado completo, y reproducir la verificación en otra máquina, incluso sin Mac ni iPhone.

Entre los riesgos reconocidos por el propio proyecto están: ausencia de auditoría criptográfica independiente, ningún build reproducible, un campo de timestamp "placeholder" y una matriz de pruebas de llaves de seguridad "sin filas completas". Para tenedores de hardware wallets, el README recomienda explícitamente: "No hagas de Seal la única copia de una seed phrase activa".

¿Qué significa esto para tu startup?

Más allá del uso personal, la arquitectura de Seal es una clase magistral — y descargable — de tres tendencias que están reescribiendo la seguridad de producto:

Post-quantum por defecto, no como bolt-on. Combinar X25519 con ML-KEM-768 vía HKDF-SHA256 y registrar cuál se usó es exactamente el patrón que Cloudflare llevó a IPsec en producción durante 2026 (Tech Times, 9 de julio de 2026) y que Apple formalizó en corecrypto. Si tu producto maneja claves, sesiones largas o datos que vivirán más de 5 años, empieza a diseñar con KEM híbrido ya.
Sin servidor propio no significa sin confianza. Usar CloudKit como almacenamiento público verificable elimina un backend, pero descarga toda la seguridad en la criptografía verificable offline. Para un founder técnico, el patrón "verificador Python standalone + cápsula JSON firmada" es replicable: te da auditabilidad sin vendor lock-in.
Diseño trust-minimized sin sacrificar UX. Seal pide a los usuarios encontrarse cara a cara una vez para registrar la clave pública del otro, y rechaza claves distintas servidas bajo el mismo nombre para siempre. Es un buen ejemplo de cómo reemplazar email + OTP por presencia física cuando lo que está en juego es crítico.

Acciones concretas que puedes tomar hoy

Audita tu testamento digital: ¿tu gestor de contraseñas o tus frases semilla están en un documento que termina en un juzgado? Sácalos del testamento y documenta dónde vive la copia de seguridad y a quién llamar primero.
Evalúa un dead man's switch en tu equipo: si operas una startup, documenta quién tiene acceso a qué si tú o un cofundador quedan incapacitados. Una carta sellada con instrucciones de continuidad (sin secretos en sí) puede valer más que un testamento.
Descarga y lee los 6 archivos clave del repo (EstateKeys.swift, KEMBundle.swift, Shamir.swift, ReleaseMachine.swift, WebAuthnParsing.swift y verify_capsule.py). Son una lectura corta que enseña jerarquía de claves post-cuántica, Shamir sobre GF(256) y un verificador reproducible en Python: útil incluso si nunca tocas iOS.