4 votes

Chiffrement compatible multiplateforme de la carte SD pour Android

Comment pourrais-je encrypter ma toute nouvelle carte SD de 256 Go, destinée à mon téléphone Android, en tenant compte des éléments suivants :

  • La carte doit être utilisable sur plusieurs appareils Android et autres plates-formes (Linux..). Par conséquent, le chiffrement natif des cartes SD Android n'est pas une solution car le contenu n'est pas lisible sur d'autres plates-formes, ni récupérable en cas de panne du téléphone ou de réinitialisation nécessaire.
  • Le cas d'utilisation consiste à protéger les données, principalement des photos, contre un voleur/trouveur de téléphone, pas contre une agence gouvernementale ou la police. Je comprends que la plupart des méthodes de chiffrement sont inefficaces sur Android à ces fins car les clés sont souvent accessibles depuis la mémoire. En ce sens, une fois le téléphone déverrouillé, il est considéré comme fiable, donc le chiffrement doit être transparent pour que les fichiers soient accessibles via des applications téléphoniques standard (c'est-à-dire que les photos apparaissent dans la galerie).

Idées :

  • Méthodes de chiffrement en mode disque complet telles que Luks. J'ai trouvé ce programme : EDS qui apparemment peut monter un volume Luks si le téléphone est rooté. Je ne sais pas dans quelle mesure cela est performant, ou si c'est sécurisé pour la carte.
  • Programmes commerciaux utilisant leur propre chiffrement basé sur des fichiers mais disponibles sur plusieurs plates-formes comme Boxcryptor ou Cryptomator. Leur objectif est à l'origine de chiffrer les fichiers avant de les stocker dans le cloud. Il ne semble pas que je puisse accéder aux fichiers en utilisant des applications régulières avec cette solution.
  • Changer mon téléphone pour un sur lequel je peux installer UbPorts :)
  • Utiliser Termux et rooter le téléphone pour monter un système de fichiers chiffré gocryptfs ou autre
  • Utiliser le chiffrement par défaut des cartes SD Android (FDE / FBE), extraire la mémoire pour accéder à la clé de chiffrement et l'utiliser à partir de Linux pour accéder aux fichiers
  • Autre idée bienvenue !

Je ne trouve aucune information sur ce cas d'utilisation qui me semble très étrange..

Un grand merci pour toute contribution !

0 votes

Merci pour toutes vos réponses.. pour l'instant, j'ai opté pour le cryptage Android par défaut car il est beaucoup plus simple à mettre en œuvre.. J'ai trouvé quelques explications sur la manière de casser le FDE Android sur les anciennes versions d'Android, mais rien sur la manière de récupérer la clé fscrypt (c'est-à-dire à partir de la mémoire) utilisée dans les versions plus récentes. Avez-vous une idée si cela est réalisable ou non? // Passez une bonne journée tout le monde

1 votes

Les appareils récents utilisent uniquement FBE. Le chemin /data/misc/vold appartient à la description d'Irfan de FDE.

4voto

Irfan Latif Points 16863

FDE

Dans les versions précédentes, le chiffrement par défaut d'Android pour /data et le Stockage Adoptable était le chiffrement complet du disque (FDE) qui est une implémentation personnalisée de dm-crypt. La partition userdata (sur FDE ainsi que sur FBE) est difficile (ou impossible) à décrypter hors de l'appareil en raison du chiffrement sécurisé par matériel. En cas de Stockage Adoptable implémenté depuis Android M, la clé est enregistrée à /data/misc/vold/expand_*.key, vous n'avez pas besoin de vider la mémoire mais l'accès à /data nécessite des droits root. La clé est stockée non chiffrée en raison de l' hypothèse:

Parce que le contenu d'un appareil de stockage adopté est fortement lié à l'appareil Android qui l'a adopté, les clés de chiffrement ne doivent pas être extraites de l'appareil parent, et donc l'appareil de stockage ne peut pas être monté ailleurs.

Mais si vous avez déjà rooté et une fois que vous avez la clé, il est possible de décrypter la carte SD sur une machine Linux en utilisant dmsetup. Notez également que retirer la carte SD physique cassera votre /sdcard et les applications que vous auriez déplacées.

FBE

Les versions récentes d'Android utilisent principalement le chiffrement basé sur les fichiers (FBE) qui repose sur le chiffrement du système de fichiers Linux (pour ext4 et f2fs). Il n'utilise pas une clé unique, mais la clé maître génère des clés par fichier (par inode en fait) au fur et à mesure. Sur Android, la clé maître chiffrée est enregistrée à /data/misc/vold/user_keys/de/ et /data/misc/vold/user_keys/ce/ ainsi qu'avec d'autres fichiers associés. Les sous-répertoires sont nommés d'après l'ID utilisateur, par exemple 0 pour le propriétaire de l'appareil. Ici, de est pour le stockage chiffré de l'appareil qui est entièrement chiffré par matériel et est disponible au démarrage sans interaction de l'utilisateur. ce est le stockage chiffré par les informations d'identification qui nécessite un NIP/mot de passe de l'utilisateur pour le déchiffrement en plus de la clé sécurisée par matériel. Les différents répertoires sur la partition /data sont (pas chiffrés ou) chiffrés avec des clés différentes; DE ou CE, pour l'utilisateur 0 ou l'utilisateur 10 et ainsi de suite.

Ainsi, chaque utilisateur a 2 clés chiffrées - une pour CE et l'autre pour DE - tout comme la clé chiffrée stockée au pied de la partition userdata comme dans le cas de FDE. Les clés ne peuvent pas simplement être utilisées pour déchiffrer des fichiers sur un PC contrairement à une seule clé requise pour déchiffrer l'ensemble du périphérique de stockage dans le cas de Stockage Adoptable FDE. De plus, FBE avec Stockage Adoptable ne fonctionne pas sur Nougat et Oreo, et ne semble pas très stable sur Pie. Je ne suis pas sûr de comment cela va fonctionner lorsque les choses seront rationalisées. Si certaines implémentations stockent les clés maîtresses non chiffrées (CE/DE) dans /data/misc/vold/user_keys/, il y aurait de grandes chances pour que FBE fonctionne sur plusieurs plateformes.

AUTRES OPTIONS

Si vous ne voulez pas utiliser FDE ou FBE natifs d'Android, vous pouvez configurer manuellement dm-crypt (plain / LUKS), ou essayer d'abord des solutions basées sur FUSE comme encfs ou gocryptfs; elles sont relativement plus simples. Les binaires sont disponibles ici.

FBE peut être géré manuellement avec l'outil fscrypt mais je ne pense pas que ce soit une option très faisable pour le moment. Vous pouvez tout de même essayer.

ecryptfs est une autre fonctionnalité native du noyau Linux. Android n'a jamais utilisé par défaut ecryptfs à ma connaissance, donc cela dépend du constructeur de ROM s'ils ont construit le noyau avec CONFIG_ECRYPT_FS=y ou non. Vous devrez peut-être reconstruire le noyau.

Toutes les options ci-dessus fonctionnent bien mais nécessitent toutes un accès root et une configuration manuelle sur Android, par exemple un script init.d ou une solution tierce.

Ou si vous voulez simplement chiffrer des répertoires sélectionnés et non toute la carte SD, essayez MiXplorer. Il inclut une version Java de encfs qui ne nécessite pas de root. Cependant, le répertoire déchiffré dans MiXplorer ne sera pas accessible aux autres applications. Pour un cas d'utilisation comme Boxcrypter, je préfère rclone car il est open-source.

EN LIEN:

0 votes

Beaucoup plus clair en effet, merci. Cependant, je ne comprends toujours pas où je peux trouver la clé FBE pour pouvoir décrypter les fichiers depuis Linux.. une idée ?

1 votes

Compris, merci.. par conséquent, je suppose qu'il n'y a pas de moyen pratique de mettre en œuvre cela... Je vais rester avec le chiffrement de la carte SD d'Android et utiliser un logiciel de synchronisation pour sauvegarder et synchroniser mes fichiers. Si je change de téléphone, j'espère pouvoir d'abord tout décrypter pour ne pas avoir à recopier tout depuis la sauvegarde sur la carte... merci à tous et merci

0 votes

Lorsque vous utilisez FDE et que vous démontez et retirez la carte SD (stockage adopté), rien de grave ne se produit. Lorsque vous la réinsérez, elle fonctionnera normalement.

androidalle.com

AndroidAlle est une communauté de androiders où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X