Protéger les secrets de son code mobile Android avec Git-crypt 📱💻🔐

Photo by Max Bender on Unsplash

Protéger les secrets de son code mobile Android avec Git-crypt 📱💻🔐

#Android #mobile #security#opensource #tutorial #cryptography

Cet article va permettre de présenter l’outil open source Git-crypt, utilisé afin de protéger les secrets (clés d’API, tokens, mots de passes, …) d'un répertoire Git. L’article va contenir un tutoriel réalisé sur Mac afin de suivre pas à pas le chiffrement et le déchiffrement assuré par l’outil dans le cadre d’un projet mobile Android. Un avis sera donné sur cet outil à la fin de cet article.

Précisions
Habituellement en développement web les secrets sont portés par la CI et injectés au moment des pipelines de build, environnement par environnement. Sur Git, il n’y a qu’une configuration locale qui ne nécessite pas d’être chiffrée. Dans ces cas là, l’utilisation de Git-crypt ne se justifie pas... Cependant, en développement mobile les équipes de peuvent être amenées à construire des builds sur différents environnements depuis leur poste, dans ce cas l'utilisation de Git-crypt pour les protéger fait sens.

Introduction


Du fait de son essor et de sa lucrativité, le développement (mobile et web) a attiré malgré lui nombre d’utilisateurs malveillants. Protéger son application apparait donc comme primordial. En effet, ne pas le faire peut coûter cher, on ne compte plus les scandales et autres piratages récents. L’article du jour va traiter d’une méthodologie de chiffrement des données confidentielles présentes à l’intérieur du code, cette méthodologie pourra être utilisée dans le cadre d’une solution plus complexe de sécurisation d’une application. Plus spécifiquement laisser en clair dans le code des mots de passes, clés d’API, crée le risque que quiconque qui parvient à obtenir le code du projet y ait accès. Si cet utilisateur s’avère être malveillant, mieux vaut ne pas imaginer ce qu’il pourrait faire de ces informations récoltées.

Heureusement des solutions de protections existent, les outils permettant de crypter les données d’une application sont variés, tant open-source que payants (Git-crypt, BlackBox, SOPS, Transcrypt, HashiCorp Vault, AWS Secrets Manager, …). Dans cet article, nous allons nous focaliser sur Git-crypt qui a l’air de sortir son épingle du jeu.

Présentation de Git-crypt


Git-crypt est un outil open source disponible sur GitHub : https://github.com/AGWA/git-crypt. Il a pour objectif d’encrypter et de décrypter certains fichiers d’un répertoire Git. Plutôt populaire, il est utilisé par des milliers de projets qu’ils soient web ou mobile. Mis au point il y a 10 ans il est régulièrement mis à jour, sa fiabilité n’est plus à démontrer. Autre point fort, il est rapide à mettre en place et fonctionne bien. Plus de temps à perdre, nous allons le mettre en place sans tarder.

Prise en main


Configuration utilisée
Le tutoriel suivant est réalisé sur un projet mobile Android et sur MacBook Pro Ventura 13.5.2.

Installation

Il va tout d’abord falloir installer Git-crypt sur sa machine, pour cela je vais utiliser Homebrew (https://brew.sh/), un gestionnaire de package très pratique sur MacOs. Il suffit d’installer brew et de taper la commande suivante pour installer Git-crypt : brew install git-crypt.

Initialisation

Il va falloir maintenant initialiser l’outil dans notre répertoire, pour effectuer ceci on va se déplacer dans notre répertoire puis lancer la commande git-crypt init.

Cette commande a permis la génération d’une clé, il va nous falloir maintenant l’exporter dans un fichier. Pour effectuer ceci, on peut utiliser la commande git-crypt export-key.

En se rendant à la racine de notre projet, nous pouvons nous rendre compte que la clé a bien été exportée. Nous pouvons ouvrir le fichier et visualiser la clé aléatoire générée.

Chiffrement

Nous allons maintenant passer à la phase de chiffrement, nous aurons préalablement besoin de définir les règles de chiffrement. Pour effectuer ceci, il va maintenant nous falloir créer un fichier caché .gitattributes à la racine du projet. Dedans, nous pouvons définir quels fichiers crypter et lesquels ne surtout pas crypter. Voici un exemple de fichier .gitattributes où nous allons encrypter le fichier gradle.properties, où sont stockées des clés et tokens. Mais nous aurions très bien pu masquer d’autres fichiers, comme par exemple le keystore.

Il est important de noter qu’ici la ligne !filter !diff permet d’empêcher le chiffrement d'un fichier, ce qui est utile dans notre cas car il ne faudrait pas crypter notre clé par erreur.

En analysant notre projet, nous pouvons nous rendre compte que le .gitattributes apparait bien. S’il est invisible on peut utiliser les commandes “Command+Shift+.” pour le faire apparaitre.

Une fois ces règles définies nous allons pouvoir crypter nos fichiers. Nous pouvons visualiser le statut de chiffrement du répertoire en utilisant la commande git-crypt status.

Celle-ci va nous retourner la liste de tous les fichiers du répertoire ainsi que leur statut.

Dans notre cas, nous pouvons remarquer que le fichier build.gradle n’est pas encrypté, ça tombe bien nous n’avons pas demandé à le faire. En revanche le fichier gradle.properties à l’air d’être encrypté mais seulement en local, pour le pousser nous allons avoir besoin de la commande git-crypt status force pour forcer les changements.

Le fichier a l’air d’être bien encrypté, nous pouvons le vérifier en relançant la commande précédente.

Tout a l’air de bien fonctionner, le chiffrement n’apparait pas en local car nous possédons la clé de chiffrement. Nous allons maintenant pousser nos changements et essayer de décrypter notre projet. Il faut faire attention à ne pas pousser la clé de chiffrement sur le répertoire Git, sinon tout ce qu’on a fait n’aura servi à rien. En ouvrant le fichier gradle.properties dans le répertoire Git en ligne, nous nous rendons compte que le fichier est bien crypté et donc incompréhensible.

Nous allons maintenant nous mettre dans la peau d’un utilisateur qui récupère le projet et allons essayer de le décrypter.

chiffrement

Afin de présenter le processus de déchiffrement je vais supprimer le projet de ma machine et le réinstaller, en tenant compte de bien garder la clé utilisée pour le chiffrement a portée de main car sans je ne pourrai pas décrypter le projet.

Lorsque j’essaye de lancer le projet, le build fail. C’est normal car en observant le code on se rend compte que le fichier gradle.properties est bien crypté comme voulu. Si l’utilisateur ne possède pas la clé de déchiffrement il ne pourra pas compiler le projet et visualiser les secrets.

Afin de procéder au déchiffrement nous allons avoir besoin d’utiliser Git-crypt, s’il n’est pas installé sur la machine, il est possible de le faire en se référant à la section installation.

Pour le déchiffrement, nous allons avoir besoin de notre clé de chiffrement, nous allons placer ce fichier à la racine du projet et lancer la commande git-crypt unlock à la racine du projet.

Notre projet est décrypté, on peut le vérifier en observant notre fichier gradle.properties.

Pour aller plus loin

Encrypter les données c’est bien me diriez-vous, mais comment va-t-on pouvoir utiliser notre CI/CD si les données sont cryptées ? Il n’y a aucun problème, il est possible d’exécuter Git-crypt avant le build pour que les secrets ne soient pas masqués. Voici un exemple la solution Bitrise en utilisant un step script avant le build et en plaçant la clé dans les secrets :

Avis


Maintenance (7/10)

Le projet est apparu il y a quasiment 10 ans et il a été maintenu sur toute cette période. Sa dernière mise à jour remonte à avril 2022. Selon le site https://linuxsecurity.expert/tools/git-crypt/, le projet est fiable à 74%.

Il est important de noter que le propriétaire du répertoire compte mettre au point une version 1.0. De plus, le projet est également très populaire sur GitHub et utilisé pour de nombreux types de projet, ce qui permet de nous rassurer quant à sa maintenance.

Utilisation (9/10)

Git-crypt est un outil simple d’utilisation et rapide à mettre en place, en 10/15 minutes le projet est configuré. Le fait qu’il soit configurable et que l’on puisse choisir les fichiers à crypter est un atout fort également. La seule ombre au tableau concerne la gestion de la clé de chiffrement car il ne faut pas la pousser sur le répertoire Git et la transmettre à chacun des collaborateurs, ce qui peut être fastidieux.

Sécurité (8/10)

Git-crypt est l’un des outils les plus sécurisés sur le marché, cela s’explique par le fait qu’il repose sur le chiffrement AES-256 (Advanced Encryption Standard) en mode CTR. C’est un algorithme symétrique, il utilise la même clé pour le chiffrage et le déchiffrage. Son implémentation sur 256 bits est la plus sécurisée de la famille de standards AES. Elle a été approuvée par la NSA et est encore utilisée aujourd’hui pour la protection de nombreuses agences gouvernementales et banques. AES 256 est ainsi l’un des algorithmes les plus compliqués à casser.

Git-crypt dépend de git filter qui n’a pas été particulièrement conçu pour la sécurité, notre outil va être plus performant si une petite partie des fichiers est cryptée et non pas l’ensemble. Il reste primordial de sécuriser l’accès au répertoire Git en le mettant en protected ou en private.

Conclusion


Au fil des tests de cet outil, j’ai été agréablement surpris par sa facilité d’utilisation. Étant assez bien maintenu et sécurisé je recommande son utilisation pour chiffrer les secrets de son projet. Il peut être également intéressant de tester d'autres outils similaires en fonction de ses besoins. Cependant, il est impératif d’utiliser des méthodes de sécurité complémentaires pour limiter les vulnérabilités et faille de son projet. Par exemple, dans le cadre d’un projet mobile, il est important de n’utiliser que des dépendances fiables et à jour, d’avoir une bonne couverture de tests, d’avoir son code le plus à jour possible, … Avant de nous dire au revoir, il est important de préciser que Git Crypt est un outil qui permet de chiffrer le code sur un dépôt, mais il ne prémunit pas d’une décompilation de l’app, et les secrets sont toujours visibles dans le binaire de ton app : il ne faut pas le confondre avec une solution d’obfuscation de code.

Sources