All about donnes - Matoumba

Pourquoi le “prediction market” ne fait pas recette en France (voire ailleurs...)

- 21 hours and 9 minutes ago

Lorsqu’on vous parle d’entreprise 2.0 vous pensez blogs, wikis, réseaux sociaux etc…. Et si je vous parle de “prediction market” vous allez surement me regarder avec des yeux ébahis. Et pourtant dès que vous lisez un livre sur le sujet provenant de l’autre coté de l’Atlantique, dès que vous discutez avec des spécialistes locaux ils ne manquent pas d’inclure ce type d’outil dans le spectre des outils 2.0.

Pour savoir de quoi il s’agit je vous renvoie à la définition wikipedia pour commencer.

Il ne s’agit ni plus ni moins que de donner des jetons “virtuels” aux participants et leur demander de les “placer” sur des paris du genre “quel type de produit aura le plus de succès chez nos clients l’an prochain”, “quelle sera la part du budget IT des clients affecté aux réseaux sociaux etc…”. Cela peut se passer avec les salariés voire avec le grand public. Et visiblement c’est utilisé avec succès dans un certain nombre d’entreprises là bas.

L’expérience prouve que les résultats obtenus sont au moins aussi pertinents qu’avec des études plus longues et couteuses.

La question qu’on peut dès lors se poser est : pourquoi est-ce totalement méconnu chez nous ?

L’idée qui me vient spontanément à l’esprit est, une fois encore, que culturellement parlant cela ne passe pas.

D’abord la notion même de pari, un peu ludique, et connotée “jeu d’argent”, risque fort de mal passer dans des environnements où plaisir, fun et travail ne vont pas ensemble et où à partir du moment où quelque chose a l’air ludique ça ne peut être professionnelle sérieux.

En plus vous imaginer un collaborateur parier contre le succès d’un produit ? La capacité à délivrer un projet en temps et heures ? Coté pile ce sont effectivement les hommes de terrain qui sont souvent les mieux placés pour deviner à l’avance ce qui peut marcher ou pas. Coté face : cela revient à dire qu’on ne croit pas à ce que des gens hauts placé ont décidé et franchement cela n’est pas sérieux.

Vous me direz que pourtant le “crowdsourcing” intéresse nos entreprises. Oui. Mais discuter c’est bien, parier comme dans un casino ça l’est moins.

Et puis une discussion cela donne des ressentis. Le prediction market donne des chiffres et les chiffres c’est sérieux, on ne va pas laisser le quidam les impacter.

Vous voyez d’autres raisons ? Peut être même connaissez vous des entreprises Gauloises qui ont recours à ce type de pratiques et qui seraient passées sous mon radar. Peut être connaissez vous des pays hors US où cela fonctionne ?

Partagez cet article avec votre réseau:

Articles sur le même sujet

Add a comment

6,4,paris,2,rapports

Il donne 18 coups de couteau dimanche... puis est libéré lundi !

Tests / Metro 2033

Belgocontrol, temple de lÂ´incurie

Hippocampe donne naissance à des bébés

Kane Lynch 2: Trailer de gameplay

Marty : Créer un serveur OpenVPN

Planet Libre

- 1 days and 7 hours ago

Article publié le 23/09/2009

Depuis quelques mois, les solutions de VPN payant type Ipredator ont fleuri sur la toile. Ces solutions d'anonymat, séduisantes au premier abord, possèdent un gros point noir : qui se cache réellement derrière ces VPN ? N'y a-t-il pas un risque que ces « bienfaiteurs de l'Internet libre » ne revendent un jour toutes les données collectées ? Comme on n'est jamais mieux servi que par soi-même, nous allons voir comment monter son propre serveur VPN grâce à OpenVPN. Par ailleurs, ce VPN pourra aussi vous servir à passer les éventuelles restrictions mises en place sur votre lieu de travail, ou sécuriser votre connexion lorsque vous devez vous connecter sur des réseaux publics peu sécurisés.

Configuration du serveur

Avant toute chose, vous devez avoir accès à un serveur, si possible avec une bande passante suffisante. En effet, ce serveur va servir de relai entre vous et la cible distante : la bande passante en upload du serveur deviendra votre bande passante en download maximale. Dès lors, mieux vaut se tourner vers un service professionnel, offrant souvent une bande passante allant jusqu'à 100 Mb/s (environ 12 Mo/s). Cherchez donc du côté des VPS (Virtual Private server) : vous aurez toutes les possibilités d'un serveur dédié, mais à prix (et performances) réduit. Un serveur OpenVPN est très léger, donc 128 Mo de RAM devraient être suffisants. En France, Gandi, OVH ou LWS ont des offres intéressantes à moins de 15 â‚¬ par mois. Partagée entre 2 ou 3 personnes de confiance, cette solution est rapidement plus avantageuse qu'une solution type Ipredator. Attention tout de même car beaucoup de VPS promettent une bande passante de 100 Mbits/s, mais en pratique ce n'est pas le cas. La bande passante n'est pas partagée de manière équitable entre les différentes machines virtuelles, et résultat les performances laissent à désirer (j'ai déjà eu le cas avec du 100 Mbits/s qui en pratique approchait péniblement le 100 kbits/s...). Cherchez donc des solutions où la bande passante est moindre, mais assurée (comme Gandi le propose).

Avant de mettre en place votre VPN, pensez à sécuriser votre serveur. Une machine avec IP fixe accessible 24h/24 sera irrémédiablement la cible d'attaques.

Installation de OpenVPN et création des clés et certificats

Installez tout d'abord OpenVPN, bien souvent disponible dans les dépôts de base de votre distribution :

marty@server:# apt-get install openvpn

OpenVPN peut fonctionner avec plusieurs types d'authentification. Nous utiliserons l'authentification par clés et certificats, plus sûre que le classique login/mot de passe. Pour générer les clés et certificats nécessaires, des scripts ont été créés et se situent, sous Ubuntu 9.04, dans le dossier /usr/share/doc/openvpn/examples/easy-rsa/2.0. Commençons par copier tout ceci dans un répertoire de travail (tout le processus doit s'effectuer en tant que root) :

marty@server:# cd /etc/openvpn marty@server:# cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0 /etc/openvpn marty@server:# mv 2.0/ easy-rsa/ marty@server:# cd easy-rsa/

Modifiez tout d'abord les variables du fichiers vars :

export KEY_COUNTRY="US" export KEY_PROVINCE="CA" export KEY_CITY="SanFrancisco" export KEY_ORG="Fort-Funston" export KEY_EMAIL="me@myhost.mydomain"

Initialisez-le via la commande :

marty@server:# . ./vars

(vous devez bien écrire point/espace/point, ce n'est pas une erreur).

On efface les éventuelles clés présentes :

marty@server:# ./clean-all

On crée le certificat et la clé de l'Autorité de Certification (CA) :

marty@server:# ./build-ca

Les fichiers ca.crt et ca.key sont alors créés dans le dossier keys, et les variables précédentes devront être confirmées. Ces fichiers sont les fichiers centraux de la sécurité de votre serveur OpenVPN. La clé vous servira à signer les clés du (des) serveur(s) ainsi que des différents clients, et le certificat servira de « carte d'identité » à laquelle serveur(s) et clients se réfèreront.

On crée le certificat et la clé pour le serveur :

marty@server:# ./build-key-server server

Laissez toutes les options par défaut (y compris la demande de mot de passe), et répondez « yes » à la question de la signature :

Certificate is to be certified until Sep 5 14:02:19 2019 GMT (3650 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y

Le certificat du serveur sera alors signé avec la clé de l'Autorité de Certification. Les fichiers server.crt et server.key seront créés.

On crée le certificat et la clé pour le client :

marty@server:# ./build-key client1

De la même manière que pour le serveur, on laisse toutes les options par défaut et on accepte la signature par avec la clé de la CA. Les fichiers client1.crt et client1.key seront créés. Il est recommandé de créer une paire certificat/clé par client, de manière à pouvoir les révoquer par la suite si nécessaire (au cas où le client les perdrait).

Pour que notre serveur fonctionne, nous auront également besoin des paramètres de Diffie-Hellman :

marty@server:# ./build-dh

Le fichier dh1024.pem est créé. J'avoue, je n'ai pas compris à quoi cela servait précisément dans le cas de OpenVPN...

Finalement, nous augmentons encore la sécurité de notre serveur grâce à tls-auth :

marty@server:# openvpn --genkey --secret keys/ta.key

Le fichier ta.key est créé.

Résumé des fichiers créés

Au terme dela génération de ces diverses clés et certificats, nous obtenons les fichiers suivants :

ca.crt : certificat de l'Autorité de Certification
ca.key : clé de l'Autorité de Certification
server.crt : certificat du serveur
server.key : clé du serveur
client1.crt : certificat du client1
client1.key : clé du client1
dh1024.pem : paramètres de Diffie-Hellman
ta.key : clé utilisée pour tls-auth

En vert, les fichiers qui ne sont pas secrets, en rouge les fichiers secrets. Attention toute particulière au fichier ca.key qui sert à signer tous les certificats. Il permet d'autoriser ou non un client, et il est donc fondamental qu'il soit gardé secret !

En pratique, les fichiers nécessaires sont :

serveur : ca.crt, server.crt, server.key, dh1024.pem et ta.key
client1 : ca.crt, client1.crt, client1.key et ta.key

Notez bien que le fichier ca.key n'est nécessaire ni sur le serveur, ni chez aucun client ! Gardez-le en lieu sûr ;-)

Fichier de configuration serveur

Toute la configuration s'effectue dans un fichier quelconque, ci-après server.conf. Voilà un exemple typique :

#Configuration serveur mode server # c'est le fichier de configuration du serveur proto tcp # protocole TCP port 443 # port 443 (https) dev tun # mode routé #Clefs ca keys/ca.crt cert keys/server.crt key keys/server.key dh keys/dh1024.pem tls-auth keys/ta.key 0 # 0 pour le serveur cipher AES-256-CBC # algorithme de chiffrement #Configuration VPN #client-to-client # permet la connexion entre clients server 10.8.0.0 255.255.255.0 # adresse IP attribuées sur le VPN push "redirect-gateway def1 bypass-dhcp" # redirection du flux de données push "dhcp-option DNS 208.67.222.222" # utilisation de DNS alternatifs push "dhcp-option DNS 208.67.220.220" keepalive 10 120 # ping toutes les 10 secondes, # considéré comme down après 120 secondes sans réponses #Divers user nobody # on passe de l'utilisateur root à nobody group nogroup # nogroup est typique d'Ubuntu, groupe nobody pour les autres chroot /etc/openvpn/ovpn_jail # chroot de openvpn persist-key # n'accède plus à certaines options, persist-tun # car réduction des privilèges utilisateur comp-lzo # compression des données #Log verb 3 # verbosité du log (1-9, 4 recommandé) mute 20 # ne répète pas plus de 20 fois un message status openvpn-status.log # fichier de statut log-append /var/log/openvpn.log # fichier de log

Tout d'abord, le port utilisé (443) a été choisi parce qu'il n'est jamais bloqué (port https). Vous pouvez utiliser un autre port plus aléatoire si vous ne devez pas contourner de blocages quelconques.

Le mode routé (dev tun) est préféré au mode bridgé pour sa plus grande simplicité de configuration. Si vous avez une utilisation « basique » du VPN, ne vous préoccupez pas de ça.

De nombreux algorithmes de chiffrement sont disponibles. Nous choisissons ici le chiffrement AES 256 bits, qui est assez élevé. Si votre serveur rame, tentez de passer à du 128 bits.

client-to-client permet à deux clients de se connecter l'un à l'autre, par exemple via un serveur NFS. Dans notre cas, cette ligne est commentée.

server 10.8.0.0 255.255.255.0 définit le range d'adresses IP locales qui seront attribuées. Le serveur prendra l'adresse 10.8.0.1, et les clients 10.8.0.2, 10.8.0.3, 10.8.0.4... Attention : cette adresse ne doit rentrer en conflit avec aucune autre. Évitez donc d'utiliser les habituelles 192.168.x.x ou 10.108.x.x.

La ligne contenant « redirect-getaway » spécifie que tout le flux doit être redirigé vers le VPN. Attention à cette ligne qui peut différer d'une version à l'autre. Il semble que sous CentOS, il ne faille pas mettre les mots clés « def1 bypass-dhcp », alors que sous Ubuntu 9.04 cela est obligatoire.

Par la suite, la sécurité est améliorée en diminuant les privilèges du programme (« user nobody », « group nogroup ») et en effectuant un chroot (le dossier spécifié doit être créé). De cette manière, une éventuelle faille d'OpenVPN ne pourra être exploitée qu'en tant qu'utilisateur restreint, dans un environnement restreint.

Vous pouvez faire un premier test, en commentant la ligne « log-append » pour que le log s'affiche directement dans le terminal. Pour cela, on lance (en root, dans le dossier où se trouvent le fichier server.conf ainsi que le répertoire keys) :

marty@server:# openvpn server.conf OpenVPN 2.1_rc11 i486-pc-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] built on Mar 9 2009 Diffie-Hellman initialized with 1024 bit key /usr/bin/openssl-vulnkey -q -b 1024 -m Control Channel Authentication: using 'keys/ta.key' as a OpenVPN static key file Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication TLS-Auth MTU parms [ L:1560 D:168 EF:68 EB:0 ET:0 EL:0 ] ROUTE default_gateway=XXX.XXX.XXX.XXX TUN/TAP device tun0 opened TUN/TAP TX queue length set to 100 /sbin/ifconfig tun0 10.8.0.1 pointopoint 10.8.0.2 mtu 1500 /sbin/route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.8.0.2 Data Channel MTU parms [ L:1560 D:1450 EF:60 EB:135 ET:0 EL:0 AF:3/1 ] chroot to '/etc/openvpn/ovpn_jail' and cd to '/' succeeded GID set to nogroup UID set to nobody Listening for incoming TCP connection on [undef]:443 Socket Buffers: R=[87380->131072] S=[16384->131072] TCPv4_SERVER link local (bound): [undef]:443 TCPv4_SERVER link remote: [undef] MULTI: multi_init called, r=256 v=256 IFCONFIG POOL: base=10.8.0.4 size=62 MULTI: TCP INIT maxclients=1024 maxevents=1028 Initialization Sequence Complete

La première ligne en gras indique que l'interface tun0 a bien été créée (c'est le réseau virtuel), et les 3 autres que le chroot ainsi que le changement de propriétaire ont bien fonctionné. Dans un autre terminal, le ifconfig donne :

eth0 Link encap:Ethernet HWaddr 00:16:3e:51:5f:e9 inet addr:XXX.XXX.XXX.XXX Bcast:XXX.XXX.XXX.255 Mask:255.255.252.0 inet6 addr: fe80::216:3eff:fe51:5fe9/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:162377096 errors:0 dropped:0 overruns:0 frame:0 TX packets:153812357 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4278174076 (4.2 GB) TX bytes:2956197161 (2.9 GB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:127075 errors:0 dropped:0 overruns:0 frame:0 TX packets:127075 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:77312107 (77.3 MB) TX bytes:77312107 (77.3 MB) tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.8.0.1 P-t-P:10.8.0.2 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

L'adresse IP du serveur sur le réseau virtuel (tun0) est bien 10.8.0.1.

En l'état, votre serveur ne fonctionnera pas. Pourquoi ? Parce que le firewall n'a pas été configuré bien sûr ;-)

Configuration du firewall

Avant toute chose, on s'assure que le forwarding est activé en tapant dans un terminal (en root) :

marty@server:# echo 1 > /proc/sys/net/ipv4/ip_forward

Comme dans la section précédente, nous utiliserons Webmin pour configurer le firewall.

Dans la section Packet filtering, on ajoute les règles :

Incoming packets (INPUT) Accept If protocol is TCP and destination port is 443 Accept If input interface is tun0 Forwarded packets (FORWARD) Accept If input interface is tun0 Accept If output interface is tun0

Et dans la section Network address translation :

Packets after routing (POSTROUTING) Masquerade If source is 10.8.0.0/24 and output interface is eth0

Adaptez évidemment en fonction du protocole, port et adresse IP choisis.

Avec Iptables, cela donne :

iptables -A INPUT --dport 443 -p tcp iptables -A INPUT -i eth0 iptables -A FORWARD -i tun0 -j ACCEPT iptables -A FORWARD -o tun0 -j ACCEPT iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Ces règles sont peut-être un peu trop permissives, il est surement possible de les améliorer.

Configuration du client

Configurer un client est très simple, car cela repose sur la création dun fichier client.conf, à la manière du server.conf. Voilà le fichier client.conf associé au server.conf précédent :

#Configuration client client # mode client dev tun proto tcp-client remote XXX.XXX.XXX.XXX 443 #Remplacer XXX par l'adresse IP ou le nom d'hôte resolv-retry infinite nobind persist-key persist-tun #Clefs ca keys/ca.crt cert keys/client1.crt key keys/client1.key tls-auth keys/ta.key 1 #1 pour le client cipher AES-256-CBC #Ces 3 lignes sont inutiles si spécifié dans la configuration du serveur #redirect-gateway def1 bypass-dhcp #dhcp-option DNS 208.67.222.222 #dhcp-option DNS 208.67.220.220 comp-lzo verb 3

Il faut bien s'assurer que les options sont identiques entre client et serveur (compression, port, protocole, chiffrement...), car une seule erreur et ça ne fonctionnera pas. Après avoir fourni les clés fichiers nécessaires (voire section précédente) ainsi que le fichier client.conf au client concerné, installé OpenVPN sur la machine cliente, il suffit de lancer dans un terminal (après avoir préalablement lancé OpenVPN sur le serveur):

marty@client:# openvpn client.conf OpenVPN 2.1_rc7 i486-pc-linux-gnu [SSL] [LZO2] [EPOLL] built on May 8 2009 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info. /usr/bin/openssl-vulnkey -q -b 1024 -m Control Channel Authentication: using 'keys/ta.key' as a OpenVPN static key file Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication LZO compression initialized Control Channel MTU parms [ L:1560 D:168 EF:68 EB:0 ET:0 EL:0 ] Data Channel MTU parms [ L:1560 D:1450 EF:60 EB:135 ET:0 EL:0 AF:3/1 ] Local Options hash (VER=V4): '2f2c6498' Expected Remote Options hash (VER=V4): '9915e4a2' Attempting to establish TCP connection with XXX.XXX.XXX.XXX:443 [nonblock] TCP connection established with XXX.XXX.XXX.XXX:443 Socket Buffers: R=[87380->131072] S=[16384->131072] TCPv4_CLIENT link local: [undef] TCPv4_CLIENT link remote: XXX.XXX.XXX.XXX:443 TLS: Initial packet from XXX.XXX.XXX.XXX:443, sid=4421b77a 4dc14e71 VERIFY OK: depth=1, /C=US/ST=CA/L=SanFrancisco/O=Fort-Funston/CN=Fort-Funston_CA/emailAddress=me@myhost.mydomain VERIFY OK: depth=0, /C=US/ST=CA/L=SanFrancisco/O=Fort-Funston/CN=server/emailAddress=me@myhost.mydomain Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA [server] Peer Connection Initiated with XXX.XXX.XXX.XXX:443 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1) PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 208.67.222.222,dhcp-option DNS 208.67.220.220,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5' OPTIONS IMPORT: timers and/or timeouts modified OPTIONS IMPORT: --ifconfig/up options modified OPTIONS IMPORT: route options modified OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified TUN/TAP device tun0 opened TUN/TAP TX queue length set to 100 ifconfig tun0 10.8.0.6 pointopoint 10.8.0.5 mtu 1500 route add -net XXX.XXX.XXX.XXX netmask 255.255.255.255 gw 192.168.1.1 route add -net 0.0.0.0 netmask 128.0.0.0 gw 10.8.0.5 route add -net 128.0.0.0 netmask 128.0.0.0 gw 10.8.0.5 route add -net 10.8.0.1 netmask 255.255.255.255 gw 10.8.0.5 Initialization Sequence Complete

et ça devrait fonctionner ! Pour vérifier, on tente d'abord un ifconfig qui devrait renvoyer quelque chose de similaire à ce qui s'affiche sur le serveur, et vérifier son adresse IP sur http://checkip.dyndns.com. Vous devriez alors avoir l'adresse IP du serveur. Par ailleurs, vérifiez également que vos DNS ont été changés (allez sur le site http://www.opendns.com/, et si c'est le cas « You're using OpenDNS » devrait être indiqué). Si ce n'est pas le cas, changez-les manuellement dans le fichier /etc/resolv.conf ou via l'applet de configuration réseau.

Un peu d'automatisation...

Côté serveur, on peut lancer OpenVPN grâce à la commande :

marty@server:# nohup openvpn server.conf &

nohup permet de ne pas terminer la commande (en l'occurence, openvpn) lorsqu'on coupera la connexion SSH. Selon la distribution utilisée, il est possible qu'OpenVPN se lance automatiquement au démarrage.

Côté client, il vous faudra installer le paquet network-manager-openvpn pour pouvoir effectuer la configuration depuis l'applet réseau. Avec les versions récentes de ce dernier, il suffit de glisser-déposer le fichier client.conf dans l'onglet VPN pour que la configuration soit automatique. On activera/désactivera alors simplement la connexion via l'applet réseau.

Conclusion

En principe, tout devrait être fonctionnel. Si ce n'est pas le cas, n'hésitez à pas demander de l'aide au support de votre hébergeur, certains nécessitant une configuration supplémentaire pour fonctionner.

Vous pouvez également vérifier le trafic réseau grâce à Wireshark (à lancer en root). Allez dans Capture â†’ Options, puis cliquez sur Start. Dans la colonne Info, vous devriez voir la mention « Encrypted data » de nombreuses fois, et des transferts vers le port https (si vous avez choisi le port 443, évidemment). Si c'est le cas, c'est que ça fonctionne !

Billet original de Marty.Votez pour cet article sur le Planet Libre.

Add a comment

6,4,1,3,2

Marty : Anonymat et partage de fichiers

Planet Libre

- 1 days and 7 hours ago

Article publié le 07/07/2009

Il est temps à présent de s'attaquer à la partie la plus sensible du sujet : comment partager des données anonymement. Nous verrons ici qu'il est tout à fait possible d'être anonyme grâce à la décentralisation et au chiffrement des données. Les réseaux existants (Bittorrent, eDonkey2000, etc.) n'ayant pas été prévu dans cette optique, il nous faudra en utiliser de nouveaux. Le point fort de certains logiciels présentés est de combiner un réseau existant avec un réseau décentralisé, de sorte que les nouveaux réseaux mis en place ne pêchent pas par leur manque de choix.

Je vous rappelle qu'il est interdit d'utiliser ces logiciels à des fins illégales (piratage, contrefaçon ou toute autre activité étant considérée hors-la-loi par les lois en vigueur dans votre pays de résidence). Vous pouvez toutefois les utiliser pour toutes autres utilisations privées, ou pour télécharger des données libres.

Il faut être un minimum honnête avec les créateurs qu'on apprécie. Si vous aimez un disque, un film ou un jeux, achetez-le, allez aux concerts ou au cinéma. Internet permet un accès à une culture gigantesque, et la moindre des choses est d'encourager ceux qui vous font plaisir. Outre l'honnêteté, ayez à l'esprit que c'est vous seul qui êtes responsable si un artiste arrête de produire car il ne gagne plus assez.

Bittorrent : OneSwarm, un début prometteur

Mis en place en 2002, le protocole de peer-to-peer (P2P) Bittorrent a connu un succès fulgurant, notamment pour les raisons suivantes :

Vitesses de téléchargement nettement supérieures à celles atteintes par les autres réseaux P2P (quelques explications), notamment grâce à un système de « récompense » (plus on envoie vite, plus reçoit vite) assez agressif.
Nombre de fakes (fichier dont le contenu ne correspond pas au nom) réduit grâce à la centralisation des liens sur les trackers et l'impossibilité de renommer un fichier partagé.

De nombreuses distributions Linux ont alors pu être distribuées de cette façon. Le protocole étant ouvert, de nombreux logiciels clients sont apparus, les plus célèbre étant ÂµTorrent, Azureus (Vuze) ou Deluge. Une première avancée fut l'arrivée du chiffrement des données : impossible alors pour le FAI de détecter que les données transitant étaient de l'échange de fichier. Restait un problème majeur : la centralisation des adresses IP des utilisateurs sur les trackers. Il suffit de se connecter à ce tracker pour connaître toutes les personnes partageant ce fichier. Qui plus est, de nombreux sites (notamment les trackers privés) gardent des logs assez complets, permettant de déterminer qui a partagé quoi (voir par exemple l'affaire de SnowTiger).

Récemment, OpenBittorrent (ainsi que PublicBT ou encore Torrage), un tracker Bittorrent ouvert à tous, a été lancé. L'idée est tellement simple qu'on se demande pourquoi elle n'a pas été appliquée avant. Habituellement, lorsque vous recherchez un fichier, vous devez naviguer sur le site du tracker (The Pirate Bay, Demonoid, SnowTiger...), voire sur un méta-moteur (Btjunkie, Mininova...). L'inconvénient est que le serveur qui gère les connexions Bittorrent est lié au serveur de recherche de fichiers. Si le serveur de recherche de fichiers tombe sous le coup de la justice, il entraine celui qui gère les connexions et les torrents sont perdus. OpenBittorrent est un tracker public, et ne détient aucune information sur les fichiers dont il se fait le relai. Chacun peut, lorsqu'il crée son torrent, ajouter le tracker OpenBittorrent et utiliser sa bande passante pour les connexions. Juridiquement parlant, il est très difficile de condamner ce tracker car :

Il ne pourra matériellement pas garder des logs détaillés.
Il ne pourra effectuer aucune censure ou filtrage vu qu'il ne détiendra aucune information sur les fichiers qui lui sont ajoutés.
Il n'est lié d'aucune façon avec les personnes qui l'utilisent.

La partie la plus sensible vis-à-vis de la loi, c'est-à-dire l'indexation des fichiers, est donc dissociée de tout serveur gérant les connexions. Si un moteur de recherche de fichiers torrent doit fermer, cela n'aura aucun impact sur la santé du réseau car d'autres moteurs de recherches existent. En théorie, OpenBittorrent serait donc intouchable juridiquement... De plus, le service d'indexation des fichiers n'a aucune information sur les données que vous avez partagées. Un « miroir » de OpenBittorrent a été mis en place, il s'agit de PublicBT.

Plus fort que Openbittorrent, BitTorrent Hydra est un tracker ouvert qui utilise le réseau Tor pour faire transiter les requêtes. Grâce à l'anonymat fournit par Tor, il est impossible de savoir où se situe ce tracker. Attention, cela fournit un anonymat au tracker, pas aux utilisateurs.

Notons aussi l'existence de proxys spécialisés dans le trafic Bittorrent, comme superchargemytorrent. Moyennant quelques euros, le serveur servira de passerelle pour vos téléchargements, chiffrant par la même occasion l'entièreté du flux. Il suffit de configurer le proxy dans les paramètres de votre client Bittorrent.

Lancé récemment, OneSwarm est un logiciel libre basé sur Azureus. Entièrement compatible avec le réseau Bittorrent, il utilise également son propre réseau totalement chiffré et décentralisé. Un fichier téléchargé sur le réseau Bittorrent classique sera automatiquement mis en partage sur le réseau de OneSwarm, de sorte qu'il soit disponible sans passer par le tracker. A l'instar de I2P ou Freenet, chaque utilisateur joue également le rôle de passerelles entre les autres utilisateurs. Il est donc impossible de savoir d'où viennent réellement les données, où elles vont et ce qu'elles sont réellement (car chiffrées de bout-en-bout). L'intérêt majeur de OneSwarm est de pouvoir pratiquer le friend-to-friend (F2F) : on ne se connecte alors qu'à des personnes de confiance, ce qui rend l'utilisateur invisible sur le réseau hors de son cercle d'ami.

OneSwarm est encore un peu jeune et n'est pas exempt de bugs. Cependant, il est activement développé ce qui augure de très bonnes choses pour la suite

Installation et configuration

Note du 10 mars 2010 : depuis la rédaction de cet article, le logiciel a fortement évolué. Référez-vous au site officiel pour plus de détails.

OneSwarm est open-source et disponible pour Windows, Linux et Mac OS (Java est requis). Après installation (une simple décompression du fichier compressé sous Linux), lancez l'exécutable et vous verrez apparaître l'interface dans votre navigateur Web. A ce sujet, il semble que ça ne fonctionne pas trop avec Internet Explorer, à vérifier. En l'état, il n'est possible que d'utiliser le réseau Bittorrent classique. Vous pourrez ajouter des fichiers .torrent comme vous le faisiez avec d'autres logiciels.

Pour utiliser le réseau chiffré anonyme, il vous faudra ajouter des amis dans votre liste. Si vous n'avez pas d'amis, cliquez sur Add Friend et choisissez l'option « Subscribe to a friend feed from a community server ». Configurez comme sur la figure ci-dessous, et des amis vous seront ajoutés automatiquement. Cette liste sera régulièrement mise-à-jour, et vous pourrez à tout moment ajouter d'autres serveurs. Vous noterez que lors de l'ajout d'amis, l'option « Limited » est cochée par défaut. En fait, un ami ajouté avec cette option ne pourra pas voir votre liste de fichiers. C'est donc fondamental pour la sécurité d'enlever ce statut limité aux personnes de confiance uniquement.

OneSwarm - Ajout d'amis

OneSwarm - Configuration d'un community server

Vous pouvez également ajouter ajouter un ami manuellement, grâce à l'option « Add friends manually using public keys ». OneSwarm fonctionne sur le principe de chiffrement asymétrique. Vous échangez votre clé publique avec celle de votre ami, et le tour est joué.

OneSwarm - Ajout manuel d'amis

Il est tout de même conseillé d'avoir quelques amis pouvant accéder à vos données, de manière à ce que vos fichiers puissent également être partagés. OneSwarm gère également les groupes d'amis via « More actions â†’ Manage visibility ». Vous pourrez alors partager certains fichiers avec un groupe en particulier uniquement.

Après avoir ajouté des amis, il vous suffit de faire une recherche dans le champ dédié. Le choix est encore un peu maigre, mais les dernières nouveautés arrivent assez vite compte tenu de l'utilisation parallèle du réseau Bittorrent.

eMule : utilisation de I2P avec iMule

Apparu en 2000, le réseau eDonkey2000 (sur lequel se base eMule) est un réseau encore largement utilisé pour le partage de fichiers. Son succès est dû principalement au grand choix de fichiers disponibles. En effet, contrairement au réseau Bittorrent centré sur le partage d'un nombre limité de fichiers, le réseau eDonkey2000 permet :

Le partage d'une grande quantité de fichiers, avec un système poussé de gestion de file d'attente.
Une vitesse moindre. Si cela semble être un handicap, en pratique l'utilisateur laissera un fichier plus longtemps en partage.
Une décentralisation des données, car les utilisateurs n'ont pas besoin de se connecter à un tracker unique pour être mis en relation. Cependant, on trouve plus facilement des fakes, car il suffit de renommer un fichier.
Un outil de recherche intégré au logiciel

Le plus célèbre des logiciels supportant le protocole eDonkey2000, eMule, propose deux réseaux pouvant fonctionner de manière indépendante ou en parallèle. Tout d'abord le réseau eDonkey2000 classique, pour lequel des serveurs permettent de mettre en relation les utilisateurs et centraliser la liste des fichiers partagés par toutes les personnes connectées. Ensuite le réseau Kademlia, où les serveurs sont inutiles car les utilisateurs font également office de « mini-serveurs » pour mettre en relation les utilisateurs connus.

eMule étant un logiciel libre, de nombreux MOD sont apparus (versions d'eMule modifiées apportant certaines options). Parmi eux, aMule a été porté sous Linux, puis a servi d'inspiration pour iMule. iMule utilise un troisième réseau pour partager les fichiers : le réseau I2P. Tout comme pour Kademlia, les utilisateurs servent de relai pour mettre en relation les utilisateurs, mais ils servent également de relai pour faire transiter les données d'une personne à l'autre (comme OneSwarm). Cependant, il semble qu'il ne soit pas possible (pour le moment) d'utiliser iMule comme un client eMule classique, en parallèle de son utilisation sur le réseau I2P.

Je n'ai, à ce jour, pas encore testé iMule (il vous faut une distribution récente ou Windows, ce que je n'ai pas). Le site du créateur est assez lent, et il n'est pas rare qu'il soit injoignable. Parcourez le forum de I2P, vous y trouverez surement un sujet parlant de la dernière version en date et des liens pour la télécharger.

Direct Download, ou DDL (RapidShare, MegaUpload...) : toujours tranquille ?

Apparus récemment, les sites de partage de fichiers volumineux ont rapidement été détournés pour le partage illégal de fichiers. En effet, contre quelques euros par mois, ces sites proposent une vitesse de téléchargement inégalable en P2P, tout en assurant l'anonymat des utilisateurs. Cependant, il persiste plusieurs inconvénients :

Le prix de l'abonnement : même faible, il n'est pas nul. De plus, il faudra faire un choix parmi les nombreux sites existants, et les limitations sont excessives si on n'est pas abonné.
Trouver un fichier en particulier n'est pas toujours chose facile, car il existe de nombreuses « boards » (sites où sont centralisés les liens).
Sur plainte d'un éditeur, un fichier sera purement et simplement supprimé des serveurs, et il faudra attendre que quelqu'un veuille bien le remettre.
La centralisation des informations : pour trouver un fichier, on devra d'abord s'inscrire sur une board pour avoir accès à la liste des fichiers proposés (les IP sont très souvent enregistrées). Ensuite, payer l'abonnement au site de partage pour télécharger dans de bonnes conditions (utilisation d'une carte de crédit â†’ très facile de retrouver son propriétaire). Si pour l'instant, ces sites promettent de ne pas stocker les logs permettant de savoir qui a téléchargé quoi, qui sait ce qui se passera dans le futur.

Pour celui qui en a les moyens, RapidShare et ses équivalents sont très pratiques une fois que les boards intéressantes ont été trouvées. Malheureusement, ceci implique de laisser de nombreuses traces de son passage, et rien ne dit qu'à l'avenir les utilisateurs ne soient pas inquiétés. N'oublions pas qu'aucun de ces services n'est hébergé dans un pays laxiste en matière de piratage (RapidShare est basé en Allemagne, MegaUpload aux USA...), donc un minimum de collaboration des forces de police pourrait faire mal.

L'ancêtre : Usenet

Usenet est l'ancêtre de nos forums, et est apparu en 1979, soit bien avant le World Wide Web. Il est articulé autour du principe de « groupes de discussions » (ou newsgroups) : un groupe de discussion est un groupe rassemblant les articles d'un sujet précis, ces articles étant stockés sur des serveurs communicant ensemble. S'il est possible de déposer des articles sur ces serveurs, ils est également possible d'y déposer des fichiers. Moins populaire que les logiciels de P2P, cette méthode est toujours utilisée par quelques irréductibles qui apprécient les vitesses de téléchargement élevées et l'anonymat relatif.

Cependant, qui dit serveur centralisant les fichiers, dit service payant. Pour avoir accès à ces newsgroups, il faudra s'abonner chez un fournisseur proposant plusieurs offres dont le prix varie en fonction du volume de transfert alloué. Notons que certains FAI, comme Free, proposent un service de newsgroup inclus dans l'abonnement.

Installation et configuration

Après avoir pris un abonnement chez un fournisseur (par exemple Giganews), vous devrez choisir parmi les nombreux newsreader. Choisissez-en un qui gère facilement les fichiers, car ce n'est pas le cas de tous (rappelons qu'à la base, Usenet est fait pour l'échange d'articles, pas le téléchargement de fichiers). Parmi ceux qui reviennent souvent, GrabIt sous Windows et Pan sous Linux. La configuration du logiciel varie de l'un à l'autre, mais reste assez facile : vous aurez besoin de l'adresse du serveur du fournisseur, du port, de votre nom d'utilisateur et mot de passe. Ensuite, partez à la recherche des fichiers NZB (ce sont les fichiers rassemblant les informations qui permettent de télécharger les différentes parties du fichier désiré) sur les moteurs de recherches comme Binsearch, Newzleech ou MegaNZB. Une fois sauvé, ouvrez le NZB avec votre logiciel, et le tour est joué.

Un VPN pour cacher son IP

Déjà présenté dans un précédent article, l'utilisation d'un VPN vous permettra de masquer votre adresse IP, que ce soit lors de l'utilisation du P2P ou du direct download, tout en conservant une vitesse de téléchargement correcte. Outre le fait qu'il faille faire confiance aux propriétaires de ce VPN concernant les données et logs conservés, le paiement de ce service entrainera irrémédiablement des traces de votre passage.

Les réseaux alternatifs

En marge des réseaux de P2P les plus connus que sont Bittorrent et eDonkey2000, de nombreux réseaux parallèles ont vu le jour. Historiquement pionnier dans le domaine, GNUnet est un logiciel de P2P conçu pour résister à la censure : chiffrement bout-à-bout, décentralisation des données, utilisateurs servant de relais pour brouiller les pistes, friend-to-friend, etc. Toutes ces recettes ont été reprises dans OneSwarm, ou dans d'autres logiciels comme Ants P2P ou MUTE.

Malgré la grande qualité des idées fondamentales de ces projets, ces réseaux pêchent par le manque de choix, et par un développement nettement moins actif que OneSwarm. La dernière version de Ants P2P date de 2007, celle de MUTE de 2008, et aucun développement ne semble être prévu. Le développement de GNUnet est plus actif, mais mon dernier essai s'est soldé par un échec car le logicel ne semblait pas très stable.

Les solutions hybrides

Et si nous pouvions combiner les avantages du P2P (décentralisation, recherche aisée, choix) avec ceux du téléchargement direct (rapidité et anonymat) ? Séduisant n'est-ce pas ? C'est ce que proposent des proxys Bittorrent comme Furk, Torrent Relay ou même ImageShack (ce dernier nécessite une inscription pour voir apparaitre l'option). Le proxy se charge de télécharger le fichier à votre place, et quand cela est fait il ne vous reste plus qu'à le récupérer comme un téléchargement classique. Les connexions sont évidemment sécurisées, les taux de téléchargement très bons et vous évitez les éventuels filtrage par votre FAI. Notons que Furk garde sur ses serveurs les fichiers déjà téléchargés par d'autres utilisateurs, et vous y donne accès gratuitement (avec des restrictions sur la vitesse, cependant). Tout cela est bien évidemment payant, avec les risques que cela comporte.

Je ne suis cependant sceptique quant à la légalité de la chose... Si les sites habituels de DDL comme RapidShare peuvent avoir un fond de commerce tout à fait légal, ces sites ne sont là principalement que pour faciliter le téléchargement d'Å“uvre protégées. Ce n'est d'ailleurs pas pour rien qu'il sont situés au Canada ou aux Pays-Bas, pays plus laxistes en la matière. J'ai donc de gros doutes sur leur pérennité.

Conclusion : peer-to-peer ou direct download, que choisir ?

Impossible de donner une réponse précise, car comme nous l'avons vu chaque méthode a ses avantages et ses inconvénients. Tentons de faire un petit récapitulatif...

Les avantages du peer-to-peer :

Une décentralisation des données, rendant difficile l'élimination des fichiers mis en partage.
Une visibilité temporaire : dès qu'on ne partage plus le fichier, on disparait de la liste des utilisateurs (mais gare aux trackers privés Bittorrent gardant des logs détaillés). Cependant, il faut tempérer cette « visibilité » : si toutes les personnes téléchargeant un fichier peuvent connaitre votre adresse IP, il leur faudra intenter une action en justice pour mettre un nom dessus. Notons que grâce aux nouveaux réseaux, cette visibilité devient quasi nulle.
Une notion de partage et de communauté plus forte : l'utilisateur n'est pas un simple consommateur, il peut partager avec les autres membres ce qu'il apprécie.
Un service gratuit.

Les inconvénients du peer-to-peer :

L'introduction de fakes est plus ou moins aisée (très facile dans le cas d'eMule, plus difficile dans le cas de Bittorrent).
Une vitesse pas toujours au rendez-vous.
Les risques juridiques plus élevés : en mettant à disposition des autres utilisateurs du contenu non-libre de droit, des sanctions supplémentaires sont à craindre. On est largement hors du cadre de la « copie privée ». Notons que les condamnations ont toujours été faites sur base de la mise à disposition illégale de contenu.

Les avantages du direct download :

Une vitesse maximale.
Un anonymat relatif : seuls les responsables du site ou newsgroup sur lequel vous téléchargez savent ce que vous faites.
Très peu de fakes, car les liens sont référencés sur des boards où les participants n'ont aucun intérêt à donner de faux liens aux autres, sous peine d'être rapidement éjectés.
Les risques juridiques moindres car vous n'avez pas mis en partage vos données.

Les inconvénients du direct download :

Un service payant.
Des traces nombreuses, au risque qu'elles soient permanentes, rendant votre identification facile et la liste de vos actions aisément consultable.
Un contenu susceptible de disparaitre des serveurs en cas de plainte de l'ayant-droit.

Pour le moment, les solutions payantes semblent les plus sures d'un point de vue juridique : ne partageant rien vous-même, vous risquez moins que si vous mettez à disposition des données. Cependant, ces solutions sont aussi les plus jeunes, contrairement aux utilisateurs des réseaux P2P qui ont déjà subi plusieurs attaques des ayants-droits (voir par exemple le jugement de cette américaine). Rien ne dit que la facilité avec laquelle vos téléchargements peuvent être listés ne se retournera pas contre vous un jour ou l'autre...

Billet original de Marty.Votez pour cet article sur le Planet Libre.

Add a comment

explorers,emule,fakes,faires,futurs

Marty : Sécuriser ses échanges

Planet Libre

- 1 days and 7 hours ago

Article publié le 27/05/2009

Dans l'article précédent, nous avons vu comment il était possible de protéger ses données personnelles grâce à TrueCrypt. Nous allons à présent voir comment il est possible de protéger des données à échanger grâce à la cryptographie asymétrique. Un récent article de Â@om est très bien mais peut-être trop orienté Ubuntu. Je tenterai donc d'apporter quelques éléments nouveaux.

Pourquoi chiffrer ses communications ?

Avant d'aller plus loin, posons nous la question : pourquoi donc chiffrer un e-mail, vu que votre messagerie dispose d'un mot de passe et que vous n'avez rien à cacher ? Tout comme un courrier classique, un e-mail risque de voyager entre plusieurs intermédiaires (au minimum, les serveurs mails). L'inconvénient est qu'un e-mail classique peut être facilement lu :

Par le serveur mail lui-même. Au minimum, votre serveur mail dispose d'un anti-spam : le contenu sera donc analysé pour vérifier que certains mots-clés ne s'y trouvent pas. Google, entre autres, étend ce principe pour vous proposer de la publicité ciblée. Chaque mail reçu avec GMail est donc analysé pour tracer votre portrait.
Les éventuels mouchards du gouvernements français. Hé oui, il semble que la réalité dépasse la fiction...
Votre FAI, si la connexion à votre webmail n'est pas chiffrée.
Un petit malin qui se serait infiltré sur votre réseau... Même si c'est le moins probable, l'espionnage industriel n'est pas un mythe.

Contrairement à une lettre placée dans une enveloppe, le contenu d'un e-mail peut donc être relativement facilement accessible. Il ne faut pas non plus sombrer dans la paranoïa, car dans la vie courante de nombreuses traces sont également semées ça et là. Pensez donc aux diverses cartes de fidélité des grands magasins (Monsieur Auchan sait tout de vous, de vos habitudes alimentaires à votre marque de PQ triple épaisseur préférée), aux inscriptions diverses, abonnements... Sans compter que tous ces fichiers clients s'échangent. Inutile donc de vouloir chiffrer le moindre échange si, en parallèle, vous semez des traces à tout va. Certains sujets mériteraient, par contre, une attention plus particulière. Monsieur Google ou Microsoft vous inspire-t-il suffisamment confiance pour que vous lui racontiez vos problèmes sentimentaux, vos problèmes de santé ou la dernière crasse que votre patron vous a faite ? A vous d'utiliser ces services « gratuits » en connaissance de cause...

Un point n'a cependant pas été abordé, les erreurs humaines (que celui qui n'a jamais envoyé un e-mail par erreur me jette la première bière ;-) ). Dans le domaine industriel, cela pourrait être très problématique : envoyer un rapport confidentiel à un concurrent, fournir des résultats financiers à de mauvaises personnes, une blague de cul bien grasse à la vieille secrétaire acariâtre...

Il n'est donc pas nécessaire d'avoir quelque chose à se reprocher pour utiliser le chiffrement. De toutes façons, vous êtes légalement tenus de fournir votre clé de déchiffrement aux autorités, sinon vous risquez la peine maximale du délit dont on vous accuse.

Le principe de base de la cryptographie asymétrique

La cryptographie asymétrique se base sur l'utilisation d'une paire de clé, composée d'une clé publique et d'une clé privée. La clé publique est utilisée pour chiffrer des données, et la clé privée pour les déchiffrer ansi que pour les signer (de manière à en assurer la provenance). Ces deux clés étant mathématiquement liées, à chaque clé publique ne correspond qu'une seule clé privée. Cependant, déduire la clé privée à partir de la clé publique est excessivement long (plusieurs centaines voire milliers d'années), ce qui assure une très bonne sécurité.

Prenons un petit exemple : Bob désire envoyer des données secrètes à Alice et Jack, mais il veut pas qu'Alice ait accès aux informations envoyées à Jack, et inversement. En premier lieu, Bob, Alice et Jack génèrent chacun une paire de clé. Chacun s'échange ensuite ses clés publiques respectives. Pour envoyer un message à Alice, voilà ce qui va se passer :

Bob chiffre le message grâce à la clé publique d'Alice
Bob signe le message grâce à sa propre clé privée
Bob envoie le message à Alice
Alice vérifie la signature du message grâce à la clé publique de Bob, et s'assure qu'il en est bien l'auteur
Alice déchiffre le message grâce à sa clé privée

Supposons que Jack soit une enflure et qu'il parvienne à intercepter le message de Bob. Bien qu'il soit en possession de la clé publique d'Alice, il ne pourra rien en faire car déduire la clé privée d'Alice à partir de sa clé publique est très long. Bob et Alice peuvent donc communiquer sans risques.

Nous utiliserons GnuPG dans le texte qui suit, qui est une implémentation libre et open source d'OpenPGP. Notez que GnuPG utilise une méthode de chiffrement hybride. En fait, le chiffrement asymétrique s'applique à une clé symétrique qui est utilisée pour le chiffrement des données.

Gestion de clés sous Linux

Avant tout chose, il sera nécessaire d'installer Seahorse ainsi que gnupg grâce à votre gestionnaire de paquets.

Générer une paire de clés

Lancez tout d'abord Seahorse (il est possible qu'il se trouve sous l'appellation « Applications â†’ Accessoires â†’ Mots de passe et clés de chiffrement » sous Gnome). Pour générer une paire de clés, cliquez tout d'abord sur Clé â†’ Créer une nouvelle clé, et choisir « Clé PGP ». Entrer ensuite vos informations personnelles :

Entrer ses informations personnelles

A tout hasard, je décoche « N'expire jamais » et je choisis une clé de 4096 bits (sécurité maximale). Entrez ensuite votre passphrase, qui n'est rien d'autre qu'un long mot de passe. La paire de clé générée apparait dans votre liste de clés :

La clé est créée

L'identifiant de la clé permettra d'identifier votre clé lorsque vous la déposerez sur un serveur de clés (voir plus loin). Dans les propriétés de la clé (Clic droit â†’ Propriétés), vous pourrez changer la passphrase ainsi que la date d'expiration. Sous l'onglet détails, vous trouverez également l'empreinte unique de votre clé (chez moi : 5ED6 EE4A 8514 6203 A01E 688F 28CD 661C C961 9A0F). Cette empreinte vous permettra d'identifier univoquement votre clé. En effet, il est tout à fait possible de générer une clé avec des informations identiques (même utilisateur, adresse e-mail et commentaire).

Les détails d'une clé

Nous constatons que la clé que la clé est en fait composée de deux sous-clés. La clé DSA est utilisée pour signer le message (à l'origine, DSA était destiné uniquement à la signature) et ElGamal est utilisée pour le chiffrement.

Échanger sa clé publique

Maintenant que nous avons créé notre paire de clé, il va falloir échanger notre clé publique. Pour cela, deux solutions : copier-coller ou sauvegarder la clé publique, ou l'envoyer sur un serveur de clés.

Si on ne désire pas utiliser un serveur de clé, il suffit d'un clic droit sur une clé et de choisir :

Copier, pour la copier dans le presse papier.
Exporter la clé publique, pour créer un fichier contenant la clé.

Rien de plus simple que de la transmettre à son correspondant (e-mail, IM...).

L'utilisation d'un serveur de clé peut cependant être utile car une clé peut être sujette à modification. Il est possible de modifier la date d'expiration, de révoquer (annuler) la clé ou d'ajouter sa signature à une clé publique. En synchronisant son trousseau de clé avec le serveur, vos correspondant seront mis au courant des éventuelles modifications. Pour cela, il suffit de choisir « Synchroniser et publier des clés » lors du clic droit. Vous pouvez faire un tour du côté des serveurs de clé. Personnellement, je n'ai jamais eu de problème avec le serveur du MIT : hkp://pgp.mit.edu:11371.

Synchronisation d'une clé

Votre correspondant pourra chercher la clé grâce à la fonction de recherche, disponible en cliquant sur Distant â†’ Chercher des clés distantes. La recherche s'effectue sur le nom, l'adresse mail ou le commentaire. Un simple Clic droit â†’ Importer et la clé apparaitra dans l'onglet « Autres clés obtenues ».

Signer une clé publique

Signer une clé publique reçue n'est pas un acte anodin : ceci est censé assurer que vous êtes sûr de la provenance de la clé. Reprenons notre exemple avec Bob, Alice et Jack. Supposons qu'Alice et Jack ne se connaissent pas, et que Bob connaisse tout le monde.

Bob et Alice échangent leur clé, chacun s'assure qu'elle est correcte et la signe grâce à sa clé privée.
Bob et Jack échangent leur clé, chacun s'assure qu'elle est correcte et la signe grâce à sa clé privée.
Jack désire communiquer avec Alice, mais ne la connait pas. Si il récupère la clé d'Alice sur un serveur de clé, il constatera qu'elle a été signée par une personne de confiance, c'est-à-dire Bob. Il est donc sûr que cette clé est la bonne.

Pour signer une clé d'un correspondant (apparaissant dans l'onglet « Autres clés obtenues »), il suffit de faire un Clic droit â†’ Signer la clé et de choisir quelle clé privée sera utilisée pour la signer (ainsi que le niveau de confiance).

Application : chiffrer/signer ou déchiffrer un fichier quelconque

Haaa, enfin une petite application ! Chiffrer un fichier n'est pas possible depuis Seahorse, et en fonction de votre environnement de bureau, cela peut être différent. Pour Gnome, un simple clic droit sur le fichier vous donne accès aux options voulues (voir l'article de Â@om). C'est donc extrêmement simple. Si vous voulez une méthode universelle, faites donc un petit tour plus bas dans la section ocncernant la ligne de commande.

Gestion de clés sous Windows

GnuPG est disponible sous Windows. Après installation, deux interfaces de gestion des clés sont disponibles : WinPT et GPA. Le principe est identique à Seahorse, donc pas de captures d'écrans :-D

Pour générer une clé dans le cas de GPA, il faut tout d'abord, cliquer sur Edit â†’ Preferences et cocher « Show advanced mode ». Ensuite, il suffit de générer une clé en cliquant sur Keys â†’ New Key. Pour une raison que j'ignore, il n'est pas possible de générer une clé de taille supérieure à 2048 bits.

Dans le cas de WinPT, il vous obligera à créer une clé au premier démarrage, sans pouvoir spécifier d'options. Pour spécifier les options, il suffira de générer une autre clé à partir du menu Key â†’ New â†’ Expert.

Chiffrer un e-mail

Le très intéressant blog de Â@om propose une solution pour Evolution, client mail par défaut d'Ubuntu. Penchons-nous sur Thunderbird et FireGPG.

Thunderbird

Thunderbird n'intègre pas par défaut le chiffrement PGP, mais il est possible de lui ajouter cette fonctionnalité via Enigmail. Cette extension est sûrement disponible dans les dépôts de votre distribution Linux, mais également sur le site officel des modules de Thunderbird. Outre les fonctions basiques que sont le chiffrement, la signature et le déchiffrement d'un e-mail, Enigmail vous permet de gérer votre liste de contact de façon à ce que la bonne clé soit automatiquement sélectionnée en fonction du destinataire.

Après installation, le menu OpenPGP apparaitra dans la fenêtre principale de Thunderbird. Un rapide coup d'Å“il dans Gestion de clés et vous trouverez vos clés privées et publiques. En fait, ce gestionnaire vous permet de faire la majorité des opérations classiques (création, suppression, exportation, modification...).

Dans les paramètres des comptes (Édition â†’ Paramètres des comptes), il est possible de configurer l'utilisation par défaut d'Enigmail pour chaque compte e-mail : clé privée, options cochées par défaut...

Gestion des clés à partir d'Enigmail

Paramètres des comptes

Dans les préférences d'Enigmail (OpenPGP â†’ Préférences), cochez Mode expert dans l'onglet Général, et vous aurez accès à une gestion fine des clés via l'onglet Sélection clef. Si vous cliquez sur Mofifier les règles, vous pourrez définir manuellement des règles d'envoi en choisissant les destinataire et la clé à utiliser. Notez qu'Enigmail peut également utiliser les adresses e-mails spécifiées dans les identifiants des clés publiques. Par exemple, si l'adresse azerty@exemple.com est indiquée dans une des clés publiques, Enigmail utilisera automatiquement cette clé lorsqu'un e-mail sera envoyé à azerty@exemple.com.

Paramètres de sélection des clés

Création manuelle de règles

Pour envoyer un mail chiffré et signé, il suffit de cocher les cases adéquates lors de la rédaction. Si le destinataire n'apparait ni dans les règles manuelles, ni dans les clés publiques, il vous sera demandé de choisir une clef. Sinon, les règles définies auparavant seront appliquées.

Rédaction d'un e-mail

FireGPG

FireGPG est une extension intégrant le chiffrement et la signature de messages pour Firefox. Ceci se révèle très utile lors de l'utilisation de divers webmails. Il suffit alors de sélectionner le texte à chiffrer/signer ou déchiffrer, et de choisir l'action désirée dans le menu FireGPG apparaissant lors du clic droit. FireGPG s'intègre avec Gmail, et de manière générale repère les textes chiffrés dans une page web pour y ajouter un bouton de déchiffrement. En outre, un éditeur est disponible, ce qui peut être pratique si des brouillons sont enregistrés à intervalles réguliers (l'extension les désactive par défaut sur GMail).

Dans l'éditeur, tapez votre texte puis choisissez Chiffrer et signer. La clé publique de chiffrement puis la clé privée de signature vous seront demandées. Cette extension est très simple d'utilisation tout en restant très puissante. Elle permet également le chiffrement symétrique d'un message.

Chiffrer ses conversation IM

Tout comme les e-mails, les conversations utilisant les messageries instantanées (MSN, GTalk, AIM, ICQ, Jabber...) sont susceptibles d'être interceptées. Nous verrons ici comment il est possible d'utiliser les chiffrement PGP pour les chiffrer.

Pourquoi ne pas choisir MSN ?

Avant de vouloir chiffrer ses communications, il vaudrait mieux utiliser un logiciel et un protocole sûr, n'est-ce pas ?

Si vous êtes un adepte d'MSN, vous avez surement déjà rencontré une personne vous envoyant des messages automatiquement, signe qu'un virus avait infecté son logiciel. Vous avez peut-être également connu la censure de Microsoft, censée vous protéger des virus mais prouvant que vos messages sont scannés en permanence. Si ce n'est pas le cas, posez-vous tout de même la question de savoir si un protocole aussi fermé que celui d'MSN (donc faisant potentiellement transiter des informations supplémentaires inconnues) est bien approprié pour des discussions sécurisées. Si toutes les informations passent en plus par les serveurs de Microsoft (vive la centralisation :/ ), la réponse est non.

Nettement moins connu, le protocole Jabber est :

open-source, donc gage de transparence
libre, donc l'utilisation de programmes différents est facilitée (utilisé entre autre par Google Talk)
décentralisé, donc assez facile d'éparpiller les traces laissées sur le réseau. Il est même possible de monter son propre serveur Jabber chez soi.

De plus, certains logiciels permettent l'utilisation du chiffrement PGP, de manière totalement transparente une fois que les clés publiques ont été échangées. Il suffit de créer un compte sur un serveur quelconque, par exemple celui de l'APINC. Aucune information confidentielle ne vous sera demandée, juste un nom d'utilisateur et un mot de passe.

Gajim

Choix le plus judicieux pour le protocole Jabber quand on tourne sous Linux, Gajim intègre par défaut la possibilité de chiffrer ses conversations. Après installation (disponible par défaut dans la majorité des distributions Linux) et ajout de contacts, faire un clic droit sur le contact désiré et choisir Gérer le Contact â†’ Assigner une clé OpenPGP pour désigner la clé publique voulue. Le choix de la clé privée se fait dans Édition â†’ Comptes, onglet Informations personnelles.

Pour chiffrer une conversation, aller dans les options avancées (dernier bouton de la fenêtre de conversation), et cochez Activer le chiffrement GPG. Rien de très compliqué dans tout cela, donc pas de screenshots ;-)

Gajim permet également de chiffrer ses communications en se passant de GPG, via l'option « Activer le chiffrement de bout-en-bout ». Cette méthode est propre à Gagim, et ne fonctionne qu'entre 2 clients Gajim. De plus, on perd toute la notion de signature.

Sous Windows, Gajim ne supporte pas le chiffrement, il faut donc se tourner vers Psi.

Psi

Psi est le choix le plus judicieux pour les personnes utilisant Windows, car il permet d'utiliser le chiffrement GPG. Il est donc possible d'utiliser le chiffrement entre un client Gajim et un client Psi.

Pidgin

Pidgin est le client par défaut sous Ubuntu, et a l'avantage d'être multi-protocole. Le plugin pidgin-encryption est disponible dans les dépôts de la majorité des distributions, ou sur le site officiel. Après installation, se rendre dans Outils â†’ Plugins et cocher Pidgin-Encryption. Dans la fenêtre de conversation, un petit cadenas apparait en haut à droite pour chiffrer la conversation. L'avantage de l'utilisation de Pidgin est que la génération ainsi que l'échange de clés se fait de manière automatique. Cette automatisation n'est cependant pas idéale pour la sécurité des transmissions (les clés sont mises à jour automatiquement, pas de système de signature...).

Un petit mot sur S/MIME

S/MIME est une méthode de chiffrement différente de OpenPGP, fonctionnant sur base de certificats, utilisée pour les e-mails. Ces certificats doivent être obtenus auprès d'une autorité de certification, et sont souvent payants (StartSSL en fournit cependant gratuitement). Les inconvénients majeurs sont :

Les clients mails ne supportent pas toujours S/MIME.
L'accès d'un webmail à la clé privée peut poser des problèmes de sécurité.
S/MIME ne chiffre pas seulement le message, mais également les éventuels malwares.

En bref... Mieux vaut utiliser OpenPGP.

Annexe : Gestion de clés en ligne de commande (tous les OS)

La ligne de commande de GnuPG est en principe universelle, donc vous pourrez l'utiliser sur n'importe quel OS. Ce guide ne se veut pas exhaustif, mais donnera juste les exemples les plus utilisés. Pour plus d'informations, la documentation du site d'Ubuntu-fr est très bien faite. Et toujours, bien sûr, le manuel ainsi que la commande man !

Générer une paire de clés

La génération de la clé est extrêmement simple : il suffit d'utiliser la commande gpg --gen-key. Des questions identiques vous seront posées :

[wacken@desktop ~]$ gpg --gen-key gpg (GnuPG) 1.4.9; Copyright (C) 2008 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Sélectionnez le type de clé désiré: (1) DSA et Elgamal (par défaut) (2) DSA (signature seule) (5) RSA (signature seule) Votre choix ? 1 La paire de clés DSA fera 1024 bits. les clés ELG-E peuvent faire entre 1024 et 4096 bits de longueur. Quelle taille de clé désirez-vous ? (2048) 4096 La taille demandée est 4096 bits Spécifiez combien de temps cette clé devrait être valide. 0 = la clé n'expire pas = la clé expire dans n jours w = la clé expire dans n semaines m = la clé expire dans n mois y = la clé expire dans n années La clé est valide pour ? (0) 2y La clé expire le lun. 23 mai 2011 16:45:23 CEST Est-ce correct ? (o/N) o Vous avez besoin d'un nom d'utilisateur pour identifier votre clé; le programme le construit à partir du nom réel, d'un commentaire et d'une adresse e-mail de cette manière: « Heinrich Heine (Der Dichter) » Nom réel: Wacken2 Adresse e-mail: wacken@exemple.com Commentaire: Ceci est un autre exemple Vous avez sélectionné ce nom d'utilisateur: "Wacken2 (Ceci est un exemple) " Changer le (N)om, le (C)ommentaire, l'(E)-mail ou (O)K/(Q)uitter ? o Vous avez besoin d'une phrase de passe pour protéger votre clé secrète.

En gras, les questions qui vous seront posées. Il vous sera également demandé de taper au clavier pour augmenter le caractère aléatoire de clé. Pour voir la liste des clés, un simple gpg --list-key :

[wacken@desktop ~]$ gpg --list-key /home/wacken/.gnupg/pubring.gpg -------------------------------- pub 1024D/C9619A0F 2009-05-23 uid Wacken (Ceci est un exemple) sub 4096g/86261ABE 2009-05-23 pub 1024D/9B06A561 2009-05-23 [expire: 2011-05-23] uid Wacken2 (Ceci est un autre exemple) sub 4096g/44981553 2009-05-23 [expire: 2011-05-23]

Nos deux clés apparaissent comme on pouvait s'y attendre ;-)

Échanger sa clé publique

Pour exporter une clé publique de Wacken dans le fichier wacken_key.asc :

[wacken@desktop ~]$ gpg --armor --export Wacken > wacken_key.asc

Il est également possible d'utiliser le numéro de la clé, dans notre cas :

[wacken@desktop ~]$ gpg --armor --export C9619A0F > wacken_key.asc

(...)

Add a comment

4,1,3,2,faires