Using rsync

May 6th, 2009

I spent a bit of time playing around with rsync.

As an old machine (in 2.6.25, there is bug reported against 2.6.24, but it still is doing it) is regularly reseting the USB interface under heavy load, I wanted a solution checking out that file transfered are correct. rsync is doing a checksum control on each transfert.
So here is a small tip with what I am now using. I’ll add an alias to my Zsh.

Be warned that using rsync on a machine with cyphered volumes is putting an heavy load on the machine…

Tags: , ,
Posted in Documentation, SysAd | Comments Off

Using another usbstick to boot

April 27th, 2009

A quick post copying part of my previous post about Grub21.

I just added a few precisions while re-testing those notes.

1. Use case

The goal is :

  1. being able to use another usbstick than the dedicated one.

Your crafted Grub2 configuration on your dedicated usbstick is using the option search –fs-uuid –set <UUID>. So, when booting in your (fully encrypted) hard drive the first stage (I do not know if it is the first or 1.5 one) is looking for this UUID. And, of course, it doesn’t find it as you plugged another usbstick.

2. Variables

  • <dev_hardisk> [/dev/sda] : device of the main hard disk, fully encrypted and used to boot

  • <dev_usbstick> [/dev/sdb] : device of the usbstick used to boot

  • <dev_usbstick_bootpartition> [/dev/sdb1] : device of the partition on the usbstick hosting the /boot partition

  • <id_bootpartition> [1] : id of the partition on the usbstick hosting the /boot partition. On my usbstick it is not the first partition as the first one is a FAT one dedicated to Windows that is unable to read a partition if it is not the firt one (on a removable mass storage)

  • <uuid_usbstick_bootpartition> [46521b2b-b510-486c-bdef-ed62z0053c11] : UUID of <dev_usbstick_bootpartition>

  • <dir_mount_usbstick_bootpartition> [/media/tmp] : directory where <dev_usbstick_bootpartition> is mounted

  • <dev_root_kernel> [/dev/mapper/vg_main-lv_slash] : the root device to which initrd pivots once is has done its job (including the opening of the cryptocontainer). In this case, I am using LVM on top of the cryptocontainer with one volume group and several logical volumes. FIXME- add the default naming convention of Debian -FIXME

To get <uuid_usbstick_bootpartition> value :

$ sudo vol_id --uuid <dev_usbstick_bootpartition>
46521b2b-b510-486c-bdef-ed62z0053c11
$

3. To boot a machine when its dedicated boot usbstick is lost

As Grub2 is not finding the UUID of the dedicated usbstick it should get the /boot directory from, it switches to rescue mode.

Grub2 shell
[…]
grub rescue> set                                               <1>
grub rescue> prefix=UUID=<uuid_usbstick_lost>/grub             <2>
grub rescue> root=UUID=<uuid_usbstick_lost>                    <2>

grub rescue> set root=hd1,<id_bootpartition>                   <3>
grub rescue> set prefix=(hd1,<id_bootpartition>)/boot/grub     <3> <4>
grub rescue> set                                               <5>

grub rescue> root=hd1,<id_bootpartition>
grub rescue> prefix=(hd1,<id_bootpartition>)/boot/grub
grub rescue> insmod /boot/grub/normal.mod                      <6> <7>
grub rescue> normal                                            <8>

grub> insmod /boot/grub/_linux.mod                             <9>
grub> insmod /boot/grub/linux.mod                              <9>
grub> linux /boot/<machine_name>/vmlinuz-2.6.28-1-amd64 root=<dev_root_kernel> ro quiet <10>

grub> initrd /boot/<machine_name>/initrd.img-2.6.28-1-amd64    <11>
grub> insmod /boot/grub/boot.mod                               <12>
grub> boot                                                     <13>

  1. Let see what variable are set to which value

  2. Two variables are set to the UUID of the partition hosting the Grub2 on the lost usbstick

  3. Set new value for root and prefix variable according to the usbstick used to boot

  4. Parenthesis for the prefix variable are not mandatory. Actually, the whole step is optional

  5. Check out which variable are set to which value ; values just set should be displayed

  6. Load the normal module

  7. There is no completion as the shell is the rescue one. Basic completion will work once in the normal mode

  8. Grub2 is now switching to normal mode

  9. Load the Linux modules. This adds the following commands to the shell : initrd and linux

  10. Set the Linux kernel command and launch it. You better know the mounting point of your encrypted volume for slash (/). By default, if installed with Debian Installer (DI), this is the partition name (such as sda1) with _crypted as a suffix (sda1_crypted). If you are using LVM, I do not remember DI default naming scheme

  11. Set the initrd command and launch it

  12. Load the boot module

  13. Actually launch the boot process

Enjoy !

  1. Notes about using Grub2 during the boot process [↩]

Tags:
Posted in SysAd | Comments Off

Ebios training

April 10th, 2009

I attended a few weeks ago an Ebios1 training by the DCSSI2.
Quite interresting and rather good trainers.
My notes are available here.
Oh, by the way, that’s in French… ;)

  1. http://en.wikipedia.org/wiki/EBIOS [↩]
  2. a href=”http://fr.wikipedia.org/wiki/Dcssi”>http://fr.wikipedia.org/wiki/Dcssi [↩]

Tags: , ,
Posted in Security | 2 Comments »

Building Zsh completion… at least, trying…

April 10th, 2009

Last week, I spent four days with a goal ; write Tripwire completion file for Zsh.
I have been working with Zsh version 4.3.2 (actually, I took those notes a few… months ago).

Short version

I failed. After discovering Zsh completion system and regex & globing, I have been unable to get the command getting automatically commands and subcommands, as it is done for Aptitude or Subversion.
See below, for references and what I have done, if it can be useful.

Long version

1/ “Dumb” way

I have been able to write a completion configuration for a script I wrote1. But, this is a “dumb” version one, as I wrote all options in the file. If something change (new or modified option), this configuration file must also be changed.
To do that, I used2 and3.
I produced a commented version of Figlet completion configuration4. This configuration has changed a bit since LinuxMag used it for its article[2].

2/ “Smart” way

The smart way to go is to write a command that get sub-commands and/or options directly from the program –help. Hence, the maintenance of the completion configuration is minimal.
This is the way used by completion configuration of such program as Perforce5, Subversion6 or Aptitude7. I tried to understand the inerworking of this “smart” way of doing completion by reading thoses configurations.

I produced a commented version of Subversion and Aptitude completion configuration. Actually, what I commented is the command getting the result of –help to produce the array awaited by the _arguments or _description functions. It was a way for me learning Zsh language.

Hoping it can help others producing completion configurations.

3/ Documentation used

As already mentionned, I read the LinuxMagazine article “Writing Zsh Completion Functions”[2], quite good to write simple completion configurations.
For advanced configuration, the Perforce completion and configuration is commented (I found no other). Moreover, chapter 6.8 of “A user’s Guide to the Z-shell”8 is dedicated to writing advanced completion configuration based on Perforce case.
The “Zsh Reference Card”9 is a must have to help in the command jungle of zsh.
To finish, ‘man zshcompsys’ is the way to go… Good luck !

Now, what I think after spending a bit of time on that matter, is that there is a (very) few (very) bright people actually knowing the gory details of Zsh (and able to use its – huge – potential) and the vast majority is merely taking / copying what these people are doing, often, without even understand a single bit of what they are taking. And I am still part of the vast majority, even if I understand a bit more of Zsh now ! ;)

—
[1] – https://svn.timetombs.org/svn/tagpix/dev/trunk/_tagpix
[2] – Writing Zsh Completion Functions, Linux Magazine, 20020715, John Beppu
[3] – /usr/share/zsh/4.3.2/functions/Completion/Unix/_figlet, on Debian
[4] – https://svn.timetombs.org/svn/zsh/_figlet
[5] – /usr/share/zsh/4.3.2/functions/Completion/Unix/_perforce
[6] – /usr/share/zsh/4.3.2/functions/Completion/Unix/_subversion
[7] – /usr/share/zsh/4.3.2/functions/Completion/Unix/_aptitude
[8] – http://zsh.dotsrc.org/Guide/zshguide06.html#1177
[9] – http://zsh.sourceforge.net/Refcard/

  1. https://svn.timetombs.org/svn/tagpix/dev/trunk/_tagpix [↩]
  2. Writing Zsh Completion Functions, Linux Magazine, 20020715, John Beppu [↩]
  3. /usr/share/zsh/4.3.2/functions/Completion/Unix/_figlet, on Debian [↩]
  4. https://svn.timetombs.org/svn/zsh/_figlet [↩]
  5. /usr/share/zsh/4.3.2/functions/Completion/Unix/_perforce [↩]
  6. /usr/share/zsh/4.3.2/functions/Completion/Unix/_subversion [↩]
  7. /usr/share/zsh/4.3.2/functions/Completion/Unix/_aptitude [↩]
  8. http://zsh.dotsrc.org/Guide/zshguide06.html#1177 [↩]
  9. http://zsh.sourceforge.net/Refcard/ [↩]

Tags: , ,
Posted in Documentation, SysAd | Comments Off

Booting secured systems with one usbstick ; playing again with Grub2

March 17th, 2009

Few notes taken after a day and a half fighting with Grub2.

Use case

The goal is simple :
1. having systems with hard disk fully encrypted, therefore having a /boot partition on another media ;
2. having a usbstick allowing to boot several systems including a live one (GRML) and a Debian Installer.

To boot a system with hard disk fully encrypted there are two solutions :
1. starting the boot on the hard disk and use a usbstick for hosting /boot ;
2. booting on the usbstick.

The decision is yours. It is decided either

* in the bios ;
* or at the boot time by hitting a key (such as , F12 or F2, for example).

It is easy to have a dedicated boot usbstick for each machine having a totally encrypted hard disk. It can be handled at the installation time (just tell to Debian Installer to use the usbstick volume for the /boot mount point).

It is easy to build a bootable usbstick with the Debian Installer or any live system.

My goal was to mix both as usbstick are quite large nowadays :

* if any of my fully encrypted hard disk machine was booting on its hard disk, it had to find its /boot on the usbstick. The same usbstick for all those machines ;
* I wanted to be able to boot any machine with the same usbstick and choose to boot a live system or the Debian Installer or any kernel/initrd of any of the fully encrypted machine.

Here is the whole process I followed to reach that goal :

1. create a bootable usbstick : see § Usbstick boot ;
2. get its UUID (it will be useful at some point to know it) : see To get UUI D value ;
3. create a directory for each fully encrypted disk in the usbstick /boot directory and copy into it the kernel and initrd of the machine ;
4. edit the file boot/grub/grub.cfg on the usbstick and create an entry for each machine ;
5. re-install Grub2 on each fully encrypted machine so that it knows the /boot has changed (from a dedicated usbstick to a mutualised one that can boot itself) : see § Hard disk boot / With a mutualized usbstick.

To read more just click here : Notes about using Grub2 during the boot process

Tags: , , , , ,
Posted in Configuration, Documentation, SysAd | 1 Comment »

c&esar 2008 — compte-rendu

January 14th, 2009

Début décembre avaient lieux les journées du Celar : C&ESAR. Le thème 2008 était : « Informatique… de confiance ? ».

Ces notes sont la retranscription des notes prises par Yves-Alexis, Delphine et moi-même.

Elles ne sont qu’une vue (parfois très) partielle des présentations. Reportez-vous aux présentations mises à disposition par le CELAR. Ces présentations ne sont elles-mêmes qu’une synthèse sans les aspects les plus gore des papiers publiés dans les actes.

Les parties Avis / commentaire n’engagent que moi.

Enfin, toute erreur dans ces notes est mienne.

Et pour finir, les actes prennent le temps d’expliquer plein de choses qui sont jugées connues lors des conférences.

1. Introduction – Économie numérique 2025 : Sécurité, sûreté et confiance

Alain Bravo – Supélec

1.1. Notes

Redéfinir les priorités politiques wrt. STIC

Objectif : dépasser 2012

Décomposition du système économie numérique en cinq composantes (contenant au total 43 variables) :

  1. technologies déterminantes pour l’avenir
  2. marché
    • échanges mondiaux, biens et services (93 % PIB mondial)
    • secteur de l’économie numérique (7 % PIB mondial)
  3. réglementation, régulation
  4. contexte socio-économique
  5. usages
    • des personnes
    • des entreprises et organisations, publiques et privées
    • spécifiques de la puissance publique

1.1.1. Technologies déterminantes

  • conception et design
  • cognitives
  • sécurité et contrôle
  • intégration des réseaux (Internet) et systèmes
  • mobilité / ubiquité / systèmes embarqués
  • économie d’énergie
  • interfaces systèmes à systèmes
  • nano-technologies

1.1.2. Marché

  • échanges mondiaux
    • secteurs potentiellement compétitifs
    • flux des échanges mondiaux (produits et services numériques)
    • contrôle et fiscalité des échanges de services numériques
  • secteur de l’économie numérique
    • secteurs potentiellement compétitifs du secteur TIC
    • modèles économiques
    • nouveaux entrants et nouveaux marchés
    • stratégies des puissances publiques

1.1.3. Réglementation, régulation

  • périmètre du service universel
  • standards, normes, interopérabilité (y compris des contenus)
  • sécurité, confiance dans les transactions, gestion des données privées
  • sûreté et régime de responsabilité des TIC (impacts sanitaires potentiels, cf. ondes radios)
  • droit commercial, de la concurrence, immatériel (propriété intellectuelle)
  • gestion des ressources TIC (fréquences, positions orbitales, nommage…)
  • problème de gouvernance entre monde réel et monde virtuel

Règles du jeu restent encore à inventer.

1.1.4. Contexte socio-économique

  • problème d’individualisation
  • redéfinition des sphères publiques et privées

→ besoin d’interventions dans l’éducation → formations initiale et continue

1.1.5. Usages

  • personnes
    • apprendre, communiquer, divertir, socialiser
    • commercer / acquérir
    • se soigner (cf. dossier numérique médical)
    • gérer et protéger ses identités et ses biens (dont les données)
    • maîtriser les multi-activités (dont se déconnecter)
  • entreprises
    • anticiper, identifier les risques et maîtriser les responsabilités
    • créer et innover
    • produire les biens et les services
    • prospecter, vendre et distribuer
    • puissance publique
    • démocratie et modes d’expression politique
    • sécurité, sûreté, justice et gestion des infrastructures critiques
    • gestion des risques et crises

Dans 17 des 43 variables, les notions de sécurité, sûreté et confiance sont a minima sous-jacentes et elles sont au premier rang dans 5 des 43 variables.

1.1.6. Conclusion

  • Qu’est-ce qu’est la confiance ?
    • penser qu’une entité va réaliser correctement une certaine action dans un certain contexte (« ce que je demande est bien effectué ») ;
    • penser qu’il existe une police de l’économie numérique, qui veille à ce que tout se passe bien, de façon juste et proportionnée.
  • Comment créer cette confiance ?
    • communiquer même si cela est difficile. Un travail est en cours avec des personnes des sciences humaine et sociale (SHS) ;
    • travailler à la réputation des systèmes numériques.
  • En qui avoir confiance : homme ou machine ?
    • il faut construire une confiance entre homme, machine et réseau en s’assurant que les machines et les réseaux aient un bon niveau de sûreté ;
    • mais on ne peut pas enlever le facteur humain.

1.2. Avis / commentaire

C’est bien ces approches haut-niveau et hors technique. On se demande juste si parfois c’est effectivement lu par des décideurs non-techniques ou si c’est juste pour faire croire aux techos qu’ils ne sont pas tout seul à ramer…

2. Trusted computing : objectives and roadmap

Martin Sadler – HP Labs Bristol

2.1. Notes

Trusted Computing Group multiple views about security (MS, Intel, IBM, HP, Dell…). Might be a little confused.

2.1.1. Timeline

  • start mid 90s
    • “smartcards”
    • secure Linux
    • lead into TCPA
    • concerns over control and ownership of the platform
  • ’00s
    • TCPA → TCG
    • virtualization
    • openTC
  • choice between servers, printers, PCs

2.1.2. Context & Risks

  • challenges
    • dependences on ICT
    • organized crime
    • changing threats social networking firmwares (software everywhere: cars etc.) + mobility
    • Moore’s law for surveillance
    • the pace of change
  • limits
    • how software are produced ?
    • how system are designed ?
    • how solutions are deployed ?
    • security mechanism
    • economy of security
  • need to consider the whole lifecycle

2.1.3. Where should we focus ?

  • server: utilisation, green IT, cloud computing
  • consumers: struggle to understand online privacy, trust & security
  • HP:
    • clients → collaboration → servers → assurance → homes
    • attestation rather than authentication
    • it should “just work” and people shouldn’t worry about security
  • start by getting clients “right”
    • devices = single clients, network centric
    • supporting multiple persons on a device (VMs, appliances, jails…)
    • virtualising the TPM
    • multiple profiles on the same device (personal/business)
  • rapid evolution of personal services
    • cloud services
    • devices convergence
    • trusted virtualization (one physical device, multiple logical ones)
  • multiple worlds on the device
    • freedom and highly controlled environment
    • ability to introduce new services rapidly
    • business continuity
  • changing assurance requirement
pre-SOX world SOX world
critical reviews ongoing assurance
historical based strategic
intrusive collaborative
adherence to rules
  • understand how much it costs
    • driving security choices from economics
  • trust economics
    • how much I spend on security?
    • can we understand tradeoffs between:
      1. risks
      2. policy
      3. employee compliance
      4. technology enforcement

        → believe in a response by an analytical modelling

  • assurance
    • model based on audit services separated from hypervisor, management and user space
    • handle :
      1. what should we be collected ;
      2. who can see it ;
      3. how it should be collected.

2.1.4. Increasing trustworthliness

  • need to move beyond discuss of :
    • complexity trusted computer base ;
    • good service management ;
    • VM interface management.
  • need to link TPM fonctionalities with :
    • economic model of risk ;
    • automation of policy (and the home) ;
    • monitoring and surveillance ;
    • and the policies of certification.

2.1.5. Roadmap

  • using the market
    • clients > collaboration > servers > assurance > homes
  • should we trust trusted computing?
    • probably not, but no alternative…

2.2. Avis / commentaire

3. Can computer security live with the human notion of trust

Dr. Jean-Marc Seigneur – Université de Genève

3.1. Notes

3.1.1. Intro

  • trust is overused
  • trust in traditional computer security
  • human notion of trust

3.1.2. Trust in traditional computer security

  • security perimeter (external users untrusted, authentification, users trusted)
  • authentication burden
    • multiple security perimeters
  • global computing: constraints
    • no skilled and dedicated admin
    • no worldwide legitimate authority
    • large number of entities

3.1.3. Computational trust

Two main types of trust:

  1. system trust:
    • law
    • insurance
  2. interpersonal trust:
    • direct observation
    • recommendation
    • reputation (can be influenced, worst type of trust)

Trust values:

  • count of positive and negative outcomes (p,n) (cf. ebay)
  • triple, including uncertainty (p,u,n)
  • manually set by the users: 75%

Trust metrics:

  • local → centralized
    • group
    • scalar
  • global
    • distributed
    • centralized

3.1.4. Conclusion

  • Global computing can benefit from computational modelling of the human notion of trust
  • needs to be scientifically evaluated and standardized to be used on a large scale
  • EU project on that

trustcomp.org

3.2. Avis / commentaire

La pire conférence. Je m’attendais à une approche sociologique — ou « sciences molles » de manière générale. Rien n’était défini proprement, les modèles ultra-légers. Sans parler du catalogue de .com ayant essayé de se lancer sur ce secteur…

Nul.

4. Multiniveau : problématique, solutions et axes d’études

David Boucart, Sébastien Gay – DGA/CELAR

4.1. Notes

4.1.1. Problématique (besoin et contraintes)

Multiplication des sensibilités d’information:

  • OTAN, Européen, CD/SD/etc.

Existence de deux impératifs contradictoires :

  • besoin d’accéder aux différentes informations
  • mais besoin de compartimenter les différentes informations

Différentes approches :

  • accès simultané et permanent à plusieurs niveaux de sensibilité
  • accès alterné et raccordement ponctuel à des niveaux différents

→ besoin d’accès à plusieurs niveaux (mutualisation des moyens)

  • accès permet consultation/modification mais pas l’échange d’information
  • échanges nécessitent l’interconnexion des niveaux

→ besoin d’échange de données entre plusieurs niveaux (efficacité)

  • confidentialité : no read up (Bell Lapadula, 1975)
  • intégrité : no write down (Biba, 1977)
  • contrôles stricts des échanges entre niveaux.

Multi-niveau : ensemble des mécanismes et architectures de sécurité permettant l’accès et l’échange d’informations entre niveaux de sécurité différents.

Pas de solution miracle générique mais des critères de choix :

  • comparaison des niveaux de sécurité à traiter : plus l’écart est grand, plus la solution doit être robuste. Pas toujours possible de hiérarchiser  « équivalence » des niveaux mais domaines de sécurité distincts.
  • vulnérabilités résiduelles : pas toujours quantifiable précisément. Nécessité de bien cadrer le besoin pour y répondre, sans plus.
  • facteur humain : problématique de l’acceptation de la solution par les utilisateurs.

4.1.2. Solutions

Postes multi-niveaux
  1. pas de mutualisation
    • solution actuelle : un poste par niveau
    • pas très ergonomique
    • meilleures garanties de sécurité si on respecte quelques règles (règles Tempest, périphériques amovibles, respect des conditions d’utilisation)
  2. mutualisation des périphériques
    • KVM
    • attention aux problématiques Tempest
    • « KVM intelligent » disposent d’une logique embarquée, et donc de vulnérabilités supplémentaires
    • périphériques sont communs, peuvent constituer des canaux cachés
    • KVM « sécurisé » (mais à creuser)
  3. mutualisation du hardware
    • solutions « alternées » (multi-boot)
      • problèmes de rémanence des zones mémoire ?
    • solutions « simultanées » (virtualisation / cloisonnement)
      • pas forcément pensées pour des besoins de sécurité et de cloisonnement
      • matériel devrait être contrôlé par hyperviseur, pas toujours le cas (prendre de l’hyperviseur type I qui n’est pas hosté par une instance privilégiée d’OS)
  4. mutualisation de l’OS
    • système d’exploitation multi-niveau (MLS)
    • mécanismes internes (contrôle d’accèsi MAC, labellisation)
    • solution complexe à évaluer
Flux multi-niveaux
  1. réseaux physiques dédiés
    • coûteuse en câblage et points d’accès
    • cloisonnement physique
    • bonne confiance à condition d’être protégé contre les attaques physiques
  2. réseaux virtuels VLAN
    • cloisonnement et non confidentialité (pas de chiffrement)
    • cloisonnement niveau 2 :
      • statique avec vlan par port,
      • dynamique avec 801.1X,
      • statique simultanée avec marquage 802.1q
    • cloisonnement niveau 3 avec labellisation des paquets IP (utilisation des options de sécurité IP)
    • un VLAN pour chaque niveau, sans routage inter-VLAN
    • pas plus mauvais que le physique (i.e. il faut maîtriser la sécurité physique des locaux)
    • nécessite une confiance dans la commutation, label 802.1q, auth EAP et dans la configuration des équipements
    • possibilité d’utiliser un « commutateur de confiance » (machine externe, dédiée)
  3. réseaux virtuels VPN (ipsec / chiffrement niveau 3)
    • protection contre les attaques physiques
    • multiplication des associations et politiques IPsec et des clés
    • quelle architecture pour un chiffreur multi-niveau ?
    • cloisonnement des interfaces rouges d’un chiffreur multi-niveau
  4. réseau unique
    • chiffrement ou marquage applicatif
    • lié à un usage précis et difficile à généraliser
    • dépendant d’une application (et quelle confiance dans l’application ?)
    • comment apposer un marquage sûr sur de l’information ?
    • de façon automatique ?
Échanges inter-niveaux
  1. échanges hors-ligne (support de stockage externe)
    • « pis-aller » mais difficile à utiliser pour faire fuire de l’information à grande échelle
    • nécessite de sensibiliser les utilisateurs
    • support peut être piégé
    • amélioration à l’aide d’un sas de dépollution
  2. échanges uni-directionnels
    • on raccorde, à l’aide d’une diode (physique)
    • intéressant pour la remontée d’information vers un niveau haut
    • très simple, donc confiance assez bonne
    • mais la diode ne protégera pas de code piégé donc nécessite une solution pour protéger l’intégrité du niveau haut (voir sas de dépollution ci-dessus)
  3. échanges bi-directionnels avec contrôle des flux
    • basée sur un firewall/DMZ
    • serveurs placés en coupure sur les flux applicatifs, filtrent le contenu
    • confiance limitée, selon les systèmes émetteurs même avec de la défense en profondeur (flux bien définis, maîtrise des applications source et maîtrise de la sécurité globale du système)
    • pour des échanges entre niveaux proches ou dans un contexte déterminé et relativement restrictif
  4. échanges bidirectionnels avec contrôle des informations : labellisation
    • plutôt pour la descente : « droit de sortie »
    • labellisation + signature de l’autorité ⇒ engagement de la responsabilité
    • passerelle en coupure, vérification du label et de la signature
    • comment s’assurer que de l’information n’est pas cachée ? i.e. labellise-t-on ce qui est visualisé ?
    • quelle confiance dans la passerelle ? (et non du système dans son ensemble comme dans le cas précédent)
    • comment automatiser la solution ? (labellisation, signature, etc.)

4.1.3. Conclusion : architecture et vulnérabilités

  • Solutions combinables (postes de travail, flux, échanges)
  • Implémentation dans la zone de confiance des postes s’ils en ont une ou bien boîtiers dédiés
  • Mécanismes d’échanges peuvent faire partie du poste (zone de confiance) ou bien passerelles dédiées

Mais :

  • quelle confiance dans la zone de confiance ? Que met-on dans la zone de confiance ? En mettre beaucoup réduit la maîtrise que l’on peut en avoir (quid des évolutions ?)
  • comment traiter en pratique les différents formats de données ? Les formats sont de plus en plus dynamiques et nombreux…
  • quelle confiance dans le matériel ?

4.2. Avis / commentaire

Super présentation et synthèse du sujet.

Ils ne sont toujours pas convaincus par SELinux à la DCSSI ;)

5. Quelles confidentialités, pour quelles confidences, et avec quelle confiance ?

Gilles Trouessin – OPPIDA Sud

5.1. Notes

Né du besoin de pouvoir mettre en place une solution fiable et sécurisée d’une version anonymisée du programme de médicalisation du système d’information (PMSI) pour suivre la trajectoire de soins hospitaliers et de remboursement des actes médicaux à la fin des années 90. Une fonction d’occultation d’information nominative (FOIN) a été élaborée à partir du numéro d’identification (NIR) au registre national d’identification des personnes physiques (RNIPP) et de la date de naissance de la personne. Celle-ci permet de générer toujours et partout le même identifiant anonyme pour un individu donné pour quiconque possède l’ultra-secret d’anonymisation.

5.1.1. Définition : vie privée

Notions et périmètres variables :

  • privative
  • publique
  • citoyenne
  • internaute
  • professionnelle

5.1.2. Définition : confidentialité

  • Propriété qui permet de garantir la divulgation des informations de façon autorisée.
  • Nature des informations
    • confidentiel : besoin d’en connaître
    • secret médical : remplacé par le secret professionnel d’ordre médical
    • secret professionnel : obligation de réserve de manière générale. Relève de la déontologie.
    • discrétion professionnelle : respect de l’individu

Dans le cadre du secteur de la santé, la confidentialité est particulière. Elle est au centre de la relation soigné-soignant, appelée colloque singulier. Dès lors, le patient peut confier toute l’information permettant au médecin de soigner complètement et globalement conformément aux bonnes pratiques de son art. Dès lors, les informations recueillies ne peuvent servir intégralement ni aux soins, ni aux remboursements, etc. De nombreux textes s’attachent à bien marquer la distinction entre :

  • la confidentialité-séclusion liée à la confidence du colloque singulier
  • et la confidentialité-discrétion exigée pour toute information rendue non-médicale et utile pour l’administratif ou les statistiques.

Il est donc essentiel de pouvoir distinguer les lieux et contextes d’utilisation où :

  • l’on peut se contenter d’une confidentialité plus ou moins partageable et partagée (et donc en partie réversible) : il s’agit alors de confidentialité au sens de discrétion
  • et ceux où l’on doit imposer une confidentialité unique et absolue (irréversible) : il s’agit alors de confidentialité au sens de séclusion. Hors du cadre déclaré il faut pouvoir garantir l’anonymat.

Distinction de :

  • l’obligation éthique de confidentialité au sens moral du terme : adaptée à la confidentialité-discrétion
  • l’obligation déontologique de confidentialité au sens très formel du terme : adaptée à la confidentialité-séclusion.

Dans le cadre de l’obligation déontologique — à rapprocher de l’exigence de confidentialité classique — on peut assurer la confidentialité par les mesures classiques :

  • juridiques : respect de la loi Informatique et liberté, Code de déontologie médicale
  • organisationnelles : définition (et révision permanente) de la politique régissant les droits et contrôles d’accès aux données
  • technologiques / techniques : définition d’une politique d’identification/authentification adaptée, chiffrement, etc.

Ces mesures s’appliquent à tous les secteurs manipulant une partie des données du soigné. Néanmoins, des environnements ne permettent pas une confiance absolue :

  • lors du passage depuis le cercle soin/médical vers le cercle santé/remboursement ou statistique/épidémiologique
  • lors du passage entre la demande individuelle et l’attente collective.

5.1.3. L’anonymisation

Vaste famille de solutions juridico-technico-organisationnelles qui permettent de rendre peu sensible une donnée hautement sensible auparavant.

Toute la difficulté de la mise en place d’une démarche d’anonymisation consiste à bâtir une solution dont on puisse garantir la robustesse. Robustesse au sens :

  • cryptographique :
    • réelle fonction à sens unique (hash)
  • fonctionnelle et technique :
    • effet d’avalanche ou différentiation
    • reproductibilité dans l’espace : pas de collision
    • reproductibilité dans le temps : pas de doublon
  • à la réversion :
    • directe : dépend de la fonction de hashage
    • indirecte : pas de table de correspondance
  • organisationnelle :
    • secret d’anonymisation : hautement confidentiel
    • chaînage :même anonymisation partout mais attention à la corrélation
    • (double-anonymisation à la source et à la réception)
  • à l’inférence : reconstitution d’information personnelle à partir de croisement d’information anonymisée (inférence par déduction, induction, abduction).

Toutes ces exigences ne sont pas obligatoirement applicable à tous les contextes. Cela dépend de la fonction de base retenue, des acteurs impliqués en amont et/ou aval de la procédure, la nature des données anonymisées, l’ampleur du chaînage, etc.

5.1.4. Anonymisation dans le secteur de la santé

Trois types chaînage pour constituer des trajectoires reliant des épisodes de soin, de santé, de remboursement, sociaux ou d’accidentologie :

  1. chaînage temporel, spatial et spatio-temporel : tous les épisodes sur une période de temps et/ou géographique (attention aux inférences)
  2. chaînage thématique et spécialisé : seuls des épisodes appartenant à une thématique (soin xor médical xor social, etc.), voire à une discipline au sein d’une thématique
  3. chaînage total / partiel / nul : le chaînage n’est fait que par période temporelle et/ou géographique

5.1.5. Conclusion

  • pas de confidence médicale sans confiance singulière
  • distinction entre confidentialité-discrétion et confidentialité-séclusion
  • distinction entre pseudo-anonymisation reversible et véritable anonymisation irréversible
  • distinction entre pure anonymisation sans chaînage et pseudonymisation avec chaînage

5.1.6. Notions de donnée personnelle

  • caractère personnel
  • atomique
  • agrégée
  • pseudonymisée
  • dépersonnalisée
  • anonymisée : suppression définitive (i.e. irréversible) des entités

5.1.7. Divers types de données personnelles et nominatives

  • de nature comportementale

5.1.8. Continuum des données personnelles aux données anonymes

  • directement nominative (état civil)
  • indirectement nominative (numéro de sécu)
  • très indirectement anonymes
  • très, très indirectement anonymes
  • anonymisées
  • anonymes

Beaucoup de textes réglementaires.

5.2. Avis / commentaire

Présentation très intéressante. Touffue ; le fil conducteur n’est pas évident. Il était très difficile de prendre des notes car le fond était dense et rapide (et donc sans fil conducteur explicite). Les notes ci-dessus sont plutôt extraites du papier des actes.

Menée par un passionné qui semble avoir réfléchi en profondeur et en largeur au sujet.

Celui-ci rappelait aussi que dans le cadre de la santé on n’a pas le choix d’être enregistré ou non…

6. Protection des infrastructures vitales

Philippe Wolf – SGDN

6.1. Notes

6.1.1. Dispositif français de protection des infrastructures vitales

  • Protection générale
    • système d’alerte national (VIGIPIRATE) (en rouge depuis les attentats de Londres en 2005). Revu mensuellement pour adaptation mais au sein du même niveau.
    • mesures de protection publiques et privées
  • Secteur d’Activité d’Importance Vitale (SAIV)
    • service indispensable au maintien des fonctions sociétales
    • menaces malicieuses (attentat) et menaces naturelles (pandémie)
      1. évaluation de la menace (premier ministre) → code couleur (niveaux d’alerte)
      2. plans de protections
Pourquoi une réforme ?
  • ordonnance de 1958 (« installation d’importance vitale »)
  • IGI 4600 : points et réseaux sensibles
  • système hétérogène, type guerre froide, trop de points (6 600)
Objectifs des réformes
  • faciliter l’application du plan Vigipirate face aux nouvelles menaces
  • associer les opérateurs privés à l’effort de vigilance
  • sélectionner les points à protéger selon le niveau de menace : protéger plus efficacement des points moins nombreux
  • procédures juridiquement plus solides (plus de poids qu’une IGI)
Contexte international
  • OTAN
  • programme européen de protection des infrastructures vitales (site « siwin »)
    • principe de subsidiarité
    • une nouvelle directive pour le secteur du transport et de l’énergie

6.1.2. Nouveau dispositif en quatre volets

  1. des Directives Nationales de Sécurite (DNS) pour chaque SAIV (20 sur 21 sont approuvées). Chacune est pilotée par un ministère régalien
  2. un Plan de Sécurité Opérateur (PSO) élaboré par chaque Opérateur d’Importance Vitale (OIV)
  3. des Plans Particuliers de Protection (PPP) élaborés par l’opérateur pour chaque Point d’Importance Vitale (PIV)
  4. des Plans de Protection Externe (PPE) élaborés par les pouvoirs publics avec l’opérateur pour chaque PIV
Le nouveau dispositif
  • liste des secteurs d’activité
    • dominante régalienne : activités civiles, judiciaires, militaires de l’État
    • dominante humaine : alimentation, eau, santé
    • dominante économique : énergie, finances, transports
    • dominante technologique : communications électroniques et audiovisuelles, industrie, espace & recherche
  • méthodes d’analyse
Les textes
  • ordonnance du 29 décembre 1958
  • décret du 23 février 2006 relatif aux PIVs
  • trois arrêtés classifiés :
    1. liste des secteurs
    2. méthode d’analyse
    3. plan type des PSO
DNS
  • élaborées par un ministre coordonateur
  • pour un secteur ou un sous-secteur
  • fixent le cadre, les objectifs, en fonction des menaces
  • tiennent compte des inter-dépendances
  • fixent des mesures spécifiques et rappellent les mesures vigipirate

20/21 approuvées

Élaboration des PSO
  1. identifier les scénarii de menaces
  2. conduire une analyse de risque
  3. identifier les PIV
  4. identifier les mesures permanentes et graduées
OIV
  • critères dans les DNS
  • consultation interministérielle
  • consultation de l’opérateur
  • avis de la Commission Interministérielle de Défense et de Sécurité
  • désignation par le ministre (arrêté)

actuellement : 220 dans sept secteurs

Coopération entre opérateurs et autorités publiques, décentralisation

Obligations des OIV
  • désigner des délégués pour la défense et la sécurité
  • rédiger le PSO, à partir de l’analyse de risque, en prenant en compte les DNS
  • repérer les PIV
  • rédiger les PPP
PIV
  • installation, établissement, ouvrage
  • dans un secteur d’importance vitale
  • en cas d’indisponibilité :
    • conséquence grave ou danger grave
Zones d’importances vitales (ZIV)

Ensemble de PIVs proches relevant d’opérateurs différents et interdépendants sous autorité du préfet de zone.

6.1.3. Plans de détection et d’intervention

  • NRBC : piratome, biotox, piratox
  • liés à un milieu : piranet, metropirate, piratemer, etc.
  • sanitaire : pandémie

Tous classifiés, sauf le plan pandémie.

Ces plans sont déclinés au niveau ministériel et local.

Préparation
  • validation des plans
  • formation des nouveaux joueurs
  • exercices nationaux / locaux (quatre par an)
  • retour d’expérience (RETEX)

6.1.4. Communication électronique : un secteur transverse

  • quoi protéger ?
    • téléphonie fixe et mobile
    • transport de données
    • internet
  • acteurs :
    • grands opérateurs
    • FAI
  • spécificités
    • effet dominos
    • PIV
    • toutes les menaces de l’EBIOS
    • difficultés des mesures d’impact
    • fort impact de la compétitivité, dimension internationale
  • interdépendances des secteurs (énergie)
  • beaucoup de points critiques dans les réseaux (liaisons, équipements actifs etc.)
  • paquet télécom : obligation des opérateurs d’informer les utilisateurs sur les mesures de sécurité et sur les incidents

Travaux de la CICREST : guide pédagogique pour aider les services de l’État

Directive numéro 4 MinDef / DGSIC

Lire aussi the ARECI report de l’UE.

Attention aux systèmes SCADA.

Réseaux de souveraineté
  • ISIS : réseau gouvernemental data homologué CD
    • échange et partage en temps réel d’informations qualifiées
  • RIMBAUD : téléphonie

6.2. Avis / commentaire

Excellente présentation et super intéressant.

Comme le disait une personne lors des questions, « si le but des terroristes est de foutre le bordel dans la tête des gens, pourquoi ne pas généraliser ce genre de présentation qui montre que l’on essaie de se préparer, voire d’anticiper ? ». Et je pense effectivement que ce genre de présentation ferait un excellent premier niveau de défense.

7. Assurance et sécurité : Interprétation du vla.4/van.5 dans le domaine du logiciel

Pascal Chour – SGDN/DCSSI

7.1. Notes

7.1.1. Référentiel d’évaluation

Principes directeurs pour accepter/refuser des demandes d’évaluations. Évaluation de la confiance dans la sécurité de produits grâce à des référentiels (CC, CSPN…). Ces référentiels donnent une mesure :

  • sur la façon de développer
  • sur la conformité par rapport aux spécifications
  • sur l’efficacité des fonctionnalités de sécurité (vla/van)

Rappel vla.4/van.5 des critères communs : analyse des vulnérabilités.

7.1.2. Niveaux de confiance

Les niveaux de confiance en critères communs (CC) s’étalent de EAL2 à EAL7 :

  • EAL2 : produit testé structurellement
  • EAL3 : produit concu, testé et vérifié de manière méthodique
  • EAL4+ : le « plus » indique un résistance avancée aux attaques en plus du niveau 4
  • EAL6/7 : van.5
  • EAL7 : conception formelle

Difficulté : estimer le coût.

Pas de définition pour le « basic » : accord tacite.

« Beaucoup de cartes ne résistent pas aux attaques de niveau élémentaire ».

7.1.3. Analyse des vulnérabilités

Schéma d’analyse des vulnérabilités :

  1. vulnérabilité potentielle
  2. tests d’attaque
    • échoue : vulnérabilite potentielle
    • réussite : cotation
      • > niveau visé : vulnérabilité résiduelle
      • < niveau visé : vulnérabilite exploitable

Existence de tables permettant la classification.

7.1.4. Différence d’évaluation de sécurité des cartes à puces par rapport au logiciel

Les cartes à puces sont traitées de façon spéciale (à cause de l’historique, Bull CP8 etc., et de la présence des deux premiers acteurs mondiaux en France).

L’auditeur souligne la sensibilité du secteur des cartes à la sécurité : un peu plus de la moitié des produits sont passés aux CC. Ce qui n’est pas vrai dans le logiciel mais est probablement dû à quelques différences fondamentales :

  1. les cartes sont probablement la catégorie de produit la plus testée. Les logiciels de leur côté se répartissent en de nombreuses sous-catégories. Il est donc très difficile de synthétiser un retour d’expérience ; les schémas d’évaluation pouvant être très différents ;
  2. les cartes évaluées sont en général au niveau VLA4. Les logiciels sont au niveau VLA2 ou VLA3, sauf s’il y a de nombreuses hypothèses simplificatrices qui vident la certification de son sens ;
  3. les profils de protection de la catégorie carte sont peu nombreux. Ce qui n’est pas le cas de la catégorie logiciel où des mêmes types de matériel peuvent avoir de nombreux profils. Donc pas de comparaison possible ;
  4. les acteurs du monde des cartes se sentent concernés par les évaluations. Les éditeurs perçoivent plutôt ça comme la façon de disposer d’un avantage concurrentiel ;
  5. les hypothèses simplificatrices permettent au logiciel d’atteindre quasi-systématiquement la certification de niveau VLA4, de nombreux chemins d’attaques étant mis de côté. Ce qui n’est pas le cas en général pour les cartes ;
  6. la communauté qui travaille sur l’évaluation des cartes est très active dans la spécification des méthodes d’évaluation des cartes. Ce qui permet de définir un état de l’art. Chose qui n’existe pas dans le logiciel ;
  7. le monde des cartes accepte mal le principe « d’erreur de construction ». Ce qui est largement accepté dans le logiciel, au mieux comme une fatalité.

Tout cela pour dire que la certification VLA4 dans le monde du logiciel en particulier mais aussi de manière générale peut être très relative puisque deux produits fonctionnellement identiques peuvent avoir la même certification VLA. Mais l’un grâce à des hypothèses techniques et/ou organisationnelles très fortes, l’autre non.

7.1.5. Illustration

S’ensuivit une illustration présentant une même application, l’une monolithique, l’autre modulaire (schéma dans les actes).

L’idée étant que la conception modulaire inspire une plus grande confiance (à iso-périmètre d’hypothèses) puisqu’intuitivement il est plus difficile de compromettre les autres modules à partir d’une faille dans le premier que dans le cas de l’architecture monolithique.

Mais d’autres cas sont possibles :

  • complexité du produit (notion toute relative, néanmoins) ;
  • le multi-couche : un bug en couche n pouvant invalider des fonctions de sécurité de la couche n+1.

7.1.6. Acceptation des demandes de certification VLA4

Pour éviter des dérives, le but est de fournir des règles (appliquées par les schémas français et allemand d’évaluation). Ces règles sont traduites en huit principes :

  1. la DCSSI peut refuser une demande de certification si elle estime que cela serait trompeur ;
  2. l’architecture du produit doit contribuer à la sécurité en faisant en sorte que les fonctions de sécurité du produit ne puissent être mises en défaut que si au moins deux vulnérabilités distinctes sont exploitées (voir exemple ci-dessus de défense en profondeur grâce à la modularité) ;
  3. les hypothèses sur l’environnement technique doivent être réalistes et en tout ou en partie vérifiables ;
  4. les hypothèses sur l’environnement technique doivent être détaillées. Le développeur doit fournir la preuve du réalisme des hypothèses ;
  5. les hypothèses sur l’environnement organisationnel doivent être réalistes pour le type de produit concerné (on peut avoir plusieurs niveaux) ;
  6. un produit dont la résistance aux attaques de fonction de sécurité VLA4 ne reposant que sur des hypothèses d’environnement n’est pas acceptable ;
  7. une mesure de la complexité du logiciel évalué devrait être fournie et vérifiée par le laboratoire ;
  8. l’existence de compétences couvrant les fonctionnalités de sécurité du produit chez le développeur devrait être validée ;
  9. avant toute demande de certification de niveau VLA4, le commanditaire devrait valider avec la DCSSI l’acceptabilité de sa cible de sécurité.

Des composants TPM sont maintenant évalués : Infinéon et ST. Groupe de travail pour faire la même chose que dans les cartes à puces dans la monétique.

7.2. Avis / commentaire

Présentation claire et facile à suivre malgré la sécheresse des normes abordées. En substance, « dans les cartes c’est bien cadré, tout le monde est au niveau et continue à l’entretenir, on (les laboratoires français et allemand) a réussi à définir un cadre méthodologique qui tient la route et prend le meilleur des CC. Venez pas mettre la bazar en ouvrant la possibilité de certification à des laboratoires qui ne suivraient pas ces règles. Et essayez de les appliquer dans le logiciel, ça lui ferait pas de mal… ».

Les principes me semblent un peu utopiques. Mais plein de bon sens. En tout cas, il est clair qu’il ne faut pas que cela devienne (plus) un outil marketing.

8. Sécurités (safety/security) multi-niveaux en avionique

Yves Deswarte – CNRS/LAAS Toulouse

8.1. Notes

8.1.1. Problématique

  • Constructeurs s’occupent surtout de safety (ils ne laissent pas décoller un avion s’ils ne sont pas sûrs qu’il va atterrir). Mais depuis 9/11 ils s’occupent de security, en particulier vis à vis d’une malveillance (prise de contrôle).
  • Approche multi-niveau « naturelle » :
    • toutes les tâches n’ont pas la même criticité (failure severity)
    • dépend des systèmes, des moments etc.
  • Quelle confiance dans quelles tâches ?
    • validation de la conception (en fonction de la criticité des tâches)
    • validation crédibilité de l’implémentation
    • intégrité (protection des systèmes contre les corruptions)
  • cohérence des niveaux entre « task failure severity » (FSL) et « confidence level » (CL) :
    • pour une tâche : CL(T) ≳ FSL(T)
    • architecture modulaire : contraintes sur les modules
      1. pas de tolérance aux fautes : CL(M) ≳ FSL(T)
      2. tolérance aux fautes : M = Σ(composants redondants) CL(c) ≳ FSL(T) -1 si les défaillances sont indépendantes
  • Isolation et interactions :
    • plusieurs tâches de criticités différentes doivent interagir
    • de façon sécurisée

8.1.2. Solutions

  1. Certifier tous les modules au niveau le plus haut (infaisable)
  2. Utiliser des pare-feux unidirectionnels, diodes (trop restrictif, mais fait en pratique, ex. A380) mais dans certains cas, besoin de contourner la diode (le cockpit peut avoir besoin d’informations venant de la cabine)
  3. Contrôle de flux spécifique (Flow Control Model – Totel 98) :
    • niveaux d’intégrité
    • des tâches de même niveau peuvent communiquer entre elles
    • des tâches de haut niveau peuvent communiquer vers des tâches de bas niveau
    • des tâches de bas niveau ne peuvent pas communiquer vers des tâches de haut niveau (cf. Biba, on peut faire ça avec des diodes)
    • mais certaines tâches ne sont pas critiques en tant que telles (capteurs, qui pris séparément ne sont pas crédibles, mais ensemble, suffisamment de redondance)
    • passage par des objets spéciaux qui vérifient les flux remontants, avec des flux sortants dignes de confiance (éventuellement « rien de confiance ») (validé au niveau qu’elle traite)
    • TCB vérifie que ces flux sont bien les seuls qui transitent du bas vers le haut (validé au niveau le plus haut qu’elle traite)

8.1.3. Exemple : pour la maintenance

  • Plusieurs niveaux de criticité croissants :
    1. Calculateur de maintenance (embarqué à bord de l’avion)
    2. Maintenance
    3. Aircraft Information System
    4. Aircraft Control
    5. Flight Control
  • Tâches ne communiquent pas entre les niveaux
  • TCB contrôle les échanges
  • Complexité inversement proportionnelle à la criticité
  • Diversification par virtualisation :
    • moniteur de machines virtuelles validées au bon niveau
    • hardware validé
    • plusieurs VM, avec plusieurs OS auxquels on ne fait pas confiance séparément, mais qu’on estime sûrs ensemble (difficulté de réaliser les mêmes attaques sur deux OS différents)

8.1.4. Exemple : pilot laptop application

  • Laptop non trusté :
    • utilisé par le pilote (internet, etc.)
    • configuré par les compagnies
    • pré-chargé en données de vol
  • Comment le brancher sur le flight control ?
    • utilisation d’un moniteur de machines virtuelles ? → mais validation au niveau « rouge » relativement impossible
    • passage par un proxy (deux étapes de validation, voire trois)

8.1.5. Exemple : ArSec Project (Airbus-LAAS)

  • Mécanismes de tolérance aux fautes implémentés dans des « Validation Objects »
  • Mécanismes de contrôle de flux :
    • applications
    • passerelles
    • middleware
    • OS
      1. comment être sûr que le même code tourne sur des OS différents, et qu’ils font bien la même chose ?
    • hyperviseur
    • entrées/sorties

8.2. Avis / commentaire

On retrouve plein de concepts liés au MLS avec des cas non seulement concrets mais aussi réels.

Très intéressant.

Et belle présentation, d’autant qu’elle n’était pas prévue.

9. Panorama des architectures informatiques sécurisées et de confiance

Guillaume Duc – Orange/FT R&D Ronan Keryel – Institut Telecom/ENSTB

9.1. Notes

9.1.1. Problématique

En informatique il existe de nombreux angles d’attaques (virus, spam, vol/corruption de données, etc.) car structure en plusieurs couches (matériel, OS, protocoles, applications, etc.).

De nombreux travaux ont été réalisés au niveau logiciel :

  • algos de chiffrements, intégrité, auth
  • protocoles (SSL/TLS)
  • OS sécurisés (micro-noyaux, etc.)
  • logiciels de sécurité

Mais quelle sécurité pour le support d’exécution ?

  • informatique de confiance (TCG) : milieu industriel
  • architectures sécurisées : milieu académique et militaire

9.1.2. Informatique de confiance (TCG)

  • s’assurer que le système informatique se comporte de façon bien définie
  • s’assurer de la résistance à des attaques logiques et quelques attaques physiques
  • exemples d’utilisation :
    • vérification si un système distant est « de confiance » (e-banking, VPN etc.)
    • protection de données locales contre le vol (logique/physique)
TCG
  • produit des spécifications de composants pour l’établissement d’une certaine confiance
  • différents groupes de travail pour les différents domaines (laptops, serveurs, mobiles, virtualisation…)
  • fonctions de base (racines de confiance) :
    • prise de mesures sur des composants susceptibles d’avoir un impact sur la sécurité (BIOS, boot loader…)
    • stockage sécurisé de ces mesures (sécurité physique et logique) et d’autres informations
    • besoin de certifier ces valeurs vis à vis d’un demandeur, y compris à distance
TPM
  • puce soudée à la carte mère (protection physique)
  • mesures incrémentales des éléments intervenants lors du boot
  • rapport des mesures à une entité distante
  • stockage sécurisé, éventuellement lié à l’état de la plate-forme (afin de ne pas le divulguer si l’état n’est pas sûr)
  • prise en compte de la privacy (différentes clés pour différentes actions)
Autres groupes
  • mobile : TPM = MTM
    • plusieurs propriétaires (constructeur, opérateur, utilisateur)
    • secure boot pour garantir la voie radio
  • « trusted network connect »
    • spécifications pour permettre/interdire l’accès à un réseau en fonction de la confiance dans la plate-forme cliente (802.1X)
  • « Trusted Execution Computing »
    • plus large que TPM, étendu à tout le système : protection de l’exécution, des entrées/sorties, de l’affichage, etc.
    • utilise TPM + autres composants protégés :
      1. chipset : DMA
      2. CPU : partitionnement
      3. chiffrement des entrées/sorties (et donc intégration dans les périphériques)
Critiques
  • image sulfureuse (TCPA/Palladium, DRM, Microsoft)
  • fournisseurs de services peuvent décider quels programmes l’utilisateur peut exécuter pour y accéder (qui fait les listes, etc.)
  • compatibilité avec modes de distributions des logiciels libres (recompilation des sources, comment certifier ?)
  • entrave à l’interopérabilité

9.1.3. Architectures sécurisées

Motivations
  • Confiance relative dans le logiciel (OS très gros, etc.)
  • Attaques matérielles possibles :
    • lecture/modification mémoire
    • espionnage des bus du CPU
    • attaques directes contre le CPU
    • moyens importants mais pas irréalisable (cf. MIT/Xbox)
  • Peu de supports d’exécution sécurisés
  • Attaquant = contrôle total (sauf le CPU)
  • Application : cloud computing (peu de confiance dans les nœuds)
    • perturbations (résultats erronnés)
    • espionnage
Modèle de sécurité
  • Il doit :
    • garantir la confidentialité
    • garantir l’intégrité
    • garder des performances raisonnables
Deux grandes catégories
  1. Co-processeurs :
    • environnement d’exécution blindé (smartcards, etc.)
    • problèmes de performances
    • peu évolutif
  2. Exécution de programmes chiffrés, chiffrement de bus
    • tout ce qui rentre dans le processeur est chiffré (rappel : on fait confiance au CPU)
    • interface de chiffrement/déchiffrement entre le processeur et le reste du monde
    • gros ajouts par rapport à un système classique
    • performances très honnêtes (~ 3.8% de perte)
    • Ex : CryptoPAGE
Synthèse
  • architectures sécurisées peuvent répondre aux problématiques de l’informatique de confiance
  • mécanisme d’attestation
  • pas besoin de mesurer l’état de la plate-forme (processus sécurisé ne peut s’exécuter que sur processeur sécurisé)

9.1.4. Conclusion

  • sujet d’actualité
  • nombreuses applications potentielles
  • architectures de confiance déjà disponibles (TPM)
  • augmentation du nombre de transistors (Loi de Moore), possibilité d’en dédier à la sécurité
  • beaucoup de travail restant pour l’industrialisation
  • garder une éthique sur les usages
    • cf. problèmes TCPA/Palladium
    • acceptabilité des technologies
    • perturbation de l’écosystème informatique (renforcement de monopoles, etc. ?)
    • dé-responsabilisation de l’utilisateur, est-ce qu’il reste libre de ce qu’il peut exécuter ?

9.2. Avis / commentaire

Présentation pas inintéressante car reprenant des points présentés dans d’autres conférences. De même le croisement TCG / architecture sécurisée est intéressant.

Néanmoins, et ce sont les questions/réponses qui l’ont fait apparaître, le projet d’architecture sécurisée à la base de cette présentation est complètement « virtuelle » (i.e. rien de concret) : il s’agit d’une architecture dérivée de l’architecture CryptoPAGE testée en simulateur (ce qui n’enlève rien à la performance technique). De manière générale, la moitié des architectures sécurisées présentées sont purement virtuelles.

Enfin, la motivation derrière ce projet d’architecture sécurisée est de pouvoir appliquer les DRM sans risque de reverse-engineering…

Bref, le papier est plus intéressant que le projet lui-même, que je perçois comme plein de vide.

10. Apports de la virtualisation pour une plate-forme informatique de confiance

Sébastien Gay – DGA/CELAR

10.1. Notes

  • réalisation d’une architecture de confiance très difficile (difficile de rendre un OS constitué de millions de lignes digne de confiance s’appuyant lui-même sur des plate-formes physiques dont les mécanismes de sécurité sont pour le moins discutables [voir en particulier la conférence § Quelle confiance dans les composants matériels ?])
  • amélioration grâce à la virtualisation :
    • fonctionnalité de cloisonnement proche du matériel et hors OS
    • possibilité de se placer en coupure d’appels aux périphériques

10.1.1. Virtualisation

Historique
  • vieille technologie (IBM dans les années 60, mainframes)
  • boom depuis 2000
Objectifs
  • abstraction entre matériel et OS
  • plusieurs OS sur une machine physique (partage de ressources physiques)
  • sous contrôle d’un moniteur (hyperviseur…)
Différents principes
  • isolation (chroot, jail, vserver) de contextes d’exécutions au sein d’un même OS. Difficile d’avoir un bon niveau d’assurance au niveau du cloisonnement, difficulté d’auditer tout le noyau (le noyau est commun à l’ensemble des partitions)
  • émulation
    • plate-forme matérielle (qemu) : simulation intégrale de l’architecture. Intéressant mais grosses pertes de performances
    • émulation d’APIs (wine, cygwin) : trop intégré à l’OS hôte
  • virtualisation : partage d’un pool de ressources matérielles, on n’émule que ce qui est vraiment nécessaire
    • même architecture matériel host/guest
    • performances acceptables, bon niveau de cloisonnement
    • bonne solution a priori pour la sécurité
    • pas de développement avec des soucis de sécurité
Virtualiseur
  • abstraction mise en place par un moniteur de machines virtuelles ou un hyperviseur ou virtual machine monitor (VMM)
  • il doit respecter trois principes :
    • équivalence : le comportement d’une application exécutée dans le VMM doit être le même que s’il était exécuté directement sur le matériel → transparence
    • performance : la très large majorité des instructions doit être exécutée directement sur la machine physique sans intervention du VMM
    • cloisonnement : VMM doit gérer l’ensemble des accès au matériel
Différents types de partage des ressources
  • partage temporel de certaines ressources (CPU)
  • partitionnement de certaines autres (mémoire, stockage)
  • gestion de l’attribution des interfaces d’entrée/sortie
Plusieurs types d’hyperviseurs
  1. type I : directement au dessus de la machine physique avec une instance de contrôle
  2. type II : lancé par un OS hôte dont il utilise les services
    • moins bien d’un point de vue sécurité

10.1.2. Fonctionnement de la virtualisation

Le principe dit « trap and emulate » :

  • possibilité d’interrompre l’exécution d’un programme en cas de modification de l’état du processeur
    • exécution d’un code dans un environnement non privilégié
    • interruption lors du passage en mode privilégié, et passage à l’hyperviseur
  • noyau d’un OS
    • besoin de changer l’état du CPU

10.1.3. Application sur l’architecture x86

Quatre niveaux d’exécution (ring) :

  • ring 0 : instructions privilégiées
  • trap & emulate : déplacement du noyau de l’OS virtualisé (ring 1 en x86_32, ring3 en x86_64)
Limites
  • 17 instructions privilégiées qui ne trappent pas correctement si exécutées ailleurs qu’en ring0
  • pas « classiquement virtualisable »
  • pertes de performances importantes dues aux changements de contexte
Solutions
  • traduction binaire dynamique
    • analyse et modification du code à la volée (remplacement des 17 instructions pénibles)
    • permet de faire tourner n’importe quel OS sans adaptation
    • complexe à réaliser, complexe à évaluer, aggrave les problèmes de performances
    • quelques cas difficiles à traiter (codes automodifiants)
  • para-virtualisation (xen, hyper-v, paravirt-ops Linux)
    • OS hôte coopère avec hyperviseur (noyau modifié)
    • hyperviseur fournit une API pour ne pas avoir à appeler les 17 instructions
    • moins de lignes de code, plus facile à évaluer
    • mutualisation des appels aux modes privilégiés
  • virtualisation matérielle (VT / AMD-V)
    • traiter les limitations x86 au niveau de la puce (ajout d’un mode « VMX root »
    • fonctionnalités complémentaires facilitant la virtualisation
    • amélioration des performances
    • mécanismes de sécurité supplémentaire
    • hyperviseur beaucoup plus léger
    • pas de modification des OS
    • besoin d’un matériel adapté
    • niveau de confiance à apporter au matériel plus important et mécanismes dédiés

10.1.4. Vulnérabilités / État de l’art

  • OS virtualisé est soumis aux même menaces qu’un OS normal
  • limite pire, parce que les gens y font moins attention (un OS virtualisé doit donc être sécurisé de la même manière qu’un OS normal)
  • problématiques de détection (cf. analyse des malwares)
    • différences de comportement (analyse temporelle, résultats d’exécution)
  • impossible à rendre complètement transparent
Mise en défaut du cloisonnement
  • entre deux machines
  • entre l’host et le guest
  • entre le guest et le VMM
  • type de virtualisation important (type I en coupure, alors que type II tout est mélangé)
  • mécanismes de communication (vmware-tools, etc.)
  • problèmes d’implémentation
    • mécanisme complexe
    • partage des ressources
    • partage des périphériques
    • nombreux problèmes et vulnérabilités reportés (fuzzing, etc.) (y compris sur des type I)
  • problèmes de conception : pas fait pour la sécurité dès le départ
    • Xen permet l’établissement de canaux cachés entre instances
    • trade-off performances. vs. sécurité
    • augmentation de la taille et des fonctionnalités
    • API généraliste pour tous les types d’OS hôtes
Sécurité matérielle

Hyperviseur repose au final sur le matériel qui peut poser problème

  • DMA
  • bugs CPU et en particulier quid de la documentation de modification du microcode des CPU ?, instructions non documentées, mode de fonctionnement (mode de maintenance SMM, ce mode autorisant un accès complet à la mémoire).
  • détournement de fonctionalités du chipset (même avec des fonctionnalités IOMMU)
  • périphériques (commandes constructeur des disques durs)
  • mémoire rémanente (pas ou peu de documentation sur les protocoles d’accès aux mémoires des écrans, clavier, souris, etc.)
  • firmwares : boîtes (très) noires (et UEFI n’améliorera pas forcément les choses)
Zone de confiance

Besoin d’un OS pour piloter (type I) ou héberger (type II) le mécanisme de virtualisation : cet OS est critique.

  • attention particulière
  • deux optiques
    1. réutilisation d’un micro-noyau minimaliste implémentant uniquement les fonctions souhaitées
    2. réutilisation d’un OS complet durci et sans fonctionnalités inutiles
  • « découpage » de l’OS en domaines
Rootkits à base de mécanismes de virtualisation
  • très à la mode (bluepill etc.)
  • malware se transforme en hyperviseur pour virtualiser l’OS
  • détection difficile
    • depuis l’OS, possible mais difficile
    • virtualiser le plus tôt possible (course)
    • utilisation du TPM (mais virtualisation du TPM ?)

10.1.5. Exemples d’utilisation

  • renforcement de la sécurité d’un OS : isoler certaines fonctions critiques (AV, crypto, I/O sensibles). Deux possibilités :
    1. intégration de ces fonctionalités dans l’hyperviseur (mais augmentation de sa taille et puis il faudrait aussi mettre les drivers)
    2. utilisation d’une zone de confiance avec un OS dédié et minimaliste avec modules de sécurité et drivers (solution plus réaliste)
  • multiplications d’instances invitées (MLS) (généralisation de la solution 2 précédente)
    • une instance par niveau de sécurité
    • voir les actes pour les produits/projets
  • durcissement de serveur : niveau d’assurance moindre puisqu’aux faiblesses liées au matériel, il faut ajouter celles liées au VMM…
  • virtualisation de DMZ (appliances)
    • gain en granularité
    • mais en cas de faille dans le mécanisme de virtualisation, toute la DMZ est compromise

10.1.6. Conclusion

  • technologies « pleine de promesses »
  • cloisonnement local, proche du matériel, plus facile à évaluer que les autres
  • hyperviseurs grands publics pas vraiment développés avec des objectifs de sécurité
  • problématique commence à être prise en compte

10.2. Avis / commentaire

Encore une super présentation. Bien complémentaire des conférences multi-niveau et confiance dans le matériel.

Pas de secret : la virtualisation peut ajouter de la sécurité si le reste est là. Sans être la solution ultime. Mais bien combinée avec du durcissement avancé, ça peut commencer à faire des trucs sympas (un des produits en MLS est en cours d’évaluation EAL6+).

11. Composant cryptographique TPM : retours d’expérience et perspectives

Frédéric Rémi – AMOSSYS Goulven Guiheux – AMOSSYS

11.1. Notes

La trusted computing platform alliance (TCPA) devenue le trusted computing group (TCG) a plus de 130 sociétés membre.

11.1.1. Revue du TPM et services intrinsèques

Composant cryptographique esclave sur carte mère, sur bus LPC (bas débit) et maintenant south bridge dans le ICH10 et bientôt dans le CPU.

Soudé ou non.

Principaux constructeurs : STElectronic, Infinéon, Atmel, Broadcom, Intel.

USD5 pièce.

Très très répandu.

Architecture interne
  • durcissement de la puce
  • module I/O (chiffre/déchiffre les flux)
  • module non-volatile storage : contient
    • la endorsment key (EK) : clé asymétrique dont la partie publique est certifiée par le fabricant. Donc ID unique du TPM
    • la storage root key (SRK) : clé racine dont la partie privée est stockée dans une partie protégée de la mémoire non-volatile et la partie publique est utilisée pour le chiffrement de données ou de clés filles
    • owner authorization data : hash de 160 bits créé (comme la SRK) lors de l’initialisation / appropriation. Sert de mot de passe entre le composant et son propriétaire légitime
  • module volatile storage
  • module plateform configuration register (PCR) : registres de 160 bits permettant de stocker l’état de la plate-forme
  • module attestation identity key (AIK) : les clés AIK ne sont que des alias pour protéger l’EK et peuvent être stockées hors du TPM
  • moteurs cryptographiques : RSA, HMAC, SHA1, RNG
  • communications internes chiffrées
Services intrinsèques
  • unicité de la plate-forme
  • stockage sécurisé
  • création de clés cryptographiques
  • chiffrement/signature (asymétrique)
  • génération d’aléa
Avantages/inconvénients
  • opération crypto et stockage sécurisé de la clé privée dans le chip
  • protection matérielle et logicielle (selon les spécifications…)
  • mais fonctionnement en boîte noire, difficile à auditer (quid du RNG ?)
Utilisations

TCG Software Stack (TSS)

  • communications
  • synchronisation (pas de multi-threading)
  • gestion des clés
  • authentification
  • multi-plate-forme (Windows/Linux)

11.1.2. Service de haut niveau

Mesure de l’intégrité de la plate-forme

Chaîne de confiance depuis la phase de boot : chaque élément effectue des mesures et les vérifie sur son successeur avant de lui passer la main.

  1. CRTM : racine de confiance (premiers octets du BIOS) se mesure lui-même, puis le reste du BIOS, et lui passe la main
  2. BIOS
  3. boot-loader
  4. OS
  5. applications

Mesure ?

  • stockée dans le SML
  • SHA-1 (processus)
  • extension d’un registre PCR
    • permet de chaîner l’ensemble des mesures
    • vérification de l’intégrité du fichier SML

Sécurité du schéma repose sur la sécurité de SHA-1 (collision en 263)

Attestation à distance
  • offre l’opportunité à un tiers distant de vérifier l’état d’une plate-forme
  • principe de challenge/response (envoi des fichiers SML et PCR signés avec une clé AIK)
  • génération pour chaque vérifieur de clés filles RSA, attestation identity key signée (AIK) par EK
  • deux protocoles :
    1. v1.1 : AC privée pour la certification des AIK
      • anonymat (collusion AC privées et vérifieurs)
      • disponibilité, gestion des AC
    2. v1.2: DAA (Direct Anonymous Attestation)
      • protocoles zero-knowledge
Stockage sécurisé, trousseau de clés

Plusieurs types de clés RSA :

  1. signature
  2. chiffrement
  3. scellement / stockage

Certaines clés non transférables d’une plate-forme à une autre (unicité du TPM).

  • Chaque clé est protégée (scellée) par une clé mère
  • Clé racine (SRK, storage root key) peut protéger une infinité de clés stockées à l’extérieur du TPM (chiffrées)
  • utilisation d’une clé peut être conditionnée :
    • passphrase
    • passphrase clé parente
    • état du TPM

11.1.3. RETEX

TrouserS, integrity measurement architecture (IMA), trusted grub, ecryptfs

Expertise technique, temps contraint, aspects logiciels (inspiré du schéma de certification CSPN de la DCSSI).

Trusted grub

boot-loader, mesure de l’OS qui va être lancé ne fait que des mesures, prend pas de décisions (dans la branche testée)

  • se mesure lui-même (stage 1.5 et 2, 1 est mesuré par le bios)
  • fichier de config
  • noyau et initrd
  • possibilité de donner des fichiers à mesurer
  • problèmes de programmation : processus d’extension non-réalisé donc il ne peut pas vérifier l’intégrité du SML
IMA

Patch du noyau Linux fait par IBM

  • mesure automatique à l’exécution (exe, pilotes, shared libs)
  • transparent pour l’utilisateur
  • pas de mécanisme de vérification des mesures vs. une base de référence (pas de prise de décision)
Trousers
  • implémentation libre de TSS (85 % des spécifications de la v1.2 : le DAA/zero-knowledge reste à implémenter)
  • dédié au pilotage TPM
  • stade prototype
  • pas de protection contre les attaques de la littérature
  • API hooking pour récupérer des infos sensibles
eCryptfs
  • couche de chiffrement symétrique FS
  • une clé de chiffrement symétrique par fichier
  • chaque clé est scellée par TPM (y compris au niveau de l’état des registres : le scellement est donc conditionné à l’état des PCR)
  • auth avec TPM non conforme aux spécifications
  • outil d’expert (connaissances approfondies du TPM, registres PCR, etc.)
  • quelques bugs
  • pas assez mature pour de la production

11.1.4. Conclusion

  • Technologie prometteuse pour la sécurisation des architectures
    • services cryptos à bas coût
    • attestation distante avec anonymat
  • Manque de maturité
    • non conformité par rapport aux spécifications
    • problèmes de compatibilité matérielles de certains composants
    • opacité des spécifications (« boîte noire ») et trop haut-niveau permettant trop d’interprétations

Est-il réaliste de partir du principe que les CRTM soient immuables ? (problème d’accès physique à la machine).

La génération RNG en usage interne est noire. Elle est analysée pour la certification qui est faite pour les puces, mais quid des autres ?

Le principal reproche porte sur la partie d’attestation à distance qui peut être utilisée pour empêcher l’utilisation de logiciels « concurrents ».

11.2. Avis / commentaire

Encore une présentation super intéressante. J’avais l’impression de nettement mieux comprendre ce qu’est le TPM et donc une partie des enjeux derrière. Ceci dit, la partie évaluation de la présentation, me laisse le sentiment que tout cela n’est pas encore prêt à être mis en production.

C’est clairement le genre de présentation qui peut aider à faire tomber des a priori.

12. Efficient techniques for securing off-chip memory

Vladimir Kolesnikov – Bell Labs NJ

12.1. Notes

12.1.1. Challenge

  • Hardware operation in hostile environment. Protect against attacker which has full control over the device (cf. iphone, xbox, etc.)
  • Protection of:
    • software and other IP
    • device entrusted secrets
    • integrity of operation of device
  • Enforcement :
    • DRM
    • business model

12.1.2. Solution : system on chip (SoC)

  • assumed infeasible to break inside standard SoC
  • protection of interfaces ?
  • sufficient hardware support to provide :
    • secure boot
    • secure execution with insecure ram
  • but SoC cannot embed enough memory so it must work with off-ship DRAM
Lightweight crypto-based memory controller
  • protect against RE and tampering
  • strong security, minimal hardware overhead
  • rigorous crypto design & analysis
  • very small footprint → FPGA

protection against replay attacks

Design
  • fast, small, suitable for FPGA
  • minimal performance impact
    • no on-chip verification data
    • no hash-tree mac
    • small DRAM overhead (15 %) : each bit of MAC stored in DRAM represents overhead from a user point of view
  • security trade-off (not full protection against replay attacks)
    • heuristics to minimize the risk
  • symmetric equivalent of public key signature
    • secret key to sign and verify
    • cannot sign without secret key
  • None-based MAC
  • PRNG AES-based (output undistinguishable from random)

12.2. Avis / commentaire

Solution probablement intéressante pour un certain nombre de constructeurs.

Le principal de la présentation était de démontrer la faisabilité d’une solution légère et adaptable à des environnements dont le CPU n’est pas un quad-core. Le papier présente toutes les astuces et algorithmes utilisés pour arriver à une solution efficace, voire efficiente.

Je dois reconnaître que passé les dix premières minutes mon attention fut « suspended ».

13. Environnement matériel de confiance et sécurité des protocoles distribués

Céline Burgod – XLIM

13.1. Notes

  • nœud
    • hôte non digne de confiance car sous le contrôle de l’utilisateur : H (hardware)
    • utilisation de plate-forme matérielle de confiance (carte à puce) : TH (trusted hardware)
  • H : responsable des communications entre TH
  • TH possèdent un identifiant unique ID et une clé secrète commune
    • soit permanente et fournie par le constructeur
    • soit obtenue lors de l’entrée d’un nœud dans le réseau et se présente comme un TH valide
  • HMAC en en-tête des messages

Modèle du réseau :

  • nœuds statiques
  • communications sans fil
  • liens symétriques
  • liens fiables (pas de perte de messages)

Objectif : assurer le bon fonctionnement du protocole distribué. Mais assurer l’intégrité de son exécution n’est pas suffisant.

Problème : comment le matériel de confiance peut il avoir confiance dans l’hôte qui l’embarque ? Puisque si l’on maîtrise H celui-ci peut supprimer, fabriquer ou rejouer des messages destinés à d’autres TH.

Approche :

  • détection d’actes non conformes dans les actes d’émission/réception au niveau des couches basses
  • acquittements explicites pour chaque message
  • croisement des informations
  • hypothèse : au moins un nœud avec un comportement conforme

13.1.1. Étude de la transmission d’un message de U à son voisinage

  1. TH génère mu,idu,snu,hmacu (hmacu = (hmac(mu,idu,snu))
  2. mu est transmis à H
  3. TH attend l’acquittement
  4. H diffuse le message
  5. chaque voisin transmet le message à son TH
  6. chaque TH génère un ack id,
  7. chaque TH envoie l’ack à son H
  8. chaque voisin renvoie l’ack à H
  9. H envoie l’ack à TH
  • Difficultés pour identifier de manière précise l’origine d’une faute
  • Mais permet d’avoir des infos fiables sur la qualité du lien entre deux H
    • protocoles de routage
    • réputation

13.1.2. Application dans les réseaux ad-hoc

Soit les nœuds A, B, C, D et E.

Si HB omet de transmettre m à sont TH, THA ne recevra pas d’ACK.

Si HB transmet bien m à THB, qui donc génère un ACK mais que HB ne retransmet pas m ni à A (source du premier message) ni aux autres nœuds (par conséquent THB ne reçoit jamais les ACK de ces autres nœuds et donc A ne peut pas non plus recevoir l’ACKB transmis par un autre nœud), d’un point de vue de THA la qualité du lien entre A et B est mauvaise. Et d’un point de vue THB les liens avec l’ensemble des autres nœuds est mauvais (aucun retour d’ACK).

13.1.3. Coût

En volume, l’utilisation de HMAC ajoute le hash (160 bits pour du SHA-1) plus les ID de séquence et de l’émetteur.

En puissance, le calcul des hash (négligeable pour une carte à puce).

En traffic, les ACK de chaque nœud pour un message augmente significativement le nombre de messages.

En mémoire, puisque chaque nœud maintient en mémoire une table avec les ID de séquence et leur temps d’expiration pour tous les messages en attente d’ACK.

13.2. Avis / commentaire

Présentatrice sous Prozac et probablement un cas d’école en terme de contre-exemple à tout ce qu’il faut faire lors d’une présentation.

Fonds nettement moins intéressant que la conférence (au périmètre beaucoup plus large aussi) sur les systèmes distribués du SSTIC2008.

14. Quelle confiance dans les composants matériels ?

Lorïc Duflot – SGDN/DCSSI

14.1. Notes

Sécurité et confiance dans les composants génériques (processeurs et chipsets).

14.1.1. x86

CPU et Chipset (northbridge + southbridge)

Privilèges :

  • ring0 = privilèges maximum (noyau)
  • ring3 = privilèges restreints (applications)

Base de la séparation espace applicatif / espace noyau, cloisonnement

Mémoire :

  • segmentation (obligatoire) → par processus
  • pagination (optionnelle, mais systématique en pratique) → page de RAM

Les applications n’ont jamais accès aux adresses physiques.

14.1.2. Prise en compte de la sécurité limitée

  • maintien de la compatibilité descendante
  • héritage de fonctionnalités des ancêtres
  • impensable de retirer la moindre fonctionnalité
  • fonctions de sécurité « à la demande » et parfois redondantes
    • assurer la non exécutabilité des données pouvait se faire avec le segmentation
    • mais en fait ça a été fait avec la pagination, avec le flag NX/XD
    • mécanismes concurrents
  • fonctions juxtaposées sans étude de risques liés à l’introduction de nouvelles fonctions
Absence de modèle de sécurité
  • impossible de trouver des analyses de sécurité d’un composant
  • pas de vision globale, à l’échelle de la machine
  • persistence des modes (réel, protégé, 8086 virtuel, system management, ia32e…)
  • mode system management :
    • mode de maintenance privilégié (equivalent ring0)
    • utilisé pour la gestion matérielle
    • chaque événement se produisant sur la carte mère déclenche une interruption qui entraîne l’exécution en mode SMM d’une routine de la carte mère
    • attaquant peut remplacer la routine de traitement de la SMI
      1. escalade de privilèges
      2. camouflage de rootkit
    • mécanismes de contrôle d’accès existent dans le CPU mais sont contournables par des fonctions des chipsets (prouvé)
  • DMA (connu depuis longtemps et exploitable via USB/firewire et contre-mesures peu utilisées)
Complexification des CPU
  • plus d’un milliard de portes électroniques
  • multi-cœur avec partage de cache et de ressources
  • possède des coprocesseurs crypto intégrés (RSA, SHA1, AES)
  • multiples modes de fonctionnement
  • instructions non documentées
    • salc et loadall (permettaient le chargement de tous les registres CPU en un cycle d’horloge)
Chipsets
  • CPUs
  • contrôleur mémoire
  • contrôleur graphique
  • USB, réseau, SATA, etc.
  • manageability engine
    • teχ ASF & AMT
    • remontée d’alarme sur le réseau, administration à distance
    • technologies implantées dans le chipset (https, soap…)
    • en quoi ils seraient moins vulnérables que les logiciels classiques ?
  • fonctions AV dans le chipset (Blackhat, Deepwatch, Yuriy Bulygim)
    • confiance dans le dispositif ?
  • fonctions d’administration, supervision, sécurité directement dans les chipsets
  • code logiciel s’exécutant dans le chipset, niveau de confiance pas supérieur au code de « dehors »
  • toujours plus de fonctions sous prétexte que c’est dans le matériel (« de confiance »)
  • problème de cohérence globale

Changement de paradigme

14.1.3. Impact d’un bug ou piégage sur la sécurité des OS et VMM

  • attaquant: capable d’exécuter du code dans une application non privilégiée (browser par exemple ?)
  • objectifs :
    • discret
    • exploitable avec un minimum de privilèges
    • doit donner les privilèges maximums
    • exploitable dans tous les cas
  • exemple : piège dans l’instruction salc, si le CPU est dans un état particulier (registres)
    • permet de prendre la main car les OS n’utilisent pas la segmentation au maximum de ses possibilités
    • mais marche moyen sur les VMM
  • exécution de code en ring0 ne suffit pas, il faut pouvoir accéder à la mémoire qu’on veut (contournement pagination et segmentation)

En pratique :

  • rapports de bugs Intel/AMD
  • juin 2007, Theo de Raadt (OpenBSD) : bugs sans doute exploitables
  • octobre 2008, Kris Kaspersky FUD, 2 bugs exploitables à distance, 14 localement (aucune démo, proof of concept)

14.1.4. Contre-mesures

  • virtualisation la plus lourde possible (pour éviter les bugs matériels)
  • réduire la surface d’attaque
    • réduire les applications qui tournent
    • supprimer les moyens de compilation/exécution de code (macros)
    • bonnes pratiques de sécurité au niveau réseau
  • redondance de processeurs différents et comparaison comportementale (peu réaliste actuellement)

14.1.5. Conclusion

  • piégeage exploitable assez facile à réaliser
    • quelles que soient les mesures de sécurité au niveau OS/VMM
  • réalité de la menace
  • complexification des matériels

14.1.6. Notes

« Une dizaine de personnes chez Intel doivent savoir comment ça marche ».

Les transitions vers les modes « dangereux » sont spécifiques à la carte mère ; il n’est donc pas possible d’intégrer cela à une politique de sécurité.

14.2. Avis / commentaire

Toujours aussi intéressant.

On attend la suivante ;)

15. Un panorama des techniques de furtivité et de leur détection

Jean-Marie Fraygefond – DGA/CELAR

15.1. Notes

  • malware furtif : compilateur C infecté par un virus. Tout fichier source C compilé avec ce compilateur serait infecté.
  • racine de confiance ?

15.1.1. Définitions

Malware
  • logiciel développé dans le but de nuire à un système
  • « un machin informatique nuisible »
  • Il porte atteinte à :
    • la confidentialité
    • l’intégrité
    • la disponibilité
  • On l’utilise à des fins :
    • d’espionnage
    • de chantage
    • de sabotage
Sphère informationnelle
  • informatique : ensemble des systèmes d’information, de façon très large
  • toute transformation de l’information
  • sphère informationnelle
    • stockage
    • traitement
    • acheminement

Malware peut être tout et n’importe quoi dans la sphère informationnelle (code, thread, processus, application, OS, CPU, machine, sphère)

15.1.2. Les méchants

  • différents niveaux
    • compétences
    • moyens
  • différents objectifs
    • statistiques
  • postures (global/local)

15.1.3. Où il est ?

Du méchant dépend de où on peut trouver le malware

  • rootkit sony
    • installation automatique (autorun)
    • camouflage, modification SSDT
    • finalité = DRM, mais couche de service aux autres malwares
  • bluepill (much ado about nothing)
    • fonctionnalité hyperviseur utilisant virtualisation AMD
    • virtualise l’OS « à la volée »
    • cohabite avec l’OS, n’interagit pas. couche de virtualisation
    • prototype

15.1.4. Détection

Détecter quoi ?

  • code (mais quel type de code ?)
  • quelque chose qui s’installe sans le consentement (impossible à dire)
  • fuite d’information (mises à jour automatiques ?)
  • nuisance ? (notion éminemment subjective)
  • bluepill : bataille d’experts
  • confusion entre détecter de la virtualisation et détecter un malware
  • qu’est ce qu’on sait détecter ?
  • qu’est ce qu’on veut détecter ?

15.1.5. Conclusion

Le malware ultime existe-t-il ?

  • oui → on ne sait pas, car on ne sait pas le détecter
  • non → ouf

Vraie question : peut-on continuer à vivre en sachant ça ?

⇒ question de la confiance (où est le curseur ?)

15.2. Avis / commentaire

La présentation faisait plus rump session que « vraie » présentation. Son contenu est aussi plutôt trivial. Mais le papier est très bien et offre un panorama des techniques de furtivité accessible (allez le lire).

16. Mobile transactions : trust and privacy aspects

Jean-Claude Paillès – Orange Labs

16.1. Notes

16.1.1. Contexte

Mobile = outil à tout faire (identification, paiement, contenus, internet, etc.).

16.1.2. Plate-forme mobile : approche TCG

  • configuration : différences TPM/MTM :
    • MTM peut vérifier les mesures en local
    • protocole de mise à jour des références de mesures
    • car le réseau n’est pas trustable
  • gestion de clés
  • stockage sur TPM

Besoin d’un standard sur le sujet (solutions propriétaires posent de vrais problèmes wrt. confiance et preuve de confiance).

16.1.3. Architecture mobile « trustée »

Plusieurs fonctions sous différents niveaux de responsabilités

  • radio → constructeur
  • réseau opérateur
  • opérations de paiement
  • applications diverses → éditeur

Approche virtualisation : un MTM physique, 4 MTM virtuels (un par responsable).

MTM (TCG de manière générale) assure l’intégrité de l’OS, pas son caractère trusté (intégrité d’une passoire est pas très intéressante).

MTM = petit bout du problème

MTM séparé ou intégré ?

  • séparé :
    • plus simple
    • liaison attaquable
    • packaging compliqué
  • intégré :
    • dur à auditer (CC)
    • liaison sûre
    • packaging plus simple

TCG ∾ EAL3. Or certaines applications nécessitent beaucoup plus de confiance (cartes bancaires sont EAL4+).

Déporter les opérations en question sur un secure element (SE) de confiance (la SIM en général).

⇒ besoin d’un secure channel SIM ↔ plate-forme.

“Global Bootstrap Architecture” : envoi d’une clé commune dans la SIM et dans une cible à côté (après vérification que le mobile est sain).

16.1.4. Privacy

  • mobile = moyen de paiement, accès, identification universel
  • sécurisé
  • mais quid du contenu des données échangées wrt. privacy ? → contactless (NFC)

Éco-système de la privacy

  • réglementation (CNIL, OCDE, CC)
  • publications
  • forums & projets
  • produits

Privacy dans les transactions mobiles ?

  • NFC : connexions doivent être très rapides (300 → 500 ms)
  • pas moyen de contacter un ID provider extérieur dans l’intervalle
  • NFC :pas besoin de données invariantes
    • certaines applications ont besoin d’une identification (CB)
    • certaines autres non (cf. métro ou porte monnaie électronique) : seul un contrôle de droit / propriété / crédit est nécessaire
  • solutions
    • TCG / DAA (Direct Anonymous Attestation, basé sur zero-knowledge)
    • projets européens (PBSS, PRIME etc.)
  • on doit pouvoir repérer une attaque et révoquer les faux
Note :

L’anonymat complet n’est pas vraiment possible, un minimum de traçabilité doit être possible (rôle de la variable γ de DAA).

16.1.5. Trusted Secure Computing (TSC)

  • Consortium d’industriels (EADS, FT, STM, Bull, etc.)
  • basé sur TCG, proposition d’améliorations
  • France, Espagne, Hollande
  • jusqu’à fin 2009
  • Orange : AACA (Anonymous Access Control Application)
  • requêtes fines demandées à la SIM sans dévoiler trop d’information (en fait le strict minimum nécessaire)
    • utilise PBSS (moins coûteux que ZKPK)

16.1.6. Conclusion

  • mobile → potentiel d’usage important
  • gros problèmes de privacy à résoudre très rapidement (anticiper ?)
  • solutions standardisées existent (TCG)
  • France Numérique 2012 ? cf. action 69

16.2. Avis / commentaire

Présentation claire.

Grosso modo, il existe, a minima, des pistes permettant de faire d’un téléphone mobile un véritable couteau suisse digne de confiance et respectant la « privacy » mais il n’y a guère de motivation autre que la peur d’un clash futur.

17. Panorama of secure contactless communications

François Vacherand et al. – CEA/LETI

17.1. Notes

17.1.1. Introduction

RFID :

  • identification de personnes (coopératif)
  • identification de produits
  • bandes de fréquences normalisées (il en existe cinq mais une seule pour les cartes à puce)

Carte à puce :

  • particularités du lien sans contact :
    • distance ~ 10 cm
    • alimentation de la carte
    • singulation / identification / inventory des objets dans le champ (concurrences d’accès)
  • trois fonctions : power+clock+data
    • pas de bouton on/off, uniquement par entrée dans le champ à 13.56 MHz
  • bases de sécurité :
    • confidentialité
    • identification (mutuelle)
    • intégrité
    • disponibilité
  • caractéristiques majeures :
    • passif (pas d’énergie embarquée, donc pas de moyen de défense)
    • low power
    • low resources (pas de MIPS sur les tags qui s’étendent de quelques microW à quelques dizaines de miliW pour les plus grosses)
    • low cost : trade-off security/cost
    • one reader, many tags → dispositifs anti-collision

17.1.2. Menaces

Deux grandes catégories de menaces :

  • économique (fraude, etc.)
  • privée (espionnage, traçabilité de la personne, etc.)

Vulnérabilités :

  • over the air communications
  • over the air power
  • over the air clock
  • passive devices (sans défenses)
  • no on/off switch
  • load based retro-modulation
  • singulation protocol (anti-collision)
  • “kill command” (désactivation de l’étiquette)

Menaces :

  • hypothèse souvent admise : carte/tag dans le champ du lecteur (cf. attaque par proxy, antennes, etc.)
  • substitution d’objets (carte ou reader)
  • RF jammers (dispo)
  • perturbations RF (power, data, clock)
  • destructions d’antennes (résonance)
  • écoute
  • skimming (activation non voulue)
  • analyse de la consommation par retro-modulation
  • utilisation malicieuse de la “kill command”

17.1.3. Attaques

Trois grandes familles d’attaques :

  1. passive listening : analyse de la consommation de la carte (nécessite un laboratoire)
  2. remote activation : attaque relais, injection de perturbations
  3. DoS : jammer, blocker

Grandes attaques :

  1. eavesdropping
  2. RFA (SPA-DPA-CPA through RF Channel)
  3. relay & MITM
  4. injection de faute

17.1.4. Contre-mesures

  • singulation phase : read (U)ID
    • anti-collision based on Aloha protocol
    • binary tree search
  • travaux côté du lecteur (beaucoup plus puissant, beaucoup moins de contraintes)
  • énergie à bord de la puce pour avoir quelques fonctions de défense, détection d’intrusion, effacement de données sensibles.

17.1.5. Conclusion

  • sécurité reste quand même très proche de la sécurité de la carte à puce
  • mais dispositifs très peu complexes, peu de moyens de défense

Il reste des choses à faire :

  • précaution particulière pour les low profile devices
  • improve singulation protocol
  • tests d’attaques réelles
  • robustesse aux DoS
  • standards
  • améliorer la confiance et privacy

17.2. Avis / commentaire

Encore un autre domaine ouvrant plein de nouvelles utilisations possibles mais nécessitant aussi de la confiance. Or la dissymétrie entre les deux acteurs ne facilite pas les choses.

À l’heure actuelle c’est bien l’attaque relais qui reste la plus problématique.

Accessoirement, mettre ses cartes RFID dans un étui blindé coupe court au skimming.

18. EMAN : Un cheval de Troie dans une carte à puce

Jean-Louis Lanet – Université de Limoges

18.1. Notes

18.1.1. Principe

Mettre un cheval de Troie dans une javacard (v.3.0, version restreinte).

18.1.2. Les sécurités dans la carte

  • Java : fortement typé, vérification au niveau du bytecode, pas possible de manipuler les références. Propriétés vérifiées au niveau du bytecode (garantie d’isolation).
  • Firewall : isolation entre les différentes applets de la carte (uniquement au sein de contextes de sécurité ou via des interfaces très spécifiées). Mais cela est seulement valable pour les instances, pas pour les classes (donc pas pour les variables globales).
  • Chargement d’une application uniquement possible en passant par la plate-forme globale et donc prouver qu’on a les droits de chargement (clé de chargement). Applet loading only if authenticated (SCP01).
    • ok sur des cartes de développement

Javacard ~ java sauf que le vérificateur de bytecode est externalisé

18.1.3. Objectif de l’attaque

Cheval de Troie, qui modifie de façon non autorisée une application qui n’appartient pas à son contexte de sécurité Par exemple, supprimer le lancement d’une exception si le PIN est mauvais (au niveau du bytecode)

Le firewall ne peut pas (par construction) vérifier les contextes quand on utilise les instructions putstatic, getstatic, invokestatic (car ça touche des variables globales, de classe).

Reste de la présentation = plan de l’attaque, description du processus, etc.

18.2. Avis / commentaire

Waouh.

Présentation faite par un prof, extrêmement didactique.

Cette attaque, comme les autres attaques de type logique citées, repose sur des faiblesses des spécifications ou des implémentations de JavaCard.

La norme JavaCard 3.0 ne permet plus la réalisation de l’attaque présentée.

19. Trusted software within Focal

François Pessaux et al. – LIP6

19.1. Notes

19.1.1. Problématique

  • présence croissante de logiciels dans les systèmes (firmwares, etc.)
  • questions sur la fiabilité des logiciels ?
  • méthodes empiriques insuffisantes
  • méthodes formelles difficiles (problème du passage à l’échelle)
  • outils séparés → problèmes aux interfaces
  • fiabilité/sûreté/sécurité du logiciel valable à tout moment du cycle de vie

19.1.2. Projet FoCaL

IDE pour le développement de « logiciel de sécurité »

  • langage de programmation
  • langage de propriétés
  • langage de preuves

soit un IDE « formel »

  • outils d’aides à la preuve
  • même outil pour le code et les propriétés → pas de problèmes de ponts
  • modélisation des spécifications à l’implémentation

Donc propriétés et preuve des spécifications à l’implémentation.

19.1.3. Ingéniérie logicielle et philosophie FoCaL

  • cahier des charges → expression des besoins du client
  • spécifications → fonctionnalités sans référence aux solutions pratiques
  • implémentation → solution
  • cahier des charges de systèmes critiques ont des propriétés de « sécurité », exigences
    • propagées ou changées au long du cycle de vie
    • au final doivent être vérifiées / satisfaites
  • FoCaL :
    • déclarations ↔ spécifications
    • construction algorithmiques ↔ implémentation
  • base : espèce, enregistrement (record) regroupant structure de données et opérations
  • modularité
  • opérations (méthodes) :
    • type support
    • déclarations (signatures) = nom + type
    • définitions (let) = implémentation calculatoire des fonctions
    • propriétés (property) = nom + formule logique du 1er ordre
    • théorème = propriété + preuve
    • preuve : preuve retardée de propriétés

19.2. Avis / commentaire

Trop technique pour mes compétences tant en développement qu’en formalisme.

Néanmoins super intéressant. En tout cas pour l’objectif et les moyens mis en œuvre (pour ceux que j’ai compris). J’aime beaucoup l’idée d’utiliser le même langage des spécifications à l’implémentation en étant capable de prouver que l’implémentation répond bien aux spécifications. J’aime bien aussi l’idée que la problématique de l’établissement de la preuve fasse appel à des outils externes déjà existants.

Et cela a semblé intéresser des industriels dans la salle.

20. Digital Rights Management and trust

Éric Diehl – Thomson R&D

20.1. Notes

Quatre couches :

  1. trust management
  2. rights management
  3. right enforcement
  4. content protection

20.1.1. Trust your model

  • tous les pouvoirs à l’attaquant (pas de alice/bob/eve du modèle OpenSSL)
  • Rule n1 : les attaquants gagnent toujours à la fin
  • nouveau types de DRM : contenus en clair, avec tatouage, et observation a posteriori
  • problèmes de privacy
  • si bob se fait voler le contenu, on est dans le vent

20.1.2. Trust your implementation

  1. compliance rules : la boîte fait-elle ce qu’elle doit ?
  2. robustness rules : à quoi la boîte doit-elle résister ?
  3. means for compliance : comment faire respecter les règles (une technique étant de placer un algorithme bidon mais breveté car si il est désossé, il n’y a pas seulement viol de licence mais aussi de brevet…).

Avec quels outils tester notre implémentation pour avoir confiance ?

→ outils simples pour vérifier que l’implémentation résiste au moins aux attaques les plus connues (key management, buffer overflow…)

20.1.3. Trust the greed

  • problèmes d’alignement entre les différents acteurs qui ne cherchent pas la même chose (hardware/software)

    → alignement des intérêts des parties en présence (intérêt économique). Pour cela :

    1. étude du retour sur investissement
    2. étude du retour de non perte
    3. étude du facteur humain
      • tenir compte de la psychologie (prospect theory)
      • théorie du jeu (game theory) : ajuster les paramètres pour changer les équilibres

20.1.4. Conclusion

  • confiance fondamentale
  • modèle de confiance pas encore trouvé

20.2. Avis / commentaire

Un gros bullshit bien présenté, le conférencier étant bon.

De mon point de vue, le problème est fondamentalement mal posé concernant les DRM. Le but n’est pas de trouver un « nouvel » équilibre comme dit par le conférencier mais d’aligner tous les acteurs du marché sur les intérêts des studios.

De manière générale, le discours est fondamentalement malsain. Je recommande la lecture de http://www.techdirt.com/.

21. Vote électronique : constats, questions et certitudes

Chantal Enguehard – Université de Nantes/LINA

21.1. Notes

L’anonymat est la différence avec tout le reste.

Différentes solutions de vote électronique (nomenclature UE) :

  • ordinateur de vote avec bulletin dématérialisé (DRE)
  • ordinateur de vote avec bulletin dématérialisé puis matérialisé (VVAT)
  • comptage automatique des bulletins matérialisé (scanner)
  • kiosque (centralisation)
  • internet
  • hybride

21.1.1. Constats

Élections présidentielles et législatives 2007, municipales et cantonales 2008.

Données recueillies : 21 000 journées de bureaux de vote (dont ⅓ électronique).

Observation de la différence entre nombre de votes (V) et nombre d’émargements (E) :

K = (|V-E|/V)×1 000

En gros, un peu plus d’erreur sur les votes électroniques que les votes à l’urne.

21.1.2. Recherche de corrélations

  • pas lié à la participation (K n’est pas lié au nombre de votes)
  • pas d’effet d’apprentissage (pas de différence de K entre le premier et second tour)
  • indépendance entre les remarques portées sur les PVs et les bureaux en erreur.

21.1.3. Certitudes en ce qui concerne la solution DRE ?

  • vérification par approximation (sondages ou résultats antérieurs) → ne marche pas puisque si les sondages ou les votes précédents étaient fiables, on ne voterait pas…
  • garanties apportées par les traitements (tests) : on ne peut prouver que la machine est inaltérable ou immune de fautes
  • preuves de résultats
    • marche si c’est bien inaltérable (voir ci-dessus)
    • il est impossible de prouver l’adéquation entrée / résultat puisque l’entrée, par définition, est inconnue

21.1.4. Certitudes en ce qui concerne la solution VVAT ?

Production d’un bulletin de vote imprimé vérifié par l’électeur et stocké pour vérification

  • mise en œuvre variable
  • vérification optionnelle
  • pas de preuve de l’intention de vote (seul le juge peut valider ou non un résultat ; pas l’électeur ou le candidat)

21.1.5. Recomptage manuel

Cela se fait aux États-Unis d’Amérique et au Vénézuela.

  • barrière légales
  • difficultés organisationnelles
    • déplacement et stockage des urnes
    • choix des urnes (protocoles, validité scientifique)
    • traitement juridique
  • si ça ne change pas le résultat, rien n’est fait

21.1.6. E2E : end to end verifiable and auditable

  • électeur peut vérifier que son vote est bien enregistré
    • complexe
    • vérification optionnelle
    • pas de preuve matérielle
  • électeur peut vérifier que le total est correct
    • complexe
    • compréhensible
  • électeur est à l’abri de la cœrcition (pas de preuve matérielle de vote)

21.1.7. Conclusion

Gros problèmes, deux contraintes

  1. anonymat pour tous
  2. dématérialisation (discontinuite physique de la représentation du vote)

Risques effectifs :

  1. perte de sincérité
  2. perte de confiance
  3. atteinte à la sûreté nationale (ingérence étrangère)

21.2. Avis / commentaire

Conférence passionnante, pleine de bon sens, rappelant, avant toute considération technique, les fondations de notre société concernant la définition d’élections libres et honnêtes. Considérations que mêmes nos décideurs politiques semblent parfois oublier.

22. Secured and practical voting machines

Florent Chabaud – SGDN/DCSSI

22.1. Notes

22.1.1. Fondements scientifiques

Doutes sur les machines.

Apparition de fausses bonnes idées :

  1. ne pas recourir aux machines à voter (pas très constructif)
  2. bulletins classiques à scanner
    • problème juridique :
      • qu’est ce qui prévaut en cas de différence ?
      • les bulletins sont détruits sous 24 heures
    • problème de fond :
      • ça ne dissipe pas les doutes…
  3. protocoles cryptographiques de vote
    • coût élevé
    • compréhension par le citoyen

Idée intéressante :

  • séparer le processus de configuration du scrutin et le vote

22.1.2. Architecture

Machine à voter :

  • automate minimal (interface)
  • IHM
  • module cryptographique
  • logiciel de décompte
  • sécurité physique
Principe de l’interface

Application au cas français (il existe de nombreux systèmes de votes).

Principe : assurer la transparence

  • interface (publié par la mairie, certifiée par le ministère de l’intérieur)
  • vérifiable
  • permettant de s’entraîner
Principe de l’automate

Doit être uniquement capable de :

  • afficher les images du fichier d’interface
  • affecter des liens à certaines portions
  • passer d’une page à l’autre
  • comptabiliser certaines transitions

Code doit être public (source et binaire) prouvé et certifié cryptographiquement, vérifié par le module cryptographique de la machine.

Module cryptographique
  • ne participe pas au comptage (pas de chiffrement dans le dépouillement)
  • ne vérifie que la certification
  • dispose d’un affichage autonome et indépendant
Sécurité physique

La sécurité logique est assurée par le le module cryptographique.

  • scellé externe numéroté
    • protège contre l’ouverture de la machine
  • capot interne transparent
    • protège l’accès aux composants
    • protège les connecteurs d’interface
  • scellé interne numéroté
    • protège contre l’ouverture du capot
  • deux clés physiques pour les opérations sensibles

22.1.3. Le jour J

  1. vérification du paramétrage
    • preuve formelle a priori du logiciel
    • certification cryptographique des logiciels
    • vérification de la certification le jour J
    • a posteriori contrôle de la sécurité physique
    • suivi de la maintenance
    • vérifications :
      • scellé physique externe,
      • autotest du module cryptographique,
      • empreintes cryptographiques des logiciels certifiés
      • nombre nul de votants
  2. déroulement du scrutin
    • président active un droit de vote après vérification de l’identité
    • confirmation du vote, désactive la machine à voter
    • si pas de validation :
      • on le rattrape ?
      • sinon, président et assesseur à distance, activent la fonction « vote nul »
    • panne : machine de secours
    • toute anomalie signalée
  3. fermeture du scrutin
    • vérifications :
      • preuve cryptographique d’origine du résultat du vote,
      • scellé interne,
      • contrôle visuel de la zone de sécurité (par rapport au cahier de suivi)
  4. affichage des résultats
  5. vérification des résultats

22.1.4. Contrôle par le citoyen

Les systèmes de contrôle actuels sont mauvais.

  • contrôle de l’agrément des machines
  • en fonction de ses compétences
    • intégrité physique
    • cahier de suivi
    • signatures de l’automate et du fichier d’interface (certificat)
    • logiciel d’interface (contenu et preuve formelle)
    • résultats affichés

Pas d’usage de cryptographie en confidentialité (uniquement preuve d’origine et intégrité).

Gestion de clés minimaliste, publication des certificats racine.

22.1.5. Conclusion

  • on peut trouver des architectures qui soient transparentes
  • sécurité pas absolue, mais attaques ont un coût important, et attaque globale est relativement improbable

22.2. Avis / commentaire

Excellent complément à la conférence précédente.

Le conférencier a bien indiqué dès le début que le but n’était pas de dire si le vote électronique était bien ou mal, s’il fallait l’implémenter ou non, mais de disposer d’une solution saine en cas de décision d’implémentation.

La solution proposée m’a clairement convaincu. Et sans être contre a priori le vote électronique, j’étais largement dubitatif du fait du non respect de principes de bases liés à notre démocratie des solutions existantes.

Encore une conférence montrant que notre administration publique peut être brillante.

J’ai oublié de demander s’il y avait eu un « proof of concept ».

23. Clôture des journées SSI

François Fayard – ex-DGA/OTAN

23.1. Notes

n/a

23.2. Avis / commentaire

Hors-sujet du début à la fin. Mais on a eu un bon brief sur l’OTAN ;)

Tags: , ,
Posted in Security | 1 Comment »

[apt] – to change installation status

November 16th, 2008

When installing a package foobar, all its dependencies are installed automatically.

These packages are marked as installed automatically.

If you do an ‘apt-get install blarf‘, blarf being a dependence of foobar, it won’t be installed (as it has been installed automatically). But, its installation status is changed ; it is now set to “manually installed”.

To change that back :

  1. edit the file /var/lib/apt/extended_states
  2. change the value 0 to 1 on the line ‘auto-installed: ‘ for the package blarf.

Enjoy!

Tags: ,
Posted in Configuration, Debian, Documentation, SysAd | Comments Off

After ssh-keys, try OTP

October 30th, 2008

I wrote a short introduction to one time password (OTP) usage a while ago.

As I said usage, there is no howto install the solution. First, that is quite easy and there are a few pages well done on the Net explaining that part.

My point is about use case.

So here is the document :

https://svn.timetombs.org/svn/tip/tip-nix-soft-opie.html

The solution is using OPIE on a Debian.

Let me know which generator you are using !

Tags: , ,
Posted in Documentation, Security | 1 Comment »

Generate strong passwords with APG

September 3rd, 2008

I just reworked a bit on PAM and especially with pam-craklib.

As I was writing my rules to enforce strong passwords, I thought it would be nice to have an utility to generate password that would match my cracklib rules.

Here is my command line to generate secure passwords using APG [1].

$ apg \
    -a 0 \      ## default algorithm to generate pronounceable password
    -m 10 \     ## minimum length of ten characters
    -x 12 \     ## maximum length of twelve characters
    -M SNCL \   ## mode used. There must be special symbol (S), numeral
                ##  symbol (N), capital symbol (C), small letters symbol (L)
    -E \" \     ## excluded character '"' (escaped for the shell)
    -y \        ## also print crypted passwords (crypt())
    -l \        ## also spell the password for reading it to someone
    -t \        ## print pronounciation
    -s \        ## ask user for random sequence for password generation

$ apg -a 0 -m 10 -x 12 -M SNCL -E \" -y -l -t -s
$ apg -a 0 -m 10 -x 12 -M SNCL -E \" -t -s

One drawback : you cannot specify how many of each kind of symbol you want. So tweak the password you pick (apg generates five ones) to pass your cracklib rules.

Nothing special here ; I just read the man page [2].

[1] http://www.adel.nursat.kz/apg/download.shtml
[2] man apg

Tags: , ,
Posted in Documentation, Security, SysAd | 2 Comments »

Playing with the last layer before bare metal ; Grub2

July 2nd, 2008

I screwed up my machine and spent almost two days trying to repair it…

Context

My machine’s hard drive is fully encrypted. This volume is then the PV of an LVM with one VG and several LVs. As the whole hard drive is encrypted, the /boot partition is on a usbkey. So the idea is that Grub is installed on the hard drive (/dev/sda/) MBR, boot with the /boot on a usbkey, then open the crypto container and then activate the LVM and finally mount all the partitions.

My machine is using Sid and therefore Grub2. And this configuration was fully achieve just by using Debian Installer.

Problem

The first thing I tried was to remove the usbkey without unmounting /boot. The system was fully functional but it was then impossible to regain access to /boot.

Then one day, I rebooted… (actually, this was an error ;))

Solution

After the reboot, I was welcomed with Grub message « Welcome to Grub! » (in rescue mode).

So first, I rebooted on my usbkey (not the one with the /boot partition) which has a Debian installed (see FIXME for details about this usbkey). The idea was to

  1. boot,
  2. open the crypto-container,
  3. activate the LVM,
  4. mout all partitions (including /boot on the other usbkey),
  5. chroot
  6. and re-generate an initramfs.

Except that this system is i386 and my machine is amd64 ; no way to chroot…

So, Corsac generated an amd64 LiveDebian cd.

This time, I was able to follow the plan (see § chroot operation below for details). And I rebooted… to get the same message from Grub.

At that stage, we worked together with Corsac (I still did not find a better solution than working with a friend to solve problems ! It’s good to keep moral up, exchange ideas, get help… ;))

So, now we had to play with Grub…

The first thing to know is that Grub2 does not work like Grub.

root, kernel and initrd are variables to set. And Grub2 has lots of modules that must be loaded before being able to actually do something. Making long story short, the prefix variable was set to (fd1,0)/grub/. Which is totally wrong as I do not even have a floppy drive…

So first, all variables ware unset.

unset prefix
unset root

Then the right ones were set.

set root=(hd1,1)
set prefix=(hd1,1)/grub/

Then the normal.mod module was loaded and the normal mode launched.

insmod /grub/normal.mod
normal

At that stage, the Grub menu was launched and my machine booted normally.

What we tried within Grub2 « shell »

But we tried lots of things before finding this. Before finding those two culprits we

  • loaded manually ls.mod, _linux.mod and then linux.mod modules and set linux variable to the right value
insmod /grub.ls.mod
insmod /grub/_linux.mod
insmod linux.mod
set linux=/boot/vmlinuz-2.6.24-1-amd64 root=/dev/mapper/sda1_crypt
  • then initrd.mod module and set initrd variable to the right value
insmod /grub/initrd.mod
set initrd=/boot/initrd.img-2.6.24
  • finaly booting
insmod /grub/boot.mod
boot

chroot operation

During the chroot operation, the following steps were done.

Open the cryptocontainer (the name of the unencrypted logical volume must be the one from the system to be rescued. Indeed, it will be exported to the chrooted system and be used when generating the initramfs. If it is not the same unencrypted LV as the system to be rescued, when booting the initramfs won’t have the name actually used by the system ; it will fail)

# cryptsetup luksOpen /dev/sda5 sda5_crypted

Activate the LVM using the (now unencrypted) encrypted partition

# lvm vgchange -a y

Mount the root LV somewhere to chroot within

# mount /dev/mapper/vg_main-slash /mnt/toberescued

Mount /dev within the chroot so that other LVs are available

# mount --bind /dev /mnt/toberescued/dev

Actually chroot

# chroot /mnt/toberescued

Mount the other partitions (the chrooted system /etc/fstab is available)

<toberescued># mount /proc
<toberescued># mount /sys
<toberescued># mount /home
<toberescued># mount /var
<toberescued># mount /usr
<toberescued># mount /tmp
<toberescued># mount /var/log
<toberescued># mount /boot

Regenerate the initramfs

<toberescued># update-initramfs -u -t

Re-install Grub

<toberescued># grub-install --recheck /dev/sda

Unmount everything and exit the chrooted system.

Tags: , , ,
Posted in Configuration, Debian, SysAd | 1 Comment »

sstic 2008 – compte-rendu

June 19th, 2008

Ces notes sont la retranscription de mes notes prises lors des conférences, complétées de celles de mes camarades Yves-Alexis et Delphine.

Elles ne sont qu’une vue (parfois très) partielle des présentations. Reportez-vous aux présentations mises à disposition par le SSTIC. Ces présentations ne sont elles-mêmes qu’une synthèse sans les aspects les plus gore des papiers publiés dans les actes.

Les parties Avis / commentaire n’engagent que moi.

Enfin, toute erreur dans ces notes est mienne.

Sinon, vous pouvez aussi consulter http://sid.rstack.org/blog/index.php/279-le-sstic-2008-en-live qui est un compte-rendu live des conférences.

Et pour finir, les actes prennent le temps d’expliquer plein de choses qui sont jugées connues lors des conférences. Les actes comme les présentations sont disponibles là : http://actes.sstic.org/sstic08/.

1. Sécurité, anatomie d’un désastre annoncé

par Marcus Ranum / CSO Tenable Network Security, Inc.

1.1. Notes

“La sécurité n’est pas prise en compte”…

Le logiciel est désormais plus complexe qu’un système tel que la navette spatiale. “C’est un miracle que ça marche un peu”.

D’un autre côté, l’informatique n’a pas (encore) provoqué de morts ; seulement des millions de dollars de perte.

La position générale est qu’”il n’y a pas de problème puisque ça marche”. Mais la question n’est pas de savoir si il va y avoir une catastrophe, mais quand.

Le cheminement habituel est :

  1. Une mauvaise idée est proposée
  2. Des warnings sont levés pour stopper cette idée
  3. L’idée survit à ces warnings
  4. On procède à des ajustements pour s’accommoder des warnings levés. En fait ces accommodements rendent l’idée moins manifestement dangereuse et surtout compliquent la solution. L’idée est toujours mauvaise et une catastrophe aura lieu.
  5. L’écart entre les objectifs et la réalité augmente. L’écart est de l’ordre du gouffre.
  6. La catastrophe se produit
  7. On cherche les responsables et on retrouve les mémos
  8. Massacre des innocents
  9. On n’apprend pas de l’expérience
  10. Et on recommence

Une fois qu’il y a eu beaucoup d’investissements sur une idée, même mauvaise, elle ne sera plus stoppée. L’inertie intellectuelle et financière est quasi-infinie.

Les décideurs n’assumeront pas, malgré les discours.

Une solution possible est que les équipes de sécurité puissent avoir accès au numéro 1 directement. Dès lors, on évite la création artificielle d’un gouffre entre réalité et perception.

Souligne la perversité des statistiques utilisées pour dire n’importe quoi.

Les organisations n’apprennent quasiment jamais de leurs catastrophes…

1.2. Avis / commentaire

La position de Ranum est clairement le fruit de (très) nombreuses années d’expérience, et son constat est assez désabusé.

Ranum complète beaucoup son analyse à l’aide de l’analyse de Feyman sur la catastrophe de la navette Columbia. Ce qui a le mérite d’éclairer la problématique de la sécurité plus largement. Ce n’est pas (qu’)une problématique informatique. C’est une problématique générale entre les gens qui comprennent les technologies utilisées et le management.

Néanmoins, il faut bien “faire des choses” et donc prendre des décisions. De mon point de vue, tant que les décisions intègrent l’état de l’art au moment où elle est prise, il est difficile de faire des reproches a posteriori. Même, si à terme, cette décision s’avère mauvaise.

2. Identification et exploitation des failles humaines par les prédateurs

informationels : un risque sous-estimé par les entreprises ?

par Michel Iwochewitsch

2.1. Notes

Prédateurs

  • one shot : social engineer, escroc, journaliste
  • long terme : établissement longue dans l’entreprise. Discret et bien formé. Peut viser tout le monde. Renseignement, activiste, criminalité organisée.

Valeurs de l’information

  • pécuniaire : connaître une information avant, même quelques heures
  • intégrité :
  • confidentialité : en fusion/acquisition par exemple
  • disponibilité : non accès au système Sabre pour tout l’aéroport de Londres
  • nuisance : temps passé à reconstituer l’information (vol de laptop)
  • pour l’opposition

Vulnérabilité

L’exploitation de vulnérabilité n’a rien d’un art depuis le développement des sciences cognitives. Pour les russes, le cerveau humain est un système sans firewall.

  1. exploitation de la personne
  2. capacité décisionnelle
  3. besoins sociaux : reprogrammation d’un fax pour copie systématique (4/10)
  4. loi d’influence, manipulation, psychologie sociale
  5. heuristiques et biais cognitif

Disposer des outils pour mieux appréhender la cible.

Failles

  1. la personnalité
  2. la perception et la capacité de réflexion : elle influent sur les décisions et les heuristiques
  3. l’environnement social : universel

Heuristique (modèle mental appliqué dans des situations de danger ou même quotidienne permettant des décisions rapides en environnement incertain)

  • de disponibilité : estimation d’une fréquence en fonction de la facilité des exemples qui nous viennent à l’esprit. Ex: un attaquant veut avoir des numéros. Il appelle d’abord la standardise et demande des petites choses sans importance, et ce régulièrement. Puis pour la standardiste c’est normal qu’il appelle et elle lui donne les numéros. Mémoire de ce qui s’est déjà passé.
  • de représentativité : comparaison cas particulier et cas général. Ex: un médecin comparant nos symptômes à des listes de combinaisons.
  • d’ancrage : estimation de valeurs. On rapproche des valeurs incertaines de valeurs déjà connues. Ex: nombre de pays dans l’OTAN → environ 30. En appel, l’attaquant devient sympathique, il pose des questions, habitude de l’avoir en ligne. Ex: chat sur internet, on connaît les individus sans les avoir rencontrés.
  • d’émotions (primaires et secondaires) : raccourcis heuristiques fondamentaux. Simple à provoquer et facile à exploiter. Une amorce de base est de demander de l’aide. Échanger des émotions avec son interlocuteur. Ex: un attaquant appelle est dit que son patron a absolument besoin d’une information sinon il va se faire lyncher. Mais pour cela il doit se connecter au réseau. Influence la prise de décision par la pitié.

Biais cognitif

  • effet de primauté : ce biais est lié à l’archi-cortex. On retient mieux la première information que celles qui suivent (“oui mais…”)
  • effet de Halo : on applique à l’ensemble d’un raisonnement un premier jugement (positif ou négatif) non lié. La 1ère chose qu’on fait, va déterminer le reste de la journée. Ex: un escroc va faire se sentir mal un employé dans son entreprise et lui présenter une porte de sortie
  • connaissance rétrospective : auto-manipulation de la mémoire. Se ré-approprier des choses du passé alors qu’on ne les a pas vécues
  • complaisance égocentrique : on s’approprie la réussite et on refuse l’échec. Ex: Lors d’un match, si la France gagne, les supporters s’exclament “On a gagné!”, lorsque la France perd : “Ils ont perdu!”

De manière générale, une perception se forme facilement et est difficile à changer.

La personnalité et son exploitation

  • comportement passé
  • prise de décision
  • bain culturel
  • heuristiques et biais cognitif
  • émotions
  • personnalité

Définition des humains (publicité et politique le font)

On utilise plusieurs outils

  • big five factors : en moins d’une heure et par téléphone il est possible d’avoir le profil de quelqu’un. (utilisé par les psy, étoile a 5 branches (schéma))
  • système de défense de l’Ego
  • besoins sociaux de base

L’EDS objectif bloquer le processus de décision. Augmenter le stress de décisions.

Les boutons universels

  • besoins de reconnaissance
  • tendance naturelle à l’effacement
  • tendance naturelle à corriger les autres
  • tendance naturelle à vouloir que l’autre se trompe (l’ego)
  • absence d’oreilles dans ce monde …

Manipulation des sources

  • MICE
  • ASIE
  • SANSOUCIS

Prédateur “one shot”

  • social engineer : peu formé, peu de méthodologie
  • con artist : très bien formé exploite bien les failles simples
  • opérateur IE

Il choisit le maillon le plus fragile, et agit rapidement et agressivement.

Élicitation : action d’obtenir une information sans l’avoir explicitement demandée.

2.2. Avis / commentaire

Une grosse reprise de son article dans le Misc.

J’ai trouvé les slides plus intéressantes car moins méthodologiques et plus proches des outils psy / neuro-science. [les slides sont maintenant disponibles].

Grosso-modo, le cerveau humain est facilement manipulable dès que placé en situation de stress ou flatté. Les taux de réussite sont significatifs.

3. Contactless smartcard activation without cardholder agreement

par Carine Boursier, Pierre Girard, Christophe Mourtel / Menalto

3.1. Notes

Présentation des cartes à puce (avec un micro-processeur) et non des RFID.

Constituants :

  • antenne
  • chip : micro-processeur
  • portée : de 0 à 10 cm
  • champs magnétique : 14 – 19 MHz
  • pas de batterie

La carte et l’émetteur modulent le champs magnétique pour communiquer (en half-duplex).

Norme ISO1443.

La carte à 250 ms maximum pour tout faire (y compris la sécurité donc).

La bande passante est de 106 kb.s-1.

L’UID de la carte fait de 4 à 10 octets. C’est cet UID que l’on peut tracer.

Deux catégories de risques :

  • passif : pas d’action sur le système. Pas de modification de données possible. Soft attack (bug) et side channel analysis (on capte le signal, on enregistre et l’on en déduit ce que fait la carte)
  • actif : fault attack (perturbation physique), invasive attack (modification du circuit imprimé)

Les risques :

  • listen and eavesdrop data exchanged between the reader and the smart card during the transaction
  • tracking : the same during the samrtcard activation. On e-passport there is a mandatory random value for the UID…
  • active scanning : unauthorized reader
  • relay attack : ability to propagate an information over the physical limitation distance

Les attaques

  • RFID de TI
  • augmentation de la distance de lecture jusqu’à 50 cm
  • Mifare (puce Philips représentant environ 90 % du marché) cracking. Un algorithme propriétaire a été reversé et craqué.

Solutions :

  • carte dans une cage de Faraday (le papier aluminium est effectif)
  • action par l’utilisateur signifiant son accord (push-button)
  • authentification du lecteur et secure channel (vraies solutions à long terme)

Évocation des téléphones NFC (near field communication) qui vont être émetteur et carte… Il existe déjà une attaque publiée…

3.2. Avis / commentaire

Présentation claire de l’état de l’art.

Diminue les fantasmes mais montre aussi que des “attaques” ne sont pas difficiles à monter. Semble montrer que la solution e-passport est relativement robuste.

Le problème fondamental est d’avoir un moyen de solliciter l’accord explicite de l’utilisateur. Quid d’une box se souvenir de ma décision à la FF pour les cookies. Ainsi l’utilisateur pourrait choisir.

4. Expertise judiciaire des téléphones mobiles

par David Naccache

4.1. Notes

Statistiques (attention de 2004)

  • Motorola Nokia Siemens + Samsung = 70 % marché
  • types
    • basiques = 22 %
    • améliorés = 72 %
    • intelligents = 5 %
    • pda = 1 %
  • ~ 1 500 modèles

Trois types de données

  • utilisateur : répertoire, appels, marqueur WAP. Pré-requis : code PIN. Les fabriquants fournissent des outils pour gérer ces données (i.e. pas les analyser). Leurs utilisations modifient l’état du téléphone.
  • opérateur : IMSI, paramètres SMS, géo-localisation (dernière balise accrochée)
  • mobile : IMEI (tracé dans l’envoi de SMS…) et paramétrage

Deux problèmes :

  • PIN : papier officiel du juge le demandant à l’utilisateur (art. 164 CPC). Sinon pour récupérer un PIN/PUK on peut :
    • se baser sur les papiers d’ouverture de la ligne (perquisition)
    • demander à l’opérateur
    • demander au fabriquant de carte
    • craquer la carte
  • analyser sans modifier l’état du téléphone

Techniques d’extraction

  • téléphone cassé = extraction de la flash
  • piratage légal (extraction du PIN)
    • ver légal
    • attaque par faute
    • attaque par consommation de courant
    • cheval de Troie sur portable (expérimental)
  • injection de faute
    • objectif = extraction de PIN, données, etc.
    • outils = lecteur de précision, oscilloscope, traitement du signal, microscope, laser (écrasement du PIN), logiciels spécifiques…
    • deux étapes :
      1. identifier où et quand injecter la faute
      2. analyser les données fausses obtenues
  • cheval de Troie
    • code hostile dans une applet attractive/innocente et/ou “faussement” certifiée (comme un jeu)
    • se déclenche sur sms reçu
    • demande le code PIN (“error SIM…”)
    • stocke le PIN, puis l’envoie

Un outil : GemXplore CASE lite

Passage à la présentation et démonstration qu’une machine peut toujours communiquer quoique l’on fasse. Basé sur un exemple “rigolo” : c’est le ventilateur qui communique en jouant sur l’échauffement des composants et un “thermo-bug” récupère l’information. L’autre exemple est le passage d’information entre deux zones isolées par des “pont-levis” (“norme” NSA) sur un FPGA. Tout est fait numériquement…

4.2. Avis / commentaire

Une bonne introduction / présentation du contexte.

Un long point sur l’utilisation d’applet malicieuses. Qui pose toujours la même question : qui signe quoi pour qui ?

Je n’ai toujours pas compris la digression sur la communication par canal caché mais c’était rigolo et très impressionnant.

5. Outils d’intrusion automatisée : risques et protections

par Mathieu Blanc /

5.1. Notes

Outils :

  • Matasploit
  • CoreImpact
  • Canvas

Tous intègrent :

  • une base d’exploits
  • des vulnérabilités distantes, locales et “client side”
  • une exécution des exploits fiabilisée
  • la possibilité d’intégrer des zero days (payant)

Ces outils passent par les étapes suivantes :

  • découverte des systèmes
  • identification des versions des systèmes
  • tentative d’exploitation des vulnérabilités trouvées
  • déploiement d’agents sur les machines compromises
  • élévation des privilèges éventuellement

Risques :

  • erreurs de manipulation
  • une utilisation d’un exploit peut déclencher un DoS

→ il faut connaître les détails des exploits et ses conséquences

Ils ciblent surtout et avant tout Windows.

Pas de furtivité : ces outils sont bruyants et les communications ne sont pas chiffrées

Il y a deux étapes :

  1. la découverte et l’exploitation d’une faille pour installer un agent
  2. la mise en place du-dit agent et son utilisation.

Il est proposé d’utiliser des signatures de ces agents puisque cela indique 1/ que l’attaque a réussie et 2/ que l’outil utilisé est connu.

Cette signature est basée soit :

  • sur les traces réseaux de l’envoi de l’agent. Ces signatures sont intégrables à Snort, ce qui permet d’être pro-actif (à condition d’être rapide ;) ;
  • sur les appels systèmes de l’agent et leur séquence. La solution est nettement plus lourde.

Dans les deux cas, elle est indépendante de la vulnérabilité utilisée en phase 1/.

En conditions réelles, il n’y a jamais eu de faux-positif sur un mois et demi d’analyse.

FIXME- syscall proxying

En contre-mesures, l’habituel :

  • la mise à jour des systèmes…
  • bloquage avec un IDS à partir des signatures détectées ou re-routage dans un environnement confiné
  • contre-attaque de l’outil utilisé (eux aussi ont des failles et la machine qui fait tourner l’outil est en général en petite culotte)

5.2. Avis / commentaire

Présentation intéressante de ces outils.

J’en retiens qu’un bon audit requiert une bonne utilisation de ces outils “automatiques” qui exige toujours une (très) bonne compétence générale et surtout l’utilisation d’outils maison. Ouf ! ;)

6. Bogues ou piégeages des processeurs : quelle conséquence sur la sécurité ?

par Loïc Duflot / DCSSI

6.1. Notes

Toute la présentation s’appuie sur la réalisation de l’hypothèse suivante : une machine boguée ou piégée, c’est la même chose.

Est aussi rappelé que les bogues CPU ont tendance à s’empiler d’une génération à une autre et qu’un CPU lorsqu’il bogue a un comportement complètement aléatoire.

Petits rappels sur l’architecture x86 :

  • les privilèges vont du ring0 au ring3
  • deux niveaux de traduction dans le CPU :
    • la segmentation : traduit les adresses physiques en adresses virtuelles utilisées par les programmes. Elle permet le contrôle d’accès en désignant des modes sur des blocs (adresse de base + taille)
    • la pagination : présente l’adressage mémoire pour chaque processus et gère derrière (mémoire principale vs. swap). Des droits sont aussi gérables sur les pages.

Objectif du bogue/piège :

  • exploitable avec le minimum de droits
  • donner accès au ring0
  • fonctionne quelque soient les couches supérieures
  • discret

Il est alors démontré en partant de l’hypothèse d’un bogue sur l’instruction “salc”, qu’en positionnant des registres à une valeur particulière, le champs CPL du processeur est passé à zéro (soit un passage en ring0 pour la tâche courante).

Les démonstrations sont faites avec un QEMU modifié afin d’émuler un bogue.

Démonstration que cela peut même fonctionner sur des machines virtuelles…

Contre-mesures pour réduire (i.e. pas supprimer) le risque :

  • réduire la surface d’attaque
  • pas d’outils de compilation ou d’exécution de code (macro)
  • respect des bonnes pratiques de sécurité (accès réseaux…)

6.2. Avis / commentaire

De manière générale, présentation nettement trop bas niveau pour mes compétences. Ce qui me laisse perplexe, c’est comment on se débrouille pour planquer du code déclenchant le piège dans une application… Je sais, ce n’est pas le plus dur, mais n’empêche.

C’est flippant. Et pour ceux qui se posent encore la question, ni SELinux, ni TPM ne sont des barrières.

Une autre contre-mesure : disposer de ses propres fondeurs… Au moins, il n’y a pas de bogue volontaire ;)

7. Autopsie et observation in vivo d’un banker

par Frédéric Charpentier et Yannick Hamon

7.1. Notes

Présentation du virus anserin, spécialisé dans le vol d’information bancaire.

Ce virus s’accroche à IE.

Deux types de serveur dans l’architecture :

  1. collector :
    • mise à jour
    • collecte des identifiants
    • sécurisation des flux entre les agents et le back-office (URL chiffré, blacklistage d’agent “méchant”)
  2. injector :
    • fonctionnalité optionnelle
    • distribution de formulaires malicieux avec injections simples et évoluées (cartes multi-entrées, clavier virtuel, etc.)

Le processus est le suivant :

  1. l’utilisateur accède à sabank.com
  2. anserin demande à son injector s’il connaît cette banque
  3. injector répond oui et envoie le formulaire malicieux qui va bien
  4. anserin récupère les données saisies et les envoie sur son collector à un moment ou à un autre

Les communications sont chiffrées (inversées, hexadécimalisées, XORées avec l’ID de l’agent).

Les formulaires (pour 500 et des brouettes banques) sont mis à jour quasi quotidiennement et proprement localisés.

Ce virus est extrêmement résilient au chambardement de l’architecture (coupure des serveurs) : par un mécanisme de FQDN pseudo-aléatoire il saura retrouver un serveur avec un peu de temps. L’architecture est aussi capable d’utiliser des fast-flux DNS. Tout cela est hébergé chez des providers bullet-proof (i.e. ne coupant pas les services même quand la police leur demande) et l’hébergeur change toutes les semaines. Basé sur la documentation de ces hébergeurs, le coût de fonctionnement mensuel est estimé à 1 000 USD par mois. anserin a commencé en étant hébergé sur le RBN, et utilise des registrar au Panama et Nassau, ce dernier semblant être le pivot. Il est très lié au “secure hosting” et affiche fièrement un blason “hacker free” de FIXME.

La conclusion est la suivante :

  • la course aux signatures anti-virus est perdue
  • Firefox est aussi concerné (une rump précisera même que Firefox dispose de fonctionnalités (sans hack) au moins aussi dangereuses que celles d’IE…)
  • l’authentification double canal devient impératif (SMS, OTP, etc.)
  • l’authentification deux-tiers pour les paiements par CB (3DSecure, SecureCode, etc.)
  • quid du filtrage par les FAI des serveurs C&C ?

7.2. Avis / commentaire

Présentation extrêmement visuelle et accessible.

Après ça, on peut se demander pourquoi les banques ne font pas systématiquement de l’authentification forte / double canal…

Cette présentation illustre bien un sentiment de fond de “professionalisation” (j’ai horreur de ce terme ; il est employé au sens de “pour faire de l’argent”) des méchants.

Le dernier point de la conclusion laisse un goût amer…

8. GenDbg : un débogueur générique

par Jean-Marie Fraygefond et Didier Eymery / Cellar

8.1. Notes

Présentation d’un débogueur multi-plateforme, multi-architecture et multi-OS.

Le but étant de disposer du meilleur de ce qui existe pour chaque point : IHM, scripting, etc.

Les fonctionnalités :

  • IHM en mode texte pour l’efficacité
  • moteur de script “maison” pour rester cohérent avec leurs applications
  • architecture client/serveur

L’architecture est minimaliste. Elle est essentiellement composée de :

  • framework : permet de communiquer entre les différents modules
  • stub : code exécuté sur la machine cible. Il implémente les primitive et est chargé des interruptions/exceptions de la machine cible.
  • module ASM : assembleur/désassembleur lié à l’architecture.
  • modules optionnels :
    • modules de commande liés à l’architecture (IA-32, etc.)
    • modules d’OS helper (propre à l’OS cible)
    • module de symboles
    • module BT (breakpoint extenders lié à l’architecture cible)

GenDbg permet de mettre plusieurs stub sur une même application. Ce qui est très pratique pour les applications sur VM.

8.2. Avis / commentaire

Encore très bas niveau.

Y’a des gens comme les opérateurs dans Matrix ; ils lisent l’assembleur en direct-live… Pas moi ;)

9. Sécurisation, état de l’art et nouveaux enjeux des green data center

par Christophe Weiss / APL France

9.1. Notes

Présentation des mesures de protection des data centers (DC) : sécurité physique, disponibilité, supervision, etc.

Un DC est un bâtiment sûr et sécurisé avec personne.

Périmètre :

  • terrain et environnement
  • coque (on laisse les générateurs à l’air libre ?)
  • architecture intérieure adaptée à l’exploitation
  • des installations lourdes et complexes (courants forts…)
  • supervision en temps réel

Avant 2004 : 500 W.m-2 maximum. Redondance n+1

À partir de 2004 : les serveurs 2U et autres pizza-box arrivent. 500 à 800 W.m-2

À partir de 2005 : arrivée des blades. 700 à 1 000 W.m-2 . Passage à une redondance 2n ou 2(n+1). Introduction de charges capacitives.

2006 - 2007 : généralisation des charges capacitives. Généralisation des blades. On passe à plus de 1 000 W.m-2. Classification des DC par tiers (4).

2008 : jusqu’à 12 à 15 kW par baie haute densité.

Les questions sont :

  • refroidir le matériel
  • état capacitaire et marge d’évolution réelle
  • quid du tiers IV
  • solution d’extinction en cas d’incendie
  • optimisation énergétique

Sustainability : aspects liés à la bonne gestion du site

Marier l’efficience énergétique et la continuité de service (raison d’être des DC) est très délicat, ces deux objectifs étant antinomiques.

La climatisation d’un site représente 63 % de la consommation électrique d’un DC (33 % pour l’équipement IT).

Ration PUE (power unit efficiency) = consommation globale du site sur un an (lissage de l’effet saison) / consommation des équipement IT (sans prise en compte de la charge CPU)

Les PUE sont aux environs de 2,5. La cible est de 1,8 voire 1,6.

Ordre de grandeur du coût de l’électricité (en France où elle est très peu chère) d’un DC de 2 000 m2, à 1 kW.m-2 avec un PUE de 2,3 : 1,3 M€ par an.

La recherche de la redondance exige une multiplication des équipements, donc une augmentation de la consommation et de pertes à faible charge.

La classification par tiers est faite par l’uptime institute.

L’idéal est le tiers IV où tout est doublé, y compris l’alimentation secourue. Ce qui exige plus de surface générale pour moins de surface utile. Un DC appartenant à cette catégorie souffrira d’une interruption de 0,8 heure par an, soit un arrêt tous les quatre ans.

Les valeurs des dissipations des constructeurs sont fausses : il faut les diviser par deux.

Listage des besoins et contraintes ÷

  • surface
  • puissance
  • niveau de service / continuité
  • évolutions envisageables
  • modalités d’exploitation futures

80 % des DC vont devoir être restructurés dans les cinq ans à venir. Vaut-il mieux restructurer ou reconstruire ?

Les réserves de fioul sont pour une durée de 3 à 5 jours. C’est une denrée périssable, à renouveler donc.

A priori, seule l’armée a été intéressée par des DC faradaysés, à sa connaissance.

9.2. Avis / commentaire

Une présentation un peu plus éloignée du CPU (encore que…).

De mon point de vue, un super état de l’art avec des ratios remis à jour (par rapport à ce que l’on trouve dans la littérature). Clairement, le monsieur semble savoir de quoi il parle.

10. Déprotection semi-automatique de binaire

par Alexandre Gazet et Yoann Guillot

10.1. Notes

On repart dans du bas niveau.

Rappels sur l’outil Metasm et en particulier les fonctionnalités de backtracing (fonction limitée dans IDA).

En fait, toute la présentation repose sur deux exemples tirés de challenges de sécurité.

Avant de présenter leurs exemples, ils présentent ce qui est la base de leur raisonnement / façon de faire. Trouver la sémantique de tout morceau de code et donc pouvoir le factoriser au maximum.

Ils présentent ensuite tout un tas de techniques d’obfuscation (insertion d’éléments neutres, expansion de constantes, obfuscation structurelle et complexification à l’envie).

Le premier exemple (pouet.exe) leur permet de présenter les fonctionnalités de détection de sauts conditionnels biaisés ainsi que le nettoyage/factorisation du code, enfin du graphique présentant le code. On passe d’un truc impossible à un code exploitable ; il est réduit de près de 80 %.

Le second exemple présente les capacités de nettoyage de junk code inséré par un packer pour rendre illisible/inexploitable le code. Y compris lorsque le-dit code utilise une machine virtuelle (interpréteur)…

10.2. Avis / commentaire

Présentation très claire. Limite j’avais l’impression de pouvoir me lancer dans un débogage pour le prochain challenge sécurité…

Ah, aussi, y’a vraiment des gens vicieux et pas bien dans leur tête quand on voit l’obfuscation qui peut être faite…

11. ERESI : une plate-forme d’analyse binaire au niveau noyau

par Anthony Desnos et Sébastien Roy

11.1. Notes

Ne prenez pas l’ascenseur, on reste en bas…

Il s’agit d’un ensemble d’outils dédiés au reverse du noyau. Il assemble de quoi faire du débogage statique et dynamique, ainsi que du scripting. Le tout utilisant un langage propre et commun à toutes les fonctionnalités offertes.

ERESI se compose de :

  • logiciels scriptables
  • librairies+API

ERESI supporte :

  • les architectures : IA-32, Sparc, Mips
  • les plateformes : Linux, BSD, Solaris

Il ont ressuscité Kernsh pour l’occasion et l’intégrer (aussi). Et puis comme Kernsh il s’exécute en contexte utilisateur, ils ont écrit Ke2dbg qui lui tourne entièrement en contexte kernel (ça va plus vite, mais c’est potentiellement plus instable et puis ça peut modifier l’état du chat…).

Pour imager tout ça, ils présentent le tout dans le contexte d’un rootkit (injection de code, détournement de fonctions kernel non-exportées, etc.).

Les fonctionnalités sont entre autres :

  • lecture/écriture dans la mémoire kernel (utilisation de get_raw, surcharge des fonctions de libkernsh)
  • possibilité d’allouer/libérer de la mémoire (kmalloc et/ou syscall existant)
  • injection de code
  • redirection de fonctions (jump)

Les inconvénients :

  • le changement de contexte induit des problèmes de performance et de fiabilité des informations obtenues
  • bogues

11.2. Avis / commentaire

Impressionnant mais pas utile tous les jours pour moi ;)

12. Cryptographie : attaques tous azimuts

par Jean-Baptiste Bédrune / ESAT

12.1. Notes

Le but est de présenter comment craquer du chiffrement sans avoir recours à la cryptanalyse lourde.

Présentation de deux cas :

  • application web / client lourd Java : les clefs (privées) étaient dans des fichiers…
  • MacOSX : mot de passe en clair (dans le swap, puis après un fix, dans la RAM)

L’idée est qu’il y a beaucoup de fonctions cryptographiques un peu partout. Le but est alors de retrouver les primitives puis d’analyser leur utilisation et enchaînements afin d’isoler une faiblesse.

Les primitives sont retrouvées à l’aide de patterns tels que les constantes utilisées (fonction de hash) :

  1. analyse statique : identification des primitives
  2. analyse dynamique : appel à quelle primitive identifiée en 1/ et où.

12.2. Avis / commentaire

Bref, pas besoin de disposer d’un centre de calcul en peta flops pour s’attaquer à la cryptographie. Néanmoins, une connaissance avancée des principales fonctions cryptographiques est requise.

13. Sécurité dans les réseaux de capteurs

par Jean-Claude Castellucia / INRIA

13.1. Notes

Capteurs : ensemble de nœuds déployés plus ou moins aléatoirement. Chaque nœud est un capteur et un routeur.

Architecture en arbre : les capteurs sont les feuilles et la station de base la racine

Applications :

  • militaire
  • surveillance de l’environnement
  • structure de bâtiment
  • conditions routières
  • médicale

Problème difficile :

  • capacités très restreintes (cpu et mémoire en quantité limitée)
  • énergie très limitée et lorsqu’elle est épuisée, le nœud est out (énergie = 2 × 1,5 V). Utilisation de protocoles très économes
  • nœud facilement accessible
  • protection physique difficile
  • contrainte de prix

Sécurité

  • passif : écoute de ce qui se passe. Mise en place de capteurs dans le même environnement
  • actif : re-routage des capteurs.

→ Bambi contre Godzilla.

Résolution

Problématiques diverses selon les usages ÷

  • intégrité confidentialité des données
  • protocole d’échange de clefs efficaces : comment échanger des clefs entre capteurs sans utilisation d’un protocole à clefs publiques (trop coûteux)
  • sécurité du routage (attaquant peut entrer dans le réseau car réseau ad-hoc)
  • sécurité de localisation du nœud
  • agrégation sécurisée

Deux illustrations

  • application médicale avec le pacemaker
    • 1 ou 2 nœuds non accessible car dans le patient
  • application militaire : surveillance

13.1.1. Médicale

Interface sans fil. Le médecin configure l’implant à distance. Stockage d’informations dans l’implant. Récupération des mesures par le médecin. Surveillance, monitoring du patient et réaction en temps réel.

Implant cardiaque (défibrillateur et pacemaker)

Stimulateur cardiaque : stimuli électriques faible périodiquement Défibrillateur : émet des stimuli quand le cœur ne va plus, et hop un stimulus plus fort pour permettre au cœur de reprendre un rythme normal.

Systèmes actuels

  • ultra low power cpu + 128ko de RAM
  • communication par induction (donc proche)
  • bande passante limitée

Nouveaux systèmes

  • fréquence radio portée de 2 à 3 m. Surveillance à distance, facilité de programmation et d’installation
  • bande passante plus importante (400 bits.s-1)

Aspect sécurité

Les systèmes actuels n’ont aucune sécurité : pas de mécanisme de contrôle d’accès, pas de confidentialité des données. Un attaquant peut facilement lire les données mesurées et stockées, lire les données personnelles du patient et du médecin, modifier les paramètres et désactiver l’implant.

Pourquoi ce manque de sécurité ?

  • les fabricants jugent cela inutile. Il faut être proche du patient. Mais un attaquant peut utiliser un équipement non standard et donc accéder à une distance plus importante aux données (cf. conférence Gemalto)
  • coûteux en terme de ressources (cpu, bande passante, énergie)

→ compromis sécurité/sûreté : la sécurité ne doit pas mettre en danger le patient en cas d’urgence. Pas d’accès aux données par les attaquants mais dans ce cas les données sont aussi inaccessibles aux médecins en cas d’urgence ? Un attaquant ne doit pas désactiver l’appareil mais un urgentiste doit pouvoir le faire…

Il faut pouvoir authentifier le lecteur : gestion de clés (données au médecin traitant mais en cas d’urgence ?) carte a puce ? Comment révoquer les clefs ? PKI ?

Solution contre DoS : combiner RFID et capteur. La puce RFID sert de parefeu. RFID implémente le contrôle d’accès et vérifie que le lecteur est autorisé. Si le lecteur est accepté alors la communication est rendue possible avec le capteur sinon RFID bloque. Comme RFID est passif il ne consomme pas d’énergie. Le RFID pourrait émettre un son pour avertir le patient de l’interaction.

L’authentification passive est prometteuse. Mais la cryptographie ne suffit pas car le fait d’émettre des signaux révèle en soi des informations : le patient porte un pacemaker, information intéressante pour un assureur ou un employeur… Il y a déjà atteinte à la protection de la vie privée.

Besoin de protocole qui ne s’active qu’en présence de lecteur autorisé mais détectable et accessible en cas d’urgence. Le patient doit être mis dans la boucle (conscience de ce qui se passe, ça le rassure).

13.1.2. Surveillance

Un avion envoie des capteurs sur une zone. Le passage d’un char est détecté et les capteurs préviennent. Ex: feu de foret, routes…

Caractéristiques

  • nombre important de capteurs
  • capteurs bon marché

Problème de sécurité

  • capteurs facilement accessibles (ils sont dans la nature)
  • sécurité de l’infrastructure
  • distribution et échange de clefs
  • agrégation des données chiffrées
    • besoin de minimiser les transmissions (consomme beaucoup : 1 bit transmit = 1 000 opérations CPU)
    • agrégation : données compressées/traitées dans le réseau

Agrégation triviale sans sécurité mais devient difficile avec. Confidentialité ? Assurer l’authenticité ? Intégrité des données ?

  • approche saut à saut : chaque noeud chiffre et authentifie les données avec la clef qu’il partage avec l’agrégateur.
    • nécessite un protocole d’échange de clef
    • coûteux
    • sécurité faible (agresseur compromis peut accéder aux données)
  • approche bout en bout : chaque noeud partage une clef avec la station de base, l’agrégateur manipule les données chiffrées sans les déchiffrer.
    • besoin d’un algorithme de chiffrement homomorphe par l’addition (un peu magique mais ça marche)
    • l’agrégateur additionne les données chiffrées
    • la station de base reconnaît les clefs

13.2. Avis / commentaire

Mon seul endormissement pendant quelques slides mais un gros regret. Super, super intéressant. J’ai lu les actes et les recommande.

14. Dépérimétrisation : futur de la sécurité réseau ou pis aller passager ?

par Cédric Blancher / EADS

14.1. Notes

L’idée serait de sécuriser les données elles-mêmes.

La think-tank derrière le buzz est le Jericho forum.

Périmètre :

  • vieux
  • ne protège pas
  • contre productif

→ il faut donc :

  • ouvrir les réseaux
  • remonter la sécurité vers les applications

Tout cela pose beaucoup de questions :

  • réalité technique ?
  • réel apport ?
  • pour quelle cible ?

D’un point de vue réseau, l’objectif est le réseau plat :

  • moins de firewall
  • plus de connectivité (principe IPv6)
  • sécurité de bout en bout
  • fonctionnalités telles que l’overlay (réseau logique over réseau IP, tel que Skype)

On voit que l’on ne supprime pas le périmètre mais qu’on le reconstruit. Le problème est déplacé sur une couche logique.

La situation n’évolue pas trop :

  • mêmes moyens de sécurité
  • menaces client-side
  • problématique de confinement

→ la question reste de savoir comment gérer l’exposition des systèmes en terme de résilience, en particulier par rapport au reste du périmètre.

En fait la problématique reste la même :

  • mêmes services
  • mêmes données
  • mêmes accès
  • plus une gestion de l’impact de l’exposition accrue…

Le fond du problème réside dans la gestion des données

  • la valeur réside dans les données
  • comment protéger efficacement les données ?

Et quid de toutes les données ne transitant pas sur un réseau (clef USB) ?

14.2. Avis / commentaire

Probablement la conférence la moins technique.

Une bonne synthèse sur un sujet hot en ce moment qui évite de se taper pas mal de lecture pour se forger son opinion.

Surtout à faire lire à des n+x pour tuer le zombie avant qu’il ne s’élance…

Pas de solution miracle concernant la protection de la donnée elle-même (étonnant ;)). Et même, ce qu’il faudrait c’est une protection de la donnée selon le contexte d’utilisation… /dream_off

15. Pentests : réveillez-moi, je suis en plein cauchemar !

par Marie Barel / Orange business service

15.1. Notes

Mission du pen-testeur : détecter et exploiter des vulnérabilités d’un SI.

Démarche en boite noire :

  1. recueil d’information sur la cible et cartographie
  2. identification des vulnérabilités
  3. exploit
  4. collecte des preuves

Risques liés à la cible :

  • tests sur un système sans autorisation (avant-vente…)
  • erreur sur la cible
  • test sur une partie SI hors du champs de responsabilité du signataire du contrat
  • dépassement du périmètre contractuel des tests
  • SI cible hébergé par un tiers
  • test impliquant l’attaque de systèmes tiers pour faire un rebond

Article 323.1 du CP. Pour prouver, il faut :

  • un fait matériel
  • une intention frauduleuse
    • sans droit
    • en connaissance de cause

Protections :

  • caractère obligatoire du contrat “mandat express”
  • durée et modalités des tests
  • étapes de validation :
    • qualité et pouvoir du signataire
    • périmètre de la cible (validation de la cartographie après la première étape)
    • collecte de l’autorisation des tiers

15.2. Avis / commentaire

Encore une bonne synthèse sur le sujet.

Évidemment, l’intervenant (le masculin ne marque pas le genre en français, faites pas iech…) n’approuve pas les contrats type. On se doute que chaque cas est unique et qu’il faille adapter, mais éviter de repartir à zéro à chaque fois, ça fait gagner un peu de temps et des gens capables d’inventer l’eau chaude, il n’y en a pas beaucoup…

16. Une architecture de workspaces ubiquitaires, sécurisée et distribuée

par J. Rouzaud-Cornabas / LIFO

16.1. Notes

L’idée du bureau distant part du constat suivant :

  • augmentation bande passante
  • clients légers
  • centralisation du SI (mutualisation, économies d’énergie…)
  • augmentation de la sécurité

Le projet est pensé avec la sécurité en premier plan depuis la conception.

La solution s’appuie sur :

  • KDE
  • technologie NX : 10 kb.s-1 par utilisateur
  • sécurisation des flux avec openssh
  • authentification sur la base du couple Kerberos et LDAP. Solution de SSO.
  • virtualisation : virtualisation légère utilisant la solution OpenVZ (gestion de quotas poussée)

Migration à chaud et répartition de charge (dynamique de par l’utilisation d’un système P2P) et reprise automatique sur panne. Pas encore en production.

Le système est très surveillé à l’aide SNORT, NAGIOS, OSIRIS. De nombreuses alarmes sont générées ; ce n’est pas gérable par un humain. Aussi, y a-t-il des machines à état pour corréler toutes ces alertes :

  1. nœud = événement
  2. arc = transition chronologique, à autoriser sous conditions

L’architecture est entièrement composée d’élément en GPL.

Actuellement en production sur quatre machines physiques avec chacune 6 à 7 workspaces.

Sont passés de MySQL à PostgreSQL à cause d’un problème de mise à l’échelle.

16.2. Avis / commentaire

Intéressant.

Je ne suis pas sûr qu’une présentation de 30 minutes permette de se rendre compte de la quantité de travail que ce projet représente…

Je serai curieux de connaître le résultat de la mise en production lors de la rentrée 2009.

17. Take a walk on the wild side

par G. Arcas

17.1. Notes

La papier s’appuie sur l’analyse de 6 Go de traces réseaux (juillet 2007 à mars 2008). Pas de reverse.

Stormworm : cheval de Troie, rootkit.

Apparu fin 2006.

Premier botnet avec un C&C en P2P fiable.

Principalement utilisé pour :

  • du spam
  • DDoS
  • proxification web/DNS

Utilise du fast-flux hosting.

Suspect numéro 1 ruse | en russie (au choix). Utilisation des infrastructures RBN jusqu’en octobre 2007.

17.2. Avis / commentaire

Pour ceux qui ne se seraient pas tapés la lecture de la tonne de littérature sur le sujet, ben c’est un bon point d’entrée ;).

J’ai beaucoup aimé la question de l’ajout de certificats sur les postes infectés ou de l’utilisation de capacités de stockage, suite à l’ajout de la capacité DNS dans l’architecture de storm.

18. SinFP, unification de la prise d’empreinte active et passive des systèmes d’exploitation

par P. Auffret /

18.1. Notes

OSFP = art d’identifier la nature d’un OS par l’analyse de la manière dont il construit ses paquets réseaux

Deux modes :

  • actif : provoquer des réponses à l’aide de requêtes construites
  • passif : écoute seule des requêtes et des réponses

→ les empreintes sont différentes dans les deux modes.

Outils actuels ont de nombreuses limitations :

  • très détectable par les IDS
  • utilisation de nombreux protocoles souvent filtrés
  • utilisation de paquets non standard avec dommages collatéraux (crash et détection)
  • utilisation de ports différents : une autre machine en coupure peut répondre à la place
  • souvent IPv4 seulement
  • utilisation de bases de signatures (grosses) différentes pour l’actif et le passif

Les principes de SinFP :

  • utilisation de trois paquets standards sur un même port ouvert maximum (mais il est tout à fait possible de faire une prise d’empreinte avec seulement le deuxième paquet)
    1. 1 paquet TCP SYN sans option TCP
    2. 1 TCP SYN avec options TCP
    3. 1 TCP SYN+ACK (pour RST+ACK)
  • une seule base de signatures (les signatures passives sont dérivées)
  • IPv6 compliant

en se plaçant toujours dans les pires conditions possibles. (un seul port ouvert, filtrage state-full, packet scrubbing, etc.)

Une empreinte peut varier en fonction :

  • des conditions réseau
  • des dispositifs de filtrage
  • de la personnalisation de la pile IP

→ on utilise donc des masques pour redresser les distortions

Ces masques se basent sur cinq éléments :

  • binary
  • flags
  • window size
  • options
  • mss

18.2. Avis / commentaire

Avec mes maigres connaissances en la matière, je trouvais que des réponses différentes à des sollicitations de ports différents dues à des répondeurs en coupure ou re-routés permettaient justement d’avoir une bonne cartographie…

Le type présente ça avec une simplicité déconcertante alors qu’il doit pouvoir directement parler sur le réseau…

Je ne connaissais pas et je vais essayer (ce n’est pas dans la Debian).

19. Le recueil de la preuve numérique

par Nicolas Duvinage / département informatique-électronique de l’IRCGN (i.e. les experts au pays merveilleux…)

19.1. Notes

IRCGN :

  • 25 % de 3ème cycle
  • 50 % de 2ème cycle

Département : 15 personnes dont 12-13 ingénieurs

L’institut répond aux normes ISO 17025.

Quotidien : très peu de piratage. C’est du basique :

  • très peu d’intrusion/compromission mènent à des affaires judiciaires
  • 90 % de Windows, très peu de chiffrement (zip avec mots de passe)
  • communications email et MSN

Trois types de crimes & délits :

  • ceux où l’objet numérique est accessoire (mails, sms)
  • ceux où l’objet numérique est utilisé de façon principale (contenu illicite sur le net)
  • ceux où l’objet numérique est l’objet de l’infraction (craquage de carte téléphonique)

Les deux premiers types, le suspect a une faible connaissance (voire nulle) des objets numériques en cause.

Dans tous les cas, le travail d’analyse de la preuve doit être scientifique et indiscutable.

Preuve numérique :

  • tout élément matériel ou immatériel
  • recueilli et analysé dans le respect de la législation
  • apportant un indice (disculpant, incriminant, autre)

En pratique, il s’agit de :

  • supports de stockage numérique : magnétique, (les plus ennuyeux étant les cassettes de sauvegarde), flash, optique, magnéto-optique, micro-contrôleur, carte à puce
  • informations stockées chez des tiers : logs des FAI

Le recueil se fait de manière :

  • directe : perquisition
  • indirecte : réquisition judiciaire

Difficultés :

  • objets numériques très répandus, qui peuvent tous contenir quelque chose d’intéressant, mais les enquêteurs ne peuvent pas être partout
  • preuve peut être stockée sur un serveur distant (hors de France)
  • très grande variété de formes
  • ordinateur allumé, comment l’éteindre
    • extinction propre ou arrache de prise ?
    • transporter sans l’éteindre ?
  • GSM et sim en fonctionnement
    • extinction avec risques de non accès ultérieur ?
    • transport allumé avec risque de réception de messages ?
    • cage de faradayø?

Exploitation :

  • l’exploitation ne doit pas modifier l’élément de preuve car :
    • il faut pouvoir rendre indiscutable ce qui est trouvé
    • il faut, si il y a contre-expertise, qu’elle trouve les mêmes résultats
  • mais :
    • booter modifie pleins de choses (logs, etc.)
    • même en montant le disque dur en esclave sur un autre système, il y a des précautions à prendre (-ro est un peu court) Quid de SMART et GListRemapper ?
  • risques de pannes matériel

Donc, on travaille systématiquement (autant que possible) sur une copie :

  • blocage (matériel – voir http://tableau.com – ou logiciel - again -ro ne suffit pas) en écriture
  • ordre des examens (empreintes sur un CD, etc.)
  • connectique trop ancienne ou trop rare
  • connectique ne supportant pas la copie bit à bit
  • copie bit à bit qui modifie l’originale (dessoudage)
  • secteurs défectueux
  • supports endommagés / en panne

La copie est ensuite (techniquement) analysée :

  • analyse semi-automatique de systèmes de fichiers avec divers outils commerciaux ou pas (PhotoRec pour le carving)
  • FS rares ou pas documentés (GSM etc.)
  • formats bizarres
  • problèmes non techniques
    • quoi chercher
    • comment les mettre à disposition (format de fichier et support physique)
  • capacité des disques croissante, mais temps de GAV ne bouge pas
  • problèmes de tri et de temps d’analyse

Mais l’analyse technique ne suffit pas :

  • mettre les données en perspective, wrt. reste de l’enquête
  • rendre les analyses compréhensibles par un non-spécialiste
  • exprimer clairement les limites de l’analyse

Conseils lors de la découverte de ce que l’on pense être une infraction :

  • ce n’est pas forcément une infraction
  • le suspect n’est pas forcément responsable
  • un responsable n’est pas forcément coupable (pour de vrai)
  • même coupable, il ne sera peut-être pas forcement condamné
  • attention aux fausses accusations
  • prudence et discrétion
    • attention aux complicités internes
  • pas de jugements hâtifs (présomption d’innocence)
  • réagir vite, mais en respectant le droit
    • pas de perquisition sauvage, analyse de fichiers personnels, etc.
  • préserver les éléments de preuves
    • changer le pc (en prétextant une maintenance, une mise à jour, une infraction moins grave, etc.)

19.2. Avis / commentaire

Une présentation carrée, structurée, claire, intéressante. Non pas que les autres ne l’étaient pas aussi, mais là je pense que c’est un modèle d’école.

Sinon, pensez à regarder des séries françaises. Le monsieur a dit que ça a tendance à énerver le gendarme qui débarque à 0600 quand on lui demande un mandat…

Je vous invite à lire les papiers concernant les cold boot attack pour certaines questions levées ici.

20. Voyage au cœur de la mémoire

par D. Aumaître

20.1. Notes

  • présentation orientée Windows
  • mémoire physique = vue indépendante de l’OS
  • multiples points d’accès

Mais :

  • besoin de reconstruire les structures de l’OS
  • base de la mémoire pour un process stocké dans la structure _KProcess
  • la structure _KProcess est retrouvable en cherchant les structures _Dispatcher_header qui ont une signature fixe puis en éliminant les mauvaises possibilités

20.1.1. Comment accéder à la mémoire physique ?

  • firewire
  • VMWare
  • fichiers d’hybernation
  • forensic
  • coldboot attack

Le firewire permet l’accès direct à la mémoire physique via DMA.

L’accès à la mémoire est contrôlé par deux registres dans le contrôleur firewire qui est interdit par défaut sous Windows sauf pour certains périphériques (stockage de masse). La carte d’identité d’un ordinateur est modifiable, on peut donc la transformer et faire passer son Linux pour un iPod…

20.1.2. Accès direct à la mémoire

  • en lecture :
    • utilisation de Process Explorer 101, clone de Process Explorer. Utilise les informations suivantes : voir papier
    • utilisation de Regedit 101, clone de Regedit. Utilise les informations suivantes : voir papier
    • → forensic, récupération de données « sensibles »
  • en écriture :
    • patch de deux octets dans la base de registre
    • → login sans mot de passe
  • en exécution
    • détournement de pointeurs de fonctions. Si l’adresse d’un gestionnaire d’interruption est modifiée par du code contrôlé, celui-ci est exécuté à chaque fois que l’interruption est appelée
    • démonstration en exécutant un shell alors que la machine attaquée à la fenêtre de login
    • → whatever ;)

20.2. Avis / commentaire

Impressionnant. Je pense que tout le monde était relativement pantois devant la démonstration ;)

Pourquoi, puisque les *nix autorisent par défaut l’accès directe à la mémoire (en r pour Linux, en rw pour BSD et OSX), l’exploit n’est pas (aussi) présenté sur les *nix ?

21. Recherche et développement en sécurité des systèmes d’information : orientations et enjeux

par F. Chabaud / DCSSI

21.1. Notes

21.1.1. Enjeux de souveraineté

  • autonomie
  • protection du citoyen

21.1.2. La sécurité

Se base sur l’article « the six dumbest ideas in computer security » par Marcus Ranum (http://www.ranum.com/security/computer_security/editorials/dumb/)

  • autorisation par défaut : principe de la démocratie mais… Un utilisateur utilise moins de trente applications…
  • recenser les vulnérabilités
  • pénétrer et corriger
  • le hacking c’est super : quid d’enseigner à faire des systèmes sûrs…
  • sensibiliser l’utilisateur : si l’on compte sur l’utilisateur, c’est que l’on est en autorisation par défaut… Si ça avait dû marcher, ça aurait déjà marché…
  • il vaut mieux agir que de ne rien faire : « il est plus facile de ne pas faire quelque chose d’idiot que de faire quelque chose d’intelligent »

Tout ça, mais avec quelques nuances.

21.1.3. Défense en profondeur

Olivier Gobelin

Travailler sur tous les points suivants qui définissent la défense en profondeur :

  • prévenir
  • bloquer
  • renforcer
  • détecter
  • réparer

Mais, de manière générale :

  • on est mauvais en prévention
  • on mise trop sur le blocage (firewall), systèmes très connectés
  • on est mauvais en tolérance aux agressions
  • on commence à peine à faire de la détection
  • capacité de réparation très faible
    1. cycle de réparation très long
    2. quid de la réparation d’une puce de téléphone «ømauvaiseø»ø?

La plupart des problèmes est liée à des erreurs de conception.

La priorité devrait être au développement d’OS moins vulnérable et plus tolérant.

Point sur le concept du honeypot. Pourquoi ne pas utiliser le principe mais pour des systèmes en production ?

21.1.4. Forces & faiblesses de la recherche française

  • atouts
    • bonne école de cryptographie
    • bonne école de méthodes formelles

Mais les systèmes sont déjà bien standardisés aux niveau de la cryptographie et utilisent rarement les méthodes formelles. La qualité de la recherche française dans ces domaines a peu d’impact sur les systèmes opérationnels.

  • faiblesses
    • déséquilibre grave. Des compétences cruciales ne sont pas couvertes :
      1. OS
      2. protocoles réseaux
      3. architectures matérielles
    • bonne expertise dans l’analyse, mais pas dans la conception
    • recherches académiques sont peu connues des industriels
    • sensibilisation des décideurs
    • ré-équilibration de la recherche dans les domaines de la SSI (vastes domaines : cryptographie, informatique, électronique, protocoles, physique, etc.)
    • problème du retour sur investissement
    • besoin d’une communauté SSI
    • industriels doivent pouvoir identifier facilement les chercheurs susceptibles de les aider
    • structure d’échange

21.1.5. Thématiques prioritaires

Issues du rapport d’orientation du 10/04/2008

  • architectures des produits et des systèmes
    • enseigner à concevoir des architectures saines
    • les architectures sont beaucoup plus pérennes que les technologies (IP)
    • utiliser les compétences en architecture auto-organisante
  • informatique de confiance
    • TCG = futur des architectures de PC (qu’on le veuille ou non)
    • impact sur toutes les technologies
    • industrie de la carte à puce en première ligne (trois entreprises françaises sur 180)
    • représentation française insuffisante
    • initiative de la DCSSI en cours pour faire mieux connaître les travaux et y participer
    • éviter la politique de l’autruche / les approches idéologiques
  • cryptographie et gestion de clefs
    • ne pas se reposer sur ses lauriers
    • « la cryptographie c’est ce qui reste quand toutes les protections ont disparu »
    • le plus difficile à changer dans un système opérationnel
  • faciliter la SSI : ergonomie et supervision
    • l’amélioration de l’ergonomie faciliterait l’adoption de solutions sécurisées
  • fédération d’identités
    • réponse à une problématique d’ergonomie
    • crucial pour l’identification distante
    • éviter la politique de l’autruche
    • vraiment de la recherche à faire
      1. référentiel de la DCSSI pour l’authentification distante (proposé à l’AFNOR)

21.1.6. Fondations de la SSI

  • formats de données et protocoles
  • systèmes d’exploitation
    • anti-virus doivent être « éradiqués » (pas la réponse appropriée)
  • développer une masse critique pour avoir une communauté à même d’avoir de l’influence. Communauté mêlant recherche et industriels
  • défi SEC&SIø: Système d’Éxploitation Cloisonné et Sécurisé pour l’Internaute
    • appel à projet de l’ANR
    • 6 mois de conception pour proposer une configuration linux
      1. dédiée à l’internaute
      2. dédiée aux opérations sensibles (banque, télé-déclaration, messagerie signée)
    • 6 mois d’évaluation
      1. par attaque théorique ou pratique
      2. arbitrage DCSSI
  • trois challengers :
    • OSOSOSOS
    • Safe OS
    • SPACLik
  • bientôt site de référence

21.2. Avis / commentaire

Comme pour la première conférence, toute ressemblance avec des situations connues ne serait que purement fortuite…

J’ai bien aimé la mise en exergue de l’importance de l’OS… SELinux rulez ;)

Je me demande dans quelle mesure le développement de politiques SELinux pour faire un kiosque (contexte propre à Iceweasel et les deux ou trois plugins autorisés) de Dan Walsh répondrait au défi.

Très intéressant.

On sent l’intervenant légèrement désabusé par un certain nombre de comportements de nos dirigeants.

22. Dynamic malware analysis for dummies

par Philippe Lagadex / NATO/NC3A

22.1. Notes

Scénario type : gestion d’incidents – fichier infecté, on veut savoir ce que fait le code malveillant rapidement, sans avoir besoin d’une analyse exhaustive – temps réduit, pas forcément expert ASM

But de l’analyse

  • est-ce vraiment malveillant ?
  • est-ce un fichier connu ou une attaque ciblée ?
  • etc.

Etapes de l’analyse

  • désassemblage
    • vue complète et détaillée du code
    • mais besoin d’un expert, et ça peut prendre du temps
  • débogage
    • vision pas à pas de l’exécution
    • complémentaire du désassemblage
  • exploration de fichier
    • éditeur hexa
    • recherche de chaînes
    • explorateur de formats
    • file carving / forensic
    • anti-virus
    • scanners d’exploits
    • extraction simple, mais ne fonctionne pas si camouflage
  • analyse dynamique runtime : exécuter le code pour observer son fonctionnement
    • aperçu rapide et « facile »

Exemple

En cas d’attaque . exploration de fichier . analyse dynamique

On obtient des résultats partiels mais rapides. Si on a plus de temps, on passe au désassemblage et au débogage.

Pour ce genre d’ananlyse un laboratoire détient (au moins) :

  • sandnet = sandbox + internet simulé
  • deux machines (virtuelles ou non) connectées
  • un serveur
    • passerelle par défaut
    • serveur DNS
    • répond sur toutes les IPs
    • faux serveurs
    • enregistre toute l’activité réseau
  • une machine victime
    • OS brut, pas d’AV/firewall
    • compte administrateur
    • enregistrement des actions locales en temps réel ou par delta avant/après

Outils :

  • rescan
  • scalpel
  • hachoir
  • fess / officecat
  • sysanalyzer
  • anubis
  • cwsandbox
  • norman sandbox
  • joelbox
  • decalogue.info/sstic08/

22.2. Avis / commentaire

Conférence m’ayant donné l’impression que je n’étais peut-être pas si nul. Bon en même temps c’est pour dummies ;)

D’autant que pas mal des techniques proposées sont largement utilisables pour d’autres besoins du SI.

Tags: , ,
Posted in Security | 5 Comments »

Scuttle collaborative bookmarks manager needs a captcha

May 6th, 2008

We operate a nice collaborative bookmarking site for our little community. We use the ’scuttle’ Debian package of the Scuttle social bookmarking system and it serves our needs well. But lately we have seen it inundated by torrents of spam unchecked by the slightest user registration control. Not checking whether the poster is human was all right twenty years ago, but in an age where most of the traffic is spam it is looking for trouble.

Some sort of registration validation has been requested more than three years ago, but progress of the project has been quite slow – apparently in part because Marcus Campbell prefers working alone to avoid having to manage other developers and conflicting agendas.

Last year, Telgorn submitted a patch to add captcha for user registration. But is probably stands no chance of inclusion into the main branch : Marcus Campbell has stated two years ago that he “will not be adding captcha” to Scuttle.

For now, having no patience for spam and only having to support a tiny community, I resorted to remove user registration from Scuttle and manage the registrations manually. The result can be witnessed at the modified registration page, and I’ll post this trivial patch if anyone asks. But for any significant community this is not an acceptable fix.

As Telgorn’s captcha patch shows, adding that functionality to Scuttle is simple. The question is rather about the future of Scuttle. Scuttle is a very nice tool, and compatibility with the del.icio.us API is a wonderful way to open it to a world of interactions. But not including CAPTCHA is a death wish for a tool that can only thrive if larger community can use it without overwhelming their administrative staff with spam cleanup duties.

The network effect inherent to social bookmarking grows faster than the number of users – which means that larger sites are the one who benefit the most from Scuttle. Scuttle is quite fast and I guess it could handle large crowds… If only it was capable of dealing with spam.

Will someone fork Scuttle or will it be soon confined to small communities ? Time will tell, but for now the future is incertain as far as I can see.

Posted in Security | 2 Comments »

« Older Entries