Extrait traduit de l'article de Ledger : https://www.ledger.com/blog/software-wallets (auteurs Charles Guillemet et Jean-Baptiste Bedrune).

Portefeuilles logiciels sur smartphone

Les smartphones Android et iOS offrent par défaut des fonctionnalités de sécurité qui ne sont pas largement utilisées sur les systèmes d’exploitation de bureau.

Les systèmes d'exploitation mobiles offrent une protection des données des applications et des utilisateurs. En particulier, les sandboxes d'applications sont obligatoires pour toutes les applications. Ce n'est pas le cas, par exemple, sous Windows : par défaut, n'importe quelle application peut accéder aux données des utilisateurs.

Par conséquent, une application malveillante ne peut pas lire les données d’une autre application, sauf si :

• Il trouve une vulnérabilité sur cette application.

• Ou bien il parvient à augmenter ses privilèges, par exemple en exploitant une vulnérabilité du noyau lui permettant d'obtenir un accès root au système.

Malheureusement, de telles attaques existent. Elles sont bien plus faciles à utiliser sur les versions obsolètes d'Android et d'iOS, ainsi que sur les appareils anciens ou bon marché où le code tiers est souvent moins sécurisé.

Sur un système d’exploitation à jour, ces attaques sont plus difficiles à mettre en œuvre, mais pas pour autant irréalisables. Par exemple, Ian Beer a montré une attaque zero-click extrêmement impressionnante sur iOS 13.5 en décembre 2020. Guang Gong a présenté une chaîne d’exploitation permettant de rooter à distance une large gamme d’appareils Android basés sur Qualcomm en juin 2020. Et, il y a deux semaines, Forbidden Stories a révélé que NSO Group avait utilisé une chaîne d’exploitation pour cibler des appareils iOS et Android récents en utilisant des vulnérabilités zero-day.

Les attaquants moins sophistiqués peuvent exploiter des vulnérabilités locales leur permettant d'extraire les données du portefeuille d'une application malveillante. Les courtiers en vulnérabilités tels que Zerodium paient jusqu'à 200 000 $  pour une élévation des privilèges vers le root sur Android et iOS, mais jusqu'à 1 500 000 $ pour des attaques à distance.

Nous avons étudié quelques portefeuilles Android/iOS. Leur sécurité dépend de l'application elle-même, mais aussi des fonctionnalités de sécurité du système d'exploitation sous-jacent. Bien entendu, lorsque la sécurité du système d'exploitation est compromise, l'application n'est plus sécurisée

Deux méthodes sont couramment utilisées pour protéger les seed :

• Protection par mot de passe  – les données du portefeuille sont protégées par un mot de passe saisi par l’utilisateur. La conception est la même que pour les portefeuilles de bureau. En pratique, les données sont plus difficiles à extraire que depuis un ordinateur, car récupérer les données d’une application malveillante est techniquement plus difficile, pour les raisons expliquées ci-dessus. Cependant, récupérer le mot de passe une fois les données volées est en pratique plus facile : la saisie de mots de passe complexes sur les téléphones mobiles est fastidieuse, c’est pourquoi les utilisateurs ont tendance à choisir des mots de passe plus simples. De plus, les mécanismes de dérivation de clés (utilisés pour créer une clé à partir d’un mot de passe) sur les appareils mobiles sont généralement plus simples à casser, car ils sont souvent plus légers pour des raisons de performances.

• Coinomi  et Metamask sont des exemples de tels portefeuilles.

Dans la vidéo suivante, nous présentons une autre application jouet développée pour cet article. Il s'agit d'un malware déguisé en un faux widget de ticker Bitcoin. Le malware exploite une vulnérabilité connue sur un appareil non corrigé pour obtenir un accès root sur l'appareil et pour exfiltrer la graine cryptée vers un serveur distant. Le serveur utilise ensuite le mot de passe par force brute pour décrypter la seed.

Cette méthode n'est pas spécifique à un portefeuille. Elle peut être (plus ou moins) facilement adaptée à n'importe quel portefeuille protégé par mot de passe. Voici le même exemple avec Coinbase Wallet :

Sécurité basée sur le Keystore Android (ou le trousseau iOS)  – Dans ce cas, les données du portefeuille sont chiffrées avec une clé de chiffrement stockée dans le Keystore Android (porte-clés iOS). Ces services ont été initialement conçus pour stocker de manière sécurisée les clés de chiffrement, et de nombreuses applications les utilisent pour générer une clé qui chiffrera toutes les données sensibles de l'utilisateur. Les applications utilisant le Keystore implémentent le mécanisme suivant :

• L'application demande au Keystore de générer une clé de chiffrement pour un identifiant donné. Le Keystore génère la clé et la stocke en toute sécurité.

• Lorsque l'application souhaite crypter ou décrypter un blob, elle envoie le blob avec l'identifiant de clé au Keystore.

• Enfin, le keystore vérifie si l'application dispose réellement des droits d'utilisation de cette clé et renvoie ensuite les données de sortie à l'application.

Avec ce modèle, l'application ne peut pas connaître la valeur de la clé mais peut l'utiliser. Il est également possible d'associer des contrôles d'accès supplémentaires à la clé : par exemple, l'accès à la clé peut être conditionné à une authentification de l'utilisateur ( demande d'un code PIN ou d'un schéma de déverrouillage ).

Ce mécanisme peut apporter une sécurité supplémentaire, par rapport à la protection par mot de passe. En effet, sur les téléphones récents, le Keystore est adossé à un Trusted Execution Environment (TEE), ou parfois à un Secure Element.

Cela signifie qu'un attaquant disposant des privilèges root ne pourra pas extraire les clés de chiffrement du keystore. Néanmoins, il pourra utiliser le keystore comme un oracle de déchiffrement et chiffrer ou déchiffrer toutes les données qu'il souhaite.

Keystore propose des services de chiffrement, mais aussi de signature. Alors, un portefeuille pourrait-il protéger ses clés de chiffrement, les rendant difficiles à extraire ? La réponse est malheureusement non : les portefeuilles logiciels n'utilisent pas Keystore pour signer les transactions, et les clés privées sont toujours manipulées en clair par l'application .

La raison est simple : KeyStore et KeyChain proposent des services génériques de signature et de chiffrement, mais ne prennent pas en charge la cryptographie utilisée dans les cryptomonnaies. Par exemple, KeyStore implémente la signature ECDSA mais uniquement sur les courbes NIST définies dans la norme FIPS 186-4 (P-224, P-256, P-384 et P-521). Bitcoin utilise une autre courbe,  secp256k1 , qui n'est pas encore prise en charge.

Pour résumer, Keystore et Keychain sont de bons services pour protéger  les clés secrètes et privées . Ils peuvent offrir une certaine sécurité en chiffrant les données sensibles : certaines classes de vulnérabilités (lecture arbitraire de fichiers, par exemple) seront traitées par le chiffrement Keystore. Cependant, si une escalade des privilèges root ne suffit pas à extraire les valeurs de clés d'un Keystore matériel, elle est suffisante pour déchiffrer les données sensibles.  Un attaquant capable d'instrumenter l'application est en mesure de récupérer ses secrets.

Pour conclure sur les portefeuilles mobiles :

• Le mécanisme d’isolation entre les applications fourni par iOS/Android élève la barre en matière de sécurité par rapport à un portefeuille logiciel exécuté sur un ordinateur. L’attaquant doit d’abord obtenir une élévation de privilèges pour accéder aux données de l’application. Cela est possible sur des appareils obsolètes. Des attaquants qualifiés (Ian Beer l’a fait en 6 mois seulement mais… c’est Ian Beer) peuvent également le faire sur des appareils récents et corrigés.

• Les services de protection de clés (KeyStore, KeyChain) peuvent ajouter une couche de sécurité supplémentaire pour protéger les secrets au repos. Néanmoins, comme ils ne prennent pas en charge les algorithmes cryptographiques pour les applications de cryptomonnaie, la clé peut toujours être extraite.

• Dans tous les cas, un attaquant disposant d'un accès root peut soit récupérer la graine au repos, lorsqu'elle est utilisée, soit exploiter les droits de l'utilisateur pour vider le portefeuille en utilisant le portefeuille logiciel comme oracle.

Voici un dernier exemple d'un logiciel espion ciblant le portefeuille Blockchain.com (bien que cela puisse être fait sur de nombreux autres portefeuilles tout aussi facilement). Il est installé à distance et surveille le portefeuille. Une fois que l'utilisateur s'est authentifié à l'aide de son empreinte digitale, la clé de cryptage est déverrouillée et les données du portefeuille sont décryptées. Le logiciel espion instrumente l'application pour récupérer cette clé de cryptage. Il exfiltre ensuite la clé et les données du portefeuille vers un serveur distant :

Conclusion

En conclusion, les portefeuilles logiciels ont différents niveaux de sécurité. Cependant, leur modèle de menace ne couvre pas le cas d'un malware exécuté sur le système d'exploitation avec une élévation de privilèges. C'est voulu : l'application de portefeuille ne peut pas être plus sécurisée que le système d'exploitation sur lequel elle s'exécute.

• Le mécanisme d'isolation entre les applications fourni par iOS/Android augmente la barre en matière de sécurité par rapport à un portefeuille logiciel exécuté sur un ordinateur. L'attaquant doit d'abord obtenir une élévation de privilèges pour accéder aux données de l'application.

• Les services de protection de clés (KeyStore, KeyChain) pourraient ajouter une couche de sécurité supplémentaire pour protéger les secrets au repos. Néanmoins, comme ils ne prennent pas en charge les algorithmes cryptographiques pour les applications de cryptomonnaie, les clés doivent être manipulées directement depuis l'application, ce qui leur offre une protection limitée.

• Dans tous les cas, un attaquant disposant d'un accès root peut soit récupérer la graine au repos, lorsqu'elle est utilisée, soit exploiter les droits de l'utilisateur pour vider le portefeuille en utilisant le portefeuille logiciel comme oracle.