Salut Jérémy,
Jeremy Dubreil <[EMAIL PROTECTED]> writes:
>> Et nos
>>contraintes de sécurité seront probablement *très* spécifiques.
>>
> Elle sont les mêmes pour tout les systèmes de vote, sur lesquels il y a
> pas mal de travaux
Pas toutes les contraintes. Par exemple, demexp autorise le changement
de vote à tout moment, ce qu'aucun des sytèmes « classiques » ne permet
et ce qui change certaines contraintes ou mécanismes de sécurité
(comment annuler le vote précédent en gardant l'anonymat ?).
> J'ai lu le rapport de projet de l'ENST Bretagne qui donne des idées pour
> formaliser les politiques de sécurité d'un système de vote. Le vote
> électronique est souvent pris comme exemple et le modèle Or-BAC de
> Cuppens & Co est tout à fait adapté pour formaliser les contraintes d'un
> tel système. Seulement, la problématique est de passer d'une
> description macroscopique des contraintes à une idée de preuve des
> algos ou du programme (en COQ ou par model checking par exemple) qui
> partent d'une desription des contraintes de sécurité sous forme
> d'automate ou de logique temporelle. Dans une certaine mesure s'assurer
> qu'un vote est bien pris en compte ne fait pas intervenir
> l'environnement, OS, réseaux ..., qui sont supposé marcher et dont on
> peut avoir un modèle très abstrait.
Avoir un modèle abstrait serait déjà pas mal pour démarrer.
> Seulement, pour un système Linux
> actuel, on ne peut pas faire l'hypothèse qu'un cheval de troie ou même
> Skype est incapable d'inférer des informations, même partielles, sur les
> actions du votant. On a même assez peu d'idée de ce que qu'un programme
> espion peut inférer d'un autre programme.
Oui, enfin on part de l'idée que côté serveur il n'y a que demexp qui
tourne. C'est vrai que côté client, on peut avoir un skype espion, mais
à ce moment là, aucun OS grand public (Windows, Linux, MacOS X) n'est
adapté à ce genre de contrainte de sécurité.
> En dehors de l'idée d'un CD Live qui ne fait tourner que Demexp, il
> existe des solutions pour "envelopper" les processus par domaine de
> confiance. Par ex : domaine Interface Utilisateur, domaine skype qui ne
> communique avec le domaine Utilisateur que de manière explicite (et avec
> contenu crypté et enveloppe XML pour D-BUS, Bonobo ou DCOP par
> exemple). Ceci est fait afin d'éviter la création de canaux cachés non
> souhaitables entre les différents programmes.
Mmmm, à vue de nez, je n'ai pas l'impression que chiffrer les canaux de
communication empêche les canaux cachés qui reposent justement sur des
moyens indirect : perception du temps, consommation mémoire, etc.
> La solution la plus avancé
> est SELinux initié par la NSA qui permet de mettre tout ça en
> oeuvre. J'ai pas encore compris les détails (en 1 mois de travail)
Si tu peux faire un exposé sur SELinux, ça m'intéresserait (et
probablement du monde dans Gulliver, le LUG local rennais). Mais de ce
que j'en ai vu, SELinux est un bouzin trop complexe que seuls des
experts arrivent à comprendre. Et en sécurité, qui dit complexité dit
erreurs assurées.
> puisque qu'il faut que je commence déjà par bien comprendre comment
> fonctionnent de la gestion des processus en théorie des OS pour
Tu cherches quoi exactement ? Pour les systèmes Unix, il y a un
excellent bouquin pour comprendre leurs fonctionnements : _Unix
Internals_, de Uresh Vahalia (Éd. Prentice Hall).
> comprendre dans quelle mesure ils peuvent interférer de l'information
> l'un sur l'autre pour avoir une idée de comment et ou mettre en place un
> cloisonnement, i.e. ce que fait SELinux.
Regarde aussi du côté du noyau Mach. Au début des années 90, l'armée
américaine avait fait une version sécurisée de Mach 3.0. Mais si je me
souviens bien, pour un traitement approfondi des canaux cachés, il faut
avoir le processeur qui va bien aussi.
> Après on peut avoir une idée de
> preuve qu'il n'y a pas de fuite d'information quand au nom du vote et du
> vote ...
Mouais, les canaux cachés, c'est probablement le dernier truc que je
regarderais sur un système avec un OS classique et un processeur
généraliste : ça doit fuire de partout avec les caches, la gestion
mémoire, l'utilisation du processeur (cf. le thread relatif à
l'hyper-threading et les canaux cachés sur linux-kernel).
Amicalement,
d.
PS : on devrait faire une réunion cette semaine, mais on ne sait pas
encore quand. :) Si tu as des contraintes, fait le nous savoir.
--
pub 1024D/A3AD7A2A 2004-10-03 David MENTRE <[EMAIL PROTECTED]>
5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A
--
Liste de discussion demexp-fr.
Pour se désinscrire, cliquer sur le lien ci-après.
mailto:[EMAIL PROTECTED]
