Sécurité & architecture

Truth-Check répond à une question simple : comment prouver qu'une photo ou une vidéo existait bien, sous cette forme, à une date, un lieu et depuis un appareil donnés ? Un fichier seul ne prouve rien — ses métadonnées EXIF sont trivialement modifiables.

Notre approche : au moment de la capture, l'application collecte le média et son contexte (date, coordonnées GPS, modèle d'appareil, résolution), puis crée côté serveur un enregistrement horodaté et figé. Cet enregistrement reçoit un code de vérification unique et devient consultable publiquement. La preuve ne dépend donc pas du fichier que l'on vous présente, mais d'un enregistrement serveur indépendant.

La création suit un chemin déterministe, sans aucune décision algorithmique :

1. L'application transmet le média et ses métadonnées au backend via une connexion chiffrée (HTTPS/TLS).
2. Le serveur attribue un horodatage de confiance (généré côté serveur, pas fourni par le client) et un code de vérification unique de 10 caractères, sans caractères ambigus.
3. Le média est stocké et l'ensemble (contenu + métadonnées) est écrit dans la base au sein d'une transaction atomique.
4. Une fois écrit, l'enregistrement n'est plus modifiable par un client : seules les opérations serveur autorisées peuvent y toucher.

Le résultat est une page publique truth-check.com/<code> affichant la preuve et son contexte.

Soyons précis, car c'est là que beaucoup de services exagèrent. Truth-Check n'applique pas, à ce jour, de signature asymétrique (RSA/ECDSA) propre à chaque certificat. Nous ne parlerons donc pas de « scellement cryptographique » que nous ne réalisons pas.

L'intégrité repose sur un ensemble de garanties bien réelles :

• Enregistrement autoritaire côté serveur : les règles de sécurité de la base interdisent toute écriture ou modification depuis un client. Un certificat ne peut être créé ou altéré que par le backend.
• Horodatage serveur : la date est posée par le serveur, pas par l'appareil, ce qui empêche l'antidatage.
• Empreinte SHA-256 pour les fichiers émis via l'API (voir plus bas), permettant de détecter toute altération ultérieure.
• Chiffrement plateforme au repos et en transit (voir plus bas).
• Vérification publique : n'importe qui peut consulter l'enregistrement d'origine et le comparer au fichier présenté.

Nous appliquons une logique de minimisation. Pour un certificat, sont conservés :

• Le média (photo, ou pour la vidéo un GIF animé reconstitué — la vidéo brute n'est jamais stockée) ;
• Les métadonnées de capture : horodatage, coordonnées GPS, modèle d'appareil, résolution ;
• Les informations que l'utilisateur choisit d'associer (nom, adresse e-mail du titulaire) ;
• Le code de vérification, le statut et la date d'expiration.

Le média doit rester consultable puisque le but même du produit est la vérification publique : il est donc servi via une URL non devinable. Nous ne stockons aucune donnée de carte bancaire (paiements délégués à Stripe et Apple).

Certaines données ne sont jamais conservées en clair, seulement sous forme d'empreinte SHA-256 :

• Mots de passe de certificats protégés : stockés en sel:SHA-256 (salage aléatoire par certificat), jamais en clair.
• Clés d'API des émetteurs vérifiés : seul le préfixe et un hash SHA-256 sont conservés ; la clé complète n'est affichée qu'une seule fois, à la création.
• Fichiers émis via l'API Émetteurs : une empreinte SHA-256 du fichier est calculée côté serveur et stockée, ce qui permet de vérifier ultérieurement qu'un document n'a pas été modifié d'un seul octet.

Par honnêteté : le hachage des mots de passe utilise un SHA-256 salé (à passe unique), et non une fonction de dérivation lente type bcrypt/Argon2. C'est un point que nous documentons ouvertement.

Puisque nous n'apposons pas de signature asymétrique par certificat, il n'existe pas de clé privée de signature de certificats à protéger — ni, par conséquent, à voler.

Les seuls secrets sensibles de la plateforme (identifiants du SDK d'administration Firebase, clés des prestataires de paiement, secrets d'API) sont stockés comme variables d'environnement chiffrées et dans le gestionnaire de secrets de la plateforme, jamais dans le code source ni exposés côté client.

Nous préférons décrire précisément ce qui existe plutôt que d'invoquer un « HSM » ou un « Cloud KMS » que nous n'utilisons pas pour les certificats.

• En transit : toutes les communications entre l'application, l'API et le stockage passent par HTTPS/TLS.
• Au repos : les données sont chiffrées par la plateforme Google Cloud (chiffrement côté serveur AES-256 géré par le fournisseur pour Firestore et Cloud Storage). Ce chiffrement est une garantie de l'infrastructure sous-jacente, pas une couche applicative que nous aurions ajoutée — nous l'indiquons clairement.

Nous concevons pour limiter la casse. En cas de compromission :

• Aucune clé privée de signature ne peut être dérobée — il n'y en a pas.
• Les mots de passe de certificats et les clés d'API ne sont exposés que sous forme de hash, non réversibles en clair.
• Aucune donnée de paiement n'est présente : Stripe et Apple les détiennent, pas nous.

En revanche, restons transparents : les certificats sont conçus pour être publics et les médias sont servis via des URL non devinables — un attaquant lisant la base y verrait des contenus déjà destinés à la vérification publique, ainsi que les métadonnées associées. C'est pourquoi nous invitons à ne certifier que ce qui a vocation à être partagé.

La création d'un certificat est entièrement déterministe : capture → métadonnées → enregistrement horodaté. Aucun modèle de langage, aucune IA générative, ne participe à cette chaîne.

C'est un choix de conception : une preuve doit être reproductible et auditable. Faire dépendre l'intégrité d'un modèle statistique, non déterministe et susceptible d'évoluer, affaiblirait précisément la confiance recherchée.

De l'IA existe ailleurs dans le produit, clairement séparée de la certification : par exemple une transcription optionnelle de l'audio d'une vidéo (service tiers), affichée avec un avertissement et sans effet sur la validité de la preuve.

C'est la distinction la plus importante à comprendre.

• Truth-Check établit une preuve de provenance et d'intégrité : ce média a été capturé à cette date, ce lieu, cet appareil, et n'a pas été modifié depuis. C'est objectif et vérifiable.
• Truth-Check ne produit pas de « score de crédibilité » algorithmique du type « cette image est vraie à 87 % ». Un tel score serait subjectif, opaque et contournable.

Autrement dit, nous prouvons le contexte et l'authenticité technique, pas la vérité du contenu — cette dernière relève du jugement humain, que nous outillons sans le remplacer.