Principe de fonctionnement
Seal permet à un utilisateur de créer des enveloppes chiffrées (lettre, photo, vidéo, fichier ou secret) destinées à des proches. Chaque enveloppe est liée à une clé publique enregistrée via un passkey ou une security key. Aucun mot de passe, adresse e‑mail ou code de récupération n’est utilisé, ce qui élimine les vecteurs de phishing classiques. L’application s’appuie sur Face ID pour l’authentification locale et stocke les données chiffrées dans un conteneur iCloud dédié à Seal, sans jamais transmettre les clés privées hors du téléphone.
Architecture cryptographique
Le cœur du protocole repose sur ML‑KEM, l’algorithme de key‑encapsulation post‑quantum recommandé par le NIST. Lors de l’enregistrement, chaque appareil génère une paire de clés ML‑KEM ; la clé publique est échangée en face à face et inscrite dans le registre local de l’autre appareil. Les secrets sont ensuite chiffrés avec la clé publique du destinataire, garantissant que seul le détenteur de la clé privée correspondante peut les déchiffrer. Pour prévenir l’ouverture prématurée, Seal implémente un compte à rebours signé : le propriétaire fixe une date de libération et le code signe ce timestamp avec une clé partagée. Le mécanisme de key split divise la clé privée en plusieurs parts stockées séparément, mais l’arithmétique de ce partage n’est pas constante‑time, ce qui est justifié par le fait que les parts restent toujours sur l’appareil du propriétaire.
Analyse des risques et limites
Le projet indique explicitement qu’aucune audit indépendante n’a été réalisée ; la seule revue de conception provient d’un assistant du développeur, qui a corrigé deux points déjà résolus. L’absence de reproductibilité des builds empêche de vérifier que le binaire distribué par Apple correspond exactement au code source. De plus, le timelock cryptographique n’est pas implémenté : le compte à rebours repose sur une autorité de timestamp publique non défensive, ce qui signifie que les détenteurs de parts de clé peuvent, en collusion, ouvrir les enveloppes avant la date prévue. Les tests de sécurité sont limités : le script
sh tools/run_core_tests.shSecurityFixTests n’est pas enregistré et ne s’exécute jamais. Enfin, la prise en charge des security keys reste non testée (matrice d’interopérabilité vide), alors que les passkeys sont la voie la plus fiable aujourd’hui. En résumé, Seal propose une approche novatrice d’héritage numérique sans serveur, mais la sécurité repose sur des hypothèses fortes (absence d’audit, non‑constant‑time, manque de timelock) qui limitent son usage pour des secrets critiques tels que les phrases de récupération de portefeuille matériel.
