Simon's World

Archives de la catégorie ‘Technique’

Driverless Infrared Receiver for your Apple Remote with Arduino.

Dimanche 19 février 2012

Since I’m an (Mac) OS X lover but also a broke student, my main workstation is a Hackintosh.
I’m mostly using this computer to listen music, and was quite disappointed about the fact it could not be used with my Apple Remote. So I ordered on eBay an IR Receiver from China, thus I had to wait about two or three weeks before it arrives in my mailbox.

Then, I saw my supernumerary Arduinos on my desk. Three Nano, one Mega. I also had an IR Receiver. So i came straight to the idea I could do it all by myself. So was born this project.

This page gave me the schematics and the library to convert Arduino into an HID device. After reading the HID documentation, I understood the usbkeyboard library won’t fit for this usage as the play/pause, next track, and volume functions were defined in the « Customer Device » HID specs page, while the library was configured as a keyboard device. It was a real pain in the ass to understand only with HID official documentation, but thanks, I found this page.

Using « HID Descriptor Tool » (and some hand tweaking…) I made my own HID descriptor, as follow :

PROGMEM char usbHidReportDescriptor[31] = { // USB report descriptor
0×05, 0×01,                    // USAGE_PAGE (Generic Desktop)
0×09, 0×06,                    // USAGE (Keyboard)
0xa1, 0×01,                    // COLLECTION (Application)
0×05, 0x0c,                    //   USAGE_PAGE (Consumer Devices)
0×09, 0xcd,                    //   play/pause
0×09, 0xe9,                    //   volume up
0×09, 0xea,                    //   volume down
0×09, 0xb5,                    //   next track
0×09, 0xb6,                     // previous track
0×09, 0xec,                      // mute
0×15, 0×00,                    //   LOGICAL_MINIMUM (0)
0×25, 0×01,                    //   LOGICAL_MAXIMUM (1)
0×95, 0×06,                    //   REPORT_COUNT (6)
0×75, 0×01,                    //   REPORT_SIZE (1)
0×81, 0×02,                    // INPUT (Data,Var,Abs)
0xc0

};

This goes to the usbKeyboard.h file, and you’ll have to correct the descriptor size constant in the usbconfig.h file of your library.
Just a few explications :

The first two lines describes the device as a keyboard, then there’s a collection of the device capabilities in the Consumer Device page, which defines controllers for multimedia devices.

Those lines are important :

    0×15, 0×00,                    //   LOGICAL_MINIMUM (0)
0×25, 0×01,                    //   LOGICAL_MAXIMUM (1)
0×95, 0×06,                    //   REPORT_COUNT (6)
0×75, 0×01,                    //   REPORT_SIZE (1)

It defines that each values will be defined on a single bit on a six bits buffer, in the order we defined before.
For instance, the buffer 0b00000001 will send a play/pause command, and 0b00000100 will send a volume down command.

I had modify a few lines in the usbkeyboard.h library file. The sendKeyStroke functions must be like that :

 

void sendKeyStroke(byte keyStroke, byte modifiers) {

while (!usbInterruptIsReady()) {
// Note: We wait until we can send keystroke
//       so we know the previous keystroke was
//       sent.
}

memset(reportBuffer, 0, sizeof(reportBuffer));

reportBuffer[0] = keyStroke;

usbSetInterrupt(reportBuffer, sizeof(reportBuffer));

while (!usbInterruptIsReady()) {
// Note: We wait until we can send keystroke
//       so we know the previous keystroke was
//       sent.
}

// This stops endlessly repeating keystrokes:
memset(reportBuffer, 0, sizeof(reportBuffer));
usbSetInterrupt(reportBuffer, sizeof(reportBuffer));

}

 

And then, from arduino, to send, by instance, a previous track command :

                  UsbKeyboard.sendKeyStroke(8);

If you did not follow, 8 in binary is 2^3, so it will send the third command (starting form 0), which is, according to my custom HID descriptor, previous track.

With this method, I can send any command to my computer. Since it’s considered as an HID device, no drivers are required!

But then, came the second problem… The IR library uses timer… and so does the AVR-USB libray!
I took a few hours to rewrite the IR library to use ATMega’s timer1, which was not used by the AVR-USB Libray.
But then, tests showed me that the ATMega, with its 16Mhz frequency, can not be constantly interrupted by those two libray.

That’s why my project uses in fact, not only one, but two Arduino nano! One to receive the IR command, the other one to receiver them using the digital pins, and them them to my Hackintosh… and it works flawlessly!

I was about to solder the circuit when I finally received the IR Receiver from China, which costed about 13$, when my circuit, with its two Arduinos and miscellaneous components costed between 35$ and 45$. So I decided to use the the made in China thingie to save up my Arduino nano. With Twisted Melon’s Mira software, my Apple Remote can also put my computer to sleep, switch applications, work with my self-made Last.FM client and so on…

But anyway, it was a cool project : I played with the HID standard, timers in ATMega, Zener diodes, infrared command…

If you’re even more interested in this project, here are the codes, you’ll be able to guess the circuit layout. When I stopped working on it, everything was functional, but there surely is some useless functions since it’s like I’m still working on it.

IR Receiver picture

 

Présentation de Qubes OS, l’OS client ultra sécurisé.

Mardi 6 septembre 2011

Qubes OS (à ne pas confondre avec qube OS) est un système d’exploitation orienté sécurité du poste de travail proposé par Invisible Things Labs. Il est basé sur Xen et Fedora. La virtualisation est utilisée massivement pour répondre à la problématique de sécurité : les applications tournent dans des machines virtuelles selon leur domaine d’application, tandis que même le stockage et le réseau fonctionnent dans des domaines distincts.

Par défaut, Qubes OS installe l’hyperviseur Xen, trois VM pour ses services et trois domaines pour les applications utilisateur.

Les VMs pour les services sont les suivantes :

  • Le domaine du stockage contient le nécessaire concernant la gestion de fichier : c’est lui qui contient les pilotes et la pile de gestion des media de stockage (disque dur, clef usb, CD/DVD…)
  • Le domaine réseau, très exposé sur l’extérieur, contient les pilotes, les piles des protocoles, etc.
  • Le domaine administratif héberge l’interface graphique «sécurisée» et le logiciel de gestion. Aucune installation supplémentaire ne doit y être installée.

Concernant les VM applicatives, elles sont toutes basés sur une image disque «maitresse» contenant un navigateur Internet (Firefox), un client mail (Thunderbird), des logiciels de bureautique (Traitement de texte, tableur, création de présentations…) ainsi que diverses applications moins utiles. Invisible Things Labs propose par défaut un domaine rouge, un domaine jaune et un domaine vert.
Le vert est destiné aux applications professionnelles : le navigateur Web pour l’intranet, et le surf professionnel, et le client email/bureautique pour les documents et échanges professionnels uniquement.
Le jaune est plutôt destiné pour les activités personnelles : «social networking», email personnel, documents divers, photos, etc.
Le rouge est destiné aux activités à risque comme le surf aléatoire, le téléchargement de films de vacances / de musique libre de droits, messagerie instantanée, jeux dans le navigateur, l’installation de logiciels de source peu sure, etc.

 

Bien sur, il est possible de créer plus de domaines, comme un pour le commerce en ligne, un pour la banque, réseau social seulement, etc…

Grace à la virtualisation, aucun débordement n’est possible entre les VM : si l’utilisateur ouvre un lien vérolé depuis sa messagerie instantanée, seule la VM rouge est vérolée : un potentiel pirate n’aura pas accès aux données professionnelles potentiellement critiques puisque celles-ci sont dans une autre VM. De même, si un attaquant découvre une faille dans les drivers de la carte WiFi et s’en sert pour attaquer la machine, celui-ci sera seulement cantonné à la VM réseau : il ne pourra pas se propager sur le reste du système , et n’aura d’ailleurs pas accès à plus d’informations que celles qui transitaient déjà sur le réseau.

Qubes OS implémente aussi le concept de DisposableVM : pour ouvrir un fichier peu sur (au hasard, par exemple un pdf reçu par email), il est possible de le lancer dans une VM jetable grâce à un menu disponible en faisant un clic secondaire. Une fois le document lu, la VM est supprimée. En fait, il s’agit d’une VM template de base mise en veille : son lancement est très rapide puisqu’il s’agit simplement de restaurer la mémoire RAM : il suffit de quelques secondes pour ouvrir le document sans risques !
On peut également modifier le document : les modifications seront remontées jusqu’a l’appVM où se situe vraiment le document. Petit point noir cependant, cela ne protège pas d’une faille potentielle dans le parsing des documents par le navigateur de fichier, celui-ci créant des miniatures.

 

Architecture de Qubes OS

L’hyperviseur est la clef de voute de la sécurité de Qubes OS puisque la sécurité est basée sur la séparation des différents domaines, il est donc absolument nécessaire de sélectionner soigneusement le logiciel de virtualisation pour assurer la robustesse et la sécurité de la solution.
ITL a choisit Xen plutôt que KVM pour diverses raisons : globalement, le fonctionnement de KVM est trop proche d’un Linux «normal» pour s’approprier la confiance des développeurs.
Par exemple, Xen permet de virtualiser dans de domaines séparés les drivers et même l’émulateur d’entrées-sorties, permettant ainsi d’éloigner un maximum l’hyperviseur des brèches potentielles. Ainsi, le code au contact du monde extérieur est réduit à son strict minimum. On peut en plus vider l’hyperviseur de fonctionnalités presque superflues, comme l’ACPI pour s’assurer d’encore plus de sécurité.

Le second point critique après l’hyperviseur est le dom0 puisqu’il héberge le daemon XenStore et l’interface graphique. L’interface n’a pas été placée dans un autre domaine car de toutes façons, si un attaquant arrive à prendre possession de l’interface graphique, il a accès aux VM. Dom0 est donc strictement cantonné au XenStore daemon et à l’interface graphique : il n’a pas accès à l’extérieur (pas de réseau) et ses interfaces avec les autres VM sont réduites au minimum vital. Dom0 stocke également les clefs de chiffrement des disques des autres domaines.
Enfin, dom0 et les autres VM sont protégées de failles hardware  grâce à la technologie Intel VTd. (rappelons qu’on peut «aspirer» la mémoire RAM d’un ordinateur simplement via le firewire par DMA)

Gestion du stockage

Afin d’éviter qu’une compromission de la VM contenant les drivers du stockage permette une fuite des données qu’elle gère, les disques virtuels sont chiffrés et les clefs conservées dans dom0. En fait, les disques des VM sont séparés en trois fichiers :

  • Chaque VM est installée depuis une image disque commune contenant l’arborescence par défaut. Vu que cette image ne contient pas de données critiques (ça n’est que l’arborescence contenant par exemple les exécutables) elle est simplement signé : une altération de ce disque de base bloquera les processus de boot des VM.
  • Si des changements doivent être faits postérieurement, ils sont sauvegardés dans une image disque séparée grâce à la fonctionnalité de Copy on Write, apparu dans la version 2.6 du noyau.
  • Les répertoires /home et /var sont dans une dernière image disque, pour chaque AppVM.

Les deux derniers disques sont bien chiffrés, avec la clef stockée sur dom0.
Le disque différence créé par COW sur le template de base est supprimé lors du reboot de l’appVM afin d’éviter de conserver de possibles altérations. En effet, le fait que les VM soient toutes basées sur la même arborescence de base permet de toutes les mettre à jour en même temps ; si l’utilisateur a besoin d’installer un logiciel en particulier ou d’une version particulière sur une VM seulement, ils doivent être installés dans /usr/local.
Le mot de passe demandé lors de l’installation sert à chiffrer la partition contenant les images disques pour éviter une attaque matérielle sur le domaine de stockage. En revanche, le domaine de stockage ayant accès direct au contrôleur de disque, celui-ci peut manipuler les images de l’hyperviseur et de dom0. C’est à ce moment là que la sécurité de l’OS se base sur la puce TPM, en particulier sur la fonction TXT (Trusted Execution Technology).
Lors du boot, la puce TPM fait une empreinte de dom0 et de l’hyperviseur, avant de les charger et de les exécuter. L’initialisation de dom0 nécessite l’obtention d’un secret auprès de la puce TPM : celle-ci ne le livrera uniquement si l’empreinte est correcte, permettant de déchiffrer la clef de chiffrement du reste du système de fichier. Ainsi, l’hyperviseur et dom0 ne peuvent être altérés sans bloquer le système si l’ordinateur est laissé sans surveillance dans un milieu hostile.
Finalement, la passphrase est demandée à l’utilisateur pour déchiffrer le fichier contenant les clefs nécessaires à la création du domaine de stockage.

À noter qu’à la rédaction de cet article, la version proposée (Beta 1) n’implémente pas encore les fonctionnalités de boot sécurisé via Intel TXT ou de stockage sandboxé, cela viendra dans les prochaines versions et sera sans aucun doute disponible dans la version finale.

Gestion du réseau

Jusqu’à maintenant, le service réseau des systèmes d’exploitation, dont les drivers et la pile, fonctionnent souvent dans l’espace noyau ou avec des privilèges très élevés : une exploitation via une pile buggée ou un driver dysfonctionnel peut donc avoir des conséquences désastreuses. Dans qubes OS, la pile réseau est éloignée hors de l’hyperviseur, ainsi que le code de l’hyperviseur concernant la gestion du réseau, évitant les attaques décrites précédemment. De plus, la technologie VT-d permet à la VM de gestion du réseau d’avoir un accès direct et exclusif au matériel. La surface d’attaque restante est une très hypothétique faille dans la pile tcp/ip de Linux.

Chaque VM est reliée au domaine réseau par des interfaces virtuelles : leurs paquets passent le domaine réseau et sont filtrées par le firewall avant de pouvoir resortir sur le monde réél. Les VM ne sont pas reliées entre elles pour éviter les interactions, voire les covert channels.


Naturellement, certaines VM peuvent ne pas avoir accès au réseau, par exemple celles contenant des fichiers très confidentiels.

Ensuite, des pare-feux individuels peuvent être appliqués à chaque VM : par exemple, la VM professionnelle ne devrait accéder qu’au serveur imaps de l’entreprise, et à l’intranet, de même pour la VM bancaire qui devrait pouvoir accéder qu’au site de la banque. En effet, les navigateurs et client web font parfois des connections à des serveurs sans nous mettre au courant : expliciter précisément les permissions permet une sécurité accrue.

Les développeurs ont préféré mettre le pare-feu dans les VM concernées pour plusieurs raisons. Premièrement, le but de ce pare-feu n’est pas de contenir un malware : si le malware a pu arriver jusque là, le niveau de protection supplémentaire ajouté par le firewall est dérisoire : ces pare-feux permettent surtout que les connections automatiques des applications, potentiellement pas écrites de manière sécurisée, puisse compromettre l’application. De plus, les placer ailleurs offre une surface d’attaque supplémentaire. Bien sur, l’utilisateur peut déplacer lui-même le firewall dans la VM de gestion du réseau, voire ajouter une VM spécialisée.

Dans l’installation par défaut, Qubes promose néanmoins un domaine destiné au firewalling, contrairement à ce qui est annoncée dans le document des spécifications (du coup, on est pas certain que cela reste dans la version finale). C’est une bonne surprise, puisque cela permet de gérer facilement les accès des VM, d’autant plus qu’il y a une petite interface graphique dédiée.

On peut d’ailleurs créer un domaine destinée à la connexion au VPN d’entreprise, ou d’accès au réseau tor. Un tel domaine prendrait la place du domaine réseau, dans le sens où tout les domaines seraient connectées sur lui, avant de réinjecter le trafic sur le domaine réseau. Ainsi, une compromission du domaine réseau, par exemple via une faille des drivers, ne permet pas d’écouter directement le trafic réseau critique (celui d’entreprise notamment).

 

Attaques potentielles

Xen est l’élément le plus critique de l’architecture de Qubes OS : si un bug est trouvé et exploité dans l’hyperviseur, toute la sécurité s’écroule. A l’heure qu’il est, un seul exploit a été conçu pour Xen, et il a été créé par les créateurs de Qubes OS, et touchait en plus qu’un module optionnel. La partie critique de Xen fait entre 200’000 et 50’000 lignes de code : les développeurs essayent de s’approcher de 50’000. Le démon XenStore dans dom0 constitue aussi une surface d’attaque puisqu’il s’agit de l’interface entre les VM et l’hyperviseur, ceci est également valable pour le démon de gestion de la GUI. Les codes gérants ces interfaces ont été conçus de manière scrupuleuse et de la manière la plus épurée possible. Des bugs dans le matériels pourraient également être incriminés, par exemple une escalade de privilèges entre les rings du processeur ou des fuites de caches. Ces bugs toucheraient de toute manière tout les autres systèmes.
Ces attaques nécessitent une seule étape, néanmoins d’autres attaques sont possibles si l’attaquant a déjà réussit à mettre la main sur, par exemple, le domaine de stockage.
En effet, celui-ci possède un accès direct au matériel via VT-d : une faille potentielle dans VT-d pourrait permettre au domaine d’utiliser la DMA (pour lire des données dans la mémoire. L’assaillant pourrait aussi reflasher le firmware des contrôleurs avec un firmware malicieux qui installerait une backdoor sur la MBR qui elle-même installerait une backdoor sur un matériel utilisé exclusivement par dom0 (comme la carte graphique ou la carte son) avant que la protection VT-d soit initialisée. Ces backdoors pourraient ensuite accéder à la mémoire de dom0 via DMA. Ce type d’attaque est très complexe à mettre en œuvre. D’autres composants matériels ou logiciels, tels la puce TPM ou la pile TCP/IP de Linux peuvent aussi ouvrir des brèches, mais ce sont souvent des composants dignes de confiance car critiques et donc bien audités.

Informatique quantique et cryptographie

Mercredi 13 juillet 2011

La sécurité de la cryptographie est basée sur l’hypothèse que l’attaquant ne possède pas de moyens de calcul suffisants pour trouver les clefs de chiffrement en un temps raisonnable : par exemple, RSA est basé sur l’espoir que l’attaquant n’aie pas les capacités techniques de trouver la clef de chiffrement. Or, les chercheurs travaillent actuellement à la réalisation de calculateurs quantiques. Ces ordinateurs, basés sur certaines propriétés insolites d’objets quantiques, proposent une puissance de calcul qui dépasse l’entendement pour certains types de calculs par rapport à nos ordinateurs classiques. Petit tour d’horizon du fonctionnement d’un calculateur quantique et de ses conséquences sur la cryptographie.

Petit traité de physique quantique

En raison de ses techniques de calcul différentes, un ordinateur quantique utilise certaines propriétés d’objets quantiques afin d’effectuer ses calculs. Il se base principalement sur deux concepts : intrication d’états et superposition d’états. Le phénomène de décohérence quantique est également à prendre en compte.

Principe de superposition d’états quantiques

Les lois de la physique classique que nous côtoyons tous les jours et qui imprègnent notre représentation du monde n’a plus emprise sur le monde quantique, qui est soumis à des règles échappant à notre bon sens. Un de ces phénomènes est la superposition quantique. Il stipule qu’un objet quantique peut se trouver dans plusieurs états en même temps et n’a nul pareil dans le cadre de la physique classique. À notre échelle, cela pourrait signifier qu’un dé lancé ne donne pas un seul nombre, mais les six en même temps dans un état superposé, ou qu’un objet puisse être à plusieurs endroits à la fois. Il est naturellement erroné d’utiliser des termes tels « en même temps » ou « à la fois », mais il s’agit du moyen le plus simple pour désigner un phénomène non imaginable par notre cerveau de primate habitué au monde newtonien dans lequel nous avons grandi. Par exemple, on apprend que l’atome d’hydrogène a un électron tournant autour d’un noyau sur une orbite particulière, alors qu’en réalité il tourne sur plusieurs orbites à la fois. Au moins deux tentatives d’explication divisent la communauté scientifique à propos du phénomène de superposition. Les plus importantes sont l’interprétation de Copenhague qui dit que seul l’état mesuré après la décohérence (cf plus bas) a un sens physique et que la superposition n’est que résultante de formules mathématiques, alors que selon la théorie d’Everett, chacun des états est présent dans un univers parallèle.

Intrication quantique.

L’intrication quantique est un phénomène concernant également les états quantiques d’objets. Elle spécifie que deux objets quantiques intriqués doivent être considérés comme un seul objet de manière inséparable. Cela a pour conséquence qu’une modification sur l’un des objets modifie également le second de manière instantanée et quelque soit la distance qui les sépare.

Décohérence quantique.

« C’est bien beau tout ça, mais pourquoi ne puis-je pas être aussi à la fois dans mon lit et en cours ? »
Le phénomène de décohérence constitue une frontière entre notre monde soumis aux règles de la physique classique et le monde quantique considéré comme contre intuitif. En effet, comment expliquer que nous autres humains (ou toute autre entité intelligente lisant le présent document), composés d’atomes aux propriétés quantiques, nous trouvons nous visiblement qu’a un endroit à la fois. La nécessité de répondre à cette question a été mise en évidence par le très connu paradoxe du chat du Shrödinger, objet macroscopique héritant son état mort/vivant d’une particule quantique dans un état de superposition quantique. Le paradoxe est posé de la manière suivante : un chat est enfermé dans une boite munie d’un dispositif tuant le chat si un atome se désintègre. L’atome a par exemple une chance sur deux de se désintégrer en une minute. Après une expérience d’une minute, l’atome est donc superposé dans les états désintégré et non désintégré, par conséquent le chat est également à la fois mort et vivant. Or, aucun chat zombie de la sorte n’a été vu, aussi bien au coin de notre rue que dans un laboratoire de physique expérimentale. La décohérence quantique constitue la tentative d’explication la plus communément admise par la communauté scientifique pour expliquer le phénomène. Selon cette théorie, les interactions de l’objet quantique avec le reste de son environnement permettent d’éliminer les superpositions incohérentes (d’où le nom de la théorie) avec le reste de l’environnement. En fait, ces superpositions restent en théorie réelles, mais deviennent totalement négligeables. Il faut retenir que la décohérence d’un objet quantique (le passage d’états quantiques superposés) est précipitée par les interactions avec le monde extérieur. Ainsi, le simple phénomène de mesure décohère l’objet quantique étudié de manière pratiquement instantanée.

Et l’ordinateur quantique dans tout ça ?

Nous y arrivons. Toutes les lois précitées servent dans la compréhension du fonctionnement de l’ordinateur quantique. Au lieu d’utiliser des bits faits de transistors comme l’ordinateur que vous avez sous les yeux, le calculateur quantique utilisera des objets quantiques.

Les qubits

Les quantum-bits sont des objets quantiques (atome, ion, etc.) qui peuvent stocker dans un état superposé des 1 et des 0. Cependant, la lecture de ce qubit donne soit 1, soit un 0 à cause du phénomène de décohérence cité ci-dessus. Ce phénomène interdit par exemple la lecture de calcul intermédiaire ou la copie du qubit (théorème de non-clonage).
L’ajout de qubit dans un processeur quantique augmente ainsi sa puissance manière exponentielle puisque chaque qubit ajouté double sa puissance de calcul. Ainsi, un hypothétique ordinateur de « seulement » 100 qubits permet de simuler un cerveau humain, tandis qu’avec 300 qubits on pourrait simuler la totalité de l’univers visible depuis le big bang !
Les calculs se faisant sur des états superposés, effectuer une unique fois le calcul sur les qubits équivaut à le faire sur toutes les autres combinaisons en même temps, alors qu’il faudrait effectuer un calcul sur chaque combinaison de bits avec un ordinateur classique.
Il en découle que l’ordinateur quantique est parfait pour résoudre des problèmes combinatoires (tel, justement, le cassage de mots de passe).

Mise en œuvre : quelques pistes

À cause du phénomène de décohérence et des difficultés de manipulation d’objets quantiques de taille picomètrique, la longue route vers la mise au point du calculateur quantique est jonchée d’écueils. Comme expliqué précédemment, la décohérence est précipitée par les interactions avec des objets décohérés, comme des microscopes à effet tunnel, des chats ou même des photons, véhiculant les ondes électromagnétiques. C’est pour cela qu’il est nécessaire de réduire la température du « processeur » quantique à des températures proches du zéro absolu afin d’éviter que la chaleur environnante décohère l’objet quantique sur lequel les calculs sont effectués.

Compte tenu de ces difficultés, les chercheurs travaillent actuellement sur plusieurs pistes:

Point quantique : Il s’agit par exemple d’un électron enfermé dans une cage d’atomes (expérimenté par Bell). Quand ce point est « éclairé » par un laser, il passe dans un état excité, puis si on le « re-éclaire » il retourne dans son état fondamental. On peut considérer ces deux états comme codant des 1 et des 0. Il s’agit finalement d’une fonction NOT. Si on envoie la moitié de l’énergie nécessaire pour faire basculer le système d’un état à un autre, alors il sera dans un état de superposition : il s’agit de cet état qui nous intéresse pour effectuer les calculs. On peut imaginer la création d’autres fonctions plus complexes en arrangeant différemment les points quantiques. Cependant, cette technologique se heurte à plusieurs difficultés : par exemple le point quantique reste excité pendant une milliseconde : réduisant ainsi le temps de cohésion disponible pour effectuer les calculs. De plus, les difficultés de création de ces points quantiques (il faut manipuler les atomes un par un, et utiliser un laser avec une grande précision, aussi bien pour la visée qu’au niveau de la quantité d’énergie employée) font que cette technologie n’est pas encore viable.

Nuclear magnetic resonance : Plutôt que de gérer les atomes un par un comme avec le point quantique, les chercheurs se sont essayés à utiliser une « mer de molécules ». Cette méthode s’appuie elle aussi sur les températures proches du zéro absolu, mais permet une décohésion plus tardive. C’est cette technique qui a été utilisée par IBM en 2001 pour factoriser le nombre 15 à l’aide d’un calculateur à 7 qubits. (cette expérimentation historique est une des plus importantes du domaine.) Les qubits sont les atomes d’une molécule organique où le spin des atomes (sorte de sens de rotation) est la caractéristique quantique codant les 1 et les 0. Les scientifiques ont utilisé des champs magnétiques en utilisant les caractéristiques supraconductrices des métaux à ces températures pour choisir les spins et pour les lire. Cette technique est intéressante même si de grandes réserves ont été apportées : augmenter le nombre de qubits reviendrait à faire des molécules avec plus d’atomes : mais la lecture via les signaux magnétiques liés aux spins des qubits devient de plus en plus difficile quand le nombre d’atomes augmente : pas de solutions sont envisagées au-delà d’une vingtaine de qubits. Il est intéressant de noter que cette technique utilise un grand nombre de molécules identiques pour faire les calculs. Le calcul quantique est par nature statistique : parfois la décohérence peut donner un résultat faux, obligeant les manipulateurs à faire un grand nombre de fois le calcul afin qu’un répartition gaussienne des résultats permette de donner la bonne solution. Naturellement, effectuer plusieurs fois le calcul sera plus rapide qu’un seul calcul sur les ordinateurs quantiques du fait du travail sur les états superposés. Ici, le calcul étant fait sur un grand nombre de molécules, la mesure éclipsera d’elle-même les quelques molécules ayant décohéré sur une erreur, minoritaires par rapport aux bons résultats.

La piste des semi-conducteurs : Il s’agit de la piste la plus prometteuse, mais aussi de la plus expérimentale. Il s’agit d’utiliser des matériaux semi-conducteurs pour stocker les qubits à grand renfort de nanotechnologies. Plusieurs technologies sont expérimentées : certains essayent de piéger des photons dans des cavités optiques ou des électrons dans des nanostructures semi-conductrices, ou en utilisant les spins des atomes des impuretés des semi-conducteurs. Certains scientifiques évoquent aussi la possibilité d’utiliser des flux électroniques ou électriques à travers des matériaux particuliers. La perpétuelle problématique de décohésion impliquant d’utiliser de très basses températures est un frein technologique majeur à la démocratisation de cette technologie, même si les progrès en nanotechnologie, chimie ou supraconductivité laissent planer l’espoir d’une technologie plus simple à mettre en œuvre.

Le problème de l’algorithmique

Si l’informatique quantique a l’air d’apporter une solution élégante au plafonnement de la loi de Moore, cette migration, pour utiliser toute la puissance de calcul promise, doit penser superposition des états. En effet, les algorithmes doivent être réécrits en prenant en compte les spécificités du calcul quantique. À l’heure actuelle, peu d’algorithmes ont été développés, faute d’appareil quantique susceptible de les faire fonctionner. Un des algorithmes fondateurs de la physique quantique est l’algorithme de Shor, qui permet de factoriser des nombres en un temps polynomial. C’est cet algorithme qui a été utilisé par IBM sur son calculateur quantique. Cet algorithme apporte toute la problématique de l’arrivée de l’informatique quantique : il peut en effet factoriser les très grands nombres utilisés par les cryptosystèmes à clef publique, comme RSA, en quelques minutes, alors qu’il faudrait plusieurs milliers à milliards d’années de calcul à un ordinateur tel que celui utilisé pour rédiger ce texte. Il est estimé qu’un ordinateur classique nécessite plusieurs millions de milliards de milliards d’années pour factoriser un nombre de 1000 chiffres, contre 20 minutes sur un ordinateur quantique. Cet algorithme contient une partie classique pouvant être effectuée sur un ordinateur classique, montrant que l’ordinateur quantique sera probablement un hybride avec des modules classiques et des modules quantiques.
Un autre algorithme intéressant est celui de Grover, qui était chercheur dans les laboratoires Bell, comme Shor. Cet algorithme permet de faire de la recherche dans une base de données non classée en un temps proportionnel à √n avec une mémoire proportionnelle à log(n) où n est le nombre d’entrées. Cet algorithme peut être utilisé dans une grande variété de problèmes décisionnels, tel la coloration de graphes ou la résolution de sudokus. Il a même été prouvé mathématiquement que cet algorithme était le plus efficace en recherche non structurée en utilisant le calcul quantique. Il est intéressant de noter que la partie quantique de l’algorithme va trouver instantanément la bonne réponse en faisant instantanément toutes les vérifications de correspondance (toutes les possibilités sont explorées dans des « mondes parallèles » selon certains), mais c’est l’extraction de la réponse du système quantique qui nécessite √n itérations. Là est un des grands problèmes des ordinateurs quantiques tels qu’on les imagine aujourd’hui : 99 % du temps de calcul est perdu sur les corrections d’erreurs et la gestion mémoire ou la convergence vers la solution, alors qu’un pour cent du temps sera effectivement passé à calculer. C’est un peu comme si vous engagiez un détective privé pour retrouver une personne sur terre. Ce détective aura juste besoin de prendre une personne au hasard dans la rue et de vérifier si c’est la bonne personne pour localiser instantanément l’être recherché. (Ou, comme s’il allait questionner une personne différente dans chaque univers parallèle et c’est le détective dans le bon univers qui revient vous donner la réponse) En revanche, celui-ci mettra du temps à bien vouloir vous répondre, mais beaucoup moins de temps que si vous aviez cherché de manière exhaustive. Les algorithmes de Shor et Grover sont les plus connus, mais il en existe d’autres, tel l’algorithme de Simon pour effectuer des tests sur boite noire.

Le calculateur quantique aujourd’hui.

La conception d’un tel système est à la croisée des deux sciences que sont l’informatique et la physique quantique. Les budgets alloués à la recherche sur le sujet ont très nettement augmenté depuis la révélation de l’algorithme de Shor en 1994, à cause de ses implications sur la cryptographie. En effet, le premier pays arrivant à maitriser la technologie aura une supériorité énorme dans le domaine de l’espionnage et du renseignement, au même titre que Colossus, créée pour casser Enigma et co-réalisé par Turing lors de la Seconde Guerre mondiale, qui a probablement aidé à une sortie de guerre en notre faveur. Certains adeptes de théorie du complot évoquent même l’idée que les services de renseignement américain sont déjà en possession d’une telle machine, dans le plus grand secret. De grands groupes d’informatique « classique », comme HP, NEC, Microsoft,Hitachi et bien sûr IBM ont déjà lancé plus ou moins discrètement des programmes de recherche sur le sujet, tout en maintenant un très lourd secret industriel sur le sujet. De plus, les États-Unis d’Amérique investissent cent quarante-neuf millions de dollars chaque année dans le sujet (contre douze millions pour l’Union européenne) Le Canada et l’Australie dépensent l’équivalent d’un dollar par habitant dans le domaine, soit plus de deux fois plus que les USA ou six fois plus que le Japon. L’université de Yale a montré en 2009 un solid state quantum processor fonctionnel de deux qubits, proche de ce qu’on peut espérer voir un jour arriver dans nos ordinateurs conventionnels.

Cependant, il semblerait que le marché propose déjà quelques puces utilisant certains concepts de physique quantique, en témoigne la présentation que Google a tenu en 2009. Durant cette démonstration, les chercheurs ont montré un algorithme permettant de trier des photos de voitures plus rapidement que n’importe quel calculateur existant dans leurs datacenter. Néanmoins, leur démonstration a été faite en utilisant des processeurs quantiques de la société canadienne D-Wave, sujette à de nombreuses controverses quant à leur technologie. Depuis 2008, cette entreprise annonce avoir mis au point un processeur quantique de 128bit, ce qui n’a jamais été vérifié. Il s’agirait plutôt d’accélérateurs de calculs utilisant la physique quantique, à mi-chemin entre un ordinateur classique et un ordinateur quantique, la société présentant son produit comme un « processeur quantique adiabatique ». Il serait curieux qu’une entreprise privée ait réussi à intriquer 128 qubits alors que le record actuel, datant de cette année, est de 14 qubits. L’entreprise ne donne depuis que très peu de nouvelles, si bien que l’on ne sait pas croire si elle a fait faillite ou si sa technologie est utilisée dans le plus grand secret par les services de renseignement…

Dans tous les cas, aucune loi de la physique ne s’oppose à la création d’un ordinateur quantique : le problème est uniquement d’ordre technologique. Toujours est-il que la recherche n’en est qu’à ses balbutiements, et de nombreuses pistes gagneront à être développées, mais on peut espérer que d’ici une ou deux générations, on comptera autant de physiciens que d’électroniciens chez les concepteurs d’ordinateur.

La cryptographie quantique

Alors que l’avènement des calculateurs quantiques promet un bouleversement des rapports de forces entre les attaquants et les défenseurs dans le domaine de la cryptographie, il serait élégant que la technologique quantique apporte également une solution. Par chance, c’est le cas.

Chiffre de Vernam

Cet algorithme de chiffrement symétrique a beau être d’une simplicité déconcertante, il n’en est pas moins un des rares qui soit théoriquement impossible à casser. En revanche, sa mise en pratique s’avère plus épineuse.
Il utilise un simple masque jetable à appliquer sur le message à chiffrer, une clef peut donc prendre toutes les formes possibles, de même qu’un message chiffré : la seule attaque possible serait une bruteforce qui essaierait toutes les clefs disponibles (soit 2^n clefs différentes ou n est le nombre de caractères du message).

Cependant, l’utilisation de ce masque jetable induit de sévères contraintes :

  • La clef doit faire la même taille que le message à chiffrer.
  • La clef doit être générée de manière totalement aléatoire.
  • La clef ne doit être utilisée qu’une unique fois.
  • La clef doit bien évidemment rester secrète.

C’est ici que la physique quantique intervient : celle-ci est capable de répondre à toutes ces problématiques d’un seul jet. L’utilisation du Chiffre de Vernam couplé à la cryptographie quantique garantit une « sécurité inconditionnelle ». À l’opposée de la sécurité calculatoire, où les algorithmes prennent en compte les (in)capacités de calcul de l’espion, la sécurité inconditionnelle espère simplement que l’attaquant veuille bien se soumettre aux lois de la physique de notre univers (et on l’imagine difficilement faire autrement). Le concept de sécurité inconditionnelle ainsi que la démonstration que le chiffre de Vernam offre une sécurité absolue ont par ailleurs été démontrés en 1949 par le mathématicien américain Claude Shannon, alors chercheur chez AT&T.

Distribution quantique des clefs

Protocole BB84
Ce protocole, développé par Bennet et Brassard en 1984, est le premier protocole décrit, et est par conséquent très documenté. Il utilise la polarisation des photons. À cause du comportement à la fois ondulatoire et corpusculaire de la lumière, et in extenso des photons, la propagation des photons peut être vue comme une onde : sa polarité peut être considérée comme le sens de propagation de l’onde électromagnétique dans l’espace. Elle peut par conséquent prendre des valeurs allant de 0° à 180°. La polarisation des photons est une propriété quantique au même titre que le spin des atomes : on peut donc également allègrement jouer avec, et les lois de la physique quantique s’y appliquent.
Un photon polarisé verticalement peut passer à travers un polarisateur vertical, et un photon horizontal peut passer à travers un polarisateur horizontal. En revanche, tous deux ont 50 % de chance de passer à travers un polarisateur orienté à 45° (ou 135°). Tout cela parait évident, et complètement conceptualisable par notre approche classique de notre environnement. Il convient donc d’ajouter que la probabilité de passage du photon à travers le filtre polarisant orienté en diagonale est indéterministe et imprévisible. Ensuite, on ne peut mesurer le sens de polarisation qu’en utilisant un filtre polarisant : si le photon passe, c’est qu’il était polarisé dans le même sens : on ne peut donc pas mesurer précisément la polarisation. Enfin, quand un photon passe (ou ne passe pas) à travers un filtre transverse, on ne peut pas retrouver le sens de polarisation original.
Cet algorithme se base aussi sur le théorème de non-clonage, qui interdit la copie d’états quantiques inconnus.

Pour expliquer plus en détail le fonctionnement de cet algorithme, nous retrouvons nos protagonistes chers aux scénarios cryptographiques les plus fous : Alice, Bob, et la fourbe Ève. Alice et Bob possèdent deux canaux de communication : un quantique pour s’échanger des photons (une fibre optique est tout à fait appropriée) et un canal plus conventionnel qui peut être espionné par Ève. Fixons pour cet exemple que des photons polarisés à 0° ou 45° codent des zéros, alors qu’a 90° ou 135° on code des 1. Alice envoie une clef bit à bit en utilisant des photons polarisés de manière aléatoire entre les deux possibilités idoines, et note la polarisation employée. Par exemple, pour envoyer un zéro, elle choisira aléatoirement un angle de 0° ou 45°. À l’arrivée, Bob positionne son filtre polarisant de manière aléatoire pour chaque bit photonique reçu. Quand le photon est passé à travers le filtre, il note un 1, sinon il note un zéro.
À présent, Alice et Bob doivent communiquer sur les filtres employés : cela peut se faire via une communication non sécurisée. Bob dit à Alice quel filtre il a utilisé, et Alice confirme ou infirme avoir utilisé le même filtre. Ils conservent alors les bits sur lesquels ils ont utilisé le même filtre, qui constitueront la clef, sans préciser s’il s’agit d’un 1 ou d’un 0. Vous êtes susceptibles de penser qu’il suffit à Ève de « sniffer » les photons échangés pour trouver la clef : si c’est le cas, je vous invite à relire les propriétés quantiques des photons citées précédemment. Il convient de rappeler que le seul instrument à sa disposition pour mesurer la polarité est le filtre polarisant qu’elle utilisera en position rectiligne ou diagonale. Elle devra ensuite réémettre un photon polarisé à Bob pour qu’il ne se doute de rien : mais a 50 % de chances de se tromper et d’employer le mauvais filtre (puisque deux polarisations différentes codent un même bit), et Bob pourra retrouver ces erreurs dans ces mesures. Normalement, sans aucune perturbation, l’échange de photons polarisés devrait se faire sans aucune erreur. Dans la réalité, il existe une petite marge d’erreur à cause du bruit : il faut donc choisir à partir de quel seuil les erreurs seront considérées comme provenant d’une tentative d’espionnage. Pour tester la sécurité de la clef, Alice et Bob échangent la valeur de quelques bits au hasard sur la clef. S’ils trouvent des erreurs, c’est qu’un tiers a essayé de les espionner. Il faut ensuite appliquer un code correcteur d’erreur, pour éliminer les erreurs. Si le nombre d’erreurs dépasse la valeur seuil, la clef est jetée, et le protocole d’échange de clefs est réitéré. Sinon, ils utilisent la clef créée par la concaténation des valeurs des bits sur lesquels ils ont utilisé le même filtre polarisant, en soustrayant les bits utilisés pour vérifier la confidentialité de l’échange de clef qu’ils pourront utiliser pour chiffrer leur missive en utilisant par exemple le chiffre de Vernam. Il est intéressant d’ajouter que même si ce chiffre offre une sécurité inconditionnelle, le débit de donnée sera limité au débit d’échange du masque. On peut donc se servir des technologies d’échange quantique des clefs pour des algorithmes plus rapides, comme l’AES, en changeant fréquemment les clefs.

Protocole E91
Ce protocole a été imaginé par Artur Ekert en 1991. Il utilise une paire de photons intriqués qui peuvent être créés par Alice ou Bob. Ces deux photons ont donc exactement les mêmes propriétés : leur mesure en utilisant des filtres polarisés doit donc donner le même résultat. Il est précisé précédemment qu’un photon polarisé de manière horizontale ou verticale traversant un filtre en diagonale donne aléatoirement 1 ou 0. Du fait de l’intrication quantique, les deux photons intriqués traversant chacun de leur côté le filtre oblique donneront le même résultat, résultat aussi imprévisible qu’aléatoire. Finalement, qu’importe le filtre choisi, les deux interlocuteurs trouveront le même résultat. Si Ève lit un des photons, puis qu’elle le réémet, elle sera soumise au même problème d’erreurs révélées lors de la phrase de réconciliation qu’avec le BB84, dont cet algorithme n’est qu’une variation reposant sur le paradoxe EPR.

Protocole S09
Ce protocole très récent n’est pas une variante du protocole BB84, et son fonctionnement est plus proche de la cryptographie asymétrique, ce qui permet ainsi la communication entre plus de deux pairs. Il utilise uniquement des canaux de communication quantique, contrairement à BB84 qui utilise aussi un canal conventionnel pour les phrases de réconciliation ou de transmission du message chiffré. En revanche, son implémentation est bien plus complexe en raison de l’échange fréquent de qubits.

Il existe encore une toute petite poignée d’autres algorithmes, très peu documentés, tels que KMB09 ou SARG04.

La cryptographique quantique, déjà une réalité

Contrairement à l’ordinateur quantique qui reste une arlésienne, la cryptographie quantique a déjà été mise en pratique, et plusieurs sociétés (majoritairement européennes) proposent même des produits commerciaux l’utilisant.

Le record de débit est le fruit de la coopération entre Toshiba et l’Université de Cambridge. Il est de 1 Mb/s sur 20 km, ou 10 kbit/s sur 100 km. Par ailleurs, le record de distance est de 150 km, suite à une coopération entre le Nationnal Institute of Standards and Technology (NIST) et le Laboratoire national de Los Alamos (qui est d’ailleurs le laboratoire responsable du projet Manhattan et a conçu les bombes d’Hiroshima et Nagasaki). Ces deux expérimentations utilisent le protocole BB84 à travers des fibres optiques.
En outre, une expérience européenne s’est affranchie de l’utilisation de fibre optique afin d’utiliser simplement l’air : l’utilisation du protocole E91 a ainsi permis en 2006 un échange entre deux iles de l’archipel des Canary, soit 144km. La même expérience a même été renouvelée en 2007 en utilisant une version améliorée de BB84.
La solution commerciale la plus en vogue est fournie par l’entreprise suisse id Quantique. Ses produits ont défrayé la chronique en 2007, quand ils ont été utilisés à Genève pour transmettre les résultats des élections nationales. Ils ont également été utilisés pour la première fois en 2004 pour une importante transaction financière requérant une sécurité absolue.
La DARPA (agence américaine sur la recherche militaire avancée) possède par ailleurs depuis 2004 un réseau de distribution quantique des clefs. Ce réseau possédant dix nœuds a été réalisé par un consortium réunissant des entreprises de défense et des Universités britanniques et américaines.
L’Union européenne a par ailleurs financé à hauteur de 11 millions d’eurosle réseau SECOQC, lancé en 2008 à Vienne, en réponse au programme d’espionnage Echelon.

Les courtes distances de transmission s’expliquent par des difficultés techniques plus qu’une limitation théorique. En effet, afin d’éviter le bruit, il faut que les fibres optiques soient les plus pures possible, avec le moins de courbures possible et avec le moins d’épissures (« soudures » de fibre) possible.

Les faiblesses des implémentations : la porte ouverte aux attaques

La première faiblesse est d’ordre statistique : un photon espionné par Ève aura 25 % de probabilité de donner une erreur chez Bob : il faut donc que Bob et Alice sacrifient le plus de bits de leur clef possible pour s’assurer de ne pas avoir été espionné. La fiabilité de la détection d’un indiscret est de 1-(3/4)^n où n est le nombre de bits. À partir d’un certain nombre de bits, Ève a plus de chance de gagner à Euromillion et de se faire percuter par une météorite en se faisant manger son troisième bras par un requin en haut du Chimborazo que de ne pas se faire détecter.
Bien sûr, on fixera que Ève n’a pas accès aux appareils de Bob et Alice. De plus, ces derniers devront aussi utiliser un générateur de nombre aléatoire totalement aléatoire (la physique quantique peut d’ailleurs répondre à cette problématique, cf les photons polarisés verticalement ou horizontalement passant à travers un filtre oblique donnant un 1 ou un 0 de manière indéterministe). Enfin, Alice et Bob doivent communiquer de manière authentifiée pour éviter que Ève se fasse passer pour l’un ou l’autre des protagonistes. La cryptographie quantique propose d’ailleurs une solution à ce problème : l’authentification Wegman-Carter.

Une autre faiblesse se base sur la difficulté technique pour l’émetteur d’envoyer les photons de manière unitaire : le produit commercialisé par id Quantic emploie en effet des émetteurs qui peuvent envoyer plus d’un photon à la fois : il suffit donc à Ève de séparer le flux de photon et d’en mesurer une partie, laissant le reste rejoindre le détecteur de Bob. Elle devra alors conserver les photons (c’est tout à fait possible en les faisant passer dans un milieu à une température proche du zéro absolu afin de les ralentir drastiquement) jusqu’a ce que le schéma de polarisation soit révélé sur la ligne non sécurisée. Cette attaque, photon number splitting attack existe à cause d’un décalage entre le fonctionnement théorique et l’implémentation pratique du protocole, qui demande une utilisation de photons à l’unité. Cependant, les recherches sur l’informatique photonique, basée sur la manipulation de photons à la place d’électrons, pourront apporter une solution en promettant de pouvoir toujours envoyer les photons un à un.

Une autre attaque permet de révéler le schéma de polarisation employé par Alice en envoyant un puissant flash lumineux sur l’émetteur. Une partie du flash sera réfléchie par l’appareil de mesure derrière le filtre polarisant : il suffit à Ève de regarder la polarisation de la lumière réfléchie pour déduire le filtre employé. Une solution proposée est d’utiliser un isolant optique pour éviter que la lumière entre dans l’émetteur.
D’autres attaques existent (faked state attack, remappage de phase ou décalage temporaire), mais celles-ci sont malheureusement peu documentées et exploitent des erreurs ou approximations d’implémentation des équipements.
Il pourrait être hypothétiquement possible pour Ève de mesurer la polarisation des photons par weak mesurement. Mais cette mesure induit un retard de réception des photons par Bob, donc si un jour le weak mesurement devient une réalité pratique, les protocoles de QKD devront vérifier les délais de transmission.

Toutes ces attaques se basent sur le fait que l’avancement technologique actuel ne permet pas de réaliser des appareils permettant d’implémenter de manière très stricte les protocoles de chiffrement : la sécurité de ceux-ci n’est donc pas à remettre en cause. Il faut donc espérer qu’avec le temps, la technologie évolue assez pour que les implémentations exploitent totalement les possibilités de la cryptographie quantique.

Les technologies émergentes de l’informatique quantique promettent de grand changement dans notre vision du monde informatique. En effet, ces nouvelles formes de traitement de l’informatique ouvrent des possibilités insoupçonnées. En outre, elle montre que la convergence des sciences et des technologies apportera un tel niveau de complexité que les futurs bidouilleurs devront toucher à plus de domaines que celui de l’informatique.

Bibliographie

http://fr.wikipedia.org/wiki/Impossibilit%C3%A9_du_clonage_quantique
http://fr.wikipedia.org/wiki/Masque_jetable
http://en.wikipedia.org/wiki/Quantum_key_distribution
http://www.perimeterinstitute.ca/personal/dgottesman/qsig.html
http://www.perimeterinstitute.ca/personal/dgottesman/qauthentication.html
http://wakaziva.pagesperso-orange.fr/crypto/6.htm
http://www.futura-sciences.com/fr/news/t/informatique/d/le-premier-reseau-informatique-geant-avec-cryptage-quantique_16997/
http://www.needocs.com/document/academique-cours-mathematiques-cryptographie-quantique-et-teleportation,6300
http://www.phys.ens.fr/spip.php?article340
http://arxiv.org/PS_cache/quant-ph/pdf/0411/0411004v4.pdf
http://www.secoqc.net
http://prl.aps.org/abstract/PRL/v94/i23/e230504
http://arxiv.org/PS_cache/arxiv/pdf/0908/0908.2146v3.pdf
http://arxiv.org/abs/0908.2146v3
http://www.bibmath.net/crypto/moderne/quantique.php3
http://www.bibmath.net/crypto/moderne/clesec.php3
http://www.astrosurf.com/luxorion/ordinateur-quantique.htm
http://www.cnrs.fr/sciencespourtous/abecedaire/pages/heisenberg.htm
http://alumni.imsa.edu/~matth/quant/
http://www.popsci.com/technology/article/2009-12/google-algorithm-uses-quantum-computing-sort-images-faster-ever
http://www.hobbyprojects.com/progression-of-computer-technology/ibm-led-team-unveils-most-advanced-quantum-pc.html
http://www.qubit.org/worldwide-groups.html
http://www-users.cs.york.ac.uk/~schmuel/
http://www.research.ibm.com/quantuminfo/
http://arxiv.org/abs/quant-ph/0012108
http://epiq.physique.usherbrooke.ca/?section=nouvelles&page=44
http://weblogs.asp.net/infinitiesloop/archive/2007/07/20/hacking-the-universe-quantum-mechanics.aspx
http://www.physique-quantique.wikibis.com/paradoxe_epr.php

Using TLC5940 Library with ethernet shield on Arduino

Samedi 9 juillet 2011

I’ve decided, for costs reason, to use an arduino nano instead of a mega for my final version of the project I’m working on. The arduino nano is based on ATMega328 chip which does not provide enough PWM output for the 3 RGB led I need. That’s why i decided to use a TLC5940, which provides 16PWM output for a cost of 3 PWM and 2 digital outputs on the Arduino board. Unfortunately, the library uses the SPI interface. TLC5940′s implementation of the SPI bus does not allow more devices on the bus than him and the master, and my project involves an internet chip, which uses the SPI interface too. I did’nt found on google any clear explainations on the subject, so i decided to go deeper.

The library provides a mode to avoid the use of the SPI : it is the bitbang mode. You have to edit the tlc_config.h in your tlc library folder and change the DATA_TRANSFER_MODE line :

#define DATA_TRANSFER_MODE    TLC_BITBANG

You then have to tell which pin to use : that’s the harder part. The library uses the pin at a very low lever : you have to specify pin, port and ddr of the pin you are aiming. I spent time on google to find which pin/port/ddr coresponds to which pin. I started reading the ATMega1280 datasheet, but in fact, it was obviously on the arduino mega schematic. For example, to use pin 48 and 49, change the tlc_config.h file to this :

/** SIN (TLC pin 26) */
#define SIN_PIN        PL0
#define SIN_PORT       PORTL
#define SIN_DDR        DDRL
/** SCLK (TLC pin 25) */
#define SCLK_PIN       PL1
#define SCLK_PORT      PORTL
#define SCLK_DDR       DDRL

The ddr, port and pin are defined in the schematic : but here is a list to avoid the pain of reading the schematic. It’s for the arduino mega, you’ll have to get the value for others Arduinos on thair respective schematics.

  • 53 : PB0 (which corresponds to PIN = PB0, PORT = PORTL, DDR = DDRL)
  • 52 : PB1
  • 51 : PB2
  • 50 : PB3
  • 49 : PL0
  • 48 : PL1
  • 47 : PL2
  • 46 : PL3
  • 45 : PL4
  • 44 : PL5
  • 43 : PL6
  • 42 : PL7
  • 41 : PG0
  • 40 : PG1
  • 39 : PG2
  • 38 : PD7
  • 37 : PC0
  • 36 : PC1
  • 35 : PC2
  • 34 : PC3
  • 33 : PC4
  • 32 : PC5
  • 31 : PC6
  • 30 : PC7
  • 29 : PA7
  • 28 : PA6
  • 27 : PA5
  • 26 : PA4
  • 25 : PA3
  • 24 : PA2
  • 23 : PA1
  • 22 : PA0

 


Putting ENC28J60 ethernet controler in sleep mode on Arduino.

Dimanche 3 juillet 2011

During my fabulous trip in the fantastic word of Arduinos, i had to gather some data from the Internet. As a lucky owner of an Arduino Mega Board (Or some kind of chinese counterfeit), i was quite disappointed when i finally discovered that there were no official Ethernet shield designed especially for the ATmega1280 based boards. In fact, SPI pin on the Arduino Mega are not physically located like on the Diecimila/Duemilanove boards. Someone hacked the official shield to work on the Mega, but, la flemme.

 

The beast

Anyway, after a quick search on eBay, I finally found a very cheap ethernet shield compatible with the mega board. This Shield is based on a ENC28J60 chip, contrary to the official board. A side effect is that the official library does not work. After doing some googling, I’ve found this absolutely perfect library. For example, it fully supports DNS, DHCP while the official does not. The library does not work de facto on my ekitzone Ethernet shield. I spent a few hours figuring out why the fuck it was malfunctioning on my board. Finally, I noticed a comment from Telek explaining what to change in the libraries. If I noticed it before, I would have gained a lot of time. From now, you should be glad of knowing it :P

Nevermind, that’s not what this article is about.

Briefly, my project involves controlling a few RGB leds from the Internet. The Arduino board have get some input data every 3 minuts on the internets. That mean the Ethernet shield is unused about 2min and 58second per cycle. During these nearly 3 minuts, the traffic and state leds keep blinking furiously each time le board recieves anything : even when it’s broadcasted paquets. The perpetual-furiously-yellow-blinking-led reassures at the beginning (wow, it WORKS) but becomes very annoying when dealing with RGB led smoothly and gently fading.
The other point is that the ENC28J60 chip drains power and warms up. After quickly reading the ENC28J60 data-sheet, I learned the chip had a low power consumption mode. Thanks to google, i sorely found this post explaining how to manipulate registers to put the chip in deep sleep. I could not find on the Internet a function doing that, so i finally written it. (yeah, sometimes i write functions, amazing uh ?). I thought i may actually interest someone, i decided to publish it. Here it comes. You have to add the following lines in your enc28j60.c file in your ethershield library :

void enc28j60PowerDown() {
 enc28j60WriteOp(ENC28J60_BIT_FIELD_CLR, ECON1, ECON1_RXEN);
 while(enc28j60Read(ESTAT) & ESTAT_RXBUSY);
 while(enc28j60Read(ECON1) & ECON1_TXRTS);
 enc28j60WriteOp(ENC28J60_BIT_FIELD_SET, ECON2, ECON2_VRPS);
 enc28j60WriteOp(ENC28J60_BIT_FIELD_SET, ECON2, ECON2_PWRSV);
}

void enc28j60PowerUp() {
 enc28j60WriteOp(ENC28J60_BIT_FIELD_CLR, ECON2, ECON2_PWRSV);
 while(!enc28j60Read(ESTAT) & ESTAT_CLKRDY);
 enc28j60WriteOp(ENC28J60_BIT_FIELD_SET, ECON1, ECON1_RXEN);
 }

And then,

extern void enc28j60PowerDown();
extern void enc28j60PowerUp();

In enc28j60.h

Finally :

void EtherShield::ES_enc28j60PowerUp(){
 enc28j60PowerUp();
}

void EtherShield::ES_enc28j60PowerDown(){
 enc28j60PowerDown();
}

in EtherShield.cpp with the following prototypes in EtherShield.h :

void ES_enc28j60PowerDown();   
void ES_enc28j60PowerUp();

Finally, you can try the modification with a code like this one :

Serial.println("Pausing");
 es.ES_enc28j60PowerDown();
 Serial.println("Paused");
 delay(10000);
 Serial.println("Powering Up");
 es.ES_enc28j60PowerUp();
 Serial.println("Powered up");
 delay(2000);

If everything is okay, you should see that the shield goes off for ten second : the leds are off and the chip cools down. The two processes of putting to sleep and waking up are done very quickly (about 1ms). This will help me reducing power consumption, heat generation and among all, avoids me the pain of getting the two annoying leds off the board.

Edit : After more tests, i discovered that the chip (or the library) seems to forget some part of the configuration after beeing waked up : you could need to re-configure some settings. In my case, a es.ES_client_set_gwip(gwip); did the trick. See edit 4.

Edit 2 : Correction of a little mistake, thanks to Christian N. for reporting (see comments).

Edit 3 : According to Christian N (see comments), putting the chip in sleep mode reduce the consumption by 150mA. Also, he had to re-initialise the board after waking up : re-setting the gateway how I explain in my first edit is not enough. Do you own tests !

Edit  4 : Thanks to Peter (see comments), the PowerUp() and PowerDown() code is corrected : my implementation was missing something, so the powering up function was not 100% effective and I had to reinitialize the chip.

Mise en place d’un système d’authentification forte via OTP sous Linux

Dimanche 3 juillet 2011

Authentification forte?

Il existe trois facteurs d’authentification à un système informatique :
-Ce que l’on sait, par exemple un mot de passe ou une phrase secrète
-Ce que l’on est, par exemple via le biais d’un lecteur biométrique
-Ce que l’on a : par exemple à l’aide d’un lecteur de carte à puce.

Chacune de ses méthodes a ses inconvénients : la carte à puce peut être volée ou le mot de passe peut être trouvé par exemple par le biais d’un keylogguer.
Ma motivation était d’empêcher le sniffing de mot de passe par le réseau ou d’un entourage curieux pouvant observer mon clavier afin de voir mon mot de passe.
Grace à l’authentification forte, ces risques sont réduits en utilisant deux facteurs conjointement. Le but de cet article est d’utiliser à la fois ce facteur «ce que l’on sait» et le facteur «ce que l’on a».

Pour cela, autant utiliser un objet que l’on a toujours sur nous, tel notre téléphone mobile qui va pouvoir assumer la partie «ce que l’on a».
Grace à un logiciel adéquat, notre téléphone  va générer un mot de passe à usage unique et qui a une durée de vie de quelques minutes. Ainsi, un mot de passe sniffé ou vu sera invalidé dès son utilisation, et les attaques de brute force ont très peu de chances d’aboutir en raison de la volatilité du mot de passe.

Le mot de passe est généré en faisant un hash du temps unix, d’une clef secrète (appelée semence ou seed) partagée par le serveur et le téléphone, ainsi que d’un code PIN entré par l’utilisateur sur son téléphone pour générer chaque mot de passe jetable, et connu du serveur également. Ainsi, même en cas de vol du téléphone, il faudra quand même connaitre le code PIN pour générer un mot de passe fonctionnel.

Installation du générateur de mot de passe sous Apple iPhone.

De nombreuses applications gratuites et performantes sont disponibles sur le marché. Pour en avoir essayé plusieurs, je vous conseille iOTP pour son efficacité et sa simplicité. Il est téléchargeable gratuitement sur l’App Store.

Lors du premier lancement de l’application, il vous faut créer un compte en allant dans l’onglet Accounts puis en touchant la croix en haut à droite.

Ensuite, il faut donner un nom au compte et toucher «Generate Secret». L’application vous donne alors une clef hexadécimale qu’il vous faut absolument noter : on devra ensuite la renseigner au serveur. Il vous est possible de vous l’envoyer par email, en prenant soin de l’effacer ensuite.

Une fois la configuration sauvée, vous pouvez générer un semblant de mot de passe en entrant un code PIN au hasard. Remarquez qu’un mot de passe différant est généré toutes les 20 secondes, il va falloir apprendre à taper vite.

Il est bien sur possible d’utiliser un générateur sur d’autres types de mobile, des clients spécifiques sont évidemment disponibles pour les personnes s’étant orientées vers des plateformes plus libres, tel Google Android ou simplement pour des téléphones supportant Java.
Ceci était la partie simple, il va maintenant falloir mettre les mains dans le cambouis et s’attaquer à la configuration du versant serveur.

Mise en place du serveur.

La suite de ce tutorial est faite sur Linux Ubuntu 9.10 version serveur, mais est facilement reproductible sur d’autres distributions voire sur des systèmes de type BSD.

Téléchargement de otpverify.sh

Ce script permet de vérifier la validité d’un mot de passe jetable en lui fournissant le PIN et la semence. Il vous faut le copier dans le repertoire /usr/local/bin et le rendre exécutable. Pour cela entrez les commandes suivantes:

cd /usr/local/bin
sudo wget http://motp.sourceforge.net/otpverify.sh
sudo chmod +x otpverify.sh

Le script fonctionne avec l’interpréteur de commande ksh, vous devriez peut-être l’installer en entrant la commande suivante:

sudo apt-get install ksh

Vous pouvez à présent tester le script en entrant la commande suivante:

 sudo otpverify.sh Utilisateur MotdePasse Semence PIN Décalage

Où Utilisateur est un nom d’utilisateur choisit arbitrairement, MotdePasse est le mot de passe livré par votre générateur, Semence est la semence générée par votre téléphone lors de son initialisation, PIN est un pin choisit arbitrairement pour les tests et décalage est le décalage horaire entre les deux appareils, qui est de zéro si le serveur et le téléphone sont dans le même fuseau horaire.
Le script a besoin des droits d’écriture dans le dossier /var/motp c’est pour cela qu’on doit le lancer en root.

Soit ici par exemple:

sudo otpverify.sh test 64b63d 17dcfe83efc531b6 9999 0

Si tout s’est bien passé, alors le script devrait retourner un simple «ACCEPT»
Si «FAIL» est retourné, c’est que les horloges ne sont pas bien synchronisées, il faut donc mettre l’heure à jour en s’aidant par exemple d’un serveur de temps public.

Installation du serveur d’authentification.

Le script va venir s’interfacer avec un serveur d’authentification radius pour une grande flexibilité et afin de permettre d’utiliser l’authentification forte avec un grand nombre de logiciels sur le marché.
Le serveur radius retenu ici est XTRadius mais la procédure est très proche pour d’autres serveur radius du marché.

Pour installer le serveur radius, utilisez apt-get comme à l’accoutumée. Il est également possible de le télécharger et de le compiler depuis le site officiel.

Des fichiers de configurations tout prêts pour XTradius sont disponibles sur le site de motp, il suffit de les installer en entrant les commandes suivantes :

cd /etc/raddb
sudo wget http://motp.sourceforge.net/dictionary.motp
sudo wget http://motp.sourceforge.net/execparams
sudo mv execparams.1 execparams

Il faut également rajouter la référance au nouveau dictionnaire dans le fichier des dictionnaires : il suffit de rajouter «$INCLUDE dictionnary.motp» au fichier dictionary

sudo nano dictionary

Vous devez maintenant renseigner les utilisateurs, ainsi que leur PIN et leur semence dans le fichier users selon le modèle suivant:

Il suffit de mettre le nom d’utilisateur, son secret, de choisir son code PIN et de mettre l’offset en cas de décalage horaire.

A présent, démarrez le serveur radius en mode verbose à l’aide de la commande suivante :

sudo radiusd -sxxy

On peut à présent tester le serveur radius à l’aide de l’utilitaire radtest à lancer dans un autre terminal. Si tout s’est bien passé, le serveur doit répondre «ACCEPT»

Et le serveur devrait afficher les opérations suivantes :

Si le serveur renvoie un «FAIL», il est possible que vous avez atteint le maximum de tentatives de login, il vous faut supprimer le contenu du repertoire /var/motp/users

A noter : le testing123 est la clef de cryptage qui correspond au client d’ip 127.0.0.1
Il n’est pas nécéssaire de la changer car ici le client et le serveur étant sur la même machine, les communications passent en loopback et donc par un réseau de confiance. Si  vous souhaitez quand même changer cette clef ou accéder au serveur radius depuis une autre machine, les informations se trouvent dans le fichier clients du repertoire /etc/raddb.
Le serveur radius est à présent bien configuré, on peut passer à l’étape suivante : configurer PAM pour que l’authentification,  ssh ici, passe par le serveur radius.

Configurer PAM pour fonctionner avec radius.

PAM (Pluggable authentication modules) est, comme son nom le laisse entendre, un système de gestion de l’authentification d’un grand nombre d’OS open source, pouvant être utilisé par de nombreux services. Faire le lien entre PAM et radius nous permettra d’utiliser l’OTP pour l’authentification, aussi bien pour FTP que SSH.

Le module à installer est sobrement appelé pam_radius_auth.
Il est possible de télécharger le module sur internet, mais par chance il est également disponible dans les dépots d’ubuntu.

Pour l’installer, il faut utiliser le sempiternel apt-get :

sudo apt-get install libpam-radius-auth

Il y a un brin de configuration à faire, ca se passe dans /etc/pam_radius_auth.conf où il vous faudra écrire le secret du serveur radius, c’est à dire testing123 par défaut.

Ensuite, il vous faudra configurer le fichier de configuration pour le service que vous voulez utiliser avec OTP. Ces fichiers se situent dans /etc/pam.d/
Ici, nous allons modifier sshd qui gère SSH. Il faut commenter la ligne

@include common-auth

en rajoutant un # devant. Puis, il faut ajouter la ligne

auth required pam_radius_auth.so

au dessus ou au dessous de la ligne précédement commentée.
Ensuite, il vous suffit d’enregistrer le fichier.

Pour être sur que ssh utilise PAM, il faut modifier /etc/ssh/sshd_config qui n’est d’autre que le fichier de configuration du service ssh en changeant la directive «ChallengeResponseAuthentication» pour la passer à yes.

Ensuite, redémarrez le serveur ssh et le serveur radius.

Un serveur web très sécurisé avec OpenBSD.

Dimanche 16 janvier 2011

Ces dernières semaines ont été pour moi l’occasion de faire la connaissance d’OpenBSD, un système d’exploitation orienté serveur, et ce bien plus que Linux. J’y ai retrouvé les mêmes qualités que lors de ma première découverte du monde de GNU/Linux il y a quelques années : fiabilité, sécurité, stabilité. OpenBSD semble faire mieux que GNU/Linux sur ces qualités, ceci induisant une plus grande inertie (le serveur Web par défaut n’étant qu’apache 1). En revanche, celui-ci n’hérite pas du côté « bazar » de GNU/Linux. Tout y est plus propre, plus organisé, et tout le monde possède sa page de man.

Pour explorer ce nouveau monde, il m’a semblé pertinent de commencer par installer et configurer Apache et son acolyte PHP en insistant sur les fonctionnalités de sécurisation d’OpenBSD, qui ont fait la notoriété de ce dernier. C’est cette expérience que je souhaite partager avec vous. Si elle s’avère concluante, je pense utiliser OpenBSD sur mes petits serveurs.

Je commencerais mon article par cette petite citation de Theo De Raadt qui pourrait résumer l’esprit de la communauté BSD, fréquemment surprise à piquer GNU/Linux

Linux people do what they do because they hate Microsoft. We do what we do because we love Unix.

1°Installation du système

Pour ma part, j’installerais mon système dans une VM, afin de pouvoir ensuite l’envoyer sur mon futur serveur ESXi. Bien sûr, la procédure est en tout point similaire en cas d’installation « en dur ».

Après avoir récupéré l’iso sur le site d’OpenBSD, et son lancement dans une machine virtuelle utilisant les pré-réglages de VMware (en utilisant le préréglage FreeBSD cependant), nous arrivons à la première étape d’installation.

Première étape

Dans le cadre d’une première installation, il nous faudra naturellement appuyer sur la touche I.

  1. Il vous demandera ensuite votre keyboard layout. Tapez fr si vous avez un clavier français.
  2. Choisissez votre nom d’hôte.
  3. Laissez lui obtenir son adresse par DHCP, il sera de toute manière possible de revenir là-dessus lors de la mise en production.
  4. Choisissez votre mot de passe root. OpenBSD est un système sécurisé, il serait dommage que sa plus grosse faiblesse vienne d’un mot de passe root anémique. Choisissez-en un unique, aléatoire, long et contenant des caractères spéciaux. Enfin, vous connaissez tout ça, mais ça me parait très important pour un système qui se veut sécurisé. Attention au pavé numérique en tapant des chiffres !
  5. Ensuite, libre à vous d’activer SSH par défaut, pour ma part j’utilise uniquement SSH et ne peut que vous conseiller de faire de la même façon.
  6. Le serveurNTPD n’a pas de sens puisqu’on veut un système léger et avec le moins possible d’angle d’attaque.
  7. Dans le cadre d’un serveur, utiliser X parait inapproprié, pour ma part je répondrais non à l’installeur. Répondez non à la question suivante, ça devrait aller.
  8. Créez ensuite votre compte utilisateur. Je vous conseille vivement de choisir un mot de passe différent que le mot de passe root, mais tout aussi complexe.
  9. Après avoir laissé la configuration par défaut aux questions suivantes, nous arrivons au partitionnement. N’ayant pas de problématique particulière, j’utiliserais tout le disque (W), en utilisant l’auto layout.

Après le formatage du disque, nous arrivons au choix de la source d’installation. Ayant eu des problèmes avec le ftp, je préfère le http. Je n’utiliserai pas de proxy, et garderai l’URL proposée par l’installeur.

Il est ensuite temps de sélectionner les paquets à installer. Refusant le superflu, et souhaitant le système le plus épuré possible, nous désactiverons les paquets game48.tgz, xbase48.tgz, xetc48.tgz, xshare48.tgz, xfont48.tgz et xserv48.tgz en tapant leurs noms précédés du signe – . Ces paquets contiennent le nécessaire pour le serveur graphique que nous n’utilisons pas, ainsi qu’un paquet de jeux.

Les téléchargements commencent, prenez le temps de boire un café (ou un thé selon vos préférences). Il vous faudra ensuite régler l’heure, puis c’est tout. Qui a dit qu’installer OpenBSD était fastidieux ?
Finalement, tapez reboot pour redémarrer.

2° Prise en main initiale du système

Bienvenue chez vous ! Vous pouvez vous connecter en root. Pour commencer, lisez votre premier mail, en tapant la commande éponyme. Il contient de nombreuses instructions post-installation.

Une des premières opérations à effectuer est d’activer sudo pour notre compte. Entrez la commande visudo et dé-commentez la ligne qui donne au groupe wheel le droit d’utiliser sudo. Attention, c’est vi, c’est assez pénible quand on connait pas.

A présent, je me connecterais en SSH à mon serveur pour avoir le clavier bien mappé et tout ça.

Vous remarquerez que le système prend moins de 500 Mo une fois installé. Il est bien sûr possible de descendre en deçà, mais la légèreté par défaut est très agréable.

Nous allons ensuite modifier notre .profile afin d’avoir toujours la variable PKG_PATH active. C’est cette variable qu’utilisera pkg_add pour  télécharger les logiciels.

J’y ajouterais les lignes suivantes :

export PS1="\u@\h:\w\$ "
export PKG_PATH=ftp://ftp.arcane-networks.fr/pub/OpenBSD/4.8/packages/amd64/

La première ligne sert à avoir une console affichant des informations sur le nom d’utilisateur, le nom d’hôte et le répertoire actuel. Ces informations éviteront d’inverser les serveurs, de se tromper d’utilisateur ou travailler sur les mauvais répertoires. Vous pouvez choisir l’URL de votre path selon vos préférences, le miroir que j’ai sélectionné me parait suffisamment sérieux.

Un rapide passage de nmap sur le serveur montrera qu’il y a déjà trop de services activés : ident, daytime et time. Ces petits services émanent du démon inetd. Celui-ci sert à lancer des services en cas de connexion sur des ports précis. Par exemple, il peut écouter le port ftp et attendre une connexion sur ledit pour lancer le serveur ftp. Ceci évite d’avoir le service ftp lancé si on utilisation est rare. Je désactiverais inetd car il nous sera inutile dans le cadre d’un serveur web simple, et dominera ainsi la surface d’attaque possible pour un attaquant potentiel. Pour cela, modifiez /etc/rc.conf et changez le YES en NO sur la ligne correspondante. Vous remarquerez que ce fichier contient tous les services, et s’ils doivent se lancer au démarrage. J’en profiterais pour désactiver sendmail car je ne l’utilise pas, mais faites comme vous en avez l’habitude.

Nous en profiterons pour activer apache, puisqu’après tout, c’est pour lui que nous travaillons.

# use -u to disable chroot, see httpd(8)
 httpd_flags=YES # for normal use: "" (or "-DSSL" after reading ssl(8))

Nous pouvons passer à l’installation de PHP. Rassurez-vous, ça devient intéressant

3° Installation de PHP et intégration dans l’environnement de chroot.

Sous OpenBSD, apache est chrooté. Pour faire simple, cela signifie qu’il est strictement cantonné à un répertoire, en plus de tourner sous un utilisateur spécifique. Cela signifie que, dans l’hypothèse d’une compromission de son processus, l’attaquant sera tristement cantonné au répertoire d’apache, réduisant ses possibilités d’obtenir un shell root, de modifier le reste du système ou de mettre la main sur d’autres données.

C’est le moment de mettre les points sur les i. Toutes ces protections ne sont pas complètement sécurisées pour toujours : les possibilités de failles logicielles et d’exploitation seront toujours présentes. Il s’agit simplement de multiplier les barrières au pirate potentiel afin de lui rendre la tâche plus compliquée, en espérant qu’il bute sur une de ces barrières. Vous allez penser que le titre de mon article vous vendait du rêve, je suis désolé d’entacher vos illusions, mais je pense qu’on sera d’accord pour dire qu’un système d’information infaillible et inviolable est une chimère. Le meilleur moyen de sécuriser un système, c’est de le débrancher (et de retirer la batterie sur un portable, bien sûr) et de ne rien attendre de lui. Néanmoins, relativisons, OpenBSD est très sécurisé, et à moins que votre système serve à contrôler des usines d’enrichissement d’uranium illégales, et que l’unité 8200 veut votre peau, il devrait pouvoir contenir un grosse majorité d’attaquants.

Pour revenir à nos moutons, le chroot est aussi une petite difficulté pour nous : php a besoin de certains fichiers qui ne sont pas dans l’environnement de chroot, et il va falloir mettre les mains dans le cambouis pour pallier à cela. Par chance, le php dans les dépots prend en compte toutes ces spécificités, évitant de devoir l’analyser pour copier dans le chroot les fichiers dont il a besoin. Pour l’avoir fait, c’est une manipulation assez peu intéressante.

Premièrement, installer php :

# pkg_add php5-core-5.2.13p0.tgz
 php5-core-5.2.13p0:libxml-2.7.6: ok
 php5-core-5.2.13p0: ok
 --- +php5-core-5.2.13p0 -------------------
 To enable the php5 module please create a symbolic
 link from /var/www/conf/modules.sample/php5.conf
 to /var/www/conf/modules/php5.conf.
ln -s /var/www/conf/modules.sample/php5.conf \
 /var/www/conf/modules
The recommended php configuration has been installed
 to /var/www/conf/php.ini.

Écoutez l’installeur et faites le lien comme demandé :

 ln -s /var/www/conf/modules.sample/php5.conf  /var/www/conf/module

Vous devez ensuite modifier /var/www/conf/httpd.conf et ajouter

AddType application/x-httpd-php .php

ou décommenter la ligne spécifique.

Ligne à décommenter

Ligne à décommenter

Il faut alors (re)lancer apache avec la commande

sudo /usr/sbin/apachectl restart

Pour vérifier l’installation  de notre php, nous poserons un fichier php avec phpinfo() et nous essaierons (avec succès normalement) d’y accéder depuis notre navigateur.

4° Un Apache sous haute surveillance avec systrace

Le chroot offre une bonne sécurité au niveau du système de fichier : Apache sera confiné à son répertoire et, à moins d’une faille dans chroot lui-même, le pirate potentiel sera déjà pas mal limité. Cependant, dans son répertoire, Apache pourra faire ce que bon lui semble.

Systrace permet de s’assurer qu’apache fait uniquement ce qu’il doit faire en surveillant attentivement ses appels système. Systrace se place comme un system call proxy, en se plaçant entre Apache et le kernel. Ainsi, il surveillera les appels système de Apache afin de s’assurer qu’il ne fait que des actions qui entrent dans le cadre de ses fonctions. Il faut donc créer les policies, listant tout ce que le logiciel fait en temps normal. Pour se faire, arretez apache avec sudo apachectl stop, puis relancez le avec sudo systrace -A  httpd.

Il faut à présent utiliser votre site dans ses moindre retranchements, afin de laisser systrace créer les règles. Pensez à utiliser toutes les fonctionnalités de votre site. Mon site possédait une fonctionnalité d’envoi d’images, je n’avais pas pensé à l’utiliser la première fois, cassant ladite fonctionnalité lors de la mise en production avec l’application de la police.

Une fois ce laborieux travail effectué, vous pouvez arrêter apache avec apachectl stop.

Il va falloir nettoyer la police afin de l’optimiser. Le fichier sera utilisé à chaque appel pour vérifier les droits, il faut donc qu’il soit très clair, et le plus condensé possible afin de minimiser l’inévitable impact sur les performances. Le fichier contenant la police sera créé dans le dossier .systrace de votre home. La lecture de ce fichier sera d’autant plus intéressante qu’elle vous apprend la totalité des actions entreprises par apache et vous dévoile son fonctionnement intrinsèque.

Je suppose que votre fichier ressemblera au mien :

Vous voyez tout les appels qu’apache à utilisé. Il faut à présent les condenser : Par exemple, apache aura besoin de lire dans /var/www, puisque c’est dans son répertoire. On a par exemple la ligne

native-fsread: filename eq "/var/www" then permit

qu’on peut transformer en :

native-fsread: filename match "/var/www/*" then permit

Vous devez, de cette façon, remodeler le fichier de police afin de réduire son nombre de règles. Pensez par exemple aux droits d’écriture dans le dossier tmp de php, ou dans le dossier des logs. Pensez également qu’après le chroot, le nouveau dossier racine est /var/www, il va donc falloir autoriser la lecture dans /htdocs et non /var/www/htdocs, etc. Notez les ports dont il a également besoin, comme le port dns 53, car ils nous serviront plus tard à configurer le pare-feu. Systrace offre également la possibilité de faire les règles en interaction avec le switch -t, cependant celle-ci ne créait pas toujours les règles avec les arguments des appels, créant ainsi des polices très laxistes.  Je suppose qu’on peut ordonner les appels par ordre croissant d’utilisation, afin d’éviter à systrace de parcourir toute la police à chaque fois. Toutes les opérations usuelles, telles les lectures dans /htdocs devraient être en haut. Je ne peux que vous inviter à passer du temps à concocter ces règles, celles-ci pouvant être la source de nombreux dysfonctionnements. Et en plus, c’est une activité assez intéressante car dévoilant les tréfonds de votre fidèle Apache. Vous remarquerez que les exécutables des shell, tels /bin/sh ne sont pas autorisés. En toute logique cela signifie que des shellcodes lançant des shells seront ainsi inefficace.  De plus, les appels concernant le réseau sont aussi interdits (sauf pour les dns et bien sur l’écoute sur le port 80), obligeant le pirate à réutiliser la connexion utilisée par le service de la page en HTTP, rendant une hypothétique exploitation bien plus compliquée.

Systrace peut également se montrer utile pour débugguer rapidement un programme en examinant les appels faits avant un crash. Systrace peut aussi servir à lancer une application nécessitant le compte root avec un compte limité, en exécutant lui même en root les quelques appels système root que le programme demande.

Il faut maintenant déplacer la police dans /etc/systrace/ avec mv et modifier /etc/rc pour qu’il lance httpd avec systrace, en ajoutant systrace -a avant la ligne lançant apache.

Modifications dans rc

Ligne à corriger

Lors du prochain redémarrage, httpd devrait se lancer, confiné dans son chroot et sous l’étroite surveillance de systrace. Je n’ai pas pu chiffrer l’impact sur les performances, mais je suppose qu’elles ne sont pas négligeables. Dans le cas d’un serveur non critique, l’activation de ce système n’est pas obligatoire, mais son approche et son application me parait assez intéressante pour être abordée.

5° Un système hermétique avec pf

Afin de limiter au strict minimum les interactions possibles avec notre serveur, et ce dans les deux sens, nous allons appliquer une stratégie très paranoïaque avec notre firewall. L’idée est que seuls les services nécéssaires soient accessibles depuis l’extérieur d’une part, et qu’une éventuelle compromission de notre serveur reste confiné en autorisant seulement certaines connexions sortantes.

La première question à se poser est « De quoi ai-je besoin ? ». Dans notre cas, nous aurons besoin de http sur le port tcp 80 en entrée et sortie, de ssh sur le port tcp 22 en entrée seulement. Il ne faut pas oublier les quelques interractions secondaires que notre serveur peut avoir vers l’extérieur. Par exemple, les dns sont utilisés fréquemment par plusieurs parties du système, on autorisera ainsi le port tcp/udp 53 en entrée et en sortie. Mon site a également besoin de se connecter à un serveur smtp pour envoyer des mails, ainsi ajouterai-je le port tcp 25. L’heure en synchronise en NTP, il faudra donc autoriser le port udp 123. Ajoutez à cette liste les ports dont vous avez besoin dans votre configuration.
Il ne reste qu’a modifier /etc/pf.conf pour y ajouter les règles suivantes, à la fin :

table <bruteforce> persist

tcp_in = " {www} "
tcp_out = " {domain, smtp} "
block all
block quick from <bruteforce>
pass in proto tcp to port $tcp_in
pass out proto tcp to port $tcp_out
pass in quick proto tcp from any to any port ssh flags S/SA keep state (max-src-conn 10, max-src-conn-rate 3/3, overload <bruteforce> flush global)

Ces règles sont certes très fermes puisque n’autorisant que le strict nécessaire (il vous sera impossible de faire des ping !) mais reste dans la continuité de notre stratégie consistant à n’autoriser que le strict nécessaire, et ce afin d’éviter contamination ou contagion.

La dernière ligne a pour effet de laisser passer le SSH, mais empêche les attaques bruteforce en bloquant les adresses IP des personnes ayant ouvert plus de 10 personnes à la fois, ou 3 connections en moins de 3 secondes, ce qui n’arrive jamais en utilisation légitime. Si vous utilisez plus de 10 connections simultanées en SSH, vous pouvez naturellement changer les valeurs.

6° Les file flags, et le securelevel ou comment empêcher la modification du système

OpenBSD possède une autre fonctionnalité de gestion des droits : il est capable d’apposer des drapeaux sur les fichiers afin d’éviter leur modification ou leur suppression (entre autre). Nous allons nous servir de ces flags pour empêcher un intrus de modifier notre noyau, ou de modifier/ajouter des binaires. Cela rendra la pose de porte dérobée ou l’altération du système moins discrète puisque l’attaquant devra redémarrer, voire un peu plus compliqué. Nous allons poser le drapeau schg, qui rend le fichier immuable, sur les dossiers /bsd (qui contient le noyau), /bin et /sbin (qui contiennent les exécutables). Attention, pour retirer un file flag, il faudra que le système s’exécute avec un securelevel de -1. Les securelevel définissent un comportement sécuritaire global sur le système. Pendant l’exécution, il est possible de monter le securelevel, mais pas de le descendre. Pour le monter, il faut utiliser sudo sysctl -w kern.securelevel=1 Pour le diminuer, il faut redémarrer après avoir modifié /etc/rd.securelevel.

Les securelevel sont les suivants :

  • -1 : Tout est comme un UNIX normal. Si vous voulez bidouiller, c’est le runlevel à adopter.
  • 0 : Ce securelevel est utilisé pendant la procédure du boot, avant que le système passe en multi utilisateur. Lors du passage en multi utilisateur, le securelevel est de toute manière élevé à 1, donc mettre securelevel=0 dans /etc/ rc.securelevel revient à un securelevel de 1.
  • 1 : Par défaut. C’est ici que l’utilité du runlevel se fait sentir :
    • Personne peut écrire dans /dev/mem et /dev/kmem (périphériques de la mémoire / mémoire du kernel)
    • Les raw disk devices sont en read only, tout doit passer par le système de fichier.
    • Les files flag ne peuvent pas être supprimés
    • On ne peut pas ajouter le modules au kernel. Mais ça n’ aucun impact pour nous autres administrateurs système légitimes puisque le noyau est de toute manière monolithique.
  • 2 : Niveau maximum. Comme le niveau 1 plus :
    • L’horloge système ne peut pas être reculée ou proche du point d’overflow
    • pfctl ne peut pas modifier les règles PF ou NAT
    • Les valeurs sysctl du débogueur de noyau ddb ne peuvent pas être changées.

Pour en revenir à nos file flags, nous allons placer schg sur les dossiers invoqués plus haut :

sudo chflags -R schg /sbin/
sudo chflags -R schg /bin/
sudo chflags schg -r /bsd

Pour retirer les file flag, il faudra modifier /etc/rc.securelevel et mettre le securelevel -1, puis redémarrer et taper les commandes

chflags noschg /bsd

L’idée de mettre un schg sur /etc m’a caressé l’esprit, mais étant donné que le fichier pour changer le securelevel est dedans, j’ai préféré éviter la catastrophe en abandonnant l’idée. Il est bien sur possible de mettre les flags fichier par fichier en fonction de ce que vous souhaitez protéger. Vous pouvez ensuite relancer le serveur avec le securelevel de 2.

Une autre pratique courante est de poser un flag sappnd sur l’history des shell, pour garder une trace de toutes les manipulations des utilisateurs.

7° Le mot de la fin

Une fois le serveur redémarré, il devrait être « fonctionnel ».
« Fonctionnel », car le client aura ce qu’il veut, soit un site accessible. Cependant, toutes ces sécurités apportent une lourdeur d’administration assez conséquente : sans redémarrer, il est impossible de mettre à jour les logiciels, de modifier les règles du pare-feu, de pinger, de télécharger un fichier, etc. Comme toujours, une sécurité accrue se fait au détriment de l’ergonomie pour le sysadmin. C’est pour cela qu’il faudra « vitrifier » le système qu’une fois tout rodé. Enfin, ce type d’architecture est plus intéressante utilisée conjointement avec un load balancing avec un système bsd + pf en frontal, afin de pouvoir mettre à jour les serveurs sans interruption de service.
En outre, il ne vous protège pas d’attaques périphériques, comme un attaquant s’introduisant sur votre machine pour poser un keylogger pour obtenir votre mot de passe SSH, de vol de clef, de MITM ou plus sobrement de shoulder surfing. La surveillance  des logs du serveur pourra permettre de surveiller des intrusions, et il est bien sur possible d’utiliser des IDS/HIDS pour surveiller tout cela.

Si vous voyez des failles, des mauvais réglages ou si vous avez des choses à ajouter, je vous invite à me contacter. Amusez-vous bien avec OpenBSD !

 

Update 1 : Mise à jour des règles du pare feu, merci à ptr pour ses éclairements. (Voyez les commentaires pour plus d’informations)