Le modèle de sécurité.

Cryptographie

• Chiffrement : chaque note est scellée sur votre téléphone avec AES-256-GCM (un nonce de 12 octets et une balise d'authentification de 16 octets) avant tout envoi. Un texte chiffré altéré échoue à l'authentification au lieu de se déchiffrer en n'importe quoi.
• Dérivation de clé : la clé provient de HKDF-SHA256 sur 32 nouveaux octets aléatoires — la clé de fragment — plus un sel aléatoire de 16 octets. Ces 32 octets vont dans le #fragment du lien et nulle part ailleurs.
• Phrase secrète (facultatif) : si vous en définissez une, elle est renforcée par PBKDF2-HMAC-SHA256 sur 600 000 itérations et mêlée à la dérivation, si bien que le lien seul ne suffit plus. Les mauvaises tentatives échouent localement dans le navigateur du destinataire et ne consomment jamais de vues.
• Vérifié deux fois : les implémentations Swift et Kotlin des applis et l'implémentation WebCrypto du lecteur sont vérifiées l'une contre l'autre avec des vecteurs de test générés indépendamment, de sorte qu'une note scellée par l'une s'ouvre toujours dans l'autre.

Le lien à clé dans le fragment

Un lien de note ressemble à burnpony.app/n/<id>#<key>. Tout ce qui suit le # est un fragment d'URL, et les navigateurs n'envoient pas les fragments dans les requêtes HTTP — ni à ce serveur ni à aucun autre. Le serveur apprend l'ID aléatoire de la note ; la clé n'existe que dans le lien lui-même et dans le navigateur du destinataire pendant la lecture. C'est pourquoi « le serveur ne peut pas lire votre note » est une propriété du fonctionnement du web, pas une promesse.

Ce que le serveur stocke — et ne peut pas lire

Tant qu'une note est active, le serveur détient : l'ID aléatoire de la note, le blob de texte chiffré scellé, les horodatages de création et d'expiration, le quota et le compteur de vues, l'indication d'un accusé de lecture demandé, et un hachage du jeton de gestion qui permet à votre appli de brûler la note plus tôt. Si les accusés sont activés, les horodatages d'ouverture sont enregistrés. Voilà l'inventaire. Il n'a jamais la clé, le texte de la note, ni même le réglage de masquage automatique — celui-ci voyage chiffré dans la note. La limitation de débit à la création utilise des hachages d'IP avec un secret serveur qui expirent après environ deux heures, pas des journaux d'adresses bruts.

Le brûlage, et ce qui reste

Quand la dernière vue autorisée est récupérée, le texte chiffré est supprimé dans la même transaction de base de données qui l'a servi. Les notes expirées sont retirées par un balayage qui s'exécute toutes les cinq minutes. Et surtout, une note brûlée, une note expirée et une note qui n'a jamais existé renvoient exactement la même réponse — le serveur ne peut pas servir d'oracle pour confirmer qu'un lien donné a un jour été réel.

Le lecteur

Les destinataires ouvrent une seule page autonome : pas de frameworks, pas de cookies, pas d'analytique, aucune requête ailleurs que vers ce serveur pour la note scellée elle-même. Elle porte une Content-Security-Policy stricte (default-src 'none'), une directive noindex et une politique sans référent pour que le lien ne fuite jamais par les en-têtes de référent. Le déchiffrement se fait dans le WebCrypto intégré du navigateur. La page est assez courte pour être auditée avec Afficher la source — c'est un objectif de conception, pas un hasard.

Accusés de lecture, en toute honnêteté

Les accusés sont optionnels par note. Le destinataire voit « L'expéditeur sera notifié à l'ouverture de cette note » avant de la révéler. La notification que vous recevez est volontairement générique — « Une note a été ouverte. » avec uniquement l'ID de la note attaché — de sorte que rien du contenu de la note ne transite par les serveurs du fournisseur de notifications.

Modèle de menace

BurnPony protège la confidentialité et l'intégrité d'une note face au serveur, aux observateurs réseau et à quiconque trouve plus tard l'URL sans son fragment — et il limite la durée et le nombre de fois qu'une note est lisible. Il suppose que votre téléphone et le navigateur du destinataire se comportent comme documenté. Il ne défend pas contre un logiciel malveillant sur l'un ou l'autre point d'extrémité, ni contre un destinataire qui copie, capture ou photographie la note tant qu'elle est visible — aucun outil d'autodestruction ne le peut. L'autodestruction limite l'accès futur ; elle ne peut pas surveiller le moment de la lecture.

Limites honnêtes

• Le lien est la clé. Quiconque obtient le lien complet (et la phrase secrète, si définie) avant qu'il ne brûle peut lire la note. Envoyez-le par un canal auquel vous confieriez le secret lui-même, ou ajoutez une phrase secrète et partagez-la séparément.
• Les écrans peuvent être capturés. Le compte à rebours de masquage automatique réduit le temps de regard par-dessus l'épaule ; ce n'est pas une protection contre les captures d'écran.
• Téléphone perdu, gestion perdue. Les notes que vous avez envoyées continuent de brûler et d'expirer selon leur propre calendrier, mais sans l'onglet Envoyés de l'appli vous perdez la possibilité de les brûler plus tôt ou d'en vérifier le statut.
• Des métadonnées de niveau réseau existent. Comme tout serveur web, celui-ci voit les adresses IP qui se connectent au niveau réseau pendant qu'il sert les requêtes. Le serveur web devant le relais est configuré avec la journalisation des accès désactivée, et l'application ne conserve que les hachages d'IP salés à durée de vie courte décrits ci-dessus.

La spécification exacte

Chaque affirmation de cette page est énoncée avec précision, constante par constante, sur la page du protocole v1, rédigée d'après le code figé dans le dépôt public et vérifiable avec les vecteurs de test partagés.

Ouvert à l'inspection

Le lecteur est vérifiable dès aujourd'hui sur chaque lien de note, et le cœur cryptographique, le lecteur et le serveur relais sont prévus pour publication — voir la page open source pour l'état d'avancement.

Signaler une vulnérabilité

Vous avez trouvé quelque chose ? Écrivez à NorseHorse@norsehor.se — chiffré avec la clé PGP si vous préférez. Les rapports vont droit au développeur, et les correctifs sortent vite car aucun comité ne fait obstacle.