Introduction
Le secteur de la blockchain s'est donné pour obsession de trouver les failles dans le code des contrats intelligents. Les équipes de développement investissent dans des audits, des concours de chasse aux bugs, des outils de fuzzing et des techniques de vérification formelle, convaincues qu'en trouvant tous ces bugs dans le code final, la sécurité sera assurée.
Cette méthode est importante, mais elle ne tient pas compte d'un des faits les plus effrayants qui a été révélé en 2024. La voie d'attaque la plus catastrophique qui touche actuellement les protocoles de cryptomonnaie n'est pas liée à des chaînes d'exploitation complexes ou à des vulnérabilités cachées dans le code. C'est plutôt une menace bien plus profonde et encore moins discutée qui a dominé le paysage des menaces ces dernières années.
La compromission des clés privées domine le paysage des menaces
Une étude de 2024 montre des chiffres inquiétants qui vont nous obliger à repenser notre approche de la sécurité des blockchains. La part de tous les fonds en cryptomonnaie volés au cours de l'année qui a été compromise via une clé privée est de 43,8 %, ce qui en fait de loin le type d'attaque le plus efficace.
Les faiblesses architecturales en matière de contrôle d'accès ne sont généralement pas signalées comme des conclusions officielles par les cabinets d'audit traditionnels spécialisés dans la blockchain, et les plateformes d'audit concurrentes découragent clairement les soumissions qui se concentrent sur ce genre de problèmes systémiques.
Cette façon de penser est très différente des bonnes pratiques en matière d'audits de sécurité dans d'autres secteurs, où l'escalade des privilèges et la conception du contrôle d'accès sont des questions essentielles qui doivent être prises en compte plus tôt dans le cycle de développement, à un moment où il est souvent trop tard pour changer la nature globale des problèmes de contrôle d'accès du système.
Pour comprendre comment les choix de conception peuvent influencer la vulnérabilité aux attaques contre les clés privées, pensez à ce protocole théorique de prêt surcollatéralisé. Mais, il faut un accès privilégié à ces systèmes pour faire plusieurs opérations importantes :
- Liste et suppression de la liste des actifs pris en charge
- Configurer les paramètres de risque et les taux d'intérêt
- Perception des frais de protocole
- Pauses d'urgence et mises à niveau du développement des contrats intelligents
Ces éléments définissent la résilience globale d'un tel protocole face à la compromission d'une clé privée.
Niveau 1 : exposition totale avec contrôle en un seul point
Le niveau le plus bas, c'est quand le développeur a un seul compte contrôlé de l'extérieur avec tous les droits d'administration sur toutes les fonctions du protocole. Cette architecture est la configuration la plus vulnérable, où le piratage d'une seule clé privée donne aux attaquants un accès instantané et complet au système, qui peut prendre la forme de portefeuilles logiciels connectés à Internet.
La menace de trahison est énorme et ses effets sont dévastateurs et directs.
Niveau 2 : Gestion simple des risques par clés distribuées
La prochaine étape, c'est de transférer les pouvoirs administratifs vers le portefeuille multi-signature, qui aura besoin de la garantie de plusieurs détenteurs de clés pour faire la mise à niveau. Ça ne fera que réduire les risques de compromission sans limiter les dégâts possibles au protocole, mais c'est quand même une amélioration.
C'est bien mieux qu'une clé unique en termes de sécurité, car pour prendre le contrôle du protocole, il ne suffit plus d'avoir accès à une seule clé de signature. Mais même avec cette amélioration, les risques restent élevés :
- La rapidité d'exécution est super importante, car des actions malveillantes peuvent être lancées avant que la sécurité ne réagisse
- Même si les points de défaillance sont répartis entre les clés, la structure de contrôle reste centralisée
- Même les systèmes multi-signatures bien sécurisés peuvent être piratés grâce à des techniques avancées d'ingénierie sociale
Niveau 3 : Protection améliorée grâce à la séparation des temps et des rôles
Pour vraiment améliorer la maturité, il faut mettre en place deux mécanismes de contrôle super importants : les verrous temporels et le principe du moindre privilège.
Les verrous temporels imposent un délai entre l'approbation et l'exécution d'une transaction, ce qui laisse le temps d'examiner la transaction et de réagir aux incidents. Le principe du moindre privilège consiste à séparer les rôles et les responsabilités de manière à ce que chaque rôle ne se voie accorder que le minimum d'autorisations nécessaires à l'accomplissement d'une tâche particulière.
Ce niveau traite des échecs fondamentaux des méthodes plus simples :
- N'autorise pas l'exécution immédiate
- Partage le contrôle entre plusieurs spécialisations
- Donne le temps aux équipes de sécurité de vérifier les transactions inattendues
- Permet une intervention proactive plutôt qu'une gestion réactive des dégâts
Niveau 4 : niveau de sécurité ultime
Le niveau de maturité le plus élevé repose sur la suppression totale des actions administratives, et c'est la forme la plus radicale d'engagement envers l'idée de décentralisation et de minimisation de la confiance. Une telle stratégie exclut catégoriquement le contrôle d'accès dans le cadre du modèle de menace du protocole.
Pour atteindre ce niveau, il faut adopter des approches complètement différentes de celles des autres niveaux :
- La possibilité de mettre à niveau les contrats doit être supprimée - les contrats intelligents deviennent complètement immuables
- La liste des actifs devient libre d'accès - les marchés autonomes se déploient de manière indépendante
- Les paramètres de risque sont gravés dans le marbre - aucune gestion administrative n'est possible
- Intervention d'urgence impossible - les systèmes ne peuvent pas être modifiés après leur mise en place
Dans le cas des systèmes de prêt surcollatéralisés, il faut prendre en compte plusieurs éléments importants :
- Nouvelles fonctionnalités déployées dans des environnements complètement différents avec migration manuelle des utilisateurs
- Marchés formés comme des instances de protocole indépendantes pour des actifs particuliers
- Les paramètres de risque suivent les directives algorithmiques ou les paramètres de déploiement permanents.
Ce chiffre est cinq fois plus élevé que tous les autres types d'attaques confirmés, mais l'écosystème de sécurité de la blockchain n'est pour l'essentiel pas prêt à faire face à une telle menace.
Sécurisez votre protocole dès aujourd'hui
N'attendez pas qu'il y ait un compromis. Mettez en place dès maintenant des contrôles d'accès appropriés.
Cadre de séparation des rôles
| Type de rôle | Responsabilités | Exigences en matière de sécurité | Durée du verrouillage temporel |
|---|---|---|---|
| Système central | Mises à niveau des contrats | Seuils multisignatures élevés | Longs délais |
| Opérations | Configuration du protocole au quotidien | Besoins de sécurité modérés | Retards moyens |
| Pause Guardian | Suspension du protocole d'urgence | Capacité d'action immédiate | Pas de retard |
| Annuler Guardian | Annule les approbations malveillantes. | Autorité de réponse rapide | Pas de retard |
Les équipes de sécurité peuvent maintenant intervenir de manière positive dans les cas, au lieu de juste réagir aux dégâts une fois qu'ils sont faits, mais ça amène de nouveaux risques, comme des bugs possibles dans les systèmes de gestion des rôles.
Même si ce modèle de conception ne présente aucun risque en matière de contrôle d'accès, il comporte des inconvénients importants, notamment l'impossibilité d'intervenir en cas d'urgence et des coûts de vérification initiaux élevés.
Construire des systèmes résilients dès le premier jour
La vulnérabilité des clés privées, à l'origine de près de la moitié des vols de cryptomonnaies en 2024, est un problème qu'on ne peut pas ignorer à cause des choix architecturaux faits au début du processus de conception en matière de contrôle d'accès. Même si l'identification classique des vulnérabilités reste nécessaire, les décisions fondamentales en matière de conception devront être prises beaucoup plus tôt dans le cycle de développement.
Voici quelques mesures concrètes qui peuvent être prises pour améliorer la sécurité :
- Analyse honnête de l'état actuel de maturité du protocole
- Mise en place de contrats à durée déterminée pour les fonctions administratives
- Mettre en place des systèmes de surveillance adéquats pour les modes administratifs à haut risque.
- Mappage des fonctions privilégiées et séparation en rôles logiques
- Utilise le principe du moindre privilège.
- Identification des éléments de conception adaptés aux modèles immuables
Pour créer des protocoles à la fois innovants et solides, les développeurs doivent comprendre les cadres de maturité et choisir consciemment des modèles de conception qui évitent de dépendre de la confiance ou qui permettent la propagation des compromis.
Ça demande d'investir dans la résilience opérationnelle dès les premières phases de développement, en s'assurant que les protocoles résistent pas seulement aux intrusions techniques, mais aussi aux facteurs humains qui font que la compromission des clés privées est une menace si efficace.
