Comme mentionné plus haut, je partirais sur griller le composant USB un peu plus en amont si possible (assez souvent y a un contrôleur dédié à l'usb-c).
Sinon, je comprends pas exactement les précisions sur chiffrement mounté/démounté. Lors du reboot en fastboot le device passe assez fatalement en chiffrement démounté. À moins que le kernel de GrapheneOS explicite vide la RAM au démarrage, sans que le bootloader ne le fasse. Mais une recherche rapide ne me donne rien (mais en vrai ça se fait assez facilement en rajoutant memtest dans le kernel+cmdline)
Un commentaire plus haut mentionne l'auto-reboot/reset au branchement USB. Ça avec un memtest au boot ça me parait raisonnable, en supposant que le threat model ne suppose pas que l'attaquant connaisse tes défenses. Aussi, si on considère que l'attaquant est suffisamment sophistiqué pour découvrir des attaques fastboot, il saura aussi empêcher le démarrage du kernel (il "suffit" de court-circuiter un pin de data de l'UFS au bon moment, et l'appareil restera en bootloader, avec la RAM allumée, mais non écrasée par Linux).
Sinon, au risque de dire des évidences, quelques étapes supplémentaires de sécurisations avant ce niveau là:
- Interdire les applications Google—rien que connaître la liste des applications installées par un utilisateur est un danger
- Bloquer WiFi/BT (comme mentionné dans un autre commentaire), et VoLTE/VoWifi qui sont des composants qui ont très régulièrement des failles de sécurité. (j'ai un projet bien avancé de sécurisation VoLTE/VoWifi, mais pour le moment ça n'a attiré personne)
- Installer un adblocker (cf recommandations FBI)
Et enfin, vu que tu parles de faire des séries, c'est que t'as potentiellement de l'argent, donc une vraie sécurité serait de ne pas dépendre de la sécurité des autres:
L'intégralité de la sécurité des Pixels repose sur des clés de signature de Google. Ils peuvent tout à fait publier des firmwares de leur chips qui publient tout les secrets et autorise de démarrer n'importe quoi.
Évidement ils ne vont pas le faire volontairement. Par contre il n'y a aucun visibilité sur qui a ce genre de firmware.
La solution que je propose donc, c'est d'utiliser un smartphone qui autorise de mettre ses propres clés! Au passage, les composants en DMA sont dangereux (même en supposant une iommu fonctionnelle, écrire des drivers qui garantissent les échecs de TOCTOU est non trivial), donc un appareil qui éviterait ces écueils pour les composants "connectés au monde extérieur" (WiFi, 4G/VoLTE. BT/NFC à ma connaissance ne sont jamais en DMA) serait pas mal.
Des smartphones qui autorisent ces sécurités sont les PinePhone Pro et les Librem.
Petits bonus: On peut flasher leur OTP pour interdire le mode USB de la bootrom, et supprimer complètement le support USB du bootloader. Aussi, on peut vider la RAM dès son initialisation (rendant donc inutile une attaque du fastboot s'il existait), plutôt que d'attendre que Android démarre.
# Alternative
Posté par Ph Husson (site web personnel) . En réponse au journal Sécurisation du port USB-C sur smartphone pour moules barbares. Évalué à 4.
Comme mentionné plus haut, je partirais sur griller le composant USB un peu plus en amont si possible (assez souvent y a un contrôleur dédié à l'usb-c).
Sinon, je comprends pas exactement les précisions sur chiffrement mounté/démounté. Lors du reboot en fastboot le device passe assez fatalement en chiffrement démounté. À moins que le kernel de GrapheneOS explicite vide la RAM au démarrage, sans que le bootloader ne le fasse. Mais une recherche rapide ne me donne rien (mais en vrai ça se fait assez facilement en rajoutant memtest dans le kernel+cmdline)
Un commentaire plus haut mentionne l'auto-reboot/reset au branchement USB. Ça avec un memtest au boot ça me parait raisonnable, en supposant que le threat model ne suppose pas que l'attaquant connaisse tes défenses. Aussi, si on considère que l'attaquant est suffisamment sophistiqué pour découvrir des attaques fastboot, il saura aussi empêcher le démarrage du kernel (il "suffit" de court-circuiter un pin de data de l'UFS au bon moment, et l'appareil restera en bootloader, avec la RAM allumée, mais non écrasée par Linux).
Sinon, au risque de dire des évidences, quelques étapes supplémentaires de sécurisations avant ce niveau là:
- Interdire les applications Google—rien que connaître la liste des applications installées par un utilisateur est un danger
- Bloquer WiFi/BT (comme mentionné dans un autre commentaire), et VoLTE/VoWifi qui sont des composants qui ont très régulièrement des failles de sécurité. (j'ai un projet bien avancé de sécurisation VoLTE/VoWifi, mais pour le moment ça n'a attiré personne)
- Installer un adblocker (cf recommandations FBI)
Et enfin, vu que tu parles de faire des séries, c'est que t'as potentiellement de l'argent, donc une vraie sécurité serait de ne pas dépendre de la sécurité des autres:
L'intégralité de la sécurité des Pixels repose sur des clés de signature de Google. Ils peuvent tout à fait publier des firmwares de leur chips qui publient tout les secrets et autorise de démarrer n'importe quoi.
Évidement ils ne vont pas le faire volontairement. Par contre il n'y a aucun visibilité sur qui a ce genre de firmware.
La solution que je propose donc, c'est d'utiliser un smartphone qui autorise de mettre ses propres clés! Au passage, les composants en DMA sont dangereux (même en supposant une iommu fonctionnelle, écrire des drivers qui garantissent les échecs de TOCTOU est non trivial), donc un appareil qui éviterait ces écueils pour les composants "connectés au monde extérieur" (WiFi, 4G/VoLTE. BT/NFC à ma connaissance ne sont jamais en DMA) serait pas mal.
Des smartphones qui autorisent ces sécurités sont les PinePhone Pro et les Librem.
Petits bonus: On peut flasher leur OTP pour interdire le mode USB de la bootrom, et supprimer complètement le support USB du bootloader. Aussi, on peut vider la RAM dès son initialisation (rendant donc inutile une attaque du fastboot s'il existait), plutôt que d'attendre que Android démarre.