
BlockChain Security Construction
Dans cet article, nous présentons principalement plusieurs aspects de l'audit de chaîne publique qui méritent l'attention. Pour les auditeurs de sécurité et les développeurs de chaînes publiques, il s'agit d'un projet digne de référence et de réflexion.
Avant de présenter la construction du système de chaîne publique, examinons l'architecture de la blockchain :
Ère de la blockchain 1.0 :
Architecture : comme le montre la figure ci-dessous
Produits représentatifs : bitcoin, reborn coin, dogcoin, Leyte coin, MasterCard coin, etc

Ère de la blockchain 2.0 :
Architecture : comme le montre la figure ci-dessous
Produits représentatifs : Ethereum, lisk, hyperledger, etc
Principaux changements :

Ère de la blockchain 2.0
Architecture : comme le montre la figure ci-dessous
Produits représentatifs : EOS, VaR, AE, ash, ELA, dfinity
Principaux changements : les scénarios d'application de la blockchain dans tous les secteurs d'activité hors industrie financière peuvent répondre à des logiques métier plus complexes

Ensuite, nous donnons une brève introduction aux problèmes méritant réflexion dans la construction de la sécurité de la chaîne publique de la blockchain, selon l'architecture de la blockchain. Environ 75 % de ces problèmes ont provoqué des problèmes de sécurité de chaîne publique, et constituent également des points dignes d'attention dans l'audit de sécurité de la chaîne publique. Ici, nous les présentons sous forme de questions pour éveiller notre réflexion. Si vous souhaitez poursuivre la discussion, vous pouvez le faire directement dans une issue :
La couche de données est la technologie de couche de base ; ses principales fonctions sont le stockage des données, la mise en œuvre des comptes et des transactions, et la sécurité. Le stockage des données repose principalement sur l'arbre de Merkle, réalisé par une structure de blocs et de chaîne. La plupart sont persistés via une base de données kV, comme bitcoin et leveldb adoptés par Ethereum.
La couche de données mérite d'être examinée comme suit :
Le principal objectif de la couche réseau est de réaliser l'interaction d'informations entre les nœuds du réseau blockchain. L'essence de la blockchain est un réseau pair-à-pair (P2P). Chaque nœud peut recevoir des informations et également en produire. Les nœuds maintiennent la communication en conservant une blockchain commune. Dans le réseau blockchain, chaque nœud peut créer un nouveau bloc. Une fois le nouveau bloc créé, les autres nœuds en sont informés par diffusion. En retour, les autres nœuds vérifient le nœud. Lorsque plus de 51 % des utilisateurs du réseau blockchain valident la vérification, le nouveau bloc est ajouté à la chaîne principale.
Plusieurs points de la couche réseau méritent d'être examinés
La conception de l'algorithme de découverte de nœuds de la chaîne publique est-elle raisonnable ?
La conception des nœuds de la chaîne publique est-elle raisonnable ?
La conception du mécanisme de punition est-elle raisonnable ?
La conception du protocole de communication est-elle raisonnable ?
La conception du traitement des requêtes du nœud de chaîne publique est-elle raisonnable ?
Existe-t-il une limite sur la taille du paquet de traitement des requêtes ?
La conception du mécanisme de communication des transactions de la chaîne publique est-elle raisonnable ?
Le mécanisme de synchronisation des données de blocs est-il raisonnable ?
La conception logique du traitement des transactions est-elle raisonnable ?
La couche de consensus permet à des nœuds fortement dispersés d'atteindre un consensus sur la validité des données de bloc dans un système décentralisé. Chaque blockchain en fonctionnement a besoin d'un algorithme de consensus pour garantir la validité et l'ordre de sortie des blocs. Les algorithmes de consensus courants incluent pow, POS, dpos, Poa, POC, etc.
Au niveau du consensus, nous devons considérer les points suivants :
La conception de l'algorithme de consensus de la chaîne publique est-elle sûre ?
La conception de la vérification du consensus de la chaîne publique est-elle raisonnable ?
La conception de la confiscation du consensus de la chaîne publique est-elle raisonnable ?
La conception des frais de service de la chaîne publique est-elle raisonnable ?
La conception du minage de la chaîne publique est-elle raisonnable ?
La conception de l'ajustement dynamique de la difficulté du bloc est-elle raisonnable ?
La conception logique de la vérification de la difficulté du bloc est-elle raisonnable ?
Conception de la réorganisation de la chaîne, de la réinitialisation de la chaîne, de la bifurcation de la chaîne, etc. ?
Le but de la couche d'incitation de la chaîne publique est de fournir certaines mesures incitatives pour encourager les nœuds à participer à la vérification de sécurité de la blockchain, et d'assurer l'équilibre et le développement sain de l'écosystème de la blockchain. Dans la chaîne commune décentralisée, il est nécessaire de mettre en place le mécanisme d'incitation correspondant pour encourager les nœuds comptables participants qui respectent les règles, et d'établir le mécanisme de punition pour sanctionner les nœuds comptables participants qui ne respectent pas les règles. La couche d'incitation de la blockchain introduit des facteurs économiques dans le système technologique de la blockchain, ce qui améliore l'efficacité de la coopération organisationnelle et des échanges de valeur au sein de l'écosystème. Le mécanisme d'incitation de la chaîne publique est un mécanisme important pour garantir le développement vertueux de la blockchain.
Plusieurs points concernant la couche d'incitation méritent notre attention
La conception du mécanisme d'émission de la chaîne publique est-elle raisonnable ?
La conception du mécanisme de punition de la chaîne publique est-elle raisonnable ?
La couche de contrat encapsule toutes sortes de codes de script et d'algorithmes du système blockchain, ainsi que les contrats intelligents plus complexes qui en sont générés. Si les trois niveaux que sont les données, le réseau et le consensus, en tant que « machine virtuelle » sous-jacente de la blockchain, assurent respectivement les fonctions de représentation des données, de diffusion des données et de vérification des données, la couche de contrat est la logique métier et l'algorithme basés sur la machine virtuelle de la blockchain, qui constituent la base de la programmation flexible et de l'exploitation des données du système blockchain. La plupart des cryptomonnaies numériques, y compris bitcoin, utilisent un simple code de script non Turing-complet pour programmer et contrôler le processus de transaction, ce qui constitue également l'ébauche du contrat intelligent. Avec le développement de la technologie, il existe des langages de script Turing-complets comme Ethereum qui peuvent réaliser des contrats intelligents plus complexes et plus flexibles ; la blockchain peut prendre en charge de nombreuses applications des systèmes financiers et sociaux macroéconomiques.
Nous devons considérer les points suivants concernant la couche de contrat :
Conception de la sécurité de la machine virtuelle du contrat ?
Déploiement / exécution / interface du contrat ?
Sécurité liée au contrat intelligent ?
La couche d'application encapsule divers scénarios et cas d'usage de la blockchain, à l'instar des divers programmes logiciels d'un ordinateur. C'est un produit que les utilisateurs ordinaires peuvent réellement utiliser directement, et on peut également le comprendre comme le navigateur des produits à architecture B/S.
Nous devons considérer les points suivants concernant la couche d'application (uniquement la chaîne publique, pas les applications de portefeuille / échanges / DEFI, etc.) :
Conception de la logique CRUD du compte de portefeuille ?
Vérification des permissions d'importation et d'exportation du portefeuille ?
Conception de la complexité du mot de passe du portefeuille ?
Vérification de la validité de l'adresse du compte de portefeuille ?
L'interface RPC publique a-t-elle besoin d'un réseau public externe ?
Les autorités de l'interface RPC de la chaîne publique sont-elles clairement réparties ?
L'interface RPC publique comporte-t-elle des opérations de type sensible ?
L'interface RPC publique gère-t-elle les exceptions ?
Limite maximale de traitement des données de l'interface RPC de la chaîne publique ?
Encodage et décodage des données des requêtes de l'interface RPC de la chaîne publique ?
SSL est-il activé pour le traitement des requêtes RPC de la chaîne publique ?
Conception du traitement des requêtes à forte concurrence dans la chaîne publique ?
Définition du nombre maximal de connexions ?
L'interface Web UI de la chaîne publique autorise-t-elle l'accès distant ?
Existe-t-il une vulnérabilité de type web dans l'interface webui de la chaîne publique ?
L'interface webui de la chaîne publique est-elle autorisée à stocker localement des informations de mot de passe ?
Il est vrai qu'il n'existe pas de « couche de code » dans la chaîne publique. Ici, l'auteur la propose principalement pour classer les problèmes qui peuvent devoir être pris en compte au cours du développement de la chaîne publique :
Caractéristiques du langage de développement de la chaîne commune, telles que readall (), fonctionnalités d'append dans la lecture de données du langage go
Version du langage de développement de la chaîne publique, par exemple, certaines versions du langage go présentent une exécution de commandes à distance
Codage selon les spécifications de développement de la chaîne publique, comme les opérations de pointeur nul, de découpage (slicing), de gestion des exceptions, etc.
Traitement du chiffrement et du déchiffrement de la chaîne publique, comme l'encodage et le décodage de haute complexité sans vérification de longueur
Traitement de la conversion de types de données, comme hextobyte, integer. Parseint(), etc.
Conception de la logique métier de base, par exem
En plus des problèmes ci-dessus dignes de considération au niveau de l'architecture de la blockchain, nous devons également considérer les problèmes de sécurité suivants :
Le stockage des données est-il chiffré ?
Les permissions des fichiers sont-elles raisonnables ?
L'environnement d'exécution est-il sûr ?
Le nœud n'est-il pas démarré en root ?
Existe-t-il un service web vulnérable côté nœud ?
Y a-t-il une configuration non sécurisée côté serveur du nœud ?
Existe-t-il une vulnérabilité d'accès non autorisé côté serveur du nœud ?
Le mot de passe du compte SSH est-il divulgué côté serveur du nœud ?
Attaque des 51 %
Bifurcation dure de la chaîne commune
Détournement de puissance de calcul (vers infectant les machines de minage)
Savoir si l'on utilise les bibliothèques tierces présentant des vulnérabilités, telles que Jackson databind, fastjson, etc.
Utilisation d'un middleware vulnérable, comme la version inférieure de tendermint
Le mode de chaîne croisée est-il fiable et approprié ?
Schéma d'implémentation de chaîne croisée isomorphe et hétérogène ?
Reprendre les problèmes de sécurité de la section précédente
Participez directement à la discussion des problèmes associés dans l'issue