Bonjour, j'ai partiellement répondu à cette question dans certains commentaires. Je me permets de plus ou moins le faire si ça ne dérange pas. :)
Entre autres, un bootloader déverrouillé permet à n'importe quel attaquant physique (on parle de simple "possession" du smartphone) d'exécuter des commandes privilégiées qu'il ne devrait pas pouvoir faire (fastboot et adb). Il permet par exemple d'installer un rookit (un malware persistant), de faire une copie des partitions (les effacer aussi, mais c'est "moins" grave), de pouvoir mener des attaques qui peuvent aller jusqu'à compromettre les données malgré le FDE/FBE (chiffrement de disque/profil). Ce n'est pas alarmiste, ce n'est même pas seulement à la portée d'un attaquant sophistiqué, c'est juste la pierre angulaire du modèle de sécurité mobile.
Android a également cette mitigation que l'on appelle verified boot, c'est la vérification d'intégrité au démarrage du firmware et de l'OS. Elle ne peut pas, par nature, fonctionner avec un bootloader déverrouillé. Elle permet non seulement de lutter contre des attaques physiques mais aussi à distance : les persistances peuvent être détectées, l'idée est de ne jamais démarrer un système compromis et dont il est impossible de retrouver l'état d'intégrité. Le verified boot n'est bien entendu pas propre à GrapheneOS, il est propre à Android mais la plupart des constructeurs en ont une mauvaise implémentation (pour ne pas dire qu'elle ne fonctionne pas). iOS l'a aussi, d'ailleurs.
En d'autres termes, le déverrouillage du bootloader doit être une étape temporaire uniquement lors de l'installation d'un OS custom. L'installateur WebUSB de GrapheneOS l'explique assez bien d'ailleurs, mais n'hésite pas à rechercher pour plus d'informations.
[^] # Re: Bootloader
Posté par Wonderfall (site web personnel) . En réponse à la dépêche De l'art d'installer GrapheneOS sur son smartphone. Évalué à 7.
Bonjour, j'ai partiellement répondu à cette question dans certains commentaires. Je me permets de plus ou moins le faire si ça ne dérange pas. :)
Entre autres, un bootloader déverrouillé permet à n'importe quel attaquant physique (on parle de simple "possession" du smartphone) d'exécuter des commandes privilégiées qu'il ne devrait pas pouvoir faire (fastboot et adb). Il permet par exemple d'installer un rookit (un malware persistant), de faire une copie des partitions (les effacer aussi, mais c'est "moins" grave), de pouvoir mener des attaques qui peuvent aller jusqu'à compromettre les données malgré le FDE/FBE (chiffrement de disque/profil). Ce n'est pas alarmiste, ce n'est même pas seulement à la portée d'un attaquant sophistiqué, c'est juste la pierre angulaire du modèle de sécurité mobile.
Android a également cette mitigation que l'on appelle verified boot, c'est la vérification d'intégrité au démarrage du firmware et de l'OS. Elle ne peut pas, par nature, fonctionner avec un bootloader déverrouillé. Elle permet non seulement de lutter contre des attaques physiques mais aussi à distance : les persistances peuvent être détectées, l'idée est de ne jamais démarrer un système compromis et dont il est impossible de retrouver l'état d'intégrité. Le verified boot n'est bien entendu pas propre à GrapheneOS, il est propre à Android mais la plupart des constructeurs en ont une mauvaise implémentation (pour ne pas dire qu'elle ne fonctionne pas). iOS l'a aussi, d'ailleurs.
En d'autres termes, le déverrouillage du bootloader doit être une étape temporaire uniquement lors de l'installation d'un OS custom. L'installateur WebUSB de GrapheneOS l'explique assez bien d'ailleurs, mais n'hésite pas à rechercher pour plus d'informations.