Sécurité
Comment le coffre-fort est construit et ce qu'une brèche révélerait.
Dernière mise à jour : 21 septembre 2026 · AssuredAuth, par CircleRoll LLC
Voici la description publique de la manière dont AssuredAuth protège vos identifiants à deux facteurs, mots de passe et cartes bancaires. Elle est rédigée de façon à permettre à un lecteur soucieux de la sécurité de vérifier chaque affirmation concernant l'application et les vecteurs de test publiés (disponibles sur demande à hello@assuredauth.com). Ce document énonce les faits, et rien de plus : aucune garantie d'invulnérabilité n'est donnée, et aucun pourcentage n'est avancé.
En résumé : votre coffre-fort est stocké à un seul endroit, votre téléphone. Chaque donnée est chiffrée à l’aide d’une clé que le système de sécurité du téléphone conserve et ne peut exporter. Nous n’utilisons aucun serveur de coffre-fort, ne conservons aucune copie ni aucune clé. Un fichier de sauvegarde ne quitte le téléphone qu’après avoir été chiffré à l’aide d’une phrase secrète qui n’est jamais stockée.
Signaler un problème : hello@assuredauth.com. Voir « Signaler une faiblesse » à la fin.
1. Qu'est-ce qui est chiffré, et avec quoi ?
| Données | Sur le téléphone | Clé |
|---|---|---|
| Secrets à deux facteurs (graines TOTP/HOTP/Steam) | Sur le téléphoneTrousseau (iOS) / Boutique basée sur Keystore Android | CléLa clé matérielle de la plateforme ; la ligne de la base de données ne contient qu’une référence (secretRef), jamais la graine. |
| Mots de passe (valeur du mot de passe, notes) | Sur le téléphoneLigne scellée : AES-256-GCM, un nonce aléatoire de 96 bits par valeur | CléUne clé de données aléatoire de 256 bits, elle-même encapsulée dans la clé matérielle du §2 |
| Cartes (numéro, date d'expiration, nom sur la carte, CVC) | Sur le téléphoneMême sceau que pour les mots de passe ; le CVC est facultatif et n’est enregistré que si vous le saisissez. | CléMême clé de données |
| Métadonnées (noms de service, noms d'utilisateur, icônes, ordre de tri) | Sur le téléphoneLa base de données de l'application (SwiftData / Room) | CléProtégé par le chiffrement des fichiers du système d'exploitation ; traité comme non secret |
| Fichier de sauvegarde (.authbackup) | Sur le téléphoneOù que vous le placiez : Fichiers, iCloud Drive, dossier de données d’application Google Drive, feuille de partage | CléUne clé dérivée de votre phrase de passe (§3). Apple et Google reçoivent le fichier scellé et rien d'autre. |
| Compagnon Watch / Wear | Sur le téléphonePorte-clés/Préférences partagées cryptées de la montre | CléClés de la plateforme de montre ; transférées via le canal des appareils appariés de la plateforme |
| Trafic de l'extension de bureau (codes à usage unique sur demande) | Sur le téléphoneNon stocké ; relayé sous forme d'enveloppes cryptées de bout en bout | CléUne paire de clés X25519 par appariement, clé privée dans le trousseau/magasin de clés ; le relais ne voit que le texte chiffré. |
Le module Diagnostics ne comporte aucune méthode acceptant un secret. Aucun événement d'analyse ne contient de champ de coffre-fort. Aucune valeur du coffre-fort n'est jamais consignée dans un journal, quelle que soit la version.
2. Où se trouvent les clés, sur chaque plateforme
iOS. La clé de données est encapsulée dans une clé générée au sein de l'Enclave sécurisée (kSecAttrTokenIDSecureEnclave) avec les autorisations d'accès .privateKeyUsage + .userPresence, accessibilité …ThisDeviceOnly, dans le groupe d'accès partagé du Trousseau de l'application, afin que l'extension de remplissage automatique puisse utiliser la même clé. La clé privée ne peut être lue hors de l'Enclave ni par l'application, ni par une sauvegarde, ni par un débogueur ; l'Enclave n'accepte de l'utiliser qu'en présence de l'utilisateur (Face ID, Touch ID ou code d'accès de l'appareil). L'option ThisDeviceOnly signifie qu'une sauvegarde iCloud ou iTunes du téléphone ne contient pas la clé ; un téléphone restauré démarre avec un coffre-fort vide et demande votre fichier de sauvegarde et votre phrase secrète. Un téléphone sans code d'accès ne peut pas générer de clé .userPresence (l'Enclave refuse d'en créer une), et le simulateur emprunte le même chemin par conception (son invite de présence est une alerte à laquelle aucun test ne peut répondre) : la clé de données y est un simple élément du Trousseau d'accès propre à l'appareil — toujours absent de toutes les sauvegardes, toujours illisible lorsque le téléphone est verrouillé, mais sans deuxième invite — et l'écran de sécurité l'indique clairement et suggère de définir un code d'accès.
Android. La clé de données est encapsulée dans une clé AES-256 AndroidKeyStore, générée dans StrongBox si l'appareil en possède une (sinon, dans l'environnement d'exécution de confiance). Les options `setUserAuthenticationRequired(true)`, `setUnlockedDeviceRequired(true)` et `setInvalidatedByBiometricEnrollment(true)` sont activées, ainsi qu'une authentification biométrique ou par identifiants d'appareil pendant 30 secondes. Cette dernière option est sans incidence sur le fonctionnement de l'application : Android l'applique uniquement aux clés exigeant une authentification biométrique à chaque utilisation. Sur cette clé de 30 secondes avec identifiants d'appareil autorisés, elle est donc inopérante. La sécurité repose sur l'exigence du code PIN lors de l'enregistrement et sur l'invalidation définitive de la clé par la suppression du verrouillage de l'écran. Les clés Keystore ne sont pas exportables et sont exclues de la sauvegarde cloud d'Android. Un domaine nommé par une application sur ses propres vues (webDomain) n'est reconnu que par un navigateur connu. Pour tout autre package, il doit également s'agir d'un package vérifié par le système (liens vers les ressources numériques), car toute application peut revendiquer n'importe quel domaine.
Que signifie cela pour un fichier de base de données volé ? Le fichier SQLite et ses lignes chiffrées sont du texte chiffré. La clé permettant de les déverrouiller est stockée dans le système de sécurité du téléphone d'origine et ne peut être copiée avec le fichier. Il est impossible de la deviner hors ligne : la clé de données est aléatoire et ne dépend d'aucun choix humain.
3. Le fichier de sauvegarde
Les sauvegardes sont les seules données qui quittent le téléphone ; elles constituent donc, en principe, le seul point d’entrée possible pour une attaque hors ligne. La conception du téléphone rend cette attaque coûteuse et lui offre le moins de marge de manœuvre possible.
- La phrase de passe comporte au moins 12 caractères (la feuille refuse les phrases de moins de 12 caractères et affiche une barre de force).
- Aucun indice concernant la phrase de passe n'est stocké nulle part, ni dans le fichier ni dans l'application.
- Un sel aléatoire de 16 octets et un nonce de 12 octets sont générés pour chaque fichier écrit.
- L'intégralité du code est chiffrée en AES-256-GCM, donc une phrase de passe incorrecte ou un fichier endommagé est refusé, et jamais déchiffré en données illisibles.
- L'en-tête (format, version, paramètres KDF, sel) est intégré à la balise GCM en tant que données authentifiées supplémentaires, de sorte qu'un fichier dont le facteur de travail a été réduit ne s'ouvre pas.
Le fichier est au format JSON et lisible avec n'importe quel éditeur de texte ; seul le texte chiffré est opaque. Quiconque retrouvera le fichier dans cinq ans, une fois l'application supprimée, pourra voir exactement comment il a été chiffré et l'ouvrir avec OpenSSL ou n'importe quelle bibliothèque Argon2.
Format v1 (livré dans la version 1.0, reste lisible)
{
"format": "authbackup",
"version": 1,
"kdf": "PBKDF2-HMAC-SHA256",
"rounds": 600000,
"salt": "<base64, 16 bytes>",
"cipher": "AES-256-GCM",
"nonce": "<base64, 12 bytes>",
"ciphertext": "<base64>",
"tag": "<base64, 16 bytes>"
}| Étape | Octets |
|---|---|
key | PBKDF2-HMAC-SHA256(passphrase as UTF-8, salt, 600000 rounds, 32 bytes) |
aad | UTF-8("authbackup:1:600000:") ‖ salt (octets de sel bruts, pas base64) |
ciphertext, tag | AES-256-GCM(key, nonce, plaintext, aad); Étiquette de 16 octets, stockée séparément |
plaintext | JSON UTF-8, clés triées : {"accounts":[…],"exportedAt":"…Z","passwords":[…],"version":1} |
Note de compatibilité : Android 1.0 a généré une variante de v1 — kdf en minuscules, sans clé d’étiquette (l’étiquette de 16 octets ajoutée au texte chiffré) ni données supplémentaires. Les deux plateformes continuent de lire ces fichiers (en l’absence d’étiquette : les 16 derniers octets sont extraits, l’ouverture se fait avec un AAD vide et la comparaison du kdf est insensible à la casse) et n’écrivent désormais que la structure décrite ci-dessus.
Format v2 (actuel ; format par défaut pour les nouvelles sauvegardes)
{
"format": "authbackup",
"version": 2,
"kdf": "Argon2id",
"memoryKiB": 65536,
"passes": 3,
"lanes": 1,
"salt": "<base64, 16 bytes>",
"cipher": "AES-256-GCM",
"nonce": "<base64, 12 bytes>",
"ciphertext": "<base64>",
"tag": "<base64, 16 bytes>"
}| Étape | Octets |
|---|---|
key | Argon2id(version 0x13, passphrase as UTF-8, salt, m = 65536 KiB, t = 3, p = 1, tagLength 32, no secret, no associated data) |
aad | UTF-8("authbackup:2:argon2id:65536:3:1:") ‖ salt |
ciphertext, tag | AES-256-GCM(key, nonce, plaintext, aad); Étiquette de 16 octets, stockée séparément |
plaintext | JSON UTF-8, clés triées : {"accounts":[…],"cards":[…],"exportedAt":"…Z","passwords":[…],"version":2} |
Argon2id est l'implémentation C de référence (phc-winner-argon2, CC0), disponible sur les deux plateformes. L'opération prend environ une seconde sur un téléphone récent, avec 64 Mio et 3 passes, et chaque tentative consomme autant de mémoire et de temps quel que soit le matériel. C'est un avantage de PBKDF2 face aux systèmes équipés de GPU, et la raison d'être de la version 2. Un lecteur ignore les clés qu'il ne reconnaît pas ; ainsi, un lecteur v1 associé à un boîtier v2 ne détecte jamais les cartes.
Preuve
Trois fichiers de test (sauvegarde v1, sauvegarde v2 et Argon2id) sont générés par une troisième implémentation, indépendante des deux applications (OpenSSL de Node pour PBKDF2 et AES-GCM, et un Argon2id WebAssembly vérifié lors de sa génération par rapport aux réponses publiées de l'implémentation de référence). Chaque fichier contient la phrase de passe, le sel, le nonce, le texte clair, la clé dérivée, l'AAD, le texte chiffré attendu, l'étiquette et le fichier complet. Les tests unitaires sur iOS et Android lisent les mêmes fichiers et vérifient les mêmes octets ; ainsi, une sauvegarde scellée sur une plateforme est prouvée, et non supposée, s'ouvrir sur l'autre, et la concordance des trois ne signifie pas deux copies de la même erreur. Un outil complémentaire ouvre un fichier qu'un téléphone a réellement écrit avec cette même troisième implémentation et vérifie l'en-tête par rapport aux règles ci-dessus (exactement les clés du format, donc aucun indice ou nom ne peut être présent ; sel de 16 octets, nonce de 12 octets, étiquette de 16 octets stockés séparément ; version 2 à exactement 64 Mio / 3 / 1 ; la phrase de passe incorrecte est refusée) ; l'exécution automatisée d'iOS en écrit un sur le simulateur et l'ouvre de cette manière, puis recherche dans le conteneur d'applications du simulateur, le conteneur de groupes d'applications et la base de données du trousseau chaque mot de passe initialisé et numéro de carte au format UTF-8 et UTF-16 (0 résultats).
4. Modèle de menace
| Situation | Ce qu'ils ont | Ce qu'ils obtiennent |
|---|---|---|
| Téléphone perdu ou volé, verrouillé | Ce qu'ils ontL'appareil, le fichier de base de données, les lignes scellées | Ce qu'ils obtiennentTexte chiffré. La clé de chiffrement est stockée dans l'enclave sécurisée/le coffre-fort et n'est libérée qu'après le verrouillage de l'appareil et la saisie d'une nouvelle donnée biométrique ou d'un nouveau code d'accès. L'effacement à distance du téléphone (Localiser mon appareil) détruit également la clé de chiffrement. |
| Fichier de sauvegarde volé | Ce qu'ils ontLe fichier .authbackup d'un compte cloud, d'un e-mail ou d'un ordinateur portable | Ce qu'ils obtiennentUn chiffrement AES-256-GCM est utilisé avec une clé dérivée d'une phrase de passe d'au moins 12 caractères, un sel par fichier et un chiffrement Argon2id à 64 Mio × 3 passes (v2) ou PBKDF2 à 600 000 itérations (v1). Aucun indice, nom d'utilisateur ou liste de comptes n'est accessible en clair. Chaque tentative nécessite le calcul complet de la phrase de passe ; il n'existe aucune solution de contournement. La robustesse de la phrase de passe constitue l'unique défense, comme indiqué dans la fiche technique de l'application. |
| Appareil volé avec écran déverrouillé | Ce qu'ils ontUn téléphone en main, déverrouillé | Ce qu'ils obtiennentListe des codes. Le coffre-fort (mots de passe, cartes) est protégé par le verrouillage de l'application et se reverrouille automatiquement après un délai prédéfini (immédiatement / 1 min / 5 min). La valeur déchiffrée est conservée en mémoire uniquement pendant son affichage. Le remplissage automatique et l'exportation en texte clair nécessitent une nouvelle authentification biométrique, même lorsque l'application est ouverte. Activez le verrouillage de l'application sur « Immédiatement » si cela vous inquiète. |
| Application malveillante sur le même téléphone | Ce qu'ils ontLe bac à sable d'une autre application, le presse-papiers, les astuces d'accessibilité ou de superposition | Ce qu'ils obtiennentIl est impossible de lire nos fichiers (isolation de la plateforme) ou d'utiliser notre clé (celle-ci est liée à notre identité de signature et à la présence de l'utilisateur). Les copies sont effacées du presse-papiers après 30 secondes ; sur Android, la copie est marquée comme sensible et exclue de l'historique du presse-papiers. Les écrans du coffre-fort sont marqués comme sécurisés sur Android (pas de captures d'écran, pas d'enregistrement d'écran, écran vide dans le sélecteur) ; sur iOS, la vignette du sélecteur est masquée. La saisie automatique sur Android est uniquement disponible pour les applications vérifiées par le système auprès du domaine enregistré (liens vers les ressources numériques), empêchant ainsi toute utilisation de votre mot de passe par une application similaire. |
| Page d'hameçonnage | Ce qu'ils ontUn site qui ressemble à celui que vous avez enregistré | Ce qu'ils obtiennentAucun champ n'est automatiquement rempli. La correspondance s'effectue par domaine enregistrable (liste de suffixes publics, intégrée et mise à jour avec l'application) : login.example.com et example.com correspondent, example.com.evil.net et examp1e.com ne correspondent pas. Le navigateur intégré fonctionne de la même manière et remplit uniquement le champ demandé, en vérifiant son origine au moment du remplissage. Un hôte sans domaine enregistrable (une adresse IP, un nom de domaine nu sur le réseau local) correspond exactement, sans aucune approximation. La fonction de remplissage automatique d'iOS ajoute la vérification des domaines associés d'Apple. Un mot de passe que vous devez coller manuellement dans un champ similaire représente toujours un risque ; l'application ne peut pas le supprimer, mais seulement éviter d'y contribuer. |
| Nos propres serveurs | Ce qu'ils ont— | Ce qu'ils obtiennentIl n'y a pas de serveur de coffre-fort. AssuredAuth ne possède aucun compte, aucune connexion et aucune copie de votre coffre-fort. Vos données ne sont donc en aucun cas susceptibles d'être volées ou piratées. Deux éléments fonctionnent côté serveur, sans aucun contact avec le coffre-fort : une boîte mail relais pour l'extension de bureau, qui stocke des enveloppes chiffrées de bout en bout (codes à usage unique, supprimés après lecture ; le relais ne possède jamais de clé), et les serveurs de sortie de la connexion privée optionnelle, qui acheminent le trafic et ne conservent aucun journal d'accès. |
| Une assignation à comparaître ou une demande du gouvernement | Ce qu'ils ontProcédure judiciaire adressée à nous | Ce qu'ils obtiennentNous n'avons rien à fournir : nous ne possédons ni coffre-fort, ni clé, ni phrase secrète, ni sauvegarde. On peut nous contraindre à le dire ; on ne peut nous contraindre à produire ce qui n'existe pas. |
5. Presse-papiers, captures d'écran et mémoire
- La commande Copie place la valeur dans le presse-papiers pendant 30 secondes, puis la supprime si elle nous appartient toujours. Sur Android, l'élément copié est marqué EXTRA_IS_SENSITIVE afin que le système le masque dans l'aperçu et l'historique du presse-papiers ; sur iOS, l'élément du presse-papiers est uniquement local (il n'est pas transféré vers d'autres appareils via Handoff).
- Les écrans du coffre-fort (Mots de passe, Mot de passe, Cartes, Fiches de phrases secrètes, Exportation en texte clair) activent l'indicateur FLAG_SECURE sur Android. Sur iOS, il n'existe pas d'indicateur équivalent ; l'application masque sa vignette dans le sélecteur d'applications et les valeurs sont accessibles par défaut via un bouton en forme d'œil.
- Les valeurs déchiffrées sont conservées en mémoire uniquement pendant leur affichage à l'écran et sont supprimées lorsque l'écran disparaît ou que l'application se verrouille. La clé de données est déchiffrée pour chaque requête et n'est pas mise en cache pendant la durée du verrouillage.
- L'exportation en texte brut existe (vous pouvez donc toujours partir) et se fait derrière une feuille de confirmation et une nouvelle biométrie, et son écran est également FLAG_SECURE.
6. Remplissage automatique : ce qui est rempli et ce qui ne l’est pas
| Où | Mots de passe | Cartes |
|---|---|---|
| iOS : Safari et applications (extension AutoFill) | Mots de passeOui, après une nouvelle authentification Face ID / Touch ID / code d'accès dans l'extension (LAContext), et uniquement pour le domaine enregistrable pour lequel l'entrée a été sauvegardée, avec la vérification des domaines associés d'Apple pour les applications. | CartesNon. Le remplissage automatique des cartes dans Safari est une fonctionnalité exclusive d'Apple ; l'écran de la carte indique « Remplissage dans le navigateur AssuredAuth et avec Copie » et ne promet rien d'autre. |
| Android : applications et Chrome (service de remplissage automatique) | Mots de passeOui, authentification par ensemble de données : le système affiche BiometricPrompt avant le remplissage ; le package de l’application est associé uniquement lorsque Digital Asset Links le relie au domaine enregistré | CartesOui, les indications relatives au numéro de carte de crédit, à la date d'expiration* et au code de sécurité, ainsi qu'au portail biométrique, sont utilisées. |
| Le navigateur AssuredAuth (les deux plateformes) | Mots de passeOui, par domaine enregistrable — un hôte sans aucune correspondance exacte avec ses propres noms de domaine — dans le cadre demandé, biométrique avant le remplissage | CartesOui, par détection sur le terrain, biométrique avant le remplissage |
| Boutons Copier | Mots de passeDerrière le verrouillage de l'application, presse-papiers de 30 secondes | CartesNuméro, expiration, CVC (mêmes règles) |
Rien ne se remplit sur un hôte qui lui ressemble. Rien ne se remplit sans la biométrie.
7. Ce qui n'arrive jamais
Aucun serveur de coffre-fort. Aucune donnée analytique contenant un champ de coffre-fort. Aucune exportation en texte brut sans confirmation ni authentification biométrique récente. Aucun SDK tiers chargé sur l'écran du coffre-fort. Aucune capture d'écran de l'écran du coffre-fort. Aucun indice pour le mot de passe. Aucun enregistrement des valeurs, quelle que soit la version.
8. Ce contre quoi nous ne pouvons pas nous protéger
Une phrase de passe trop faible pour être devinée. Un téléphone dont le système d'exploitation est compromis (un appareil jailbreaké ou rooté peut induire l'application en erreur sur tous les points mentionnés ci-dessus). Une personne surveillée pendant qu'elle écrit. Un logiciel malveillant sur le bureau où vous collez le texte. Nous précisons cela afin que la liste ci-dessus soit bien comprise : il s'agit des éléments qu'une conception peut éliminer.
9. État de la revue
Cette conception a été testée unitairement par rapport aux réponses connues et publiées sur les deux plateformes, ainsi que par rapport à ses propres vecteurs multiplateformes. Un examen externe est prévu avant la publication du coffre-fort sur la fiche produit ; en attendant, ce document le mentionnera.
10. Où chaque chose s'exécute
Aucun élément du coffre-fort ne quitte le téléphone, mais certains services associés fonctionnent sur les machines d'autres personnes. Voici la liste et le contenu de chaque service ; les flux de données sont décrits dans la politique de confidentialité disponible à l'adresse https://assuredauth.com/privacy.
- Google Cloud / Firebase — la boîte aux lettres relais pour l'extension de bureau (enveloppes chiffrées de bout en bout, supprimées après lecture), les jetons push, l'état des achats et les messages envoyés via le formulaire de contact.
- Vercel — ensuredauth.com, ses pages et les petites fonctions qui les sous-tendent.
- Vultr — les serveurs de sortie de la connexion privée. Le trafic y transite ; rien n’y est stocké.
- Apple et Google Play — achats et abonnements, dans leurs propres boutiques.
- PostHog — analyse de produits : comptage des utilisations, sans lien avec une identité.
- RevenueCat — l'état d'un abonnement : actif ou expiré, et sur quel forfait.
Chaque article contient ce qu'il indique et rien provenant des archives. La liste évolue en fonction des produits, et cette section est mise à jour en conséquence.
Signaler une faiblesse
Si vous pensez avoir découvert une faille dans l'un des éléments décrits ici, veuillez écrire à hello@assuredauth.com avec pour objet « Sécurité ». Merci d'indiquer la plateforme, la version de l'application et la procédure ; une preuve utilisant vos propres données suffit, et nous vous demandons de ne pas effectuer de tests sur des données tierces. Nous ne fournissons pas de clé PGP ; si un rapport ne doit pas être transmis par e-mail non chiffré, veuillez le préciser dès votre premier message afin que nous trouvions une autre solution.
En contrepartie, nous nous engageons à accuser réception de votre contribution sous trois jours ouvrables, à vous tenir informé(e) de l'avancement du projet, à corriger les erreurs avant toute publication et à vous mentionner comme contributeur(trice) si vous le souhaitez. Nous nous engageons également à ne pas engager de poursuites judiciaires concernant les recherches effectuées de bonne foi dans le cadre défini ci-dessous.
Sont concernés : les applications iOS et Android, les applications pour montres connectées, l’extension de bureau, le site ensureauth.com et son API. Sont exclus : l’App Store et Google Play, les fournisseurs mentionnés ci-dessus, l’ingénierie sociale et les attaques par déni de service.
Aucune prime n'est offerte pour le moment. Un signalement donne lieu à une solution et à des remerciements, pas à une récompense financière.