Les portefeuilles Bitcoin recommandés pour Android sont-ils ...

Les portefeuilles Bitcoinrecommandes pour Android

sont-ils vraiment recommandables ?

Emmanuel Schmid

Departement TIC - orientation TS

Professeur : Sylvain Pasini

Entreprise partenaire : Securing Apps (Jeremy Matos)

Responsable de la filiere : Juergen Ehrensberger

27 juillet 2018

Table des figures

2.1 Principe chiffrement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2 Niveau de protection OWASP-MASVS . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.1 Reseau decentralise BC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2 Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.3 Blockchain : chaıne la plus longue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.4 Transaction, cle privee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1 Protcole SPV, source - https ://eprint.iacr.org/2014/763.pdf . . . . . . . . . . . . . . . 354.2 Multisignatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.1 Methodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.1 Cas d’utilisation d’un wallet generique . . . . . . . . . . . . . . . . . . . . . . . . . . . 486.2 Source de menaces, motivation et cibles . . . . . . . . . . . . . . . . . . . . . . . . . . 546.3 DFD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556.4 Matrice de criticite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

3

4 TABLE DES FIGURES

Liste des tableaux

4.1 Resultat du processus de recommandation . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.1 Selection des wallets a analyser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5

6 LISTE DES TABLEAUX

Cahier des charges

SommaireCadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Problematique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Objectifs pedagogiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Objectifs techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Taches a realiser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Livrables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

7


Cadre du projet

Ce projet est realise dans le cadre d’un travail de fin d’etudes au sein de la HEIG-VD.

Annee academique 2017-2018

Responsable Prof. Pasini Sylvain

Etudiant Schmid Emmanuel

Departement Technologies de l’information et de la communication (TIC)

Filiere Telecommunications (TELE)

Orientation Securite de l’information (TS)

Institut IICT

Entreprise partenaire Matos Jeremy (Securing Apps)

Confidentiel Non

Domaine de recherche Securite, Android, Bitcoin, blockchain

Langue Francais

Duree 62 jours

Problematique

Depuis la nuit des temps, les moyens d’echange n’ont pas cesse d’evoluer et ont pris differentesformes. Aujourd’hui, les avancees informatiques et cryptographiques ont permis d’elaborer une mon-naie sans support physique s’affranchissant des institutions bancaires. Les cryptomonnaies permettentdes transactions sans l’intervention de tiers de confiance. L’utilisateur endosse par consequent cer-taines responsabilites de la banque, notamment celle de securiser son compte. En realite, les por-tefeuilles virtuels ne stockent pas de cryptomonnaies en soit, mais une paire de cles permettant designer les transactions. L’embleme des cryptomonnaies, le Bitcoin, est accepte par une grande partiedu e-commerce. Certains commercants l’utilisent aux quatre coins du globe.

Cette revolution economique et informatique a debute en 2009 par la publication de sa premierespecification et preuve du concept, sous le mysterieux pseudonyme de ”Satoshi Nakamoto”. Le Bit-coin est un systeme de paiement electronique qui permet d’effectuer des transactions pair a pair. Ils’appuie sur son reseau decentralise et sa blockchain pour fonctionner. Le wallet Bitcoin representeune interface permettant d’interagir avec son reseau et offrant la possibilite de creer des comptes, deles consulter et de generer des transactions. Il est loin d’etre evident pour un utilisateur de choisirun wallet adapte a ses besoins et garantissant un bon niveau de securite. C’est la responsabilitede l’utilisateur de securiser ses Bitcoins et cela commence par le bon choix du wallet. L’associa-tion Bitcoin recommande un certain nombre de portefeuilles Bitcoin (wallet) pour smartphones :(https://bitcoin.org/fr/choisir-votre-porte-monnaie).

L’avantage de controler son argent implique des risques securitaires non negligeables. A l’imaged’un mot de passe qui securise l’acces a un compte, la paire de cles est l’unique element necessairepour effectuer des transactions valides. Comme il s’agit d’applications permettant des transactionsfinancieres, le choix du bon modele de menaces est primordial. L’elaboration d’un modele de menaces,sur la base d’un wallet generique, permet de cibler les biens a proteger, les menaces possibles et lescontre-mesures a mettre en place.

L’objectif de ce travail est de verifier que ces 11 applications sensibles pour Android ont adressecorrectement la problematique de la securite. Et en particulier la gestion de la cle privee effectuant la

<https://bitcoin.org/bitcoin.pdf>


https://bitcoin.org/fr/choisir-votre-porte-monnaie

LISTE DES TABLEAUX 9

signature des transactions. Mais aussi de maniere plus generale de valider que les recommandations del’OWASP MASVS ont ete suivies (https ://github.com/OWASP/owasp-masvs). Les contre-mesuresetablies enrichissent la checklist de l’OWASP. Pour cela, il faudra proceder a une revue du code Java(analyse statique), puis de confirmer la criticite de certaines failles via hooking (analyse dynamique).

Dans le cas ou des vulnerabilites seraient identifiees, une demonstration de l’exploit sera docu-mentee, la publication d’un papier et la participation a une conference securite (via un CFP) serontau programme.

Objectifs pedagogiques

La realisation de ce travail permettra a l’etudiant de :

— planifier un projet

— se montrer autodidacte

— travailler de maniere autonome

— utiliser et de mettre en avant les notions acquises lors de la formation, majoritairement lasecurite de l’information et le developpement logiciel

— presenter et valoriser son travail

Objectifs techniques

L’etudiant devra :

— Se familiariser et synthetiser le fonctionnement du Bitcoin, de la blockchain et des wallets

— Etablir un modele de menaces d’un wallet Bitcoin generique

— Lister les criteres et les exigences securitaires attendues

— Mettre en place une methodologie d’audit

— Analyser la securite des portefeuilles Bitcoin sous Android recommandes par la fondation Bit-coin.

— Verifier que la problematique de la securite a correctement ete adressee

— Valider que les recommandations de l’OWASP MASVS ont ete suivies

— Effectuer une bilan comparatif des divers applications auditees

— Preparer une presentation des resultats destinee a une audience grand-public

https://github.com/OWASP/owasp-masvs


Taches a realiser

— Documenter le contexte

— Concept de la cryptomonnaie

— Resume du fonctionnement bitcoin/blockchain

— Documenter, trier et selectionner les wallets recommandes a analyser

— Documenter le fonctionnement d’un wallet Bitcoin

— Analyse de risques d’un wallet generique

— Etablir la liste des criteres et des exigences securitaires attendues

— Proposer un modele de menaces

— Analyser les applications Bitcoin Android recommandees par bitcoin.org

— Proposer une selection des applications

— Realiser un rapport securitaire technique pour les applications analysees

— Adopter une politique de Responsible disclosure en cas de decouverte de vulnerabilite

— Elaborer un rapport et presentation des decouvertes pour un public moins technique

— Optionnel : Fabriquer des clones demonstratifs (inoffensifs)

Livrables

Rendu intermediaire

— Journal de travail

— Rapport intermediaire

— Contexte (Crypto-monnaies, etc)

— Modele de menaces et exigences

— Analyse detaillee de 1 portefeuille (au minimum)

— Liste des resultats

— (Optionnel) Bilan intermediaire.

Rendu Final

— Journal de travail

— Rapport final

— Analyse detaillee des 6 applications selectionnees

— Bilan comparatif

— Presentation des resultats pour le public moins initie

— Document de presentation/defense du projet

LISTE DES TABLEAUX 11

Resume

Depuis la nuit des temps, les echanges de marchandises, de produits, de services et de valeursn’ont cesses d’evoluer. Le troc, meme si toujours existant de facon marginale, a laisse la place al’utilisation de la monnaie. Cette derniere a fini par se dematerialiser, coexistant ainsi avec les versionspieces et billets, toujours beaucoup utilisees, de facon plus ou moins prononcee selon les pays ou lescultures. La monnaie dematerialisee s’est elle-meme diversifiee trouvant ses bases soit au sein d’uninstitut bancaire prive ou etatique soit de maniere completement autonome. Le Bitcoin fait partiede ces cryptomonnaies, nees hors de tout systeme etablis, dont la securite n’est plus dependanted’une autorite reconnues mais d’un systeme autonome et complexe de transactions, toutes liees etindissociables, securisees par cryptographie. Ce travail decrit cette evolution mais en focalisant sur lecas specifique du Bitcoin en y exposant et decrivant les differentes specificites de cette cryptomonnaie.L’accent sera mis notamment sur l’aspect securite trouvant ses bases dans la cryptographie et lastructure meme du blockchain. Comme toutes les monnaies, les Bitcoins sont geres par les detenteursa l’aide de portefeuilles (wallets) mais qui n’offrent pas tous le meme niveau de robustesse auniveau securitaire. Un certain nombre de ces Wallets sont passes en revue et critiques/commentes en fonction de leurs caracteristiques. Comme tout systeme renfermant des valeurs, les wallets sontsoumis aux risques inherents a ce type de probleme (vol, perte, etc.). Ces menaces et attaquespotentielles, relativement nombreuses, seront decrites ainsi que seront listees les mesures securitairesexistantes visant a prevenir les consequences negatives qui en decouleraient.Avant de se lancer dans une analyse approfondie, il a fallu selectionner les applications a examinerparmi les onze que l’organisation Bitcoin.org recommande. Ce cadre pose par Bitcoin – en raison dumanque de temps lors de ce travail – a du etre restreint davantage. Le critere supplementaire a ete lafrequence d’utilisation des onze applications conseillees. Ainsi, les 6 favorites des consommateurs fontl’objet de l’analyse. L’etape suivante est le choix de la methodologie. L’examen repose sur un modelede menaces, lui-meme developpe a partir des methodologies existantes : le modele de classificationdes menaces STRIDE et celui d’evaluation globale des risques OCTAV. Pour finir, les contre-mesures preventives a mettre en place pour eviter des attaques en tous genres, decoulent du modelede menaces applique a un wallet generique.

Table des matieres

Cahier des charges 7

Cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Problematique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Objectifs pedagogiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Objectifs techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Taches a realiser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Livrables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1 Introduction 15

1.1 L’evolution de la monnaie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.2 La revolution Bitcoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.3 Importance d’un portefeuille vis-a-vis de la securite . . . . . . . . . . . . . . . . . . . . 17

1.4 Organisation du document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2 Etudes preliminaires 19

2.1 Concepts cryptographiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2 OWASP MASVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 Bitcoin 25

3.1 Bitcoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2 Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.3 Les transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.4 Miner du Bitcoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4 Wallets Bitcoin 31

4.1 Les wallets Bitcoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2 Deterministic wallet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.3 Simplified Payment Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.4 Multi-signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.5 Processus de recommandation Bitcoin.org . . . . . . . . . . . . . . . . . . . . . . . . . 37

5 Methodologie 41

5.1 Selection des wallets a analyser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.2 Methodologies existantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.3 Modele de menaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

13

14 TABLE DES MATIERES

6 Modele de menaces 456.1 Description d’un wallet mobile generique . . . . . . . . . . . . . . . . . . . . . . . . . . 476.2 Scenarios d’attaques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566.3 Mesures securitaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656.4 Criteres d’evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

7 Analyse detaillee 737.1 Resultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747.2 Observations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

8 Bilan 1078.1 Bilans securitaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1088.2 Bilan intermediaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1098.3 Bilan Final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1118.4 Bilan personnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1118.5 Authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

9 Bibliographie 113

10 Annexes 11510.1 Journal de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Chapitre 1

Introduction

Sommaire1.1 L’evolution de la monnaie . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.1.1 Centraliser pour controler . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.1.1.1 Digitalisation de la monnaie . . . . . . . . . . . . . . . . . . . . 16

1.1.2 Changement de cap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.2 La revolution Bitcoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.3 Importance d’un portefeuille vis-a-vis de la securite . . . . . . . . . . 17

1.4 Organisation du document . . . . . . . . . . . . . . . . . . . . . . . . . . 17

15

16 CHAPITRE 1. INTRODUCTION

1.1 L’evolution de la monnaie

Sel, pierre, or, argent ou simplement dematerialises, les moyens d’echanges n’ont jamais cessed’evoluer a travers l’histoire. Le troc, premiere operation economique, introduit les premieres problem-atiques : la rarete et la valeur d’un bien. Il a fallu trouver un moyen d’echange que tout le monde vou-lait ou necessitait et en lequel on avait confiance. Les diverses civilisations se sont rapidement tourneesvers un systeme monetaire. Comme les premieres monnaies etaient frappees dans des materiauxprecieux, elles etaient entreposees chez un tiers de confiance qui retournait une attestation. Cettepremiere generation de banquiers s’est tres vite rendue compte, qu’ils pouvaient preter l’or qu’ilsentreposaient et degager des benefices. Les supports physiques n’ont depuis plus aucune valeur mar-chande. Il y a encore 60 ans, toutes les monnaies avaient une equivalence en or. Aujourd’hui, lavaleur d’une monnaie depend entierement du prix du marche, soit les cours de change d’une devisecomme le franc suisse en une autre. La confiance qu’a la societe en sa monnaie est primordiale poursa valorisation ; la monnaie est devenue une convention sociale.

1.1.1 Centraliser pour controler

L’importance indiscutable de la monnaie dans notre societe a tres vite pris une dimension poli-tique. La majorite des Etats du monde a cree et utilise leur propre monnaie. La regulation s’effectuepar l’intermediaire d’un tiers de confiance, a savoir une banque centrale. Cet organisme charge dela politique monetaire de l’Etat a la responsabilite de gerer la masse monetaire par le biais de soninfluence sur les taux d’interets et les accords de pret.

1.1.1.1 Digitalisation de la monnaie

Avec l’avenement des technologies de l’information et d’Internet, la gestion des monnaies s’estlargement informatisee. Le solde de votre compte en banque par exemple n’est en fait pas stocke dansun coffre, mais correspond a une entree dans une base de donnees. Les plates-formes de e-bankinget les moyens de paiement electronique ont fait diminuer l’utilisation de billets et de pieces. Lavirtualisation de la monnaie a ete possible par l’amelioration constante des moyens de chiffrement etde protection des donnees. Lors de transactions, les operations de verification sont gerees entierementpar les banques. En d’autres termes, les banques sont le cœur de ce type de systeme monetaire.

1.1.2 Changement de cap

Durant la crise des subprimes en 2007, le systeme bancaire s’ecrase et de grandes banques fontfaillite. C’est dans un contexte de mefiance envers le systeme bancaire que les cryptomonnaies voientle jour. L’objectif de ce nouveau genre de monnaie est de permettre a deux entites d’effectuer unetransaction sans l’intervention d’un tiers de confiance. Dans un systeme monetaire concurrentiel, laconfiance est remplacee par la preuve. Aucune banque ou gouvernement ne peut influencer l’emissionou la regulation de ce type de monnaie. L’utilisateur est replace au cœur du systeme. Il endossepar consequent certaines responsabilites de la banque, notamment celle de securiser son compte. Leprefixe crypto indique que ce sont des monnaies construites sur une base cryptographique permettantde garantir l’authenticite et l’integrite des transactions.

1.2. LA REVOLUTION BITCOIN 17

1.2 La revolution Bitcoin

La flambee du cours du Bitcoin a nourri plus d’un fantasme. Que se soit dans la sphere privee ouprofessionnelle, l’embleme des cryptomonnaies a fait parler de lui. Cette revolution economique etinformatique a debute en 2009 par la publication de sa premiere specification et preuve du concept,sous le mysterieux pseudonyme de ”Satoshi Nakamoto”. Le Bitcoin est un systeme de paiementelectronique qui permet d’effectuer des transactions pair a pair. Il s’appuie sur son reseau decentraliseet sa blockchain pour fonctionner. Les portefeuilles Bitcoins representent une interface permettantd’interagir avec son reseau et offrent la possibilite de creer des comptes, de les consulter et de genererdes transactions. Il est loin d’etre evident pour un utilisateur de choisir un wallet adapte a ses besoinset qui garantisse un bon niveau de securite.

1.3 Importance d’un portefeuille vis-a-vis de la securite

En s’affranchissant des services tiers comme les banques, les responsabilites comme la gestiondes comptes et leur securite sont restituees aux differents acteurs du systeme Bitcoin. Mais l’avan-tage de controler son argent implique des risques securitaires non negligeables. Il est de la res-ponsabilite de l’utilisateur de proteger ses Bitcoins et cela commence par le bon choix du wallet.L’association Bitcoin recommande un certain nombre de portefeuilles Bitcoin (wallet) pour smart-phones : (https://bitcoin.org/fr/choisir-votre-porte-monnaie). A l’image d’un mot de passequi securise l’acces a un compte, la paire de cles est l’unique element necessaire pour effectuer destransactions valides. Les portefeuilles Bitcoin, souvent illustres comme des porte-cles, s’assurent dela bonne gestion des cles, des transactions et de la gestion du compte. Il est donc primordial que lewallet utilise ait correctement adresse la problematique de la securite. Securiser des Bitcoins signifie :proteger la paire de cles, sauvegarder et chiffrer le wallet. Une bonne solution pour epargner des Bit-coins est d’utiliser un wallet hors-ligne. Celui-ci n’est pas connecte a Internet et n’est par consequentpas sujet aux attaques.

1.4 Organisation du document

Le present document est divise en 8 chapitres. Chacun des chapitres permet de repondre au cahierdes charges et de remplir les objectifs.

Cahier des charges Le document debute par le cahier des charges. Celui-ci fixe le cadre, pose laproblematique et definit les objectifs, les taches a realiser ainsi que les livrablesdu projet.

Chapitre 1 Le premier chapitre est une introduction au projet. Il presente les points clesde l’evolution de la monnaie, le contexte dans lequel Bitcoin a ete developpe,l’importance de proteger ses Bitcoins et l’organisation du document.

Chapitre 2 Le deuxieme chapitre correspond aux analyses preliminaires et introduitles notions necessaires a la comprehension des sujets abordes. La premiereetude preliminaire est un rappel des concepts cryptographiques de base. Laseconde etude presente OWASP MASVS.

Chapitre 3 Le chapitre trois est entierement consacre a Bitcoin et sa blockchain. L’objectifest de se familiariser avec les concepts du systeme Bitcoin.


https://bitcoin.org/fr/choisir-votre-porte-monnaie

18 CHAPITRE 1. INTRODUCTION

Chapitre 4 Le chapitre quatre permet de rentrer dans le vif du sujet en presentant le fonc-tionnement des differents wallets Bitcoin, l’architecture des wallets mobiles etl’analyse du processus de recommandation de l’organisation Bitcoin per-mettant par la suite d’effectuer une selection des applications a auditer.

Chapitre 5 La methodologie appliquee est detaillee dans ce chapitre. Elle explique lamaniere dont les applications ont ete selectionnees et decrit des methodologiesexistantes. Ce chapitre se conclus par le choix de la methodologie a savoir :l’elaboration d’un modele de menaces sur la base d’un wallet generique.

Chapitre 6 Le sixieme chapitre marque le debut de l’audit a proprement parler et docu-mente les differentes parties d’un modele de menaces. Celui-ci a permis,sur la base d’un wallet generique, de cibler les biens a proteger, les me-naces et les contre-mesures. Les contre-mesures etablies durant l’analysede menaces enrichissent la checklist d’OWASP mobile utilisee comme modelede bonnes pratiques et de contre-mesures a mettre en place.

Chapitre 7 Ce chapitre presente les resultats de l’analyse detaillee des applicationsselectionnees. La checklist finale utilisee permet de verifier les points essentielsetablis par le modele de menaces et les bonnes pratiques d’OWASP mobile.

Chapitre 8 Le chapitre huit conclut l’audit realise par un bilan securitaire et donne uneconclusion generale du projet. Une demonstration pratique accompagnechaque vulnerabilite majeure qui a ete decouverte.

Bibliographie Cette partie liste les differentes sources consultees.

Annexe Cette partie regroupe toutes les annexes. Notamment la fiche technique dechaque wallet recommande par l’organisation Bitcoin ainsi que les observa-tions relevees lors de l’analyse detaillee.

https://bitcoin.org

Chapitre 2

Etudes preliminaires

Sommaire2.1 Concepts cryptographiques . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.1.1 Chiffrement symetrique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.1.2 Chiffrement asymetrique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.1.3 Courbes elliptiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.1.4 Fonctions de hachage cryptographique . . . . . . . . . . . . . . . . . . . . 21

2.2 OWASP MASVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2.1 Niveaux de securite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2.2 Mobile App Security Checklist . . . . . . . . . . . . . . . . . . . . . . . . 23

19

20 CHAPITRE 2. ETUDES PRELIMINAIRES

2.1 Concepts cryptographiques

Par definition, une crypto-devise s’appuie sur des notions cryptographiques. Sans entrer dansles details, ce chapitre evoque les notions fondamentales sur lesquelles sont concues les differentesmonnaies virtuelles. La cryptologie consideree comme la science du secret depuis peu englobe :

La cryptographie qui represente les moyens techniques mathematiques et physiques permettantde (de)chiffrer, de signer un message et d’authentifier les individus.

La cryptanalyse qui represente l’activite visant a casser la securite d’un algorithme cryptogra-phique pour dechiffrer des conversations par exemple.

Deja depuis l’Antiquite, la necessite d’envoyer des messages chiffres presente une problematique.L’evolution constante des algorithmes de chiffrement est le fruit du combat incessant entre les crypto-graphes et les cryptanalystes. Cette concurrence a permis d’ameliorer les algorithmes et de diversifierles approches. Le principe general est illustre ci-dessous.

Figure 2.1 – Principe chiffrement

2.1.1 Chiffrement symetrique

Connue comme la plus ancienne forme de chiffrement, la cryptographie symetrique permet dechiffrer un message et de le dechiffrer a l’aide de la meme cle. La securite repose entierement sur lesecret partage, a savoir la cle choisie. La plus grande problematique de cette approche est l’echange dusecret, la cle, avec un tiers. On denombre plusieurs familles d’algorithmes, voici quelques exemples :

Lineaire utilise des fonctions affines. Ces algorithmes sont faibles et ne doivent par consequentjamais etre utilises !

Exemples : Vigenere, Hill, par permutation

Par flot permet de chiffrer un flux continu de donnees. Ce type d’algorithme fait partie des methodesmodernes de chiffrement.

Exemples : One-Time Pad, RC4

Par bloc permet de chiffrer un message en le decoupant en blocs de taille fixe (32-512 bits). Lamaniere dont les blocs sont chiffres est definie par le mode d’operation (ECB, CBC, CTR,etc). Ce type d’algorithme fait egalement partie des methodes modernes de chiffrement.

Exemple : DES (3-DES), AES, IDEA

2.1. CONCEPTS CRYPTOGRAPHIQUES 21

2.1.2 Chiffrement asymetrique

Par opposition au chiffrement symetrique, ou il est necessaire de partager un secret, le chiffrementasymetrique permet de s’affranchir de cette contrainte. La confidentialite des donnees representeespar l’etape de chiffrement s’effectue par le biais de fonction a sens unique. Ces fonctions ont lapropriete d’etre facilement calculables, mais difficilement inversables. Les entites possedent une pairede cles :

• Une cle publique peut etre partagee et distribuee a n’importe qui. La cle publique du destinataireest utilisee par l’expediteur pour chiffrer les donnees.

• Une cle privee doit etre stockee d’une maniere sure et ne doit jamais etre divulguee. A la receptiond’un message chiffre, le destinataire utilise sa cle privee pour le dechiffrer. La cle privee peutetre illustree par une breche secrete de la fonction a sens unique la rendant reversible. De cefait, elle permet facilement de retrouver le message original.

Les generations des cles asymetriques utilisent differentes proprietes mathematiques (logarithmesdiscrets, nombres premiers) et s’appuient sur la difficulte de factoriser des grands nombres en nombrespremiers. En general, les differentes cles asymetriques sont composees de deux nombres entiers. Lataille de ces deux parametres est determinante pour le niveau de securite. Ci-dessous sont listes deuxexemples d’algorithmes asymetriques incontournables :

— Protocole d’echange de cles Diffie-Hellman base sur un challenge-response.

— RSA (Rivest, Shamir, Adleman)

2.1.3 Courbes elliptiques

Les courbes elliptiques s’inscrivent egalement dans le cadre du chiffrement asymetrique. Bien quel’implementation et la theorie soient plus complexes, le chiffrement par courbe elliptique admet destailles de cles plus petites pour un niveau de securite equivalent. Les transactions Bitcoin sont signeesen utilisant cette technologie. La cle privee est representee par un nombre aleatoire et la cle publiquepar un point bidimensionnel de la courbe. L’algorithme utilise la multiplication de points et reposesur la difficulte a retrouver le facteur multiplicatif du point d’origine.

2.1.4 Fonctions de hachage cryptographique

Le principe d’une fonction de hachage cryptographique est d’associer une donnee d’une taille arbi-traire a son empreinte de taille fixe. Les fonctions de hachage cryptographiquement sures permettentde verifier l’integrite, d’authentifier l’expediteur et de signer un message. Ce type de fonction possedeles proprietes suivantes :

1. Le calcul de l’empreinte d’un message est une operation rapide.

2. L’empreinte doit etre impossible 1 a inverser (Resistance a la premiere preimage)

3. Il est impossible 1 de generer une meme empreinte avec un message different (Resistance ala deuxieme pre-image).

4. Il est impossible 1 que deux messages differents possedent la meme empreinte (Resistanceaux collisions).

1. Ce n’est pas impossible, mais on parle de computationally infeasible en anglais. Cela signifie que les calculsnecessiteraient trop de ressources. En cryptographie, on s’assure que le cout necessaire en ressources pour resoudre leprobleme soit superieur a sa recompense.


2.2 OWASP MASVS

MASVS pour Mobile Application Security Verification Standard est destinee aux developpeurset aux equipes de securite. Ce framework propose par l’OWASP et sa communaute fournit les res-sources necessaires pour creer et maintenir des applications mobiles securisees. L’utilisation desbonnes pratiques et le respect des exigences securitaires permettent de reduire significativementla probabilite des menaces et leurs impacts. Bien que les efforts soient concentres sur l’application,MASVS inclut dans ses criteres la securite de l’infrastructure. Ces recommandations ont ete definiesdans le but de fournir :

— Des standards pour que les applications puissent etre comparees

— Une ligne de conduite lors de la phase de developpement

— Une ligne de conduite lors de la phase d’analyse de la securite

2.2.1 Niveaux de securite

Pas toutes les applications doivent fournir le meme niveau de securite. C’est pourquoi MASVSdefinit 2 niveaux (L1,L2), ainsi qu’un niveau de defense en profondeur (R) visant a se premunir dureverse engineering. Les niveaux L1 et L2 fournissent des exigences de securite generiques.

L1 couvre toutes les applications

L2 couvre les applications qui traitent des donnees sensibles

R couvre les controles supplementaire du cote client

Figure 2.2 – Niveau de protection OWASP-MASVS

2.2. OWASP MASVS 23

2.2.2 Mobile App Security Checklist

Une checklist est disponible pour evaluer le niveau de securite des applications. Pour selectionnerquelles exigences sont interessantes pour nous, on se base sur le modele de menaces et sur les actifs.

Architecture, Design and Threat Modelling Requirements

Les premiers points de la checklist repertorient les exigences relatives a l’architecture de l’ap-plication et de l’infrastructure ainsi qu’au modele de menaces. Cette premiere partie s’assure quela securite a ete prise en compte durant tout le cycle de vie du projet. C’est pour cela que cettecategorie est ecartee. Neanmoins ces exigences permettront de s’assurer d’avoir liste toutes les end-points distants, les acteurs externes et les donnees sensibles.

Data Storage and Privacy Requirements

La protection des donnees est un point essentiel de la securite sur mobile. Les smartphones sontdes peripheriques tres exposes aux pertes et aux vols. De plus, la separation de contexte d’executionest plus ambigue sur Android. Le mecanisme IPC si mal implemente peut permettre a d’autresapplications d’acceder a certaines donnees. Avoir le controle sur les donnees est facile localement,mais les donnees ont tendances a terminer sur le cloud, generalement sous forme de backup.

Cryptography Requirements

La protection des donnees passe inevitablement par des methodes de chiffrement. Les aspectscryptographiques de l’application ne sont pas a prendre a la legere, car trop souvent les standardsne sont pas suivis. Les exigences de cette partie s’assurent que les pratiques soient conformes austandard et a l’industrie. Par exemple :

— L’utilisation de librairies standard

— L’implementation et le bon choix de l’algorithme

— La generation de nombres aleatoires conformes

Authentication and Session Management Requirements

La majorite des applications necessite la connexion d’un utilisateur a un service distant. Bien quele code ne soit pas disponible et que la majorite de la logique soit effective sur le serveur distant, lesexigences de gestion des comptes et des sessions peuvent facilement etre verifiees.

Network Communication Requirements

Une application fonctionne rarement de maniere isolee et doit echanger des informations avecd’autres services distants. La confidentialite et l’integrite sont donc des vecteurs importants. Toutecommunication doit par consequent s’effectuer sur un canal chiffre. L’utilisation du protocole SSL/TLSest incontournable pour garantir un minimum de securite.

Platform Interaction Requirements

Les exigences de cette partie concernent les API utilisees, l’implementation des composants stan-dards et la communication entre les applications (IPC).


Code Quality and Build Setting Requirements

L’objectif est de s’assurer de la qualite du code au travers des bonnes pratiques. Le compilateuroffre de nombreuses possibilites pour d’augmenter le niveau de securite.

Resiliency Against Reverse Engineering Requirements

Les codes sources des wallets Bitcoin recommandes par l’organisation Bitcoin sont deja disponibleset en libre acces. C’est pourquoi le reverse engineering n’a que peu d’interet dans notre cas. Lescontroles de cette partie augmentent le niveau de securite de l’application en compliquant la tache al’attaquant.

Chapitre 3

Bitcoin

Sommaire3.1 Bitcoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1.1 Avantages du Bitcoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1.2 Inconvenients du Bitcoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2 Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2.1 Full nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2.2 Chaıne la plus longue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2.3 Confirmation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3 Les transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3.1 Wallets Bitcoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.4 Miner du Bitcoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.4.1 Valider un bloc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

25

26 CHAPITRE 3. BITCOIN

3.1 Bitcoin

Le Bitcoin est un systeme de paiement electronique qui permet d’effectuer des transactions sansl’intervention d’une institution bancaire. A l’inverse du schema traditionnel, le Bitcoin ne repose passur la confiance en une entite tierce, mais sur des preuves cryptographiques. Le fonctionnement duBitcoin repose entierement sur son reseau decentralise et sa blockchain.

Figure 3.1 – Reseau decentralise BC

Source - https ://bitcoin.org/img/icons/new-user.svg

Les nœuds du reseau peuvent etre des clients Bitcoins qui generent des transactions ou des mineursqui les valident. En theorie, comme les nœuds sont independants les uns des autres, personne ne peutprendre le controle du systeme. Cependant, plus de la majorite de la puissance de calcul se trouvesur le territoire chinois. Chaque membre du reseau Bitcoin possede une adresse unique, a l’imaged’un numero de compte bancaire. Pour connaıtre le solde d’un compte, il faut analyser le flux destransactions en lien avec celui-ci. Seul le proprietaire peut gerer son compte et le depenser. De jouren jour, le Bitcoin seduit de nouvelles entreprises a travers le monde. On compte quatre moyensd’acquerir de la monnaie BTC :

1. Demande de paiement en Bitcoin

2. Achat sur une bourse de change

3. Echange de Bitcoin avec quelqu’un

4. Miner du Bitcoin

3.1.1 Avantages du Bitcoin

— Transfert d’une somme sans limite aux quatre coins du monde avec de faibles frais.

— Les transactions ne contiennent pas d’informations personnelles, sont securisees et irreversibles.

— L’utilisateur a un controle total, meme sur les frais.

— Le protocole Bitcoin est cryptographiquement sur.

— La blockchain est consultable en temps reel.

3.2. BLOCKCHAIN 27

3.1.2 Inconvenients du Bitcoin

— Tout le monde n’a pas acces a Internet, ni ne connaıt l’existence du Bitcoin.

— Les transactions ne sont pas instantanees : il faut attendre environ 1h pour la validation.

— Si la majorite du reseau est corrompue, le systeme Bitcoin peut etre controle ou manipule.

— La nature volatile du Bitcoin : le prix du Bitcoin varie a chaque instant.

— Bitcoin n’est pas encore assez mature. De nombreuses applications et autres alternatives (Ethe-rum, etc.) sont en cours de developpement.

3.2 Blockchain

La blockchain ou chaıne de bloc en francais contient toutes les transactions confirmees depuisla creation du Bitcoin. Elle peut etre illustree par un livre comptable. Chaque bloc de la chaıneconsignent un certain nombre de transactions ayant ete confirmees. Tous les blocs confirmes sontrepertories de maniere securisee, transparente et irreversible. La cryptographie assure l’integrite desblocs ainsi qu’un ordre chronologique entre ceux-ci par le biais d’empreinte cryptographique.

Figure 3.2 – Blockchain

3.2.1 Full nodes

La blockchain se trouve localement recopiee sur differents nœuds de son reseau decentralise. Cesnœuds sont nommes full nodes en anglais. Ils sont indispensables a la decentralisation et verifienttoutes les regles Bitcoins de tous les blocs qu’ils telechargent, voici un extrait :

— Toutes les signatures des transactions doivent etre correctes

— Le montant genere par un bloc doit etre conforme a la norme du moment(actuellement 12.5BTC)

— Verifier les doubles depenses

— Verifier le Proof of Work

— Verifier le chaınage

Tout les nœuds du reseau ne sont pas des full nodes et donc ne stockent pas la blockchainlocalement. Pour leur permettre tout de meme de determiner si une transaction a ete validee ou decalculer le solde d’un compte, la methode Simple Verification Paiement permet d’interroger les fullnodes. Ceux-ci filtrent les transactions pour ne retourner que les informations minimums.


3.2.2 Chaıne la plus longue

Deux blocs ne contenant pas obligatoirement les memes transactions sont confirmees simul-tanement. Chacun des deux blocs pourra integrer la blockchain, puisqu’il est considere comme valide.Cette situation donne naissance a une deuxieme instance de la chaıne. C’est a la reception du pro-chain bloc que le reseau sait quelle chaıne est acceptee : c’est toujours la chaıne la plus longue quiest consideree.

Figure 3.3 – Blockchain : chaıne la plus longue

L’illustration ci-dessus montre le scenario dans lequel deux fois de suite deux blocs sont validessimultanement. C’est a la reception du troisieme bloc que le reseau ecarte l’instance du haut etaccepte celle du bas.

3.2.3 Confirmation

Une transaction est dite confirmee lorsque son bloc integre la blockchain. Le risque d’etre inva-lide diminue d’une facon plus ou moins exponentielle a chaque confirmation, c’est-a-dire a chaquereception d’un nouveau bloc. Bien qu’une confirmation soit suffisante pour de petits montants, uneattente de six blocs est justifiee pour des montants importants.

3.3 Les transactions

Pour effectuer une transaction, il est necessaire d’etre connecte au reseau et de posseder uneadresse Bitcoin, ce qui implique de posseder une paire de cles. Lors d’une transaction, l’expediteurcede en fait la propriete d’un montant inclus dans la blockchain a un destinataire. La transaction estprotegee par signature contre les modifications et est diffusee afin que les nœuds du reseau puissentla verifier. Les utilisateurs sont encourages a ajouter quelques centimes pour une confirmation plusrapide et pour remunerer les mineurs une fois la limite du nombre de Bitcoins en circulation atteinte.

3.3.1 Wallets Bitcoin

Les Bitcoins ne sont pas stockes dans un portefeuille numerique, mais dans la blockchain. Unwallet stocke en realite le moyen d’acceder aux Bitcoins, c’est-a-dire la paire de cles. Les walletsBitcoin creent et diffusent de nouvelles transactions. La cle publique identifie l’utilisateur du wallet,alors que la cle privee permet de signer des transactions et de fournir un moyen mathematique afinde prouver la propriete des Bitcoins.

3.4. MINER DU BITCOIN 29

Figure 3.4 – Transaction, cle privee

Source - https ://bitcoin.org/img/icons/private-keys.svg

3.4 Miner du Bitcoin

A l’image des employes d’une banque qui verifient et ecrivent les transactions dans un registre,les mineurs verifient constamment les nouvelles transactions. Le role des mineurs est indispensableau fonctionnement du Bitcoin, il protege la neutralite du reseau et permet a differents noeuds des’entendre sur l’etat de la blockchain (consensus). Ils collectent les transactions et les regroupentpour former un bloc. Chaque bloc integre a la blockchain genere une quantite predefinie de Bitcoinsqui est reduite de moitie tous les quatre ans. Ces nouveaux Bitcoins sont ajoutes au bloc sous formed’une nouvelle transaction au benefice du mineur. Il n’existe cependant pas une quantite infinie deBitcoins ; la limite d’unites en circulation est fixee a 21 millions et sera atteinte en 2104. A noterqu’il est necessaire d’attendre au minimum 100 confirmations avant de pouvoir depenser des Bitcoinsfraıchement generes. Cette precaution est necessaire pour limiter les effets lorsqu’une instance de lablockchain est invalidee.

3.4.1 Valider un bloc

Pour creer un nouveau bloc, il ne suffit pas de simplement verifier les transactions. Les mineursdoivent trouver une solution a un probleme cryptographique. On appelle ce concept Proof of Work ;travail difficile a produire, couteux en temps et en energie, mais tres facile a verifier. L’algorithmeBitcoin specifie qu’il faut environ 10 minutes au reseau de mineurs pour creer un nouveau bloc. Lebut est de calculer a l’aide de l’algorithme sha-256, un hash contenant un certain nombre de 0. Cenombre defini par le reseau indique la difficulte du challenge : plus il y a de 0, plus le challenge estdifficile. Le mineur se base sur le hash du bloc precedant, le hash de la racine des transactions, untimestamp et une valeur aleatoire. Pour chaque valeur aleatoire, l’algorithme doit etre effectue. Lepremier mineur qui trouve un hash respectant la difficulte dictee envoie le bloc a ses voisins. Cesnœuds du reseau verifient la validite du bloc a l’aide de la valeur aleatoire utilisee. Ensuite, si le blocest valide, ils propagent le bloc a leur tour.

Chapitre 4

Wallets Bitcoin

Sommaire4.1 Les wallets Bitcoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1.1 Generer des comptes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1.2 Calculer le solde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1.3 Effectuer une transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1.3.1 Rotation d’adresse . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1.4 Securite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1.5 Lightweight node wallets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2 Deterministic wallet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2.1 Ancienne approche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2.2 Type 1 - Deterministic wallet . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2.2.1 Type 2 - Hierarchical Deterministic wallet . . . . . . . . . . . . . 34

4.3 Simplified Payment Verification . . . . . . . . . . . . . . . . . . . . . . . 35

4.3.1 Peer Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.3.2 Bloom filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.4 Multi-signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.4.1 Hybrid wallet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.5 Processus de recommandation Bitcoin.org . . . . . . . . . . . . . . . . 37

4.5.1 Categorie de wallet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.5.2 Criteres et contre-mesures . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.5.3 Resultats du processus de recommandation . . . . . . . . . . . . . . . . . 38

4.5.4 Points forts du processus de validation . . . . . . . . . . . . . . . . . . . . 39

4.5.5 Points faibles du processus de validation . . . . . . . . . . . . . . . . . . . 39

31

32 CHAPITRE 4. WALLETS BITCOIN

4.1 Les wallets Bitcoin

Les wallets Bitcoin se retrouvent sous 3 formes differentes.

Hardware

Un portefeuille physique prend generalement la forme d’une cle USB. Cet appareil dedie etsecurise permet de stocker les cles privees hors d’atteinte du reseau. Meme si la machine estinfectee, les cles sont inaccessibles. Ce type de wallet offre le meilleur niveau de securite.

Software

Un portefeuille applicatif s’installe soit sur un telephone mobile, soit en local sur un ordinateur.Il peut etre relie a Internet ou non selon le niveau de securite souhaite. C’est la forme la plusrepandue et la plus facile d’utilisation. La generation des differents elements est geree parl’application.

Web

Un portefeuille en ligne est generalement propose par les plateformes d’achat. Bien que sonutilisation soit simplifiee au maximum, cela pose des problemes securitaires. Certaines attaquesont permis de derober des cles privees. Les hackers ont ainsi acces aux Bitcoins des utilisateursconcernes.

4.1.1 Generer des comptes

La premiere chose a faire pour utiliser Bitcoin est de creer un wallet. Il s’agit de generer une pairede cles, ainsi qu’une adresse Bitcoin. Bitcoin utilise l’algorithme ECDSA, Elliptic Curve DigitalSignature Algorithm pour generer les differentes cles et verifier les signatures.

La cle privee

La cle privee permet de prouver via une signature que l’utilisateur est bien le proprietaire dumontant transfere. L’algorithme genere un nombre entier aleatoire qui correspond a un pointsur une courbe elliptique.

La cle publique

La cle publique permet de verifier la signature d’une transaction. Cette cle est generee surla base de la cle privee et correspond a un facteur multiplicatif du generateur de la courbeelliptique. Il est impossible de retrouver la cle privee a partir de la cle publique.

L’adresse Bitcoin

L’adresse Bitcoin permet de recevoir des transactions. Elle est generee a partir d’une cle pu-blique sur laquelle un double hashage (SHA-256, RIPEMD-160) est realise. L’adresse est auformat ASCII encodee en Base58Check pour eviter les erreurs humaines. L’adresse BC estsouvent presentee sous forme de QR.Code.

La possiblite de generer deux fois la meme adresse Bitcoin est possible, mais la probabilite quecela arrive est minime et negligable.

4.1.2 Calculer le solde

Le solde du compte est constamment affiche et rafraıchi dynamiquement sans que l’utilisateur enfasse la demande. Le wallet doit inspecter toutes les transactions en lien avec le compte et calculerle solde a partir des blocs confirmes de la blockchain. Soit le wallet dispose d’une blockchain localeet dans ce cas, il peut la consulter lui-meme, soit il passe par l’intermediaire d’un full node et lamethode Simple Payment Verification.

4.1. LES WALLETS BITCOIN 33

4.1.3 Effectuer une transaction

Pour effectuer une transaction, il est necessaire de specifier au minimum l’adresse Bitcoin dudestinataire et le montant de la transaction. Des frais de transaction peuvent etre ajoutes pourremunerer les mineurs. Pour qu’une demande de transaction soit prise en charge par le reseau demineur, il faut que la transaction soit signee, c’est-a-dire s’assurer que ce soit reellement l’expediteurde la demande qui ait donne l’ordre du virement. La transaction est signee a l’aide de la cle priveede l’utilisateur.

4.1.3.1 Rotation d’adresse

Les transactions recues peuvent etre considerees comme des pieces Bitcoins. Ces pieces ne peuventpas etre divisees en unites plus petites. Lors d’une transaction, une ou plusieurs pieces sont utilisees.Si le montant a payer est inferieur au total des pieces, alors le surplus de BTC est retourne auproprietaire sous forme d’une nouvelle transaction.

4.1.4 Securite

A l’inverse d’un portefeuille classique ou un peu de liquidite serait perdue et les cartes rem-placees, la perte ou le vol d’un wallet Bitcoin est une situation irreversible. C’est donc au prorietairequ’incombe la responsabilite de securiser les diverses cles.

Sauvegarde

Il est indispensable d’avoir un moyen securise de recuperer ses cles perdues ou volees. Il existeplusieurs possibilites : sauvegarder les cles en format de fichier chiffre, ecrire les cles sur dupapier ou utiliser une valeur aleatoire permettant de retrouver les cles.

Utilisation responsable

Pour garantir une bonne securite, il est necessaire que l’utilisateur soit informe des risques etdes menaces qui pese sur lui. Le choix du wallet est un point important puisque l’applicationeffectue la gestion et le stockage des cles.

Epargne

Les wallets mobiles ont une large surface d’attaque, c’est pourquoi leur utilisation est recom-mandee pour stocker des Bitcoins susceptibles d’etre depenses comme par exemple l’argentliquide. Une solution d’epargne securisee est l’utilisation d’un wallet hardware.

4.1.5 Lightweight node wallets

L’espace necessaire pour stocker la blockchain est incompatible avec un environnement mobile.Le papier officiel Bitcoin de Satoshi Nakamoto detaille le moyen pour un lightweight wallet, walletqui ne dispose pas de la blockchain localement, de verifier des transactions. L’approche consiste ainterroger un full node du reseau Bitcoin, qui lui, possede toutes les informations necessaires afinde valider des transactions.


4.2 Deterministic wallet

Un wallet deterministe permet de deriver une infinite de cles a partir d’une valeur aleatoire. Al’aide de ce seed uniquement, il est possible de sauvegarder et de restaurer facilement un compteBitcoin possedant plusieurs adresses BTC. Des cles publiques peuvent meme etre generees sansconnaıtre la cle privee.

4.2.1 Ancienne approche

Les premiers wallets Bitcoin generaient un pool de cles privees ( 100) de maniere aleatoire. Cescles sont utilisees pour la reception de paiements et la rotation d’adresse. Une fois ce pool epuise, lasauvegarde est invalidee puisqu’il est necessaire de generer un autre pool.

4.2.2 Type 1 - Deterministic wallet

Un wallet deterministe de type 1 utilise une chaıne de caracteres pour generer les adresses. Chaqueadresse est generee de la maniere suivante :

1. La chaıne est concatenee avec un compteur

2. Le resultat de la concatenation est hashe avec l’algorithme SHA-256

3. Le compteur des cles generees est incremente

4.2.2.1 Type 2 - Hierarchical Deterministic wallet

Un HD wallet offre des fonctionnalites plus avancees qu’un wallet deterministe. Il genere des clesprivees a partir d’un seed, sous forme de 12 mots en anglais, de 128 bits. Il exploite les proprietesdes courbes elliptiques pour generer des cles publiques sans connaıtre la cle privee. La definition duconcept HD wallet est precisee dans les BIPs (Bitcoin Improvement Proposal) : 32, 39, 44.

4.3. SIMPLIFIED PAYMENT VERIFICATION 35

4.3 Simplified Payment Verification

L’approche Simplified Payment Verification telecharge uniquement les en-tetes des blocs dela plus longue chaıne lors de la synchronisation initiale. La taille se limite ainsi a 4.2 MB par annee.Toutes les nouvelles transactions font l’objet d’une requete aupres d’un full node. La methode SPVutilise la racine merkle et la branche associee pour prouver qu’une transaction est incluse dans unbloc. Cela ne garantit dans aucun cas la validite de la transaction, mais permet d’estimer la quantitede travail necessaire pour realiser une attaque a double depense. Cette estimation se base sur laprofondeur du bloc, c’est-a-dire ou il se trouve par rapport au dernier bloc ajoute a la blockchain.

Figure 4.1 – Protcole SPV, source - https ://eprint.iacr.org/2014/763.pdf

4.3.1 Peer Discovery

Un wallet leger doit absolument se connecter a un full node pour fonctionner correctement. Pource faire, plusieurs noms DNS sont hard-codes dans les librairies Bitcoinj et Bitcoin core. Ces seedsDNS peuvent soit etre statiques soit dynamiques et fonctionnent sur le port 8333 pour mainnet ou18333 pour testnet. Ils sont maintenus par la communaute Bitcoin.

4.3.2 Bloom filter

Un bloom filter est une structure de donnees utilisee pour tester l’appartenance d’un element.C’est en fait un tableau de n bits associes a k fonctions de hashage. Chacune des sorties de ces kfonctions est un entier entre 1 et n. Lors de l’ajout d’un element dans le filtre, l’element est hashek fois separement. Pour chacune des sorties des fonctions de hashage, les bits du filtre associe sontpasses a 1. Plus on retrouve de 1 dans le filtre, plus la probabilite est grande que l’element appartiennea un ensemble. Des parametres permettent a l’utilisateur de choisir le taux de faux positifs.


4.4 Multi-signature

Generalement une transaction est effectuee d’une personne a une autre. La transaction n’est doncsignee que par une seule cle privee. Les wallets implementant la multi-signature utilisent plusieurs clesprivees pour autoriser une transaction. L’adresse du compte est en fait partagee entre les membres dugroupes. Le nombre de cles minimum devant signer la transaction est fixe a la creation de l’adresse.Donc si quelqu’un s’empare de la cle privee, il ne pourra pas depenser les Bitcoins. Il devra au moinsvoler le nombre de cles necessaires a la validation d’une transaction.

Figure 4.2 – Multisignatures

4.4.1 Hybrid wallet

Les wallets en ligne ont tres vite evolue sous la forme de wallets hybrides. Les cles sont stockeeslocalement dans un wallet, mais on trouve aussi une copie chiffree chez le service tiers. Lorsqu’unutilisateur s’authentifie aupres du service tiers et effectue une transaction, sa paire de cles est chargeedans un navigateur Web. La transaction est signee par l’utilisateur et le service tiers. C’est en faitune implementation du multi-signatures. La cle doit alors etre chiffree avec un mot de passe robuste.

4.5. PROCESSUS DE RECOMMANDATION BITCOIN.ORG 37

4.5 Processus de recommandation Bitcoin.org

Quelques recherches sur le web demontrent qu’il existe une multitude de wallets Bitcoin. Il est loind’etre evident pour un utilisateur de choisir un wallet adapte a ses besoins et qui garantisse un bonniveau de securite. Comme mentionne precedemment la securite d’acces aux Bitcoins est a la chargedu proprietaire. Le premier pas est le bon choix du wallet. L’organisation Bitcoin, consciente desrisques et des menaces pesant sur sa communaute, a mis en place un processus de recommandation.Celui-ci a permis de recommander 11 wallets qui selon leurs criteres fournissent un niveau de securitesuffisant. Le but de cette section est d’analyser ce processus ainsi que ses resultats. Une grande partiedu travail effectue ici a ete la documentation des applications recommandees, repertoriees dans lesannexes.

Toute la documentation du processus de recommandation se trouve sur le depot github suivant :https://github.com/bitcoin-dot-org/bitcoin.org#how-to-participate. Avant de soumettrele nouveau wallet, un certain nombre de criteres doivent etre respectes. Voici quelques exemples decriteres :

— Un nombre suffisant de feedbacks disponibles publiquement ;

— Le fonctionnement de l’application exempte de bugs ;

— Le code source teste en interne et les resultats publics ;

— Le portefeuille doit exister depuis au moins 3 mois ;

— Le site Internet doit supporter SSL/TLS ;

— L’identite des developpeurs ou du CEO doit etre connue.

A noter qu’un audit independant n’est qu’un critere optionnel ! Une fois valide, le portefeuille ne doitplus repasser par le processus de validation meme apres une mise a jour.

4.5.1 Categorie de wallet

L’analyse preliminaire realisee sur le Bitcoin a montre qu’il existait plusieurs categories de wal-lets. Chacune de ces categories possede une architecture differente et donc des niveaux de securitedifferents. La surface d’attaque, les risques et les menaces ne sont pas identiques pour toutes cescategories. Le classement ci-dessous a ete defini par l’organisation Bitcoin. Les categories sont classeesdu plus au moins securise.

1. Full Node

2. SPV, Random servers

3. Hybrid, Multisig wallets

4. Web wallets

Les wallets implementes en full node se pretent mal a un environnement mobile. Actuellement,les smartphones ne fournissent pas l’espace suffisant pour stocker la blockchain en entier. Les walletsweb n’ont que peu d’utilite a etre implementes en application mobile si ce n’est de fournir uneauthentification a 2 facteurs pour s’authentifier aupres du service tiers via une page web. La majoritedes wallets mobiles sont donc de categorie 2 et 3.

https://github.com/bitcoin-dot-org/bitcoin.org#how-to-participate


4.5.2 Criteres et contre-mesures

En plus de remplir les exigences de base, le processus de validation s’appuie sur 5 criteres. Cescriteres servent a augmenter le niveau de securite generale de l’application. Pour chacune des applica-tions soumises au processus de recommandation, les mainteneurs de bitcoin.org evaluent et attribuentun score pour tous ces criteres.

Controle : Quel controle l’utilisateur a sur ses Bitcoins ?

Le portefeuille doit fournir a l’utilisateur un controle exclusif sur ses Bitcoins. Les sauvegardesen ligne doivent etre chiffrees pour que seul l’utilisateur puisse les dechiffrer. Les portefeuillesmulti-signatures sont egalement acceptes a condition qu’une transaction ne demande pas l’au-torisation d’un service tiers. Vous etes toutefois toujours responsable de securiser et de sauve-garder votre portefeuille.

Validation : A quel point peut-on avoir confiance en la securite d’un paiement ?

La meilleure facon d’avoir une confiance totale dans le systeme de paiement est que le walletsoit implemente en full node. C’est-a-dire de stocker la blockchain entiere. Toutefois, le modeleSPV fournit un niveau acceptable de securite.

Transparence : Peut-on avoir confiance en l’application ?

Le code source doit etre open-source afin que la communaute puisse le consulter et l’analyser.L’executable doit etre compile d’une maniere deterministe.

Environnement : Est-ce que l’environnement du portefeuille est securise ?

Le meilleur score est obtenu lorsqu’il n’est pas possible d’installer d’autres applications. Ce-pendant, l’isolation des applications doit etre suffisante ou alors l’application doit fournir uneauthentification a deux facteurs. Un environnement securise permet de se proteger des logicielsmalveillants. En pratique toutefois, les malwares sont une menace non negligeable, capablesd’acceder a l’application bien qu’elle s’execute de maniere isolee.

Confidentialite : Est-ce que le portefeuille protege la vie privee des utilisateurs ?

Bitcoin ne garantit pas l’anonymat, ni la confidentialite du solde et des transactions. Il est ce-pendant possible de compliquer la tache a un attaquant en utilisant une rotation des adressesBitcoin. Le principe est d’utiliser pour chaque transaction une nouvelle adresse. Les infor-mations doivent eviter de transiter par des tiers ou des serveurs centralises. Un plus est lacompatibilite de l’application avec le reseau Tor.

4.5.3 Resultats du processus de recommandation

Les criteres de transparence, d’environnement et de privacy ne sont volontairement pas presentes.Toutes les applications recommandees mettent a disposition le code source et toutes s’executent surun environnement mobile. De plus, elles permettent toutes la rotation d’adresses a l’exception d’une,libellee par weak privacy. Seulement 2 wallets parmi 11 permettent d’utiliser le reseau Tor quiameliore la privacy. Les applications ont volontairement ete divisees en categories pour faciliter lescomparaisons. Les categories 2 et 3 sont representees plus ou moins de maniere egale. On retrouve 6applications de categorie 2 et 5 de categorie 3. Bien que les wallets hybrides ou multi-signatures aientune surface d’attaque plus grande, ils restent tres utilises et repandus. Le tableau ci-dessous resumeles resultats du processus. Toutes les informations sont disponibles sur le github de l’organisationBitcoin.

Sans grande surprise, la categorie 2 offre d’une maniere generale un meilleur niveau de securiteou du moins obtient un meilleur score que la categorie 3. Du a l’architecture des wallets hybrides et

4.5. PROCESSUS DE RECOMMANDATION BITCOIN.ORG 39

Application Categorie Controle Validation Score RemarquesBitcoin Wallet 2 Full SPVBreadwallet 2 Full SPVElectrum 2 Full SPVSimple Bitcoin wallet 2 Full SPVBither 2 Full SPV 7Weak privacyGreenBits 2 Multi SPV 3TorArcBit 3 Full centraliseCoin.Space 3 Full centraliseGreenAddress 3 Multi decentralise 3Auth 2 facteurMyceluim 3 Multi centralise 3TorAirBitz 3 Hybrid centralise

Table 4.1 – Resultat du processus de recommandation

aux multi-signatures, les services tiers sont d’avantage presents. Seule une application sur les 5 offrela possibilite d’une validation decentralisee et plus de la moitie stockent une copie des cles chez unservice tiers.

4.5.4 Points forts du processus de validation

1. Pre-choix

2. Wallets audites

3. Securite axee Bitcoin

4.5.5 Points faibles du processus de validation

1. Il ne s’effectue qu’une seule fois. Une mise a jour peut introduire de nouvelle vulnerabilite

2. Il ne verifie pas les bonnes pratiques

3. Lourd et restreignant pour les nouveaux wallets

Chapitre 5

Methodologie

Sommaire5.1 Selection des wallets a analyser . . . . . . . . . . . . . . . . . . . . . . . 42

5.1.1 Criteres de selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.1.2 Selection des wallets a analyser . . . . . . . . . . . . . . . . . . . . . . . . 42

5.2 Methodologies existantes . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.2.1 L’analyse de menaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.2.2 L’analyse de risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.3 Modele de menaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.3.1 Methodologie choisie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

41

42 CHAPITRE 5. METHODOLOGIE

5.1 Selection des wallets a analyser

5.1.1 Criteres de selection

Actuellement bitcoin.org recommande onze portefeuilles. Le temps ne permet pas d’auditer l’en-semble de ces applications mobiles dans le cadre de ce travail. Pour maximiser l’impact de cetteetude, les applications seront selectionnees sur la base des criteres suivants :

Nombre de telechargements

La popularite de l’application est un bon facteur de motivation pour un attaquant. Plus lacommunaute est grande, plus il y a d’utilisateurs cibles.

Date release

Pour maintenir un bon niveau de securite, les applications doivent etre maintenues et mises ajour regulierement. Les mises a jour permettent de corriger des erreurs ou des failles, de mettrea disposition de nouvelles fonctionnalites et de s’adapter a l’environnement qui lui aussi evolue.

Date validation

Durant leur cycle de vie, les portefeuilles recommandes ne sont valides qu’une seule fois. Achaque mise a jour, on ne doit pas negliger le risque d’introduire de nouvelles vulnerabilites.

5.1.2 Selection des wallets a analyser

Le nombre d’installations 1 est un bon indicateur de la popularite de l’application au sein de lacommunaute Bitcoin. Plus il y a d’utilisateurs touches par une faille potentielle, plus l’impact de cetravail est grand.

Application Categorie Nb d’installations Date release1 Bitcoin Wallet 2 1 000 000 - 5 000 000 18.03.20182 Myceluim 3 500 000 - 1 000 000 24.02.20183 AirBitz 3 100 000 - 500 000 29.09.20174 Simple Bitcoin wallet 2 100 000 - 500 000 20.12.20175 Electrum 2 100 000 - 500 000 12.03.20186 Breadwallet 2 100 000 - 500 000 17.03.20187 GreenAddress 3 50 000 - 100 000 16.12.20178 GreenBits 2 50 000 - 100’ 000 16.12.20179 Coin.Space 3 50 000 - 100 000 02.03.201810 ArcBit 3 10 000 - 50 000 15.01.201811 Bither 2 10 000 - 50 000 05.02.2018

Table 5.1 – Selection des wallets a analyser

Au premier coup d’œil, on remarque dans le top 3, deux wallets de categorie 3. Les utilisateursde ce type de wallet deleguent leur responsabilite au service tiers et leur accordent toute confiance.Un peu ironique tout de meme en sachant que Bitcoin a ete construit de maniere a eviter ce genrede situation. Les applications sont maintenues a jour regulierement. Il existe cependant quelquesexceptions.

1. Le nombre d’installations par application a ete releve depuis le Google Play store

<https://bitcoin.org/fr/wallets/mobile/android/>

5.2. METHODOLOGIES EXISTANTES 43

5.2 Methodologies existantes

Les methodologies existantes presentees ci-apres ont servi de base de reflexion. Il en existeevidemment d’autres, cependant celles-ci ont permis d’en definir une personnalisee.

5.2.1 L’analyse de menaces

L’analyse de menaces se focalise sur les menaces pesant sur le systeme. Elle vise a documenteret a proposer des mitigations aux vulnerabilites identifiees. Cette analyse s’adresse a un public plustechnique.

STRIDE est un modele de classification de menaces. Il identifie et classe les menaces du pointde vue de l’attaquant : Spoofing, Tampering, Repudiation, Information Disclosure, Denial ofService, Elevation of Privilege.

Arbre d’attaque est un arbre dont les nœuds representent une attaque. Chaque branche representeune etape de l’attaque. Cette approche est utile pour avoir une vue d’ensemble des conditionsnecessaires a une attaque.

5.2.2 L’analyse de risques

L’analyse de risques permet d’identifier, de documenter et de reduire les risques par le biais d’uneclassification selon leur criticite, a savoir la probabilite sur l’impact. Cette analyse s’adresse a unpublic plus large et pas forcement technique.

OCTAVE est l’acronyme de Operationally Critical Threat, Asset, Vulnerability Evaluation developpepar Computer Emergency Response Team (CERT). Ce framework s’oriente vers une evaluationglobale des risques. L’approche d’OCTAVE se concentre principalement sur les actifs dans leurcontexte d’utilisation, de stockage, de transport, de traitement et leur exposition aux menaces,aux vulnerabilites et aux perturbations.

5.3 Modele de menaces

Le modele de menaces est une approche developpee par Microsoft afin d’integrer la securitedes le debut plutot que de la patcher. La documentation realisee lors du modele de menaces aide acomprendre le systeme dans son integralite. Le processus de la modelisation de menaces se decomposeen trois grandes parties.

1. La premiere etape consiste a comprendre l’application et ses interactions avec les entitesexternes. Cette phase comprend :

— La documentation des cas d’utilisation de l’application

— L’identification des points d’entree

— L’identification des actifs

— L’identification des niveaux de confiance accordes aux services tiers

Ces informations servent a produire des diagrammes de flux de donnees (DFD).

2. La deuxieme etape permet de determiner et de classer les menaces. Cette phase est realiseeen appliquant une methodologie de categorisation de menaces. L’objectif de cette methodologieest donc d’identifier les menaces, leurs impacts et de les classer selon leurs risques.

44 CHAPITRE 5. METHODOLOGIE

3. La troisieme et derniere etape sert a elaborer les contres-mesures. La priorisation desrisques permet de developper une strategie d’attenuations. Cette strategie priorise la mise enplace des contre-mesures.

Le but de cette analyse est de definir une liste de criteres d’evaluations. Ces derniers sontle fil conducteur permettant l’audit plus detaille des applications recommandees.

5.3.1 Methodologie choisie

La documentation des onze differents wallets a revele les fonctionnalites les plus pertinentes. Surla base de ces informations, un wallet generique peut etre propose comme base de reflexion. Le modelede menaces d’un wallet generique aidera a etablir les contre-mesures preventives a mettre en place.Les resultats de l’analyse de menaces s’appliquent a tous les wallets Bitcoin implementant les memesfonctionnalites. Ces contre-mesures integreront par la suite une checklist indiquant si oui ou nonl’application est vraiment recommandable. L’illustration suivante decrit la methodologie appliqueepour atteindre les objectifs.

Figure 5.1 – Methodologie

Chapitre 6

Modele de menaces

Sommaire6.1 Description d’un wallet mobile generique . . . . . . . . . . . . . . . . . 47

6.1.1 Remarques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6.1.2 Acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6.1.3 Cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.1.3.1 Details des cas d’utilisations . . . . . . . . . . . . . . . . . . . . 49

6.1.4 Actifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.1.5 Sources de menaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6.1.6 Data Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.2 Scenarios d’attaques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6.2.1 Criteres de mesure de l’impact . . . . . . . . . . . . . . . . . . . . . . . . 56

6.2.2 Client local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.2.3 Service tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.2.4 Developpeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6.2.5 Priorisation des menaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6.3 Mesures securitaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.3.1 Stockage de donnees et confidentialite . . . . . . . . . . . . . . . . . . . . 65

6.3.1.1 Chiffrer les donnees sensibles . . . . . . . . . . . . . . . . . . . . 65

6.3.1.2 Chiffrer les sauvegardes . . . . . . . . . . . . . . . . . . . . . . . 65

6.3.2 Cryptographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.3.2.1 Choix/implementation d’un algorithme de chiffrement en accordavec les bonnes pratiques . . . . . . . . . . . . . . . . . . . . . . 66

6.3.2.2 Seed genere de maniere aleatoire et non deterministe . . . . . . . 66

6.3.3 Authentification et gestion de session . . . . . . . . . . . . . . . . . . . . . 66

6.3.3.1 Verification des entrees utilisateurs et validation cote serveur . . 66

6.3.3.2 Forcer un mode de deverrouillage du systeme . . . . . . . . . . . 66

6.3.3.3 Proteger l’acces a l’application . . . . . . . . . . . . . . . . . . . 66

6.3.3.4 Proteger les actions sensibles . . . . . . . . . . . . . . . . . . . . 67

6.3.3.5 Politique anti-Bruteforce . . . . . . . . . . . . . . . . . . . . . . 67

6.3.3.6 Limiter la duree de vie d’une session . . . . . . . . . . . . . . . . 67

6.3.4 Communication reseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

45

46 CHAPITRE 6. MODELE DE MENACES

6.3.4.1 Proteger les communications avec TLS . . . . . . . . . . . . . . 67

6.3.4.2 Verifier les certificats . . . . . . . . . . . . . . . . . . . . . . . . 67

6.3.4.3 Restreindre les CAs . . . . . . . . . . . . . . . . . . . . . . . . . 67

6.3.4.4 Certificate Pinning . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6.3.5 Configuration SSL stricte du serveur . . . . . . . . . . . . . . . . . . . . . 68

6.3.6 Autres criteres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6.3.6.1 Tenir le systeme et les applications a jour . . . . . . . . . . . . . 68

6.3.6.2 Politique des mots de passe . . . . . . . . . . . . . . . . . . . . . 68

6.3.6.3 Installer l’application uniquement depuis une source sure . . . . 69

6.3.6.4 Chiffrer l’appareil . . . . . . . . . . . . . . . . . . . . . . . . . . 69

6.3.6.5 Politique anti-DDoS . . . . . . . . . . . . . . . . . . . . . . . . . 69

6.3.6.6 Installer un anti-malware . . . . . . . . . . . . . . . . . . . . . . 70

6.3.6.7 Informer l’utilisateur des menaces . . . . . . . . . . . . . . . . . 70

6.3.6.8 Code source disponible . . . . . . . . . . . . . . . . . . . . . . . 70

6.4 Criteres d’evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

6.1. DESCRIPTION D’UN WALLET MOBILE GENERIQUE 47

6.1 Description d’un wallet mobile generique

Le modele de menaces se base sur un wallet Bitcoin mobile et generique. Dans sa forme la plusbasique, un wallet offre la possibilite de gerer des comptes, d’effectuer des transactions et proposeun moyen de sauvegarde de la cle privee. En analysant les wallets Bitcoin recommandes, on observeque dans la majorite des cas, le wallet est de type Hierarchical Deterministic (BIP 32, 39, 44). Ceciimplique que la sauvegarde ne contient plus les cles privees, mais le seed utilise. La liste suivanteresume les fonctionnalites que l’on retrouve generalement implementees :

— HD wallet

— Creation de compte (paire de cles, BTC adresse)

— Sauvegarde du seed/mnemonic code (wallet papier)

— Sauvegarde locale/distante des cles (fichier)

— Authentification aupres d’un service tiers

— Chiffrer le fichier resultant de la sauvegarde

— Acces a la cle privee/seed protege

— Services de validation des transactions (SPV)

— Ordre de paiement par NFC, BT

— Rotation d’adresse

6.1.1 Remarques

La sauvegarde locale ou distante des cles s’adresse aux wallets qui n’utilisent pas de seed pourgenerer les cles. Cette fonctionnalite implique que le resultat du backup soit chiffre et que si le backups’effectue sur un serveur distant, alors une authentification aupres du service tiers est requise.

6.1.2 Acteurs

Utilisateur Ce profil correspond a tous les utilisateurs qui utilisent Bitcoin comme moyen depaiement. La simplicite des paiements s’adresse a un public tres large. En effet, iln’est pas necessaire de connaıtre et de comprendre tous les concepts.

Service tiers Certains services proposes par des wallets necessitent de faire confiance a un tiers.Les fonctionnalites de backup distant ou de gestion de comptes en ligne sont de bonsexemples faisant intervenir un service tiers, auquel on doit accorder sa confiance.

Mineur Les mineurs font partie du reseau Bitcoin. Ils recoivent les transactions, les regroupentet tentent de valider le block.

Full node Les full nodes font egalement partie du reseau BC. Ils sont necessaires a la verificationdes transactions grace a la methode SPV.


6.1.3 Cas d’utilisation

Les cas d’utilisations permettent de comprendre le fonctionnement de l’application, de lister lesfonctionnalites et les acteurs.

Figure 6.1 – Cas d’utilisation d’un wallet generique


6.1.3.1 Details des cas d’utilisations

Cas 1. Creer un wallet BTCActeur(s) Utilisateur du walletDescription Lors de la premiere execution, le wallet genere une paire de cles et une adresse

BTC. Si c’est un HD wallet, un seed est utilise pour generer les cles.Pre-conditions Aucune

Cas 2. (De)chiffrer un walletActeur(s) Utilisateur du walletDescription Le wallet contient la cle privee qui doit rester secrete. Il est important de chiffrer

le contenu du backup pour que personne n’y ait acces. La confidentialite desdonnees est garantie par un chiffrement symetrique. L’utilisateur entre un motde passe pour dechiffrer sa cle privee.

Pre-conditions Posseder un wallet, mot de passe definit

Cas 3. Sauvegarder un walletActeur(s) Utilisateur du walletDescription La sauvegarde du wallet evite la perte des cles.Pre-conditions Posseder un wallet

Cas 3.1 Sauvegarder un HD walletActeur(s) Utilisateur du walletDescription La sauvegarde d’un HD wallet consite a recopier les douze mots en anglais

(code Mnemonic). L’application demande a l’utilisateur de completer la listedes douze mots. Cette etape permet de verifier que l’utilisateur a recopie lesmots correctement.

Pre-conditions Posseder un HD wallet

Cas 3.2 Sauvegarder un wallet non deterministeActeur(s) Utilisateur du walletDescription La sauvegarde d’un wallet non deterministe genere un fichier contenant les cles.Pre-conditions Posseder un wallet

Cas 3.3 Stocker localementActeur(s) Utilisateur du walletDescription Les wallets non deterministes sont sauvegardes sur le mobile. Le fichier de la

sauvegarde est chiffre.Pre-conditions Posseder un wallet non deterministe, avoir chiffre le wallet

Cas 3.4 Stocker a distanceActeur(s) Utilisateur du wallet, service tiersDescription Les wallets non deterministes sont sauvegardes sur un serveur distant. Le fichier

de la sauvegarde est chiffre.Pre-conditions Posseder un wallet non deterministe, avoir chiffre le wallet, etre authentifie

aupres du service tiers.


Cas 4. Creer une transactionActeur(s) Utilisateur du walletDescription L’utilisateur cree une nouvelle transaction. Il entre l’adresse BTC du destina-

taire, le montant et les frais de transaction.Pour effectuer une transaction, il est necessaire de specifier au minimuml’adresse Bitcoin du destinataire et le montant de la transaction. Des fraisde transaction peuvent etre ajoutes pour remunerer les mineurs.

Pre-conditions Posseder un wallet, posseder des BTC

Cas 4.1 Signer une transactionActeur(s) Utilisateur du walletDescription Pour qu’une transaction soit prise en charge par le reseau de mineur, elle doit

etre signee. La transaction est signee a l’aide de la cle privee de l’utilisateur.Pre-conditions Posseder un wallet, avoir effectue une transaction, avoir dechiffre la cle privee

Cas 4.2 Envoyer une transactionActeur(s) Utilisateur du wallet, reseau de mineursDescription Pour valider la transaction, il est necessaire de l’envoyer au reseau de mineurs.

Une fois validee, elle integrera la blockchain.Pre-conditions Posseder un wallet, avoir effectue une transaction, avoir chiffre la cle privee,

avoir signe la transaction

Cas 5. Demande de paiementActeur(s) Utilisateur du walletDescription L’utilisateur genere une demande de paiement pour son client qui se trouve

dans la meme salle. La demande de paiement necessite de fixer un montant.Pre-conditions Posseder un wallet

Cas 5.1 Ordre de paiement via QR CodeActeur(s) Utilisateur du walletDescription L’utilisateur peut transmettre la demande de paiement a son client via un QR

Code. Le QR Code contient le montant et l’adresse Bitcoin du destinataire.Pre-conditions Posseder un wallet, avoir effectue une demande de paiement

Cas 5.2 Ordre de paiement via NFCActeur(s) Utilisateur du walletDescription L’utilisateur peut transmettre la demande de paiement a son client via NFC.

Les donnees transmises sont le montant et l’adresse Bitcoin du destinataire.Pre-conditions Posseder un wallet, avoir effectue une demande de paiement, mobile compta-

tible avec NFC

Cas 6. Rotation de l’adresse BTCActeur(s) Utilisateur du walletDescription A chaque transaction effectuee ou recue, le wallet change d’adresse. La rotation

d’adresse protege l’utilisateur dans le cas ou ces transactions sont tracees.Pre-conditions Posseder un wallet, avoir effectue ou recu une transaction


Cas 7. Calculer le solde du compte (SPV)Acteur(s) Utilisateur du wallet, service tiersDescription Le solde du compte est constamment affiche et rafraıchi dynamiquement sans

que l’utilisateur en fasse la demande. La verification des paiements au traversde la blockchain permet d’evaluer le solde d’un compte. Ce dernier s’effectuevia la methode SPV.

Pre-conditions Posseder un wallet, etre connecte a un full node

Cas 8. Taux de changeActeur(s) Utilisateur du walletDescription Le taux de change du Bitcoin en une devise standard est disponible sur l’ap-

plication a titre informatif. Le Bitcoin est une devise volatile. C’est pourquoiun taux de rafraıchissement est specifie. Les donnees sont rapatriees depuis uneAPI d’un service tiers.

Pre-conditions Connexion a Internet

Cas 9. Achat de BTCActeur(s) Utilisateur du walletDescription Certains wallets offrent la possibilite d’acheter des Bitcoins. Dans la majorite

des cas, le wallet redirige l’utilisateur sur une page Internet. L’achat de BTCs’effectue par carte de credit.

Pre-conditions Posseder un wallet, connexion a Internet

Cas 10. Authentification service tiersActeur(s) Utilisateur du wallet, service tiersDescription Certains wallets proposent de sauvegarder les cles sur un serveur distant. L’uti-

lisateur doit s’authentifier aupres du service tier.Pre-conditions Connexion a Internet


6.1.4 Actifs

Les actifs d’un wallet Bitcoin representent les informations qui doivent etre protegees. Cetteetape decrit leurs caracteristiques, leurs qualites et leurs valeurs, afin de mieux evaluer par la suiteles differentes menaces.

Paire(s) de cles (Bitcoin)

La paire de cles contient une cle publique et une cle privee. La cle privee ne doit pas etrepartagee, car elle atteste de la possession des Bitcoins. Les cles sont des nombres aleatoires sur256-bits et sont representees en base58.

Credential service tiers

Le nom d’utilisateur et le mot de passe d’un service tiers permettent de s’authentifier de maniereunique. Les fonctionnalites varient, generalement le compte est utilise pour sauvegarder sonwallet ou acceder a un wallet en ligne.

Informations bancaires

Certains wallets offrent la possibilite d’echanger des Bitcoins contre une devise standard. Lesinformations bancaires sont donc necessaires pour transferer les fonds. Dans la majorite descas, l’application redirige l’utilisateur sur une page Internet.

Mot de passe/PIN

Une grande partie des wallets protege l’acces a l’application par PIN ou mot de passe. En plusde proteger l’acces, ce secret chiffre les donnees a l’aide d’un algorithme symetrique. De cettefacon, les donnees ne sont plus accessibles en claire dans la memoire. Une copie hashee duPIN/mot de passe est stockee sur le mobile.


6.1.5 Sources de menaces

Organisation criminelle

Bitcoin est une solution attractive pour les organisations criminelles, car elle s’affranchit desinstitutions bancaires, rend difficile de traquer les transactions et elle garantit dans une certainemesure l’anonymat. Ces organisations utilisent Bitcoin entre autres pour blanchir de l’argent,vendre des produits illegaux ou encore pour des demandes de rancons, etc.

Motivation(s) : Recuperation d’informations, finances, acces permanent au systemeCible(s) : Tous les actifsProbabilite : Haute

Cybercriminel

Ce profil est similaire a une organisation criminelle, excepte qu’il est a plus petite echelle commecelle d’un petit groupe d’individus par exemple. Le vol de wallets Bitcoin est une pratiquerepandue et les attaques realisees sont plus elaborees et avancees.

Motivation(s) : Recuperation d’informations, finances, acces permanent au systemeCible(s) : Tous les actifsProbabilite : Haute

Gouvernement

Les systemes de paiement decentralises ont force les gouvernements a encadrer leurs utilisations,voire a les interdire. Il est dans leur interet de surveiller les utilisateurs des marches noirs. Lesgouvernements possedent enormement de ressources et leur objectif principal est d’obtenir desinformations dans le but de taxer les utilisateurs et de surveiller des reseaux criminels.

Motivation(s) : Recuperation d’informations, acces permanent au systemeCible(s) : Tous les actifsProbabilite : Moyenne

Developpeur malveillant

Ce profil regroupe toutes les personnes qui ont de solides connaissances du protocole Bitcoinet en programmation. Ils partagent ou ameliorent des solutions au sein de la communaute.

Motivation(s) : Recuperation d’informations, finances, acces permanent au systemeCible(s) : Tous les actifsProbabilite : Moyenne

Ami/Collegue

Lorsqu’on laisse son smartphone sans surveillance, un ami ou un collegue mal intentionne peuteffectuer une transaction ou derober la cle privee, ainsi que les credentials d’un service tiers oudes informations bancaires.

Motivation(s) : Jalousie, financesCible(s) : Paire(s) de cles (Bitcoins)Probabilite : Moyenne

Scipt kiddy

A l’aide des moteurs de recherche et d’un peu de motivation, on trouve facilement des attaquespretes a l’emploi. Ce profil regroupe les personnes qui n’ont pas de connaissances approfondiesen programmation. Un script kiddy tente generalement d’impressionner ces camarades ou des’amuser.

Motivation(s) : Gloire, entraınement, amusementCible(s) : Tous les actifsProbabilite : Faible


Figure 6.2 – Source de menaces, motivation et cibles


6.1.6 Data Flow Diagram

Le DFD represente les flux de donnees transitant par le systeme, donne un apercu de celui-ci etdu traitement des donnees.

Figure 6.3 – DFD


6.2 Scenarios d’attaques

Divers scenarios d’attaques ont ete elabores et analyses en details. Chaque scenario se base sur desfailles potentielles et permet de lister toutes les contre-mesures necessaires. Un scenario d’attaquea pour objectif d’expliquer la marche a suivre d’un attaquant. L’elaboration des scenarios aide amieux comprendre les vecteurs d’attaques, leur impact, les sources de menaces, leur motivation etles actifs cibles. Chaque scenario presente les failles potentielles, les enjeux et propose une strategiede mitigation. Ils sont classes en trois categories distinctes selon la surface d’attaque ciblee : clientlocal, service tiers, developpeurs. Cette etape regroupe les parties suivantes :

L’identification des scenarios de menaces donne une vue d’ensemble des menaces.

L’identification des risques determine les consequences des menaces mises en avant.

L’analyse de risques attribue des scores aux menaces, basees sur une mesure qualitative de l’am-pleur de l’impact. Ce score permet de classer les risques par criticite.

6.2.1 Criteres de mesure de l’impact

La premiere etape est d’etablir une liste de zone d’impact. Elle est classee par ordre de priorite.

1. Finances : vol des Bitcoin en possession d’un utilisateur

2. Reputation : la publication de l’historique de transactions

3. Productivite : l’indisponibilite du service

Le tableau ci-dessous represente le bareme qui mesure l’impact de la menace. Le nombre d’utili-sateurs touches influence sur la categorie de l’impact.

Categorie Low Medium HighNombre d’utilisateurs touches groupe n personnes Tous les utilisateurs (Android)

6.2. SCENARIOS D’ATTAQUES 57

6.2.2 Client local

A - Acces physique au mobile

Aujourd’hui les smartphones suivent leur proprietaire partout ou ils vont, renfermant toutes leursdonnees et applications. La vie privee est entierement digitalisee et a portee de main en quelquessecondes. Il est si facile malheureusement de l’oublier sur le bureau pendant la pause cafe, de leperdre ou meme de se le faire voler. Le controle d’acces sous forme de PIN, passphrase ou em-preinte biometrique permet d’authentifier l’utilisateur. L’acces est garanti pendant une duree limitee.Scenario : Votre collegue de travail jaloux de vos gains, grace a la prise de valeur du

Bitcoin, s’empare discretement de votre smartphone abandonne pendant lapause cafe. Si le smartphone ne necessite pas de PIN ou est deverrouille etque vous etes authentifie, ce meme collegue peut effectuer un versement surson compte. Dans le cas contraire, votre collegue cherche et trouve un scriptcapable de bruteforcer le PIN de l’application.

Cible(s) : Tous les actifsSource(s) de menaces : Ami/collegue, cybercriminel, script kiddyMoyen(s) : Session active, bruteforce, aucune protection d’accesMotivation(s) : Finances, jalousieConsequence(s) : L’attaquant peut utiliser les Bitcoins de la cible.Categorie(s) : Spoofing, Information disclosureProbabilite : MediumImpact : LowMitigation(s) : Forcer un mode de deverrouillage du systeme

Proteger l’acces a l’applicationProteger les actions sensiblesTenir le systeme et les applications a jourPolitique des mots de passePolitique anti-BruteforceLimiter la duree de vie d’une session

B - Acces au systeme

Alors que les applications ne sont que la pointe visible de l’iceberg, le systeme d’exploitationrepresente une surface d’attaque encore plus considerable. Une vulnerabilite sur le systeme d’exploi-tation permet a un attaquant d’obtenir des droits en lecture, en ecriture et en execution.Scenario : Un hacker exploite une vulnerabilite d’Android et accede ainsi au systeme en

lecture, ecriture et en execution.Cible(s) : Tous les actifsSource(s) de menaces : Cybercriminel, organisation criminelle, gouvernementMoyen(s) : Exploitation des vulnerabilites d’AndroidMotivation(s) : Finances, acces permanent au systeme, recuperation d’informationsConsequence(s) : L’attaquant obtient un acces en lecture, en ecriture et en execution. Il peut donc

modifier, ou derober le systeme a sa guise et executer des codes malveillants.Categorie(s) : Tampering, Information disclosure, Elevation of privilegeProbabilite : MediumImpact : HighMitigation(s) : Tenir le systeme et les applications a jour

Chiffrer l’appareilChiffrer les donnees sensibles


C - Infecter l’environnement par un malware

Un malware peut prendre differentes formes : virus, vers et chevaux de Troie. En generalisant, c’esten fait un petit programme malveillant qui nuit au systeme. Il est capable de voler des informations,de se diffuser et/ou de rendre le systeme inutilisable. Dans la majorite des cas le social engineeringest le vecteur d’attaque.Scenario : Un hacker projette de voler des Bitcoins ou toutes autres informations dispo-

nibles sur les wallets mobiles. Ayant de bonnes connaissances en programma-tion, il developpe un code permettant de fouiller dans la memoire d’un smart-phone et d’envoyer toute information interessante a un serveur distant. Etantdonne qu’il est difficile d’exploiter directement une faille du systeme, le hackermet en place un piege. Il se sert du social engineering pour que la victime cliquesur un lien qui installera le malware.

Cible(s) : Tous les actifsSource(s) de menaces : Cybercriminel, organisation criminelle, gouvernement, script kiddyMoyen(s) : Social engineeringMotivation(s) : Finances, recuperation d’informations, gloireConsequence(s) : Vol des Bitcoins et des donnees de la cible, acces au systemeCategorie(s) Spoofing, Tampering, Information disclosureProbabilite : HighImpact : HighMitigation(s) : Tenir le systeme et les applications a jour

Informer l’utilisateur des menacesChiffrer les donnees sensiblesChiffrer l’appareilInstaller un anti-malware

D - Compromettre la generation des cles

La generation d’une paire de cles s’appuie sur des nombres aleatoires pour garantir une securitemaximale. S’il est possible d’etablir un lien entre ces nombres generes, il est aussi possible de prevoirles cles de chiffrement. Dans ce cas, un attaquant pourra utiliser la cle privee de la victime poursigner des transactions.Scenario : Un hacker planifie de compromettre la generation de la paire de cles, ainsi il

pourra utiliser les Bitcoins de sa victime. Ayant reussi a acceder au systeme desa victime via l’exploitation d’une faille Android ou via l’infection du mobilepar un malware, il definit le seed utilise lors de la generation des nombresaleatoires. De cette facon, il rend la generation de la paire de cles predictible.

Cible(s) : Paires de clesSource(s) de menaces : Cybercriminel, organisation criminelle, developpeursMoyen(s) : Acces au systeme (scenario A) pour definir un seed utilise lors de la generation

aleatoire.Motivation(s) : FinancesConsequence(s) : Vol de Bitcoins de la cible : l’attaquant predit les paires de cles utilisees.Categorie(s) : Spoofing, TamperingProbabilite : LowImpact : MediumMitigation(s) : Choix/implementation d’un algorithme de chiffrement en accord avec les

bonnes pratiques.Seed genere de maniere aleatoire et non deterministe.


E - Exploiter l’algorithme de chiffrement des cles privees

La cle privee ne peut etre stockee en clair dans la memoire, il est necessaire de la chiffrer afin degarantir la confidentialite. Toute personne ne possedant pas la cle de dechiffrement ne peut pas lire lecontenu du message, meme si celui-ci est intercepte. Cependant, tous les algorithmes de chiffrementne sont pas consideres comme surs et certains peuvent meme etre facilement casses. Meme si unminimum de recherche permet de choisir un algorithme offrant un niveau correct de securite, laphase la plus critique est celle de l’implementation. Un grand nombre de vulnerabilites peut etreintroduit durant cette phase.Scenario : Un hacker en analysant le code source se rend compte que l’algorithme de

chiffrement utilise pour chiffrer les cles privees n’est pas standard, qu’il se basesur des librairies depassees et/ou qu’il n’est pas implemente correctement. Il sesert donc de ces vulnerabilites pour casser le chiffrement.

Cible(s) : Cle priveeSource(s) de menaces : Cybercriminel, organisation criminelleMoyen(s) : Acces au systeme (scenario A), analyser et exploiter les vulnerabilites (algo-

rithme mal implemente, algorithme non standard).Motivation(s) : FinancesConsequence(s) : L’attaquant possede un acces aux donnees sensibles meme chiffrees.Categorie(s) Spoofing, Information disclosureProbabilite : MediumImpact : MediumMitigation(s) : Choix/implementation d’un algorithme de chiffrement en accord avec les

bonnes pratiques.Seed genere de maniere aleatoire et non deterministe.

6.2.3 Service tiers

F - Recuperation d’un mot de passe

L’authentification permet au systeme de savoir si oui ou non la demande d’acces est legitime.C’est-a-dire de s’assurer que l’utilisateur est bien la personne qu’il pretend etre et qu’il possede lesautorisations necessaires pour acceder a l’information. La forme d’authentification la plus couranteest la combinaison d’un nom d’utilisateur et d’un mot de passe sous la forme d’une page de login.Scenario : Un hacker se rend compte que le wallet necessite d’etre authentifie aupres d’un

service tiers. Il sait que la majorite des utilisateurs utilise des mots de passefaibles, facilement predictibles. Dans un grand jour de chance, il trouve le motde passe d’un utilisateur et peut donc acceder a son compte.

Cible(s) : Tous les actifsSource(s) de menaces : Script kiddy, cybercriminel, organisation criminelleMoyen(s) : Mot de passe faible, brute-force, vulnerabilites du controle d’acces, duree de

vie de la session inadequate, intercepter une communicationMotivation(s) : FinancesConsequence(s) : L’attaquant possede les credentials de l’utilisateur. Il peut usurper l’identite de

la victime et realiser des actions aupres du service tiers.Categorie(s) Spoofing, Information disclosureProbabilite : HighImpact : MediumMitigation(s) : Politique des mots de passe.

Politique anti-Bruteforce.Limiter la duree de vie d’une session.Proteger les communications avec TLS.


G - Attaque par deni de service

Ce type d’attaque est un grand classique facilement realisable. L’objectif est de rendre un serviceindisponible par le biais d’un trop grand nombre de requetes jusqu’a ce que la cible soit saturee. Leprobleme majeur de ce type d’attaque est qu’il est difficile de s’en proteger entierement.Scenario : Un attaquant se rend compte qu’un des services tiers est indispensable au bon

fonctionnement de l’application. Il decide donc de prendre en otage le serviceen le rendant indisponible jusqu’a la reception de la rancon.

Cible(s) : Disponibilite/Fonctionnement de l’applicationSource(s) de menaces : Script kiddy, cybercriminel, organisation criminelleMoyen(s) : Envoyer un grand nombre de requetesMotivation(s) : Finances, gloire, ternir l’image de l’entreprise, vengeanceConsequence(s) : Le service tiers est indisponible. Cela peut alterer le fonctionnement de l’appli-

cation.Categorie(s) Denial of serviceProbabilite : HighImpact : MediumMitigation : Politique anti-DDoS

H - Intercepter les communications

L’information transitant sur le reseau passe par plusieurs intermediaires et sous differentes formes.Sur un reseau wi-fi par exemple, il est facile de voir le trafic et de l’intercepter. C’est pourquoi ilest essentiel que les communications se fassent de maniere chiffree. Cependant certaines attaques detype man in the middle contournent cette mesure. L’objectif de ce type d’attaque est de se placer enintermediaire de la communication. L’intermediaire se fait en realite passer pour le serveur aupresdu client et pour le client aupres du serveur.Scenario : Un attaquant conscient des vulnerabilites des reseaux sans fil propose un point

d’acces identique a celui de Starbucks, par exemple. Il configure un proxy, luipermettant d’intercepter tout le trafic, meme chiffre. Il attend ensuite que savictime se connecte au reseau et interagisse avec le service tiers.

Cible(s) : Tous les actifsSource(s) de menaces : Cybercriminel, organisation criminelleMoyen(s) : Man in the middle, proxy, wi-fi non securiseMotivation : FinancesConsequence(s) : L’attaquant intercepte et recupere toutes les informations en clair.Categorie(s) : Spoofing, Information disclosureProbabilite : MediumImpact : MediumMitigation(s) : Authentification plus stricte entre les 2 entites

Proteger les communications avec TLSInformer l’utilisateur des menaces


I - Faux service tiers

L’usurpation d’identite est une pratique courante. L’objectif est de se faire passer pour un autreclient ou serveur du reseau afin de voler des donnees, de contourner des controles d’acces ou d’installerdes codes malveillants.Scenario : Un hacker propose un point d’acces gratuit. Il redirige toutes les requetes du

client au service tiers sur son serveur.Cible(s) : Tous les actifsSource(s) de menaces : Cybercriminel, organisation criminelleMoyen(s) Usurpation IP, DNS, redirection de trafic dans un reseau WifiMotivation(s) : FinancesConsequence(s) : L’attaquant reussi a installer un client malveillant sur le mobile de la cible.Categorie(s) : Spoofing, Information disclosureProbabilite : MediumImpact : MediumMitigation : Authentification plus stricte entre les 2 entites

Verifier les certificatsRestreindre les CAsCertificate pinning

J - Faux certificat d’autorite de certification (CA)

Les algorithmes de chiffrement asymetriques utilisent une paire de cles pour chiffrer ou dechiffrerles donnees. La cle publique est utilisee lors de l’etape de chiffrement, mais rien ne garantit que cettecle appartienne effectivement au destinataire. L’utilisation d’un certificat permet de prevenir ce genrede situation. Il permet d’attester que la cle publique appartient bien a M. Dupont par exemple. Uneautorite de certification se charge de delivrer ces certificats. Ceux-ci comportent une date de validiteet une date de revocation.Scenario : Une organisation criminelle souhaite derober des Bitcoins a grande echelle.

L’organisation dispose de beaucoup de fonds et peut donc se permettre d’ache-ter un certificat. A l’aide du certificat, les attaquants peuvent dechiffrer toutle trafic.

Cible(s) : Tous les actifsSource(s) de menaces : Cybercriminel, organisation criminelle, gouvernementMoyen(s) : Creer ou un acheter un CA pour contourner le chiffrement. Installer le CA sur

le mobile via un malware.Motivation(s) : FinancesConsequence(s) : Le trafic est dechiffre. Des attaques de types man in the middle sont possibles.Categorie(s) : Spoofing, Information disclosureProbabilite : MediumImpact : HighMitigation(s) : Restreindre les CAs

Verifier les certificatsCertificate pinning


K - Vol d’un backup distant

Une fois de plus, les smartphones sont fortement exposes aux vols et aux pertes. Rappelons-nousque lorsqu’on perd sa paire de cles, on perd ses Bitcoins. Il est donc indispensable d’effectuer dessauvegardes de la paire de cles. Bien que les HD wallets ne proposent pas cette fonctionnalite, certainswallets plus anciens la necessitent. Ce qui souleve une nouvelle problematique : est-ce que le servicetiers est capable de proteger les donnees ?Scenario : Un hacker souhaite effectuer une attaque a grande echelle. Intrigue par la fonc-

tionnalite de sauvegarde, il se rend compte que les backups sont stockes sur unserveur distant. En analysant la securite de l’infrastructure du service tiers, ildecouvre une vulnerabilite exploitable. Il derobe tous les backups des clients.

Cible(s) : Paire de clesSource(s) de menaces : Cybercriminel, organisation criminelleMoyen(s) : Exploiter les vulnerabilites du service tiers, intercepter les communicationsMotivation(s) : FinancesConsequence(s) : L’attaquant peut utiliser les Bitcoins de la cible.Categorie(s) : Spoofing, Tampering, Information disclosure, Elevation of privilegeProbabilite : LowImpact : MediumMitigation(s) : Chiffrer les sauvegardes.

Politique des mots de passeProteger les communications avec TLSChoix/implementation d’un algorithme de chiffrement en accord avec lesbonnes pratiques

6.2.4 Developpeurs

L - Ajout du code malveillant

Les clients utilisent des wallets Bitcoin et accordent leur confiance aux developpeurs de l’applica-tion. En quelques lignes de codes seulement, un developpeur mal intentionne est capable de recuperertoutes les paires de cles. Il est egalement possible qu’un developpeur soit paye pour introduire unevulnerabilite dite backdoor. L’interface graphique, apres une mise a jour, peut rester inchangee, c’estpourquoi il est impossible pour un utilisateur - sans consulter le code - de savoir ce qui a ete change.Comme vue dans la partie 4.5.5 la mise a jour, ayant lieu apres la validation par l’organisationBitcoin, sera acceptee par tous les smartphones.Scenario : Un developpeur proche de la retraite a des problemes financiers. Il se fait ap-

procher par une organisation criminelle qui lui propose une somme enorme enechange d’une backdoor dans le code. Pour resoudre ses problemes financiers,le developpeur accepte et integre la backdoor dans le code.

Cible(s) : Tous les actifsSource(s) de menaces : Cybercriminel, organisation criminelle, concurrent, gouvernementMoyen(s) : Ajout d’une backdoor ou du code malveillantMotivation(s) : Finances, recuperation d’informations, vengeanceConsequence Le wallet est distribue alors qu’il contient du code malveillant (backdoor)Categorie(s) : Spoofing, Tampering, Information disclosure, Elevation of privilegeProbabilite : LowImpact : MediumMitigation(s) : Code source disponible


M - Clone malveillant

Pour instaurer un climat de confiance, les developpeurs mettent a disposition leurs codes sources.Ils sont disponibles en lecture a tout le monde, ce qui permet de les analyser. Avec quelques no-tions de programmation, il est possible de compiler l’application soi-meme et d’y ajouter d’autresfonctionnalites voire meme des codes malveillants.Scenario : Un developpeur mal intentionne recupere le code source d’un wallet Bitcoin. Il

modifie quelques lignes, lui permettant de recuperer les paires de cles a chaquenouvelle transaction. Il spoof le site web officiel du wallet afin que les utilisateurstelechargent le clone malveillant

Cible(s) : Tous les actifsSource(s) de menaces : Developpeur, cybercriminel, organisation criminelleMoyen(s) : Clone malveillant propose sur un site web spoofe.Motivation(s) : FinancesConsequence(s) : L’attaquant peut utiliser les Bitcoins de la cible et a acces a toutes les infor-

mationsCategorie(s) Information disclosureProbabilite : HighImpact : MediumMitigation : Installer l’application uniquement depuis une source sure

Informer l’utilisateur des menaces.


6.2.5 Priorisation des menaces

Les menaces sont presentees sous format matriciel afin que leurs priorisations soient instinctifs.Ainsi, il est possible d’appliquer une strategie de mitigations dans un ordre chronologique selon lacriticite des risques.

Figure 6.4 – Matrice de criticite

Le tableau suivant propose une strategie de mitigation. Les scenarios sont classes et regroupespar criticite decroissante.

Scenario ID MitigationsC Tenir le systeme et les applications a jour

Informer l’utilisateur des menacesChiffrer les donnees sensiblesChiffrer l’appareilInstaller un anti-malware

B, F, G, J, M Politique des mots de passePolitique anti-BruteforceLimiter la duree de vie d’une sessionProteger les communications avec TLSPolitique anti-DDoSInstallation uniquement depuis une source sureVerifier les certificatsRestreindre les CAsCertificate pinning

E, H, I Choix/implementation d’un algorithme de chiffrement en accord avec les bonnes pratiquesSeed genere de maniere aleatoire et non deterministeAuthentification plus stricte entre les 2 entites

A, D, K, L Forcer un mode de deverrouillage du systemeProteger l’acces a l’applicationProteger les actions sensiblesChiffrer les sauvegardesCode source disponible

6.3. MESURES SECURITAIRES 65

6.3 Mesures securitaires

Cette partie consigne les resultats du modele de menaces. La methodologie se base exclusivementsur les actifs primordiaux au bon fonctionnement d’un wallet Bitcoin Android. Les contre-mesuressont classees selon les categories de la checklist. Cette categorisation permet ensuite de cibler lesmesures securitaires associees aux menaces et de ne garder ainsi que les points les plus importantsde la checklist de l’OWASP. Le tableau ci-dessous enumere toutes les mesures securitaires associeesaux scenarios.

Mesures securitaires ID scenario1. Chiffrer les donnees sensibles B, C2. Chiffrer les sauvegardes K3. Choix/implementation d’un algorithme de chiffrement en ac-cord avec les bonnes pratiques

D, E, K

4. Seed genere de maniere aleatoire et non deterministe D, E5. Forcer un mode de deverrouillage du systeme A6. Proteger l’acces a l’application A7. Proteger les actions sensibles A8. Politique anti-Bruteforce A, F9. Limiter la duree de vie d’une session A. F10. Proteger les communications avec TLS F, H, K11. Verifier les certificats I, J12. Restreindre les CAs I, J13. Certificate Pinning I, J14. Configuration SSL stricte du serveur H, I15. Tenir le systeme et les applications a jour A, B, C16. Politique des mots de passe A, F, K17. Installer l’application uniquement depuis une source sure M18. Chiffrer l’appareil B, C19. Politique anti-DDoS G20. Installer un anti-malware C21. Informer l’utilisateur des menaces C, H, M22. Code source disponible L

6.3.1 Stockage de donnees et confidentialite

6.3.1.1 Chiffrer les donnees sensibles

Les donnees sensibles, telles que les cles privees, credentials,le PIN/mot de passe et lesinformations bancaires doivent etre stockees d’une maniere securisee. Elles ne doivent pas etreen clair dans la memoire. C’est pourquoi il est necessaire de les chiffrer. Ainsi, meme si elles sontderobees, il sera difficile de les exploiter.

6.3.1.2 Chiffrer les sauvegardes

Dans un systeme decentralise, les responsabilites deleguees a l’utilisateur incluent la sauvegardedes cles privees. En cas de perte ou de vol du smartphone, il est impossible de recuperer ces Bitcoinsa moins de posseder une sauvegarde. Une fois chiffre, le resultat de la sauvegarde doit etre stocke surun autre appareil/disque dur externe. Certains wallets proposent d’effectuer des sauvegardes sur un


serveur distant. Si l’utilisateur profite de cette fonctionnalite, il doit s’assurer que les donnees soienteffectivement chiffrees correctement.

6.3.2 Cryptographie

6.3.2.1 Choix/implementation d’un algorithme de chiffrement en accord avec les bonnespratiques

A moins d’etre un expert en cryptographie, il est deconseille d’implementer soit meme un algo-rithme. Premierement, car si l’algorithme est trop faible, il peut etre casse facilement. Deuxiemement,car lors de l’implementation des vulnerabilites peuvent etre introduites. Il est recommande d’utiliserdes librairies standards, des algorithmes cryptographiquement surs et de suivre les bonnes pratiques.

6.3.2.2 Seed genere de maniere aleatoire et non deterministe

Les machines actuelles qu’il s’aggise d’un ordinateur, d’un smartphone ou d’un Raspberry PI,sont incapables de produire une veritable sequence de nombres aleatoires. Lorsqu’ils generent demaniere standard un nombre au hasard, la valeur est predictible. Cet aspect est incompatible avec lesconcepts cryptographiques et de ce fait avec la securite. Il est donc necessaire d’utiliser un generateurde nombres pseudo-aleatoires cryptographiques consideres comme sur. L’exemple ci-dessous est tirede la documentation de l’OWASP.

1 public static int generateRandom(int maximumValue)

2 SecureRandom ranGen = new SecureRandom ();

3 return ranGen.nextInt(maximumValue);

4

Lors de la generation des cles, on utilise une sequence aleatoire. Les cles generees servent ensuite achiffrer des donnees. Il est donc primordial pour garantir la confidentialite de generer des nombresaleatoires et non deterministes.

6.3.3 Authentification et gestion de session

6.3.3.1 Verification des entrees utilisateurs et validation cote serveur

Tous les formulaires ou entrees utilisateurs doivent etre verifiees et validees du cote du serveur.Evidemment, un controle doit etre effectue en local, mais seul le serveur a le droit de valider lesdonnees. Ainsi, l’authentification aupres d’un service tiers - si necessaire - s’effectue du cote duserveur.

6.3.3.2 Forcer un mode de deverrouillage du systeme

Pour augmenter le niveau de securite globale, l’application doit verifier si un mode de deverrouillagedu systeme est active. Dans le cas contraire, elle ne doit pas s’executer. Cette contre-mesure permetde se premunir contre l’utilisation du smartphone par une personne non autorisee.

6.3.3.3 Proteger l’acces a l’application

Seul le proprietaire du wallet a le droit d’acceder a son wallet. C’est pourquoi, l’application doitmettre en place un systeme d’authentification par mot de passe. De plus, cette derniere permet de

https://www.owasp.org/index.php/Insecure_Randomness


chiffrer les donnees sensibles disponibles en memoire (cles privees, crendentials, PIN/mot de passe,etc.).

6.3.3.4 Proteger les actions sensibles

Certaines actions sensibles comme l’envoi d’une transaction, la consultation de cles privees, lasauvegarde ou la restauration doivent etre protegees. Pour se premunir des utilisateurs non legitimes,mais aussi des erreurs humaines.

6.3.3.5 Politique anti-Bruteforce

En plus d’appliquer une bonne politique de mot de passe, il est possible de mitiger les attaquesde bruteforce en profondeur. Que ce soit lors de l’authentification local ou distante, un nombremaximum de tentatives peut etre fixe. Une fois atteint, le compte est bloque pendant une dureedeterminee. Celle-ci est variable. Elle peut etre augmentee voire indeterminee pour bloquer le walletcompletement selon le niveau de securite souhaite.

Une solution efficace pour les connexions a un service distant est l’utilisation d’un captchas. Cettemitigation supplementaire verifie que c’est bien un humain qui essaie de se connecter. Si le niveaude securite n’est toujours pas satisfaisant, on peut mettre en place une authentification a 2 facteurs.

6.3.3.6 Limiter la duree de vie d’une session

Apres son authentification sur un service distant ou en local, l’utilisateur obtient un droit d’acces/desession lui permettant d’acceder a un systeme ou a un service. Ce droit ne doit pas etre infini dans letemps, il est recommande de fixer une duree de vie. Celle-ci depend des informations et des actionsdont l’utilisateur a besoin. Il faut cependant trouver un juste milieu ; si la duree de vie est tropcourte, l’utilisateur devra s’authentifier plusieurs fois par jour. Dans le cas contraire, l’inattentiond’un utilisateur, qui quitte son bureau sans verrouiller sa session, permettrait a un collegue, parexemple d’acceder a son compte durant son absence.

6.3.4 Communication reseau

6.3.4.1 Proteger les communications avec TLS

Pour des raisons de confidentialite, les trames ne peuvent pas circuler en clair. Avec les techno-logies sans fil, il est tres facile de sniffer le reseau et de capturer des trames, de les modifier et de lesrejouer. C’est pourquoi, il est indispensable de chiffrer toutes les communications a l’aide de SSL/TLSentre l’application et les services tiers (taux de change, achat de Bitcoins, sauvegarde distante).

6.3.4.2 Verifier les certificats

Lors d’une connexion securisee avec TLS, l’application doit verifier le certificat du serveur. S’ilne peut pas etre valide, alors l’interruption de la connexion est necessaire, car cela implique quel’identite du serveur n’est pas verifiable.

6.3.4.3 Restreindre les CAs

Les certificats fonctionnent selon une hierarchie, il suffit qu’une autorite de certification soitcompromise ou delivre un certificat par erreur pour briser la chaıne de confiance. Pour prevenir ce


genre de situation, il est possible de creer une liste d’autorites acceptees. Si le CA n’est pas dans laliste, la connexion est refusee.

6.3.4.4 Certificate Pinning

L’epinglage de certificats permet d’associer un nom de domaine a un certificat. De cette maniere,on limite les certificats possibles permettant de chiffrer la communication. Seul le ou les certificatsattendus seront acceptes.

6.3.5 Configuration SSL stricte du serveur

La configuration du server SSL doit suivre les bonnes pratiques. Il faut utiliser des protocolessurs (TLS 1.1 ou 1.2), des algorithmes de chiffrement surs (ECDSA,RSA), desactiver SSL v3 et larenegociation de la connexion initiee par le client.

6.3.6 Autres criteres

6.3.6.1 Tenir le systeme et les applications a jour

Tenir a jour son systeme ainsi que ses applications est essentiel afin de maintenir un bon niveaude securite. Chaque jour de nouvelles vulnerabilites sont decouvertes et necessitent d’etre corrigees.De plus, les mises a jour n’apportent pas que des correctifs de securite, elles introduisent aussi denouvelles fonctionnalites ou permettent de corriger des bugs. Il est conseille de mettre a jour lesysteme et les applications automatiquement. La procedure qui suit est tiree de la documentationofficielle d’Android.

Pour mettre a jour automatiquement les applications de votre appareil Android, procedez commesuit :

1. Ouvrez l’application Google Play Store.

2. Appuyez sur Menu puis Parametres.

3. Appuyez sur Mise a jour automatique des applis.

4. Selectionnez une option :

• Mettre a jour les applications a tout moment pour mettre a jour les applications viale Wi-Fi ou les donnees mobiles.

• Mettre a jour automatiquement les applications via Wi-Fi uniquement pour mettrea jour les applications uniquement lorsque vous etes connecte au Wi-Fi.

Remarque : Si un compte sur votre appareil presente une erreur de connexion, il est possibleque les applications ne soient pas mises a jour automatiquement.

6.3.6.2 Politique des mots de passe

Le mot de passe, suite de caracteres secrets, est un moyen d’identifier un utilisateur puisque lui seulconnaıt cette information. Lorsque l’utilisateur souhaite acceder a son compte, il doit s’authentifieren fournissant son nom d’utilisateur et son mot de passe. Les mots de passes font partie des donneessensibles et doivent repondre a certaines exigences.


Creation mot de passe En general, la longueur minimal requise est de 8 caracteres. La diversitedes caracteres utilisees est importante. Il est recommande de varier minuscules et majuscules etd’inserer des caracteres speciaux. Il est au contraire deconseille d’utiliser un PIN. Pour eviter lesattaques de brute-force, le mot de passe ne doit pas contenir de mot present dans le dictionnaire,ni de nom propre ou d’information personnelle. Afin de sensibiliser l’utilisateur, l’applicationinforme de la qualite du mot de passe lors de sa creation en evaluant sa fiabilite.

Periode de validite Pour des raisons de facilite de memorisation, on utilise generalement le mememot de passe pour plusieurs applications. Ce comportement est a proscrire, car si un de noscomptes est compromis, alors il faut changer de mot de passe sur tous les comptes. Une periodede validite force l’utilisateur a changer son mot de passe regulierement. Attention tout de memea ne pas creer une situation inverse : mot de passe ecrit sur un post-it, etc. Lorsque l’utilisateurest invite a changer de mot de passe, il vaut mieux eviter un choix trop proche du precedant.

Bonnes habitudes Il est bon de rappeler a l’utilisateur les bonnes pratiques, ci-dessous un extrait :

• Ne jamais partager un compte

• Ne jamais utiliser le meme mot de passe pour plusieurs comptes

• Ne jamais ecrire son mot de passe sur un post-it ou ailleurs

• Ne jamais communiquer son mot de passe a quelqu’un d’autre, meme aux charges de securite

6.3.6.3 Installer l’application uniquement depuis une source sure

Malheureusement, le maillon faible de la chaıne de securite est bien trop souvent l’utilisateur.Le social engineering est frequemment utilise pour berner une personne mal informee. Une attaquepeut etre mise en place afin que l’utilisateur clique sur un lien qui lui installe un clone malveillant.La seule contre-mesure possible est d’apprendre a l’utilisateur a ne pas installer des applications desource non-officielle ou de site douteux.

6.3.6.4 Chiffrer l’appareil

En cas de perte ou de vol du smartphone, le deverrouillage du systeme peut etre contourne.C’est pourquoi, il est recommande de chiffrer son telephone. Cependant cette contre-mesure ne peutpas etre consideree comme un critere d’evaluation, parce que c’est a l’utilisateur d’activer cettefonctionnalite.

6.3.6.5 Politique anti-DDoS

Les cibles d’une attaque par deni de services sont les services tiers : authentification, recuperationdes taux de change et serveur de mise a jour. Comme mentionne lors du scenario d’attaque as-socie, se proteger completement d’une attaque par deni de service est difficile si l’attaquant possedeenormement de ressources. Neanmoins certaines contre-mesures permettent de diminuer ce risque.Premierement, il est possible de controler les IP lors des connections et de les bloquer si un seuillimite est atteint. Deuxiemement, il est aussi possible de filtrer le trafic, notamment les requetesICMP afin de mitiger les attaques de type smurf attack. Troisiemement, au lieu d’exposer les ser-veurs directement sur le web, il est possible des les cacher derriere un reverse proxy. Ou alors, lasolution peut etre hebergee chez un prestataire de service afin d’activer l’autoscaling.


6.3.6.6 Installer un anti-malware

Les logiciels malveillants sont tres repandus sur le web ou dans certaines applications. Le codes’execute a l’insu de l’utilisateur pour realiser des actions de toutes sortes. Hormis informer lesutilisateurs, une contre-mesure possible est d’installer un anti-malware.

6.3.6.7 Informer l’utilisateur des menaces

L’essentiel reste de rappeler a l’utilisateur les differentes menaces qui pesent sur lui. Trop souventles attaquants utilisent la negligence des utilisateurs a leur insu. C’est pourquoi l’application demandea l’utilisateur d’accepter les conditions d’utilisation et les mises en garde. Les trois points suivantsdoivent etre presents :

Logique Bitcoin

Un rappel sur l’importance de ne pas partager sa cle privee et d’effectuer une sauvegarde.

Malware

Le social engineering est utilise par les attaquants pour forcer l’utilisateur a cliquer sur un lienpar exemple. Il est necessaire d’aviser les utilisateurs de ce type de menaces.

Reseau publique ouvert

Mettre en garde l’utilisateur sur les menaces d’un reseau wifi publique et ouvert a tous, ciblefavorite des scripts kiddy et des attaquants plus experimentes.

6.3.6.8 Code source disponible

Pour maintenir un climat de confiance avec ses clients, les developpeurs de l’application doiventfournir le code source. De cette maniere, les personnes interessees peuvent analyser le code. Cettemitigation permet de se prevenir des developpeurs malhonnetes qui tenteraient de derober des clesprivees, des crendentials ou des informations bancaires.

6.4. CRITERES D’EVALUATION 71

6.4 Criteres d’evaluation

Cette derniere section conclut le modele de menaces en fournissant les criteres d’evaluation.L’analyse du niveau de securite des applications se basera sur les criteres listes ci-dessous.

Criteres d’evaluations ID mesures securitaires ID OWASP checklistStockage de donnees et confidentialite1. Chiffrer les donnees sensibles 1 2.12. Chiffrer les sauvegardes 2 2.3, 2.83. Forcer un mode de deverrouillage du systeme 5 2.114. Informer l’utilisateur des menaces 21 2.125. Aucune information sensible dans les logs 2.26. Desactiver cache/suggestion clavier 2.47. Desactiver presse-papiers (champs sensibles) 2.58. Proteger mecanismes IPC 2.69. Proteger la fuite d’informations via des screenshots 2.710. Cacher les donnees en arriere-plan 2.911. Effacer la memoire 2.10Cryptographie12. Choix de l’algorithme de chiffrement 3 3.2, 3.313. Implementation de l’algorithme de chiffrement 3 3.414. Generer un seed aleatoire et non deterministe 4 3.6Authentification et gestion de session15. Proteger l’acces a l’application 6 4.1, 4.916. Proteger les actions sensibles 7 4.1, 4.917. Appliquer une politique des mots de passe 16 4.4, 4.818. Appliquer une politique anti-Bruteforce 8 4.519. Limiter la duree de vie d’une session 9 4.720. Utiliser les tokens d’authentification 4.2Communication reseau21. Proteger les communications avec TLS 10 5.122. Restreindre les CAs 1223. Configurer le serveur SSL 14 5.2, 5.424. Utiliser le certificate pinning 13 5.425. Verifier les certificats 11 5.3Interaction avec la plateforme Android26. Utiliser les permissions minimums 6.127. Valider les entrees utilisateurs 6.228. Ne pas exporter de fonctionnalites sensibles via URL 6.329. Ne pas exporter de fonctionnalites sensibles via IPC 6.430. Serialiser avec API de confiance 6.931. Detecter si le mobile est roote 6.10Qualite du code et parametres de build32. Utiliser des librairies a jour 1533. Signer l’application 17 7.134. Fournir l’application en release mode (non-debuggable) 7.235. Allouer et liberer la memoire de maniere securisee 7.736. Activer les fonctions de securite de la toolchain (byte-code mi-nification, stack protection, PIE support and automatic referencecounting)

7.8

Chapitre 7

Analyse detaillee

Sommaire7.1 Resultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

7.2 Observations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

7.2.1 Bitcoin-wallet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

7.2.2 Mycelium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

7.2.3 Simple Bitcoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

7.2.4 Breadwallet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

7.2.5 ArcBit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

73

74 CHAPITRE 7. ANALYSE DETAILLEE

7.1 Resultats

Toujours securise Securise, mais depend de l’utilisateur Securite faible Jamais Pas implemente3 3 : 7 I

Criteres d’evaluations Bitcoin Wallet Myceluim Simple Bitcoin Wallet Breadwallet ArcBitStockage de donnees et confidentialite1. Chiffrer les donnees sensibles 3 3 32. Chiffrer les sauvegardes 3 3 I I I3. Forcer un mode de deverrouillage du systeme 7 7 7 3 74. Informer l’utilisateur des menaces 3 : : 7 75. Aucune information sensible dans les logs : 3 3 3 36. Desactiver cache/suggestion clavier 3 I 3 I 37. Desactiver presse-papiers (champs sensibles) 3 I : I :8. Proteger mecanismes IPC 3 3 3 3 39. Proteger la fuite d’information via screenshots : : 7 3 :10. Cacher les donnees en arriere plans : : 7 3 :11. Effacer la memoire 3 3 :Cryptographie12. Choix de l’algorithme de chiffrement 3 3 313. Implementation de l’algorithme de chiffrement 3 3 314. Generer un seed aleatoire et non deterministe 3 3 3

Authentification et gestion de session15. Proteger l’acces a application 7 3 7 3 316. Proteger les actions sensibles : 3 3 3 717. Appliquer une politique des mots de passe 7 7 : 3 718. Appliquer une politique anti-Bruteforce 7 7 3 7 719. Limiter la duree de vie d’une session I I I I I20. Utiliser les tokens d’authentification I I I I I

Communication reseau21. Proteger les communications avec TLS 3 3 3 3 322. Restreindre les CAs 7 3 7 7 723. Configurer le serveur SSL 3 3 3 3 324. Utiliser le certificate pinning 7 7 7 7 725. Verifier les certificats 3 3 7 3 7

Interaction avec la plateforme Android26. Utiliser les permissions minimums 3 7 3 : 727. Valider entrees utilisateurs : 3 :28. Ne pas exporter de fonctionnalites sensibles via URL 3 3 3 3 329. Ne pas exporter de fonctionnalites sensibles via IPC 3 3 3 7 330. Detecter si le mobile est roote 7 7 7 3 3

Qualite du code et parametres de build31. Utiliser des librairies a jour 7 7 7 732. Signer l’application 3 3 : 3 333. Fournir l’application en release mode (non-debuggable) 3 3 3 3 3

7.2. OBSERVATIONS 75

7.2 Observations

7.2.1 Bitcoin-wallet

1. Chiffrer les donnees sensibles

Par defaut les donnees ne sont pas chiffrees puisque aucun PIN n’est configure. Une fois quel’utilisateur active le PIN, l’application chiffre le wallet.

1 if (newKey != null && !wallet.isEncrypted ())

2 wallet.encrypt(keyCrypter , newKey);

3

4 log.info("wallet successfully encrypted , using key derived by new

spending password ( scrypt iterations)",

keyCrypter.getScryptParameters ().getN());

5 state = State.DONE;

6

2. Chiffrer les sauvegardes

La sauvegarde genere un fichier contenant la paire de cles. La sauvegarde est chiffree avec AES-256et conserve le PIN des transactions.

1 /**

2 * Password based encryption using AES - CBC 256 bits.

3 *

4 * @param plainTextAsBytes

5 * The bytes to encrypt

6 * @param password

7 * The password to use for encryption

8 * @return The encrypted string

9 * @throws IOException

10 */

11 public static String encrypt(final byte[] plainTextAsBytes , final

char[] password) throws IOException

12 final byte[] encryptedBytes = encryptRaw(plainTextAsBytes ,

password);

13

14 // OpenSSL prefixes the salt bytes + encryptedBytes with Salted___

and then base64 encodes it

15 final byte[] encryptedBytesPlusSaltedText =

concat(OPENSSL_SALTED_BYTES , encryptedBytes);

16

17 return BASE64_ENCRYPT.encode(encryptedBytesPlusSaltedText);

18

3. Forcer un mode de deverrouillage du systeme

Tester dynamiquement, aucun mode de deverrouillage du systeme n’est demande.


4. Informer l’utilisateur des menaces

L’application informe l’utilisateur des differents risques et des menaces. Les notes de securiteabordent la logique Bitcoin, les logiciels malveillants et la confiance dans le reseau.

5. Aucune information sensible dans les logs

1 log.info("successfully restored unencrypted private keys: ", file);

Bien que les cles ne soient pas directement affichees, cela peut fournir/indiquer une informationimportante.

6. Desactiver cache/suggestion clavier

Les champs traitant le PIN ou le mot de passe de chiffrement ont correctement desactive le cache/la suggestion du clavier. Les entrees de ces deux donnees sont de type textpassword ou numberpass-word.

7. Desactiver Presse-papiers

Il n’est pas possible de copier une information ecrite dans un champ traitant le PIN ou le mot depasse de la sauvegarde. Par contre, longClickable devrait etre desactive, car il permet de coller ducontenu.

8. Proteger mecanismes IPC

R.A.S.

dz> run scanner . p rov ide r . f i n d u r i s −a de . s ch i ldbach . w a l l e tScanning de . s ch i ldbach . w a l l e t . . .Unable to Query content : // de . s ch i ldbach . w a l l e t . l i f e c y c l e −t r o j anUnable to Query content : // de . s ch i ldbach . w a l l e t . f i l e a t t a c h m e n tUnable to Query content : // de . s ch i ldbach . w a l l e t . f i l e a t t a c h m e n t /Unable to Query content : // de . s ch i ldbach . w a l l e t . exchange ra te s /Unable to Query content : // de . s ch i ldbach . w a l l e t . exchange ra te sUnable to Query content : // de . s ch i ldbach . w a l l e t . l i f e c y c l e −t r o j an /

No a c c e s s i b l e content URIs found .dz> run scanner . p rov ide r . i n j e c t i o n −a de . s ch i ldbach . w a l l e tScanning de . s ch i ldbach . w a l l e t . . .Not Vulnerable :

content : // de . s ch i ldbach . w a l l e t . l i f e c y c l e −t r o j ancontent : // de . s ch i ldbach . w a l l e t . f i l e a t t a c h m e n tcontent : // de . s ch i ldbach . w a l l e t . f i l e a t t a c h m e n t /content : // de . s ch i ldbach . w a l l e t . exchange ra te s /content : // de . s ch i ldbach . w a l l e t . exchange ra te scontent : // de . s ch i ldbach . w a l l e t . l i f e c y c l e −t r o j an /

I n j e c t i o n in Pro j e c t i on :


No v u l n e r a b i l i t i e s found .

I n j e c t i o n in S e l e c t i o n :No v u l n e r a b i l i t i e s found .

dz> run scanner . p rov ide r . t r a v e r s a l −a de . s ch i ldbach . w a l l e tScanning de . s ch i ldbach . w a l l e t . . .Not Vulnerable :

content : // de . s ch i ldbach . w a l l e t . l i f e c y c l e −t r o j ancontent : // de . s ch i ldbach . w a l l e t . f i l e a t t a c h m e n tcontent : // de . s ch i ldbach . w a l l e t . f i l e a t t a c h m e n t /content : // de . s ch i ldbach . w a l l e t . exchange ra te s /content : // de . s ch i ldbach . w a l l e t . exchange ra te scontent : // de . s ch i ldbach . w a l l e t . l i f e c y c l e −t r o j an /

Vulnerable Prov ider s :No vu lne rab l e p rov ide r s found .

9. Proteger la fuite d’information via screenshots

Bien que la cle privee ne soit pas revelee par l’application, le PIN de transaction et le mot de passede chiffrement peuvent etre captures via screenshot. En effet, les champs qui traitent ces donneesont l’option ”show password”. Le test dynamique a demontre qu’il n’y a aucune protection mise enplace a ce niveau.

10. Cacher les donnees en arriere plans

Si l’utilisateur a coche ”show password”, meme mises en arriere plan les donnees sont toujoursvisibles (PIN/mot de passe de sauvegarde).

11. Effacer la memoire

Le wallet efface correctement le PIN lorsque celui-ci est entre par l’utilisateur. On trouve un appela la methode : wipePasswords().

12. Choix de l’algorithme de chiffrement

Pour le chiffrement du wallet en local et pour la sauvegarde, l’application utilise l’algorithme AES- CBC 256 bits.

13. Implementation de l’algorithme de chiffrement

La librairie bitcoinj se charge de chiffrer le wallet localement. Cette librairie utilise scrpyt. L’al-gorithme qui chiffre la sauvegarde est implemente dans le code et utilise la librairie spongycastle.

14. Generer un seed aleatoire et non deterministe

Le seed de l’HD wallet est genere a l’aide de SecureRandom(). AES utilise un IV qui lui aussiest genere aleatoirement.


1 final DeterministicKeyChain chain = new DeterministicKeyChain(new

SecureRandom ());

AES utilise un IV qui lui aussi est genere aleatoirement.

1 private static final SecureRandom secureRandom;

2

3 /** Returns SALT_LENGTH (8) bytes of random data */

4 public static byte[] randomSalt ()

5 byte[] salt = new byte[SALT_LENGTH ];

6 secureRandom.nextBytes(salt);

7 return salt;

8

15. Proteger l’acces a application

Aucun

16. Proteger les actions sensibles

La cle privee ne peut pas etre consultee sur l’application. Les transactions sont protegees par PINsur demande de l’utilisateur. La fonctionnalite de backup n’est pas protegee.

17. Appliquer une politique des mots de passe

L’application utilise un PIN pour proteger les actions sensibles. Un PIN est facilement cassablepuisqu’il est seulement constitue de chiffres. En revanche, un mot de passe est employe pour chiffrerle backup. Aucune restriction du nombre de chiffres ou de caracteres n’est appliquee ni pour le PIN,ni pour le mot de passe. Meme si l’application informe l’utilisateur de la qualite du secret (PIN/mdp),elle ne considere que la longueur et ne verifie pas la diversite des caracteres.

18. Appliquer une politique anti-Bruteforce

Aucune protection anti-bruteforce n’est appliquee sur le PIN de transaction et le mot de passede chiffrement de la sauvegarde.

19. Limiter la duree de vie d’une session

Aucun controle d’acces a l’application, ni aucune authentification a un service tiers ne sont ef-fectues. Donc aucune gestion de session local ou distante n’est realisee.

20. Utiliser les tokens d’authentification

Aucune connexion a un service tiers n’est necessaire pour utiliser l’application. Il n’y a aucuneauthentification, donc aucune utilisation de token.


21. Proteger les communications avec TLS

L’application recupere le taux de change du Bitcoin en d’autres devises standards (CHF, USD,etc.) sur une API. La communication est chiffree avec TLS. BIP70 decrit une methode de paiemententre le client et le vendeur. Le site web, sur lequel le client effectue des achats, envoie une demandede paiement directement au wallet du client. La communication entre les deux se fait sur un canalprotege par TLS. Le trafic sur le reseau Bitcoin n’a jamais ete chiffre. La connexion a un full nodes’effectue de ce fait en clair et ne peut pas utiliser TLS pour chiffrer la communication.

22. Restreindre les CAs

L’application ne restreint pas les CAs. Aucune entree n’a ete trouvee dans le manifest.

23. Configurer le serveur SSL

L’API sur lequel sont recuperes les taux de change est configuree correctement (TLS1.1/2), larenegociation par le client est desactivee, algorithmes (RSA/ECDS).

24. Utiliser le certificate pinning

L’application n’utilise pas de certificate pinning.

25. Verifier les certificats

La verification des certificats est effectuee dans le scenario BIP70. L’application n’implementepas la verification des certificats, mais delegue ce service a la librairie bitcoinj.

26. Utiliser les permissions minimums

L’application demande les permissions minimums en accord avec les fonctionnalites proposees parcelle-ci.

27. Valider entrees utilisateurs

Les entrees utilisateurs ne sont pas correctement verifiees. La verification en place verifie si lasaisie n’est pas vide et retire les espaces (not null & trim()).

28. Ne pas exporter de fonctionnalites sensibles via URL

Il est possible de generer une transaction avec la commande suivante :

run app . a c t i v i t y . s t a r t −−ac t i on android . i n t e n t . a c t i on .VIEW −−data−u r i ”b i t c o i n :12A1MyfXbW6RhdRAZEqofac5jCQQjwEPBu”

Comme l’application protege l’envoie de transaction par mot de passe, cette action n’as aucunimpact.

dz> run scanner . a c t i v i t y . browsable −a de . s ch i ldbach . w a l l e tPackage : de . s ch i ldbach . w a l l e t

Invocab le URIs :b i t c o i n : //

C la s s e s :de . s ch i ldbach . w a l l e t . u i . send . SendCoinsAct iv i ty


29. Ne pas exporter de fonctionnalites sensibles via IPC

R.A.S : les activites exportees sont protegees correctement.

dz> run app . package . a t t a c k s u r f a c e de . s ch i ldbach . w a l l e tAttack Sur face :

4 a c t i v i t i e s exported2 broadcast r e c e i v e r s exported0 content p rov ide r s exported0 s e r v i c e s exported

dz> run app . a c t i v i t y . i n f o −a de . s ch i ldbach . w a l l e tPackage : de . s ch i ldbach . w a l l e t

de . s ch i ldbach . w a l l e t . u i . Wal l e tAct iv i tyPermiss ion : n u l l

de . s ch i ldbach . w a l l e t . Wal l e tAct iv i tyPermiss ion : n u l lTarget Act i v i ty : de . s ch i ldbach . w a l l e t . u i . Wal l e tAct iv i ty

de . s ch i ldbach . w a l l e t . u i . send . SendCoinsAct iv i tyPermiss ion : n u l l

de . s ch i ldbach . w a l l e t . u i . backup . RestoreWal letFromExternalAct iv i tyPermiss ion : n u l l

dz> run app . s e r v i c e . i n f o −a de . s ch i ldbach . w a l l e tPackage : de . s ch i ldbach . w a l l e t

No exported s e r v i c e s .

dz> run app . broadcast . i n f o −a de . s ch i ldbach . w a l l e tPackage : de . s ch i ldbach . w a l l e t

de . s ch i ldbach . w a l l e t . WalletBalanceWidgetProviderPermiss ion : n u l l

de . s ch i ldbach . w a l l e t . s e r v i c e . Bootst rapRece iverPermiss ion : n u l l

30. Detecter si le mobile est roote

L’application ne verifie pas si le systeme est roote.

31. Utiliser des librairies a jour

Pas toutes les librairies utilisees ne sont a jour. Voici les librairies qui doivent etre mises a jour :Protocol Buffers (3.6.0), google.guava (25.1), google.zxing (3.3.4), org.slf4j (1.8.0-beta2), logback-android (1.1.1-12), com.google.code.findbugs (3.0.2), junit 5

32. Signer l’application

L’application a ete correctement signee.

. / apks igner v e r i f y −−verbose /home/nums/Documents/ a u t r e s r e p o / b i t co in−w a l l e t .apk

V e r i f i e sV e r i f i e d us ing v1 scheme (JAR s i g n i n g ) : trueV e r i f i e d us ing v2 scheme (APK Signature Scheme v2 ) : true


Number o f s i g n e r s : 1

33. Fournir l’application en release mode (non-debuggable)

Dans le Manifest, aucune entree android :debuggable n’a ete trouvee. De plus, si l’applicationetait debuggable, une ligne supplementaire serait presente dans l’extrait suivant :

dz> run app . package . a t t a c k s u r f a c e de . s ch i ldbach . w a l l e tAttack Sur face :



7.2.2 Mycelium



Dans le cas d’une sauvegarde d’un HD wallet, l’application verifie que l’utilisateur a releve lesmots correctement. Dans le cas d’une sauvegarde d’un compte unique (une cle specifique du HDwallet), l’application genere un PDF chiffre et le mot de passe est aleatoire.


Aucun mode de deverrouillage du systeme n’est force.


L’application informe uniquement sur la logique Bitcoin et l’importance de sauvegarder les clesprivees. Aucune note n’as ete trouve ni sur les logiciels malveillants et encore moins sur la confiancedans le reseau.


R.A.S.


Le PIN permettant d’acceder a l’application n’est pas recupere sous forme de texte. L’applicationmet en place son propre systeme d’authentification. Le clavier propose est personnalise, il mets adisposition uniquement des chiffres.

7. Desactiver Presse-papiers (champs sensibles)



R.A.S.

Test ing Content Prov ider sdz> run app . prov ide r . i n f o −a com . mycelium . w a l l e tPackage : com . mycelium . w a l l e t

Authority : com . mycelium . w a l l e t . Pa i r ingProv iderRead Permiss ion : n u l lWrite Permiss ion : n u l lContent Provider : com . mycelium . mo d u l a r i z a t i o n t o o l s . Pa i r ingProv ide rMul t ip roce s s Allowed : Fa l seGrant Uri Permiss ions : Fa l se

#Test ing Content URis


dz> run scanner . p rov ide r . f i n d u r i s −a com . mycelium . w a l l e tScanning com . mycelium . w a l l e t . . .Unable to Query content : //com . mycelium . w a l l e t . f i l e sUnable to Query content : //com . mycelium . w a l l e t . f i r e b a s e i n i t p r o v i d e rUnable to Query content : //com . mycelium . w a l l e t . Pa i r ingProv ide rUnable to Query content : //com . mycelium . w a l l e t . f i l e s /Unable to Query content : //com . mycelium . w a l l e t . f i r e b a s e i n i t p r o v i d e r /Unable to Query content : //com . mycelium . w a l l e t . Pa i r ingProv ide r /

No a c c e s s i b l e content URIs found .

#SQL I n j e c t i o n in Content Prov ider sdz> run scanner . p rov ide r . i n j e c t i o n −a com . mycelium . w a l l e tScanning com . mycelium . w a l l e t . . .Not Vulnerable :

content : //com . mycelium . w a l l e t . Pa i r ingProv ide rcontent : //com . mycelium . w a l l e t . f i r e b a s e i n i t p r o v i d e rcontent : //com . mycelium . w a l l e t . f i l e scontent : //com . mycelium . w a l l e t . f i l e s /content : //com . mycelium . w a l l e t . f i r e b a s e i n i t p r o v i d e r /content : //com . mycelium . w a l l e t . Pa i r ingProv ide r /

I n j e c t i o n in Pro j e c t i on :No v u l n e r a b i l i t i e s found .


#F i l e System Based Content Prov ider sdz> run scanner . p rov ide r . t r a v e r s a l −a com . mycelium . w a l l e tScanning com . mycelium . w a l l e t . . .Not Vulnerable :

content : //com . mycelium . w a l l e t . f i l e scontent : //com . mycelium . w a l l e t . f i r e b a s e i n i t p r o v i d e rcontent : //com . mycelium . w a l l e t . Pa i r ingProv ide rcontent : //com . mycelium . w a l l e t . f i l e s /content : //com . mycelium . w a l l e t . f i r e b a s e i n i t p r o v i d e r /content : //com . mycelium . w a l l e t . Pa i r ingProv ide r /



L’affichage du code mnemonique et le mot de passe aleatoire de la sauvegarde d’une adresseunique sont correctement proteges : il n’est pas possible de faire une capture d’ecran. Mais lorsqu’onrestaure a partir du code mnemonique, il est possible de faire une capture d’ecran.



Le code mnemotechnique est cache lorsqu’il se trouve en arriere plan. Par contre, ce n’est pas lacas lorsqu’on restaure le wallet.



Algortithme : AES/GCM/NoPadding


L’application utilise la librairie cryptographique javax.crypto ;


15. Proteger l’acces a l’application

Par defaut l’application ne protege pas l’acces, mais propose d’utiliser un PIN de six chiffres.L’utilisateur a le choix.


Par defaut, l’application ne protege pas les actions sensibles (sauvegarde, transaction, change-ment PIN, exporter le code mnemotechnique), mais propose d’utiliser un PIN de six chiffres. Pouraugmenter le niveau de securite, il est impossible d’effectuer une sauvegarde supplementaire peu detemps apres avoir change le code d’acces (48h d’attente).


Les mots de passe de l’application sont sous le format PIN et leur longueur est de 6 chiffres. LesPINs sont facilement cassable.


Aucune restriction sur le nombre de tentatives.


Aucune connexion a un service tiers n’est necessaire. Il n’y a donc aucune gestion de session.


Aucune connexion a un service tiers n’est necessaire pour utiliser l’application. Il n’y a aucuneauthentification, et donc aucune utilisation de token.


Toutes les communications sont protegees avec TLS.



Aucune CA n’est restreint. Aucune entree dans le manifest.


Les differents API utilisees par le wallet sont toutes configurees correctement.


Pas de certificate Pinning, il y a plusieurs certificats par endpoints.


Le wallet dispose d’une methode lui permettant de verifier les certificats.

1 public void checkServerTrusted(X509Certificate [] certs , String authType)


Oui, l’application demandes les permissions minimums en accord avec les fonctionnalites pro-posees par celle-ci.

dz> run app . package . i n f o −a com . mycelium . w a l l e tPackage : com . mycelium . w a l l e t

App l i ca t ion Label : P o r t e f e u i l l e B i t co in MyceliumProcess Name : com . mycelium . w a l l e tVers ion : 2 . 1 0 . 6 . 2Data Di rec tory : / data / user /0/com . mycelium . w a l l e tAPK Path : / data /app/com . mycelium . wa l l e t −1/base . apkUID : 10329GID: [ 3 0 0 3 ]Shared L i b r a r i e s : n u l lShared User ID : n u l lUses Permiss ions :− com . mycelium . w a l l e t . pe rmis s ion .C2D MESSAGE− android . permis s ion .INTERNET− android . permis s ion .ACCESS NETWORK STATE− android . permis s ion .VIBRATE− com . goog l e . android . c2dm . permis s ion .RECEIVE− android . permis s ion .WAKE LOCK− android . permis s ion .NFC− android . permis s ion .CAMERA− android . permis s ion .ACCESS COARSE LOCATION− com . android . vending .CHECK LICENSEDef ines Permiss ions :− com . mycelium . w a l l e t . pe rmis s ion .C2D MESSAGE




RAS

Test ing Custom URL Schemesdz> run scanner . a c t i v i t y . browsable −a com . mycelium . w a l l e tPackage : com . mycelium . w a l l e t

Invocab le URIs :b i t c o i n : //b i t i d : //btcpop ://mycelium ://http :// w a l l e t . mycelium . com/ star tup (PATTERN PREFIX)

C la s s e s :com . mycelium . w a l l e t . a c t i v i t y . S ta r tupAct iv i ty


R.A.S : les fonctionnalites ont ete correctement protegees.

dz> run app . package . a t t a c k s u r f a c e com . mycelium . w a l l e tAttack Sur face :


dz> run app . prov ide r . f i n d u r i com . mycelium . w a l l e tScanning com . mycelium . w a l l e t . . .content : //com . mycelium . w a l l e t . f i l e scontent : //com . mycelium . w a l l e t . f i r e b a s e i n i t p r o v i d e rcontent : //com . mycelium . w a l l e t . Pa i r ingProv ide rcontent : //com . mycelium . w a l l e t . f i l e s /content : //com . mycelium . w a l l e t . f i r e b a s e i n i t p r o v i d e r /content : //com . mycelium . w a l l e t . Pa i r ingProv ide r /

dz> run app . a c t i v i t y . i n f o −a com . mycelium . w a l l e tPackage : com . mycelium . w a l l e t

com . mycelium . w a l l e t . a c t i v i t y . S ta r tupAct iv i tyPermiss ion : n u l l

dz> run app . s e r v i c e . i n f o −a com . mycelium . w a l l e tPackage : com . mycelium . w a l l e t

com . mycelium . m o d u l a r i z a t i o n t o o l s . MessageReceiverPermiss ion : n u l l

dz> run app . broadcast . i n f o −a com . mycelium . w a l l e tPackage : com . mycelium . w a l l e t

com . mycelium . w a l l e t . l t . n o t i f i c a t i o n . GcmBroadcastReceiverPermiss ion : com . goog l e . android . c2dm . permis s ion .SEND

com . mycelium . w a l l e t . PackageRemovedReceiver


Permiss ion : n u l l


L’application ne verifie pas si le systeme est roote.




$ . / apks igner v e r i f y −−verbose /home/nums/Downloads/com . mycelium . w a l l e t . apkV e r i f i e sV e r i f i e d us ing v1 scheme (JAR s i g n i n g ) : trueV e r i f i e d us ing v2 scheme (APK Signature Scheme v2 ) : trueNumber o f s i g n e r s : 1

$ j a r s i g n e r −v e r i f y −verbose −c e r t s /home/nums/Downloads/com . mycelium . w a l l e t .apk

X.509 , CN=Mycelium Developers , O=Mycelium , L=Vienna , C=AT[ c e r t i f i c a t e i s v a l i d from 6/17/13 4 :44 PM to 6/11/38 4 :44 PM][ CertPath not va l i da t ed : Path does not chain with any o f the t r u s t

anchors ]

sm 4644 Fr i Nov 30 00 : 00 : 00 GMT+01:00 1979 r e s /xml/ p r e f e r e n c e s . xml

j a r v e r i f i e d .


Dans le Manifest, aucune entree android :debuggable a ete trouve. De plus, si l’application etaitdebuggable. Une ligne supplementaire serait presente dans l’extrait suivant :

dz> run app . package . a t t a c k s u r f a c e com . mycelium . w a l l e tAttack Sur face :



7.2.3 Simple Bitcoin


class Wallet (bitcoinj), Wallet stocke dans un fichier, chiffrer


La restauration d’un HD wallet utilise uniquement le code mnemonique de 12 mots. Aucunefonctionnalite de sauvegarde est proposee directement par l’application. La documentation du walletsugere 2 possiblitees :

1. Ecrire le code sur papier et le stocker dans un endroit securise

2. Utiliser l’application Secret Space Encryptor pour chiffrer le code

En effectuant une sauvegarde de votre systeme, l’application sera backupe avec ses donnees. Lesdonnees sont chiffrees avec le mot de passe. Cela ne pose donc pas de probleme.


Aucun mode de deverrouillage du systeme force


L’application n’informe pas l’utilisateur de tous les risques et les menaces. La documentationaborde uniquement la logique Bitcoin.


RAS


Cette option a ete desactive sur les champs de type mot de passe.


Lorsqu’on change de mot de passe, le nouveau peut etre copie. Lorsqu’on restaure un codemnemotechnique, il est possible de copier le code et le mot de passe.


R.A.S

dz> run app . prov ide r . i n f o −a com . btcont rac t . w a l l e tPackage : com . btcont rac t . w a l l e t

No matching prov ide r s .

dz> run scanner . p rov ide r . f i n d u r i s −a com . btcont rac t . w a l l e tScanning com . btcont rac t . w a l l e t . . .

No a c c e s s i b l e content URIs found .dz> run scanner . p rov ide r . i n j e c t i o n −a com . btcont rac t . w a l l e t


Scanning com . btcont rac t . w a l l e t . . .Not Vulnerable :

No non−vu lne rab l e URIs found .



dz> run scanner . p rov ide r . t r a v e r s a l −a com . btcont rac t . w a l l e tScanning com . btcont rac t . w a l l e t . . .Not Vulnerable :




L’affichage du code mnemonique par l’application est correctement protege. Mais lorsqu’on res-taure a partir du code mnemonique, il est possible de faire une capture d’ecran. Comme il est demanded’entrer un nouveau mot de passe, l’image contiendra a la fois le seed de la cle privee et le mot depasse de chiffrement.

Lors de la generation du wallet, la creation du mot de passe bien que visible est correctementprotegee. Par contre lorsqu’on change de mot de passe de chiffrement, le mot de passe est vulnerablea des fuites par capture d’ecran. Le nouveau password est de type ”textVisiblePassword”.


Lorsqu’on affiche le code mnemonique, il n’est pas visible en arriere plan. Par contre, lorsqu’onrestaure la sauvegarde, le code et le mot de passe ne sont pas caches ! On obtient le meme scenariolorsqu’on change le mot de passe de chiffrement.


Cryptographie




oui, utilisation de secureRandom Authentification et gestion de session


Acces application pas protege, pas de pin pour effectuer une transaction par exemple



L’affichage du code mnemotechnique est protege par mot de passe, ainsi que les transactions.

1 generatePasswordPromptView(passType , wallet_password)


La seule restriction appliquee sur les mots de passe est la longueur minimale de 6 caracteres.Cependant le mot de passe peut etre compose de caracteres.


Aucune restriction sur le nombre de tentatives n’est appliquee.


Aucune controle d’acces a l’application ni d’authentification a un service tiers n’est effectue. Doncaucune gestion de session local ou distante n’est realisee.




L’application recupere le taux de change du Bitcoin en d’autres devises standards (CHF, USD,etc.) sur une API. La communication est chiffree avec TLS.

L’application recupere les frais de transaction recommandes sur une API. La communication estchiffre avec TLS.


L’application ne restreint pas les CAs. Aucune entree n’a ete trouvee dans le manifest.


L’API sur lequel sont recuperes les taux de change est configuree correctement (TLS1.1/2), larenegociation par le client est desactivee, algorithmes (RSA/ECDS).




Le wallet ne verifie pas les certificats.



Oui : WRITEEXTERNALSTORAGE, INTERNET, V IBRATE,CAMERA,READEXTERNALSTORAGE



Il est possible de generer une transaction avec la commande suivante :

run app . a c t i v i t y . s t a r t −−ac t i on android . i n t e n t . a c t i on .VIEW −−data−u r i ”b i t c o i n : 12A1MyfXbW6RhdRAZEqofac5jCQQjwEPBu”

Comme l’application protege l’envoie de transactions par mot de passe, cette action n’as aucuneimpact.

dz> run scanner . a c t i v i t y . browsable −a com . btcont rac t . w a l l e tPackage : com . btcont rac t . w a l l e t


C la s s e s :com . btcont rac t . w a l l e t . MainActivity


R.A.S.

dz> run app . package . a t t a c k s u r f a c e com . btcont rac t . w a l l e tAttack Sur face :


dz> run app . a c t i v i t y . i n f o −a com . btcont rac t . w a l l e tPackage : com . btcont rac t . w a l l e t

com . btcont rac t . w a l l e t . MainActivityPermiss ion : n u l l

dz> run app . s e r v i c e . i n f o −a com . btcont rac t . w a l l e tPackage : com . btcont rac t . w a l l e t


dz> run app . broadcast . i n f o −a com . btcont rac t . w a l l e tPackage : com . btcont rac t . w a l l e t

No matching r e c e i v e r s .

Permet de lancer directement le wallet, pas de soucis puisque pas de mot de passe.


L’application ne verifie pas si le systeme est roote. Qualite du code et parametres de build



Pas toutes les librairies utilisees sont a jour. Voici les librairies qui doivent etre mises a jour : spon-gycastle (1.58.0), bitcoinj-core(0.14.7), info.hoang8f(1.0.6), spray-json (1.3.4), wire-runtime (2.3.0),nv-websocket-client (2.5), com.google.zxing (3.3.3), com.journeyapps (3.6.0), com.softwaremill.quicklens(1.4.11), scala-library (2.13), rxscala (0.26.5).


PAS OK, pas le 2eme schemas valides

. / apks igner v e r i f y −−verbose /home/nums/Downloads/com . btcont rac t . w a l l e t . apkV e r i f i e sV e r i f i e d us ing v1 scheme (JAR s i g n i n g ) : trueV e r i f i e d us ing v2 scheme (APK Signature Scheme v2 ) : fa l seNumber o f s i g n e r s : 1WARNING: META−INF/ rxjava . p r o p e r t i e s not pro tec ted by s i g n a t u r e . Unauthorized

m o d i f i c a t i o n s to t h i s JAR entry w i l l not be detec ted . De lete or move theentry out s id e o f META−INF / .

. / apks igner v e r i f y −−verbose /home/nums/Downloads/com . btcont rac t . w a l l e t . apkV e r i f i e sV e r i f i e d us ing v1 scheme (JAR s i g n i n g ) : trueV e r i f i e d us ing v2 scheme (APK Signature Scheme v2 ) : fa l seNumber o f s i g n e r s : 1WARNING: META−INF/ rxjava . p r o p e r t i e s not pro tec ted by s i g n a t u r e . Unauthorized

m o d i f i c a t i o n s to t h i s JAR entry w i l l not be detec ted . De lete or move theentry out s id e o f META−INF / .

j a r s i g n e r −v e r i f y −verbose −c e r t s /home/nums/Downloads/com . btcont rac t . w a l l e t .apk

sm 6512 Thu Dec 21 09 : 17 : 02 GMT+01:00 2017 AndroidManifest . xml

X.509 , CN=B i t c o i n s w a l l e t deve loper[ c e r t i f i c a t e i s v a l i d from 7/13/15 8 :37 AM to 7/6/40 8 :37 AM][ CertPath not va l i da t ed : Path does not chain with any o f the t r u s t

anchors ]



dz> run app . package . a t t a c k s u r f a c e com . btcont rac t . w a l l e tAttack Sur face :



7.2.4 Breadwallet


Le PIN et les differents cles (privees et publiques) sont stockes dans le keystore android. Cesdonnees sont chiffrees avant d’etre stockees. Dans le code : la methode setData est le point d’entreepermettant le chiffrement et le stockage local.


L’application ne propose pas de fonctionnalite de backup. Elle n’est meme pas sauvegarde si oneffectue une sauvegarde entiere de l’appareil (manifest : android :allowBackup=”false”, android :full-BackupContent=”false”). Par contre, l’application verifie que l’utilisateur a ecrit correctement lesdouze mots du code mnemotechnique (verifie 2 mots au hasard).


L’application force l’utilisateur a active une mode de deverrouillage du systeme.


L’application informe correctement l’utilisateur sur la logique Bitcoin. Elle souligne surtout l’im-portance du code mnemotechnique de douze mots. Par contre, on ne trouve pas d’information surles menaces de type malwares et sur les reseaux Wi-Fi ouverts. De plus en testant les limites del’application, le mode de deverrouillage a ete retire ce qui a eut pour effet de corrompre le wallet.Aucune information n’a ete trouve a ce sujet.


R.A.S






R.A.S.

#Test ing Content Prov ider sdz> run app . prov ide r . i n f o −a com . breadwa l l e tPackage : com . breadwa l l e t



#Test ing Content URisdz> run scanner . p rov ide r . f i n d u r i s −a com . breadwa l l e tScanning com . breadwa l l e t . . .Unable to Query content : //com . breadwa l l e tUnable to Query content : //com . breadwa l l e t /Unable to Query content : //com . breadwa l l e t . f i r e b a s e i n i t p r o v i d e rUnable to Query content : //com . breadwa l l e t . com . android . t o o l s . i r . s e r v e r .

InstantRunContentProviderUnable to Query content : //com . breadwa l l e t . l i f e c y c l e −t r o j anUnable to Query content : //com . breadwa l l e t . c r a s h l y t i c s i n i t p r o v i d e rUnable to Query content : //com . breadwa l l e t . f i r e b a s e i n i t p r o v i d e r /Unable to Query content : //com . breadwa l l e t . c r a s h l y t i c s i n i t p r o v i d e r /Unable to Query content : //com . breadwa l l e t . l i f e c y c l e −t r o j an /Unable to Query content : //com . breadwa l l e t . com . android . t o o l s . i r . s e r v e r .

InstantRunContentProvider /


#SQL I n j e c t i o n in Content Prov ider sdz> run scanner . p rov ide r . i n j e c t i o n −a com . breadwa l l e tScanning com . breadwa l l e t . . .Not Vulnerable :

content : //com . breadwa l l e tcontent : //com . breadwa l l e t /content : //com . breadwa l l e t . f i r e b a s e i n i t p r o v i d e rcontent : //com . breadwa l l e t . com . android . t o o l s . i r . s e r v e r .

InstantRunContentProvidercontent : //com . breadwa l l e t . l i f e c y c l e −t r o j ancontent : //com . breadwa l l e t . c r a s h l y t i c s i n i t p r o v i d e rcontent : //com . breadwa l l e t . f i r e b a s e i n i t p r o v i d e r /content : //com . breadwa l l e t . c r a s h l y t i c s i n i t p r o v i d e r /content : //com . breadwa l l e t . l i f e c y c l e −t r o j an /content : //com . breadwa l l e t . com . android . t o o l s . i r . s e r v e r .



# F i l e System Based Content Prov ider sdz> run scanner . p rov ide r . t r a v e r s a l −a com . breadwa l l e tScanning com . breadwa l l e t . . .Not Vulnerable :

content : //com . breadwa l l e tcontent : //com . breadwa l l e t /content : //com . breadwa l l e t . f i r e b a s e i n i t p r o v i d e r


content : //com . breadwa l l e t . com . android . t o o l s . i r . s e r v e r .InstantRunContentProvider

content : //com . breadwa l l e t . l i f e c y c l e −t r o j ancontent : //com . breadwa l l e t . c r a s h l y t i c s i n i t p r o v i d e rcontent : //com . breadwa l l e t . f i r e b a s e i n i t p r o v i d e r /content : //com . breadwa l l e t . c r a s h l y t i c s i n i t p r o v i d e r /content : //com . breadwa l l e t . l i f e c y c l e −t r o j an /content : //com . breadwa l l e t . com . android . t o o l s . i r . s e r v e r .




Le PIN n’est jamais visible, il ne peut donc pas etre sujet a des fuites via capture d’ecran. Lesmots du code mnemotechnique sont presentes les uns apres les autres et sont protege correctement.Meme l’etape qui verifie que l’utilisateur a releve correctement les mots est protegee.


Les mots du code mnemotechnique (cle privee) sont caches lorsque l’application est mise en arriereplan.


Une fois que le PIN a ete configure et stocke de maniere securisee, une valeur vide est affectee ala variable (pin, updatePin).


Chiffrement : AES/GCM/NoPadding


L’application n’implemente pas l’algorithme de chiffrement, mais utilise le Cipher du packagejavax.crypto.


oui, le seed est genere aleatoirement.

1 public synchronized boolean generateRandomSeed(final Context ctx)

2 SecureRandom sr = new SecureRandom ();

3 final byte[] randomSeed = sr.generateSeed (16);



Par defaut, l’acces a l’application est protege par un PIN configure lors de la premiere utilisation.L’application propose d’utiliser l’empreinte digitale pour debloquer le wallet et envoyer de l’argentjusqu’a une limite definie.


Les actions sensibles sont : la mise a jour du PIN, la consultation du code mnemotechnique, lasuppression du wallet. Toutes ces actions sont protegees par le PIN, a moins que l’empreinte digitalesoit configuree. En plus du PIN ou de l’empreinte, la suppression du wallet requiert d’entrer le codemnemotechnique.


Par defaut, l’application utilise un PIN de 6 chiffres pour proteger l’acces a l’application et lesactions sensibles. Un PIN est facilement cassable due a sa taille et sa combinaison constitue de chiffre.L’application propose l’utilisation de l’empreinte digitale pour compliquer la tache a un potentielattaquant.


En analysant le code source de l’application, il semble que l’application mets en place une politiqueanti-bruteforce. Theoriquement, apres 3 tentatives erronees, le wallet se bloque. Pour debloquer lewallet, l’application demande d’entree le code mnemotechnique (seed cle privee).

i f ( BRKeyStore . getFai lCount ( context ) >= LOCK FAIL ATTEMPT COUNT) s e tWal l e tDi sab l ed ( ( Act i v i ty ) context ) ;

Pratiquement, la politique anti-bruteforce ne fonctionne pas. Le wallet n’est jamais bloque.


Aucune connexion a un service tiers n’est necessaire. Il n’y a donc aucune gestion de session.


Aucune connexion a un service tiers n’est necessaire pour utiliser l’application. Il n’y a aucuneauthentification, et donc aucune utilisation de token.



BIP70 decrit une methode de paiement entre le client et le vendeur. Le site web sur lequelle client effectue des achats envoie une demande de paiement directement au wallet du client. Lacommunication entre les deux se fait sur un canal protege par TLS.

Le trafic sur le reseau Bitcoin n’a jamais ete chiffre. La connexion a un full node s’effectue doncen clair et ne peut pas utiliser TLS pour chiffrer la communication.



L’application ne restreint pas les CAs. Aucune entree n’as ete trouve dans le manifest.


L’API (https ://api.coinmarketcap.com/) sur lequel est recupere les taux de change est configurecorrectement (TLS1.1/2, la renegociation par le client est desactive, algorithmes (RSA/ECDS)).


Pas de certificate Pinning


Les certificats sont verifiees. La classe X509CertificateValidator se charge de toutes la logique.


Certaines permissions ne sont plus valables. De plus, WRITE/READINTERNALSTRORAGEne sont pas necessaire.

dz> run app . package . i n f o −a com . breadwa l l e tPackage : com . breadwa l l e t

App l i ca t ion Label : BRDProcess Name : com . breadwa l l e tVers ion : 3 . 1 . 0Data Di rec tory : / data / user /0/com . breadwa l l e tAPK Path : / data /app/com . breadwal le t −1/base . apkUID : 10006GID: [ 3 0 0 3 ]Shared L i b r a r i e s : n u l lShared User ID : n u l lUses Permiss ions :− android . permis s ion .CAMERA− android . permis s ion .INTERNET− android . permis s ion .WAKE LOCK− android . permis s ion .WRITE EXTERNAL STORAGE− android . permis s ion .WRITE INTERNAL STORAGE− android . permis s ion .READ EXTERNAL STORAGE− android . permis s ion .READ INTERNAL STORAGE− android . permis s ion .ACCESS NETWORK STATE− android . permis s ion .USE FINGERPRINT− android . permis s ion .SEND SMS− android . permis s ion .ACCESS FINE LOCATION− android . permis s ion .ACCESS COARSE LOCATION− android . permis s ion . BIND JOB SERVICE− android . permis s ion .PACKAGE USAGE STATS− android . permis s ion .DISABLE KEYGUARD− android . permis s ion .CHANGE CONFIGURATION− com . goog l e . android . f i n s k y . permis s ion .BIND GET INSTALL REFERRER SERVICE− com . goog l e . android . c2dm . permis s ion .RECEIVE


− com . breadwa l l e t . permis s ion .C2D MESSAGEDef ines Permiss ions :− com . breadwa l l e t . permis s ion .C2D MESSAGE

27. Valider les entrees utilisateurs

Les chiffre du PIN sont verifie a leur saisie : Character.isDigit(key.charAt(0). Les mots de la listequi sont entree passe par le methode : public static String cleanWord(String word).


R.A.S.

dz> run scanner . a c t i v i t y . browsable −a com . breadwa l l e tPackage : com . breadwa l l e t


C la s s e s :com . breadwa l l e t . p r e s e n t e r . a c t i v i t i e s . Wal l e tAct iv i ty


Il est possible de contourner le controle d’acces a l’application. La commande suivante permet delancer l’activite principal du wallet sans passer par le controle d’acces.

dz> run app . a c t i v i t y . s t a r t −−component com . breadwa l l e t com . breadwa l l e t .p r e s e n t e r . a c t i v i t i e s . Wal l e tAct iv i ty

dz> run app . package . a t t a c k s u r f a c e com . breadwa l l e tAttack Sur face :


CONTENT PROVIDERSdz> run app . prov ide r . f i n d u r i com . breadwa l l e tScanning com . breadwa l l e t . . .content : //com . goog l e . s e t t i n g s / partner /content : //com . breadwa l l e tcontent : //com . goog l e . android . g s f . g s e r v i c e s / p r e f i xcontent : //com . breadwa l l e t /content : //com . breadwa l l e t . f i r e b a s e i n i t p r o v i d e rcontent : //com . goog l e . android . gms . phenotypecontent : //com . goog l e . android . gms . chimera /content : //com . goog l e . android . gms . chimeracontent : //com . goog l e . android . gms . phenotype/content : //com . goog l e . android . g s f . g s e r v i c e s / p r e f i x /content : //com . breadwa l l e t . l i f e c y c l e −t r o j ancontent : //com . goog l e . android . g s f . g s e r v i c e s /


content : //com . goog le . s e t t i n g s / partnercontent : //com . breadwa l l e t . c r a s h l y t i c s i n i t p r o v i d e rcontent : //com . breadwa l l e t . f i r e b a s e i n i t p r o v i d e r /content : //com . breadwa l l e t . c r a s h l y t i c s i n i t p r o v i d e r /content : //com . goog le . android . g s f . g s e r v i c e scontent : //com . breadwa l l e t . l i f e c y c l e −t r o j an /

#ACTIVITIESdz> run app . a c t i v i t y . i n f o −a com . breadwa l l e tPackage : com . breadwa l l e t

com . breadwa l l e t . p r e s e n t e r . a c t i v i t i e s . i n t r o . I n t r o A c t i v i t yPermiss ion : n u l l

com . breadwa l l e t . p r e s e n t e r . a c t i v i t i e s . Wal l e tAct iv i tyPermiss ion : n u l l

#SERVICESdz> run app . s e r v i c e . i n f o −a com . breadwa l l e tPackage : com . breadwa l l e t

com . goog l e . f i r e b a s e . i i d . F i r e b a s e I n s t a n c e I d S e r v i c ePermiss ion : n u l l

#BROADCASTdz> run app . broadcast . i n f o −a com . breadwa l l e tPackage : com . breadwa l l e t

com . goog l e . android . gms . measurement . AppMeasurementInsta l lReferrerRece iverPermiss ion : android . permis s ion . INSTALL PACKAGES

com . goog l e . f i r e b a s e . i i d . F i r eba s e In s tance IdRece i v e rPermiss ion : com . goog l e . android . c2dm . permis s ion .SEND


L’application refuse de s’executer si elle est emulee ou si le smartphone est roote.

1 public static boolean isDeviceRooted ()

2 return checkRootA () || checkRootB () || checkRootC ();

3


Pas toutes les librairies utilisees sont a jour. De plus, certaines librairies ne peuvent pas etre misea jour (jetty-webapp, websocket-server, jetty-continuation). Voici les librairies qui doivent etre misesa jour : commons-io(2.6), appcompat-v7(28.0.0-alpha3), design(28.0.0-alpha3), gridlayout-v7 :(28.0.0-alpha3), support-v13 :(28.0.0-alpha3), recyclerview-v7(28.0.0-alpha3), okhttp(3.10.0), firebase-core(16.0.1),crashlytics(2.9.4), zxing :core(3.3.3), constraint-layout(1.1.2).




. / apks igner v e r i f y −−verbose /home/nums/Downloads/com . breadwa l l e t . apkV e r i f i e sV e r i f i e d us ing v1 scheme (JAR s i g n i n g ) : trueV e r i f i e d us ing v2 scheme (APK Signature Scheme v2 ) : trueNumber o f s i g n e r s : 1

j a r s i g n e r −v e r i f y −verbose −c e r t s /home/nums/Downloads/com . breadwa l l e t . apk

sm 22064 Fr i Nov 30 00 : 0 0 : 00 GMT+01:00 1979 AndroidManifest . xml

X.509 , CN=Aaron Vois ine , O=breadwa l l e t LLC, L=San Francisco , ST=C a l i f o r n i a , C=US

[ c e r t i f i c a t e i s v a l i d from 4/12/16 8 :53 PM to 8/14/14 8 :53 PM][ CertPath not va l i da t ed : Path does not chain with any o f the t r u s t

anchors ]



dz> run app . package . a t t a c k s u r f a c e com . breadwa l l e tAttack Sur face :



7.2.5 ArcBit


Le wallet contenant les differentes cles (privees/publiques) ainsi que le PIN est entierement chiffredans un fichier JSON.


La restauration d’un HD wallet utilise uniquement le code mnemonique de 12 mots. Aucunefonctionnalite de sauvegarde est proposee directement par l’application. Par contre, l’applicationverifie que l’utilisateur a releve les mots correctement. Cette verification est effectuee en demandanta l’utilisateur de completer la liste de mots.


Teste dynamiquement, aucun mode de deverrouillage du systeme n’est demande.


L’application n’informe ni sur la logique Bitcoin, ni sur les logiciels malveillants et encore moinssur la confiance dans le reseau.


Aucune information sensible n’a ete trouve dans les logs.


Les suggestions proposees par le clavier ont ete correctement desactivees. Les entrees utilisateurssensibles possedant l’attribut ”textNoSuggestions”.


Le presse-papiers a ete desactive pour les entrees traitant le PIN. Lors de la restauration d’unwallet, par contre, il est possible de copier le code mnemotechnique. Le meme cas est observe lorsqu’onimporte une cle privee.


R.A.S.

#Test ing Content Prov ider sdz> run app . prov ide r . i n f o −a com . a r c b i t . a r c b i tPackage : com . a r c b i t . a r c b i t


dz> run scanner . p rov ide r . f i n d u r i s −a com . a r c b i t . a r c b i tScanning com . a r c b i t . a r c b i t . . .



#SQL I n j e c t i o n in Content Prov ider sdz> run scanner . p rov ide r . i n j e c t i o n −a com . a r c b i t . a r c b i tScanning com . a r c b i t . a r c b i t . . .Not Vulnerable :



I n j e c t i o n in S e l e c t i o n :No v u l n e r a b i l i t i e s found .No v u l n e r a b i l i t i e s found .

F i l e System Based Content Prov ider sdz> run scanner . p rov ide r . t r a v e r s a l −a com . a r c b i t . a r c b i tScanning com . a r c b i t . a r c b i t . . .Not Vulnerable :




L’affichage du code mnemonique par l’application est correctement protege. Il n’est pas possiblede faire une capture d’ecran. Mais lorsqu’on restaure a partir du code mnemonique, il est possiblede faire une capture d’ecran. De plus lors de l’importation d’une clee privee, on observe le memeresultat.


Le code mnemotechnique est cache lorsqu’il se trouve en arriere plan. Par contre, ce n’est pas lacas lorsqu’on restaure le wallet, ni lorsqu’on importe une cle privee.


La memoire est efface qu’apres une operation d’importation d’adresse privee.

1 public void clearPrivateKeyFromMemory ()

2 privateKey = null;

3


Le chiffrement du wallet s’effectue en plusieurs etapes et utilise deux algorithmes differents. Lepremier est RSA/ECB/PKCS1Padding qui permet de chiffrer le code mnemotechnique (seed de lacle privee Bitcoin). Ce resultat est utilise comme cle de chiffrement dans le deuxieme algorithme, asavoir AES/CBC/PKCS7Padding. Celui-ci se charge de chiffrer le wallet qui sera enregistre dans lefichier Json.



L’application n’implemente pas les algorithmes de chiffrement, mais utilise le Cipher du packagejavax.crypto.


Tous les valeurs aleatoires utilisees pour la generation des cles ou des vecteurs d’initialisationutilise sont correctement generees a l’aide SecureRandom

15. Proteger l’acces a l’application

De base, l’application ne protege pas l’acces a l’application. L’utilisateur doit configure l’applica-tion afin d’utiliser un PIN.


L’affichage de la cle privee (code mnemotechnique) et l’envoie de transaction ne sont pas proteges.


Le seul mot de passe est sous le format de PIN et sa longueur est de 4 chiffres.


En theorie l’application limite a 8 tentatives, par contre en pratique aucune restriction n’estapplique.


L’application ne gere aucune session local, parce qu’il n’y aucune connexion a un service tiers.





L’application recupere les frais de transaction recommandes sur une API. La communication estchiffre avec TLS.

1 public HttpURLConnection getHttpURLConnection(String URL) throws Exception

2 return NetCipher.getHttpsURLConnection(URL);

3

Le trafic sur le reseau Bitcoin n’a jamais ete chiffre. La connexion a un full node s’effectue doncen clair et ne peut pas utiliser TLS pour chiffrer la communication.



L’application ne restreins pas les CAs. Aucune entree n’as ete trouve dans le manifest.


Les API (bitpay,bitcoinfees) sur lesquelles sont recuperees les diverse informations sont configureescorrectement.




Le wallet ne verifie pas les certificats.


Oui : INTERNET,ACCESSNETWORKSTATE,CAMERA


L’application ne valide pas correctement les entrees. Elle se contente d’appller la methode trim.


RAS

Test ing Custom URL Schemesdz> run scanner . a c t i v i t y . browsable −a com . a r c b i t . a r c b i t


RAS

Test ing for S e n s i t i v e Func t i ona l i t y Exposure Through IPCEnumerate IPC components with Drozerdz> run app . package . a t t a c k s u r f a c e com . a r c b i t . a r c b i tAttack Sur face :


Content p rov ide r sdz> run app . prov ide r . f i n d u r i com . a r c b i t . a r c b i tScanning com . a r c b i t . a r c b i t . . .No Content URIs found .

A c t i v i t i e sdz> run app . a c t i v i t y . i n f o −a com . a r c b i t . a r c b i t


Package : com . a r c b i t . a r c b i tcom . a r c b i t . a r c b i t . u i . MainActivity

Permiss ion : n u l l

S e r v i c e sdz> run app . s e r v i c e . i n f o −a com . a r c b i t . a r c b i tPackage : com . a r c b i t . a r c b i t


Broadcast Rece ive r sdz> run app . broadcast . i n f o −a com . a r c b i t . a r c b i tPackage : com . a r c b i t . a r c b i t

No matching r e c e i v e r s .


Oui, l’application verifie si le smartphone est roote.

1 public boolean isDeviceRooted ()

2 return buildTags () || checkPaths () || checkSu ();

3

4

5 appDelegate.suggestions.setDisabledShowIsRootedWarning(true);


Pas toutes les librairies utilisees sont a jour. Voici les librairies qui doivent etre mises a jour : mul-tidex(1.0.3), slf4j-api(1.8.0-beta2), bitcoinj-core(0.14.7), commons-io(2.6), commons-lang(3.7), nv-websocket-client(2.5), com.google.zxing :core(3.3.3), fr.avianey.com.viewpagerindicator(2.4.1.1), net-cipher(2.0.0), socket.io-client(1.0.0), crashlytics(2.9.4)



. / apks igner v e r i f y −−verbose /home/nums/Downloads/com . a r c b i t . a r c b i t . apkV e r i f i e sV e r i f i e d us ing v1 scheme (JAR s i g n i n g ) : trueV e r i f i e d us ing v2 scheme (APK Signature Scheme v2 ) : trueNumber o f s i g n e r s : 1

j a r s i g n e r −v e r i f y −verbose −c e r t s /home/nums/Downloads/com . a r c b i t . a r c b i t . apk

sm 3692 Fr i Nov 30 00 : 00 : 00 GMT+01:00 1979 AndroidManifest . xml

X.509 , CN=Timothy Lee , OU=ArcBit , O=ArcBit , L=Davis , ST=CA, C=US[ c e r t i f i c a t e i s v a l i d from 11/22/16 8 :34 AM to 11/16/41 8 :34 AM][ CertPath not va l i da t ed : Path does not chain with any o f the t r u s t

anchors ]


sm 338 Fr i Nov 30 00 : 00 : 00 GMT+01:00 1979 a s s e t s / c r a s h l y t i c s−bu i ld .p r o p e r t i e s

X.509 , CN=Timothy Lee , OU=ArcBit , O=ArcBit , L=Davis , ST=CA, C=US[ c e r t i f i c a t e i s v a l i d from 11/22/16 8 :34 AM to 11/16/41 8 :34 AM][ CertPath not va l i da t ed : Path does not chain with any o f the t r u s t

anchors ]

j a r v e r i f i e d .



dz> run app . package . a t t a c k s u r f a c e com . a r c b i t . a r c b i tAttack Sur face :


Chapitre 8

Bilan

Sommaire8.1 Bilans securitaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

8.1.1 Bitcoin Wallet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

8.1.2 Mycelium Wallet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

8.1.3 Simple Bitcoin Wallet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

8.1.4 Breadwallet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

8.1.5 ArcBit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

8.2 Bilan intermediaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

8.3 Bilan Final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

8.4 Bilan personnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

8.5 Authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

107

108 CHAPITRE 8. BILAN

8.1 Bilans securitaire

8.1.1 Bitcoin Wallet

Les points forts

1. Sauvegarde le wallet sous format d’un fichier chiffre

2. Informe l’utilisateur des menaces

3. Verifie les certificats

4. Sensibilise l’utilisateur sur la qualite du mot de passe de chiffrement

Les points faibles

1. Ne chiffre pas le wallet si le pin n’est pas configure

2. Ne detecte pas si le mobile est roote

3. Ne protege pas l’acces a l’application

4. N’utilise pas de mot de passe, mais un PIN

Le wallet est tout de meme recommandable. Il offre un niveau de securite acceptable.

8.1.2 Mycelium Wallet

Les points forts

1. Sauvegarde une adresse unique sous format d’un fichier chiffre

2. Restreint les CAs et verifie les certificats

3. Assiste l’utilisateur

Les points faibles

8.1.3 Simple Bitcoin Wallet

Les points forts

1. Protege les actions sensibles

2. Utilise un mot de passe et non un PIN

Les points faibles

1. Fuite d’information via capture d’ecran et mise en arriere plan

2. Ne protege pas l’acces a l’application

3. Ne detecte pas si le mobile est roote

4. Ne restreint pas les CAs

5. Ne verifie pas les certificats

6. N’utilise pas de mot de passe, mais un PIN

7. N’informe pas l’utilisateur des menaces potentielles

Le wallet est tout de meme recommandable. Il offre un niveau de securite acceptable.

8.2. BILAN INTERMEDIAIRE 109

8.1.4 Breadwallet

Les points forts

1. Force un mode de deverrouillage


3. Protege correctement l’utilisateur des fuites par capture d’ecran et mise en arriere plan

4. Protege l’acces a l’application


6. Protege les communications avec TLS et verifie les certificats

7. Detecte si mobile roote

8. Propose l’utilisation de l’empreinte digital a la place du PIN

Les points faibles

1. N’informe pas les utilisateurs des menaces potentielles

2. Ne protege pas correctement les fonctionnalite via IPC (

Une responsible disclosure a ete effectue, car le PIN a ete bypasse. Cependant les actions sensiblesont ete correctement protegees. Le wallet est tout de meme recommandable. Il offre un niveau desecurite acceptable.

8.1.5 ArcBit

Les points forts

1. Detecte si mobile roote

2. Protege les communications avec TLS

Les points faibles

1. Ne force pas le deverrouillage du systeme

2. N’informe pas les utilisateurs des menaces potentielles

3. Ne protege pas les actions sensibles

4. N’applique pas de politique de mot de passe satisfaisante

5. Ne restreint pas les CAs et verifie pas les certificats

6. N’utilise pas les dernieres permissions

7. Ne protege pas assez contre les fuites via capture d’ecran ou mise en arriere plan.

Le wallet n’est pas recommandable. Il offre un niveau de securite faible.

8.2 Bilan intermediaire

Bien que l’analyse detaillee n’a pas ete menee jusqu’au bout, certains points meritent d’etre misen avant. L’analyse de la premiere application a releve un point important qui n’a pas ete soulevelors de la documentation des wallets recommandes. Les developpeurs de ce genre d’applications nepartent pas depuis zero. Ils se basent sur des librairies qui implementent pour eux les fonctionnalites.L’utilisation du protocole SPV pour interagir avec le reseau Bitcoin, la generation de la paire de


cles, les differents algorithmes de chiffrement ne sont qu’une petite partie de ce qui est fourni auxdeveloppeurs. Pour conclure, il est necessaire de reprendre la documentation des wallets et de trouverles dependances entre ceux-ci. Premierement, il faut identifier les librairies utilisees en lien avecBitcoin. Ensuite, il faut identifier les wallets qui ont ete developpes sur la base d’autre(s) wallet(s).

8.3. BILAN FINAL 111

8.3 Bilan Final

Ce travail a demontre quatre points essentiels. Premierement, les faiblesses du processus de re-commandation de l’organisation Bitcoin. Deuxiemement, aucun des portefeuilles recommandes nesuit entierement les recommandations de l’OWASP. Troisiemement, comme mentionne dans le bi-lan intermediaire, aucuns des portefeuilles n’implementent la logique Bitcoin. En l’occurrence, ilss’appuient sur la librairie bitcoinj. Si une vulnerabilite venait a etre decouverte, cela aurait un im-pact considerable, puisqu’elle constitue la base d’une majorite de wallets. C’est pourquoi il seraitinteressant de l’auditer. Quatriemement, les HD wallets ont facilites le processus de sauvegarde etreduit la necessite d’effectuer des sauvegardes sur un serveur distant. Avec grande surprise, la quasi-

totalite des portefeuilles utilisent un PIN pour proteger l’acces a l’application ou les actions sensibles.De par sa nature, le PIN est facile cassable et tres peu des applications mettent en place une po-litique des mots de passe robuste, ainsi qu’une politique anti-bruteforce fonctionnelle. La diversitedes approches pour stocker les differentes donnees a egalement ete surprenante. Elles different en unpoints : une fois l’application executee, les donnees stockees dans un fichier chiffre sont chargees enclaire dans la memoire vive. Pour conclure, un bon nombre des fonctionnalites qui permettent d’aug-

menter le niveau de securite est sous le controle du maillon faible de la chaıne. Du a la popularite descrypotmonnaies, il faut compter a present sur des profils diversifies provenant de tous les horizons.Il est donc justifie de forcer ces fonctionnalites. De plus, la securite s’inscrit dans une logique deformation continue. Il est essentiel de sensibiliser les utilisateurs, non seulement a la logique Bitcoin,mais a toutes les risques et les menaces potentielles.

8.4 Bilan personnel

Le temps a ete dans ce travail un facteur determinant. Le soucis du details et la volonte de couvrirun maximum le sujet a porte prejudice au livrable final qui malheureusement reste incomplet. Letravail mene jusqu’ici m’a tout de meme permis d’acquerir de nouvelles competences et m’as permisde souligner mes points faibles : la rigueur, la planification et le sens des priorites. L’energie et letemps investi dans ce travail n’est a la hauteur que de ma frustration, celle de ne pas avoir reussia fournir la qualite esperee. A travers ce travail aux multiples facettes, j’ai decouvert les enjeux des

cryptomonnaies. J’ai pu appliquer les notions acquises lors de ma formation au sein de la HEIG-VDet approfondir mes connaissances en developpement logiciel, ainsi qu’en modelisation de menaces.

8.5 Authentification

Emmanuel Schmid atteste avoir realise seul ce travail et que toutes les sources utilisees ont etementionnees, si ce n’est les connaissances acquises durant ses etudes et son experience professionnelle.Lieu, date :

Remarques diverses

• Une grande partie du temps a ete accorde a la comprehension du sujet et la documentationdes concepts de bases.


• Il existe evidemment d’autre vulnerabilites qui n’ont pas ete abordees dans le rapport. L’ob-jectif est d’identifier les meilleures pistes pour proteger les wallets. La securite est un domainecomplexe qui n’est jamais parfait.

• Bien que les vulnerabilites soient mises en avant, ce rapport s’inscrit dans une logique desensibilisation et d’amelioration de la securite des wallets.

Chapitre 9

Bibliographie

9.0.1 Bibliographie

[1] Application threat modeling. https://www.owasp.org/index.php/Application_Threat_

Modeling.

[2] Bip : 33. https://github.com/bitcoin/bips/blob/master/bip-0033.mediawiki.




[6] Bitcoin vocabulary. https://bitcoin.org/en/vocabulary.

[7] Comprendre le bitcoin et la blockchain. https://openclassrooms.com/courses/

comprendre-le-bitcoin-et-la-blockchain.

[8] Cryptographie. https://fr.wikipedia.org/wiki/Cryptographie.

[9] Cryptographie asymetrique. https://fr.wikipedia.org/wiki/Cryptographie_asym\

unhbox\voidb@x\bgroup\let\unhbox\voidb@x\setbox\@tempboxa\hboxe\global\

mathchardef\accent@spacefactor\spacefactor\accent19e\egroup\spacefactor\

accent@spacefactortrique.

[10] Cryptographie sur les courbes elliptiques. https://fr.wikipedia.org/wiki/Cryptographie_sur_les_courbes_elliptiques.

[11] Cryptographie symetrique. https://fr.wikipedia.org/wiki/Cryptographie_sym\

unhbox\voidb@x\bgroup\let\unhbox\voidb@x\setbox\@tempboxa\hboxe\global\

mathchardef\accent@spacefactor\spacefactor\accent19e\egroup\spacefactor\

accent@spacefactortrique.

[12] Deterministic wallet. https://en.bitcoin.it/wiki/Deterministic_wallet.

[13] Developper guide. https://bitcoin.org/en/developer-guide.

[14] Fonction de hachage. https://fr.wikipedia.org/wiki/Fonction_de_hachage.

[15] Fonctionnement bitcoin. https://bitcoin.org/fr/.

[16] Fonctionnement bitcoin. https://fr.wikipedia.org/wiki/Bitcoin.

[17] Histoire de la monnaie. https://fr.wikipedia.org/wiki/Histoire_de_la_monnaie.

113

https://www.owasp.org/index.php/Application_Threat_Modeling

https://www.owasp.org/index.php/Application_Threat_Modeling

https://github.com/bitcoin/bips/blob/master/bip-0033.mediawiki




https://bitcoin.org/en/vocabulary

https://openclassrooms.com/courses/comprendre-le-bitcoin-et-la-blockchain

https://openclassrooms.com/courses/comprendre-le-bitcoin-et-la-blockchain

https://fr.wikipedia.org/wiki/Cryptographie

https://fr.wikipedia.org/wiki/Cryptographie_asym\unhbox \voidb@x \bgroup \let \unhbox \voidb@x \setbox \@tempboxa \hbox e\global \mathchardef \accent@spacefactor \spacefactor \accent 19 e\egroup \spacefactor \accent@spacefactor trique




https://fr.wikipedia.org/wiki/Cryptographie_sur_les_courbes_elliptiques

https://fr.wikipedia.org/wiki/Cryptographie_sur_les_courbes_elliptiques

https://fr.wikipedia.org/wiki/Cryptographie_sym\unhbox \voidb@x \bgroup \let \unhbox \voidb@x \setbox \@tempboxa \hbox e\global \mathchardef \accent@spacefactor \spacefactor \accent 19 e\egroup \spacefactor \accent@spacefactor trique




https://en.bitcoin.it/wiki/Deterministic_wallet

https://bitcoin.org/en/developer-guide

https://fr.wikipedia.org/wiki/Fonction_de_hachage

https://bitcoin.org/fr/

https://fr.wikipedia.org/wiki/Bitcoin

https://fr.wikipedia.org/wiki/Histoire_de_la_monnaie

114 CHAPITRE 9. BIBLIOGRAPHIE

[18] Implementation-bitcoin. https://pascalpares.gitbooks.io/implementation-bitcoin/

content/.

[19] Le reseau de mineurs. https://openclassrooms.com/courses/

comprendre-le-bitcoin-et-la-blockchain/le-principe-du-bitcoin-2-2-le-reseau-de-mineurs.

[20] Les monnaies electroniques decentralisees(comme le bitcoin).

[21] Mobile AppSec Verification.

[22] Multisignature. https://en.wikipedia.org/wiki/Multisignature.

[23] OCTAVE Allegro.

[24] owasp. https://www.owasp.org/index.php/Main_Page.

[25] Owasp : Testing-code-quality-and-build-settings. https://github.com/OWASP/owasp-mstg/

blob/master/Document/0x05i-Testing-Code-Quality-and-Build-Settings.md.

[26] Owasp : Testing-cryptography. https://github.com/OWASP/owasp-mstg/blob/master/

Document/0x05e-Testing-Cryptography.md.

[27] Owasp : Testing-data-storage. https://github.com/OWASP/owasp-mstg/blob/master/

Document/0x05d-Testing-Data-Storage.md.

[28] Owasp : Testing-network-communication. https://github.com/OWASP/owasp-mstg/blob/

master/Document/0x05g-Testing-Network-Communication.md.

[29] Owasp : Testing-platform-interaction. https://github.com/OWASP/owasp-mstg/blob/

master/Document/0x05h-Testing-Platform-Interaction.md.

[30] Owasp :testing-local-authentication. https://github.com/OWASP/owasp-mstg/blob/master/

Document/0x05f-Testing-Local-Authentication.md.

[31] Stride. https://en.wikipedia.org/wiki/STRIDE_(security).

[32] Securiser votre portefeuille. https://bitcoin.org/fr/securiser-porte-monnaie.

[33] Wallets. https://github.com/bitcoin-dot-org/bitcoin.org/blob/master/docs/

managing-wallets.md.

[34] Why every bitcoin user should understand spv security. https://medium.com/

@jonaldfyookball/why-every-bitcoin-user-should-understand-spv-security-520d1d45e0b9.

[35] Wiki bitcoin. https://en.bitcoin.it/wiki/Main_Page.

[36] Wiki bitcoin. https://blockchain.info/fr/charts/blocks-size.

[37] Wiki bitcoin. https://blockchain.info/fr/charts/blocks-size.

[38] Christian H Kateraas. Threats to Bitcoin Software. PhD thesis, Norwegian University of Scienceand Technology, 2014.

[39] Satoshi Nakamoto. Bitcoin : A peer-to-peer electronic cash system. Technical report,www.bitcoin.org, 2008.

https://pascalpares.gitbooks.io/implementation-bitcoin/content/

https://pascalpares.gitbooks.io/implementation-bitcoin/content/

https://openclassrooms.com/courses/comprendre-le-bitcoin-et-la-blockchain/le-principe-du-bitcoin-2-2-le-reseau-de-mineurs

https://openclassrooms.com/courses/comprendre-le-bitcoin-et-la-blockchain/le-principe-du-bitcoin-2-2-le-reseau-de-mineurs

https://en.wikipedia.org/wiki/Multisignature

https://www.owasp.org/index.php/Main_Page

https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05i-Testing-Code-Quality-and-Build-Settings.md

https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05i-Testing-Code-Quality-and-Build-Settings.md

https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05e-Testing-Cryptography.md

https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05e-Testing-Cryptography.md

https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05d-Testing-Data-Storage.md

https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05d-Testing-Data-Storage.md

https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05g-Testing-Network-Communication.md

https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05g-Testing-Network-Communication.md

https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05h-Testing-Platform-Interaction.md

https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05h-Testing-Platform-Interaction.md

https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05f-Testing-Local-Authentication.md

https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05f-Testing-Local-Authentication.md

https://en.wikipedia.org/wiki/STRIDE_(security)

https://bitcoin.org/fr/securiser-porte-monnaie

https://github.com/bitcoin-dot-org/bitcoin.org/blob/master/docs/managing-wallets.md

https://github.com/bitcoin-dot-org/bitcoin.org/blob/master/docs/managing-wallets.md

https://medium.com/@jonaldfyookball/why-every-bitcoin-user-should-understand-spv-security-520d1d45e0b9

https://medium.com/@jonaldfyookball/why-every-bitcoin-user-should-understand-spv-security-520d1d45e0b9

https://en.bitcoin.it/wiki/Main_Page

https://blockchain.info/fr/charts/blocks-size

https://blockchain.info/fr/charts/blocks-size

Chapitre 10

Annexes

Sommaire10.0.1 Les portefeuilles Bitcoin recommandes . . . . . . . . . . . . . . . . . . . . 116

10.0.1.1 Airbitz Wallet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

10.0.1.2 ArcBit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

10.0.1.3 Bitcoin Wallet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

10.0.1.4 Bither . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

10.0.1.5 Breadwallet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

10.0.1.6 Coin.Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

10.0.1.7 Electrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

10.0.1.8 GreenAddress . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

10.0.1.9 GreenBits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

10.0.1.10 Mycelium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

10.0.1.11 Simple Bitcoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

10.1 Journal de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

115

116 CHAPITRE 10. ANNEXES

10.0.1 Les portefeuilles Bitcoin recommandes

10.0.1.1 Airbitz Wallet

Site officiel https ://airbitz.co/

Documentation https ://developer.airbitz.co/android/docs/userguide.html

Google Play https ://play.google.com/store/apps/details ?id=com.airbitz

Source https://github.com/Airbitz/airbitz-core-java

Developpe par Airbitz

Contact [email protected]

Politique de confidentialite https ://airbitz.co/privacy-policy/

Version 2.4.7

Nombre d’installations Entre 100 000 et 500 000

Recommandee depuis 10 fevrier 2015

Validation https://github.com/bitcoin-dot-org/bitcoin.org/pull/652

Date derniere release 29 septembre 2017

Fonctionnalites — Backup automatique

— Chiffrement du cote client

— Synchronisation entre plusieurs appereils

— Authentification a 2 facteurs

— Recuperation de mot de passe

— HD wallet

— Ordre de transaction via QR code, email/sms, BTE, NFC

— Recherche par beneficiaire, categorie ou notes

— Limites de depenses

— Architecture de serveur decentralise

Categorie Hybrid, Multisig wallets

Criteres Processus

Control Validation Transparency Environment PrivacyHybrid Valiation centralise Open source Environnement

mobileBasic privacy

Privacycheck

Address reuse Privacy Disclosure Privacy NetworkAddress rotation failprivacydisclosureaccount tor not supported

https://github.com/Airbitz/airbitz-core-java

https://github.com/bitcoin-dot-org/bitcoin.org/pull/652

117

10.0.1.2 ArcBit

Site officiel https://arcbit.io

Documentation

Google Play https ://play.google.com/store/apps/details ?id=com.arcbit.arcbit

Source https://github.com/arcbit/arcbit-android

Developpe par ArcBit


Politique de confidentialite n/a

Version 1.0.21


Recommandee depuis 16 fevrier 2017 (version 1.0.5)

Validation https ://github.com/bitcoin-dot-org/bitcoin.org/pull/1459

Date derniere release 15 janvier 2018

Fonctionnalites — Recuperation de mot de passe

— Protection par PIN

— HD wallet

— Importation de cle privees (PIB38, HD)

— Choix de l’API des exploraterus de blocs

— Cold wallet

— Mode avance

— Support email integree a l’application

— Changement en devises standard

— cle xpub stocke du cote client

— Automatic cycling of addresses to prevent address reuse


Criteres Processus

Control Validation Transparency Environment PrivacyFull control Valiation centralise Open source Environnement

mobileBasic privacy

Privacycheck

Address reuse Privacy Disclosure Privacy NetworkAddress rotation checkfailprivacydisclosurecentralizedtor not supported

https://arcbit.io

https://github.com/arcbit/arcbit-android


10.0.1.3 Bitcoin Wallet

Site officiel https://github.com/bitcoin-wallet/bitcoin-wallet

Documentation https://github.com/bitcoin-wallet/bitcoin-wallet/wiki

Google Play https://play.google.com/store/apps/details?id=de.schildbach.

wallet

Source https://github.com/bitcoin-wallet/bitcoin-wallet

Developpe par Bitcoin Wallet developers


Politique de confidentialite https://github.com/bitcoin-wallet/bitcoin-wallet/wiki/PrivacyPolicy

Version 6.04

Nombre d’installations Entre 1 000 000 et 5 000 000

Recommandee depuis

Validation

Date derniere release 18 mars 2018

Fonctionnalites — Porte-monnaie decentralise

— Affichage du montant de bitcoins en BTC, mBTC et uBTC

— Conversion vers et a partir de monnaies nationales

— Envoi et reception de bitcoins par NFC, codes QR ou URLBitcoin

— Quand vous etes hors ligne, vous pouvez quand meme payer parBluetooth

— Carnet d’adresses pour les adresses Bitcoin utilisees regulierement

— Notifications

Categorie SPV, Random servers

Criteres Processus

Control Validation Transparency Environment PrivacyFull control SPV Open source Environnement

mobileBasic privacy

Privacycheck

Address reuse Privacy Disclosure Privacy NetworkAddress rotation failprivacydisclosurespv tor not supported

https://github.com/bitcoin-wallet/bitcoin-wallet

https://github.com/bitcoin-wallet/bitcoin-wallet/wiki

https://play.google.com/store/apps/details?id=de.schildbach.wallet

https://play.google.com/store/apps/details?id=de.schildbach.wallet

https://github.com/bitcoin-wallet/bitcoin-wallet

https://github.com/bitcoin-wallet/bitcoin-wallet/wiki/PrivacyPolicy

119

10.0.1.4 Bither

Site officiel https://bither.net/

Documentation https://breadapp.com/support/

Google Play https://play.google.com/store/apps/details?id=net.bither

Source https://github.com/bither/

Developpe par getcai

Contact [email protected] ou [email protected]

Politique de confidentialite https://github.com/bither/bither-android/wiki/PrivacyPolicy

Version 1.8.2


Recommandee depuis 5 Mai 2015 (version 1.3.1/1.3.4)


Date derniere release 5 fevrier 2018

Fonctionnalites — Wallet connecte ou hors ligne

— Communication entre portefeuille connecte et hors ligne via QRcodes

— Protection par mot de passe

— Monitoring du reseau (wifi, 3g, BT)

— Backup automatique

— Architecture de serveur decentralise

— Notifications

— Taux de change en temps reelle des platformes majeurs Bitcoin


Criteres Processus


mobileWeak privacy

Privacycheck

Address reuse Privacy Disclosure Privacy Networkfail address rotation failprivacydisclosurespv tor not supported

https://bither.net/

https://breadapp.com/support/

https://play.google.com/store/apps/details?id=net.bither

https://github.com/bither/

https://github.com/bither/bither-android/wiki/PrivacyPolicy



10.0.1.5 Breadwallet

Site officiel https://breadapp.com

Documentation https://breadapp.com/support/

Google Play https://play.google.com/store/apps/details?id=com.breadwallet

Source https://github.com/breadwallet/breadwallet-android

Developpe par breadwallet


Politique de confidentialite https://breadapp.com/privacy-policy/

Version 205


Recommandee depuis 3 novembre 2016



Fonctionnalites — Protection par mot de passe

— Backup password

— Pas de serveur intermediaire

— Importation de cles privees


Criteres Processus


mobileBasic privacy

Privacycheck

Address reuse Privacy Disclosure Privacy NetworkAddress rotation failprivacydisclosurespv tor not supported

https://breadapp.com

https://breadapp.com/support/

https://play.google.com/store/apps/details?id=com.breadwallet

https://github.com/breadwallet/breadwallet-android

https://breadapp.com/privacy-policy/


121

10.0.1.6 Coin.Space

Site officiel https://www.coin.space

Documentation https://coinspace.zendesk.com/hc/en-us

Google Play https://play.google.com/store/apps/details?id=com.coinspace.

app

Source https://github.com/CoinSpace/CoinSpace

Developpe par CoinSpace


Conditions d’utilisation https://www.coin.space/terms-of-service.html

Politique de confidentialite https://www.coin.space/coinspaceprivacypolicy.html

Version 2.5.0


Recommandee depuis 17 juin 2016 (v. 2.1.3)



Fonctionnalites — HD wallet

— Ordre de transactions par Qr code

— Geolocation (Mecto) pour des transactions avec des personnesa proximitees

— Conversion dans une devise standard




Criteres Processus

Control Validation Transparency Environment PrivacyFull control Validation centra-

liseefail - Nouvelle ap-plication

Environnementmobile

Basic privacy

Privacycheck

Address reuse Privacy Disclosure Privacy NetworkAddress rotation checkfailprivacydisclosureaccount tor not supported

https://www.coin.space

https://coinspace.zendesk.com/hc/en-us

https://play.google.com/store/apps/details?id=com.coinspace.app

https://play.google.com/store/apps/details?id=com.coinspace.app

https://github.com/CoinSpace/CoinSpace

https://www.coin.space/terms-of-service.html

https://www.coin.space/coinspaceprivacypolicy.html



10.0.1.7 Electrum

Site officiel https://electrum.org/#home

Documentation http://docs.electrum.org/en/latest/

Google Play https://play.google.com/store/apps/details?id=org.electrum.

electrum

Source https://github.com/spesmilo/electrum

Developpe par Electrum Technologies GmbH


Conditions d’utilisation https://electrum.org/#disclaimer

Politique de confidentialite https://electrum.org/#privacy

Version 3.1.1.0


Recommandee depuis 17 octobre 2016



Fonctionnalites — Chiffrement du cote client

— Backup a partir d’un password

— Exporter des cles privees

— Verifie toutes les transactions de l’historique (SVP)

— Garde les cles privees hors ligne et aller en ligne avec un wallet”Watching-only”



— Server decentralise

— Wallet hors ligne


Criteres Processus


mobileBasic privacy

Privacycheck


https://electrum.org/#home

http://docs.electrum.org/en/latest/

https://play.google.com/store/apps/details?id=org.electrum.electrum

https://play.google.com/store/apps/details?id=org.electrum.electrum

https://github.com/spesmilo/electrum

https://electrum.org/#disclaimer

https://electrum.org/#privacy


123

10.0.1.8 GreenAddress

Site officiel https://greenaddress.it/en/

Documentation https://greenaddress.it/en/faq.html

Google Play https://play.google.com/store/apps/details?id=it.greenaddress.

cordova

Source https://github.com/greenaddress/WalletCordova

Developpe par GreenAddress IT Ltd


Politique de confidentialite https://greenaddress.it/en/privacy.html

Version 0.0.88


Recommandee depuis 11 avril 2014


Date derniere release 16 decembre 2017

Fonctionnalites — Authentification a 2 facteurs (phone/sms/e-mail)

— Multisignature

— Confirmation de transactions instantanees avec l’attestation Gree-nAddress

— En cas de disparition de service, les fonds peuvent etre recuperesvia les transactions nLockTime et outils open-source

— Backup papier via BIP39 mnemonics


Criteres Processus

Control Validation Transparency Environment PrivacyMulti control Validation

decentraliseeOpen source Authentification 2

facteursBasic privacy

Privacycheck


https://greenaddress.it/en/

https://greenaddress.it/en/faq.html

https://play.google.com/store/apps/details?id=it.greenaddress.cordova

https://play.google.com/store/apps/details?id=it.greenaddress.cordova

https://github.com/greenaddress/WalletCordova

https://greenaddress.it/en/privacy.html



10.0.1.9 GreenBits

Site officiel https://greenaddress.it/en/

Documentation https://greenaddress.it/en/faq.html

Google Play https://play.google.com/store/apps/details?id=com.greenaddress.

greenbits_android_wallet

Source https://github.com/greenaddress/GreenBits

Developpe par GreenAddress IT Ltd


Politique de confidentialite https://greenaddress.it/en/privacy.html

Version 0.0.88


Recommandee depuis 1 decembre 2015



Fonctionnalites — Validation SPV cote client

— Connection a un full node pour une securite accrue (meme avecTor)

— Backup papier via BIP39 mnemonics

— Authentification a 2 facteurs (phone/sms/e-mail)

— Multisignature

— Confirmation de transactions instantanees avec l’attestation Gree-nAddress

— En cas de disparition de service, les fonds peuvent etre recuperesvia les transactions nLockTime et outils open-source

— Hardware wallet


Criteres Processus

Control Validation Transparency Environment PrivacyMulti control SPV Open source Authentification 2

facteursBasic privacy

Privacycheck


https://greenaddress.it/en/

https://greenaddress.it/en/faq.html

https://play.google.com/store/apps/details?id=com.greenaddress.greenbits_android_wallet

https://play.google.com/store/apps/details?id=com.greenaddress.greenbits_android_wallet

https://github.com/greenaddress/GreenBits

https://greenaddress.it/en/privacy.html


125

10.0.1.10 Mycelium

Site officiel https://wallet.mycelium.com

Documentation https://mycelium-support.zendesk.com/hc/en-us/categories/

115000428552-BTC-Wallet

Google Play https://play.google.com/store/apps/details?id=com.mycelium.

wallet

Source https://github.com/mycelium-com/wallet-android

Developpe par Mycelium Developers


Politique de confidentialite https://wallet.mycelium.com/download/privacy.txt

Version 2.9.11.7

Nombre d’installations Entre 500 000 et 1 000 000

Recommandee depuis 21 septembre 2013


Date derniere release 24 fevrier 2018

Fonctionnalites — HD wallet (Bip32/Bip44)

— Backup (Bip39)

— Converstion en une devise standard

— Carnet d’adresses pour les adresses frequemment utilisees

— Transaction avec informations detailees

— Exporter les cles privees, xPub ou xPriv en tant que QR codes,sur le presse-papiers ou partager avec d’autres applications

— Partagez votre adresse bitcoin en utilisant Twitter, Facebook,email et plus.

— Scanneur de QR code integre

— Charge repartie sur plusieurs serveurs

— Watch-only addresses


Criteres Processus

Control Validation Transparency Environment PrivacyMulti control Validation centra-

liseeOpen source Envrionnement

mobileBasic privacy

Privacycheck

Address reuse Privacy Disclosure Privacy NetworkAddress rotation checkfailprivacydisclosurecentralizedtor not supported

https://wallet.mycelium.com

https://mycelium-support.zendesk.com/hc/en-us/categories/115000428552-BTC-Wallet

https://mycelium-support.zendesk.com/hc/en-us/categories/115000428552-BTC-Wallet

https://play.google.com/store/apps/details?id=com.mycelium.wallet

https://play.google.com/store/apps/details?id=com.mycelium.wallet

https://github.com/mycelium-com/wallet-android

https://wallet.mycelium.com/download/privacy.txt



10.0.1.11 Simple Bitcoin

Site officiel https://btcontract.com

Documentation

Google Play https://play.google.com/store/apps/details?id=com.btcontract.

wallet

Source https://github.com/btcontract/wallet

Developpe par Anton Kumaigorodski


Politique de confidentialite n/a

Version 1.075


Recommandee depuis 17 Juin 2017 (1.07)



Fonctionnalites — HD wallet

— Chiffrement du cote client

— Toutes les donnees pertinentes sont recuperees a partir du fullBitcoin nods a distance en utilisant SPV.


Criteres Processus

Control Validation Transparency Environment PrivacyFull control SPV Open source Envrionnement

mobileBasic privacy

Privacycheck

Address reuse Privacy Disclosure Privacy NetworkAddress rotation checkfailprivacydisclosurespv tor not supported

https://btcontract.com

https://play.google.com/store/apps/details?id=com.btcontract.wallet

https://play.google.com/store/apps/details?id=com.btcontract.wallet

https://github.com/btcontract/wallet


10.1. JOURNAL DE TRAVAIL 127

10.1 Journal de travail

Le tableau suivant represente le journal de travail jusqu’au rendu intermediaire.


Le tableau suivant represente le journal de travail depuis le rendu intermediaire jusqu’au rendufinal.

Les portefeuilles Bitcoin recommandés pour Android sont-ils ...

Documents

Transcript of Les portefeuilles Bitcoin recommandés pour Android sont-ils ...