Sécurité & confiance
Notre modèle de sécurité suit une règle simple : chaque fois que c'est possible, chaque affirmation doit être vérifiable à la source, par n'importe qui, à tout moment. Voici comment la plateforme est réellement construite.
Les lots de produits sont ancrés sous forme de racines de Merkle sur Base L2 (un layer-2 public d'Ethereum). L'endpoint de preuve ci-dessous est public et sans authentification : n'importe qui peut récupérer la preuve Merkle d'un produit, recalculer les hachages et comparer la racine à la transaction on-chain sur basescan.org. Sans compte, sans permission, sans intervention de SealTrust.
GET https://api.sealtrust.io/verify/merkle/{identifier}
Tableau de bord marque
Chaque vérification NFC remonte en direct, et une URL rejouée est refusée sur-le-champ. L'analyse d'anomalies, elle, se consulte dans le tableau de bord, conçue pour des centaines de milliers de produits.
À l'échelle, votre équipe ne voit pas le flux brut : des dashboards agrégés et des alertes triées, uniquement sur les anomalies.
Valeurs d'illustration
Chaque article protégé porte une puce NXP NTAG 424 DNA. Elle sort d'usine avec ses clés AES par défaut ; nous y écrivons au moment de l'encodage des clés dérivées d'une clé maîtresse protégée par un KMS cloud managé, et une fois écrites elles ne sont jamais exposées ni relisibles depuis le tag. À chaque lecture, la puce génère un code à usage unique (SDM) que notre API déchiffre et valide côté serveur. Un code capturé ne peut pas être rejoué, et sans les clés, un attaquant ne peut pas en produire un valide. L'authentification est cryptographique, pas déclarative.
Les transactions on-chain signées par la clé de plateforme le sont à l'intérieur d'un KMS cloud managé, qui détient cette clé privée et ne la restitue jamais. Les clés maîtresses qui protègent les secrets des puces NFC sont conservées chiffrées sous une clé gérée par le KMS et ne sont déchiffrées qu'en mémoire. Les clés des portefeuilles de marque et des utilisateurs sont conservées chiffrées au repos, et aucun matériau de clé n'est versionné dans un dépôt.
Les produits sont regroupés en lots dont la racine de Merkle est ancrée sur Base L2 (chain id 8453) ; les versions publiées de passeport sont ancrées de la même façon, dans des lots qui leur sont réservés. Ce qui entre dans l'arbre n'est jamais le contenu lui-même, seulement son empreinte. L'ancre étant publique, l'intégrité est vérifiable par n'importe quel tiers (un client, un auditeur, une place de marché) sans nous solliciter et sans faire confiance à notre base de données.
Changer le propriétaire d'un produit est une opération sensible : elle exige une confirmation explicite par code à usage unique (OTP ou TOTP d'application d'authentification). Un mot de passe volé ou une session détournée ne suffisent pas à déplacer un produit, et chaque transfert s'inscrit dans l'historique vérifiable de l'article.
Une URL rejouée est refusée en ligne, sur le scan lui-même : le serveur rejette un compteur déjà vu, et reconstruit le plancher depuis l'historique durable plutôt que d'en laisser passer un quand le cache l'a perdu. Chaque scan NFC alimente ensuite un moteur de confiance à base de règles, dont le score par produit est suivi par les marques depuis leur tableau de bord. Par-dessus, une analyse d'anomalies sur l'historique de scans d'une marque fait ressortir l'impossibilité géographique (la même identité en deux lieux éloignés au même moment), les compteurs qui reculent, les codes rejoués et les schémas multi-wallets ; elle se lance depuis la page sécurité du tableau de bord, pas sur une planification.
Une marque peut placer ses opérations on-chain les plus critiques derrière un portefeuille multi-signatures Gnosis Safe. Les marques qui fixent un seuil d'au moins deux signataires appliquent une politique M-sur-N : un quorum de signataires autorisés doit alors approuver avant toute exécution, et chaque approbation est enregistrée on-chain ; aucune clé isolée ne peut alors émettre ni détruire seule. Par défaut, la frappe et la destruction s'exécutent directement, sans quorum Safe, et la destruction exige en plus un code à usage unique frais (TOTP ou code de secours) de l'opérateur.
Les droits des personnes sont du logiciel qui fonctionne, pas un paragraphe de politique : l'export des données (article 15) et l'effacement (article 17) sont implémentés comme des routes API dédiées. Les adresses IP des journaux de scan sont anonymisées après 30 jours, et la conservation est bornée par catégorie de données.
La production tourne sur une infrastructure européenne : l'application, la base de données et le stockage des médias sont hébergés dans l'UE, et la clé de signature de la plateforme, les clés de signature des marques et les clés maîtresses qui protègent les secrets des puces NFC résident dans un KMS managé en région UE, ou sont chiffrées par lui. Un nombre limité de sous-traitants situés hors UE est listé dans notre politique de confidentialité et encadré par les clauses contractuelles types de la Commission européenne.
Vous avez trouvé une faille de sécurité dans SealTrust ? Écrivez à contact@sealtrust.io avec « Sécurité » dans l'objet. Nous répondons sous cinq jours ouvrés.
Périmètre : sealtrust.io, api.sealtrust.io, admin.sealtrust.io et docs.sealtrust.io.
Dites-nous ce que vous avez trouvé, où, et les étapes pour le reproduire. Testez uniquement avec votre propre compte et vos propres données, ne dégradez pas le service, et laissez-nous un délai raisonnable pour corriger avant de rendre le problème public.
Les mêmes informations, lisibles par une machine (RFC 9116) : /.well-known/security.txt
Des questions de sécurité propres à votre déploiement ? Parlez directement à l'équipe qui a construit tout ça.
Nous contacter