Modèle de menaces

Cette page recense les menaces qui pèsent sur BlockLucky, classées selon la méthode STRIDE (usurpation, altération, répudiation, divulgation, déni de service, élévation de privilèges). Pour chaque menace, elle indique la protection en place dans le dépôt, le fichier qui la met en œuvre et le risque qui reste. Les pages suivantes de cette partie détaillent chaque protection. Les notes de probabilité et d'impact sont tenues dans le registre des risques.

Le modèle décrit le dépôt tel qu'il est : un pilote sur réseau de test (Hardhat local ou Sepolia), avec des ethers sans valeur. Plusieurs risques acceptés ici deviendraient bloquants avec des fonds réels. La page Crypto-actifs et MiCA en tire les conséquences.

#Périmètre et actifs

#Frontières de confiance

flowchart LR
    C["Navigateur et application mobile"] -->|"HTTPS, jeton Bearer"| API["API Express"]
    API --> PG[("PostgreSQL")]
    API --> RD[("Redis")]
    W["Worker BullMQ"] --> PG
    W --> RD
    API -->|"JSON-RPC signé"| RPC["Nœud RPC Ethereum"]
    W -->|"JSON-RPC signé"| RPC
    RPC --> SC["Contrat BlockLucky"]
    SC -->|"requestRandomWords"| VRF["Coordinateur Chainlink VRF"]
    VRF -->|"fulfillRandomWords"| SC
    EXT["Émetteur de webhook"] -->|"HMAC SHA-256"| API

Quatre frontières concentrent les contrôles :

1. Client vers API. Tout ce qui vient du client est non fiable. Le backend valide chaque corps par Zod, authentifie par JWT et relit le rôle en base.
2. API vers stockage. PostgreSQL et Redis ne sont exposés que sur 127.0.0.1 dans docker-compose.yml. Les secrets sensibles stockés en base sont chiffrés ou hachés.
3. Backend vers chaîne. Le backend signe avec la clé du citoyen ou avec la clé opérateur. La chaîne fait foi : la base n'est qu'une projection reconstruite par l'indexeur.
4. Contrat vers oracle. Seul le coordinateur VRF enregistré peut fournir l'aléa du tirage.

#Menaces sur l'application

#Menaces propres à la blockchain

#Clé opérateur

Le compte opérateur (RELAYER_PRIVATE_KEY) signe la dotation de bienvenue, la pause du contrat, l'annulation d'un tour et le reversement de la commission. Son code est dans backend/src/blockchain/chain.client.ts. Le détail des rôles est sur la page Clés et garde des portefeuilles.

#Garde des clés citoyennes

Le portefeuille est custodial : le backend crée la clé, la chiffre et signe à la place du citoyen. Quiconque obtient à la fois la base et ENCRYPTION_KEY peut signer pour tous les citoyens. Le backend en fonctionnement dispose par construction de ce pouvoir : une compromission du serveur équivaut à la compromission de tous les portefeuilles. Cette concentration est acceptable sur un réseau de test. Elle ne l'est pas avec des fonds réels.

#Oracle Chainlink VRF

Le gagnant est randomWords[0] % ticketCount, calculé dans fulfillRandomWords du contrat smart-contract/contracts/BlockLucky.sol. Le hasard ne passe jamais par le backend. Trois risques demeurent :

#Contrat

Les protections du contrat (garde de réentrance, retraits à l'initiative du bénéficiaire, commission plafonnée à 20 %, disjoncteur) sont décrites sur la page Sécurité du contrat. Le contrat n'est pas modifiable : une faille découverte après déploiement impose une pause puis un redéploiement.

#Front-running et ordre des transactions

#Menaces hors périmètre

• Déni de service volumétrique contre l'hébergement : il relève de l'hébergeur et d'un service de protection en amont, non configuré dans le dépôt.
• Compromission du poste d'un développeur ou d'un administrateur.
• Attaque sur le réseau Ethereum lui-même ou sur l'infrastructure Chainlink.
• Ingénierie sociale des équipes de la Ville, exclue par la politique de signalement.

#Mettre à jour le modèle

Le modèle est à revoir à chaque nouvelle version du contrat, à chaque nouvelle route d'API et après chaque incident traité selon le plan de réponse aux incidents. Toute nouvelle menace notable entre aussi dans le registre des risques.