Chiffrement : comment l'expliquer à votre famille ? Partie 3

De retour sur le chiffrement !

Bienvenue dans la dernière partie de notre dossier spécial consacré au chiffrement ! Après en avoir découvert les origines dans notre première partie et ses utilisations dans la deuxième partie, c’est le moment d’aller plus loin. Alors plongez dans les profondeurs du chiffrement, et devenez un véritable expert !

Le chiffrement partiel

Même si un message est chiffré, cela ne veut pas dire que la conversation soit bien protégée. C’est là qu’entre en scène le chiffrement de bout en bout (End-to-end ou E2E).
Cette technique vous permet de vous assurer que seules les entités qui communiquent possèdent des clés de chiffrement. Et non les parties intermédiaires. De plus, cela vous permet de vérifier que le message est chiffré avant son expédition, mais aussi après sa réception. Ainsi, vous évitez des attaques de type HDM. De plus, vous n’êtes pas surveillé par le service en lui-même ou par votre FAI.
Prenons un exemple, pour expliquer le chiffrement partiel : envoyer un email à une personne tierce. Ainsi, vous pouvez créer une connexion chiffrée (SSL/TLS) entre votre appareil et le serveur d’envoi de l’email. Néanmoins, jusqu’à sa réception, il peut voyager par d’autres serveurs. Et aucun moyen de savoir si ces derniers communiquent entre eux de façon chiffrée.
De plus, si on revient sur l’exemple de la lettre et de la carte postale (vue dans la Partie 1), c’est comme si vous estimiez que votre courrier est bien protégé car il est placé dans le sac du facteur.  Ce qui n’empêchera pas un de ses collègues de le lire, au centre de tri par exemple. Ainsi, vous avez bien besoin d’une enveloppe – de chiffrement !
Néanmoins, ce n’est pas suffisant. En effet, via le traitement de vos emails, on peut avoir accès à leur contenu. Par exemple, Gmail analyse le contenu de vos emails pour cibler la publicité qui s’y trouve. Et oui, les serveurs de Google peuvent analyser le contenu des emails qu’ils hébergent.
Cependant, certains services de messagerie vous assurent qu’ils n’ont pas accès aux contenus de vos messages. En effet, ils utilisent l’implémentation du chiffrement PGP, en natif. Ainsi, c’est le cas pour ProtonMail par exemple.

Les métadonnées

Les métadonnées peuvent poser quelques problèmes. En effet, une personne tierce peut également lire d’autres informations sur votre email que son contenu. Ainsi, il peut découvrir son sujet, son expéditeur, l’heure de son envoi etc. Et exploiter ces informations.
Ainsi, soyez particulièrement vigilants aux métadonnées. Même si GPG ou S/MIME ne dissimulent pas ces informations, il existe d’autres outils pour communiquer.

Hachage et sel

En plus du chiffrement et de la signature, vous avez une autre méthode pour vérifier l’authenticité d’un élément : son empreinte, ou hash.
Cette empreinte se calcule grâce à une fonction de hachage. Les plus connues sont SFV, MD5 et SHA-1/256/384/512. Et contrairement au chiffrement, le but est d’obtenir un résultat non réversible. C’est à dire, depuis une empreinte, de ne pas pouvoir retrouver le fichier de base.
Cette empreinte permet de vérifier la véracité d’une information ou d’un fichier. De plus, elle est unique; sinon c’est une collision. Les empreintes ont deux buts. Le premier, c’est de vérifier l’authenticité d’un fichier. Ainsi, il faut comparer l’empreinte donnée par l’hébergeur et celle calculée. En effet, c’est comme ça que vous vous assurerez que le fichier est complet. Et qu’il n’a pas été corrompu durant le téléchargement.
Ensuite, l’empreinte sert à stocker les mots de passe. Et oui : mettre tous les mots de passe dans la même base de données, c’est très risqué en cas de piratage ! Donc on ne stocke qu’une seule empreinte. Ce qui permet de vérifier si le mot de passe qui a été renseigné par l’utilisateur est valide lors de la connexion. Et pour ça, on utilise des fonctions spécifiques telles bcrypt, scrypt ou Argon2.
De plus, afin d’augmenter la sécurité, on peut ajouter le sel. C’est un élément aléatoire au calcul de l’empreinte, et qui est propre à l’utilisateur. Ainsi, lorsque deux utilisateurs possèdent le même mot de passe, ils n’obtiendront pour autant pas le même résultat. Donc, ça permet d’éviter des attaques par force brute, ou de type rainbow table.

Vous souhaitez en savoir plus ? Alors découvrez le RapidCRC Unicode !

Perfect Forward Secrecy

Le perfect forward secrecy, ou « confidentialité persistante », c’est le fait d’être sûr que si quelqu’un découvre une clé, elle ne pourra pas compromettre l’intégralité des échanges.
Et oui : si vous n’utilisez qu’une unique paire de clé, et sans la changer régulièrement, quelqu’un / quelque chose risque de la découvrir. Ou son algorithme de chiffrement risque de casser. Ainsi, dans ce cas-là, vos messages peuvent être déchiffrés.
Ainsi, les outils utilisant la confidentialité s’assurent de bien utiliser une nouvelle paire de clés pour chaque nouvelle session. Et sans utiliser une manière présumable pour en générer ! Ces services en question utilisent et intègrent déjà la même notion pour la messagerie. Comme cryptocat ou OTR de Pidgin.

Le chiffrement homomorphe

Ces dernières années, on assiste à l’avènement d’un nouveau genre de chiffrement, utilisé notamment pour les services de Cloud. C’est le chiffrement homomorphe.
Ainsi, le chiffrement homomorphe sert à réaliser des opérations sur le contenu. Même si celui-ci n’est pas déchiffré. Donc un tiers peut assurer sa gestion et son stockage. Et sans pouvoir le lire en clair !

Zero Knowledge Proof

Ce concept (« Preuve à divulgation nulle de connaissance« ) né dans les années 1980 propose une méthode pour vérifier l’authenticité d’une information. Et sans avoir besoin de donner de détails à propos de l’information elle-même.
Ainsi, c’est particulièrement utile pour vérifier la véracité d’un message, ou le signer. Il est par exemple utilisé dans les cartes à puce. De plus, le Zero Knowledge Proof est aussi utile pour réaliser anonymement des actions.

Partagez l'article

Partager sur facebook
Partager sur twitter
Partager sur linkedin
Partager sur email