Ton téléphone et ton portable

On te pique ton téléphone dans le tram. Tout est dessus : tes photos, tes discussions, tes mails, l'appli de la banque. Et tu l'as protégé avec … quatre chiffres. Pourtant le voleur n'y entre pas, même pas s'il dessoude la puce et met la carte mémoire dans son propre ordinateur. Ça semble trop beau. Ce chapitre explique pourquoi c'est pourtant juste, et exactement quand ça ne l'est plus.

Tout sur le disque est du texte chiffré

Le stockage de ton appareil est chiffré de bout en bout avec AES, le même chiffre que dans chapitre 4. Ce n'est pas un programme supplémentaire qui tourne : il y a un bout de matériel entre la puce de stockage et la mémoire de travail qui déchiffre chaque bloc à la lecture et le chiffre à l'écriture. Tu ne t'aperçois de rien, et c'est le but.

Où est la clé, alors ?

C'est ici que se trouve le vrai déclic. Une clé AES fait 256 bits : un nombre parmi 2²⁵⁶ possibilités, un nombre de 78 chiffres. Ton code fait quatre chiffres. Ces deux-là ne peuvent pas être la même chose.

Calcule avec moi. Quatre chiffres de 0 à 9 donnent 10 × 10 × 10 × 10 possibilités :

10⁴ = 10 000

Dix mille. Exprimé en bits, ça fait log₂(10 000) ≈ 13,3 bits — un peu plus que 2¹³ = 8192, un peu moins que 2¹⁴ = 16 384. Un ordinateur parcourt dix mille possibilités en moins d'une seconde. Si ton code PIN était la clé, ton appareil serait ouvert en un clin d'œil.

Le code PIN n'est donc pas la clé. La vraie clé est aléatoire et longue de 256 bits, et elle se trouve dans une puce à part qui vérifie le code PIN et ne la libère qu'ensuite.

Cette puce conserve aussi un nombre unique gravé en usine dans le silicium et qui n'en sort jamais. La clé de ton stockage est dérivée de ce nombre et de ton code PIN ensemble. Conséquence : dessouder la puce de stockage et la mettre dans un autre ordinateur ne donne rien. Le nombre unique reste dans l'appareil, et sans ce nombre il n'y a pas de clé, quel que soit le nombre de codes PIN que tu essaies.

Pourquoi quatre chiffres suffisent ici

Dans chapitre 3, la lenteur était l'arme : une fonction de hachage qui fait exprès des centaines de milliers de tours, pour que l'attaquant mette une fraction de seconde par essai au lieu d'un milliardième. Ici il se passe la même chose, mais plus radicalement, et pas avec du calcul mais avec une horloge.

La puce de sécurité compte les tentatives ratées et refuse tout simplement de répondre. Redémarrer n'aide pas — le compteur est dans la puce, pas dans le système d'exploitation, et après un redémarrage le temps d'attente recommence même à courir. Voici les vrais barèmes :

Compte ce que ça veut dire. Il y a dix mille codes. Sur un iPhone, le voleur en a neuf, et puis c'est fini. Sur Android il en a dix-neuf, dont le dernier lui coûte neuf ans. Dix-neuf sur dix mille : il a une chance sur environ 526 s'il devine bien, et 1234 ou ton année de naissance ne sont hélas pas de bonnes suppositions.

C'est pour ça que quatre chiffres suffisent ici et pas sur un site web. Sur un site web, l'attaquant peut copier toute la liste et deviner chez lui des milliards de fois par seconde, et le défenseur n'a que la lenteur par essai. Ici il ne peut pas copier : il n'y a qu'un seul exemplaire de la clé, il est dans une seule puce, et cette puce compte. La lenteur n'est plus un retard mais un mur.

Sur l'iPhone, tu peux encore activer Effacer les données dans les réglages du code. L'appareil s'efface alors lui-même après dix tentatives ratées d'affilée. Pèse ça contre un petit frère qui adore appuyer sur les boutons.

Allumé ou éteint fait une grande différence

Un appareil complètement éteint n'a la clé nulle part. Elle doit encore être calculée à partir de ton code PIN et du nombre de la puce, et jusqu'à ce que ça arrive, tout ce qui est sur le stockage est du bruit. C'est l'état avant le premier déverrouillage : BFU.

Mais dès que tu as tapé ton code une fois après l'allumage, la clé est dans la mémoire de travail, et elle y reste — même si tu reverrouilles l'écran. Il le faut bien : ton téléphone doit encore faire sonner des réveils, recevoir des messages et prendre des appels avec un écran verrouillé. C'est l'AFU, après le premier déverrouillage, et c'est l'état dans lequel ton appareil se trouve presque toujours.

Apple rend ça explicite avec des classes de protection. La plus stricte jette la clé dès que tu verrouilles l'écran. La classe par défaut pour les données des applis tierces s'appelle Protected Until First User Authentication et ne le fait pas : cette clé reste en mémoire jusqu'à ce que tu éteignes l'appareil.

Concrètement : un téléphone volé qui était éteint est une pierre. Un téléphone volé qui était allumé et déjà déverrouillé ce jour-là est un coffre-fort dont la clé traîne sur la table à l'intérieur — toujours difficile, mais c'est exactement la différence avec laquelle les entreprises de criminalistique gagnent leur argent. D'où le conseil que tu entends parfois et qui n'est pas de la superstition : éteins complètement ton appareil si tu le laisses vraiment sortir de tes mains, ou si tu crains de le perdre. Redémarrer suffit — après un redémarrage, c'est de nouveau BFU.

Ce contre quoi ça ne protège pas

Le chiffrement du disque protège contre une seule chose : quelqu'un qui met la main sur ton appareil pendant qu'il est verrouillé. Rien de plus. Si ton portable est ouvert et que tu es connecté, tout est simplement lisible — pour toi, pour l'ami qui se glisse derrière, et pour un programme que tu as installé par erreur. La clé est à ce moment-là en service, donc tout est gentiment déchiffré pour tout le monde. Il en va de même pour quelqu'un qui regarde par-dessus ton épaule, pour une capture d'écran, et pour un fichier que tu envoies toi-même vers un cloud : celui-là part déchiffré et relève du chiffrement de ce cloud, pas de celui de ton disque. La clé que tu as imprimée depuis chapitre 8.1 se lit tout aussi bien sur un portable déverrouillé que sur papier.