Si vous avez suivi l'évolution d'Android, vous devez avoir entendu parler du nom de «Verified Boot» au cours des deux dernières années. Google a introduit la fonctionnalité de sécurité dans Android 4.4 (Kitkat), de manière totalement non intrusive, et augmente lentement sa visibilité dans les nouvelles versions de son système d'exploitation Android.
Au cours des derniers jours, nous avons été informés de la présence d'un « démarrage vérifié strictement » dans la dernière version de Google du système d'exploitation mobile le plus utilisé au monde. Android Nougat utilisera un niveau plus élevé de vérification de la sécurité lors du démarrage de votre appareil. Alors que, sur Marshmallow, Verified Boot n’avait donné qu’un avertissement à l’utilisateur, si celui-ci détectait un problème avec la partition système, Android Nougat ira un peu plus loin et utilisera ce que Google appelle une «boot vérifiée strictement», qui n'autorise pas du tout le périphérique à démarrer, au cas où il détecterait des anomalies dans la partition, des modifications apportées au chargeur de démarrage ou la présence de code «malveillant» dans le périphérique. Cela soulève la question suivante: «Qu'est-ce que cela signifie exactement pour les utilisateurs?» S'est avéré que la réponse diffère pour les deux principales catégories d'utilisateurs Android (utilisateurs occasionnels et avancés) et nous allons fournir la réponse pour les deux. .
Boot vérifié strictement appliqué
Tout d’abord, un peu d’arrière-plan sur le démarrage vérifié: généralement, lorsque Android exécute un test de vérification sur des partitions, il le fait en divisant les partitions en blocs de 4 Ko et en les comparant à une table signée. Si tout est vérifié, cela signifie que le système est complètement propre. Cependant, si certains blocs s'avéraient altérés ou corrompus, Android informe l'utilisateur des problèmes et laisse à l'utilisateur le soin de les résoudre (ou non).
Tout cela est sur le point de changer avec Android Nougat et le démarrage vérifié Strictly Enforced. Lorsque le démarrage vérifié s’exécute en mode appliqué, il ne tolérera aucune erreur dans les partitions. S'il détecte un problème, le périphérique ne pourra pas démarrer et l'utilisateur pourra également démarrer dans un environnement en mode sans échec pour tenter de résoudre le problème. Cependant, le démarrage vérifié Strictly Enforced n'est pas simplement une vérification des blocs de données incorrects. Il peut aussi généralement corriger les erreurs dans les blocs de données. Cela est rendu possible par la présence de codes de correction d'erreur directe, qui peuvent être utilisés pour corriger les erreurs dans les blocs de données. Cependant, cela ne peut pas toujours fonctionner, et dans les cas où cela ne fonctionne pas, vous êtes à peu près mort dans l'eau.
Botte vérifiée strictement: le bon, le mauvais et le truand
1. le bien
L'application du démarrage vérifié sur les appareils Android améliorera la sécurité des appareils. Au cas où le périphérique serait infecté par un programme malveillant, Strictly Enforced Verified Boot le détectera au prochain redémarrage de votre périphérique et le corrigera ou vous invitera peut-être à y remédier.
Cette fonctionnalité vérifiera également la corruption des données et, dans la plupart des cas, elle sera en mesure de corriger les erreurs introduites dans les données, grâce aux codes FEC. Google utilise des codes FEC capables de corriger une erreur de bit inconnu sur 255 bits . Bien sûr, cela semble être un assez petit nombre, mais mettons cela en perspective, en ce qui concerne un appareil mobile:
Remarque: Les valeurs ci-dessous sont extraites du billet de blog de Sami Tolvanen, ingénieur chez Google, sur les développeurs Android.
Google aurait pu utiliser les codes RS (255, 223) FEC: ces codes auraient pu corriger 16 erreurs inconnues sur 255 bits, mais la surcharge d'espace due aux 32 bits de données redondantes aurait été de près de 15%, et c'est beaucoup, surtout sur les appareils mobiles. Ajoutez à cela le fait qu'Android est le système d'exploitation prédominant sur les smartphones économiques dotés de mémoires de 4 à 8 Go. Un espace supplémentaire de 15% semble beaucoup.
En sacrifiant les fonctionnalités de correction des erreurs pour favoriser l’économie d’espace, Google a décidé d’utiliser les codes FEC RS (255, 253). Ces codes ne peuvent corriger qu'une seule erreur inconnue sur 255 bits, mais la surcharge d'espace n'est que de 0, 8%.
Remarque: RS (255, N) est une représentation des codes de Reed-Solomon, qui sont un type de codes de correction d'erreur.
2. le mauvais
Jamais entendu parler de "Il y a deux faces d'une pièce"? Bien sûr que vous avez. Alors que les intentions de Google avec Strictly Enforced Verified Boot étaient sans aucun doute aussi pures que des bébés licornes, elles viennent avec leurs propres problèmes.
Lorsque Strictly Enforced Verified Boot recherche des programmes malveillants, il vérifie également les modifications illégales apportées au noyau, au chargeur de démarrage et à d'autres éléments pour lesquels je ne vous ennuierai pas. Toutefois, cela signifie qu'Android Nougat rencontrera probablement de nombreux problèmes d'enracinement. ROM personnalisées clignotantes, car Verified Boot ne peut pas faire la distinction entre les codes malveillants indésirables et le code qui a déverrouillé votre chargeur de démarrage. Cela signifie que si votre appareil est livré avec un chargeur de démarrage verrouillé et que votre fabricant OEM ne permet pas le déverrouillage du chargeur de démarrage, vous ne pouvez pratiquement pas le faire. Espérons que quelqu'un trouvera un exploit pour cela.
Heureusement, la plupart des personnes qui rootent leurs appareils, et flashant ROM personnalisées pour les fonctionnalités ajoutées, vont avec des téléphones conviviaux pour les développeurs, tels que le Nexus. Il y a beaucoup de choses à considérer concernant ce sujet, et ce n'est certainement pas la fin des ROM personnalisées, du moins pas sur les périphériques fournis avec un chargeur de démarrage déverrouillé, ou qui permettent de déverrouiller le chargeur de démarrage. Cependant, des appareils tels que les téléphones Samsung n'autorisent pas officiellement le déverrouillage du chargeur de démarrage, et sur ces appareils, le déverrouillage de votre chargeur de démarrage sera très certainement considéré comme un «problème» par Verified Boot, empêchant le périphérique de démarrer.
Un autre problème qui se posera avec le démarrage vérifié strict stricto sensu est celui qui affectera même les utilisateurs qui ne se soucient pas vraiment d’obtenir les privilèges root, ou d’installer des ROM personnalisées. Au fil du temps, à mesure que vous utilisez votre appareil, il est inévitable que les données soient altérées de manière naturelle dans la mémoire. pas à cause de la présence d'un malware, mais simplement parce que cela se produit. Ce n'est généralement pas un problème, ou du moins pas un problème aussi grave que celui que verra Verified Boot. Si des données corrompues ne peuvent pas être corrigées au démarrage de Strictly Enforced Verified Boot, elles ne permettront pas à votre appareil de démarrer. À mon avis, il s'agit d'un problème plus important et plus visible que certaines données corrompues sur la partition utilisateur.
3. Le truand
Parmi tous les avantages de l’application de Verified Boot et de tous les problèmes potentiels, le plus troublant est probablement le fait que les constructeurs OEM pourraient commencer à en abuser pour verrouiller leurs appareils, de sorte que les utilisateurs ne pourraient pas utiliser Android pour ce à quoi ils étaient censés être destinés. be: ouvert, convivial pour les développeurs et entièrement personnalisable. Strictly Enforced Verified Boot mettra entre les mains des constructeurs OEM le pouvoir de s'assurer que les utilisateurs ne peuvent pas déverrouiller les chargeurs d'amorçage sur leurs appareils, ce qui leur interdit d'installer des ROM personnalisées et des outils d'amélioration tels que Xposed Modules.
Nougat Android: un changement radical dans le fonctionnement d'Android?
Bien que nous soyons sûrs que les intentions de Google soient simplement d'éviter les problèmes potentiels des utilisateurs occasionnels d'Android, ceux-ci ne sauraient pas quoi faire si leur appareil était affecté par un logiciel malveillant ou si leur mémoire avait des blocs de données endommagés, elle aurait peut-être remis aux OEM et le fabricant est l'outil idéal pour inciter les utilisateurs à vivre avec ce qu'ils ont proposé, et rien de plus.
Bien sûr, quelqu'un découvrira un exploit ou une solution de contournement à cette situation, et nous espérons bien le faire, dans le véritable esprit d'Android. Jusqu'à ce que quelqu'un trouve une solution, tout ce que nous, en tant qu'utilisateur, pouvons faire, c'est nous assurer que nous achetons nos appareils auprès de fabricants acceptant les développeurs.
Courtoisie d'image en vedette: Flickr
