Explication canonique du cryptage et des vulnérabilités d'Android

J'imagine que ça marche comme ça :

• Le stockage est crypté en utilisant une clé aléatoire synchrone.
• Lorsque l'utilisateur choisit ou modifie un mot de passe basé sur une entrée quelconque, qu'il s'agisse d'un mot de passe composé de lettres, de chiffres et de caractères, ou qu'il s'agisse d'un code pin, d'un balayage de motif, d'une empreinte digitale ou de toute autre entrée, un algorithme de cryptage asynchrone est utilisé pour crypter la clé maîtresse, de sorte qu'une identification correcte finit par décrypter l'entrée donnant lieu à la clé maîtresse, ce qui permet ensuite de crypter et de décrypter le stockage.
• Au moment où l'utilisateur se déconnecte, la mémoire contenant la clé principale est écrasée.

La grande astuce ici est le chiffrement asynchrone de la clé principale. Une fois qu'Android a la clé maîtresse, il a la possibilité d'échanger des données avec le stockage. La clé maîtresse n'est connue que lorsque l'utilisateur est connecté. Le cryptage asynchrone est ce qu'on appelle le cryptage à clé publique. Ce qui se passe, c'est qu'une clé publique crypte les données (la clé maître dans ce cas), et une clé privée décrypte les données. À ne pas confondre avec le cryptage du stockage ici. Le stockage est juste un cryptage synchrone. La même clé est utilisée pour crypter et décrypter. Mais la recherche/récupération de cette clé "maîtresse" est le problème majeur. Cela signifie que si, à un moment donné, vous avez une méthode de connexion faible, comme par exemple "1234" comme code d'identification, et que vous changez d'avis, et changez le code d'identification en "5364", qui est plus difficile à deviner, à moins que le "1234" précédent ait été volé, espionné, à n'importe quel moment, la sécurité vient d'être améliorée. Il en va de même lorsque l'on change la méthode de connexion pour un mot de passe complet impossible à deviner ou à attaquer par dictionnaire. Le stockage lui-même n'a pas besoin d'être ré-encrypté du tout. Il s'agit de cacher la clé maîtresse - en interne. L'utilisateur ne voit jamais cette clé maîtresse, car il s'agit très probablement d'une sorte de code de hachage aléatoire - rien ne pourra jamais "trouver" ou "deviner" ce code de hachage. Même la NSA ou tout autre organisme de sécurité de la planète ne pourrait jamais trouver une telle clé. Le seul vecteur d'attaque est l'espoir d'une faiblesse de la part de l'utilisateur. Peut-être que l'utilisateur a choisi un code postal de connexion. S'il s'agit de 4 chiffres, alors il y a un maximum de 10 000 codes d'identification possibles. Le système d'exploitation pourrait "bloquer" l'appareil après en avoir essayé quelques-uns en peu de temps. La solution consiste alors à "pirater" le système d'exploitation, de sorte qu'il devienne possible d'essayer tous les codes d'identification possibles sans que le système d'exploitation n'intervienne et ne bloque l'appareil. Je crois que c'est ainsi que le FBI a fini par avoir accès au téléphone d'un criminel. Une société tierce (une société israélienne, si je me souviens bien) a effectué le piratage pour le FBI, je crois. Ils ont contourné cette limite de tentative de pincode. Si le login est un mot de passe complet, et si l'utilisateur a choisi un mot de passe fort, et vous êtes résolu. Avec toute la puissance des processeurs de la planète, personne ne pourra pirater ça en un million d'années. Je ne crois pas que la NSA puisse décrypter quoi que ce soit. Je pense que ces gens ont regardé un peu trop de films d'hommes en noir. Il suffit de regarder les documents scientifiques sur les différents algorithmes de cryptage (par exemple AES), et vous saurez que le piratage n'est tout simplement pas possible, sauf à l'époque où il y avait des clés de 40 bits. Cette époque est révolue depuis longtemps. AES128 est déjà inviolable je pense, et si quelqu'un est concerné, passer à AES256 le rend plus sûr d'une magnitude équivalente à la taille de l'univers. Peut-être un jour les ordinateurs quantiques pourraient le décrypter, mais je suis sceptique. Je ne suis pas sûr qu'il soit possible qu'un système de probabilité mette simplement en évidence la solution. Nous verrons cela, éventuellement. Peut-être que c'est dans quelques vies de toute façon. Rien à craindre pour l'instant.

Ainsi, en fin de compte, la limitation de la sécurité repose entièrement sur la méthode de connexion utilisée. On peut changer la méthode sans avoir à ré-encrypter le stockage. Tout cela grâce au chiffrement asynchrone de la clé publique de la clé principale.

Les mises à jour étant fréquentes, la façon dont le chiffrement du téléphone (système d'exploitation basé sur Android) est géré peut changer d'une version à l'autre. Par conséquent, la principale préoccupation n'est pas le cryptage lui-même, mais l'endroit où le processus est exécuté. Et si cette plate-forme présente des vulnérabilités, la force de l'algorithme de cryptage lui-même n'a que peu ou pas d'importance.

En fait, une fois que votre appareil a décrypté un ou plusieurs fichiers, un processus doté de privilèges de super utilisateur peut y accéder directement. Ce processus pourrait avoir accès à votre appareil en exploitant une faiblesse dans la ROM (Android OS) elle-même. (Ce point a récemment fait l'objet de l'actualité, certaines failles ayant été exposées par WikiLeaks).

Les appareils enracinés semblent être plus susceptibles d'accéder aux données de l'étape 2 par le biais d'une récupération personnalisée/ éventuellement d'une ROM et d'un flashage de noyau ? (si c'est vrai, pourquoi cela n'est-il pas présenté comme un risque important ?)

Avant la racine : Pour Rooter un appareil, vous devez utiliser des outils externes qui ont tous un accès profond à la structure interne de l'appareil. Certains de ces outils sont précompilés et ne sont pas open source. Ils ont des sites "officiels", mais qui sont ces gens (twrp.me, supersu.com par exemple, mais il y en a d'autres comme KingoRoot) Peut-on vraiment leur faire confiance ? Je fais plus confiance à certains qu'à d'autres. Par exemple, KingoRoot a installé un programme sur mon PC qui s'est comporté comme un virus (j'ai dû utiliser le dual-boot pour le supprimer).

Après l'enracinement Le principe de base est le suivant : donner à un programme compilé (APK) un accès SU signifie qu'il peut faire tout ce qu'il veut sans restrictions ni indication de l'intention qu'il utilisera. (Les intentions sont un moyen pour les APK d'accéder à des choses comme le WiFi, la caméra, etc.) Ainsi, une "application de confiance", après avoir obtenu un accès racine, peut facilement accéder à n'importe quel type d'information et la renvoyer à son serveur.

Le cryptage complet des appareils protège-t-il mes données de Google et de la Commission européenne ? gouvernement ?

Google - oui. Il ne possède pas la clé de déverrouillage.

Le gouvernement (ou le pirate) - non. Parce que le gouvernement ou le pirate peut essentiellement utiliser un exploit qui interceptera le(s) fichier(s) comme je l'ai mentionné ci-dessus.

La complexité des procédures/algorithmes de sécurité est de peu d'utilité s'ils peuvent être interceptés et contournés.

Edit : Il est utile de mentionner que Google a la capacité de télécharger et d'installer/mettre à jour des applications sur votre appareil Android sans vous demander la permission, ou même vous notifier que la mise à jour a eu lieu. Et même sur un appareil enraciné, il ne semble pas y avoir de moyen de bloquer cela sans perdre des fonctions clés (Play Store, Maps, Sync, etc).