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

Remarque: Eh bien, la prime a expiré et une raison possible pourrait être un effort requis pour répondre à ce que je comprends des commentaires. Vu le nombre de votes positifs, cela semble également intéresser les autres. Je voudrais toujours obtenir une réponse, alors voici ce que je propose - une bonne réponse dans un mois, recevra une prime de 50. J'espère que cela donnera suffisamment de temps et d'incitation

J'essaie de comprendre le processus de cryptage Android et ses vulnérabilités depuis un certain temps

Il y a beaucoup de questions abordant des parties de ce sujet sur ce site et également sur le site frère. Pour ramener mon propos à la maison, ces questions portent sur des parties et non sur le tout (qui rappellent «les aveugles et l'éléphant ?» :)

• Qu'est-ce que le chiffrement Marshmallow protège?
• Le chiffrement complet de l'appareil protège-t-il mes données de Google et du gouvernement?
• /android/137334/if-we-encrypt-our-device-can-user-connecting-to-adb-get-it
• Questions relatives au cryptage de la carte SD
• android-encryption-when-phone-is-on
• android-cyanogenmod-encryption-vs-gnu
• y a-t-il-du-matériel-cryptographique-dans-un-telephone-carte-sim-qui-peut-être-utilisé-avec-rsa
• cryptage d'appareil Android

Ma compréhension (ou malentendu?)

1. Le mot de passe de cryptage est généré à partir d'une combinaison de code PIN de verrouillage de l'utilisateur et d'algorithme de cryptage (c'est là que réside une faiblesse inhérente en raison de la longueur limitée du code PIN)
2. Ceci est salé et stocké dans l'emplacement racine, non accessible aux utilisateurs
3. Ceci est utilisé pour générer le mot de passe réel pour crypter / décrypter et le mot de passe réel est stocké dans la RAM
4. Cela a été renforcé en reliant l'étape 1 au SoC de l'appareil ( quelle version d'Android? Quel est l'élément matériel qui identifie de manière unique l'appareil? Peut-il être remplacé par un faux? )
5. Par conséquent, il n'est pas possible de décrypter les données sans clé de chiffrement ni appareil (valable également pour les SD externes)
6. Méthodes de récupération possibles - force brute, capture d'informations RAM (étape 3) pour obtenir la clé
7. Les appareils enracinés semblent être plus susceptibles d'accéder aux données de l'étape 2 via une récupération personnalisée / éventuellement la ROM et le clignotement du noyau ?? ( si c'est vrai, pourquoi cela n'est-il pas présenté comme un gros risque? )
8. Même si ces informations sont obtenues, je suppose que ce n'est pas un effort insignifiant de générer le mot de passe réel
9. Marshmallow peut traiter le SD externe comme un «stockage interne» ou un «stockage portable». Logiquement, cela ne devrait pas faire de différence mais je ne suis pas sûr

Il y a des lacunes dans ma compréhension, sans probablement passer à côté d'autres aspects clés.

Donc, je cherche une explication canonique pour comprendre d'un point de vue utilisateur

• Processus de cryptage complet (y compris SD externe)

• Variation de l'implémentation entre les versions d'Android - de KitKat à Marshmallow (y compris deux options pour SD externe dans Marshmallow)

• Vulnérabilités au niveau utilisateur

Remarque

• Je suis conscient du risque que la question soit considérée comme trop large mais l'OMI garantit un traitement complet

• Ayant une certaine expérience dans la sécurité des communications, je comprends le défi de traduire les concepts cryptographiques au niveau utilisateur. Je préférerais que la réponse aborde cette question, avec des pointeurs explicatifs pour une meilleure compréhension. Les exemples du processus n'ont pas besoin d'être corrects sur le plan cryptographique dans un sens rigoureux, mais doivent transmettre l'essence

• Un avantage possible pourrait être de "tromper" les questions futures sur des aspects connexes

• Au prix de la répétition, les réponses devraient être principalement au niveau de l'utilisateur , mais avec une explication adéquate pour une compréhension plus approfondie. La division de la réponse en deux parties peut être une manière appropriée.

• Je mettrais un point d'honneur à voter des réponses triviales / occasionnelles / correctives pour encourager des réponses complètes

J'imagine que cela fonctionne comme ceci:

• Le stockage est chiffré à l'aide d'une clé aléatoire synchrone.
• Lorsque l'utilisateur choisit ou modifie un mot de passe basé sur n'importe quelle entrée, que ce soit un mot de passe composé de lettres et de chiffres et de caractères, ou que ce soit un code PIN, ou un balayage de modèle, ou une empreinte digitale, ou toute autre entrée, un cryptage asynchrone Un algorithme est utilisé pour crypter la clé principale, de sorte qu'une identification correcte finit par décrypter l'entrée résultant en la clé principale, ce qui permet à son tour 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

Le gros truc ici est le cryptage asynchrone de la clé principale. Une fois qu'Android a la clé principale, il a la possibilité d'échanger des données avec le stockage. Ce n'est que lorsque l'utilisateur est connecté que cette clé principale est connue. Le chiffrement asynchrone est ce qu'on appelle le chiffrement à clé publique. Ce qui se passe, c'est qu'une clé publique crypte les données (la clé principale dans ce cas), et une clé privée décrypte les données. À ne pas confondre avec le chiffrement de stockage ici. Le stockage est juste un cryptage synchrone. Là, la même clé est utilisée pour chiffrer et déchiffrer. Mais la découverte / récupération de cette clé "maître", c'est le biggie. Cela signifie que si, à un moment donné, vous avez une méthode de connexion faible, comme par exemple "1234" comme code PIN, et que vous changez d'avis, et changez le code PIN en "5364", ce qui est plus difficile à deviner, sauf si cela était antérieur "1234 " a été volé, espionné, à tout moment, la sécurité vient de s'améliorer. Même chose lorsque vous changez la méthode de connexion en un mot de passe complet impossible à deviner ou à une attaque par dictionnaire. Le stockage lui-même n'a pas du tout besoin d'être rechiffré. Il s'agit de masquer cette clé principale - en interne. L'utilisateur ne voit jamais cette clé principale, car il s'agit très probablement simplement d'un 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é sur la planète n'a jamais pu trouver une clé correspondante comme ça. Le seul vecteur d'attaque espère une faiblesse de la part de l'utilisateur. L'utilisateur a peut-être choisi une connexion par code PIN. Si c'est 4 chiffres, alors c'est un maximum de 10000 codes PIN possibles. Le système d'exploitation peut "bloquer" l'appareil après en avoir essayé quelques-uns en peu de temps. La solution est alors de "pirater" l'OS, afin qu'il devienne possible d'essayer tous les codes PIN possibles sans que l'OS n'intervienne et ne bloque l'appareil. Je crois que c'est ainsi que le FBI a finalement eu accès au téléphone d'un criminel. Une entreprise tierce (une entreprise israélienne d'après mes souvenirs) a fait le piratage du FBI, je pense. Ils ont contourné cette limite de code PIN. Si la connexion est un mot de passe complet, et si l'utilisateur a choisi un mot de passe fort, et vous êtes sol. Pas dans une vie avec toute la puissance du processeur sur la planète ne piratera cela dans un million d'années. Je n'achète aucune de la NSA qui peut décrypter quoi que ce soit des rumeurs. Je pense que ces gens ont regardé un trop grand nombre de films d'hommes en noir. Il suffit de consulter les documents scientifiques sur les différents algorithmes de chiffrement (par exemple AES), et vous saurez que le piratage ne se produira tout simplement pas, sauf dans les temps anciens où il y avait des clés de 40 bits. Ces jours sont révolus depuis longtemps. AES128 est déjà inébranlable je pense, et si quelqu'un est concerné, le passage à AES256 le rend plus sûr d'une ampleur à la taille de l'univers à peu près. Peut-être qu'un jour les ordinateurs quantiques pourraient le décrypter, mais je suis sceptique. Je ne sais pas s'il est possible d'avoir un système de probabilités simplement mettre en évidence la solution. Nous verrons à ce sujet, éventuellement. Peut-être que c'est à quelques vies de toute façon. Rien à craindre pour le moment.

Donc, en fin de compte, la limitation de sécurité repose entièrement sur la méthode de connexion utilisée. On peut changer la méthode sans avoir à rechiffrer le stockage. Tout cela en raison du chiffrement de clé publique asynchrone de la clé principale.

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

Fondamentalement, une fois que votre appareil déchiffre le (s) fichier (s), il est possible d'y accéder directement par un processus doté des privilèges de superutilisateur. Ce processus pourrait accéder à votre appareil en exploitant une faiblesse de la ROM (Android OS) elle-même. (C'était récemment dans les nouvelles car certains défauts ont été révélés par WikiLeaks)

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

Avant root : Pour rooter un appareil, vous devez utiliser des outils externes qui ont tous un accès en profondeur à 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 aux uns qu'aux autres. Par exemple, KingoRoot a installé un programme sur mon PC qui se comportait comme un virus (a dû utiliser le double démarrage pour le supprimer).

Après avoir rooté : donner à un programme compilé (APK) un accès SU signifie qu'il peut faire tout ce qu'il veut sans restrictions ni indiquer quelle intention 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 un accès root donné, peut facilement accéder à tout type d'informations et les renvoyer à son serveur.

Le chiffrement complet de l'appareil protège-t-il mes données de Google et du gouvernement?

Google - oui. Il n'a pas la clé de déverrouillage.

Gouvernement (ou pirate) - non. car le gouvernement ou le pirate peut essentiellement utiliser un exploit qui interceptera le ou les fichiers comme je l'ai mentionné ci-dessus.

Les complexités des procédures / algorithmes de sécurité sont de peu d'utilité si elles peuvent être interceptées et contournées.

Modifier: il convient de mentionner que Google a réellement la possibilité de télécharger et d'installer / mettre à jour des applications sur votre appareil Android sans demander votre autorisation, ni même vous informer que la mise à jour a eu lieu. Et même sur un appareil rooté, il ne semble pas y avoir de moyen de bloquer cela sans perdre les fonctions clés (Play Store, Maps, Sync, etc.)