Est-il raisonnablement sûr d'utiliser le code PIN pour le chiffrement?

19

Sur Android 4.0 (Samsung Galaxy Nexus), il est possible de crypter le téléphone. J'ai trouvé cela sur le cryptage sur Android 3.0, les mêmes algorithmes sont-ils utilisés dans Android 4? http://source.android.com/tech/encryption/android_crypto_implementation.html

Ma principale question concerne l'utilisation d'un code PIN pour décrypter votre téléphone. Pourquoi suis-je obligé d'utiliser le même mot de passe pour déverrouiller mon écran et décrypter mon téléphone? Cette restriction ne me permettra d'utiliser qu'un mot de passe de faible complexité (comme un code PIN) car il serait difficile d'écrire soit 17 caractères pour déverrouiller mon téléphone pour un simple appel téléphonique.

Les tentatives de force brutale contre le déverrouillage de l'écran pourraient être évitées, c'est-à-dire par un redémarrage forcé tous les 5 essais. Il n'y a donc pas besoin d'un mot de passe très fort, un code PIN peut être suffisant.
Ce type de protection ne peut pas être utilisé sur le disque, il y a donc un plus grand besoin de mots de passe plus forts ici. (Cela n'aide pas beaucoup que l'entropie des mots de passe ait augmenté car il y aura très peu d'utilisateurs avec un mot de passe complexe, donc un attaquant pourrait simplement essayer la plupart des mots de passe avec une faible complexité). Quelle est la raison d'être obligé d'utiliser le même mot de passe pour les deux fonctionnalités?

security  encryption 
— Christopher Käck
source
3
Oui, mais si j'utilise le mot de passe, j'aurais besoin de l'utiliser pour simplement déverrouiller mon écran. Pas très pratique pour taper 17 caractères pour appeler rapidement. Ainsi, la plupart des utilisateurs se débrouilleront avec les codes PIN et ce serait la première chose qu'un attaquant essaierait. Une meilleure approche serait peut-être d'autoriser les mots de passe pour le chiffrement du disque et d'autoriser de simples codes PIN sur l'écran de verrouillage. Pour éviter les tentatives de bruteforce sur l'écran de verrouillage, il peut y avoir un redémarrage forcé après 3 tentatives infructueuses entraînant une demande de mot de passe.
— Christopher Käck
1
Je ne sais pas que quelqu'un d'autre que Google pourrait vous expliquer le raisonnement, malheureusement. Vous pourriez essayer le traqueur de bogues Android pour déposer une demande de fonctionnalité, probablement. Cela semble une chose sensée à déposer là-bas.
— eldarerathis
2
Oui, contre la tentative de connexion sur l'écran de déverrouillage, mais pas contre le décryptage du disque dur. C'est ce que j'essaie de dire, le déverrouillage de l'écran n'a pas besoin d'être aussi long que le cryptage du disque dur (qui doit être beaucoup plus long que 4 chiffres) et donc on ne devrait pas être obligé d'utiliser le même pour les deux.
— Christopher Käck
1
+1, je suis totalement avec vous @ ChristopherKäck Cette décision n'a pas de sens, les ingénieurs de Google auraient dû mieux savoir, j'espère qu'ils la corrigeront bientôt.
— João Portela
1
@Christopher: mais vous basez votre décision sur une prémisse incorrecte, le chiffrement sur disque était AES 128 bits, pas le code PIN à 4 chiffres. Déterminer si ce schéma est sécurisé ou intrinsèquement défectueux, n'est pas l'expertise d'Android.SE.
— Lie Ryan

Réponses:

4

Je pense avoir trouvé la solution. Vérifiez ce lien . C'est un hack et cela nécessite un téléphone pour être enraciné, mais cela vous permet d'utiliser un mot de passe alphanumérique pour le cryptage et un code PIN pour le déverrouillage de l'écran.

— Oscar_6
source
1

En utilisant un mot de passe / une phrase par rapport à une broche à quatre chiffres, vous augmentez la sécurité de votre appareil. L'astuce est que, même en ayant un mot de passe à quatre caractères, vous venez d'augmenter votre sécurité pour deux raisons:

  • Vous avez augmenté les personnages disponibles.
  • Vous avez enlevé aux attaquants la connaissance de votre longueur de pw.

Si un attaquant sait que votre mot de passe est de 14 caractères, il est plus sûr qu'un mot de passe de quatre ou huit caractères, mais les statistiques typiques utilisent des plages (1-4, 1-8, 1-14) et non la réalité (qui serait simplement de calculer combinaisons disponibles d'une seule longueur).

Actuellement, il est tout simplement FACILE D'ACCÉDER aux données de votre téléphone. Votre grand-mère a la capacité de le faire (sans vous offenser ni à votre famille: P). Donc, bien que vous ayez raison de dire qu'il existe des limites à ce cryptage, la version «cassée» fonctionne BEAUCOUP mieux que les données non cryptées actuellement pratiquées.

C'est à vous de juger de la sensibilité et de la confidentialité de vos données, ainsi que de la cible que vous visez pour que ces données soient volées. Le choix d'un mot de passe approprié est de votre responsabilité une fois que vous avez évalué ces risques.

— EarthmeLon
source
2
Oui, mais je pense que ce serait une solution simple au problème d'avoir différents mots de passe pour déverrouiller l'écran et pour décrypter l'appareil (comme je l'ai mentionné ici android.stackexchange.com/questions/17086/… ) car ils sont utilisés dans différents senarios et doivent avoir des attributs différents.
— Christopher Käck
1

Si vous essayez de casser le chiffrement du disque, indépendamment du reste de l'appareil dans un scénario où vous avez un appareil hors tension, ou simplement des puces de mémoire, alors c'est un vecteur d'attaque différent de celui utilisé sur un appareil sous tension appareil protégé par mot de passe où la clé de déchiffrement peut être conservée en mémoire (conduisant à des vulnérabilités telles que les voleurs de clés de chiffrement Firewire répandus sur les PC utilisant un ancien logiciel de chiffrement FDE et non un module de type TPM), ou l'écran de déverrouillage peut être brutal - forcé (ou a ses propres vulnérabilités).

Si vous attaquez le disque directement, dans ce cas, vous n'attaquez pas le code PIN à 4 chiffres ou le mot de passe utilisateur qui crypte l'appareil, ce que vous attaquez est la clé AES 128 bits:

La clé principale est un nombre de 128 bits créé en lisant dans / dev / urandom. Il est chiffré avec un hachage du mot de passe utilisateur créé avec la fonction PBKDF2 à partir de la bibliothèque SSL. Le pied de page contient également un sel aléatoire (également lu dans / dev / urandom) utilisé pour ajouter l'entropie au hachage de PBKDF2 et empêcher les attaques de table arc-en-ciel sur le mot de passe.

À partir du point 4 sous « Activation du cryptage sur l'appareil » des notes sur la mise en œuvre du cryptage dans Android 3.0 que vous avez lié.

(allait être un commentaire mais s'est avéré beaucoup trop long)

— GAThrawn
source
1
Merci pour ce gentil commentaire! Une chose cependant; ne suis-je pas à la recherche du mot de passe de l'utilisateur (qui sera probablement un code PIN à 4 chiffres, car vous êtes obligé de partager la clé avec le déverrouillage de l'écran et toute autre chose sera compliquée à taper pour passer un appel téléphonique) pour décrypter le 128 bits Clé AES? (au lieu de rechercher la clé directement). Si je hache toutes les 10000 broches avec la fonction PBKDF2 + sel, n'y a-t-il pas seulement 10000 tentatives de décryptage à essayer alors?
— Christopher Käck
@Melpomene "L' attaque de la table arc-en-ciel " dont ils parlent est l'endroit où vous pré-cryptez les 10 000 combinaisons pour voir à quoi elles ressemblent cryptées, puis comparez simplement ce qui est sur le disque à ce qui est dans votre table arc-en-ciel. Le " sel aléatoire " est ce qui est utilisé pour aider à éviter cela en créant bien plus de 10 000 combinaisons que vous devrez deviner (à moins que vous n'arriviez à trouver le "sel" en premier).
— GAThrawn
1
Un arc-en-ciel est un moyen intelligent de stocker des mots de passe cryptés, oui. Et si un sel est utilisé, il devra probablement être spécialement conçu juste pour casser les mots de passe avec ce sel. Ce n'est pas une opération très difficile lorsqu'il n'y a que 10 000 mots de passe parmi lesquels choisir. Notez que le Salt est toujours considéré comme connu de l'attaquant (car il semble être lu à partir de / dev / urandom dans les documents, il est plus probable qu'il soit stocké en texte clair ou crypté avec le mot de passe de l'utilisateur). Dans les deux cas, le mot de passe utilisateur est le maillon faible.
— Christopher Käck
Mais je n'aurais même pas besoin de construire une table arc-en-ciel, car le stockage (ou le calcul) de 10 000 hachages n'est pas si difficile sur ma mémoire (processeur).
— Christopher Käck
L'utilisation d'une fonction de dérivation de clé comme PBKDF2 semble être une bonne nouvelle, mais une broche typique à 4 chiffres n'est encore que 10000 combinaisons possibles.
— João Portela
0

Si vous avez activé l'effacement à distance (en supposant qu'il fonctionne toujours avec un appareil crypté), le code PIN peut ne pas sécuriser votre appareil pour toujours, mais il peut le faire suffisamment longtemps pour vous donner le temps d'effacer votre appareil.

— Chance
source
2
Le problème est qu'un code PIN court ne peut sécuriser l'appareil que lorsqu'il est allumé. Par conséquent, la désactivation d'un appareil volé empêche son effacement et, en outre, le code PIN peut être rompu lors d'une attaque par force brute hors ligne. Par conséquent, un code PIN court ne vous aide pas dans cette situation.
— Robert
@Robert, je ne connais pas trop le fonctionnement du nettoyage à distance. Si cela se fait via Exchange, le téléphone doit-il être au même moment que la commande d'effacement à distance est émise? Je pense que si je peux émettre un effacement à distance dans les 30 minutes environ après avoir perdu mon téléphone, cela me suffit, mais je n'ai pas de données financières, ma principale préoccupation est mon e-mail de travail GMail.
— Chance
2
Le téléphone doit être allumé et en ligne un certain temps après avoir émis la commande d'effacement à distance. Si le téléphone a été éteint (et reste éteint), la commande d'effacement est inutile.
— Robert
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.