Copy Link
Add to Bookmark
Report
N0RoUTE Issue 3-22 Rumeurs a propos de PGP
Pouvons nous encrypter nos donnees ?
Si tu t'ennuies, tu peux suivres ca :)
Voici un extrait d'une mailing list, suite a une rumeur concernant une
autorisation d'utiliser PGP en France. Cela a donne lieu a un tas de
reponses. J'ai suivi tout ca en temps reel, et c'est assez amusant les
reaction :)
Voila on attaque, ca commence pas un mail tel que :
Bonjour,
Nous recherchons un(des) logiciel(s) capable(ent) d'empêcher la lecture
indiscrete de certains fichiers/répertoires sous un environnement w95?
Cette protection viserait les répertoires et fichiers contenant les
données médicales saisies dans les logiciels médicaux.
...
-- et une reponse --
Bonjour,
Si une solution avec mot de passe est envisageable, il est possible
d'utiliser de nombreux produits non-commerciaux. Je pense tout
d'abord à PGP qui est public et qui fut donc analyse en profondeur
par de nombreux experts.
-- ensuite la reponse qui a mit toutes les reactions --
PGP (Pretty Good Privacy), un logiciel de cryptage très puissant, yet
convivial, vient d'être autorisé à la vente en France.
Il répond à vos besoins à priori. Par contre je ne sais pas qui le
distribue.
-- et enfin les reactions --
Quels textes S.V.P ?
Au dernieres nouvelles, PGP etait interdit d'utilisation. Seul
l'authentification etait 'toleree' par PGP.
-- --
Hein, quoi, PGP autorisé à la vente en France !.. ???
Où avez-vous vu celà ? Quelles sont vos sources ?
Allez donc demander une autorisation au SCSSI, vous verrez ce qu'ils vous
répondront !
C'est bien la meilleure de l'année celle-là...
-- Reaction la plus courrante --
D'ou vient cette information ?
-- --
Hola !
Enfin un sujet qui suscite l'interet general ..;-)
Concernant l'info selon laquelle PGP avait recu un certain agrement en
France, j'ai vainement cherche a la retrouver, s'agissant d'une des
nombreuses publications electroniques que l'on recoit.
Cependant, elle stipulait que sous certaintes conditions,
l'utilisation
de PGP pouvait être consentie (probablement en laissant votre cle privee
chez l'epicier du coin). A verifier de toute facon.
-- --
Et vous ne la trouverez certainement pas, car elle est fausse !
PGP reste interdit en France.
Pour tous renseignements, écrire au SCSSI....
Avant de balancer de fausses infos. dans ce genre, vaut mieux
vérifier et croiser ses sources...
-- --
PGP est un freeware.
PGP est un des programmes de cryptage les plus sûr actuellement, et ne
risque
pas d'être authorisé en france.
Il existe d'autres logiciel également freeware et trés sûr qui
permettent de crypter un systeme de fichier (secdev, secdrv, sfs ...)
qui seraient plus adaptés mais qui ne risquent pas non plus d'être
authorisés en France.
Je vois 3 possibilité:
1 - Ne pas protéger son informatique, ne pas faire de commerce
electronique, ne pas authentifier ses correspondants
2 - Etre hors la loi
3 - Changer de pays
-- --
faux
En attendant la parution des decrets d'application de la
loi de 1996 -CA-, PGP-renater est autorise en france.
Le chiffrage est reglemente (~=interdit) en france. Mais toutes
fonctions de hachage (signature, scellement, ..) est libre
d'utilisation. PGP-renater est une version "light" du code de pgp qui
ne permet pas de faire de la confidentialite mais qui fait tres bien
de l'integrite et de l'authentification (==meme fonction et codage que
son frere).
-- --
Non, vrai....
Lorsque l'on parle de PGP, il s'agit bien sûr du soft de
Philip Zimmermann, et non pas d'une mouture franco-française adaptée
et "castrée" pour la circonstance !
Ce PGP-Renater a été développé par qui... Renater ? Le code source
est-il public ? Le soft est-il disponible pour le public et où ?
Si l'on ne peut pas faire de confidentialité.....
Bref, il ne s'agit en rien de PGP tel que nous l'entendons généralement.
-- --
Bonjour,
J'aimerais apporter ma contribution a cette discussion sur deux points :
- concernant PGP, il n'est toujours pas (a ma connaissance) agree par
le SCSSI, mais le fameux article que recherchait Pierre Pezziardi est
peut-etre un article du 01 Informatique du 13.06.97 ou il est ecrit que
le gouvernement des USA vient d'accorder a la societe PGP le droit
d'exporter des technologies mettant en oeuvre des cles de cryptage
de 128 bits (p. 30, "Le programme PGP bientot disponible en France ?")
- pour preciser ce que disait Arnaud Tarrago :
en France, la fourniture, l'exportation et meme la simple utilisation
de methodes de chiffrement sont reglementees par l'article 28 de la loi
du 29.12.90 sur la reglementation des telecommunications. Selon le cas,
une declaration ou une demande d'autorisation prealable doit etre
effectuee aupres du SCSSI :
. declaration pour les procedes d'authentification / integrite,
. demande d'autorisation prealable pour tout le reste, et particulierement
pour les moyens permettant d'assurer la confidentialite de l'info.
Cette demande d'autorisation passe par le depot d'un dossier detaille,
avec une partie technique comportant une description des algorithmes ou
autres procedes cryprographiques.
-- --
Exact ! Et ceux qui ont essayé de la demander pour PGP se sont
toujours vu répondre NIET !.... et pour cause...
-- --
Il est illégal (auxs Etats-Unis) exporter un PGP à France. L'exception
unique à ce point dans loi des Etats-Unis est pour américain a possédé des
compagnies fournir PGP pour l'emploi de ses filiales en France. Allez à
www.pgp.com
-- --
Au SCSSI d'agir maintenant...
Sachant que le SCSSI a deja habilite les produits netScape Navigator
et Internet Explorer pour l'utilisation de SSL, mais avec 40bits, pas
128.
-- --
J'ai ete amene, il y a quelques mois a rencontrer les gens sur SCSSI
ainsi que ceux d'un certain ministere charge des licenses d'exportations
pour les logiciels comportant des crypteurs.
Voici la conclusion des differentes rencontres que j'ai eu :
1 - La liberalisation des marche fait que, plutot que d'opter pour une
autorisation au cas par cas, les pays de l'OCDE ont conclu un accord
visant a ce qu'une autorisation d'export donnee par un pays soit
automatiquement acceptee comme droit d'utilisation et d'importation par
les autres, dans la limite des contraintes.
2 - Les autorisations d'export sont accordes sous les conditions suivantes :
- Negciation des cles de session : Pas de limite
- Crypteur : Algorithme connu (ou depose)
- Cle de cryptage : Entropie max : 40 bits.
- Domaine d'utilisation
LA TECHNIQUE DERRIERE TOUT CA :
- Le but ultime recherche, par tous les gouvernements, est de pouvoir
decoder une transmission, non en temps reelle pour faire de l'espionnage
(comme certain messages paranoiaque l'on laisser entendre sur la liste
firewall recement), mais au fins d'enquetes. Est clairement vise :
l'utilisation frauduleuse par des personnes prives des moyens autorises
d'une entreprise pour mener des actions illegales. En gros, c'est de
l'accumulation de preuves. (Note : Le domaine de l'espionnage est plus
efficace avec des moyens physiques, style service de renseignement
Portuguais).
- Ce que l'on sait faire en terme de decodage, c'est passer 3 a 5 jours
pour trouver une clee de cryptage de 40 bits. 41 bits double le temps, 56
bit donne environ 500 ans avec les memes moyens quand a 128 bits, on est
en plein dans le domaine des contraintes thermodynamiques avec des ordre
de grandeur de 10^10 fois l'age de l'univers !!. Bon, les gouvernements
visent a permettre de decoder une transmission en 2-3 jours. D'ou 40 bit
imperatifs vu que les crypteurs actuels ne sont attaquable qu'en force.
Ceci nous explique les points suivants :
- Negciation des cles de session : Pas de limite
Puisque l'attaque portera sur le crypteur, l'etablissement de la cle de
session n'a aucun interet. Vous pouvez toujours vous amuser a faire
tourner vos ordinateurs pendant des semaines pour trouver des nombres
premiers entre eux de 2048 bits ou plus, le decryptage ne portera pas
dessus. Ceci explique la 'tolerance' quand a l'utilisation de PGP pour
l'authentification. (Note : Bien evidement, signer un message du style
'hello world' avec une signature de 2 Koctets attirera l'attention !!).
- Crypteur : Algorithme connu (ou depose)
Si le crypteur n'est pas connu, son algorithme doit etre depose. De meme,
une version du logiciel doit etre fourni. Les services de renseignements
se communiquent entre eux les logiciels en question, ne vous en faites
pas, c'est toujours ca d'economise en timbre.
- Cle de cryptage : Entropie max : 40 bits.
Ici, le mot cle est 'entropie'. Tout cryptage utilisant une cle plus
longue doit etre : soit consigne (et les procedures ne sont pas encore
bien etablis ce qui fait qu'il faut pouvoir motiver aupres du SCSSI la
necessiter d'employer des cles consignes. tres dur !!) soit avoir une
partie des bits de la cle qui soit une fonction lineaire de la partie
aleatoire, celle-ci devant etre, au maximum de 40 bits. Grosso modo, on
peut dire que, par exemple, sur une cle de 56 bits, 16 bits doivent etre
'redondants' et fonction des 40 autres.
- Domaine d'utilisation
Le developpeur du logiciel doit etre :
- Une SS2I (societe informatique) editeur
- Une societe integrant des logiciels (OEM)
- Une societe informatique travaillant a facon.
- Le service informatique d'une entreprise
A croiser avec :
- Un logiciel d'utilisation vertical
- Un logiciel general integrant un cryptage pour une fonction donnee
- Un logiciel de cryptage general
Cette clause indique la capacite du logiciel a etre detournee de sa
fonction d'origine pour transmettre des messages 'humain'. Ainsi, il est
facile d'obtenir une autorisation pour un logiciel cryptant une
transmission SNMP, par exemple, alors qu'un logiciel cryptant une liaison
SMTP (mail) obtiendra plus difficilement son autorisation et qu'un
logiciel general de cryptage (type PGP) n'a quasiment aucune chance.
A noter que l'echelle de chance de se voir refuser une autorisation en
fonction de l'editeur crois dans l'ordre suivant :
- Le service informatique d'une entreprise
- Une entreprise hors de l'informatique
- Un etablissement public
- Une association
- un particulier
En gros, on peut dire qu'une SS2I fabricant un produit avec une fonction
annexe de cryptage pour les liaisons EGP aura instantanement son
autorisation alors qu'un particulier editant un logiciel du type 'super
crypteur de la mort qui tue et qui sert a tout' n'a aucune chance.
APPLICATION
A la lumiere de tout ceci, et si le gouvernement Americain a bien donner
une license d'export pour 128 bits, on peut avoir les cas suivants :
1 - La transmission est HYPER specialisee (type carte bancaire, 12
chiffres, 1 transmission max par minute, etc.... bref toute contrainte la
rendant virtuellement indetournable).
Dans ce cas, ca va renacler un peu mais on peut envisager que le
reste des pays de l'OCDE disent d'accord. Clairement, sera impose
l'impossibilite de faire des transactions superieures a 100$ ou quelque
chose de ce style.
2 - La transmission n'est pas specialisee, elle peut etre detournee avec
ou sans collaboration des deux parties (client et serveur)
Il y a alors deux cas possible :
2a - La cle possede une entropie de 40 bits.
Dans ce cas, pas de problemes. La fonction permettant
l'etablir les 128-40 = 88 bits redondant sera connue des services de
renseignement des pays de l'OCDE. A noter que, dans ce cas, autant
utiliser le 40 bits puisque le jours ou cette fonction viendra a etre
connue, la complexite du probleme sera la meme.
2b - La cle fait vraiment 128 bits
Il y a alors deux cas :
2a1 - La cle public de session est donnee auX gouvernementS
(OCDE)
Toujours pas de probleme pour l'autorisation mais alors
la securite devient tres mauvaise : le jour ou cette clee est connue,
tout transmission devient decodable en temps reel, tandis que si c'est la
fonction de redondance qui devient connu, vous etes quand meme confronte
a devoir casser 40 bits.
2a2 - Seul le gouvernement Americain la connait.
Alors les autres pays de l'OCDE crierons au non respect des
accords sur les licenses d'exportation et interdiront explicitement
l'importation et l'utilisation dudit logiciel sur leur territoire. D'ou on
aura un logiciel autorise d'export sans possibilite de l'importer et de
l'utiliser.
Voila. Les paris sont ouverts. Les reactions Europeennes vont
imanquablement nous donner des indices quand au realites techniques de
cette license d'exportation, si tant est qu'il ne s'agisse pas d'un bruit
de couloir.
Merci de votre attention, have a nice day.
(PS : Bien evidement n'hesitez pas a relever toutes les conneries que
j'ai pu ecrire (sauf pour l'Orthographe, dont je vous prie de m'excuser,
mais la, j'ai pas le temps...)).
-- --
Je tiens au nom de tous les adhérents de Micro-Médic à remercier
L'ENSEMBLE des intervenants sur la question de la sécurité des données
sous windows95.
Le débat fut très interressant. Qu'avons nous retenu ?
PGP (Pretty Good Privacy) semble selon vous le plus fiable en terme de
sécurité.
PGP est interdit en FRANCE sauf autorisation spécifique
PGP difficile d'ergonomie puisqu'il faut donner un nom à chaque cryptage
de fichiers.
Seule une solution intermédiaire entre le "password" des fichiers ZIPés
et les algorythmes fiables mais trop chers (PC/DACS95) peut séduire les
médecins et satisfaire la CNIL.
Nous allons donc tester les différents produits cités dans les
discussions.
Notre problème n'est pas tellement de trouver un cryptage infaillible
mais plutôt de trouver une interface qui permette un cryptage/décryptage
au vol. L'utilisation de cet outil doit être des plus simple pour être
accessible et utilisé quotidiennement par l'ensemble des médecins
informatisés ('les plus sensibilisés comme les plus récalcitrants à
l'informatique médicale)
Windows NT4 est certes plus protégé que Windows95 mais hélas les avis
divergent sur la réalité de cette protection....alors que penser ? La
CNIL considère telle qu' une protection NT4 est suffisante pour des
données médicales ? Nous en doutons
Nous manquerons pas de publier sur cette liste une synthèse de nos tests
afin de vous soumettre nos appréciations et opinions.
N'hésitez pas à nous faire part d'opinions ou connaissances susceptibles
de nous aider à protéger ce qui sera votre futur dossier médical... ;-)
-- --
Je voudrais mettre un bemol à ce débat PGP centrique.
OK PGP tient la route en matière de sécurité au sens technique
NOK: le modèle de confiance PGP (chaine de cetrification de proche
en proche) ne tient en général pas la route dans un contexte
professionnel. Je ne suis pas sûr que pour une appli dans le domaine
de la santé, le modèle PGP qui ne permet pas d'allouer/identifier
les responsabilités soit adapté. sans connaitre le contexte précis,
j'inclinerais même vers : totalement innapplicable
Quand on parle de crypto asymetrique
il y a le coté technique, algo etc...
il y a tout l'aspect certification: qui se porte garant de qui ou quoi?
et donc qui assume quand ça "tourne mal"
Je ne pense pas que dans la plus part des contexte cela n'ait le moindre
sens de s'occuper du 1) tant que le 2) n'est pas résolu.
Par ailleurs comme effectivement dit dans ce message, tout cela n'est
pas vraiment en phase avec le besoin ce crypto de fichiers sur des disques
tels que je le comprend dans ce contexte.
-- --
Voila.
