Sécurité chez qub

Cette traduction est fournie à titre de courtoisie. La version anglaise sur https://qub.social/security fait foi ; en cas de divergence entre cette traduction et la version anglaise, la version anglaise prévaut.

Date d’effet : 23 septembre 2026 Version : 1.1 — revue de l’exactitude de l’implémentation

Pour les chercheurs — référence rapide :

• Où envoyer les signalements : support@qub.social avec le préfixe d’objet [SECURITY].
• Quoi inclure : la vulnérabilité, les étapes pour la reproduire, et toute preuve de concept.
• Notre réponse : nous accusons réception sous 3 jours ouvrables et visons à livrer un correctif sous 90 jours.
• Safe Harbor : nous ne poursuivrons pas en justice les recherches de bonne foi qui suivent les règles du §12 (pas d’accès à des données qui ne vous appartiennent pas, pas de dégradation du service, pas de rétention de données obtenues au-delà de ce qui est nécessaire pour démontrer le problème, nous laisser une fenêtre de divulgation raisonnable).

Tous les détails figurent au §12 (Divulgation coordonnée).

Qui nous sommes

qub.social est exploité par VSPRY AUSTRALIA PTY LIMITED (ABN 41 631 026 330), Level 38, 71 Eagle Street, Brisbane QLD 4000, Australia. Les références à « qub », « nous » et « notre » désignent cette entité.

Contact sécurité : support@qub.social avec le préfixe d’objet [SECURITY].

1. Notre approche

qub est une infrastructure de confiance. Le produit ne vaut rien s’il n’est pas sûr, donc la sécurité n’est pas une fonctionnalité — c’est le substrat. Cette page décrit, en termes concrets, comment nous protégeons notre pile, vos données et l’intégrité du contenu scellé.

La valeur d’un engagement temporel vérifiable croît à mesure qu’une plus grande part d’Internet est générée par des machines. Une transaction de stockage vérifiée ou une ancre du journal de transparence peut établir que le texte chiffré existait au plus tard à l’heure du bloc ; l’artefact scellé prouve séparément l’intégrité du contenu, la liaison au tour drand et les éventuelles signatures d’auteur. C’est en maintenant ces affirmations distinctes que cette page tient ses engagements.

Nous ne vous demandons pas de nous faire confiance. Nous concevons de sorte que la confiance qui nous est demandée soit aussi minime que possible, et là où la confiance est requise, nous expliquons exactement ce qui est l’objet de cette confiance et pourquoi.

Trois principes guident chaque décision de conception :

• Minimiser ce que le serveur peut voir. Dans le flux de message par défaut du navigateur, le texte en clair et la clé d’enveloppe restent sur votre appareil. Le scellement Builder côté serveur, la contresignature des pactes et la récupération explicitement activée ont des limites de confiance différentes, décrites ci-dessous. Lorsque nous détenons des métadonnées, nous les limitons aux besoins de la fonctionnalité choisie.
• Rendre les compromissions localement contenues. Une violation d’un quelconque composant (notre serveur, le fournisseur d’e-mail, un nœud drand) ne devrait pas divulguer du contenu scellé qui n’a pas encore atteint son heure de dévoilement.
• Rendre le protocole auditable. L’artefact scellé est vérifiable de bout en bout avec de la cryptographie publique. Vous n’avez pas besoin de faire confiance à qub le service pour vérifier un qub l’artefact.

2. Modèle de menace

2.1 Ce contre quoi nous protégeons

• Un attaquant qui obtient un accès en lecture à nos données stockées côté serveur avant l’heure de dévoilement. Dans le flux privé par défaut du navigateur, il obtient des métadonnées et des octets enveloppés opaques, mais ni le texte en clair ni K. Cette protection ne s’applique ni à une clé K explicitement conservée pour la récupération, ni à une remise publique/non enveloppée après son tour drand, ni au texte en clair fourni temporairement aux flux Builder /api/v1/seal et de pacte.
• Un attaquant qui intercepte le trafic entre votre navigateur et notre infrastructure. Le TLS se termine à la périphérie de notre CDN ; les charges utiles scellées sont déjà chiffrées avant le transit.
• Un attaquant qui altère une charge utile stockée. L’authentification de l’enveloppe externe, lorsqu’elle est présente, le décodage canonique, le hachage du corps, la nouvelle dérivation de qub_id, la liaison au tour et les signatures facultatives font échouer la vérification ; le lecteur refuse d’afficher le qub.
• Un attaquant qui tente de lier un e-mail d’auteur falsifié à une clé de signature. L’attestation d’e-mail exige la possession à la fois de la clé de signature privée et d’un code unique livré dans la boîte e-mail.
• Un opérateur de balise drand compromis. Le réseau drand utilise des signatures BLS à seuil sur plusieurs opérateurs indépendants ; une minorité ne peut pas falsifier des signatures à publication anticipée.

2.2 Ce contre quoi nous ne pouvons pas protéger

Nous sommes honnêtes sur nos limites. qub ne peut pas se défendre contre :

• Une compromission de votre appareil avant le scellement. Des keyloggers locaux, des extensions de navigateur malveillantes ou un accès physique à un appareil déverrouillé peuvent capturer le texte clair au point de composition.
• Un effondrement du seuil drand. Plusieurs organisations indépendantes opèrent le réseau drand spécifiquement pour rendre cela difficile, mais ce n’est pas cryptographiquement impossible : si suffisamment d’opérateurs s’entendent, ils pourraient dériver les clés timelock à l’avance.
• Les propriétés de publication d’une copie valide. Un qub public/non enveloppé devient déchiffrable après son tour drand. Un qub privé/enveloppé nécessite en plus K ; toute personne qui obtient à la fois les octets stockés et K peut le déchiffrer après le tour. Les enregistrements du stockage permanent et du journal ancré ne peuvent pas être rappelés par leur simple retrait de l’interface du produit qub.
• Un adversaire global qui casse la cryptographie sous-jacente (AES-GCM, hypothèses de couplage BLS12-381, SHA3-256, ML-DSA-65). Si ces primitives tombent, l’écosystème cryptographique au sens large a de plus gros problèmes.

3. Cryptographie côté client

Dans le flux de message par défaut du navigateur, le chiffrement du contenu a lieu avant la requête de téléversement. Deux chemins explicites diffèrent : Builder /api/v1/seal envoie délibérément le texte en clair et la clé K générée par l’appelant au Worker pour un scellement en mémoire, tandis que la préparation et la contresignature d’un pacte envoient le pacte structuré signé au service afin qu’il puisse finaliser l’artefact bilatéral. Aucune de ces exceptions ne doit être confondue avec le chiffrement de bout en bout du chemin navigateur.

3.1 Chiffrement timelock

qub utilise tlock — un chiffrement basé sur l’identité, ancré sur un tour futur de la balise drand. Le chiffrement se déroule dans votre navigateur en utilisant la clé publique du réseau drand ; la clé de déchiffrement n’est publiée publiquement par le réseau drand que lorsque le tour cible est atteint. Personne, y compris nous, ne peut reconstruire la clé de déchiffrement en avance.

Nous ciblons la chaîne quicknet :

• Période de tour de 3 secondes
• Mode unchained (chaque tour est indépendant)
• Signatures BLS12-381 G1
• Hachage de chaîne 52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971

La clé publique et l’heure de genèse de la chaîne quicknet sont compilées dans le client. Nous ne récupérons pas les paramètres de chaîne au runtime, donc un nœud malveillant ne peut pas substituer une chaîne que nous contrôlerions.

3.2 Chiffrement symétrique

Le schéma tlock enveloppe une clé de contenu AES-256-GCM. AES-GCM fournit un chiffrement authentifié : un seul bit retourné dans le chiffré entraîne l’échec du déchiffrement, plutôt que de produire un texte clair silencieusement corrompu.

3.3 Sérialisation canonique

Les structures du protocole sont sérialisées à l’aide de CBOR déterministe (RFC 8949 §4.2 core deterministic encoding). Deux implémentations qui encodent la même structure logique produisent un CBOR identique. Les charges utiles scellées complètes ne sont pas déterministes : le chiffrement tlock et celui de l’enveloppe externe utilisent un aléa frais. Le hachage du corps est calculé sur les octets bruts du corps, tandis que l’encodage canonique rend sans ambiguïté les structures signées et du format de fil qui l’entourent.

Nous avons écrit l’encodeur CBOR à la main pour notre client et notre serveur plutôt que de nous appuyer sur une bibliothèque de sérialisation générique — l’exigence est l’exactitude, pas l’ergonomie, et des property tests s’exécutent dans les deux implémentations pour vérifier qu’elles s’accordent.

Un test de régression assure que le format de fil canonique ne contient aucune séquence d’octets de marque qub au-delà de la clé du champ de primitive de protocole qub_id. Le format de fil est intentionnellement agnostique de la marque — tout lecteur conforme (le nôtre ou celui d’un tiers) peut afficher tout qub depuis le stockage permanent, quel que soit le déploiement qui l’a scellé. Le test est un fil-piège qui empêche une modification future d’ancrer accidentellement une référence de marque dans des octets qui, une fois sur le stockage permanent, ne peuvent pas être réécrits.

3.4 Hachage du corps et intégrité avant le dévoilement

Chaque charge utile scellée porte un hachage SHA3-256 des octets bruts de son corps. Le hachage est lié à qub_id et, lorsque la signature d’auteur est activée, à l’entrée de signature V2. Un lecteur le recalcule après le déchiffrement et rejette toute différence.

L’identifiant de contenu de 32 octets qub_id est dérivé d’une pré-image de 108 octets couvrant la version du protocole, le type de contenu, les horodatages de création et de déverrouillage, l’horodatage de résultat facultatif (ou sa sentinelle nulle), le tour drand cible, le hachage du corps et le SHA3-256 du titre facultatif normalisé NFC. Une passerelle ou un CDN ne peut modifier de manière cohérente aucun champ lié tout en réussissant la nouvelle dérivation. Les titres sont plafonnés à 100 points de code NFC et rejetés s’ils appartiennent à la classe commune des points de code hostiles ou de contrôle, notamment les forçages bidi, les caractères de largeur nulle, le bloc des étiquettes, le BOM, C0, C1 et DEL.

3.5 Signature (ML-DSA-65)

La signature d’auteur utilise ML-DSA-65 (FIPS 204), un schéma de signature post-quantique standardisé par le NIST. Nous avons délibérément choisi une primitive post-quantique pour la signature parce que le contenu scellé est permanent : une signature qui se vérifie aujourd’hui doit toujours se vérifier dans des décennies, y compris après que des ordinateurs quantiques à grande échelle deviennent praticables.

Les clés de signature sont générées dans le navigateur. Le secret local est enveloppé sous une clé WebCrypto non extractible avant d’être stocké dans IndexedDB. Si la fonctionnalité de récupération multi-appareils liée au compte est utilisée, un blob de clé portable chiffré par AEAD est stocké côté serveur ; le texte chiffré de sa clé secrète est lié à l’identifiant immuable du compte, et le service valide l’enveloppe publique sans pouvoir déchiffrer le matériel secret. Les octets bruts de la clé privée ne sont pas envoyés au serveur. Les clés publiques et les enregistrements d’attestation sont stockés pour la vérification et l’affichage de l’identité.

Le même déchiffrement tlock dans le navigateur s’applique à l’intérieur de l’embed qub : quand un qub scellé est affiché via <qub-embed> sur une page tierce, le déchiffrement a toujours lieu dans l’iframe d’embed, dans le navigateur du lecteur. L’embed ne change pas le modèle de confiance — le texte clair n’est jamais déchiffré sur un serveur qub.

3.6 Attribution publique — opt-in

Les qubs scellés ne portent aucun pointeur on-chain vers leur créateur sauf si le créateur choisit explicitement d’en attacher un. Quand vous scellez un qub, l’application de référence émet un tag de stockage Author (une empreinte hex de 64 caractères de votre clé publique de signature) uniquement quand l’option « Attribution publique » est activée à l’étape sélecteur de date. Quand l’interrupteur est désactivé — par défaut — aucun tag Author n’est écrit et le qub n’est pas attribué sur le stockage permanent : rien sur le stockage ne lie l’envoi à votre identifiant, à votre adresse e-mail ou à vos autres qubs. Quand l’interrupteur est activé, l’empreinte se résout à votre @handle via la chaîne d’attestation au §6.3 / §10 et le compte à rebours du lecteur affiche « Scellé par @{handle} » avant le dévoilement.

C’est une protection délibérée contre le risque d’énumération qu’un tag Author toujours actif créerait : un tiers qui apprend l’empreinte d’un créateur pourrait sinon parcourir le stockage permanent par ce tag et reconstituer toute la production historique de ce créateur. L’attribution opt-in ferme ce canal — seuls les qubs que le créateur choisit explicitement d’attribuer apparaissent sous une empreinte sur le stockage permanent.

La page de profil /u/{handle} est une carte d’identité vérifiée — identifiant, nom affiché et URL facultatifs, pastille « e-mail vérifiée » (sans l’adresse) et la forme courte de l’empreinte cryptographique. Elle ne liste pas les qubs d’un créateur. Les visiteurs qui veulent voir un qub spécifique d’un créateur suivent l’URL de remise de ce qub directement.

3.7 Enveloppe de chiffrement externe

Même après que le déchiffrement timelock devient mathématiquement possible — une fois publiée la signature drand du tour lié — la couche timelock canonique seule permettrait à un indexeur de déchiffrer en masse les qubs découvrables. La remise privée ferme ce canal par une couche symétrique supplémentaire autour des octets chiffrés par timelock (Protocole §13). La remise publique omet intentionnellement l’enveloppe afin que les liens de notification, d’embed et de découverte fonctionnent sans fragment secret.

L’enveloppe utilise AES-256-GCM, un chiffrement authentifié standardisé par le NIST, avec une clé fraîche de 256 bits K générée par qub par le CSPRNG de votre navigateur. K est liée au qub_id du qub comme données authentifiées additionnelles, donc une clé d’un qub ne peut pas être réutilisée pour déchiffrer un autre qub.

K n’atteint jamais nos serveurs dans le flux privé par défaut du navigateur. Elle est encodée dans le fragment d’URL du lien de partage (https://qub.social/c/<tx_id>#<base64url(K)>). Les navigateurs ne transmettent pas les fragments d’URL aux serveurs — la RFC 3986 place le fragment en dehors de la requête — si bien que qub.social, les passerelles de stockage, les CDN et la surveillance des requêtes ne voient pas K dans ce flux. Le OuterWrapper stocké est un CBOR structuré reconnaissable, mais son champ de chiffré authentifié masque la structure interne de SealedQub et ne peut pas être ouvert sans K.

Conséquences nettes :

• qub.social ne peut pas déchiffrer les scellements privés du navigateur par défaut à partir des seules données stockées. Une compromission du magasin de données donne accès à un texte chiffré opaque sans K. Les qubs publics et ceux pour lesquels la récupération est activée présentent délibérément une exposition différente.
• La perte du fragment est irrécupérable sans canal de récupération activé. Si vous enregistrez un lien privé sans le fragment et n’avez pas activé la récupération, le qub devient illisible par ce lien. Le flux de scellement affiche pour cette raison un avertissement explicite vous demandant d’enregistrer cette URL.
• Récupération opt-in. Quand vous optez pour les e-mails de cycle de vie créateur pour un qub ET que l’adresse e-mail correspond à votre identité vérifiée, nous acceptons K avec l’envoi, stockons l’URL de remise complète sur l’enregistrement d’historique scellé de votre identité, et l’utilisons comme lien dans l’e-mail de confirmation de scellement. Ce compromis — un canal de récupération côté serveur en échange d’une perte de pureté bout-en-bout — n’est engagé que sur opt-in explicite et uniquement pour ce qub. La posture par défaut est la crypto-déchirure.

L’endpoint serveur du Worker /api/v1/seal (utilisé par les agents IA et autres appelants d’API) exige que l’appelant génère K à l’aide d’un CSPRNG, la conserve localement et la fournisse sous la forme wrapper_key_b64url. Le Worker voit nécessairement à la fois le texte clair et K en mémoire sur ce chemin qui repose sur une confiance explicite, mais ne persiste ni l’un ni l’autre. Un Idempotency-Key obligatoire empêche qu’une réponse perdue crée un second qub facturé, tandis que K, conservée par l’appelant, peut être combinée avec l’URL rejouée sans fragment. Cela diffère du chemin navigateur par défaut, où K n’atteint jamais le Worker à moins que le créateur n’active explicitement la récupération.

4. Transport et périphérie

4.1 TLS

Le trafic du navigateur vers qub est servi par HTTPS à la périphérie Cloudflare. Les réponses définissent HTTP Strict Transport Security (max-age=63072000; includeSubDomains; preload). La version TLS et la suite cryptographique effectivement négociées sont régies par la configuration active de la périphérie, et non affirmées par le code de l’application. Nous n’exposons aucun serveur d’origine joignable séparément.

4.2 Sécurité du contenu

Le client compilé est servi avec des en-têtes content-type et cache stricts. La SPA est sur une origine unique. Nous n’incorporons pas de scripts tiers pour des analyses ou de la publicité. Les deux points de contact tiers dans le produit sont étroitement délimités : le flux d’achat quitte la SPA entièrement avec une redirection plein écran vers le checkout hébergé par Stripe (https://checkout.stripe.com/…) — l’UI de Stripe ne s’exécute jamais dans notre origine et nous ne voyons jamais les données de carte — et le flux de scellement charge le widget Turnstile de Cloudflare, une alternative de CAPTCHA respectueuse de la vie privée que Cloudflare affiche dans sa propre iframe sandboxée. Aucune des deux parties ne peut lire le reste de la page.

L’iframe d’embed qub (servie depuis qub.social/embed/{tx_id} et chargée dans des sites tiers par embed.js) porte sa propre Content-Security-Policy. Sa liste autorisée connect-src comprend 'self', https://qub.social, https://arweave.net, https://ar-io.dev, https://permagate.io, https://api.drand.sh et https://drand.cloudflare.com. L’iframe s’exécute avec sandbox="allow-scripts allow-top-navigation-by-user-activation" (sans allow-same-origin) : la page hôte ne peut pas lire son DOM et elle ne peut pas naviguer l’hôte, sauf après une action de l’utilisateur.

4.3 CORS et portée des fetchs

Le client navigateur fait des requêtes fetch uniquement vers :

• Notre propre API (api.qub.social et les équivalents staging)
• Les passerelles de stockage (lecture seule, pour récupérer les octets privés enveloppés ou publics nus — §3.6)
• Les endpoints de balise drand (lecture seule, pour les signatures de tour à l’heure de dévoilement)

Les destinations de l’embed sont imposées par son CSP. Les destinations prévues de la SPA principale sont fixées dans le code et la configuration, puis exercées par les contrôles du navigateur et d’intégration ; Subresource Integrity n’est pas un mécanisme de contrôle des destinations réseau.

L’embed récupère les octets stockés auprès des origines qub et de stockage autorisées, déballe les charges utiles privées dans le navigateur grâce à K tirée de son fragment d’URL et récupère auprès des deux origines drand autorisées les signatures de tour nécessaires au dévoilement. La SPA principale utilise l’ensemble de repli à quatre endpoints dans config/drand-endpoints.json (drand.cloudflare.com, api.drand.sh, api2.drand.sh et api3.drand.sh) afin qu’une panne d’un endpoint ne bloque pas le dévoilement. Le CSP de l’embed interdit les connexions hors de sa liste explicite.

5. Infrastructure côté serveur

5.1 Périphérie serverless

Notre API tourne entièrement sur un runtime serverless managé en périphérie. Il n’y a pas de VM, pas de conteneurs, et pas de processus serveur persistants que nous administrons. Cela réduit considérablement la surface d’attaque dont nous sommes responsables : nous ne faisons tourner ni système d’exploitation, ni serveur web, ni runtime applicatif que nous devons patcher.

Un middleware CORS public séparé s'applique Access-Control-Allow-Origin: * au chemin défini mis en œuvre suivant : /embed.js, /embed/v1.js, tout ce qui est sous /embed/; /api/v1/telemetry; /api/v1/openapi.json; tout en dessous /api/v1/qub/ (y compris les sous-routes bytes, metadata, proof, engagement, notify et push); tout ce qui se trouve sous /api/v1/log/; gérer les recherches publiques sous /api/v1/handle/; et l'avatar public lit en dessous /api/v1/identity/avatar/. Ses permis de pré-vol GET, POST, et OPTIONS avec le Content-Type en-tête requête. Cette surface basée sur les préfixes est plus large que les seuls appels que l’embed effectue actuellement, donc chaque gestionnaire en dessous de ces préfixes doit continuer à appliquer ses propres contrôles de validation, authentification, limites de débit et abus. D’autres chemins API conservent la politique CORS qub.social-restreinte.

5.2 Stockage

• Les magasins de métadonnées et de coordination détiennent les enregistrements d’identité et d’attestation, les droits et références de facturation, les enregistrements de clés API, les entrées de liste de blocage, les sessions, l’état d’idempotence, les files d’attente ainsi que l’état des limites de débit et de concurrence. Les différents besoins de cohérence utilisent KV, D1 et Durable Objects plutôt qu’un magasin universel.
• Notre magasin d’objets constitue également un support de durabilité. Il contient les octets exacts, enveloppés ou non, du qub dont le téléversement a été acquitté, les feuilles du journal de transparence et les nœuds de Merkle indexés par coordonnées, le matériel d’ancrage, les journaux d’événements structurés et les caches de réponses et de métadonnées.
• Le stockage public permanent contient les ancres du journal de transparence et, pour le chemin T3 ou la publication différée, des transactions individuelles de qub. Nous n’exploitons pas ce réseau. Les charges utiles privées du navigateur y restent opaques, sauf si leur détenteur possède également K ; les charges utiles publiques/non enveloppées ne comportent délibérément pas cette couche supplémentaire de capacité liée au lien.

Le flux de message par défaut du navigateur ne persiste aucun texte en clair sur l’infrastructure de qub. Builder /api/v1/seal traite le texte en clair et K en mémoire, mais ne persiste ni l’un ni l’autre. La préparation d’un pacte stocke nécessairement le pacte structuré signé jusqu’à sa contresignature, son retrait ou son expiration. La récupération opt-in stocke une capacité de remise — le lien complet contenant le fragment — afin de pouvoir la récupérer ultérieurement. Nous ne décrivons donc pas l’ensemble de la couche de stockage comme constitué « uniquement de métadonnées ».

5.3 Secrets

Les secrets — portefeuilles de signature, jetons de fournisseurs et clés HMAC — sont fournis par des liaisons de secrets ou d’environnement de la plateforme, et non par le contrôle de source. Les composants d’exécution ne reçoivent que les liaisons dont ils ont besoin. Les procédures de rotation et de chevauchement sont propres à chaque composant ; nous ne revendiquons aucun mécanisme universel de rotation automatique ou auditée.

5.4 Journalisation et télémétrie

Des journaux JSON structurés sont écrits sur chaque requête API avec un identifiant de corrélation exposé dans l’en-tête de réponse X-Request-Id. La télémétrie client est anonyme — pas d’identifiant d’appareil, pas d’adresse IP, pas d’aperçu de contenu. Les événements sont mis en mémoire tampon et flushés au mieux ; un flush échoué est ignoré, pas réessayé. La télémétrie est conçue pour être désactivable au niveau réseau sans affecter le produit.

6. Authentification

6.1 Connexion par lien magique

La connexion utilise un jeton à usage unique signé HMAC et livré dans votre boîte e-mail. Le lien est valable pendant 15 minutes et sa rédemption fait l’objet d’une revendication atomique, de sorte que toute utilisation concurrente ou rejouée est rejetée de manière sûre. En cas de succès, le navigateur reçoit un cookie opaque __Host-qub_session doté des attributs Secure, HttpOnly, SameSite=Strict et Path=/.

Les sessions ont une limite d’inactivité de 30 jours et une limite absolue de 90 jours, sont renouvelées après 24 heures et n’acceptent que la génération immédiatement précédente pendant un délai de grâce de 120 secondes en cas de réponse perdue. Les modifications sensibles du compte exigent une authentification au cours des 10 minutes précédentes. Le secret de signature HMAC est une liaison de plateforme ; la seule lecture des métadonnées ne permet pas de créer un jeton valide.

6.2 Clés API (niveau Developer)

Les clés API développeur utilisent le préfixe qub_sk_ pour faciliter la reconnaissance et la recherche grep. Chaque clé :

• Est liée à un compte, à des portées et à une liste facultative de plages CIDR IP autorisées
• N’est affichée sous sa forme brute qu’une fois ; les enregistrements persistants conservent son hachage SHA-256, et non le secret Bearer
• Peut être renouvelée avec une correspondance de grâce d’une heure, pendant laquelle l’ancienne clé renvoie vers sa remplaçante
• Possède un état indépendant de quota et de limite de débit
• N’est jamais journalisée en intégralité ; les journaux n’enregistrent que l’identifiant de la clé

Les endpoints admin de gestion des clés sont protégés derrière un identifiant admin séparé.

6.3 Attestation d’e-mail (signature d’auteur)

Lier une adresse e-mail à une clé de signature exige :

1. La possession de la clé de signature privée (vous signez un challenge)
2. La possession de la boîte e-mail (vous saisissez un code à 6 chiffres livré par e-mail)

L’un seul ne suffit pas. La révocation est un enregistrement signé sur votre propre compte et prend effet immédiatement ; les lecteurs qui récupèrent l’attestation voient l’état révoqué et l’affichent en conséquence.

7. Paiements

La saisie et le traitement des cartes s’effectuent dans le checkout hébergé par Stripe. Nous ne recevons jamais les numéros de carte, les dates d’expiration ou les CVC. Nous stockons les identifiants Stripe de client et d’abonnement, l’état de l’abonnement et les données de période dans les enregistrements de droits et de clés API afin de rapprocher les accès, renouvellements, mesures d’usage, résiliations et remboursements. Les déclarations de confidentialité et de sécurité de Stripe régissent son traitement des données de paiement.

L’endpoint de scellement vérifie l’enregistrement de droits par recoupement avec l’identifiant d’appareil et, pour les utilisateurs connectés, avec l’identité liée. Un droit ne peut pas être réutilisé entre appareils sans que l’utilisateur ne le restaure explicitement via une connexion par lien magique.

8. Résistance aux abus

8.1 Détection de bot

Le flux de scellement est protégé par une alternative de CAPTCHA respectueuse de la vie privée qui n’utilise pas de cookies pour le suivi et ne fait pas de fingerprinting publicitaire. Un challenge échoué est rejeté par notre Worker de périphérie avant tout traitement côté scellement.

8.2 Limites de débit

Les limites de débit sont appliquées à plusieurs couches :

• Limites par IP et par clé sur les endpoints de scellement, lecture et auth
• Limites par e-mail sur les requêtes de lien magique (empêche le flood de boîtes mail)
• Limites par contrepartie sur les e-mails d’invitation à pacte (dix par adresse destinataire et par jour UTC, principale mitigation contre le relayage de spam ; les pactes honnêtes n’atteignent presque jamais le plafond)
• Limites par IP sur la soumission de télémétrie

Les compteurs et les revendications atomiques sont répartis entre KV, Durable Objects et les liaisons de limite de débit de la plateforme selon les besoins de cohérence de chaque endpoint. Les requêtes limitées renvoient 429 ; les endpoints capables de calculer un délai avant nouvelle tentative incluent Retry-After.

8.3 Modération de contenu

La route de téléchargement par défaut du navigateur ne peut pas analyser le corps : elle ne reçoit que l'artéfact scellé par le client. Le Constructeur /api/v1/seal la route voit le texte en clair de manière transitoire, et la préparation du pacte conserve les termes structurés jusqu'à la finalisation, mais ces exceptions de confiance ne transforment pas le chemin de téléchargement général aveugle aux octets en un scanner de contenu. La modération opérationnelle est un liste de refus au niveau du lecteur : un qub sur liste noire est refusé par notre lecteur, que la charge utile stockée soit toujours accessible ou non. La mise sur liste noire ne retire pas les octets durables, les entrées du journal de transparence ou les données du réseau permanent déjà publiées.

Les signalements d’abus sont à débit limité en utilisant un hachage à sens unique de l’IP de l’auteur du signalement ; nous ne stockons pas les IP en clair à cette fin.

9. Chaîne d’approvisionnement et intégrité de build

9.1 Toolchain épinglée

Les versions du compilateur et du runtime sont épinglées dans la configuration du dépôt, et les dépendances sont résolues au moyen de lockfiles versionnés. CI vérifie l’actualisation des fichiers générés et les invariants sensibles à la reproductibilité. Nous ne formulons pas l’affirmation plus forte selon laquelle chaque build propre serait identique bit pour bit sur toutes les machines prises en charge.

9.2 Lints et analyse statique

Le workspace active nos groupes de lint les plus stricts au niveau deny. CI traite chaque avertissement — y compris les avertissements de liens de documentation — comme un échec de build. C’est délibéré : nous utilisons la sévérité des lints comme fil-piège pour les régressions subtiles.

9.3 Gates CI

Le workflow CI couvre le formatage et les lints stricts ; les tests Rust, WASM/navigateur, Worker, embed et API ; la vérification des types ; la couverture du code ; les contrôles de mutations et d’invariants ; l’analyse statique des dépendances et des workflows ; les contrôles des clés i18n, de la couverture, de la dérive et des points de code hostiles ; l’actualisation de la documentation, de l’API et de la base de connaissances générées ; l’inventaire des documents et les liens internes ; les budgets des feuilles de style et des bundles ; ainsi que la validation OpenAPI. Certains jobs de mutation coûteux sont planifiés plutôt qu’exécutés à chaque push.

Un seul agrégat ci requis reste rouge si un job obligatoire échoue. Les branches protégées et les workflows de déploiement consomment ce résultat au lieu de dupliquer une barrière de sécurité plus restreinte.

9.4 Tests de mutation

Un job hebdomadaire exécute des tests de mutation contre les modules purs critiques pour la sécurité : hachage, CBOR canonique, scellement, déverrouillage, newtypes du format de fil, validateurs de types de protocole, et l’espace de noms d’identifiants. Les tests de mutation répondent à la question « notre suite de tests attrape-t-elle du code subtilement faux ? » — si une implémentation mutée passe encore tous les tests, nous savons qu’il y a un trou de couverture et nous l’adressons.

9.5 Hooks Git

Les hooks locaux (pre-commit, pre-push) reflètent les gates CI afin que les régressions soient attrapées avant qu’elles ne quittent la machine du développeur. Les hooks sont installés via un script du dépôt ; ils ne sont pas contournés dans notre flux et le CI est le gate autoritaire s’ils sont sautés.

10. Tests

Le code critique pour la sécurité porte trois types de tests :

• Tests unitaires vérifient le comportement attendu sur des entrées connues, y compris des vecteurs de test dérivés de la spécification du protocole.
• Tests de propriété génèrent des milliers d’entrées arbitraires et vérifient des invariants : aller-retour CBOR canonique, aller-retour de vérification de signature, prédicats de liaison d’e-mail, déterminisme de l’accusé de réception de pacte.
• Tests cross-implementation vérifient que nos implémentations client et serveur s’accordent octet par octet sur les encodages canoniques. Cela attrape la divergence entre les deux implémentations avant qu’elle n’atteigne la production.

11. Hygiène de branche et de release

Les branches de fonctionnalité ne font avancer staging que par une pull request Gate 1 : ci requis au vert, aucune demande de modification non résolue, aucun conflit de fusion et un arbre propre et revu ; la fusion est comprimée en un commit, puis la branche est supprimée. main n’avance que par la pull request Gate 2 staging → main, qui préserve l’ascendance au moyen d’un commit de fusion. Les pushs directs vers les branches ne font pas partie du flux de release.

Les déploiements staging et production sont déclenchés depuis les états correspondants des branches protégées staging et main après CI. Le code des pull requests et les identifiants des forks ne reçoivent pas les secrets de déploiement.

Les secrets utilisés dans les workflows de déploiement sont limités à l’environnement de déploiement par notre plateforme CI. Ils ne sont pas accessibles aux workflows de pull-request depuis des forks.

12. Divulgation coordonnée

Si vous estimez avoir trouvé une vulnérabilité de sécurité dans qub, nous voulons en entendre parler rapidement et nous nous engageons à traiter le signalement de manière professionnelle.

• Écrivez à support@qub.social avec le préfixe d’objet [SECURITY].
• Décrivez la vulnérabilité, les étapes pour la reproduire, et toute preuve de concept.
• Donnez-nous une fenêtre de divulgation raisonnable (typiquement 90 jours) avant la publication.
• N’accédez pas à des données qui ne vous appartiennent pas, ne dégradez pas le service pour d’autres utilisateurs, et ne conservez pas les données obtenues durant la recherche au-delà de ce qui est nécessaire pour démontrer le problème.

Nous accusons réception sous trois jours ouvrables et vous tenons informé pendant nos investigations. Avec votre consentement, nous créditons les rapporteurs dans les notes de version.

12.1 Safe Harbor

Si votre recherche suit les règles ci-dessus (investigation de bonne foi, sans nuire à d’autres utilisateurs ou au service, fenêtre de divulgation raisonnable), nous ne vous poursuivrons pas en justice et nous ne demanderons pas aux forces de l’ordre de le faire. Nous traitons votre travail comme des tests autorisés et nous préférons que vous trouviez le bug plutôt que quelqu’un d’autre.

Ce Safe Harbor s’applique à :

• La recherche sur le service qub.social en ligne (pas sur les fixtures de test que nous publions à cette fin).
• L’ingénierie inverse de nos binaires publiés et des crates open-source qub-core / qub-app.
• Toute classe de vulnérabilité — protocole, application, infrastructure, chaîne d’approvisionnement — qui affecte qub.

Il ne s’applique pas à l’ingénierie sociale des membres de l’équipe qub, aux tests de déni de service, ni à l’accès aux données d’autres utilisateurs au-delà de ce qui est nécessaire pour démontrer le problème. Si vous n’êtes pas certain qu’une chose tombe à l’intérieur du Safe Harbor, demandez d’abord en utilisant le même préfixe d’objet [SECURITY].

13. Limites assumées

La sécurité est une pratique, pas un état. Certaines limites méritent d’être nommées directement :

• Nous sommes une petite équipe. La profondeur de notre revue n’égale pas la fonction dédiée de sécurité applicative d’une grande entreprise. Nous compensons par des gates automatisés stricts et une surface d’attaque minimale, mais nous ne revendiquons pas l’infaillibilité.
• La permanence de notre backend de stockage est une porte à sens unique. Si une erreur fait que du contenu scellé devient déchiffrable plus tôt que prévu, nous ne pouvons pas l’annuler. Nous traitons le flux de scellement avec un soin proportionné.
• Le réseau drand est une dépendance externe. Une défaillance catastrophique de drand affecterait le comportement de dévoilement de chaque qub. Nous surveillons la santé de drand et avons une documentation de contingence pour la migration de chaîne en cas de besoin. Pour les dates de déverrouillage à plus de 2 ans, le modal de confirmation au moment du scellement affiche une mise en garde explicite : les qubs à long horizon dépendent de la durabilité de la chaîne drand, et une migration future de chaîne drand peut requérir des étapes de récupération pour déverrouiller le qub. Pour les dates de déverrouillage à plus de 5 ans, vous devez cocher une case supplémentaire confirmant que vous avez lu et accepté ce risque avant que le scellement ne se poursuive.
• Les primitives cryptographiques sur lesquelles nous nous appuyons sont standardisées et largement examinées, mais la cryptographie évolue. Là où nous avons des choix (signature post-quantique, chiffrement authentifié), nous prenons l’option la plus conservatrice.

14. Modifications de cette page

Les modifications matérielles sont notées en mettant à jour la date d’effet en haut. Lorsqu’un changement reflète une amélioration concrète de sécurité, nous la décrivons brièvement dans le changelog public. Lorsqu’un changement reflète une clarification de politique, nous décrivons ce qui a changé et pourquoi.

Pour toute question sur cette page, écrivez à support@qub.social avec le préfixe d’objet [SECURITY].

15. Journal des modifications