2 votes

Si la partition /system n'est jamais chiffrée (même en cas de chiffrement "full-disk"), comment est-elle protégée ?

Il semble que le système Android "full-disk-encrytpion" ne se préoccupe que du chiffrement de la data o internal storage partition. C'est écrit :

Le chiffrement intégral du disque consiste à coder toutes les données utilisateur sur un appareil Android à l'aide d'une clé chiffrée. Une fois qu'un appareil est crypté, toutes les données créées par l'utilisateur sont automatiquement cryptées avant d'être enregistrées sur le disque et toutes les lectures décryptent automatiquement les données avant de les renvoyer au processus d'appel.

Je me demande ce que vaut le cryptage (au repos) des données de l'utilisateur, si un attaquant peut simplement modifier le contenu de l'écran. /system pour contenir un logiciel malveillant qui exfiltrerait des données ou une clé de chiffrement.

Y a-t-il une raison de considérer que le cryptage d'Android est efficace même si /system La partition n'est pas cryptée ?

Je suppose qu'une réponse implique une chain-of-trust par rapport à un chargeur de démarrage verrouillé.

3voto

Slevin Points 204

/boot , /system , /vendor , /vbmeta y ODM Cloisons sont protégés par Démarrage vérifié d'Android (AVB). Elles ne sont pas cryptées mais leur intégrité est vérifiée lors du démarrage. Toute modification de ces partitions arrêtera la flux de démarrage et de briquer l'appareil. À ce stade, sans le mode EDL, vous ne serez pas en mesure de flasher le système d'exploitation stock pour le débloquer.

AVB vérifie l'image de la partition vbmeta en utilisant la clé publique de l'OEM qui est codée en dur dans le chargeur de démarrage Android (ABL). Ensuite, le hachage de l'image de démarrage est calculé et comparé au hachage stocké dans vbmeta. Une fois que l'image de démarrage est vérifiée, le noyau construit l'arbre de hachage de chaque partition et compare leur hachage Root avec ceux qui sont stockés dans vbmeta. De cette façon, en protégeant simplement vbmeta, toutes les autres partitions peuvent être vérifiées au démarrage.

Pour protéger ABL de la falsification (par exemple, en remplaçant la clé publique de l'équipementier par la vôtre et en résignant vbmeta avec votre clé privée, rompant ainsi la chaîne de confiance), les fabricants de puces mettent en place un démarrage sécurisé. Dans les appareils Qcom, le Primary Bootloader (PBL) qui est gravé sur la puce du CPU, vérifie le Xtended Bootloader (XBL) à l'aide de la clé publique de Qcom qui est stockée dans eFuse. Ensuite, le Xtended Bootloader vérifie l'ABL et l'ABL applique l'AVB.

Lorsque vous déverrouillez le bootloader (unlock et unlock_critical), AVB n'est pas appliqué mais le démarrage sécurisé est toujours appliqué par le SoC. Cette chaîne de confiance va jusqu'au niveau matériel rendant toute modification inutile. Il n'y a aucune raison de crypter les partitions du système car ces images sont déjà publiques. Ce qui compte, c'est la protection de leur intégrité.

1voto

rascalking Points 1422

On dirait que Google est d'accord avec vous et élimine progressivement le cryptage complet du disque :

Attention : La prise en charge du cryptage intégral du disque disparaît. Si vous créez un nouveau périphérique, vous devez utiliser le cryptage basé sur les fichiers.

Le chiffrement intégral du disque était considéré comme assez solide jusqu'en 2016, en raison de l'environnement d'exécution de confiance soutenu par le matériel. Selon la façon dont l'équipementier met en œuvre l'environnement d'exécution sécurisé et s'il utilise la technologie Android keystore système. Il offre un degré variable de sécurité. Si, au contraire, il s'agit d'un logiciel, ce n'est pas le cas.

Les clés de chiffrement ne se trouvent pas simplement dans une partition non chiffrée. La clé de cryptage est stockée dans les métadonnées de cryptage. les métadonnées de cryptage. Le matériel a soutenu la capacité de signature de l'environnement d'exécution de confiance et si le système de keystore d'Android est mis en œuvre, l'appareil Android dans son ensemble et même le noyau Android n'ont pas accès au keymaster dans l'environnement sécurisé de confiance. Le système keystore est très intéressant mais expliquer la sécurité et les opérations derrière lui implique une explication de plusieurs pages qui serait mieux répondue par sa propre question. 

Les appareils Android qui prennent en charge un écran de verrouillage et qui sont livrés avec Android 7.0 ou une version ultérieure disposent d'un environnement secondaire isolé appelé "Trusted Execution Environment". Cela permet une séparation supplémentaire de tout code non fiable. Cette capacité est généralement mise en œuvre à l'aide de matériel sécurisé.

Voici quelques exemples de la manière dont un environnement d'exécution de confiance peut être mis en place :

Une machine virtuelle distincte, un hyperviseur ou un environnement d'exécution sécurisé spécialement conçu, comme ARM TrustZone. L'environnement isolé doit assurer une séparation complète avec le noyau Android et l'espace utilisateur (monde non sécurisé). Cette séparation est telle que rien de ce qui est exécuté dans le monde non sécurisé ne peut observer ou manipuler les résultats d'un calcul dans l'environnement isolé.

Android 9.0 a introduit un environnement d'exécution de confiance soutenu par le matériel, appelé "strongbox". La strongbox est une unité centrale de traitement sécurisée complètement séparée, conçue et certifiée. Les exemples de dispositifs StrongBox sont les éléments sécurisés intégrés (eSE) ou les unités de traitement sécurisées on-SoC.

Un environnement sécurisé de confiance adossé au matériel qui utilise le système de keystore d'Android peut servir de protection solide pour la clé de chiffrement. À moins qu'une tierce partie comme Qualcomm (2016) ne fasse une erreur de conception dans l'implémentation du système de cryptage Android, la clé de cryptage ne sera pas protégée. keymaster .

0voto

alecxs Points 3105

Une vérification rapide sur la tablette Samsung Galaxy Tab S3 SM-T820 avec Android 9 Pie officiel indique que /system est crypté avec FDE

:/ $ df -ah
Filesystem                            Size  Used Avail Use% Mounted on
rootfs                                1.5G  9.4M  1.5G   1% /
tmpfs                                 1.7G  1.1M  1.7G   1% /dev
devpts                                   0     0     0   0% /dev/pts
none                                     0     0     0   0% /dev/cpuctl
none                                     0     0     0   0% /dev/cpuset
proc                                     0     0     0   0% /proc
sysfs                                    0     0     0   0% /sys
selinuxfs                                0     0     0   0% /sys/fs/selinux
debugfs                                  0     0     0   0% /sys/kernel/debug
tracefs                                  0     0     0   0% /sys/kernel/debug/tracing
pstore                                   0     0     0   0% /sys/fs/pstore
tmpfs                                 1.7G     0  1.7G   0% /mnt
tmpfs                                 1.7G     0  1.7G   0% /mnt/secure
/dev/block/dm-0                       3.7G  3.5G  245M  94% /system
/dev/block/bootdevice/by-name/apnhlos    0     0     0   0% /system/vendor/firmware_mnt
/dev/block/bootdevice/by-name/modem      0     0     0   0% /system/vendor/firmware-modem
/dev/block/bootdevice/by-name/dsp      12M  4.1M  7.6M  36% /system/vendor/dsp
none                                     0     0     0   0% /acct
none                                     0     0     0   0% /config
/dev/block/bootdevice/by-name/cache   193M  8.8M  184M   5% /cache
/dev/block/bootdevice/by-name/efs      16M  720K   15M   5% /efs
/dev/block/dm-1                        24G   13G   11G  56% /data
/data/knox/secure_fs/enc_user          24G   13G   11G  56% /data/enc_user
/data/knox/secure_fs/enc_media         24G   13G   11G  56% /data/knox/secure_fs/enc_media
tmpfs                                 1.7G     0  1.7G   0% /storage
/data/media                            24G   13G   11G  57% /storage/emulated
/mnt/media_rw/4280-3E71                60G  4.8G   55G   9% /storage/4280-3E71
tmpfs                                 1.7G     0  1.7G   0% /storage/self
:/ $

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