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.