PROJET AUTOBLOG


Le Blog de Genma

source: Le Blog de Genma

⇐ retour index

Chiffrement d'une clef USB que l'on a tout le temps sur soi.

jeudi 1 janvier 1970 à 01:00

Le besoin

Je transporte sans cesse une clef USB sur moi avec des données personnelles. Mais que ce passerait-il si je la perds ? Il faut donc que cette clef soit chiffrée... Je parlerai pas plus du chiffrement dans cet article, un article dédié est en cours de rédaction.

Le cahier des charges

J'ai trois machines distinctes, qui constituent un environement hétérogène de systèmes d'exploitation, sur lesquelles je suis susceptible de brancher ma clef USB contenant des données "mobiles" :

- Windows XP Pro SP3, que l'on nommera WIN par la suite

- Mac OX 10.5 (Leopard), que l'on nommera LEO par la suite

- Ubuntu 8.04.1 LTS (Hardy Heron), que l'on nomera UBU par la suite

Les 3 machines sont suffisamment puissantes pour effectuer du chiffrement temps réel, ce sera la clef USB qui sera limitante. Les clefs USB actuelles ont des capacités et des vitesses de transfert différentes : plus cette vitesse sera élévé et moins la perte de performance du au cryptage se fera ressentir.

La solution peut être compliquée à mettre en place mais doit être simple d'utilisation pour un usage quotidien.

Elle doit être à base de logiciels libres.

La clef est le principal dénominateur commun entre WIN et UBU/LEO. UBU/LEO sont sur le même réseau, WIN est sur un autre réseau d'entreprise.

La clef peut être branchée dans des ordres différents. Ce qui veut dire que je peux brancher la clef sur LEO, la débrancher, la rebrancher un peu plus tard sur LEO. Puis le lendemain sur WIN, le soir sur UBU puis sur LEO... Cela doit être totalement transparent dans l'usage que je fais de ma clef.

Je veux bien apprendre trois mots de passe différents. Les machines (on ne peut pas parler de PC, même s'il y un MacIntel dans la liste) sont "sûres"/ de confiance. Elles sont à jour, je les vérifie régulièrement. Je peux donc avoir les données en clair sur le disque de ces machines, le temps de les exploiter. Je ne peux pas créer de partition cryptées dédiées sur ces machines, mais je peux formater la clef en partition cryptée.

La solution : Truecrypt

Quelques recherches m'ont amenées au logiciel Truecrypt qui répond à mes critères. "Truecrypt offre la possibilité de créer des volumes sous Linux, mais aussi d'ouvrir le même volume crypté sous différents OS".

J'ai donc téléchargé les 3 programmes dans la même version et les ai installé sur les 3 machines aux 3 OS différents et les premiers essais sont plutôt concluants. Mon cahier des charge est rempli, j'ai une clef USB cryptée qui se monte via un logiciel libre, simple d'utilisation. La création de partition chiffrée demande un peu d'analyse pour adapter le niveau de sécurité et de chiffrement au besoin réel de protection.

Autres champs d'explorations

Les tutoriaux que l'on peut trouver se base tous sur la version ligne de commande, mais une version graphique est désormais disponible pour les 3 OS et c'est celle que j'utilise. Elle permet de créer une partition cryptée sur la clef (ce que j'ai fait) et de monter/démonter automatiquement la clef, comme une clef USB normale, avec le chiffrement temps réel en plus. Seul un mot de passe est demandé pour monter la clef, "libérant" ainsi les données qu'elle contient. Il est également possible d'avoir deux partitions, une en claire contenant les exécutables permettant d'installer Truecrypt ou la version "portable" et une chiffrée contenant les données. C'est un complément idéal à des systèmes comme la Framakey, que l'on peut sécuriser avec TrueCrypt. Je recommande d'ailleurs la lecture de cette page, qui comporte des captures d'écrans et des explications en français sur l'utilisation de TrueCrypt. La plupart des tutoriaux (le principal étant celui du site Internet) étant en anglais, je recommande en priorité la lecture de cette page.

De mon côté, je complèterai cet article après quelques jours d'utilisation, par une critique et des captures d'écrans.

Quelques liens

Pour finir, quelques liens :

- Un Livre blanc :http://www.cle-usb-truecrypt.org/

- Le site officiel :http://www.truecrypt.org
- La page de téléchargement : http://www.truecrypt.org/downloads.php

Liste de points à vérifier sur un service web avant de l'utiliser

jeudi 1 janvier 1970 à 01:00

C'est du billet écrit par SwissTengu Dis tous tes secrets à Kevlar que j'ai extrait cette sorte de liste de points à vérifier pour valider un site Internet qui prétend nous offrir un service de chiffrement. Certains points sont valables pour tout type de site webs (dans le cadre de la protection des données personnelles). Pour chacun de ces points, je donne une petite explication.

Le site n'est pas en SSL

Le SSL, pour simplifier, c'est le cadenas/le https. Si l'on doit transmettre des informations personnelles (identifiant, mot de passe ou autre) au site, il faut que le site soit accessible en https. C'est un minimum.
Rq : ce site n'est pas en https car Free ne propose pas cette option pour les hébergements des pages personnelles.

Google Analytics

Le script de Google Analytics est bloqué par les extensions comme Ghostery car il permet au webmaster du site de récueillir un certain nombres d'informations statistiques, mais également à Google d'avoir ces mêmes informations. Et de comparer, pour une même adresse IP, quelles pages sont consultées, la durée de consultation, et tout un tas d'informations, pour tous les sites que vous consultez... Si Google Analytics est présent sur le site, le site ne respecte pas votre vie privée.

Google Fonts

Google Fonts est un service d'hébergement gratuit de polices d'écritures pour le Web. Comme pour Google Analytics, si un site utilise des polices stockées chez Google, à chaque fois qu'une de ces polices est utilisée par le navigateur, Google sait (une fois de plus) que vous consultez le site web, quand et à quelle moment...

Pour ce point, je vous invite à lire le billet Se passer des polices Google sans s'en passer.

Il n'y a pas de chiffrement Javascript côté client

Dans le cas d'une messagerie qui se veut chiffrée et donc sécurisée. Si il n'y a pas de chiffrement Javascript côté client (au niveau du navigateur), cela signifie que dans le cadre du chiffrement la clef privée est du côté du serveur. L'administrateur du serveur est donc à même de déchiffré le contenu, vu qu'il a la clef privée. Le service fourni n'est donc pas confidentiel, sécurisé comme il le prétend.

Cloudflare (+DNS géré par Cloudflare)

Sur la problématique de Cloudfare, je vous invite à lire ce que j'avais écrit ici Cloudfare, Akamai et notre vie privée. Le problème est que ces services sont gérés par très peu de sociétés. Plus il y a de sites qui les utilisent et plus il y a de chances que pour la consultation de sites divers et variés, on passe par le même service. Cela est tout à fait transparent pour l'utilisateur, mais pour ces sociétés, le recoupement d'informations leurs permets de savoir de façon très simple la la liste des sites que l'on consulte (Il leurs suffit pour cela d'analyser les logs). Et que font-ils ensuite de ces informations ? Qu'en est-il du respect de notre vie privée ?

La politique de confidentialité

Quand on voit que pour les sites qui exposent les conditions d'utilisation du service, avec des textes si long que personne ne le lit, avec des clauses qui sont limites (voir complètement) abusives (Voir à ce sujet le site Terms of services didn't read, la politique de confidentialité est très importante. Les clauses peuvent être amenés à changer.

Pas de détails sur les algos, la technique etc.

La sécurité par l'obscurité ? Est-ce que c'est du logiciel libre, le code est-il auditable, disponible où ? Là encore, toutes ces informations doivent clairement être indiquées pour que l'on puisse se poser la question d'accorder un minimum de confiance et envisager d'utiliser le service.

Pourquoi ce site n'affiche pas de message sur les cookies ?

jeudi 1 janvier 1970 à 01:00

Le message Ce site utilise des cookies...

Depuis le 25 mai 2014, l'Union européenne (UE) a tranché. Le « consentement explicite » de l'utilisateur devient obligatoire pour les sites européens et ceux-ci affichent donc un message du type "Ce site utilise les cookies blabla". Ce qui est très ennuyeux. Surtout si on utilise des extensions qui font une gestion automatisée des cookies comme SelfDestructing Cookie ou Cookie Monster

Pourquoi ce site n'affiche pas ce message ?

Il existe des plugins pour SPIP (qui est utilisé pour faire tourner ce blog) qui permet de gérer un affichage automatique de ce message. Ce plugin, c'est CookieBar & CookieChoices, qui je cite :Ces plugins affichent une barre d'avertissement sur l'usage des cookies. Par défaut, SPIP est respectueux de la vie privée de ses visiteurs et ne pose pas de cookies de traçage ou publicitaires. Ces plugins sont donc utiles uniquement si votre site utilise des scripts de statistiques intrusifs (comme google analytics, xiti, ...) ou des widgets sociaux (bouton google+, facebook, twitter, ...).
- Le plugin CookieBar
- Le plugin CookieChoices

Cela fait un moment que j'ai enlevé les différents scripts non respectueux de la vie privée sur le blog (cf Ménage dans les trackers de ce site. Pour être sûr pour tout ce qui concerne les cookies, j'ai créé un profil pour Firefox vide, sans aucune extension, et en consultant différente page du site. Et je n'ai aucun cookie de déposé lors d'un simple surf sur ce site. Une bonne chose, non ?

Comment vérifier l'intégrité d'un fichier que l'on télécharge ?

jeudi 1 janvier 1970 à 01:00

Principe

Quand on télécharge un fichier, par exemple une iso de distribution Linux, on veut être sûr que le fichier a été correctement téléchargé/est le bon. Pour cela, il existe des commandes (MD5, Sha1), des sortes de moulinette qui génère un code unique pour le fichier. On compare ce code unique du fichier que l'on a sur notre ordinateur avec le code qu'indique le site qui a mis à disposition le fichier.

Si le fichier est modifié, différent, corrompu, incomplet, le code est différent. Si le fichier est strictement identique, on aura le même code, on est sûr que le fichier est bon.

MD5, Sha1, sha256

sha1 et md5 sont pas des algorithmes de hashage dont les algorithmes de calcul sont différents.

md5sum monfichier > monfichier.md5

En ligne de commande, l'utilitaire md5sum permet de calculer les sommes de contrôle MD5, l'utilitaire sha1sum permet de calculer les sommes de contrôle SHA.

sha1sum monfichier > monfichier.sha1

Pour vérifier
md5sum -c monfichier.md5
sha1sum -c monfichier.sha1

md5sum/sha1sum cherchera à calculer les empreintes des fichiers listés dans monfichier.md5 ou monfichier.sha1 et les comparera aux valeurs stockées dans le fichier.

Idem pour sha256sum qui utilise sha255, évolution plus "sécurisée" de sha1...

Pour une interface graphique à md5sum/sha1sum , il y a Check-file-integrity par exemple.

Fichier .asc - gpg

Encore plus "sécurisé", on a la signature via gpg. Cela repose sur le même principe que la signature d'un mail, avec le système de clef publique/clef privée. Un exemple d'utilisation de gpg pour certifier/signer un fichier est celui du Tor Browser Bundle. Un développeur a signé avec sa clef (privée) le package et quand on télécharge le Tor Browser Bundle, on vérifie qu'il est bon en le validant via gpg.

Signer un fichier de signature

Si je veux faire pareil, sur mon PC, je dois avoir une clef GPG privée de créer. Je tape la commande
gpg -ab file.pdf
Signification des arguments :
- a Create ASCII armored output.
- b –detach-sign Make a detached signature.

En utilisant ma clef privée, le fichier (ici file.pdf) est utilisé pour générer un fichier .asc de signature.

Les deux fichiers sont mis à disposition.

Toute personne qui les récupère aura le fichier file.pdf et le fichier file.asc qui a été généré.

Vérifier l'intégralité via la signature

Pour cela, il est nécessaire d'avoir la clef publique correspondant à la signature pour la vérification (procédure de récupération non expliquée ici. Ma clef publique quand à elle est disponible ici).

Cela se fait avec la commande
gpg --verify file.asc file.pdf

Rq : le fichier de signature est un fichier texte et l'extension varie. Elle peut être .asc (pour la signature du Tor Browser Bundle), sig (c'est celle qu'utilise TrueCrypt), .gpg pour les ISO d'Ubuntu...

Conclusion

On trouve de nombreuses explications/tutoriaux sur md5/sha1 et gpg sur le Net'. Si j'ai fait ce billet, c'est plus sensibiliser à l'usage de gpg dans le cadre de la signature d'un fichier, afin de garantir son intégrité/sa validité.

- Comment vérifier l'intégrité du TorBrowser quand on le télécharge ?.
- Comment vérifier l'intégrité de Firefox quand on le télécharge ?.

Etude de la sécurité du Tor Browser Launcher

jeudi 1 janvier 1970 à 01:00

Ce texte est une traduction du texte Tor Browser Launcher Security Design, du projet torbrowser-launcher.

Ce texte me semblait important à partager pour apprendre et mieux comprendre des notions de sécurité en informatique. Je ne peux pas tout expliquer en détail mais j'ai essayé de mettre quelques Notes explicatives liée à la traduction pour essayer de vulgariser et d'expliquer (de ce que j'ai pu comprendre) un peu plus en détail.

Voir également mes articles Le TorBrowser Bundle est un bundle et Tor Browser dans lequel je parle du Tor Launcher.

Début de traduction

Ce document est améliorable. Pour le moment, c'est un copier-coller d'un message poster sur le bug tracker de debian.

La sécurité de TLS/x.509

Le torbrowser-launcher ne repose pas sur l'infrastructure du Certificate Authority (CA). Le seul TLS qu'il fait et de faire une requête HTTPS vers check.torproject.org et (si vous n'avez pas choisi un miroir) le site www.torproject.org. Quand il se connecte à ces noms de domaines, il utilise un certificat en dur. Ainsi plus aucune TLS PKI ne se fait/ne s'applique ensuite.

(Et je ai pris des mesures supplémentaires afin de s'assurer que le .pem inclus avec torbrowser-lanceur est valable. J'ai téléchargé le CERT de différentes connexions internet / FAI et les ai comparés, et quand j'en ai eu un que je pensais correcte, j'ai échangé avec les développeurs de Tor pour vérifier c'était le bon et non un corrompu/malicieux).

Downgrade attacks - Les attaques par régression

Les attaques par régression ne devraient pas être possibles, à moins qu'elles ne soient liées à des commit des développeurs de Tor eux-mêmes. Si un attaquant récupère une ancienne demande valide au serveur https://check.torproject.org/RecommendedTBBVersions, le résultat indiquerait que la version actuelle est plus ancienne que la version actuellement installée, et le torbrowser-launcher n'effectuerait pas l'installation de cette version. (Par installer, j'entends extraire le contenu du zip dans le dossier home de l'utilisateur).

Note explicative liée à la traduction : le but d'une attaque par régression est de faire retour à une version antérieure contenant des bugs/failles de sécurité. Là, l'idée est que l'on remplace la version déjà installée du tor-browser (qui est dézippé dans le dossier /home/login/torbrowser-launcher/ par une version plus ancienne)

Toutefois, il y a le scénario où l'utilisateur a défini un miroir tierce comme site de téléchargement au lieu du site par défaut. Le site miroir peut très bien fournir un zip et un fichier de signature qui ont les noms de la dernière version, mais qui correspondent en réalité à une version de fichier d'une version antérieure. Ce type d'attaque est limitée du fait que tous les miroirs utilisent l'HTTPS — et si aucun des certificats de miroir n'est "connu", dans ce cas, c'est sur l'infrastructure du Certificate Authority (CA) que cela reposera. C'est là un cas limite, et qui ne fonctionne que contre les utilisateurs qui utilisent un site miroir , et qui nécessitent accès aux clefs de signature du CA.

Note explicative liée à la traduction : sur la vérification et la signature voir mon article Comment vérifier l'intégrité du TorBrowser quand on le télécharge ?

Installation du Tor Browser au niveau du système (system-wide)

Vous ne pouvez pas installer le Tor-Browser au sein du système (et non pour un utilisateur uniquement). Le logiciel est fourni en tant que bundle par le Tor Project. Il y un certains nombres de lignes de codes qui préviennent du fait que le logiciel modifiera des fichiers en dehors de son propre répertoire dans lequel il se trouve. Chaque fichier a pour propriétaire (note de traduction au sens permission unix) l'utilisateur courant, et cela a été pensé pour que le logiciel puisse être lancé depuis une clef USB. Il y a longtemps, j'ai travaillé pour que le Tor-Browser bundle soit bundle indépendant et puisse être installé au niveau du système (note de traduction : et donc utilisable par tous les utilisateurs) et suit arrivé à la conclusion que ce n'était pas faisable si les développeurs de Tor ne délivrait pas une version "non bundle". Si vous pouviez installer le Tor-Browser au sein du système en lui-même, il n'y aurait pas de raison à l'existence du torbrowser-launcher — il y aurait un paquet Debian (note de traduction : qui serait donc géré en tant que tel, apportant les mises à jour du Tor-browser comme n'importe quel autre logiciel).

De quels clef secrète/accès les attaquants ont-ils besoins ?

Oui, les attaquants qui 1) ont accès aux clefs de confiances fournies avec le torbrowser-launcher et 2) ont la possibilité de modifier des fichiers sur https://www.torproject.org/ ou ont accès aux clefs TLS sont en mesure de faire exécuter du code de leur choix en tant que l'utilisateur courant quand ce dernier lance le Tor Browser. Cela est valable (ou pas) pour les développeurs Tor dont les clefs son inclues (Note de traduction : dans le Tor Browser).

Mais comme le dit Holger, c'est une fonctionnalité , pas un bug (this is a feature, not a bug)C'est là le but du torbrowser-launcher, afin que les utilisateurs puissent installer automatiquement les mises à jour du Tor-Browser Bundle qui sont signés par développeurs Tor.

Fin de traduction