Sociétés?

bob wrote:

Bonsoir à tous,

existe t-il des boites en france spécialisées dans la cryptographie/
cryptologie/cryptanalyse/cryptosystème ?
Si oui, lesquelles?

Merci.

Bonsoir,

Y a MSI.

Consulte le site pour voir les partenaires:
http://www.msi-sa.net/fr/accueil.php?

Sinon, à ma connaissance, la plupart des grandes boîtes hi-tech en
France ont des laboratoires R&D/spécialistes en cryptographie:
BULL, FT, Cap Gemini, IBM, GEMPLUS

Nicolas

b0n0 wrote:

Bonsoir,

Y a MSI.

Consulte le site pour voir les partenaires:
http://www.msi-sa.net/fr/accueil.php?

Sinon, à ma connaissance, la plupart des grandes boîtes hi-tech en
France ont des laboratoires R&D/spécialistes en cryptographie:
BULL, FT, Cap Gemini, IBM, GEMPLUS

Merci bien pour ta réponse!

--
Bob

http://www.keynectis.com/ste_pourq.htm, société de certification
électronique française (service)

Bonsoir à tous,

existe t-il des boites en france spécialisées dans la cryptographie/
cryptologie/cryptanalyse/cryptosystème ?
Si oui, lesquelles?

Merci.

On Wed, 2 Mar 2005, Roland Le Franc wrote:

http://www.keynectis.com/ste_pourq.htm, société de certification
électronique française (service)

On peut aussi citer Cryptolog (http://www.cryptolog.com/), Thomas Pornin
n'oserait peut-être pas le faire lui-même...
Ils ont une brochette de très bons cryptologues en stock. ;)

existe t-il des boites en france spécialisées dans la cryptographie/
cryptologie/cryptanalyse/cryptosystème ?
Si oui, lesquelles?

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Désolé, je suis vraiement trop con (mais je l'admet), j'y comprends rien
à ces "kill file", pour moi c'est juste une sorte de censure/mépris public.
-+- GA in Guide du Neuneu d'Usenet - N'avouez jamais. -+-

On Wed, 2 Mar 2005, Roland Le Franc wrote:

On peut aussi citer Cryptolog (http://www.cryptolog.com/), Thomas Pornin
n'oserait peut-être pas le faire lui-même...
Ils ont une brochette de très bons cryptologues en stock. ;)

je n'en doute pas une seconde ... but ... à regarder leur ExaMail:

<<à chaque utilisation, le plug-in Cryptolog récupère automatiquement
les certificats sur les serveurs, et les déchiffre localement pour
pouvoir signer et chiffrer le message.>>

il me semble que ce n'est pas un cert qui doit descendre pour signer
mais un P.12 complet, par ailleurs pour chiffrer à l'intention de mon
destinataire il me semble devoir posséder sa clé publique et non mon
cert perso.

au dela des raccourcis (nécessaires?) de cette présentation, quelle est
ici la (bonne) raison de ne pas utiliser une vraie carte à puce plutot
que cette carte à puce virtuelle (même brevetée) ??

le cert descends chiffré, soit, mais comment?
- dans une tunnel SSL ? ouvert avec quel cert? un autre qui descends
chiffré ? ou n'importe lequel pour peu que l'on est transmis un
user/password texte valide? (il me semblait que pré-disposer de son cert
était un bon moyen d'établir du SSL v.3 bien propre).

- dans un tunnel-maison DH ? comment sont stockés les seed communs ? en
clair dans le plug-in? chiffré dans un process kernel ?

on lit également <<Cryptolog ne peut accéder à la forme déchiffrée des
certificats numériques>>, donc la clé de déchiffrement du P.12 user est
sur son PC uniquement - n'est-ce pas contradictoire avec un système
server-based ?

est-ce à dire que le cert descends toujours chiffré avec la même clé ...
simplement présente dans la registry de ce PC ?

indépandemment de toutes les bonnes pratiques qui ont du être
installées, peut-on seulement démontrer qu'un code sensible (la clé
privée de signature) peut s'exécuter sainement en milieu hostile ?

Sylvain.

According to Sylvain <noSpam@mail.net>:

je n'en doute pas une seconde ... but ... à regarder leur ExaMail:

On a de bons cryptologues, mais pour le web-design, il nous manque
encore quelques capacités. C'est surtout une question de main d'oeuvre.
Notre site web est notoirement peu clair et en retard. On y travaille.

<<à chaque utilisation, le plug-in Cryptolog récupère automatiquement
les certificats sur les serveurs, et les déchiffre localement pour
pouvoir signer et chiffrer le message.>>

il me semble que ce n'est pas un cert qui doit descendre pour signer
mais un P.12 complet, par ailleurs pour chiffrer à l'intention de mon
destinataire il me semble devoir posséder sa clé publique et non mon
cert perso.

L'idée générale est qu'on a un système de stockage distant de données
arbitraires (des blobs binaires, en gros). Ces blobs sont chiffrés
symétriquement avec une clé que les serveurs de stockage _ne possèdent
pas_. Ultimement, tout revient à une clé symétrique maître (pour chaque
utilisateur) chiffrée symétriquement avec une clé dérivée du login et
mot de passe de l'utilisateur (mot de passe que seul l'utilisateur
connaît). Côté client, le seul stockage permanent est le mot de passe
de l'utilisateur, qui est stocké dans la tête de l'utilisateur et nulle
part ailleurs.

Après, il y a des finasseries pour faire les choses de façon sûre et
efficace : séparation des serveurs en deux (afin qu'un seul serveur
minimal et entièrement reprogrammé à la main soit en possession non pas
du mot de passe, mais d'une donnée permettant de faire une attaque par
dictionnaire sur le mot de passe -- l'autre serveur n'a rien de tel
et peut conceptuellement être externalisé sans problème de sécurité),
initialisation avec un protocole genre PBKE en un aller-retour,
encapsulation dans du HTTP afin de mieux passer les proxys, etc...

Ce qui est stocké dans ce système (le contenu des blobs) est donc de
la responsabilité du logiciel client. Notre produit phare est un banal
plugin qui stocke des certificats X.509 et des clés privées, et les
fournit aux logiciels qui utilisent ce genre de choses (CSP pour la
CryptoAPI de Microsoft -- donc Outlook, Internet Explorer, etc -- et
PKCS#11 pour Netscape, Mozilla, Firefox... la version PKCS#11 marche
aussi sous Linux et FreeBSD, et potentiellement tout système Unix
décent).

On a aussi pas mal de code Java (compatible JDK 1.1 !) qui parle ce
protocole. On a notamment un démonstrateur sous la forme d'un client
mail complet (lecture des mails en IMAP, envoi en SMTP, visualisation --
incluant les mails en HTML et les images en pièce jointe -- et édition)
capable de faire des courriers chiffrés et/ou signés en S/MIME, en
utilisant notre système pour stocker les clés privées et certificats.


En résumé : rien n'est stocké sur le disque dur du poste client ; le
stockage permanent est sur des serveurs sous une forme chiffrée par
des clés auxquelles les serveurs n'ont pas accès.

au dela des raccourcis (nécessaires?) de cette présentation, quelle est
ici la (bonne) raison de ne pas utiliser une vraie carte à puce plutot
que cette carte à puce virtuelle (même brevetée) ??

Les raisons principales sont :

-- La robustesse : une carte à puce, ça peut tomber en panne (rarement,
mais ça arrive) et ça peut se perdre (quand on se fait voler son
portefeuille par exemple). Dans notre système, l'utilisateur transporte
son mot de passe dans sa tête, et il le tape tous les jours, donc
la perte d'accès à ses données est très peu probable. Les serveurs
eux-mêmes, étant centralisés, peuvent avoir une architecture redondante,
des backups plusieurs fois par jour, et du RAID.

-- Le nomadisme : comme le client est purement logiciel, il peut marcher
partout. Surtout pour les applets Java : pas d'installation préalable.
Et j'insiste sur le fait qu'on fait du code Java compatible avec la JVM
Microsoft telle qu'incluse dans IE 5.5 (j'insiste parce que ça n'a rien
d'évident : très peu de classes standard, et des bugs à contourner).

-- Le coût : pour les gros déploiements (genre 300000 utilisateurs),
notre solution est beaucoup moins chère que la fabrication des cartes
(et il ne faut pas oublier les lecteurs de cartes !).

Quant au brevet, il existe pour des raisons juridiques et commerciales
que je ne maîtrise pas, car je ne suis qu'un scientifique.

indépandemment de toutes les bonnes pratiques qui ont du être
installées, peut-on seulement démontrer qu'un code sensible (la clé
privée de signature) peut s'exécuter sainement en milieu hostile ?

À un certain niveau d'hostilité, on ne peut pas faire grand chose de
toutes façons. Si on fait une signature avec une carte à puce, branchée
dans un lecteur relié à un ordinateur compromis, l'utilisateur n'a
aucune garantie que ce qu'il voit à l'écran est bien ce qui est signé
par la carte.

Donc nous partons de l'hypothèse que, pendant l'utilisation par le
client, le poste local n'est pas compromis. C'est en gros la même
hypothèse que pour tous les systèmes à base de carte à puce, sauf ceux
où la carte à puce dispose de son propre clavier (pour rentrer le code
PIN) et de son propre écran (pour afficher ce qu'elle est en train de
signer) : de tels systèmes sont plus sûrs, mais je dois dire que je
n'en ai jamais vus en vrai.


--Thomas Pornin

Thomas Pornin wrote:

[...]. Dans notre système, l'utilisateur transporte
son mot de passe dans sa tête, et il le tape tous les jours, donc
la perte d'accès à ses données est très peu probable.

Donc la robustesse est celle du mot de passe.

Bon, j'imagine que vos serveurs bloquent dès que plusieurs erreurs sont
commises, ce qui protège contre l'attaque par dictionnaire sans
collaboration de l'utilisateur, mais il reste que toute les attaques où
l'on arrive à voler son mot de passe exposent ensuite définitivement
sa clé privée ...

[...]
Et j'insiste sur le fait qu'on fait du code Java compatible avec la JVM
Microsoft telle qu'incluse dans IE 5.5 (j'insiste parce que ça n'a rien
d'évident : très peu de classes standard, et des bugs à contourner).

La version qui a tellement de failles de sécurité que tout poste
l'utilisant est garanti de récupérer un Trojan/Spyware en seulement une
paire d'heure de navigation sur Internet ? (1) Utiliser cette version
est impardonnable avec votre produit vu les risques cités plus haut.

-- Le coût : pour les gros déploiements (genre 300000 utilisateurs),
notre solution est beaucoup moins chère que la fabrication des cartes
(et il ne faut pas oublier les lecteurs de cartes !).

Mais ce n'est pas pour la clé privée le niveau de sécurité des cartes à
puce.
Si la sécurité du poste où la clé est utilisé n'est pas assurée, la clé
peut être volée. Un pré-requis que posent cependant aussi les profiles
de protection standard des logiciels de signatures, parceque de toute
façon si on remet cela en cause, il n'y a pas grand chose pour s'en sortir.
Et cela n'empèche que la solution a toute sorte d'avantage que tu
énumère, et que comme c'est correctement fait, vous serveur central ne
pouvez pas voler la clé.

Je vois un avantage réel à votre solution par rapport au certificat
logiciel, c'est qu'en volant le pc de quelqu'un, on ne peut pas
récupérer la clé. Ce que l'on pourrait obtenir avec un certificat
logiciel si on trouvait un moyen de faire en sorte que le mot de passe
résiste totalement à la force brute/dictionnaire.

Quant au brevet, il existe pour des raisons juridiques et commerciales
que je ne maîtrise pas, car je ne suis qu'un scientifique.

Je trouve ça pas terrible comme justification.
Ta société a décidé de poser un brevet là dessus, assume le carrément.
Le "je ne suis qu'un scientifique" est assez déprécié depuis Los Alamos.

(1) Je n'exagère pas. Cette faille est l'une des cibles préférée de
dizaines des variantes de spyware pour s'installer sur le poste
utilisateur. Un client avec cette faille a le niveau de sécurité d'un
serveur web non patché contre "code red".

According to Jean-Marc Desperrier <jmdesp@alussinan.org>:

Bon, j'imagine que vos serveurs bloquent dès que plusieurs erreurs sont
commises, ce qui protège contre l'attaque par dictionnaire sans
collaboration de l'utilisateur, mais il reste que toute les attaques où
l'on arrive à voler son mot de passe exposent ensuite définitivement
sa clé privée ...

Les serveurs limitent le nombre d'essais sur un compte à un certain
débit (quelques essais par tranche de 5 minutes, en gros). Bloquer
le compte permet à n'importe quel quidam de bloquer les comptes de
n'importe qui, ce qui n'est pas acceptable.

Sinon, ben oui, le concept général en cryptographie est que ce qui
distingue un utilisateur donné de n'importe qui d'autre, c'est son
accès à certaines données secrètes. Dans notre cas, on voulait que
l'utilisateur puisse emmener l'intégralité de ses données secrètes dans
sa tête, et des données qui résident dans la tête d'un utilisateur, on
appelle ça vulgairement un "mot de passe". Donc, si un utilisateur se
fait piquer son mot de passe, celui qui a volé le mot de passe est alors
indistinguable de l'utilisateur légitime.

Dans la pratique, le choix du mot de passe se fait lors de l'inscription
via une applet à nous, applet qui "encadre" l'utilisateur en rejetant
les mots de passes trop "faciles". Il y a une certaine alchimie à
trouver entre la sécurité recherchée et ce que l'utilisateur acceptera.


Dans tous les cas, la sécurité est le produit d'une procédure. Cette
procédure contient des éléments logiciels et c'est ce que nous
fournissons. Un vrai système sûr devra aussi contenir, entre autres, de
quoi rendre le poste client "raisonnable" (donc pas truffé de virus)
et une formation pour l'utilisateur. Ces différents éléments sont
importants, quel que soit le système technique, et il serait illusoire
de penser qu'on peut s'en passer.

C'est pour ça aussi que le fait que notre code Java tourne sur un vieil
IE 5.5 n'est pas un problème. Nous ne conseillons pas d'utiliser IE
5.5. Mais si un utilisateur le veut absolument, c'est son choix et sa
responsabilité.

Par ailleurs, ça veut dire aussi que notre code peut tourner sur des JVM
embarquées, i.e. sur téléphone portable (ces JVM là ont une bibliothèque
standard très réduite). On a d'ailleurs essayé (sur un émulateur) : ça
rame mais ça marche.

Mais ce n'est pas pour la clé privée le niveau de sécurité des cartes
à puce. Si la sécurité du poste où la clé est utilisé n'est pas
assurée, la clé peut être volée.

Mouaif. Si la sécurité du poste où une carte à puce est utilisée n'est
pas assurée, un attaquant peut faire signer en douce une centaine de
messages pendant les quelques secondes où la carte est présente et
débloquée. La nuance entre ça et le vol pur et simple de la clé est
quelque chose d'assez ténu.

Je suis d'accord que qualitativement et d'un point de vue académique, il
y a une grosse différence entre se faire piquer ses clés et se retrouver
à "seulement" signer une centaine de chèques en blanc ; mais, dans la
pratique, cette différence est négligeable. Les deux occurrences sont
autant pénibles l'une que l'autre.

Je vois un avantage réel à votre solution par rapport au certificat
logiciel, c'est qu'en volant le pc de quelqu'un, on ne peut pas
récupérer la clé.

C'est toute l'idée : calculs en local, mais aucun stockage local. Les
moyens de signature ne sont présent sur le poste client que pendant le
temps où le poste client est physiquement protégé par l'utilisateur
(quand il est devant, donc).

Ce que l'on pourrait obtenir avec un certificat logiciel si on
trouvait un moyen de faire en sorte que le mot de passe résiste
totalement à la force brute/dictionnaire.

Dans le modèle classique (signatures vérifiables par des tiers
quelconques selon une clé publique publiée dans un certificat), on peut
montrer que c'est impossible. Si j'ai une copie du contenu du disque
dur, je peux émuler un monde où j'essaye un mot de passe, j'obtiens un
clé, je fais une signature et je vois si elle est valide. Ce qu'on peut
faire, c'est appliquer quelques rustines :

-- rendre le processus long, en faisant une transformation du mot de
passe qui exige de hacher quelques méga-octets de données ;

-- changer le paradigme en faisant des signatures qui ne sont pas
vérifiables par tout un chacun, mais seulement par des entités
assermentées.

Cette deuxième rustine est ce que fait une boîte nommée Arcot.
Évidemment, ça n'est plus du X.509(*), et ça restreint beaucoup
l'utilisation potentielle. Par ailleurs, les serveurs assermentés
rendent nettement plus difficile la conformité du système aux
recommendations européennes sur ce qui peut être un système de
signatures "à valeur juridique". Enfin, ça ne fait que de la signature ;
on peut aussi avoir envie de _chiffrer_ des courriers, ce qui est une
autre affaire.

Je trouve ça pas terrible comme justification.

Justification ? Je ne justifie pas, justement(*). J'explique qu'il y
a un brevet et que la raison fondamentale de ce brevet m'échappe.
Enfin, on peut dire qu'il y a un brevet parce que j'ai dit oui, vu que
ça avait l'air d'être très important pour mon commercial. Quand il
rencontre d'autres commerciaux, ces autres commerciaux ont l'air très
impressionnés par le brevet, et ils trouvent ça aussi très important.
Personnellement ça me laisse songeur, mais après tout qu'en sais-je ?
Comme je l'ai dit, je suis un scientifique ; il est très possible que
quelque chose de fondamental (mais non scientifique) m'échappe à ce
sujet.



--Thomas Pornin


(*) Enfin, avec les couples OID + ANY, on peut _tout_ faire rentrer
dans X.509. Mais le résultat ne respecte pas le paradigme de signature
vérifiable par un tiers quelconque.

Thales

According to Sylvain <noSpam@mail.net>:

L'idée générale est [...]

merci pour ces éclairsissements!

Les raisons principales sont :

-- La robustesse : une carte à puce, ça peut tomber en panne (rarement,
mais ça arrive) et ça peut se perdre (quand on se fait voler son
portefeuille par exemple). Dans notre système, l'utilisateur transporte
son mot de passe dans sa tête, et il le tape tous les jours, donc
la perte d'accès à ses données est très peu probable.

ça s'use et donc ça tombe en panne, c'est acquis; mais on pare à cela
très bien en backupant les bi-clés dont l'utilisabilité doit être
garanti sur un long delai.

dans le même temps, 90% des blocaques liés à l'utilisation d'une carte
résultent d'une perte du mot de passe ... match nul sur ce point.

-- Le nomadisme : comme le client est purement logiciel, il peut marcher
partout.

le paradigme vaut aussi pour une carte, elle est utilisable avec un PC,
un PDA, un mobile, une "console-vidéo" ... mais cela demande un peu de
hard en plus.

À un certain niveau d'hostilité, on ne peut pas faire grand chose de
toutes façons. Si on fait une signature avec une carte à puce, branchée
dans un lecteur relié à un ordinateur compromis, l'utilisateur n'a
aucune garantie que ce qu'il voit à l'écran est bien ce qui est signé
par la carte.

est-ce que Word affiche réellement le contenu du fichier cliqué, est-ce

OE envoie réellement le mail que je viens de taper ?....

je pensais plus au fait que la clé privée est en clair dans le plug-in
après réception du cert; il est plus simple de la relire depuis cet
endroit que depuis une carte.

sauf ceux où la carte à puce dispose de son propre clavier
(pour rentrer le code PIN) et de son propre écran
(pour afficher ce qu'elle est en train de signer) :
de tels systèmes sont plus sûrs, mais je dois dire
que je n'en ai jamais vus en vrai.

la saisie du PIN est délégué à un lecteur-avec-clavier (certifié EMV),
le mode saisie par la carte n'existe pas; par contre on peut mettre un
capteur bio sur la carte (et faire le matching on card of course); pour
le display, on commence à faire des cartes avec une ligne LCD (pour les
PME nottament), on pourrait y faire défiler le clair à hasher mais bof...

Sylvain.