HSC
Network Security Consulting Agency Since 1989 - Specialized in Unix, Windows, TCP/IP and Internet
Text mode: access to the page content
Hervé Schauer Consultants
You are here: Home > Resources > Techno-Watch >
Go to: HSC Trainings
Télécharger le catalogue des formations
Search:  
Version française
   Services   
o Skills & Expertise
o Consulting
o ISO 27001 services
o Audit & Assessment
o Penetration tests
o Vunerability assessment (TSAR)
o Forensics
o ARJEL
o Training courses
o E-learning
   Conferences   
o Agenda
o Past events
o Tutorials
   Resources   
o Thematic index
o Tips
o Lectures
o Courses
o Articles
o Tools (download)
o Vulnerability watch
   Company   
o Hervé Schauer
o Team
o Job opportunities
o Credentials
o History
o Partnerships
o Associations
   Press and
 communication
 
 
o HSC Newsletter
o Bulletin juridique HSC
o Press review
o Press releases
o Publications
   Contacts   
o How to reach us
o Specific inquiries
o Directions to our office
o Hotels near our office
|>|  
> Access to the content HTML Beginning of the report  
> Description Report on the tenth Usenix Security Symposium, which took place in Washington on 13-17 August 2001.  
> Context & Dates Report made for our news monitoring service .
The difference between the report writing and publishing dates are generally due to corrections and proofreading by the different people who took part in the conference.
17 August 2001 - Report writing
20 August 2001 - Sending to the news monitoring service subscribers
22 February 2002 - Publication on HSC's web site  
> Author Hervé Schauer (Herve.Schauer@hsc.fr) 
> Type  
> Abstract &
Table of content
Usenix a été riche, aussi malgré ma sélection ce compte-rendu est long. Je recommande à celui qui ne peut tout lire de sélectionner dans le plan ci-dessous, la majorité des paragraphes sont des résumés des sujets traités.
1. Tutoriels
2. Introduction de la conférence
3. Dénis de service
4. Firewalls
5. Les firewalls et l'inondation de SYN
6. Le firewall IP-Filter
7. SSH
8. Réseaux sans fil
9. Voix sur IP
10. Stéganographie
11. Réponse aux incidents
12. Code Red
13. Sécurité matérielle
14. Autres sujets
15. SDMI/DMCA
16. Conclusion
Annexe : Acronymes  
> Related documents
> Copyright © 2001-2002, Hervé Schauer Consultants, all rights reserved.

 


1. Tutoriels

Les deux premiers jours sont consacrés aux tutoriels. Philip Cox a proposé un nouveau tutoriel sur la sécurité des réseaux sans fil, sujet sur lequel HSC avait déjà travaillé. Cela a permis de confronter les points de vue et d'enrichir son cours. Les autres sujets étaient classiques, mais certains tutoriels me laissent perplexe : le tutoriel "Hacking Exposed" que j'ai pris la peine de suivre est un cours d'intrusion (ou de piratage) pas à pas. Je ne nie pas l'importance des prestations de tests d'intrusion et de tests de vulnérabilité pour valider régulièrement de l'extérieur ses systèmes et ses équipes par des sociétés spécialisées. Cependant je suis plus mesuré sur l'intérêt et la finalité d'enseigner les techniques d'intrusion et d'utilisation des exploitations de failles à des centaines de personnes. La raison de mon choix était simple : c'était le seul tutoriel de la journée que je n'avais pas suivi. C'était l'occasion de voir jusqu'où ils allaient et comparer avec nos propres techniques. Mais quelle est la finalité des participants ?


2. Introduction de la conférence

Richard Smith de la Privacy Foundation, a introduit les conférences en rappelant que les équipements de la maison du futur étaient conçus pour espionner nos faits et gestes et que la vie privée était grandement menacée. Il n'a cependant pas donné d'exemples pertinents ni proposé d'action concrète.


3. Dénis de service

La première session a traité des dénis de services. Cette session a tout d'abord montré la difficulté de mesurer réellement l'impact des DoS et DDoS sur Internet, les statistiques de CAIDA pourtant utiles ayant été critiquées. Mais pire, les présentations pour se protéger d'attaques ont été très sévèrement critiquées comme rarement dans une conférence.

Il y avait pourtant de bonnes idées, comme une modification du protocole TLS pour se protéger de calculs RSA provoqués inutilement sur un serveur web par un attaquant (Xerox).

Le système le plus polémique et le plus attaqué a été celui de Mazunetworks, qui détecte un déni de service réparti quand il y a trop de trafic dans un sens par rapport à un autre et filtre alors l'attaque. Les participants ont montré l'inadéquation du système, la facilité avec laquelle il pouvait être contourné, comment l'attaque pouvait se retourner contre le site ayant un tel équipement et pourquoi une telle analyse de trafic ne pouvait pas être utilisée sur des gros débits. Il n'est pas réaliste de filtrer des adresses IP source aléatoires, et il est gênant qu'un tel papier, présenté au comité de programme lorsque les auteurs étaient étudiants au MIT, ait été sélectionné pour la conférence, car il servira à justifier abusivement le marketing de cette start-up Internet.

L'analyse de trafic est une bonne méthode générale de détection des incidents, et pas uniquement des dénis de service. Par contre comme toute méthode de recherche d'incident, il ne faut pas lui associer un filtrage IP automatique, sans contrôle humain. Les routeurs et commutateurs permettent de plus en plus souvent de mesurer le trafic et le limiter (Cisco par exemple).

Un test des firewalls vis-à-vis de leur protection à l'inondation de SYN est relaté dans le paragraphe 5.

Pour en savoir plus :


4. Firewalls

La session consacrée aux firewalls a montré que le firewall demeure le coeur des dispositifs de sécurité, avec plusieurs innovations. Les firewalls ont été aussi traités à plusieurs reprises par les orateurs invités.

Un comparatif du traitement de l'inondation de SYN par les firewalls et le firewall IP-Filter sont traités dans les 2 paragraphes suivants.

Vern Paxon (ATT), a présenté le Normalizer, qui vise à éviter qu'une sonde de détection d'intrusion soit victime d'un attaquant qui cherche à masquer son attaque. En effet, en jouant au niveau IP sur le TTL, la fragmentation, etc, il est facile à un attaquant de ne pas être détecté par une sonde de détection d'intrusion, comme HSC l'a démontré à SANS en 2000. Donc si on accepte IP de bout en bout entre l'Internet et son réseau privé, il recommande l'ajout avant la sonde de détection d'intrusion de son "Normalizer", que cela soit avant ou après le firewall.

     Internet -- Normalizer ---+---- Réseau privé
                               |
                              NIDS

Vern Paxon a listé 73 reformatages possibles pour garantir des paquets IP sains, le Normalizer en réalise déjà 54, et il élimine en entrée de réseau les paquets mal formés. Il fonctionne sur Linux ou FreeBSD et supporte des débits supérieurs à 100 Mb/s. Le Normalizer améliore l'utilité du système de détection d'intrusion, même si Vern Paxon a rappelé la difficulté à utiliser efficacement un système de détection d'intrusion. Une telle fonction devrait être intégrée aux firewalls.

Peter M. Gleitz, du DoD, a présenté son utilisation du filtrage IP au DoD dans un réseau IPv6, à la suite de travaux menés chez ATT Research.

L'objectif est de filtrer correctement même les protocoles que le firewall ne connaît pas. Le principe consiste à associer à une machine autant d'adresses IPv6 que de services à contrôler sur celle-ci. Cela est très utile, notamment pour des protocoles comme Real Audio, X11, H323 et TFTP, où il n'existe pas ou très rarement un firewall permettant un filtrage dynamique de ces protocoles. En IPv6 le filtrage dynamique ne semble pas encore disponible, même pour FTP. Avec ce principe, les intervalles de ports importants qu'il faut ouvrir pour ces protocoles dynamiques, ne sont ouverts que pour le service concerné. Ils ne peuvent être accessibles par une autre application, car l'adresse IP associée n'est pas la même et l'autre application sera filtrée.

Dans les adresses IPv6 de son réseau, dans la partie locale (64 bits de droite), au milieu 16 bits sont constants, toujours à "FFFE". Il supprime ces 16 bits, et décale vers la gauche de 16 bits toutes ses adresses. L'adresse IPv6 est décomposée ainsi :

  • 64 bits de partie réseau, fournie par l'opérateur
  • 48 bits identifiant localement la machine
  • 16 bits qui identifieront le service ou l'application sur la machine, appelés PGA : Process Group Address, dans lequel sera mis un PGID (Process Group ID).

Le PGA 0000 est utilisé pour contacter la machine. Les PGA de 0001 à FFFF sont associées dynamiquement à la demande. C'est un peu comme implémenter les n° de protocole et de port dans l'adresse IP, et les n° de processus dans l'adresse IP.

Le principe a été implémenté sur Unix. Il reconnaît que ce principe augmente la complexité, mais permet des accès IP directs entre deux réseaux en toute sécurité, ce qui était impossible auparavant.

Ce principe marche bien avec telnet, FTP, SSH, SMTP, TFTP, IPsec, mais ne marche pas avec les r-commandes Unix qui font une interrogation DNS dans les deux sens, ni avec un serveur d'authentification. Au niveau du DNS, il y a 26 enregistrements par machine. Le déploiement actuel utilise un DNS modifié, mais il est possible d'utiliser aussi un DNS dynamique. Au niveau réseau, les routeurs voient des adresses avec des masques en /112. C'est transparent pour le routage. Au niveau Ethernet le routeur doit accepter des tables ARP importantes. Le seul problème non résolu concerne les ICMP redirect d'ICMPv6, qui peuvent affecter le PGA dans une adresse IPv6.

La présentation était courte et manquait de détails d'implémentation, il a cependant affirmé que c'était un déploiement opérationnel.

En dehors des présentations exposées aux paragraphes 5 et 6, d'autres présentations moins convaincantes ont traité des firewalls, comme Lumeta qui a fait une démonstration d'un logiciel qui tente de détailler les règles d'un firewall. La configuration originale était plus simple à comprendre que leur version. Ces présentations démontrent la dynamique du secteur en sécurité.

Pour en savoir plus :


5. Les firewalls et l'inondation de SYN

Ross Oliver, de Tech Mavens, a réalisé une étude comparative des firewalls qui protègent des inondation de paquets SYN (SYN-flooding).

L'objectif est de mesurer si les firewalls qui le prétendent arrêtent réellement les inondations de SYN et si les utilisateurs légitimes peuvent passer.

 Attaquant -------+
 Linux RedHat     |
                  +----- Firewall ------ Serveur
                  |      à tester        Apache sur Linux RedHat 7.1
 Client web ------+
 W2K avec wget
L'attaque est faite avec un seul attaquant et un seul client légitime, ce qui limite la portée du test.

Les tests ont étés réalisés par des équipements prêtés par des intégrateurs, à chaque fois plutôt proches de l'entrée de gamme. Deux paramètres sont mesurés, que j'ai remis sous forme de tableau : le nombre de SYN par secondes à partir desquels le serveur ne fonctionne plus ou est fortement dégradé, et le temps nécessaire au serveur pour retrouver un fonctionnement normal.

                      SYN/s à partir desquels    Temps nécessaire
                      le serveur web ne          au redémarrage
                      fonctionne plus            normal après l'attaque

 Pas de firewall           100 SYN/s                1 à 3 minutes
 Cisco PIX                 100 SYN/s                0 minutes
 Nokia 340 (Firewall-1)    500 SYN/s                3 à 10 minutes
 Netscreen 100           14000 SYN/s                0 minutes
 TopLayer AppSafe>22000 SYN/s                0 minutes

Le Cisco PIX offre une configuration contre l'inondation de SYN par "conduit" au sens du PIX, sur la base de l'analyse du trafic. D'autres routeurs/commutateurs offrent un meilleur contrôle, par adresse IP source/destination ou par flux. Il permet au serveur Linux de repartir dès l'attaque passée.

Avec le Nokia FW-1 au delà de 500 SYN/s l'accès au serveur était impossible, mais après l'arrêt de l'attaque, compte tenu de la technique de SynDefender utilisée par Check Point, il faut 3 à 10 minutes au serveur pour marcher à nouveau : le FW-1 réponds à la place du client, et s'il voit que le client ne réponds pas au bout d'un certain temps il renvoi un Reset :

                   SYN              SYN
     Attaquant -----------> FW-1 -----------> Serveur WEB
                                   SYN/ACK
                                 <-----------
                                     ACK
                                 ---------->
  et comme le ACK ne vient pas de l'attaquant, alors :
                                    RESET
                                 ---------->
Cette technique provoque un gros trafic pour rien sur le serveur WEB.

Le Netscreen a donné des réponses du serveur acceptables, et au-delà de 14000 SYN/s la performance s'est dégradée. Le retour du service est instantané dès l'arrêt de l'attaque. La technique du Netscreen est la suivante : si une adresse IP a déjà fait une connexion TCP complète alors elle n'est pas relayée par Netscreen, la connexion passe normalement en IP. Si une adresse IP est nouvelle, alors le Netscreen relaye la connexion TCP (SYN-proxying). Il envoi le ACK au client lui-même, et donc ne contacte le serveur web qu'après le ACK du client. Le Netscreen en mode transparent s'ajoute facilement à l'infrastructure et au firewall existant.

Toplayer AppSafe (anciennement AppSwitch) n'a donné aucun changement mesurable dans les temps de réponse. Le PC de l'attaquant n'a pas atteint la limite du TopLayer car il ne pouvait inonder plus de 22000 SYN par secondes. Le TopLayer apparaît comme le meilleur équipement de l'étude mais aussi le plus cher.

Le PIX et le Nokia sont réalisés avec des bases de PC, là où Netscreen et Toplayer sont des commutateurs.

Il convient de mettre ces chiffres en perspectives avec les capacités des lignes des attaquants :

  • Modem analogique : 87 SYN/s
  • Modem ISDN, modem câble, modem DSL : 200 SYN/s
  • Liaison spécialisée 1,5 Mb : 2500 SYN/s
  • 500 machines piratées avec une attaque en déni de service réparti permettent de générer plus de 25000 SYN/s.

Les statistiques des CERT indiquent qu'une attaque par inondation de SYN sur deux a moins de 500 SYN par seconde, et que moins de 5% des attaques dépassent 20000 SYN par seconde. Donc un équipement protégeant jusqu'à 500 SYN par seconde peut être utile, tout dépend de son objectif.

Ross Oliver conclut que l'on peut désormais se protéger efficacement des inondations de SYN, ce qui compte pour son choix est la bande passante en entrée, plus que le nombre de serveurs WEBs, quitte à configurer correctement ces serveurs. Il rappelle qu'il est possible de paralléliser les systèmes.

Il n'a pas eu le temps de tester les méthodes de protection contre les inondations de SYN proposées dans les serveurs, qui existent notamment sur Linux avec les SYN-cookies et sur Solaris. Celles-ci complémentaires aux protections dans les firewalls. Il recommande aussi d'utiliser le contrôle de la bande passante disponible sur les routeurs.

Je rappelle que de manière plus générale les protections dans les piles TCP/IP donnent des résultats et doivent être utilisées quand elles existent, et pour les attaques au niveau suivant, ouverture complète de la session TCP, des applications comme xinetd et popa3d offrent aussi de bons résultats.

Pour en savoir plus :


6. Le firewall IP-Filter

Il y a eu deux présentations sur IP-Filter. IP-Filter est un logiciel appartenant à son auteur, Darren Reed, et disponible gratuitement, qui transforme une machine Unix (*BSD, Solaris et HP-UX) en un firewall. IP-Filter semble le firewall actuellement le plus utilisé de ceux dont le code source est disponible. Il est utilisé dans de nombreux environnements commerciaux, certains administrateurs présents, travaillant chez des fournisseurs de service ou des institutions financières ont affirmé avoir plus de 45000 règles avec IP-Filter.

Darren Reed, auteur d'IP-Filter, a indiqué quel était son travail en cours pour IP-Filter 4.0. Les nouveautés qu'il prévoit sont conséquentes :

  • Des améliorations dans la syntaxe de configuration et dans "ipmon"
  • La fusion des tables d'état et de traduction d'adresse
  • La possibilité de configurer plus facilement un nouveau protocole avec un filtrage IP dynamique, ce qui permettra un meilleur support de SCTP, GTP, et IKE en standard.
  • La possibilité de brancher des programmes externes de gestion d'un protocole
  • Dans les nouveautés non encore décidées, il envisage des nouveaux relais, notamment un relais MS-Exchange, et une amélioration de la haute-disponibilité.
Enfin le code sera unique pour toutes les plates-formes. Actuellement la version d'IP-Filter sur HP-UX utilise des fonctions non documentées et spécifiques du noyau HP-UX.

Le lendemain, Guido Van Rooj a donné une présentation technique explicitant son implémentation du filtrage de session dans IP-Filter. Celle-ci est également utilisée dans PF, le filtrage d'OpenBSD. La gestion d'un flux TCP dans les détails est complexe et il a montré qu'il avait commis les mêmes erreurs que dans la majorité des systèmes commerciaux, mais les améliorations de la nouvelle version permettront d'éviter de casser une session TCP valide quelles que soient les circonstances. Je recommande la présentation qui explique bien le fonctionnement d'une session TCP.

Pour en savoir plus :


7. SSH

Dawn Xiadong Song a présenté une attaque peu convaincante sur SSH. Le principe est de faire une écoute passive, de noter la taille des paquets et les intervalles entre les paquets, puis d'associer cela à des bases de données permettant statistiquement de reconnaître des séquences comme "su Return password: le_mot_de_passe Return #". Le principe donne le nombre de caractères dans le mot de passe, et les associations de lettres les plus probables du mot de passe. Aucun mot de passe n'a encore été obtenu par cette technique.

SSH intéresse beaucoup de monde, et dans les discussions de couloir les attaques sur SSH intéressent beaucoup. Cependant, aucune rumeur n'a fait état d'une nouvelle attaque récente sur SSH.

Pour en savoir plus :


8. Réseaux sans fil

Adam Stubblefied de Rice University, aidé de John Ioannidis et Avi Rubin d'ATT Research, ont mit en oeuvre l'attaque décrite théoriquement par Fluhrer, Mantin et Shamir sur WEP. WEP est le protocole de chiffrement des réseaux Ethernet sans fil (norme IEEE 802.11b). L'objectif de WEP est de fournir une intégrité aux réseaux sans fil similaire à celle d'un câble. La clé secrète de 128 bits en RC4 a été récupérée en une semaine. Ils ont utilisé le fait que le vecteur d'initialisation est connu ; avec ces 3 octets connus ils en ont déduit le reste. Le code n'est pas disponible publiquement et il a indiqué qu'il n'y avait pas de raison de diffuser un tel code.

Arushesh Mishra réalise une implémentation en libre de la norme IEEE 802.1x. La norme 802.1x n'est pas spécifique à 802.11b, elle permet une authentification par prise Ethernet, et si elle ne résout pas tous les problèmes du WEP elle améliore la situation. L'authentification utilise le protocole EAP (Extensible Authentication Protocol).

Pour en savoir plus :


9. Voix sur IP

Niels Provos, de l'Université du Michighan, a présenté VOMIT (Voice Over Misconfigured Internet Telephones). VOMIT est un outil d'écoute de communication de voix sur IP, qui permet aussi de faire des appels téléphoniques en voix sur IP en batch, ou d'inclure des fichiers audio dans une communication téléphonique. Niels Provos a réalisé une démonstration en direct sur sa boite vocale. Cela montre la facilité avec laquelle la voix sur IP permet des manipulations accessibles à un plus grand nombre. VOMIT est en licence BSD et peut être réutilisé dans des logiciels commerciaux.


10. Stéganographie

Niels Provos a également réalisé un logiciel de détection de stéganographie, stegdetect, dans les images JPEG. Le logiciel fonctionne de manière distribuée sur plusieurs machines et utilise des attaques par dictionnaire sur les images. Il a amélioré les techniques d'intégration de stéganographie dans les images et l'a implémenté dans Outguess, le principal logiciel libre de stéganographie sur Internet, dont il est l'auteur.

Pour en savoir plus :


11. Réponse aux incidents

Comme chaque année à Usenix, Cory Cohen du CERT/CC a présenté les statistiques de l'année. Les augmentations demeurent impressionnantes. Je vous invite à les visiter sur http://www.cert.org/stats/cert_stats.html. Suite aux rumeurs de transformation en service commercial je rappelle que le CERT/CC est financé par le gouvernement américain et qu'il agit comme un service public. Le CERT/CC a proposé un dîner durant la conférence, mais dans l'objectif de recruter, pas de proposer ses services.

Roman Danyliw du CERT/CC a présenté ACID (Analysis Console for Intrusion Databases). ACID est une console de détection d'intrusion, qui permet des analyses en temps réel d'alarmes. Les alarmes peuvent être issues de journalisation d'applications ou de firewall, mais principalement du logiciel de détection d'intrusion Snort. ACID est un ensemble de scripts PHP sur un serveur web Apache, avec une base de donnée MySQL. Il est possible de faire des recherches sur n'importe quel critère, de grouper des évènements, de faire des statistiques, etc. L'intérêt d'ACID par rapport à snortsnarf est qu'il permet de corréler des informations depuis diverses sources. ACID est disponible en logiciel libre.

Pour en savoir plus :


12. Code Red

David Moore de CAIDA a proposé des statistiques Sur Code Red II. D'une part le trafic généré par Code Red suit les heures de bureaux des fuseaux horaires, et d'autre part la répartition statistique des adresses IP dans les sous-réseaux et dans le temps, montrent selon lui que la majorité des machines infectées appartiennent à des utilisateurs qui ne savent pas qu'ils ont IIS qui tourne sur leur machine, et qu'une même machine infectée apparaît plusieurs fois, car elle change d'adresse IP.

Il s'est arrêté là, je me risque à poursuivre en concluant que les principales victimes de Code Red sont les PME-PMI utilisant des connexions avec des adresses IP dynamiques aux heures de bureau.

Pour en savoir plus :


13. Sécurité matérielle

Peter Gutmann (IBM) a rappelé que la rémanence existait aussi dans les composants électroniques, notamment dans le cas de petits équipements spécialisés qui manipulent peu de données, il faut prendre garde au stockage des clés secrètes et éviter les mémoires non volatiles, le stockage toujours au même endroit et les EEPROM intelligentes qui ont une forme de système de gestion mémoire intégré.

Josyla Rao (IBM), après avoir tenté des attaques par l'alimentation électrique sur les cartes à puce, se consacre désormais aux attaques électromagnétiques, beaucoup plus efficaces. Il a réalisé ses tests sur cartes SIM de GSM, en reprenant des techniques issues de Gemplus. Les 5 minutes alloués par la session "work-in-progress" ne lui ont pas permis de détailler les résultats obtenus.


14. Autres sujets

D'autres présentations ont traité aussi des cartes à puces, de la sécurité des systèmes d'exploitation des PDA comme PalmOS pour le Palm-Pilot, où des recherches se poursuivent, de la gestion des mots de passe, etc. Je sélectionne celle ayant suscité l'intérêt des participants.

Dans le domaine de la distribution des clés, des PKIs et de Kerberos, la présentation de Dan Boneh intitulée "Fast revocation of public key certificates and security capabilities" a suscité beaucoup de questions aux termes desquelles sont principe semble avoir été validé par l'assemblée.

Pour en savoir plus :

La sécurité dans la programmation a fait l'objet de plusieurs présentations, sans innovation majeure cependant. Certaines ont proposé des aides et des outils pour lutter contre les débordements de buffer et les format strings, ou pour permettre un effacement sûr des données.

Pour en savoir plus :

Sun a proposé en soirée plus de 2 heures de présentations et de débat sur la sécurité chez Sun. Un dialogue et une ouverture exceptionnels, où le processus de fabrication des correctifs de sécurité a été explicité. La soirée était animée par Alec Muffett, Sun UK, avec une douzaine d'experts sécurités de Sun : Keith Watson, Sun Colorado, un des principaux auteurs sur www.sun.com/security, Casper Dik, Pays-Bas, Warren Beller, sécurité Java, Valérie Bubb, de l'équipe de développement de SunScreen à Menlo Park, Wolflang Ley, Allemagne, Lance Spitzner (Sun Professional Services), etc.

Pour en savoir plus :


15. SDMI/DMCA

Il est difficile d'assister à Usenix Security sans traiter de ce sujet, qui a sans doute permis d'atteindre les 650 participants, qui a imposé de diffuser sur Internet en direct une présentation, et a fait venir plusieurs journalistes y comprit une caméra de télévision... Le DMCA (Digital Millennium Copyright Act) instaure un copyright sur la musique aux USA. Durant 3 semaines en septembre-octobre 2000 l'industrie du disque a invité la communauté à casser son système ayant pour but de tracer la musique : le challenge SDMI (Secure Digital Music Initiative). Leur objectif est de lutter contre la copie de musique : quand un utilisateur copie la musique il perdrait la trace spécifique à un original. Le professeur Ed Felten a expliqué comment ils avaient cassé les propositions, pourtant sans avoir aucune information sur le système, mais surtout rappelé que construire un tel système était conceptuellement vain et que l'erreur vient de ceux qui ont fait croire à l'industrie du disque qu'un tel système était possible. Pour repérer et détecter le tatouage (watermark) dans la musique, les techniques sont celles de la détection de stéganographie : il y a des échos cachés dans la musique, qui sont inaudibles par une oreille humaine, mais détectables par des analyses plus poussées, utilisant le fait que ce ne sont pas des échos naturels. Un des systèmes utilisait un brevet librement disponible de la société Verance (anciennement Aris) US patent #05940135, et plutôt qu'un système de corrections d'erreur les traces étaient répétées 5 fois (80 bits pour stocker 16 bits), etc.

Usenix et l'EFF ont gagné leur procès contre l'industrie du disque par abandon des poursuites par la partie adverse pour que cette présentation ait lieu. Cependant la communication des logiciels développés à l'occasion et d'autres papiers restent bloqués par les menaces et les procès que l'industrie du disque fait aux scientifiques et universités, même quand ils ont des applications dans des domaines sans rapport avec la sécurité et la musique, comme des applications en médecine.

La présentation technique a été suivie d'un long débat politique. Impossible de passer à côté d'autres cas explicités dans ce débat comme celui de Dimitry Sklyarov, emprisonné aux USA pour avoir expliqué dans un papier comment fonctionne la sécurité dans le logiciel e-book d'Adobe.

Le contrôle et la diffusion de l'information en sécurité et la sécurité par l'obscurité demeurent malheureusement et douloureusement d'actualité.

Rob Johnson a présenté un sujet similaire : comment il a cryptanalysé HDCP (High-bandwidth Digital Content Protection System).

Pour en savoir plus :


16. Conclusion

Usenix Security Symposium demeure la conférence la plus complète et la plus enrichissante. Un tournant majeur de Usenix cette année, est l'apparition de présentations commerciales : Mazunetworks, Lumeta, @stake, WireX, etc. Le niveau d'ensemble est bon, et les sujets ont des applications concrètes pour la mise en oeuvre de la sécurité dans l'entreprise.

Hervé Schauer

Remerciements à Denis Ducamp pour sa relecture.


Annexe : Acronymes

CAIDA
Cooperative Association for Internet Data Analysis
Voir : http://www.caida.org/

EAP
Extensible Authentication Protocol (RFC 2284)

IEEE
Institute of Electrical and Electronics Engineers
 : http://www.computer.org/standards/ et http://standards.ieee.org/

IKE
Internet Key Exchange (RFC 2409)
Voir : Dynamic Management of the IPsec Parameters: The IKE Protocol et IPsec: a technical overview

GTP
GPRS Tunneling Protocol
La définition du protocole n'est pas disponible publiquement.
Voir GPRS from IP security point of view

SCTP
Stream Control Transmission Protocol (RFC 2960)
Voir : http://www.sctp.org/

SDMI
Secure Digital Music Initiative (consortium des éditeurs de musique et fabricants d'équipements de lecture de musique)
Voir : http://www.sdmi.org/ : Le site n'existe plus.

WECA
Wireless Ethernet Compatibility Alliance, consortium des fabricants de matériel conforme à la norme IEEE 802.11b, qui possède le label WiFi, réalise des tests d'interopérabilité et fait la promotion de 802.11b.
Voir : http://www.wirelessethernet.com/

WEP
Wired Equivalent Privacy
La définition de WEP est dans la norme IEEE 802.11
Last modified on 7 November 2007 at 16:30:33 CET - webmaster@hsc.fr
Mentions légales - Information on this server - © 1989-2013 Hervé Schauer Consultants