Le besoin de hasard en cryptographie

 Trucs et astuces techniques  Commentaires fermés sur Le besoin de hasard en cryptographie
Août 182011
 

Les ordinateurs sont totalement déterministes.
En dépit du fonctionnement souvent incohérent des programmes informatiques mal conçus, le matériel informatique est souvent cohérent et fiable.
La cryptographie nécessite pour être efficace de disposer de nombres à peu près aléatoires mais surtout très difficilement prévisibles, ce qui est loin d’être évident sur un système déterministe.
Les programmeurs ont conçu de nombreuses méthodes pour que les ordinateurs génèrent des nombres apparemment aléatoires.
Ces algorithmes sont regroupés sous le nom générique de générateurs de nombres pseudo-aléatoires (PRNG).
Les générateurs de nombres pseudo-aléatoires suffisent pour des applications simples, comme la création d’événements « aléatoires » dans des jeux vidéo. Le générateur de congruence linéaire (GCL), est un exemple classique de ce type d’algorithme.
Pourtant, rien n’est vraiment imprévisible dans les calculs effectués, et là réside le problème : un attaquant peut facilement utiliser sa propre copie du générateur pour
connaître tous les résultats que notre PRNG créera.
Même si notre PRNG part d’un état initial inconnu de l’attaquant, il est souvent possible de déduire des propriétés importantes de cette valeur initiale en observant les sorties produites puis d’utiliser ces informations pour régler son propre PRNG. Une méthode générale pour reconstruire et prédire tous les polynômes des générateurs de congruence a été établie dans les années 1990. Ce problème crée un trou béant dans la sécurité des algorithmes de cryptage.

La seule méthode qu’un ordinateur peut employer pour produire des données quasiment imprévisibles consiste à rassembler autant d’informations non prévisibles que possible à partir de ‘environnement physique et de les utiliser comme valeurs à transférer à tous les programmes qui nécessitent une bonne part de hasard. C’est pourquoi on récupère des événements vraisemblablement peu prévisibles comme les I/O clavier/souris, réseau et disques.

Le problème est que dans des conditions particulières, ces événements vraisemblablement peu prévisibles le sont en fait assez (prévisibles).

De nos jours, un certain nombre de plates-formes matérielles implémentent des générateurs de nombres aléatoires physiques, appelés vrais générateurs de nombres aléatoires (TRNG, de l’anglais True Random Number Generators). Ils font appel à certaines caractéristiques physiques d’un composant qui changent en raison d’un bruit thermique comme par exemple le courant dans un résistor. Cette solution simple à base de semi-conducteur est assez fiable.
Une des techniques les plus sure mais des plus tordues à mettre en œuvre est la mesure de la décroissance radioactive d’un isotope instable. Ces périphériques offrent un moyen plus fiable de générer des données vraiment imprévisibles par rapport à la collecte d’informations dont on ne fait simplement qu’espérer qu’elles soient difficiles à prédire.

Netstat et ses options sympa

 Trucs et astuces techniques  Commentaires fermés sur Netstat et ses options sympa
Fév 092010
 

Pour avoir des statistiques réseau sous linux, vous connaissez certainement netstat

Certaines combinaisons d’options sont plus faciles à retenir avec des moyens mnemotechniques
Parmis les options intéressantes :

netstat -lapute

ou encore

netstat -pantalon

Ce sont évidemment des options composées, pour plus d’infos RTFM.

Rsync en specifiant une clé RSA

 Trucs et astuces techniques  Commentaires fermés sur Rsync en specifiant une clé RSA
Jan 202010
 

L’astuce est de specifier la commande ssh que rsync doit utiliser pour se connecter et de donner les bonnes options à ssh

exemple

rsync -av -e "ssh 
-o UserKnownHostsFile=/dev/null 
-o StrictHostKeyChecking=no 
-o PasswordAuthentication=no 
-i $RSAKEYFILE" 
--delete-before 
$LOCALPATH 
user@$BACKUPSRV:$REMOTEBACKUPPATH

(Supprimer les retour de ligne pour utiliser)

WakeOnLan dans un réseau routé

 Trucs et astuces techniques  Commentaires fermés sur WakeOnLan dans un réseau routé
Déc 222009
 

Dans un réseau routé, les broadcast ne sont pas propagé. Il est donc difficile d’envoyer les magicpackets « Wake on Lan » dans tous les segments si on y possède pas déjà au moins une machine up avec les privilèges nécessaires pour emettre des broadcasts dans ce segment.

On peut bypasser une partie du problème en encapsulant les magic packet en UDP et en l’envoyant à l’IP que le poste est censé avoir.
Cependant, si le poste en question reste inactif, la table ARP du routeur perdra la correspondance IP/MAC et le routeur se contentra de faire des requetes ARP mais sans transmettre le paquet UDP (pas de broadcast) car il n’en connais pas l’adresse unicast de destination. généralement, on recevra un paquet ICMP « host unreachable » après plusieurs timeout ARP.

On peut contourner ce second problème en ajoutant une entree statique dans la table ARP du routeur :

Par exemple, supposons un routeur ayant les interfaces suivantes
eth0 : 192.168.0.254 netmask 255.255.255.0 (MAC 00:11:22:33:44:0A)
eth1 : 192.168.20.254 netmask 255.255.255.0 (MAC 00:11:22:33:44:0B)

un machine cible hors tension ayant normalement pour pour configuration
eth0 : 192.168.20.63 netmask 255.255.255.0 gw 192.168.20.254 (MAC 00:11:22:33:44:0C)

un machine « réveil » active ayant pour pour configuration
eth0 : 192.168.0.10 netmask 255.255.255.0 gw 192.168.0.254 (MAC 00:11:22:33:44:0D)

Si la machine réveil veut envoyer un paquet UDP dans le réseau 20 à la MAC 0D supposée avoir pour IP 192.168.20.63,
Le paquet UDP sera d’abord envoyé au routeur mais celui-ci le jettra car il ne connais pas la MAC de 192.168.20.63.

On pourrait envoyer à l’adresse de broadcast 192.168.20.255 mais la plupart des routeurs ne transfèrent pas ces paquets entre les réseaux pour des raisons de sécurité évidentes… (Il suffirait d’envoyer un paquet à 255.255.255.255 pour que la TOTALITE des quelques milliards de machines qui constituent l’internet le reçoivent!!! vive le flood !!!)
L’astuce consiste donc à ajouter une seconde adresse de broadcast sous la forme d’une entrée statique dans la table ARP du routeur
192.168.20.250 > FF:FF:FF:FF:FF:FF

ainsi, en envoyant le paquet UDP à l’adress IP 192.168.20.250, le routeur l’enverra à la mac FF:FF:FF:FF:FF:FF qui se trouve être l’adresse ethernet de broadcast. Le paquet sera donc reçu par toutes les machines du réseau 20 et la machine possédant la bonne mac s’allumera.

Authentification Kerberos/ActiveDirectory sur Apache2

 Trucs et astuces techniques  Commentaires fermés sur Authentification Kerberos/ActiveDirectory sur Apache2
Sep 142009
 

dans la conf du serveur web, ajouter dans le virtualhost concerné


<location />
    AuthType Kerberos
    KrbAuthRealms DOMAIN.IN.AD
    KrbMethodNegotiate off
    KrbMethodK5Passwd on
    KrbAuthoritative on
    KrbVerifyKDC off
    KrbSaveCredentials off
    AuthName "Nom de la zone réservée"
    AuthGroupFile /chemin/vers/monfichierdegroupe
    Require group nomdugroupe 
</location>

On pourrait aller chercher les membres du groupe dans l’AD avec LDAP cependant ça fait vraiment bcp de requetes LDAP et les systemes de cache sont assez chiants à mettre en place. De plus, mettre dans le serveur web les crédits necessaires pour faire des interrogations LDAP sur un AD pose des problèmes de sécurité. C’est pour ça qu’il est plus simple d’utiliser un script indépendant, lancé périodiquement en CRON par un autre utilisateur afin de créer un ficher de groupes. Ok, ça n’est vraiment pas estéthique mais ça marche très bien et c’est relativement sécure. 🙂

Pour La création du fichier de groupes, voir mon programme LDAP_C