Interview : « Apple semble avoir utilisé toutes les bonnes pratiques cryptographiques »

Stéphane Moussie |

Défendu ardemment par Apple et l'ensemble de l'industrie high-tech, conspué par certains politiques et représentants des forces de l'ordre, le chiffrement des données est au centre de débats enflammés depuis plusieurs mois. Gage de la protection de la vie privée pour les uns, il est l'obstacle entravant la sécurité des citoyens face aux criminels pour les autres.

Mais de quoi parle-t-on exactement ? Comment fonctionne le chiffrement ? Quelles sont les technologies employées par Apple ? Nous avons interrogé Vincent Bénony, titulaire d'une thèse en cryptographie et développeur du logiciel de rétro-ingénierie Hopper (lire aussi Interview : Hopper, le logiciel qui renverse la sécurité du Mac).

Crédit assillo CC BY

MacGeneration : De manière très générale, qu'est-ce que le chiffrement ? À quoi ça sert et comment cela fonctionne ?

Vincent Bénony : Le principe du chiffrement est de sécuriser un échange de données en les rendant inintelligibles par une personne qui intercepte le message, mais qui ne possède pas la clé de déchiffrement. Ça va même un petit peu plus loin, puisque l'idée du chiffrement est de transformer des données, comme un texte, en quelque chose d'indiscernable de données purement aléatoires. C'est-à-dire que si je vous donne une série de bits sans plus de détails, il ne vous sera pas possible de me dire s'il s'agit simplement de « 0 » et de « 1 » tirés à pile ou face, ou bien s'il s'agit de quelque chose qui a été chiffré.

Il existe deux grandes familles de systèmes de chiffrement : les systèmes symétriques, et les systèmes asymétriques. La différence concerne les clés.

Dans un système de chiffrement symétrique, comme l'AES, le RC4, etc., la clé qui sert au chiffrement est la même que celle qui sert au déchiffrement. Deux personnes qui souhaitent s'échanger des messages chiffrés en AES doivent au préalable s'être échangées une clé secrète commune.

Pour les systèmes asymétriques, comme le RSA, la clé de chiffrement n'est pas la même que la clé de déchiffrement : l'une est publique (la clé de chiffrement), l'autre est privée (la clé de déchiffrement). Il ne doit pas être possible de retrouver facilement la clé privée à partir de la clé publique. Dans ce cas, si je souhaite échanger des messages chiffrés en RSA avec quelqu'un, je construis dans mon coin ma clé publique et ma clé privée, et j'envoie ensuite la clé publique à mon interlocuteur. Il fait de même de son côté, et quand je souhaite lui envoyer un message, j'utilise sa clé publique.

Les systèmes de chiffrement asymétriques peuvent aussi servir à faire de la signature numérique. Une signature numérique sert par exemple à prouver que le document n'a pas été modifié, et qu'il provient bien d'une personne donnée. C'est ce qui est fait quand on paie ses impôts en ligne par exemple. Dans ce cas, le rôle des clés est inversé, et la personne qui désire signer un document va calculer une empreinte numérique du document (comme un condensat SHA-256 par exemple), et chiffrer cette empreinte avec sa clé privée. Toute personne qui souhaite vérifier l'authenticité de la signature peut le faire en calculant à son tour la même empreinte, et en la comparant à l'empreinte déchiffrée par la clé publique.

Depuis OS X Yosemite, Apple pousse à l'activation de FileVault, la fonction de chiffrement des Mac. Sur une machine équipée d'un SSD, la perte de performances est quasiment inexistante. Vous trouverez toutes les informations essentielles sur FileVault sur cette fiche technique.

Est-ce que l'on peut chiffrer tous les appareils informatiques et tous les types de données ? Faut-il un composant spécial pour gérer le chiffrement ?

Il est tout à fait possible de chiffrer n'importe quel type de données. Après tout, un fichier n'est qu'une longue suite de 0 et de 1. Le sens qu'on lui donne est purement subjectif. Je veux dire que le concept de document PDF ou d'image PNG n'est pas intrinsèque aux données, c'est juste une question d'interprétation par les applications. Même la notion de caractère dans un fichier n'est qu'une convention…

En général, on regroupe ces bits par paquets de 8, ce qui permet de les considérer comme un nombre en base 2, et donc d'en calculer une valeur entre 0 et 255. Ensuite, on utilise des choses, comme la table ASCII, qui est un tableau de 256 signes, où l'on a associé un caractère, ou un symbole, à chaque nombre. Par exemple, la valeur 65 est associée à la lettre "A" majuscule.

Quand un logiciel lit un fichier, il tente de donner un sens à cette suite de nombres en fonction de règles. Par exemple, si la suite de bits, transformée en une suite de caractères grâce à la table ASCII, commence par les symboles "%PDF", alors on va utiliser les règles qui définissent les documents PDF pour interpréter le reste du fichier. Si au contraire le document commence par les nombres 31, puis 139, alors il y a de fortes chances que ce soit un fichier compressé en gzip, etc.

Et on peut descendre encore plus bas, car même la notion de fichier n'est qu'une convention : un disque dur, une clé USB, ou tout autre support de stockage ne sont que des immenses suites de bits, que le système d'exploitation interprète comme des fichiers selon des règles bien précises qui diffèrent d'un OS à l'autre (HFS+ sous OS X, NTFS sous Windows, Ext4 sous Linux, et bien d'autres).

En partant de ce principe, strictement tout peut être chiffré ! Je peux tout à fait décider de donner une autre interprétation aux données, et les utiliser en entrée à mon système de chiffrement. Pour être à nouveau compréhensible par le système d'exploitation et les applications, il suffit de déchiffrer la suite de nombres.

Souvent, les systèmes de chiffrement sont directement intégrés aux systèmes d'exploitation. En gros, ils se logent entre le pilote du disque dur (qui écrit les données brutes sur le disque) et le système de fichiers. Ils procèdent au chiffrement et au déchiffrement à la volée, en fonction d'une clé qui dépend d'un mot de passe par exemple.

Il n'est pas nécessaire d'avoir du matériel dédié pour faire du chiffrement. Par contre, les opérations de chiffrement sont généralement coûteuses en termes de CPU, et c'est pourquoi on a tendance à équiper les appareils de puces dédiées pour soulager le CPU, surtout sur les appareils mobiles. Dans le cas des processeurs Intel, le CPU possède des fonctions primitives qui permettent de simplifier le calcul de l'AES.

Depuis l'iPhone 3GS, pour activer la fonction de protection des données qui améliore le chiffrement, il suffit de définir un code à 4 chiffres (ou plus), ce qui est fortement encouragé lors de la première configuration.

Pour chiffrer leurs données, les appareils iOS utilisent la technologie AES 256-bits. Quelles sont ses caractéristiques et quelle est sa robustesse ?

L'AES (Advanced Encryption Standard) est un système de chiffrement qui a été mis au point dans le cadre d'un concours au tout début des années 2000, pour remplacer le vieillissant système de chiffrement DES (Data Encryption Standard), utilisé jusque-là pour chiffrer les documents officiels aux États Unis. Il s'agit d'un système de chiffrement symétrique, qui peut fonctionner avec des clés de 128, 192 ou 256 bits.

Il fait partie de la famille des systèmes de chiffrement par bloc (en opposition aux systèmes de chiffrement par flot), ce qui veut dire qu'il découpe les données à chiffrer en blocs de 128 bits (16 octets), et procède à différentes transformations et mélanges en fonction des bits de la clé. Ce qui est intéressant avec l'AES, c'est qu'il a été pensé pour que les différents calculs soient simples à mettre en œuvre sur un CPU classique.

C'est un système qui a largement fait ses preuves ces dernières années, et on ne lui connaît pas de véritable biais exploitable. Ça signifie que pour déchiffrer un message dont on n'a pas la clé, il faut en essayer un grand nombre, et voir si le message déchiffré a un sens.

Imaginez que vous souhaitiez retrouver la clé qui a servi au chiffrement d'un message en AES 256. En moyenne, il faudrait tester la moitié de l'espace des 2^256 clés possibles, soit 2^255 clés. Imaginez encore que vous disposiez d'un appareil capable de tester une clé toutes les nanosecondes. Il faudrait donc environ 5,79 * 10^76 tentatives, ce qui fait approximativement 6,7 * 10^62 jours, ou encore 1,8 million de milliards de milliards de milliards de milliards de milliards de milliards d'années en moyenne pour déchiffrer un message…

Il y a quelques années, des chercheurs ont trouvé quelques petites faiblesses dans l'algorithme de l'AES qui permettent de réduire le temps de calcul par 4 (ce qui est suffisant en cryptographie pour dire que le système est "cassé"), mais même dans ce cas, ça laisse pas mal de marge.

Récemment, Apple a indiqué à un juge qu'elle ne pouvait pas accéder aux données d'un iPhone verrouillé. Sur son site, la firme explique la même chose : « Sur les appareils sous iOS 8 ou ultérieur, vos données personnelles sont protégées par votre code. En effet, pour ces appareils, Apple ne peut répondre aux demandes d’extraction de données iOS émanant des autorités » Est-ce vraiment impossible pour Apple de passer outre les protections d'un iPhone ? C'est pourtant elle qui a mis au point le système de chiffrement. N'a-t-elle pas les moyens d'avoir la clé pour ouvrir un iPhone sous iOS 8 ou ultérieur ?

Le schéma mis en place par Apple est détaillé dans un document public [Guide de sécurité iOS]. Il est assez complexe, et fait appel à tout un tas de clés en cascade.

Pour résumer, chaque fichier est chiffré avec une clé différente, générée aléatoirement au moment de la création de ce fichier. Cette clé est conservée chiffrée à l'aide d'une autre clé, qui est elle-même calculée en fonction d'un identifiant matériel (qui a été injecté dans le téléphone lors de sa fabrication), et du code PIN de l'utilisateur.

Cette dernière clé est calculée en interne par la puce cryptographique qui a la charge d'effectuer les opérations de chiffrement et de déchiffrement. Ainsi, elle ne sort pas, et elle n'est pas accessible au système d'exploitation, ni même aux différentes interfaces, comme le JTAG. Seules les données chiffrées et déchiffrées sortent de la puce. Pour extraire l'identifiant matériel de la puce, il faudrait la décortiquer physiquement à l'aide d'appareils extrêmement coûteux ; c'est très compliqué, très délicat, et surtout, très aléatoire.

Toute la sécurité du système repose donc sur la non-divulgation de l'identifiant matériel. Il est très probable que cet identifiant soit issu d'un processus aléatoire purement physique lors de la fabrication de la puce, ce qui exclut la possibilité de le lire et de le stocker.

Si Apple souhaitait mettre en place une porte dérobée, une technique possible serait de réduire l'entropie du générateur aléatoire utilisé pour créer les clés de chiffrement des différents fichiers. En gros, l'idée serait de faire en sorte que la clé ne soit pas totalement aléatoire, mais seulement en partie aléatoire, ce qui réduirait considérablement la quantité de calculs à faire pour la retrouver. Même si c'est techniquement faisable, il semble fort peu probable qu'ils l'aient fait… Au contraire, Apple semble avoir utilisé toutes les bonnes pratiques cryptographiques à ce niveau.

Les fichiers chiffrés par iOS semblent donc bien à l'abri, et je vois effectivement assez mal comment Apple pourrait passer outre…

Après, rien ne dit qu'on ne découvrira pas une méthode pour exfiltrer l'identifiant matériel de la puce cryptographique par un canal auxiliaire. Ce sont des choses qui se sont déjà vues. Par exemple, sur certaines smart cards (comme les cartes bancaires, ndr), en mesurant les fluctuations de la consommation énergétique pendant une phase de chiffrement, il était possible de récupérer de l'information sur les bits de la clé secrète. Mais c'est un domaine qui est maintenant relativement bien maîtrisé, et il y a peu de chance que les puces d'Apple en souffrent.

Vue d'ensemble de l'architecture de protection des données d'iOS. Schéma Apple.

Le gouvernement britannique réclame depuis des mois une « porte d'entrée » — de la novlangue pour parler d'une porte dérobée — dans les programmes de chiffrement. Est-ce qu'une porte dérobée réservée à une seule organisation, dans le cas présent les autorités, est faisable ? N'y a-t-il pas le risque que d'autres personnes s'engouffrent dans cette porte, comme prévient Tim Cook, entre autres ?

Une porte dérobée réservée aux autorités, c'est tout à fait faisable. Il est possible, par exemple, de faire en sorte que les clés, utilisées pour chiffrer les fichiers, soient stockées de manière chiffrée comme c'est le cas actuellement, mais en double, avec deux clés différentes : une fois avec la clé utilisée actuellement, et une autre fois avec une clé que les autorités possèdent.

Malgré tout, il y aurait plusieurs problèmes. Premièrement, s'il y a une fuite de la clé gouvernementale, tout le système tombe par terre, et il ne sera pas possible de faire marche arrière. Aujourd'hui, il ne peut pas y avoir de fuite, puisque la seule copie de la clé utilisée se trouve dans la puce.

L'autre problème, c'est qu'il semble a priori impossible de modifier les iPhone existants pour fonctionner avec un nouveau système contenant une porte dérobée. Il faudrait en effet que la puce cryptographique intègre aussi la clé partagée. Or, ce n'est possible que lors de la fabrication. Ou alors, il faudrait tout implémenter de manière logicielle, avec les problèmes de performances qui vont avec…

Est-ce que tu penses que tout le monde a intérêt à chiffrer ses appareils et ses communications ?

J'aurais tendance à pousser les personnes dans mon entourage à chiffrer au maximum leurs données, tant que ça ne complique pas trop l'utilisation du service. Ne serait-ce que pour éviter les fuites d'informations sensibles, comme certains mots de passe, des cookies de session, etc. Il y a autour de moi beaucoup de gens qui se connectent à des réseaux Wi-Fi gratuits, et qui ne réalisent pas à quel point il est simple de récupérer des données dans ce cas-là.

Un procureur de Manhattan a récemment déclaré qu'il n'avait pas pu mener 111 mandats de perquisition de données à cause du système de chiffrement d'iOS 8. Apple ne va-t-elle pas trop loin dans son « engagement de confidentialité » ? Tim Cook a élevé le respect de la confidentialité des utilisateurs au rang de principe moral. Mais Apple n'a-t-elle pas également le devoir moral de coopérer avec les autorités dans l'intérêt commun ?

C'est un avis très personnel, mais je ne pense pas qu'il faille faire marche arrière concernant le chiffrement des appareils iOS. De toute façon, si une personne souhaite réellement cacher ses communications aux autorités, il y a des tonnes de solutions très simples déjà disponibles, que ce soit le chiffrement par des outils tiers, de la stéganographie, etc. Je doute que les terroristes aient attendu iMessage pour ça.

Et concernant l'utilisateur lambda, le chiffrement systématique des données d'iOS permet de limiter la casse, par exemple, en cas de vol. D'autant plus qu'Apple a tendance à pousser ses utilisateurs à enregistrer tout un tas de données très personnelles dans leur téléphone, comme le numéro de leur carte bancaire par exemple (pour remplir les formulaires d'achat sur Internet), et ce serait une catastrophe s'il était facile de récupérer toutes ces données après un vol.


avatar initialsBB | 

Un truc que je n'ai jamais très bien compris c'est comment, dans le chiffrement asymétrique, les données sont protégée. Qu'est-ce qui empêche quelqu'un de récupérer la clé publique pour déchiffrer les messages ?

avatar bsr43 | 

La clé publique ne permet pas de déchiffrer un message, même si vous en êtes l’auteur. Seule la clé privée permet de faire l’opération de déchiffrement. Et justement, toute la sécurité réside dans le fait qu’il est difficile de retrouver la clé privée à partir de la connaissance de la clé publique seule.

avatar bugman | 

@initialsBB :
On ne peux pas a partir d'une clé publique retrouver (calculer) la cle privé associé.

avatar bugman | 

@bugman :
Une histoire de factorisation, si je ne dis pas de bêtises.

avatar Bigdidou | 

@bugman :
Ben faudrait nous expliquer en termes de non spécialistes ce que sont une clé publique et une clé privée, alors. Et comment elle sont mises en œuvre.
Pour moi, il y avait soit une clé publique, détenue par exemple par un éditeur, soit une clé privée, détenue à chaque bout de la chaîne par les personnes qui communiquent entre elles...
Je ne savais pas que leur utilisation était intriquée...

avatar bsr43 | 

Le problème, c’est que la justification mathématique derrière RSA, par exemple, dépasse de très loin le cadre de l’article.

Mais pour faire court, le principe est que l’on calcule deux quantités à partir d’un secret, que l’on appelle arbitrairement « clé privée » et « clé publique ».

Toujours dans le cas de RSA, par exemple, le secret c’est le fait d’avoir choisi deux nombres premiers « P » et « Q », très grands (de l’ordre de plusieurs centaines de chiffres par exemple). On calcule le produit de ces deux nombres, que l’on appelle « N = P x Q ». La clé publique sera par exemple le couple "(3, N)", tandis que la clé privée sera le couple "(invmod(3, phi(N)), N) », où « invmod(A, B) » représente l’inverse de A modulo B, et « phi(N) » l’indicatrice d’Euler. Ce sont des choses très faciles à calculer… quand on connaît P et Q. Par contre, quand on ne connaît que N, il est très difficile de calculer phi(N) sans factoriser N.

avatar bugman | 

@Bigdidou :
En fait il faut 4 clés. Tu gardes ta privée, tu partages ta publique et ton correspondant fait de même de son côté (si tu attends une réponse chiffrée de sa part).

avatar bugman | 

"En général, on regroupe ces bits par paquets de 8, ce qui permet de les considérer comme un nombre en base 2, et donc d'en calculer une valeur en 0 et 255."

Mhhhh !?! C'est moi ou ce n'est pas clair ?
En général, on regroupe ces bits (base 2) en groupe de 8 (byte), ce qui permet d'obtenir des valeurs comprises entre 0 et 256 (2^8).

avatar Sostène Cambrut | 

@bugman

Si tu n'exclus aucune borne de ton intervalle il y a 257 valeurs entre 0 et 256 puisque tu comptes le zéro

2^8 ça fait 256, donc il n'y a bien que 256 valeurs. Soit on décide de commencer à compter à 0 et on va jusque 255, soit on commence à 1 et on va jusque 256.

avatar bugman | 

@Sostène Cambrut :
Oui. (De 0 à 255 ou de 00 à FFT en hexa) j'ai juste fait une erreur plus haut.

avatar c.jack.s | 

Pour répondre à ta question bugman il y a 256 valeurs possibles qui vont de 0 à 255.

avatar bugman | 

@c.jack.s :
Oui, j'ai fait une etite erreur au dessus (entre 0 et 255).
Je trouve juste la phrase mal ecrite.

avatar jusdei | 

Article vraiment très intéressant !

avatar Jeff06am | 

Au top cet article, merci iGen !

avatar Alexandre | 

Excellent article !!
En plus je ne connaissait pas l'existence du guide de sécurité iOS, merci beaucoup j'ai de la lecture x)

avatar kinou_ | 

Brice de Nice devait surement faire parti de l'équipe de chercheurs qui ont trouvé des "petites faiblesses" dans l'algorithme de l'AES.

avatar Mdtdamien | 

Excellent article.
C'est un plaisir les interviews, en apprend énormément

avatar angelbj | 

Super article, continuez à nous pondre ce type d'article

avatar ziggyspider | 

Le chiffrement des données "gage de la protection de la vie privée" … disons plutôt d'une petite partie de la vie privée. Rien n'empêche ces entreprises high-tech de la piétiner, notre vie privée, pour leur(s) plus grand(s) profit(s) !
Sinon, très bon article. Je vois l'utilité du chiffrement pour les données sensibles (mot de passe, CB, …), mais de là à crypter "je prend du pain ?" ou "je rentre à 8H", ses photos, sa musique et tout le barda insignifiant, je ne vois pas l'intérêt. Pour James Bond et les apprentis-terroristes, qu'ils se cassent un peu le bonnet à trouver une solution sans leur mâcher le travail.

avatar Hideyasu | 

@ziggyspider :
Tu peux aussi partager des données sensibles par iMessage. C'est pas parce que 80% des gens ne le font pas qu'il faut laisser les 20% à l'abandon. Surtout si ca ne change rien pour les 80%.

avatar minitoine | 

Admettons une conversation cryptée entre A et B avec des clés asymétriques.

Pour communiquer en sécurisé avec B, A doit utiliser la clé publique de B pour crypter ses messages. (Il faut avant que B envoie sa clé publique), une fois reçu, B peut décrypter le message grâce à sa clé privé.

Pour communiquer en sécurisé avec A, B doit utiliser la clé publique de A pour crypter ses messages.
(Il faut avant que A envoie sa clé publique), une fois reçu, A peut décrypter le message grâce à sa propre clé privé.

En d'autres termes, A dispose d'une clé privé et publique. C'est a dire, que tout le monde peut parler en crypté avec A en lui envoyant des messages cryptés grâce à sa clé publique, mais seulement A est capable de décoder le message.

Ainsi, quand vous êtes en discussions avec un site bancaire, ou n'importe quel site sécurisé, le serveur et vous échangez vos clé publiques, et utilisez chacun la clé publique de l'autre pour communiquer..

Sachant qu'il est impossible en temps humain de récupérer la clé privé, vous êtes donc sur que vos messages ne sont décryptées que par vous, tant que vous êtes... vivant.

J'espère que c'est un peu plus clair .. :)

avatar Bigdidou | 

@minitoine :
Merci...
Je vais rerererelire pour essayer de bien comprendre.
C'est là qu'on voit qu'on perd des neurones avec l'âge, quand même... ;)

avatar minitoine | 

Pour résumer le résumé, pour crypter asymétriquement, tu as besoin de 2 clés

la clé publique, qui est disponible à tous, sert à crypter, chiffrer le message

la clé privée, que seul toi connait, qui sert à décrypter.

(C'est comme si, pour la porte d'entrée de ta maison, tout le monde avait une clé pour fermer ta porte, mais seul toi a une clé pour l'ouvrir, c'est un peu bizarre comme métaphore, mais c'est bien ce qui se passe ici et c'est pas plus mal en fin de compte... ;) )

Quand tu "discutes" en crypté, à chaque fois que tu envoies, tu utilises la clé publique de ton destinataire qui lui utilise sa clé privée pour déchiffrer. Chaque fois que tu reçois, ton interlocuteur a utilisé ta clé publique pour crypter son message, que seul toi peux lire avec ta clé privée.

Pour un message envoyé et reçu, 4 clés sont donc intervenues. 2 clés publiques des deux interlocuteurs et leurs clés privées.

Dans cette histoire, il faut donc un premier message, non crypté, afin de notifier le correspondant de sa clé publique, ensuite, la conversation passe en chiffré.

A envoie sa clé publique.
B reçoit la clé publique de A.
B peut parler en crypté à A, car A a sa clé privé pour déchiffrer.
B envoie sa clé publique. (En crypté ou non je ne sais pas, mais il le peut)
A reçoit la clé publique de B
A peut parler en crypté à B, car B a sa propre clé privé pour déchiffrer.

L'intermédiaire des échanges de clés publiques est Apple dans le cadre les iMessages, grâce à nos identifiants d'AppleID. (Edit : Je crois... )

avatar initialsBB | 

C'est beaucoup plus clair quand c'est bien expliqué, merci :)
L'analogie avec la clé de la maison est très bien !

avatar thierry37 | 

Article intéressant. Je n'y connais pas grand chose.

J n'ai pas compris sous iOS, comment est échangée la clé AES entre mon iPhone et celui du copain a qui j'envoie un iMessage.
Car il faut bien que la clé unique parvienne de l'autre côté, pour qu'il lise mon message. Non ?

avatar bsr43 | 

pour iMessage, c’est un peu différent : de mémoire, une clé AES est générée aléatoirement pour chaque échange. Elle sert à chiffrer le message. Cette clé est elle-même chiffrée grâce à la clé publique de l’interlocuteur. Le message chiffré, et la clé chiffrée sont envoyés. De son côté, le destinataire déchiffre la clé grâce à se clé privée, puis déchiffre le message. Apple sert de point d’échange pour les clés publiques…

avatar lolo57 | 

Enfin tout ceci est rigolo, mais si vous avez quelque chose de très secret et que vous voulez absolument qu'il soit impossible de le déchiffrer sans la clef, il suffit de faire un xor sur une clé aussi longue que votre document à chiffrer, programmé en 3 minutes, indéchiffrable à jamais sans la clef.

avatar bugman | 

@lolo57 :
Oui mais utilisable qu'une seule fois. Puis c'est synchrone (il faut que ton correspondant ai le masque). Sinon, oui, c'est le moyen le plus sûr de chiffrer (avec de vraies valeurs aléatoires par contre).

avatar kubernan | 

Donc soit on autorise le chiffrement sans porte dérobée, soit on ne l'autorise pas du tout (en effet, quel est l'intérêt d'utiliser le chiffrement si on peut le "contourner" ?).

avatar Sostène Cambrut | 

@kuberman

Et comme il est certain que des terroristes ne vont jamais oser enfreindre la loi anti-chiffrement on est sauvé ^_^

avatar ZANTAR2054 | 

merci pour l'article S. Moussie

avatar pauul02 | 

Très intéressant cet article !

avatar XiliX | 

Merci pour l'interview... :ThumbUp:

avatar Moonwalker | 

Une interview très intéressante.

avatar Brice21 | 

Fumisterie. Si Apple voulait offrir une porte dérobée, il suffit de modifier iOS de sorte à ce qu'iOS envoie de manière sécurisée (encodé de manière totalement indéchiffrable) le mot de passe (ou PIN) des utilisateurs d'un appareil iOS et les stocke dans une Database spécifique sur les serveurs Apple lors de leur création ou modification. Même chose pour les mot de pass iCloud et le tour est joué. Sur MacOS, il est déjà possible de s'identifier avec son compte iCloud. Et lors de l'encodage d'un volume de stockage, Apple propose également d'utiliser votre compte iCloud pour le décrypter en cas de perte du mot de passe.

avatar Lem3ssie | 

Très intéressant comme article.

CONNEXION UTILISATEUR