Nous pensons que le portefeuille crypto mobile le plus sécurisé est celui qui surmonte les contraintes inhérentes à son système d’exploitation mobile. Par exemple, sur iOS, le CryptoKit d'Apple ne prend pas en charge le courbe elliptique secp256k1, un standard pour Bitcoin, Ethereum et bien d’autres blockchains.

Cette limitation empêche les développeurs d'utiliser l'élément sécurisé des appareils pour le stockage des clés et la signature des transactions. En conséquence, les portefeuilles cryptographiques mobiles sont classés comme portefeuilles chauds car ils sont tous deux connectés à Internet et signent des transactions en dehors d'un élément sécurisé à l'aide d'une implémentation logicielle des algorithmes cryptographiques.

Cela signifie que les clés privées doivent être exposées – au moins lors de la signature – dans la mémoire de l'environnement d'application en bac à sable. Cela les laisse plus exposés aux menaces potentielles qu’un portefeuille qui utilise un élément sécurisé pour signer des transactions.

Malgré l'impossibilité d'effectuer directement la signature sur les éléments sécurisés, ce qui offrirait une protection accrue, nous nous sommes engagés à fournir un portefeuille crypto mobile open source qui donne la priorité à la sécurité, à la transparence et au contrôle des utilisateurs.

Notre architecture de sécurité est spécialement conçue pour :

• Prend en charge plusieurs blockchains
• Générez des clés privées avec une entropie élevée, une mesure d'imprévisibilité qui renforce la sécurité
• Tirez parti d'une cryptographie éprouvée pour chiffrer en toute sécurité les clés privées des utilisateurs, en capitalisant sur le matériel de sécurité des téléphones mobiles et les fonctionnalités de sécurité du système d'exploitation.
• Offrez une sécurité renforcée avec un mot de passe généré par l'utilisateur pour les utilisateurs avancés qui souhaitent un niveau de cryptage supplémentaire (en plus de la protection du trousseau du système d'exploitation pour la clé de déchiffrement)
• Créer une base solide pour l'intégration future de nouveaux types de gestion de clés, tels que les portefeuilles matériels et les systèmes basés sur quorum MPC.

L'avantage de l'open source

Comme l'un de ses principes fondamentaux de sécurité, Portefeuille Kraken est un logiciel gratuit et open source, distribué sous la licence MIT. En créant un nouveau portefeuille à partir de zéro, il était important pour nous de contribuer à favoriser l'écosystème open source et distribué.

Sans code open source, Kraken Wallet nécessiterait une grande confiance sans transparence. Cela donnerait aux clients moins de protection ; vous ne pouviez pas vérifier, modifier ou exécuter le client vous-même si vous le souhaitiez. "Ne faites pas confiance, vérifiez!" n'est pas seulement une maxime de l'industrie, c'est l'un de nos principes directeurs.

En open source, notre logiciel répond à deux objectifs fondamentaux que nous avions initialement fixés pour ce produit : une minimisation de la confiance vérifiable et auditable :

• Vérifiabilité: La possibilité de vérifier que les hypothèses de sécurité présentées dans ce billet de blog sont vraies. N'importe qui peut regarde le code source pour comprendre spécifiquement ce qui est fait et ce qui ne se fait pas dans ce portefeuille. 

• Auditabilité : La possibilité de vérifier que le résultat de notre implémentation de sécurité est correct et de signaler si ce n'est pas le cas. Nous avons engagé des équipes internes et externes pour effectuer des audits de sécurité à plusieurs reprises avant la sortie. À l’avenir, n’importe qui pourra auditer le code et produire un rapport sur ses conclusions.

Génération de clés et importation de clés

React Native, bien qu'il s'agisse d'un outil puissant, ne dispose pas de module de chiffrement intégré. Pour contourner ce problème, nous avons utilisé une implémentation pure-js (crypto-browserify) du module crypto de NodeJS. La méthode crypto.randomBytes() – qui génère les octets aléatoires réels dont nous avons besoin lors de la génération de clé – est gérée par le réagir-natif-obtenir-des-valeurs-aléatoires polyremplissage.

React-native-get-random-values ​​utilise du code natif pour utiliser le générateur de nombres pseudo-aléatoires cryptographiquement sécurisé (CSPRNG) disponible sur l'appareil pour générer des nombres aléatoires. Sur pratiquement tous les appareils modernes, ce générateur de nombres aléatoires est soutenu par un générateur de nombres aléatoires matériel sécurisé.

Lors de l'initialisation du portefeuille, nous tirons l'entropie du CSPRNG et la convertissons en une graine mnémonique à l'aide de packages npm bien établis (BIP32, BIP39).

Les clés sont converties, stockées et présentées à l'utilisateur selon la norme BIP39, qui offre une méthode mnémonique facile à sauvegarder et interopérable pour la plupart des portefeuilles de l'écosystème. La fonction d'importation prend en charge la récupération des graines compatibles BIP39, qui offrent la meilleure interopérabilité de l'écosystème. 

Gestion des clés 

Kraken Wallet contient deux valeurs secrètes – la graine et le mnémonique – et plusieurs valeurs non secrètes (mais toujours privées) telles que les adresses de portefeuille, les noms de portefeuille et les descriptions des transactions.

Le matériel de clé privée (seed/mnémonique) est stocké dans le trousseau (sur iOS) et le Keystore (sur Android). Le matériel de clé publique et les données non sensibles (clés publiques étendues, adresses et descriptions) sont stockés dans la base de données cryptée de l'application (à l'aide de Domaine).

Il existe plusieurs contrôles de sécurité protégeant les données :

• Verrou d'application: Une chaîne de 64 octets générée aléatoirement et stockée dans le trousseau ou le magasin de clés. L'accès au secret est protégé par des exigences de présence de l'utilisateur – authentification biométrique ou par mot de passe.

• Mot de Passe : Fourni par l'utilisateur et non conservé sur un appareil. Au lieu de cela, l'utilisateur doit fournir le mot de passe manuellement chaque fois que l'application le demande. Le portefeuille détermine si le mot de passe est nécessaire en consultant deux indicateurs (is_storage_encrypted et is_seed_encrypted) stockés dans le trousseau ou le Keystore. L'algorithme Argon2 est utilisé comme fonction de dérivation de clé.

• Cryptage de base de données: La base de données (Realm) est utilisée pour stocker des données non secrètes. Les données sont cryptées avec une clé aléatoire de 64 octets.

• Mécanisme de verrouillage: La saisie d'un mot de passe incorrect déclenche des délais avant que des tentatives ultérieures de mot de passe puissent être effectuées. Ce mécanisme dissuade efficacement les attaques de mots de passe par force brute. Les informations concernant les paramètres de verrouillage, tels que le nombre de tentatives et la durée des délais, sont stockées en toute sécurité dans le trousseau ou le Keystore.

La clé de chiffrement de la graine, du mnémonique et de la base de données est toujours stockée sous forme cryptée

• Lorsqu'aucune protection n'est activée: La clé de chiffrement de départ, mnémonique et de domaine est stockée directement dans le trousseau ou le magasin de clés sans contrôle d'accès par la présence de l'utilisateur.
• Lorsque le verrouillage de l'application est activé: Le mnémonique et la graine sont d'abord cryptés avec le secret de verrouillage de l'application, puis stockés en toute sécurité dans le trousseau ou le magasin de clés. La clé de chiffrement Realm est également directement stockée dans le trousseau ou le keystore.
• Lorsque la protection par mot de passe est activée: Le mnémonique et la graine sont chiffrés avec le mot de passe, tandis que la clé de chiffrement du domaine est chiffrée avec le mot de passe uniquement si is_storage_encrypted était défini sur true.
• Lorsque le verrouillage des applications et la protection par mot de passe sont activés: Le mnémonique et la graine sont cryptés avec à la fois un mot de passe (en premier) et un verrouillage d'application (en second). La clé de chiffrement du domaine est chiffrée uniquement avec le mot de passe et uniquement si is_storage_encrypted a la valeur true.

Utilisation des clés

La graine/mnémonique est stockée dans le trousseau ou le keystore et joue un rôle crucial dans les opérations cryptographiques. Lorsqu'une nouvelle adresse de portefeuille doit être générée ou qu'une transaction doit être signée, nous obtenons les informations nécessaires, telles que la clé privée, de cette graine.

Cependant, il est important de noter que la clé privée doit être chargée en mémoire lors de ces opérations. Cette nécessité découle des contraintes évoquées précédemment concernant les portefeuilles mobiles et du manque d’accès direct à l’élément sécurisé de signature des transactions.

• Signature de transaction (envoi de jetons)
• Signature des données WalletConnect (gestion des demandes de session)
• Ajouter un nouveau portefeuille
• Activation des chaînes testnet (ajout de portefeuilles testnet)
• Afficher le mnémonique
• Vérification du mnémonique
• Activer et désactiver le verrouillage des applications
• Activation et désactivation du mot de passe

Une authentification biométrique supplémentaire est effectuée pour les fonctionnalités suivantes :

• Activation du verrouillage des applications
• Effacer toutes les données
• Supprimer un portefeuille (compte)
• Activer ou désactiver un mot de passe (en plus de la récupération du verrouillage de l'application)
• Ouverture de l'application
• Déplacer l'application au premier plan
• Affichage des clés publiques étendues
• Connexion à une application décentralisée (dApp)

De plus, le mot de passe peut être requis pour ouvrir l'application. Le trousseau et le Keystore sont toujours utilisés via le réagir-natif-porte-clés enveloppe :

• Le wrapper génère une nouvelle clé dans le trousseau ou le magasin de clés pour chaque élément
• Le wrapper est responsable de transmettre les indicateurs de configuration corrects pour le trousseau et le magasin de clés.
• Le portefeuille demande toujours au wrapper de configurer les indicateurs afin que l'appareil doive être déverrouillé pour accéder à la clé
• Un contrôle de présence de l'utilisateur (biométrique) est configuré pour être basé sur le temps et le contrôle est valide pendant 5 secondes ; le contrôle de présence de l'utilisateur n'est pas effectué par accès

L'algorithme de cryptage est le même pour tous les éléments :

• La clé est dérivée avec Argon2id d'un secret normalisé NFC
• Le sel pour Argon2id est l'identifiant unique de l'appareil
• Le mode de cryptage est AES-GCM
• Le vecteur d'initialisation (IV) pour AES est de 16 octets aléatoires
• La balise d'authentification pour AES doit avoir une longueur de 16 octets

Signature des transactions

Outre les mesures mentionnées précédemment concernant le stockage des clés, la biométrie et la protection par mot de passe, la signature des transactions reste un domaine essentiel d'amélioration continue. Dans un premier temps, nous avons mis en œuvre plusieurs mesures notables dans ce domaine, notamment :

Simulateur de transactions

Nous utilisons des services API externes (tels que Blowfish et autres) pour vérifier les niveaux possibles de « gravité » qu’une transaction peut apporter à l’utilisateur (un score de risque). Cela va du blocage complet de l'écran pour d'éventuelles transactions malveillantes (ou signature de messages) aux avertissements sur les différents niveaux de prudence que l'utilisateur doit avoir avant de signer ou de confirmer une transaction. 

D'autres mesures comprennent:

• Validation de l'adresse pour vous assurer de ne pas envoyer à une mauvaise adresse
• Des adresses toujours visibles dans leur intégralité pour garantir que l'utilisateur n'est pas la cible d'attaques spécifiques liées à la composition des adresses
• Validation du réseau et avertissements pour s'assurer que l'utilisateur n'envoie pas vers le mauvais réseau
• Vérifications des frais pour s'assurer que l'utilisateur ne paie pas trop cher pour une transaction

Confidentialité du réseau

Pour protéger la confidentialité et les données personnelles des utilisateurs de manière à ce que ces données ne soient pas divulguées lors des requêtes réseau – en particulier vers des services tiers – nous avons développé une passerelle API vers les requêtes proxy. Ce proxy nous permet de ne pas transmettre les demandes des utilisateurs à des services tiers et ne révèle pas l'adresse IP d'un client à des prestataires externes ou publics. 

Ce service backend est essentiellement une API permettant d’interroger les données publiques de la blockchain. Au sein de l'architecture de sécurité du portefeuille, son objectif est d'encapsuler cette fonctionnalité derrière une API commune à toutes les blockchains afin que Kraken Wallet n'ait pas à implémenter de comportements spécifiques à la blockchain pour l'interrogation de données.

Ce service backend définit cette API commune. Il transmet finalement les requêtes à d'autres parties auprès desquelles il récupère les données réelles. Il n’indexe pas lui-même les blockchains et ne maintient pas l’état.

Hypothèses de sécurité

Notre architecture de sécurité fonctionne sur quelques hypothèses clés pour une protection optimale. Nous présumons :

• L'appareil de l'utilisateur n'est pas rooté, le système d'exploitation n'est pas non plus obsolète et sensible à des vulnérabilités critiques qui pourraient permettre à un attaquant d'accéder à la mémoire de l'appareil.
• Le package Trousseau ou Keystore offre une protection suffisamment solide
• Le système d'exploitation mobile offre un sandboxing solide entre les processus des applications, garantissant que la mémoire contenant des données sensibles telles que les graines est gérée correctement.

Fonctionnalité supplémentaire

• L'application fonctionne sur le principe de stocker uniquement le minimum de données dont elle a besoin pour faire fonctionner le portefeuille.
• Aucun kit de développement logiciel (SDK) d'analyse ou de rapport d'erreur tiers n'est utilisé sur le client.
  • Avec nos efforts pour ne divulguer aucune donnée à des tiers, cela n'aurait aucun sens d'inclure un suivi supplémentaire des données - ce qui signifie que vous ne trouverez aucun logiciel d'analyse ou de rapport d'erreur dans le client.
• Aucune mise à jour en direct (en dehors du flux de mise à jour régulier de l'AppStore/Play Store) n'est autorisée ou implémentée sur la base de code
  • L'utilisateur peut s'attendre à un logiciel compilé qui ne peut pas être mis à jour sans son consentement opt-in
• Liste de jetons et système de réputation
  • Afin d'aider les utilisateurs à gérer leurs jetons, nous avons mis en place un système de liste et de réputation basé sur les actifs fournis par Kraken et d'autres tiers.
• Spam NFT
  • Un premier effort que nous prévoyons de continuer à améliorer est la détection du spam et des attaques liées au spam, où le spam est automatiquement archivé dans le dossier de l'utilisateur.

Audit de sécurité externe

La sécurité de notre portefeuille de garde a été rigoureusement évaluée par un audit mené par Sentier des bits, un cabinet d'audit de sécurité réputé dans le secteur. Cet audit comprenait un examen détaillé de notre base de code et de notre architecture client, visant à identifier et à corriger les vulnérabilités de sécurité potentielles.

Pour garantir la transparence et donner un aperçu de la sécurité de notre plateforme, les résultats de cet audit sont accessibles au public. Cet accès ouvert permet aux utilisateurs et aux parties intéressées de consulter les résultats de l'analyse de sécurité menée par Trail of Bits. Le rapport constitue une ressource importante pour comprendre les mesures de sécurité que nous avons mises en place et notre engagement à maintenir un environnement sécurisé pour nos utilisateurs.

Donner la priorité à la sécurité, à la transparence et au contrôle des utilisateurs

Kraken Wallet établit un équilibre délicat entre commodité et protection robuste face aux contraintes inhérentes à la plate-forme. Notre approche a toujours été de commencer par une structure de portefeuille interopérable et largement reconnue. Cette base solide nous permet d’innover et d’ajouter de nouvelles fonctionnalités, dans le but d’offrir à nos utilisateurs une solution de sécurité de premier plan en constante évolution pour l’auto-garde de leurs actifs cryptographiques.

• Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
• PlatoData.Network Ai générative verticale. Autonomisez-vous. Accéder ici.
• PlatoAiStream. Intelligence Web3. Connaissance Amplifiée. Accéder ici.
• PlatonESG. Carbone, Technologie propre, Énergie, Environnement, Solaire, La gestion des déchets. Accéder ici.
• PlatoHealth. Veille biotechnologique et essais cliniques. Accéder ici.
• La source: https://blog.kraken.com/product/kraken-wallet/kraken-wallet-security