Chiffrement d’enveloppe ou SQLCipher pour une app Android

Lorsqu’une app mobile stocke des données sensibles en local, le conseil par défaut sur Android est presque automatique : utilisez SQLCipher. C’est une solution mature, bien connue, qui chiffre toute la base de données.

Lors d’un audit de sécurité et d’une remédiation pour l’app Android d’une banque de détail, nous avons choisi une autre approche : le chiffrement d’enveloppe des valeurs sensibles elles-mêmes, avec des clés conservées dans l’Android Keystore. Dans cet article, nous présentons les deux options, nous expliquons pourquoi le chiffrement d’enveloppe convenait à cette app et ce à quoi nous avons renoncé pour y parvenir.

Le problème : les données sensibles stockées sur l’appareil

Les apps bancaires mettent des données en cache pour rester rapides et utilisables hors ligne : informations de compte, transactions récentes, données de profil. Si ces données restent en clair sur l’appareil, un téléphone rooté, une sauvegarde ou une copie forensique peut les exposer. Dans l’OWASP Mobile Top 10 (2024), cela relève de M9 : Insecure Data Storage (stockage de données non sécurisé) et de M10 : Insufficient Cryptography (cryptographie insuffisante).

Option 1 : SQLCipher

SQLCipher est un fork de SQLite qui chiffre l’intégralité du fichier de base de données.

Atout : tout est chiffré, index et métadonnées compris.
Atout : les données chiffrées restent entièrement interrogeables.
Coût : des bibliothèques natives pour chaque architecture de processeur, qui alourdissent l’app.
Coût : la clé de la base doit malgré tout être protégée, généralement par le Keystore de toute façon.

Option 2 : le chiffrement d’enveloppe

Le chiffrement d’enveloppe fonctionne avec deux niveaux de clés :

Une clé de chiffrement des données (DEK) chiffre les valeurs sensibles avec un algorithme de chiffrement authentifié comme AES-GCM.
Une clé de chiffrement de clés (KEK) conservée dans l’Android Keystore encapsule la DEK. Le code de l’app ne voit jamais la KEK, et sur les appareils compatibles, elle est adossée au matériel.

📌 À retenir :

Dans les deux approches, la véritable protection vient du Keystore. Le choix porte sur ce que vous chiffrez avec : le fichier entier, ou seulement les valeurs qui comptent.

Pourquoi le chiffrement d’enveloppe convenait à cette app

1. La plupart des données stockées n’étaient pas sensibles

Une grande partie de la base locale contenait de la configuration d’interface et d’autres données non sensibles. Chiffrer précisément les valeurs sensibles protégeait l’essentiel sans changer le fonctionnement du reste de la base.

2. La taille de l’app comptait

Se passer de SQLCipher a permis d’économiser environ 6,5 Mo de code natif. Pour une app bancaire que de nombreux utilisateurs installent sur des téléphones milieu de gamme via les données mobiles, la différence est réelle.

3. Le coût en performance était mesurable et faible

Nous avons mesuré le surcoût du déchiffrement des valeurs affichées par chaque écran : environ 1 ms par écran — bien en dessous de tout ce qu’un utilisateur pourrait percevoir.

4. Un seul modèle de clés pour tout

Le même modèle de clés adossé au Keystore peut protéger les valeurs dans la base de données, dans les préférences et dans les fichiers, au lieu d’un mécanisme distinct pour chacun.

Les compromis que nous avons acceptés

Pas de requêtes sur les champs chiffrés. Les valeurs sensibles ne peuvent être ni recherchées, ni triées, ni indexées : les requêtes ont dû être conçues autour des champs non sensibles.
La classification devient une tâche de conception. Quelqu’un doit décider, et documenter, quelles valeurs sont sensibles. En cas d’erreur, des données restent en clair.
Les métadonnées ne sont pas chiffrées. La structure des tables et les colonnes non sensibles restent lisibles.

Comparatif : SQLCipher ou chiffrement d’enveloppe

Critère	SQLCipher	Chiffrement d’enveloppe
Ce qui est chiffré	Tout le fichier de base de données	Une sélection de valeurs sensibles
Requêtes sur les données chiffrées	Oui	Non
Impact sur la taille de l’app	Bibliothèques natives ajoutées	Environ 6,5 Mo de moins dans cette app
Coût à l’exécution	Chiffrement de chaque page de la base	Environ 1 ms par écran (mesuré)
Effort de conception	Faible	Classification des données nécessaire
Idéal pour	Des données majoritairement sensibles et interrogeables	Quelques valeurs sensibles dans un jeu de données plus large

Comment Mobian aborde ces décisions

Chez Mobian, chaque modification de sécurité de cet audit s’accompagnait d’une courte note de décision écrite : le risque, les options, ce que nous avons choisi et ce que nous avons écarté. C’est cette trace qui permet à l’équipe sécurité d’une banque — ou à son auditeur — de comprendre pourquoi l’app fonctionne comme elle le fait. Nous choisirions tout aussi volontiers SQLCipher pour une app dont la plupart des données locales sont sensibles.

Conclusion

SQLCipher et le chiffrement d’enveloppe s’appuient tous deux sur l’Android Keystore pour assurer une protection réelle. Pour une app dont seule une partie des données locales est sensible, chiffrer directement ces valeurs a permis d’économiser 6,5 Mo pour un coût d’environ 1 ms par écran — en contrepartie d’une classification rigoureuse des données et de l’absence de requêtes sur les champs chiffrés. La bonne réponse dépend de vos données, et la décision mérite d’être consignée par écrit.

Questions fréquentes

Qu’est-ce que le chiffrement d’enveloppe ?

Le chiffrement d’enveloppe repose sur deux niveaux de clés. Les données sont chiffrées avec une clé de chiffrement des données (DEK), et la DEK est elle-même chiffrée, ou encapsulée, par une clé de chiffrement de clés (KEK). Sur Android, la KEK peut résider dans l’Android Keystore, où elle n’est jamais exposée au code de l’app.

SQLCipher est-il un mauvais choix ?

Non. SQLCipher est mature et chiffre l’intégralité du fichier de base de données, index et métadonnées compris. Il convient bien lorsque la majeure partie de la base est sensible ou lorsque les données chiffrées doivent rester interrogeables. Il ajoute en revanche des bibliothèques natives à l’app et modifie le fonctionnement de la couche base de données.

Qu’a permis d’économiser le chiffrement d’enveloppe dans ce projet ?

Se passer de SQLCipher a permis d’économiser environ 6,5 Mo de code natif dans l’app, pour un coût mesuré d’environ 1 ms par écran pour chiffrer et déchiffrer les valeurs sensibles affichées.

Quel est le principal inconvénient du chiffrement d’enveloppe au niveau des champs ?

La base de données ne peut ni rechercher, ni trier, ni indexer les champs chiffrés. Il faut donc décider avec soin quelles valeurs sont sensibles et concevoir les requêtes autour des champs non sensibles. Le chiffrement de la base entière évite ce travail de conception.

Le chiffrement d’enveloppe répond-il aux exigences de l’OWASP ?

Correctement mis en œuvre, avec des clés adossées au matériel lorsque c’est possible et un chiffrement authentifié comme AES-GCM, il répond aux catégories stockage de données non sécurisé et cryptographie insuffisante de l’OWASP Mobile Top 10 (2024). Savoir s’il satisfait un audit donné dépend des exigences de cet audit.

Pourquoi nous avons préféré le chiffrement d’enveloppe à SQLCipher pour une app bancaire