Sécurité et architecture

En bref

• Aller par la lumière : Bouraq Prism, un fichier HTML ouvert depuis le disque, chiffre les fichiers avec la clé du compte et les affiche en codes QR ; une caméra autorisée les lit et les envoie à l'espace du compte, où ils sont reconstitués et vérifiés (sha256).
• Retour par un canal que vous choisissez : le dépôt GitHub ou GitLab privé de l'utilisateur, ou une clé USB. Il ne passe jamais par nos serveurs.
• Rien à installer, aucun accès réseau ouvert : pas d'agent, pas d'exécutable, pas de synchronisation en arrière-plan. Le poste hors ligne n'émet que de la lumière.
• Pas de chiffrement de bout en bout aujourd'hui : notre serveur détient la clé de chaque compte et déchiffre les fichiers pour les reconstituer. Voir « Ce que voit notre serveur ».
• Hébergement dans l'Union européenne : Hetzner, centre de données d'Helsinki (Finlande).

Flux de données

Aller (poste hors ligne → espace de l'utilisateur) :

• Sur le poste hors ligne, Prism compresse les fichiers (zlib) et les chiffre avec la clé du compte (XSalsa20-Poly1305), nom de fichier compris, puis les découpe en codes QR numérotés avec un contrôle d'intégrité.
• L'application Bouraq lit les codes avec la caméra d'un téléphone ou la webcam d'un ordinateur et les envoie en HTTPS au serveur, associés au compte connecté.
• Le serveur réassemble le flux, le déchiffre avec la clé du compte, vérifie l'empreinte sha256 et dépose le fichier dans l'espace du compte.
• Sur le poste personnel, l'utilisateur télécharge le fichier depuis son espace, dans un navigateur.

Retour (poste personnel → poste hors ligne) : Prism emballe le dossier modifié en un seul fichier texte (Repomix) et le pousse vers le dépôt privé de l'utilisateur, ou l'enregistre pour une clé USB. Sur le poste hors ligne, Prism vérifie chaque chemin avant d'écrire et ne supprime jamais de fichier. Ce trajet ne touche pas nos serveurs.

Ce que voit notre serveur

Pour reconstituer et vérifier un transfert, le serveur déchiffre son contenu : il voit donc le fichier, son nom et sa taille. Le fichier est conservé dans l'espace du compte jusqu'à 7 jours après son arrivée, puis supprimé ; avec l'option « Delete after download », il est supprimé dès son téléchargement complet, et seuls son nom, sa taille, son empreinte et son reçu restent ; un transfert qui dépasse le quota est supprimé dès sa récupération et au plus tard après 24 heures. Aucun chiffrement au repos n'est revendiqué par l'application.

Le serveur ne voit jamais : le trajet retour (dépôt privé ou clé USB), le jeton d'accès GitHub ou GitLab, ni les fichiers du poste hors ligne que l'utilisateur n'a pas choisis.

Si votre organisation exige que le contenu ne soit jamais lisible par un tiers, Bouraq peut fonctionner sur un serveur que vous contrôlez : écrivez-nous.

Cryptographie et comptes

• Chiffrement des transferts : XSalsa20-Poly1305 (secretbox de TweetNaCl), clé aléatoire de 32 octets propre à chaque compte, nonce aléatoire de 24 octets par transfert. Un code QR photographié sans la clé ne révèle rien du contenu.
• Clé versionnée : renouveler son Prism depuis l'application change la clé et fait refuser les copies précédentes par le serveur.
• Intégrité : contrôle par code et empreinte sha256 du fichier complet, vérifiée avant la mise à disposition.
• Transport : HTTPS uniquement (TLS 1.2 et 1.3, certificats Let's Encrypt).
• Mots de passe : empreintes scrypt ; tentatives de connexion limitées. Session navigateur par cookie HttpOnly, Secure, SameSite=Lax, valable 30 jours au plus.
• Authentification à deux facteurs (TOTP, RFC 6238) pour chaque compte, compatible avec toute application d'authentification ; une organisation peut l'imposer à ses administrateurs. Un jeton pour la ligne de commande exige aussi le code.

Le fichier Bouraq Prism

Prism est un unique fichier HTML d'environ 490 Ko que l'utilisateur ouvre depuis son disque. Votre équipe peut le lire avant usage : tout le code est dans le fichier.

• Politique de sécurité du contenu (CSP) : default-src 'none' ; seules connexions permises : api.github.com et gitlab.com, et uniquement quand l'utilisateur utilise le retour par dépôt privé.
• Avant tout envoi ou toute lecture, Prism demande au fournisseur si le dépôt est privé et refuse un dépôt public ou interne.
• Bibliothèques intégrées, versions figées et vérifiées par empreinte : pako 2.1.0, fflate 0.8.2, qrcode-generator 1.4.4, js-sha256 0.11.1, TweetNaCl 1.0.3.
• La copie personnalisée contient la clé du compte : elle se garde comme un identifiant.
• Vérifiez la copie avant de l'introduire : votre espace affiche l'empreinte SHA-256 de votre copie (certutil -hashfile <fichier> SHA256 sous Windows, shasum -a 256 sous macOS, sha256sum sous Linux). Chaque copie délivrée entre au journal d'audit avec cette empreinte et la version de clé ; un renouvellement de clé y est aussi inscrit et révoque les anciennes copies.
• Version signée : l'instance publie la déclaration signée du gabarit de chaque version de Prism (/.well-known/bouraq-prism.json). La commande bouraq-verify.py prism du script de vérification retire d'une copie sa seule ligne de compte et prouve que tout le reste est exactement ce code, octet pour octet, sans jamais afficher la clé.
• Chaque code affiché par Prism porte, sous son numéro, le compte et les 8 premiers caractères de l'empreinte sha256 du fichier, celle du journal d'audit : un transfert autorisé se reconnaît à l'écran, et un usage discret serait visible des collègues.

Hébergement et sous-traitants

• Hetzner Online GmbH : serveur, base de données et fichiers, centre de données d'Helsinki (Finlande, UE).
• Cloudflare, Inc. : noms de domaine et réception des e-mails adressés à contact@getbouraq.com.
• Stripe : paiement et abonnement ; les données de carte ne nous parviennent jamais.
• Google Workspace : notre messagerie, où arrivent vos e-mails.
• La mesure d'audience est hébergée sur notre propre serveur, sans outil de suivi externe.

Le détail des données et des durées figure dans la politique de confidentialité.

Gouvernance et usage autorisé

Bouraq est un canal de transfert neutre : il n'exploite aucune vulnérabilité et ne désactive aucun contrôle. Nos conditions n'autorisent que le transfert de contenus que l'utilisateur a le droit de déplacer.

• Chaque transfert est rattaché à un compte nominatif, horodaté et identifié par son empreinte sha256.
• Autorisation au dossier : chaque compte consigne qui l'a autorisé à faire sortir des données, son rôle, le périmètre et la période. Elle entre au journal d'audit, accompagne chaque transfert livré et figure sur son reçu ; une organisation peut refuser tout transfert sans autorisation en cours de validité.
• Journal d'audit des transferts où toute modification se détecte (chaque entrée scelle la précédente par empreinte) : envois, échecs avec leur raison et téléchargements, avec compte, nom de fichier, taille, sha256 et heure, jamais le contenu. Votre administrateur l'exporte en CSV ou JSON Lines pour votre SIEM, et chaque compte exporte ses propres entrées (pour le client dont les fichiers sont sortis) ; conservation 365 jours.
• Reçu signé pour chaque fichier livré : nom, taille, sha256, compte, heure, version de clé et entrée correspondante du journal d'audit, signés en Ed25519 par l'instance. Un auditeur, un client ou un tribunal le vérifie sans nous, avec la clé publique publiée à /.well-known/bouraq-receipt-key ; un seul octet modifié invalide la signature.
• Vérifiable sans nous : un script autonome (Python, bibliothèque standard seule, sans réseau) contrôle un export du journal d'audit et la signature d'un reçu, et compare un fichier à son reçu.
• Approbation de chaque transfert (option des organisations) : un fichier arrivé attend qu'un administrateur de l'organisation, autre que son expéditeur, l'approuve ou le refuse, avec motif ; un refus supprime le fichier. Chaque décision est signée : l'approbateur ressaisit son mot de passe, et son code s'il a un second facteur ; elle entre au journal d'audit avec la façon dont elle a été signée.
• Liste des types de fichiers autorisés (option des organisations) : seuls les types que vous nommez peuvent sortir ; un dossier envoyé en ZIP est vérifié fichier par fichier, sans extraction. Un fichier refusé n'est jamais écrit et le refus entre au journal d'audit avec sa raison. La vérification porte sur les types déclarés, ce n'est pas un antivirus. Une organisation peut aussi faire refuser les images médicales (DICOM, données de patients), reconnues à leur contenu même renommées ou zippées, et les fichiers texte portant une mention de protection (Diffusion Restreinte, VS-NfD, OFFICIAL-SENSITIVE, CUI…), un filet de sécurité contre l'erreur et non un système de classification.
• Chaque sens s'autorise séparément (option des organisations) : l'aller peut être ouvert seul ; les copies de Prism délivrées n'offrent alors que l'envoi, sans « Pack & send back » ni « Bring back », et le canal de retour du serveur est fermé. Le retour par dépôt ou clé USB ne passe jamais par nos serveurs : votre politique de supports et de dépôts reste le contrôle qui fait foi.
• Appareils nommés et révocables : chaque téléphone ou navigateur connecté apparaît avec un nom (modifiable, par exemple « Téléphone de service ») et sa dernière utilisation ; chaque transfert enregistre l'appareil qui l'a porté, au journal d'audit et sur son reçu ; un appareil perdu se déconnecte en un clic.
• L'administrateur d'une instance crée les comptes, fixe les quotas, renouvelle les clés et déconnecte une session à distance. Sur le service partagé, une organisation a ses propres administrateurs : ils ajoutent et retirent leurs collègues dans la limite de leurs sièges, changent les rôles, voient pour chacun la dernière utilisation, les appareils, le second facteur et l'autorisation au dossier, et fixent leur propre politique de transfert (approbation, types de fichiers, autorisation au dossier, sens autorisés, second facteur), jamais plus permissive que celle du service ; chaque changement entre au journal d'audit, dont l'organisation exporte sa propre partie (CSV, JSON Lines) pour son SIEM. Une revue des accès signale les membres sans second facteur, inactifs depuis 90 jours ou sans autorisation en cours, et la revue faite est consignée au journal.
• Pour une organisation : instance dédiée ou installation sur vos serveurs, sur demande.

Signaler une vulnérabilité

Écrivez à contact@getbouraq.com en décrivant le problème ; nous répondons rapidement et vous tenons informé de la correction. Merci de ne pas accéder aux données d'autres utilisateurs. Coordonnées lisibles par machine : /.well-known/security.txt.