Source: http://shervet.free.fr/Crypto_fr.htm
Timestamp: 2017-11-23 09:30:16+00:00
Document Index: 98472020

Matched Legal Cases: ['§ 6', '§ 3', "l'article 9", 'arrêt ', 'arrêt ', 'arrêt ', 'arrêt ', 'arrêt ', "l'article 9", "l'article 28"]

Cryptographie Appliquée au Web
shervet@free.fr
Ce document, non contractuel, est la traduction HTML de mon mémoire de DEA
Les personnes intéressées par le sujet, ou souhaitant apporter des precisions
peuvent me contacter en privé:Sébastien Hervet
Chapitre I. Problématique.
Chapitre II. Rappel et définitions.
1 Les différentes techniques de chiffrement.
1.2 Systèmes à Clé secrète Clé secrète.
1.3 Systèmes à Clé publique Clé publique.
2 Attaques des protocoles.
2.1 Piratage trivial.
2.2 Attaque passive Attaque passive.
2.3 Attaque active Attaque active.
3 Contexte de la cryptographie.
3.1 Petit historique de l'évolution cryptographique.
3.2 Historique de la législation législation française.
3.3 Algorithmes et propriété intellectuelle.
4 Systèmes utilisés sur Internet.
4.1 IP Security Protocol (IPSEC).
4.2 Secure Sockets Layer Secure Sockets Layer.
Chapitre III. La cryptographie simplifiée.
1 Choix des produits.
2 Techniques envisagées.
3 Tests préliminaires d'implémentation.
3.1 Plug-In 4D.
(i) Réalisation d'un squelette.
(ii) Types de données et contraintes.
3.2 JavaScript & HTML.
(i) Réception et décryptage d'informations textes.
(ii) Emission Cryptée.
3.3 Filtre de sécurité.
(ii) Nécessités d'exploitation.
Chapitre IV. Réalisations pratiques.
1 Plug-In Plug-In.
1.1 Fonction Main Main()
1.2 Fonction container container.
1.3 Fonctions de cryptographie.
2 JavaScript JavaScript.
2.1 HTML et Javascript : la liaison.
2.2 Les algorithmes de chiffrement en JavaScript.
2.3 Le serveur des pages sécurisées.
3 Filtre Cryptographique Filtre Cryptographique.
3.1 Principe d'implémentation implémentation.
3.2 Réalisation technique.
Chapitre V. Synthèse
1 Tableaux récapitulatifs de la loi française.
2 Arrêté du 13 mars 1998, définissant la demande d'utilisation de la cryptographie.
3 Plug-In 4D : Sources C principales.
4 Chiffrement a la volée du flux HTTP.
5 Filtre de sécurité sous 4D.
Règle 10 - Focaliser la cible et ne pas en changer durant la bataille. Il faut que cette cible soit la plus petite, la plus précise et la plus représentative possible.
Saul Alynski, Dix Règles de survie en Société.
Information sur information, désinformation, espionnage industriel, transactions financières. Notre société fabrique et consomme de l'information en quantités considérable. L'informatique a depuis ses origines facilité le traitement et le stockage de ses données. Avec l'arrivée d'Internet et de ce qu'on appelle aujourd'hui communément le World Wide Web World Wide Web, la diffusion d'informations est devenue planétaire. L'émergence de toutes les technologies de communication a mis sur le devant de la scène le problème de la sécurité.
Que ce soit pour sécuriser des transactions bancaires (Commerce électronique), restreindre l'accès à des informations confidentielles ou encore empêcher la modification d'informations, différents problèmes sont apparus. On peut résumer la problématique, en différents niveaux de protection des communications :
- Protéger l'information sur son support de stockage. Ce premier niveau de protection permet d'éviter les yeux indiscrets (internes ou externes), mais permet aussi d'éviter la modification de ses informations.
- Protéger l'information sur son véhicule de diffusion. Ici le cas concret sera le réseau utilisé en Intra et Internet. Cette sécurité permet d'éviter la divulgation d'informations "gratuites" à qui sait écouter un réseau.
- Identifier les intervenants. Cette dernière option, beaucoup plus évoluée, met en uvre des techniques de chiffrement, mais aussi des notions de protocoles d'accord entre différentes parties.
Actuellement, on entend souvent parler de commerce électronique, et de sécurité. Derrière cette infime partie se cache toute la réalité et la complexité du problème. Il s'agit d'essayer d'avoir la meilleure sécurité par rapport à des besoins réels. Notamment tout algorithme de modification de données prend du temps. Il faudra donc établir un rapport entre les besoins en terme de sécurité et les coûts induits par la mise en place de cette sécurité.
J'ai voulu dans une première partie définir concrètement les notions qui seront utilisées dans ce document, mais aussi les placer dans leur cadre juridique. En effet, il est important de connaître les droits d'utilisation des différents algorithmes afin de percevoir leurs limites d'intervention et de diffusion.
Dans un deuxième temps, nous verrons d'une manière pratique comment insérer la sécurité dans des applicatifs, et les besoins d'une telle implémentation. Cette partie correspond plus au côté pragmatique de la protection. Ainsi les différents moyens de protection seront mis en uvres dans des cas concrets.
Mais sais-tu bien que si tu devais compter un, deux, trois et ainsi de suite, un nombre à la seconde, pour arriver à un milliard, tu y mettrais presque trente-deux ans ?. ... Mais en vérité le vrai nom de Dieu, le nom secret, est long comme la Torah toute entière et il n'est de machine au monde qui puisse en épuiser les permutations.
Rappel et définitions.
On appelle chiffrement chiffrement toute opération consistant à rendre illisible une information pour toute personne ne détenant pas un "secret" lui permettant de déchiffrer cette information. Le but du chiffrement est de rendre la tâche la plus difficile possible au personnes voulant découvrir cette information, sans connaître la "clé". Ici on peut fonctionner avec l'analogie de la serrure : la clé permet d'ouvrir l'accès à la pièce. La clé correspond en informatique à une série de bits, la pièce est le message décrypté, et le message chiffré correspond à la pièce fermée.
Chiffrer (crypter) un message permet d'obtenir un autre message, plus court ou plus long, que l'on appelle cryptogramme. Ce cryptogramme doit s'éloigner le plus possible du message original, tant au niveau des informations codant les caractères, que sur les statistiques de répartition des informations similaires. Ainsi un bon message crypté sera difficilement compressé, et la fréquence des lettres le composant sera différente de celles du message original.
Les premiers algorithmes (par exemple chiffre de Jules César) ne rempliraient plus les conditions nécessaires à une bonne sécurité aujourd'hui. Mais pour l'époque ils constituaient une très bonne protection. Les algorithmes, tel le DES (algorithme très utilisé de chiffrement à clé secrète) ont répondu longtemps aux critères de sécurité, mais les progrès à la fois mathématiques et informatiques, ont rendu possible le "cassage" (casser un cryptogramme = retrouver le texte en clair sans la clé) des algorithmes. Ainsi il est maintenant envisageable, avec des machines du commerce, d'essayer toutes les clés possibles lorsque cette clé est inférieure à soixante bits. Par exemple le DES utilise des clés à 56 bits, mais l'entropie est de 40 bits ce qui fait 2 40 soit 1 099 511 627 776 clés possibles. De plus l'attaque exhaustive (essayer toutes les solutions), peut être effectué sur des machines massivement parallèles. Ainsi une machine de 1024 processeurs réduirait le temps par 1000. On voit là que tester 1 milliard de solution reste à la portée de tout processeur du marché actuel en quelques heures. Donc une clé de 56 bits parait bien insuffisante à l'heure actuelle alors que le DES est toujours utilisé pour les communications satellites par exemple. On notera au passage que ce niveau de protection, on l'a vu très relatif, est la seule autorisée à l'heure actuelle en France.
N'oublions pas que la cryptographie ne se limite pas à rendre un message illisible. Beaucoup d'outils tournent autour de la cryptographie afin d'authentifier les messages. Ainsi les opérations dites de signature qui associent un code unique à un message, le code ne permettant pas de retrouver le message original, et toute modification du message entraine un code différent. On trouvera ainsi dans le même contexte des fonctions de hachage à sens unique, des algorithmes de génération de clé....
Afin de simplifier la suite, on utilisera une notation commune.
On considérera plusieurs acteurs, avec leurs clés respectives. Ces noms rappelleront des souvenirs directement aux personnes ayant déjà lu des livres sur la cryptographie :
Alice Participante d'un protocole.
Bernard Participant d'un protocole.
Estelle Espionne
Martin Espion malveillant actif
Ivan Arbitre Intègre
m correspondra au texte en clair.
V correspondra au texte chiffré (cryptogramme)
k correspondra à une clé. Ainsi k A sera la clé d'Alice.
E correspondra au chiffrement. Ainsi E k(m)=V sera le message m chiffré avec la clé k.
D correspondra au déchiffrement. Ainsi D k(V)=m.
S Correspondra à la signature d'un message. S k(m).
En dehors du problème de sécurité, un algorithme cryptographique doit répondre à plusieurs critères :
¨ Non déformation des données sources. D k( E k(m))=m
¨ Aucune ambiguïté possible sur le cryptogramme : D k(E k(m))=m avec
¨ Rapidité
¨ Concision du code
La sécurité d'un algorithme tiendra à différents facteurs tels que la longueur de sa clé, mais aussi sa résistance aux différentes manières de casser un algorithme. On fera attention aux algorithmes restreints algorithmes restreint, c'est à dire dont la valeur tient au secret de l'algorithme de chiffrement. Un bon algorithme doit être un algorithme public, qui a subit les assauts de plusieurs experts. Une telle tentative de cryptanalyse est appelée attaque attaque.
Lars Knudsen a classé ces différentes manières de casser un algorithme.
1. Cassage complet
Cassage complet . Un cryptanalyste (personne analysant les messages chiffrés, avec pour objectif de retrouver le texte en clair) trouve la clef k telle que D k(V)=m.
2. Obtention globale
Obtention globale . Un cryptanalyste trouve un algorithme de remplacement équivalent à D k(V) sans connaître k
3. Obtention locale
Obtention locale . Un cryptanalyste trouve le texte en clair d'un message chiffré qu'il a intercepté.
4. Obtention d'information. Un cryptanalyste glane quelque information à propos du texte en clair ou de la clef. Cette information pourrait être certains bits de la clef, un renseignement sur la forme du texte en clair, etc.
On peut mesurer la complexité d'une attaque de trois manières différentes :
· Complexité Complexité en information. La quantité d'information nécessaire en entrée.
· Complexité en temps. Le temps nécessaire pour achever l'attaque.
· Complexité en espace. La quantité de mémoire nécessaire à l'attaque.
Enfin on a classifié les différentes méthodes d'attaque :
· L'attaque à texte chiffré seulement. Le cryptanalyste dispose du texte chiffré de plusieurs messages, tous ayant été chiffrés avec le même algorithme.
· L'attaque à texte en clair connu. Le cryptanalyste a non seulement accès aux textes chiffrés de plusieurs messages mais aussi aux textes en clair correspondants.
· L'attaque à texte en clair choisi. Le cryptanalyste peut choisir les textes en clair à chiffrer.
· L'attaque à texte en clair choisi adaptative. Il s'agit d'un cas particulier de l'attaque à texte en clair choisi. Non seulement le cryptanalyste peut choisir les textes en clair mais il peut également adapter ses choix en fonction des textes cryptés précédents.
Un autre type d'attaque dit attaque à clef choisie. Ici le cryptanalyste à accès uniquement à quelques relations entre différentes clefs.
Comme nous le verrons par la suite, les algorithmes de cryptographie que nous utiliserons sont divisés en deux grandes catégories : La cryptographie à clé symétrique, dite à clé secrète clé secrète, et la cryptographie à clé asymétrique clé asymétrique, dite à clé privée. Il existe d'autres catégories de cryptographie que nous ne verrons pas ici. Par exemple, la stéganographie qui consiste à cacher un message dans une information banale.
Il s'agit ici de la cryptographie symétrique cryptographie symétrique. Le principe fort simple consiste à utiliser la même clé pour coder et décoder l'information.
Comme nous le verrons par la suite, ce système, malgré l'arrivée des systèmes à clé publique, conserve beaucoup d'avantages. Notamment on trouvera une meilleure sécurité par rapport à la longueur de la clé, et une plus grande rapidité que les algorithmes à clé publique.
Les principaux algorithmes à clé symétrique sont principalement : DES, RC4, RC5, IDEA et autres algorithmes tel Blowfish. Comme nous le verrons dans le chapitre concernant la cryptographie et la légalité, beaucoup de ces algorithmes sont déposés, et leur utilisation n'est pas toujours gratuite. Sans compter que leur utilisation peut être parfois interdite en France.
La plupart des algorithmes, à clé secrète, fonctionnent selon quelques grands principes.
Le premièr principe consiste à traiter l'information de manière linéaire, bit après bit. Il s'agit généralement de réalisations matérielles, particulièrement bien adaptées à ce type de traitement. Le second principe consiste à découper l'information en blocs d'une certaine taille, si possible adaptée à la taille des registres du processeur utilisé. Ce type de chiffre est parfaitement adapté aux réalisations logicielles, et c'est ce dernier mode qui va ici nous servir de modèle pour expliquer d'une manière générale la cryptographie à clé secrète.
Le principe général, consiste à crypter le texte en blocs. Ainsi un texte sera découpé en blocs de taille fixe, l'algorithme se chargeant de découper l'information et de la rendre illisible. Bien sûr ce système a une faille : si on se contentait de crypter chaque bloc de manière indépendante, la tâche serait aisée car deux mêmes blocs seraient cryptés de la même façon. Pour pallier a cela, on réinjecte, généralement le résultat précédent dans le bloc suivant.
Ainsi on trouvera différents modes cryptographiques dans le traitement par bloc. Il s'agira des 4 méthodes de base :
q ECB Electronic Code Book. Cas le plus simple : chaque bloc est crypté de manière indépendante.
q CBC Cipher Block Chaining. Un vecteur d'initialisation est combiné avec le texte clair. Ensuite le résultat de chaque encryptage de bloc est combiné avec le texte en clair du bloc suivant.
q CFB Cipher Feedback. Le bloc crypté est combiné avec la clé du bloc suivant devant être crypté.
q OFB Output Feedback. La clé est modifiée à chaque itération et combinée avec la clé suivante
Il ne s'agit que de principes généraux concernant la cryptographie. Ces différents modes peuvent êtres combinés entre eux, accepter différentes techniques notamment sur le calcul du vecteur d'initialisation, sur la méthode de combinaison des éléments entre eux.
Enfin en fonction de l'algorithme différents paramètres seront à prendre en compte. Notamment la longueur de la clé, la longueur du bloc en entrée (en clair) et en sortie (crypté). Enfin ces opérations seront très souvent répétées. On parlera alors de ronde, ainsi on dira que tel algorithme est sûr à partir de 16 rondes, c'est-à-dire, qu'il est sur pour la répétition d'une technique 16 fois de suite.
Le but général est de disperser, le texte en clair, de le permuter afin que le texte final s'éloigne le plus possible du texte original. Il faudra aussi faire attention à la clé, car comme on peut s'en douter, c'est à elle que revient la sécurité du cryptogramme (texte crypté). Ainsi en fonction de l'algorithme, certaines clés seront définies comme faible, car elles facilitent la tâche du cryptanalyste en n'offrant pas une sécurité maximale car elle peuvent diviser le temps d'attaque d'un algorithme par 2 et plus.
Le but de ce type de système est de chiffrer avec une clé et de déchiffrer avec une autre. Il existe plusieurs algorithmes permettant le chiffrement asymétrique. Nous verrons uniquement l'algorithme RSA qui porte le nom de ses trois inventeurs : Rivest, Shamir et Adleman.
Ainsi, puisque l'on ne peut déchiffrer qu'avec deux clés (celle dite secrète et celle dite publique), il suffira de diffuser une des clés pour que tout le monde puisse chiffrer un message. Mais ces personnes seront incapables de déchiffrer leur propre message chiffré ! Seul le détenteur de la clef gardée secrète pourra déchiffrer le message.
Dans la plupart des algorithmes à clé publique, le but est d'essayer de trouver une fonction facile à exécuter dans un sens mais très difficile à exécuter dans l'autre sens. Ainsi il est très facile de multiplier des nombres mais très difficile de factoriser un grand chiffre.
C'est sur cette hypothèse que réside par exemple l'algorithme RSA :
En simplifiant il faut prendre deux grands nombres premiers p et q. Soit e = ( p-1)( q-1).
Soit d inverse de e modulo phi(n). Avec phi fonction phi d'Euler (Nombre d'entiers positifs plus petits que n et premiers par rapport à n.
La clé publique est alors P=( e, n) et la clé secrète S=( d, n).
Chiffrer un message consiste alors en l'opération suivante :
P(m)=m e(mod n).
Et l'opération inverse :
S(V)=V d (mod n)
On le voit ici, toute personne sachant factoriser rapidement pourra alors retrouver p et q à partir de n. Et donc obtenir lui aussi la clé secrète. Or cette opération reste très difficile (bien que non prouvée), car ce système est plus sûr que des algorithmes tels le DES, à conditions d'avoir des clés 4 à 10 fois plus grandes. La preuve et les pré-requis mathématiques se trouvent parfaitement illustrés dans " Introduction à l'algorithmique". Edition Dunod.
Attaques des protocoles.
L'objectif de cette partie n'est pas de décrire les moyens pour casser un algorithme. Il s'agit plutôt d'étudier les principes de piratage des systèmes communiquants. En effet, le but de tout bon pirate est de récolter un maximum d'informations, mais parfois, il n'est pas nécessaire de savoir déchiffrer pour pourvoir pirater un système. La grande force des pirates est qu'ils ont beaucoup de moyens d'actions, et que leur inventivité surpasse parfois les meilleurs systèmes cryptographiques. Ainsi on peut avoir le meilleur algorithme cryptographique qui existe, et avoir une faiblesse dans le protocole de communication. Donc nous allons voir quels sont les principaux moyens de protection des protocoles cryptographiques.
Qui aujourd'hui ne connaît pas les différents moyens pour retrouver un mot de passe ?. Il suffit de s'asseoir au poste d'un utilisateur et d'essayer. Essayer son nom, son prénom, le nom de ses enfants, de sa plaque numérologique, sa date de naissance, la combinaison de plusieurs éléments... Bien sûr la première sécurité passera par la clef d'authentification, mais aussi de cryptographie. Bon nombre d'algorithmes possèdent des clefs faibles, c'est à dire, dont le cryptogramme résultant est plus facile à "casser". En fonction des algorithmes utilisés il sera bon de vérifier la pertinence de la clef. Ensuite, tout bon mot de passe se doit de comporter majuscules, minuscules et chiffres. Celui-ci ne devrait pas comporter de syllabes en relation avec l'utilisateur. Beaucoup de systèmes demandent maintenant un mot de passe de n caractères minimum et suffisamment compliqué pour ne pas ressembler au nom de l'utilisateur. D'ailleurs le Service Pack 2 et 3 de Windows NT4.0 Windows NT4.0 apporte une DLL DLL ( passfilt.dll), permettant de vérifier la sécurité d'un mot de passe par rapport à différents critères :
§ 6 Caractères minimum.
§ Pas de partie identique au nom de l'utilisateur, ou tout autre utilisateur.
§ 3 des 4 types suivants sont obligatoires : Majuscules, minuscules, chiffres et caractères non alphanumériques
Dans le Service Pack 3 Service Pack 3 on voit aussi apparaître CryptoAPI CryptoAPI 2.0, permettant l'ajout de fonctions de sécurité comme la création de certificats X509.3. (voir http://www.microsoft.com/security/tech/mis6_2-f.htm)
Enfin n'oublions pas de regarder le fameux post-it collé sous les bureaux, ou encore les noms inscrits sur les posters accrochés aux murs.
Par attaque passive, nous entendons ici un utilisateur, malhonnête, mais qui n'agit pas, qui essaie simplement de découvrir des secrets. Celui-ci utilisera les techniques cités ci-dessus, mais au-delà il essaiera d'obtenir des informations grâce à des moyens détournés.
La première solution sera bien sûr d'écouter aux portes. Dans un réseau cela s'effectue très simplement : il suffit de dénuder quelques fils réseaux, des pinces crocodiles, un peu d'électronique pour brancher une dérivation qui ne génère pas d'impureté dans le réseau, un ordinateur et vous pouvez regarder passer tout le trafic réseau. Avec quelques outils d'analyse, vous pouvez certainement tomber sur des "conversations" intéressantes. Pour pallier à cela, seule la cryptographie permet de freiner ce genre d'espionnage. Sans compter qu'à partir de ces renseignements un pirate passif, peut très vite devenir actif s'il réussit à trouver vos mots de passe.
Il est très improbable que, sur Internet, une personne espionne les différentes communications. Celles-ci sont trop nombreuses et trop importantes pour pouvoir retrouver facilement et suivre les "conversations" entre un client et un serveur par exemple. Ce type d'attaque ne peut s'effectuer qu'aux deux extrémités mais pas "dans" Internet.
SAUF lorsque vous cryptez vos informations !. En effet dans ce cas il est plus facile de faire des statistiques et isoler les informations que l'on pourrait qualifier de sensibles. En effet la plupart des logiciels et protocoles cryptographiques commencent par des séquences communes. Ces séquences peuvent être repérées et analysées. Ainsi PGP
PGP (Pretty Good Privacy) a toujours le même format d'en-tête lorsque vous envoyez un eMail. De même un message "bien chiffré", a toujours certains signes distinctifs qui permettent de le distinguer des messages dits banals. En effet un bon cryptogramme est très peu sensible à la compression, et comporte donc très peu de répétitions. De plus les syllabes et les lettres le composant (voyelles/consonnes par exemple) sortent des règles des statistiques.
On le voit, crypter l'information n'est pas une chose simple, même avec de "gentils pirates". Le fait de crypter fait de vous une cible privilégiée, et donc vous oblige à mettre en place des moyens de protection efficaces. Il faut aussi faire attention à ne pas trop crypter pour ne pas attirer l'attention. De plus la cryptographie rajoute un temps de traitement non négligeable qui oblige à choisir avec attention les éléments qui doivent êtres chiffrés.
Dans ce type d'attaque tous les coups sont permis. Le pirate peut intercepter les conversations, les remplacer par ses propres conversations, il peut aussi enregistrer des conversations et les rejouer.
Ainsi il peut enregistrer la conversation entre Alice et Bernard : Alice demande par exemple 100 Francs à Bernard. Celui-ci lui fait un virement. Si Martin intercepte le message, il peut le renvoyer 100 fois à Bernard... Cela aura des effets désastreux sur le compte de Bernard, mais en plus Martin peut essayer de détourner le message pour que ce soit son compte qui soit crédité...
Les moyens d'attaque de Bernard sont très nombreux. On retiendra ici les principaux.
ü Attaque en force des clés du système : il s'agit ni plus ni moins que d'essayer toutes les clés possibles pour un algorithme particulier.
ü Cryptanalyse des codes en connaissant des morceaux de texte en clair du document (En-tête HTTP, Tags HTML, ...)
ü Rejouer des morceaux enregistrés. Il s'agit d'enregistrer des trames et de les renvoyer sans forcément connaître le contenu exact de celles-ci.
ü Intercepter les messages préliminaires de synchronisation. Ici l'attaquant se place entre le client et le serveur, intercepte les messages et les remplace par ses propres clés. Il se fait ainsi passer pour le serveur auprès du client, et pour le client auprès du serveur : toute la transaction passe par lui !.
La cryptographie a longtemps été réservée au domaine militaire. Depuis Jules César qui l'utilisait pour asseoir ses conquêtes, jusqu'à nos jours où beaucoup de pays considère le chiffrement comme une arme de guerre. La cryptographie est restée longtemps un système simple qui a du attendre l'arrivée du vingtième siècle pour se compliquer. Ainsi on est passé d'une simple rotation de 3 lettres (A est remplacé par D, B par E,...) utilisée par l'empereur romain, pour arriver à des systèmes dits à clé publique, permettant de crypter un message à l'aide d'une clé, et à le décrypter uniquement à partir d'une autre clé. Sans oublier de passer par la très connue machine Enigma Enigma inventée en 1919 et "cassée" uniquement en 1941.
L'arrivée vers les années 70 de systèmes cryptographiques considérés comme fort à l'époque, va permettre une explosion de l'utilisation de la cryptographie. Cette cryptographie commencera alors à faire une timide entrée dans le domaine commercial. Ainsi ont peut noter en 1976 la sortie du DES
DES ( Data Encryption Standard, par IBM) qui reste encore une cryptographie à clé secrète fortement utilisée. A la fin des années 70, apparaîtra de nouveaux principes cryptographiques : le chiffrement asymétrique chiffrement asymétrique. Le principe étant de dissocier la clé permettant de chiffrer de la clé de déchiffrement.
Ce monde de la cryptographie est longtemps resté secret (et l'est encore), et ne commence à arriver dans le domaine public qu'à partir des années 80. A partir des années 90 on commence à voir arriver un cadre juridique permettant d'encadrer (et donc diffuser) l'utilisation de la cryptographie.
Jusqu'en 1990 les systèmes cryptographiques étaient considérés comme du matériel de guerre. Grâce à un décret du 28 décembre 1992, un double régime de déclaration et d'autorisation a été mis en place. On a alors commencé à différencier le chiffrement pour l'authentification (Régime de déclaration), et pour la confidentialité (Régime d'autorisation).
L'article 17, de juillet 1996, completera la loi de décembre 1990 (loi n°90-1170 du 29 décembre 1990), en différenciant la prestation du moyen cryptographique. Le décret Numéro 92-1358, du 28 décembre 1992 (Journal Officiel
Journal Officiel du 30 décembre 1992), permettra de faire la distinction entre la cryptographie d'éléments d'authentification (comme les codes de Carte Bleu par exemple), et la cryptographie d'information et les matériels ou logiciels associés. De même l'article permettra de faire la différence entre la protection contre le piratage et la cryptographie... uniquement si cette protection, même tenue secrète, ne chiffre pas tout ou partie du logiciel.
décret 92-1358, on voit apparaître dans l'article 9, le SCSSI SCSSI (Service Central de la Sécurité des Systèmes d'Informations).
Art.9 - En cas d'incertitude du demandeur sur l'appartenance d'un moyen ou d'une prestation à la catégorie des moyens ou prestations de cryptologie, l'avis du service central de la sécurité des systèmes d'informations est demandé.
Clairement le SCSSI SCSSI est chargé d'apprécier le niveau de protection des systèmes d'information (cryptologie, sécurité informatique, protection contre les signaux parasites compromettants) et d'agréer les produits traitant les informations classifiés défense.
Ce même organisme forme les spécialistes dont l'Etat a besoin, sensibilise les responsables des administrations et secteurs privés à l'importance de la sécurité des SI. Il joue un rôle de conseil auprès des administrations.
On n'oubliera pas que les critères de sélections des autorisations restent secrets...
On retrouvera les textes législatifs concernant la création et la mission du SCSSI
SCSSI dans les décrets n°86-318 du mars 1996, n°93-209 du 15 février 1993 et n° 96-67 du 29 janvier 1996.
92190 ISSY LES MOULINEAUX.
Bref, la loi de juillet 1996 est très importante car elle signifie que l'on peut transmettre de l'information en clair, mais que cette information peut utiliser la cryptographie pour la signature électronique ou pour garantir de l'intégrité des messages. Cela constituait un pas énorme pour le courrier ou le courrier électronique par exemple.
Les décrets d'application des différentes lois précitées n'apparaîtront qu'un an et demi plus tard au J.O. Numéro 47 du 25 février 1998.
Le décret n°98-101 du 24 février 1998 définit les conditions dans lesquelles sont souscrites les déclarations. Il précisera aussi dans quelles conditions sont accordées les autorisations concernant les moyens et prestations de cryptologie.
Le décret n°98-102 du 24 février définit les conditions dans lesquelles sont agrées les organismes gérant pour autrui des conventions secrètes de cryptologie.
Ce dernier décret fait apparaître des organismes appelés Tiers de Confiance
Tiers de Confiance (TC), qui ont pour charge de "garder" les clés utilisées pour chiffrer. Cela permettrait de chiffrer toute information à condition d'avoir préalablement déclaré les méthodes et clés utilisées à un organisme sous contrôle de l'état. Cette possibilité permet de simplifier les procédures d'autorisations, mais laisse quand même un sentiment de frustration vis-à-vis de la faille de sécurité engendrée par l'existence obligatoire de ce tiers.
Les Décrets n°98-207 et n°96-206 du 23 mars 1998, ainsi que l'arrêté du 13 mars 1998, viennent cerner les droits d'utilisation de la cryptographie. Ainsi les moyens cryptographiques dont le "déchiffrement d'un message ou d'un fichier au moyen du parcours systématique de toutes les clés possibles ne requiert pas plus de 2 40 essais sur un test d'arrêt simple", sont dispensées de toute déclaration pour l'utilisation ou l'importation. De même un tableau récapitulatif ( Annexe 1) recense les obligations de déclaration ou non des différents moyens et prestations cryptographiques. Les esprits critiques n'oublieront pas de remarquer que l'on est autorisé à crypter, à condition que l'état puisse facilement retrouver l'information originale (Ce qui est le cas pour la cryptographie à clés inférieures à 56 bits).
Les tableaux que vous retrouverez en annexe 1 sont la reproduction des tableaux fournis avec le décret n°98-207 du 23 mars 1998 (NOR : PRMX9802750D et NOR : PRMX9802729A)
En dehors des aspects légaux
légaux d'utilisation, il reste encore à s'assurer du droit d'utilisation. En effet beaucoup d'algorithmes sont déposés, et leur simple utilisation est parfois soumise à des droits, le plus souvent ses droits s'apparentent aux droits musicaux : Tout un chacun a le droit d'écouter (utiliser), mais la reproduction pour la vente ou même à des fins non commerciales nécesse le paiement de royalties royalties.
Certains algorithmes ont été mis dans le domaine public (par exemple B lowfish de Bruce Schneier), d'autres ont des droits limités à certains pays (ainsi certains algorithmes voient leur utilisation payante sur le sol américain, alors que dans d'autres pays l'utilisation est gratuite par manque de dépôt de brevet).
Aussi, l'algorithme tombe dans le domaine public
domaine public à des dates différentes, en fonction du dépot du brevet. Par exemple le brevet de Diffie-Hellman a expiré en septembre 1997, alors que le brevet canadien expire en Septembre 1998.
Voici par exemple quelques algorithmes et leur date d'expiration.
Algorithme Date d'expiration en France Date d'expiration aux US.
Merkle-Hellman Juin 1999 19 août 1997
Diffie-Hellman Pas de Brevet. 29 avril 1997
RSA Pas de Brevet. 20 septembre 2000
Les algorithmes ne sont pas les seuls à être protégés. L'utilisation des protocoles est aussi protégée. Ainsi SSL, qui sera décrit plus loin, coûte 50 000$ à toute personne voulant l'inclure dans un programme commercial. Néanmoins en contrepartie vous disposez de sources facilement compilables et exploitables sur la plupart des OS du marché. (Les sources sont "librement" téléchargeables si vous allez sur un site autre que celui de Netscape car ce dernier empêche le téléchargement de personnes provenant de .fr).
Avant de commencer à décrire les différents moyens pour crypter de l'information sur Internet, il est important de spécifier les différentes formes de cryptographie sur les réseaux. En effet quand on parle d'Internet, on entend ici : Intranet, Extranet, et Internet. En fait il s'agit de protéger les accès réseaux. Par protection, nous entendons protéger les informations de toute tentative de lecture ou de modification de l'information.
OSI (Open System Interconnection, développé en 1978 par l'ISO, International Standards Organization), nous a donné les bases pour l'implémentations de pile réseaux. Ainsi toutes les réalisations de TCP/IP suivent de plus ou moins loin les spécifications de ce modèle.
Le modèle permet au programme de s'abstraire du matériel, par un système de sept couches, indépendantes les unes des autres. La couche n discutant uniquement avec la couche n-1 et n+1. Et la couche n d'une machine n'échangera logiquement son information qu'avec la couche n d'une autre machine. On simplifiera ce schéma, pour le découper en trois morceaux élémentaires : la couche dite matérielle : clairement, ici l'IP (Internet Protocol). Sur ce type de couche représentant les 3 premières du modèle OSI
OSI, seuls des systèmes matériels pourront assurer une protection efficace. Il s'agira de routeurs, ou de modems dotés de fonctions de chiffrement. La deuxième couche correspondra plutôt à la couche transport du modèle OSI.
Physiquement cela peut correspondre à TCP/IP
TCP/IP (Transfert Control Protocol), ou UDP UDP (User Datagramm Protocol). Ici les implémentation matérielles seront très efficaces, mais une réalisation logicielle reste totalement possible.
La troisième couche correspond plutôt à la couche des services IP, tels FTP (File transfert protocol), pour le transport de fichiers ou encore HTTP (HyperText Transport Protocol). Réaliser un matériel pour chiffrer ce type de couche reste totalement possible, mais l'implémentation logicielle sera largement facilitée.
Il n'est pas possible ici de faire un examen exhaustif de toutes les solutions existantes. Beaucoup sont des solutions propriétaires (notamment au niveau matériel) ou ne sont pas reconnues au niveau mondial (Il existe beaucoup de solutions de paiements électroniques, mais si certaines d'entre elles semblent avoir une part de marché écrasante dans certains pays, elles ne semblent pas vraiment percer en Europe ou aux Etats-Unis). Il est important de retenir le principe de ces différentes solutions.
On visualise l'imbrication des différentes couches entre-elles. Ainsi TCP utilise IP, et TCP/IP est utilisé par HTTP pour transférer l'information. Plus on protège à un niveau bas, et moins il y a besoin de crypter au niveau supérieur : Lorsque l'on crypte les trames IP, le flux HTTP passera chiffré sur Internet.
Comme on le voit, on peut crypter à plusieurs niveaux. Il n'y a pas d'endroit idéal ou la cryptographie peut être la plus efficace. Tout dépend du niveau de sécurité que l'on veut obtenir. Ainsi si on utilise une cryptographie qui crypte au niveau de la couche IP, tout ce que l'on enverra sur le réseau sera alors crypté. Ce qui n'est pas toujours nécessaire : dans une page HTML, beaucoup de choses sont communes, par exemple les tags. Parfois il est même conseillé de ne pas tout crypter : Plus on crypte d'informations standards (comme la traduction HTML), plus on donne d'informations sur le texte en clair au cryptanalyste.
Plusieurs systèmes ont été développés pour crypter l'information sur Internet. On en retiendra ici deux, tout en sachant qu'il existe d'autres protocoles. Par exemple il existe des protocoles comme PEM
PEM ou PGP PGP qui sont deux standards de fait pour sécuriser les eMails.
Nous allons ici nous intéresser à deux types de cryptographie sur Réseau : IPSEC et SSL. Ces deux techniques complémentaires, nous permettront d'aborder deux types de sécurité : une au niveau des couches que nous qualifierons de physique à savoir IPSEC et une au niveau de la couche applicative :SSL.
Ce protocole permet de créer des Réseaux Virtuels Privés
Réseaux Virtuels Privés (VPN VPN). Il s'agit en fait de sécuriser les informations circulant entre différents réseaux. Celui-ci devra donc sécuriser les informations au niveau de la couche IP IP et en dessous. Il s'agit d'un premier niveau de protection niveau de protection, qui est en fait une protection ultime car elle permet de sécuriser toutes les informations sortant d'une entreprise. Les réalisations d'IPSEC IPSEC se trouveront être des routeurs ou même des firewalls firewalls, qui non seulement contrôlent et orientent le trafic, mais qui en plus sécurisent l'information. Le but principal dans ce type de protocole est avant tout d'assurer la confidentialité, de respecter la sécurité en empechant la modification de l'information, ainsi que les attaques de types textes rejoués (qui consiste à enregistrer une conversation, et à la rejouer). Pour cela différents algorithmes seront utilisés tels MD5 MD5 (Message Digest Message Digest) ou encore SHA-1 SHA-1 (Secure Hash Algorithm) pour le calcul des empreintes des messages, et différents algorithmes comme bien sûr DES (le mode CBC est conseillé), ou encore RC4 RC4.
Il s'agit en fait d'un proxy de sécurité, prenant les données en entrée, et faisant ressortir des données protégées. L'avantage de ce type de solution est l'interconnexion de réseau. Par contre, ce procédé devient très vite coûteux lorsqu'il doit être utilisé pour sécuriser toutes les communications dans une entreprise. En effet, cela supposerait de disposer d'un boîtier de sécurité pour chaque machine d'une entreprise. Cela est très souvent inconcevable. Par contre ce type de schéma conviendra parfaitement à l'architecture suivante :
Ce protocole de protection, mis au point par la société Netscape
Netscape, est devenu un standard de fait, inclus même dans Internet Explorer Internet Explorer, et dans la plupart des serveurs HTTP tels Netscape bien sûr mais aussi Internet Information Server de Microsoft Microsoft ou encore Apache Apache. Ce protocole s'attache ici à protéger la couche applicative.
En Juin 1998, SSL
SSL en est à sa version 3.0. Mais le principe général est resté le même. Il s'agit de transférer des Identifications et des clés secrètes, à l'aide de la cryptographie à clé publique. On bénéficie ainsi de la souplesse des différents modes algorithmiques : la cryptographie à clé publique pour le transfert de secrets entre postes dans des "environnements hostiles", et la rapidité de la sécurité à clé secrète.
SSL est un protocole supportant beaucoup d'options et d'algorithmes cryptographiques. Il est ainsi possible à plusieurs clients utilisants des algorithmes différents, d'établir une connexion avec un même serveur.
Il est possible aussi de faire fonctionner cet algorithme avec un "organisme" central dont l'autorité n'est pas discutée, et qui fournira des clés publiques. On bloquera ainsi différentes attaques actives comme l'interception/modification de communication.
Un établissement de communication Client/Serveur pourra alors se résumer comme suit :
L'ordre de communication va de bas en haut, en suivant la numérotation.
On pourrait passer par une phase de demande/vérification de certificat auprès d'un orgranisme central de contrôle.
Le document complet de description, ainsi que les API de développement se trouvent sur le site de Netscape.
On dirait que l'homme est soumis à la fatale obligation de construire des voies nouvelles. Il est condamné à construire des routes qui mènent vers un but. Une route conduit toujours quelque part.
Fédor Dostoïevsky, Le Joueur
La cryptographie simplifiée.
J'ai utilisé pour développer : Visual C/C++ C/C++, JavaScript JavaScript et 4D 4D.
Le choix de ce dernier outil peut être discutable. Il s'agit d'une base de données relationnelle, fonctionnant en mode client/serveur et permettant l'ajout de fonctionnalités. Il s'agit donc d'un produit très ouvert qui de part ses fonctionnalités intégrées nous permettra de tester et valider les différentes solutions choisies.
On trouvera notamment dans 4D
§ Un langage permettant de développer des fonctions complexes.
§ Une base de données base de données pour l'analyse et le stockage d'informations.
§ Un compilateur permettant d'obtenir un exécutable rapide.
§ La possibilité d'inclure des Plug-In, notamment rajoutant des commandes d'accès à TCP/IP TCP/IP et UDP UDP.
§ Un fonctionnement C/S, pour les tests de sécurisation d'applications réseau quelconques.
§ Un serveur HTTP HTTP, pour prouver la validité des protocoles mis en place.
Le C nous permettra de développer des Plug-In et autres utilitaires. Javascript Javascript protégera les informations transmises par HTTP.
Au vu de l'existant, et de mes connaissances réseau, différentes implémentations me semblent abordables. Ces techniques étant cumulables : on peut commencer par le plus simple et compléter les développements par l'ajout de nouvelles fonctionnalités.
§ En premier lieu, l'implémentation de la cryptographie sera nécessaire et réalisée en C. En guise d'exemples, celles-ci seront réalisées sous forme de Plug-In 4D. Cela permettra d'envisager différentes couches supplémentaires de réalisation.
§ Ensuite l'interface Serveur Web Serveur Web/Navigateur Web (4D/Netscape par exemple) sera envisagée. La solution retenue est d'utiliser Javascript. Ainsi un dialogue Serveur/Client Web pourra devenir sécurisé : Le serveur Web chiffrant uniquement les valeurs des tags HTML, le Javascript permettant à la réception de la page de décrypter l'information. De la même manière en sens inverse. Java remplacera le code C implanté dans 4D. Il s'agira donc d'apprendre le langage JavaScript (qui semble à première vue similaire au C) et de regarder la faisabilité de traduction des pages (Emission/Réception).
§ Puis, la réalisation d'un filtre d'Entrée/Sortie permettant la sécurisation des connexions TCP/IP TCP/IP. Il s'agirait là d'un programme écoutant sur un numéro de port spécifique, et retournant l'information cryptée sur un autre numéro de port. Le problème sera de ne crypter que l'information de type Data, et de ne surtout pas perdre les informations de routage. Ce dernier point reste le plus ambitieux car on pense alors à différentes variantes, incluant le dialogue SSL SSL et cela sans avoir besoin de serveurs spécifiques. Cette dernière plus complexe sera étudiée en dernier.
On retrouvera en dernier une étude plus précise de la technique du filtre. Cette notion qu'on pourrait comparer à un proxy proxy amélioré impose certains besoins et règles de bases qui seront détaillés.
Afin de réaliser ces différents projets, il sera nécessaire d'étudier techniquement les solutions. Les différents algorithmes et protocoles nécessaires seront détaillés parallèlement dans la première partie.
La partie qui va suivre va donc être primordiale dans la réalisation, car c'est elle qui va décider de la validité technique de réalisation. Les réalisations pratiques ne seront alors qu'un mélange entre partie théorique et tests d'études.
Pour réaliser les différents tests, différentes techniques vont être utilisées. Notamment au niveau langage on trouvera du C/C++, et du Java/JavaScript
JavaScript. J'envisage d'utiliser 4D pour faire des tests de réalisations réseaux. Cet outil sera a priori préféré à un développement natif, pour sa relative rapidité de développement, notamment grâce à l'ajout de Plug-In tel que l'ITK (Internet Tool Kit Internet Tool Kit), donnant accès à TCP/IP à partir d'une simple base de données.
Ces différents tests sont décrits ci-dessous. Ils ont pour principe de prouver la validité de l'architecture prévue, mais aussi de préparer l'implémentation réelle des différents algorithmes. Cette architecture n'est donc pas un brouillon, mais une base solide qui sera complétée par la suite.
Afin de donner des fonctionnalités cryptographiques a une base de données un Plug-In a été développé. Ce Plug-In
Plug-In est développé sous forme de couches, afin de rendre indépendants le développement des fonctionnalités du produit. Le but est d'isoler les algorithmes algorithmes de chiffrement, des passages de paramètres, et l'appel des fonctions elle même. De la même manière afin de rendre indépendant l'algorithme de cryptographie, le développement a été réalisé afin de rendre transparent le changement d'algorithme au niveau du code source. Schématiquement nous pouvons visualiser cela sous la forme suivante :
Le Plug-In met en forme les données provenant de la Base de données
Base de données afin de les rendre FACILEMENT accessibles pour les algorithmes en C. Le passage de données se faisant sous la forme de pointeur.
Pour la notation on retrouvera la syntaxe suivante dans ce qui suivra :
Variable ou Champ
[Element facultatif]
Donnée_Cryptée := SH_Crypt( Donnée_en_Clair ; Type)
La constante Type, permet de sélectionner l'algorithme cryptographique choisi, et données Cryptée et Donnée en clair représente des variables de type BLOB
BLOB(Binary Large Objects, qui correspond à des zones mémoires dont la taille maximale est de 2Go). La réalisation d'une extension pour les autres formats (textes, entiers, ) pour ce plug-In est pour l'instant facilement possible mais pas indispensable.
Les fonctions disponibles au niveau du plug-In sont les suivantes :
Donnée_Cryptée := SH_UnCrypt( Donnée_Cryptée ; Type)
vErr := SH_DefineKey( Clé_1 ; Clé_2 ; Type ;[Longueur1 ;[Longueur2]] )
vErr := SH_GiveKey( Clé_1 ; Clé_2 ; Type ; [ Longueur1 ; [ Longueur2]])
Verr := SH_GenerateKey( Clé_1 ; Clé_2 ; Type ; [ Longueur1 ; [ Longueur2]])
Nous ne réaliserons cette implémentation qu'avec des données de type BLOB
BLOB (Binary Large Objects. Ce type de donnée a l'avantage de pouvoir englober n'importe quel autre type (on peut mettre n'importe quelle variable ou document dans un Blob) de données. Il faudrait étendre les fonctions aux documents et aux zones alpha et texte. Néanmoins dans un premier temps ses fonctions devraient nous suffire.
JavaScript & HTML.
L'avantage de cette technique sera d'offrir une protection peut coûteuse, relativement universelle à tout navigateur. De plus cette solution permet de crypter uniquement les informations nécessaires.
Le langage Java, ne semblant pas correspondre à nos besoins (les applets
applets Java sont indépendantes des pages HTML les contenants), seul javascript semble avoir les fonctions essentielles pour pouvoir crypter et décrypter l'information contenue dans une page HTML.
Pour cela, il convient d'analyser finement les besoins. Il faut que le scripte java puisse se déclencher seul, à l'ouverture de la base. Il faut aussi que les clefs d'accès soit stockées pour éviter de demander à l'utilisateur son mot de passe à chaque fois. Deux techniques sont donc envisageables : placer les Values (Valeurs de champs de saisie HTML) des champs textes dans des variables et travailler sur ces variables, ou bien aller directement lire la valeur de ses variables. Il conviendra alors de placer directement dans les pages HTML les scripts nécessaires au cryptage/décryptage de l'information. Pour cela nous utiliserons l'envoi de page HTML via 4D, qui nous servira pour envoyer rapidement, et automatiquement les javascript.
Il faudra que le poste client puisse demander à l'utilisateur un mot de passe. Le problème étant que chaque page HTML
HTML, étant indépendante les unes des autres, il faut pouvoir stocker ce mot de passe afin de ne pas pénaliser l'utilisateur, en l'obligeant à demander un mot de passe mot de passe. Pour cela l'utilisation des cookies cookies semble idéale : Il s'agit d'une zone de mémoire qui reste sur le poste navigateur et qui reste valide de session en session. De plus les cookies peuvent avoir une durée de vie limitée. Cela pose un léger problème de sécurité mais vite compensé par la facilité d'utilisation :
Le cookie est stocké sur la machine (ce dernier peut être crypter), cela permet d'éviter d'avoir à demander un mot de passe à l'utilisateur à chaque fois qu'il charge une page HTML. Sans cette fonctionnalité l'utilisateur serait condamné à saisir sont mot de passe pour chaque clic souris.
Afin de vérifier la possibilité de crypter une page HTML, j'ai réalisé une page HTML répondant aux différents critères. Pour cela l'algorithme simple a été utilisé (cryptographie de Jules César). Le bilan restant globalement (pour l'instant) positif : le déchiffrement, s'effectue au chargement, et le mot de passe est conservé de page en page, avec la possibilité de l'initialiser. Le seul problème restant les codes de caractères : il est difficile d'obtenir le code ascii ou Hexadécimal d'un caractère. De plus ce code change de plate-forme en plate-forme : si le serveur et le navigateur ne sont pas sur le même plate-forme, alors il peut exister des problèmes de conversion. Pour compenser cela tous les codes ont été traduits en Hexadécimal. Or le problème principal reste la conversion de texte en Hexa : Il n'existe pas de fonction javascript, et cette conversion reste « aléatoire » en fonction de la machine cliente.
Lors de l'envoi de l'en-tête HTTP contenant la valeur des variables il faudra aussi prévoir un script pour crypter l'information. Les pages HTML devront donc prévoir le déchiffrement et le chiffrement des informations. Le déchiffrement ne semblant pas être un problème majeur, il suffira de penser à un système permettant d'insérer la cryptographie dans l'existant de la manière la plus simple possible.
Pour cela l'attrait de 4D prend ici toute son importance : La version 6 de 4D permet de créer un serveur HTTP, dont les données situées dans le flux de sortie et d'entrée peuvent être trappées et modifiées.
Ainsi il est possible de créer des tags spécifiques permettant d'indiquer quelle cryptographie utiliser.
Les tags prévus sont donc :
<SHCrypt= " Type" Password=" Mot de passe">
</SHCrypt>
On retrouvera dans la réalisation pratique la conception d'un serveur de chiffrement des pages à la volée.
L'idée générale est de créer une sorte de serveur proxy
proxy, qui prend en charge la cryptographie.
Ce proxy se trouve aussi bien au niveau serveur qu'au niveau des clients. (Dans un premier temps).
Le proxy est une application qui se "fait passer" pour tous les autres clients : il devient le serveur, et toutes les requêtes transitent par lui. Le serveur
serveur lui, ne voit qu'un ensemble de clients situés sur la même machine.
L'idéal étant de concevoir un proxy serveur permettant de gérer de manière transparente le S-HTTP. Ici deux options de sécurité seraient envisageables : S-HTTP
S-HTTP ou SSL.
Ces deux modes de sécurité sont présents sur la plupart des navigateurs.
Ce principe est ici simplifié. A moins d'avoir une clé secrète partagée et non transmise sur le réseau, une personne malveillante pourrait s'intercaler entre les deux connexions et modifier les messages transmis.
L'idée est d'utiliser la cryptographie asymétrique pour l'échange des clés et la cryptographie symétrique (à l'aide des précédentes clés) pour crypter les informations. L'échange de clé se fera par un tiers de confiance
tiers de confiance qui va être chargé de stocker les clés des différents utilisateurs. Le but est ici de sécuriser une connexion d'une machine à une autre. Il va falloir authentifier authentifier les différents intervenants
Un protocole spécial devra être développé pour sécuriser les échanges Serveur de clés/Demandeurs.
Nous allons uniquement garantir la sécurité du dialogue : il ne pourra être ni espionné ni modifié de quelque manière que ce soit. Charge sera aux intervenants de s'identifier mutuellement. Un maintien du contexte de sécurité devra donc être envisagé.
L'idéal serait d'arriver au final à la situation suivante :
Plusieurs points devront être résolus avant de réaliser ce type d'application :
- Servir de passerelle réseau.
- Pouvoir crypter l'information.
- Reconnaître les différents protocoles de communication.
- Identifier et suivre les différentes connexions (on peut s'adresser à plusieurs clients simultanément).
- Disposer (et donc créer) un serveur central de distribution de clés.
Ce qu'il y a de beau dans un mystère c'est le secret qu'il contient, et non la vérité qu'il cache.
Eric-Emmanuel Schmitt, Variations énigmatiques.
Réalisations pratiques.
Pour réaliser ce type d'applicatif, plusieurs étapes ont du êtres franchies :
Création d'un "container" de fonction de chiffrement
Création d'un "container" de gestion des clés.
gestions des clés.
Création d'un "container
container" de création de signatures.
Pour réaliser ce container, plusieurs niveaux ont du être créés. Comme le montre le schéma à côté, je me suis inspiré du modèle en couche du modèle OSI, pour l'appliquer au Plug In.
Pour réaliser ce type de plug-In un assistant a été utilisé : Plug-In wizzard. Cet assistant permet de créer un squelette des fonctions. En paramétrant le compilateur ( Visual C++), on arrive à compiler le plug-In sous la forme d'une DLL, avec la possibilité de faire du débuggage.
La fonction principale de dérivation donnera alors (ici simplifiée pour une meilleure lecture) :
UNMANGLE MAIN(long procNum, PackagePtr paramList,void **data, ResultValue *returnedValue)
#if GENERATING68K
PrepareCallback(); /* <--Callbacks MUST be located in this file */
switch(procNum)
case kInitPackage: //Initialisation du plugIn
SETCALL4D(paramList);
Init_Decalage();
*returnedValue = kDontPurgePackage;
case kDeinitPackage: //On quitte 4D.
// DeInit_Decalage;
case PACK_SH_Crypt_Blob: //La fonction pour crypter un BLOB est appelée
SH_Crypt_Blob((XHANDLE *)returnedValue,(XHANDLE *)paramList[0],(long *)paramList[1]);
case PACK_SH_DefineKey: //Definition d'une clé.
SH_DefineKey((short *)returnedValue,(TextBlock *)paramList[0],(TextBlock *)paramList[1],(long *)paramList[2],(long *)paramList[3],(long *)paramList[4]);
case PACK_SH_GenerateKey: //Génération d'une clé
SH_GenerateKey((short *)returnedValue,(TextBlock *)paramList[0],(TextBlock *)paramList[1],(long *)paramList[2],(long *)paramList[3],(long *)paramList[4]);
ExitCodeResource(); //Spécifique processeurs motorola
Cette fonction correspond à la fonction principale, appelée à chaque appel au plug-In. Il faut alors regarder quelle fonction est appelée pour rediriger sur la bonne méthode.
Chaque fonction appelée doit regarder dans quel contexte cryptographique on se trouve. En fonction d'une constante passée en paramètre l'algorithme sera choisi.
Le rôle d'une fonction container est un rôle principalement d'abstraction : les paramètres et autres variables sont d'un accès relativement difficile. Une fonction doit donc prendre les paramètres, les rendre facilement utilisables (sous la forme d'un pointeur sur une zone mémoire), puis prendre le résultat de la fonction cryptographique pour le redonner à 4D sous la forme d'un Handle
Handle (Pointeur de pointeur sur une zone mémoire).
Voici en exemple la fonction permettant de crypter un BLOB (Binary Large Object), en fonction de l'algorithme choisi en paramètre.
/* # SH_Crypt # */
/* Procedure de cryptage d'un blob.
Retourne un nouveau blob.
Prends en argument le blob a crypter et le type d'algorithme. */
void SH_Crypt_Blob(XHANDLE *returnedValue, XHANDLE *Data, long *Type)
char * pData, *vRet;
if (*Data) // s'il y a quelque chose a crypter
LongData=GetHandleSize(*Data);
HLock(*Data);
pData=(char *)**Data; //Récupération du Handle sous la forme d'un simple pointeur.
switch(*Type) // type de cryptographie
case 1 : // Simple decalage
vRet=Crypt_Decalage(pData, LongData);
case 2: // RC5
vRet=Crypt_RC5(pData, LongData);
// Ici on peut rajouter l'appel à d'autre moyen cryptographique.
HUnlock(*Data); // On débloque la zone mémoire pour éviter fragmentation.
*returnedValue=NewHandle(_msize(vRet)); // on créé la zone en retour.
HLock(*returnedValue);
memcpy(**returnedValue, vRet, _msize(vRet));
free(vRet);
HUnlock(*returnedValue);
Il faut ensuite créer des fonctions de cryptographies qui prennent en paramètre un pointeur sur une zone mémoire, et qui retournent un pointeur sur une nouvelle zone mémoire cryptée. Ses fonctions sont les plus faciles à trouver : il existe énormément de codes source cryptographiques sur Internet. Le problème étant d'adapter ses sources qui n'ont pas forcément les mêmes types de données, et qui ont souvent des constantes qui perturbent les autres fonctions.
Pour commencer une fonction de cryptographie Simple a été créée : il s'agit tout simplement du chiffre de Jules César qui consiste à effectuer une rotation du texte en clair avec le texte chiffré. On notera que ce type de cryptographie est à la fois le mode le plus simple à déchiffrer mais aussi la cryptographie idéale:
Si la clef est courte il est très facile de retrouver le message original. Si la clef s'allonge et devient aussi longue que le message on arrive alors à l'algorithme du masque jetable. Cet algorithme est alors l'algorithme le plus sûr existant. Dans le cas de l'algorithme à masque jetable
masque jetable, chaque octet du texte est combiné avec un autre octet connu uniquement par les personnes partageant le secret. Il n'est donc pas possible de retrouver mathématiquement le message original.
MemPtr Crypt_Decalage(char * Ptr, long Longueur)
char * Retour;
char * vClef;
long lClef;
vClef=Clef_Decalage.CleSecrete;
lClef=Bits2Bytes(Clef_Decalage.lCleSecrete);
Retour=new char[Longueur];
if (Longueur>0)
if (lClef>0)
Retour[i]=Ptr[i]+vClef[i%lClef]; //Algorithme lui même.
Retour[i]=Ptr[i];
Dans ce mode cryptographique il a été nécessaire d'établir beaucoup d'étapes avant de parvenir à un résultat re-exploitable mais comme nous le verrons difficilement applicable par sa grande complexité et la faiblesse du langage JavaScript.
Le but principal est ici de faciliter au maximum l'interface utilisateur. L'idéal étant de suivre la schéma suivant :
Il suffit donc de remplacer le tage <BODY> par <BODY OnLoad="Dechiffre">, pour que la fonction de déchiffrage puisse agir au chargement. Cette fonction ira vérifier la présence d'un mot de passe dans un cookie
cookie, qui ici a été nommé password password. La fonction Dechiffre devra contenir autant d'appels à la fonction de décryptage qu'il y a d'objets à décrypter. Ici JavaScript JavaScript prend tout son sens : il suffit de prendre l'attribut value des objets de type texte pour pouvoir récupérer les valeurs chiffrées des différents éléments de la page. La page à chiffrer devra donc contenir les différents algorithmes de cryptage/décryptage décrits plus bas, mais aussi l'appel à ses fonctions avec les différentes zones déjà renseignées. Le mieux est d'avoir un serveur dynamique qui puisse récupérer la page et remplacer les bons éléments.
Un problème crucial s'est posé : traduire du C en Javascript. Dans l'absolu, cela semble facile. Néanmoins JavaScript dispose de très peu de types de données : Entier long, flottant et alpha. De plus le typage et le transtypage sont impossibles. Je me suis donc résolu à tout traduire en Hexadécimal et à travailler en Hexa. Le principal problème restant la traduction ASCII en Hexa. Il est en effet difficile de connaître en JavaScript le code ascii de la lettre 'a'. De plus l'algorithme devant être cross plateforme la traduction de la lettre 'é' par exemple est difficile : en fonction de la plateforme cible d'exécution, celui-ci change. Face à tous ces problèmes il ne m'a pas semblé nécessaire de développer complètement cette technologie. Il reste néanmoins une solution élégante facile à utiliser. Mais cette solution n'est pas universelle.
L'algorithme de déchiffrement de l'algorithme simple donne en JavaScript :
function Txt2Num(Para)
return(eval('0x'+Para));
function Num2Txt(Param)
var Tmp, res;
Tmp=Param/16;
Tmp=Math.floor(Tmp);
if (Tmp>=10)
res=unescape("%"+(41+Tmp-10));
res=unescape("%"+(30+Tmp));
Tmp=Param%16;
res=res+unescape("%"+(41+Tmp-10));
res=res+unescape("%"+(30+Tmp));
function Hexa2Txt(Parai)
var retur='';
for (i=0; i<Parai.length; i+=2)
retur=retur+unescape("%"+Parai.substring(i, i+2));
return(retur);
function uCrypt_Decalage( Ptr, Longueur)
var lClef=0, Tmp1, Tmp2;
var vretour='';
var vClef= GetCookie('Password', document.cookie); // récupère le mot de passe
// sotcké dans un cookie.
lClef=vClef.length;
Longueur=Ptr.value.length;
for (i=0;i<Longueur;i+=2)
Tmp1=Txt2Num(Ptr.value.substring(i, i+2));
Tmp2=Txt2Num(vClef.substring(i%lClef, i%lClef +2));
vretour=vretour+Num2Txt((Tmp1-Tmp2)%255);
vretour=vretour+Ptr.value;
Ptr.value=vretour;
Comme on le voit, la tâche n'est pas très aisée. Néanmoins cela fonctionne correctement dans des cas simples homogènes en terme d'architecture.
Côté serveur HTTP, il faudra prévoir l'analyse d'une page HTML et le remplacement des différents éléments par leur code chiffré. Pour cela 4D possède un avantage immense : en plus des fonctions évoluées de publication
publication, on peut capter le flux HTTP envoyé, pour le triturer à notre guise. Il "suffit" de prendre ce flux, de regarder si des parties doivent êtres chiffrées, chiffrer ses parties, et enfin insérer les javascripts adéquats, avec bien sûr l'appel dans ses javascripts des zones HTML devant être chiffrées. Pour cela, j'ai utilisé l'architecture du schéma 2.3a.
On voit ici la complexité du traitement. Il faut effectivement effectuer les opérations suivantes :
1. Vérifier si besoin cryptographique
2. Si Oui, identifier l'algorithme et le mot de passe utilisé
3. Isoler la zone de chiffrement.
4. Dans cette zone, identifier les éléments devant êtres chiffrés (Ici les zones de saisies).
5. Chiffrer (en Hexa), les zones de saisies, et les identifier.
6. Retourner le flux en Insérant les fonctions JavaScripts et les appels adéquats.
Cela permet par la suite d'envoyer n'importe quelle page HTML, tout en insérant le chiffrement dans les zones "critiques". Ces zones sont alors déchiffrées automatiquement pour toute personne possédant le mot de passe. L'utilisateur voit ici une facilité extrême. Mais le développeur voit sa tâche compliquée par le nombre de plateforme
plateforme à soutenir, ainsi que par le nombres d'éléments HTML différents à chiffrer. En effet dans cette solution il est impossible de chiffrer des zones de texte statique (sauf en passant par des variables).
Cela a été réalisé grâce à 4D, mais demande un traitement du flux par environ 250 lignes de codes 4D. Bien que le langage puisse être compilé, le nombre de traitement est trop important pour supposer une utilisation intensive. De plus, le moteur HTTP de 4D n'est pas le moteur le plus rapide et supporte difficilement plus de 15 hits
hits / seconde (Au dessus de 10 hits, il faut que les traitements soient très peu nombreux).
Le serveur utilise la décomposition suivante (on retrouvera une partie du code source en annexe:
Filtre Cryptographique Filtre Cryptographique.
Pour pouvoir réaliser pratiquement ce type de configuration, l'architecture suivante a été envisagée. Il s'agit ici d'un prototype réalisé avec un langage multiprocess multiprocess : 4D 4D
Dans ce type d'architecture, on a trois processus distincts :
§ Le process d'entrée ( P_In).
Il ouvre un descripteur (accept), prends les données et les place dans un tableau. Ce descripteur est placé à côté des données.
§ Process de traitement ( P_Master). Il effectue les actions suivantes :
-Retire les élément de la pile
-Traite (decrypte, authentifie)
-Envois au serveur les éléments traités
-Prends le résultat du serveur et les "traite".
-Place le résultat dans un autre tableau.
§ Process de sortie ( P_Out).
Il renvoie au client l'information demandée en dépilant la pile remplie par le process maître. Ce dernier peut ou non fermer la connexion.
L'avantage de ce type d'interface est la liberté vis-à-vis des données en entrée et en sortie. Le process master peut en effet être modifié simplement pour prévoir les différentes architectures. (Avec ou sans contrôle de clé
contrôle de clé).
De la même manière, ce process peut facilement être modifié afin de servir de serveur de clé dans l'architecture avec un serveur de sécurité.
Cette architecture peut être améliorée (et donc compliquée) en découpant le process maître en par exemple trois process différents. Ainsi le chiffrement/déchiffrement pourrait être pris en charge par deux process différents, permettant ainsi de changer le type de cryptographie simplement en changeant de process.
On pourrait aussi imaginer un process de chiffrement/déchiffrement par le client. Ce qui permettrait simplement d'être indépendant de la cryptographie client par client : Chaque client pourrait choisir son type de cryptographie. Mais la prolifération des process n'est pas innocentes dans 4D. En effet chaque process prend une part non négligeable de mémoire (on peut estimer cette part, pour une base n'effectuant que ce type d'opération, à environ 800K), et de temps machine (Le temps machine pris par les process évolue de manière asymptotique en fonction du nombre de process).
On notera que le process Maitre effectue le plus de traitements, c'est lui qui a en charge le protocole de communication entre deux proxy.
Techniquement, il faut faire une application TCP/IP, qui prends les connexions en entrée, les traite, les envois en clair à un serveur, et fait l'opération inverse.
La première étape consiste donc à faire un proxy
proxy inutile : Celui-ci prends les entrées sur un port particulier, et les renvois sur un autre numéro de port. Cette opération effectuée, il reste à crypter l'information.
Ainsi par exemple, la décomposition de process d'entrée est :
Ecouter sur le port d'entrée
Si (Il Existe une connexion)
Si (Ok)
Lire les données sur port d'entree
Tant que (donnees récupérées>0)
Tant que ( Semaphore (Ecriture tableau)
Mettre donnees recupérées dans tableau
Effacer semaphore
Fin tant que .
Pour pouvoir s'échanger de l'information entre deux proxy, il faut développer un protocole de communication. L'idéal (qui au mi-juin 98 n'est pas développé), serait d'utiliser le protocole SSL, afin de créer un standard.
Pour commencer un protocole de communication simple est introduit :
Code Correspond à un identifiant
0 - Erreur
1  Envoi de clé.
2  Envoi de message
3  Acquittement Ok
Nom Nom logique de l'utilisateur, ou encore identifiant, suivi du caractère 0 (chaine en C.
lClé Longueur de la clé exprimée en octets.
Clé Clef elle même (Il s'agit ici d'un simple exercice, le but est d'essayer un protocole simple).
lMess Longueur du message en octets.
Message Message à faire passer
Le principe d'échange devient alors :
Lorsque la machine A veut parler à la machine B, alors on établi une connexion, en échangeant un mot de passe (la liaison TCP est bi-directionnelle). Lorsque les deux parties sont synchronisées sur un mot de passe (phase 1 et 2), alors un dialogue peut s'établir.
Ce genre de sécurité est bien adapté à certains services comme TelNet
TelNet, mais est très contrariant pour des services comme HTTP HTTP. Dans ce dernier cas on est en mode non connecté : le navigateur demande de l'information, et coupe la connexion connexion dès qu'il a obtenu son information. Ainsi on peut s'échanger des mots de passes plusieurs fois dans une seule page HTML.
Le deuxième problème des navigateur est qu'il établissent eux-mêmes leur propre connexion : ceux-ci peuvent aller directement sur un autre serveur sans forcément passer par le proxy. L'utilisation d'un proxy devra donc être obligatoirement couplé à une correcte configuration du routeur. Dans les réseaux Intranet, il faudra configurer le navigateur sur un serveur de proxy : le filtre en local sur la machine.
Le bonheur suppose sans doute quelque inquiétude, quelque passion, une pointe de douleur qui nous éveille à nous même.
Alain, Propos. Le roi s'ennuie.
Au travers de cette étude, j'ai pu approfondir ma connaissance des systèmes de sécurité. Si la plupart des algorithmes des systèmes cryptographiques répondent à des principes connus de tous, c'est surtout le contexte que j'ai cherché à développer.
Sur le plan légal, l'état, d'une part, limite les performances des systèmes cryptographiques autorisés. Les auteurs, d'autre part, déposent des brevets qui imposent aux utilisateurs le paiement de royalties.
Sur le plan technique, dans les téléphones portables, les distributeurs de billets... on trouve depuis longtemps des systèmes de cryptographie. A défaut d'un grand degré de sécurité, ces systèmes sont "suffisants" dans la mesure ou, par définition ils ne sont pas reliés à d'autres ordinateurs.
Sur Internet, accessible à tous, y compris à ceux dotés de puissants ordinateurs et parfois aussi de mauvaises intentions, la cryptographie doit être abordée avec une autre ampleur.
Actuellement on trouve principalement deux types de chiffrements distincts:
Le chiffrement matériel et le chiffrement logiciel.
Dans cette deuxième partie, j'ai étudié concrètement l'implémentation physique d'une sécurité dans un serveur Intranet. Cela a commencé par la programmation d'un plug-in 4D de cryptographie. Ensuite j'ai traduit certaines fonctions du plug-in en Javascript afin d'appréhender la difficulté. Finalement l'ajout de Javascripts est automatisé grâce à l'analyse/traduction à la volée des pages HTML.
Ainsi j'ai pu découvrir qu'au-delà de la difficulté de traduction d'un algorithme en JavaScript, il existait d'autres problèmes que le JavaScript seul ne peut résoudre. Le langage reste trop dépendant de la machine et trop "léger" pour pouvoir développer des algorithmes évolués. L'utilisation de cette technologie reste suffisante pour certains besoins faibles de sécurisation.
Une autre technologie, se rapprochant des techniques existantes consiste à protéger à un niveau en dessous de la couche applicative. SSL, en particulier, permet cette fonctionnalité et fournit en plus des fonctionnalités d'authentification.
Afin d'étudier cette voie j'ai réalisé un "proxy" de sécurité : celui-ci prend les données en entrée et les ressort, soit chiffrées, soit en clair. Cette approche permet d'observer que les connexions TCP/IP demandent une QoS non négligeable en terme de temps. Dans une connexion Navigateur/Serveur, le serveur doit en effet être toujours disponible. Un autre problème se pose en plus de la difficulté technique : celui de la création d'un protocole permettant d'établir une connexion sécurisée.
Ainsi l'étude des solutions existantes, de la faisabilité technique permet de découvrir que le chiffrement sur le Web est un problème bien plus vaste que le simple chiffrement des communications. Une solution idéale n'existe pas. On trouvera plutôt un éventail de solutions qui permettra un choix de "la solution" en fonction du type de sécurité désirée.
ANSI American National Standards Institue. Organisation appuie et publie des standards pour l'industrie.
Authentification Processus appliqué par l'expéditeur et le destinataire pour garantir l'intégrité des données et fournir l'authentification de l'origine des données. (ISO 8730).
BNC British Naval Connector. Connecteur de forme ronde, pour les câbles coaxiaux.
Chiffre Discipline qui englobe tous principes, moyens et méthodes destinés à la transformation de données afin de cacher leur contenu, d'empêcher leur modification et leur utilisation frauduleuse. (ISO 8732).
Clés Séries de symboles commandant les opérations de chiffrement et de déchiffrement (ISO 7498-2:1989).
Cryptogramme Informations chiffrées. (ISO 8732).
Cryptographie Moyen de modification de l'information rendant impossible la lecture sans connaissance d'une clé.
DNS Data Name System. Système permettant d'associer l'adresse IP d'un machine à un nom et inversement.
FTP File Transfer Protocol. Protocole de transfert de fichier sur Internet.
HTTP HyperTextTransferProtocol. Protocole de transfert d'informations Hypertexte sur Internet/
Intégrité des données Capacité qu'ont des données de ne pas pouvoir être altérées ou détruites d'une manière frauduleuse. (ISO 8730).
ISO International Standards Organisation. Organisation internationale, qui publie différent standards réseaux dont la plupart est compatible avec Internet.
Java Language objet, indépendant de plateforme. Promulgué par Sun.
JavaScript Language objet, venant du C, et permettant l'ajout de dynamisme dans les pages HTML.
LAN Local Area Network. Réseau de machines localisé sur un seul site physique.
PEM Privacy Enhanced Mail. Protocole de protection d'eMail utilisé par certains logiciels du commerce.
PGP Pretty Good Privacy. Logiciel permettant de sécurisé l'envoi de message. Utilise des algorithmes interdits d'utilisation en France.
PKCS Public Key Cryptography standards. Standard s publiés par la société RSA qui décrive l'utilisation de la cryptographie a clé publique.
Politique de sécurité Ensemble des critères permettant de fournir des services de sécurité. (ISO 7498-2:1989).
PPP Point to Point Protocol. Protocole standard permettant l'accès distant entres deux ordinateurs.
Proxy Service qui peut crypter ou contrôler les accès réseau.
Repeteur Matériel permettant d'amplifier un signal devenu trop faible.
RJ45 Connecteur standard réseaux pour les câbles en paires torsadées..
Routeur Matériel permettant de relier différents réseaux en dirigeant l'information.
RSA Rivest Shamir Adleman. Algorithme à clé publique utilisé dans la plupart des logiciels.
S-HTTP Secure HTTP. Protocole de chiffrement des pages HTML, et des informations circulant sur Internet.
SCSSI Service Central de la Sécurité des Systèmes d'Information. Organisme français de contrôle de l'utilisation de la cryptographie.
SLIP Ancien système de connexion point à point de matériels.
SMTP Simple Mail Transfer Protocol Protocole d'envoi de mails sur systèmes hétérogènes.
SSL Secure Socket Layer. Protocole de chiffrement et d' authen-tication utilisé notamment par netscape.
Système à clé publique Algorithmes cryptographiques permettant de crypter l'information à l'aide d'une clé et de décrypter uniquement à l'aide d'une supplémentaire.
Système à clé secrète Système permettant d' obscurcir un texte à l'aide d'une clé.
Système asymétrique Voir Système à clé publique.
Système symétrique Voir Système à clé secrète.
TCP/IP Transport Control Protocol. Protocole réseau permettant le transport fiable de l'information d'une machine à une ou plusieurs autres
TelNet Application permettant de s'interfacer avec des systèmes type Unix.
Trame(IP). Elément de transfert de l'information sur les réseaux locaux et étendus.
UDP User Datagramm protocol. Protocole de transmission d'information non fiable.
WAN Wide Area Network. Interconnexion de réseaux, généralement sur de longues distances.
W3. World Wide Web. Ensemble de protocoles de présentation et de diffusion de l'information sur Internet.
4D 20, 34
algorithmes 21
algorithmes restreint 6
Attaque active 12
Attaque passive 11
authentifier 25
Cassage complet 6
chiffrement asymétrique 13
clé asymétrique 7
Clé publique 10
clé secrète 7
connexion 36
container 27, 28
contrôle de clé 34
CryptoAPI 11
cryptographie symétrique 7
décret 13
Filtre Cryptographique 34
gestions des clés. 27
HTTP 20, 36
implémentation 34
Internet Tool Kit 21
IPSEC 18
JavaScript 20, 21, 30, 31
Journal Officiel 13
légaux 15
masque jetable 30
MD5 18
Message Digest 18
multiprocess 34
Netscape 19
niveau de protection 18
Obtention globale 6
Obtention locale 6
password 31
PGP 12, 17
plateforme 32
Plug-In 21, 27
proxy 21, 25, 35
RC4 18
Réseaux Virtuels Privés 18
SCSSI 13, 14
Secure Sockets Layer 19
serveur 25
Serveur Web 20
Service Pack 3 11
SHA-1 18
S-HTTP 25
SSL 19, 21
TCP/IP 16, 20, 21
TelNet 36
test d'arrêt simple 45
tiers de confiance 25
Tiers de Confiance 14
UDP 16, 20
Windows NT4.0 11
Bruce Schneier, Trad. Laurent Viennot.
Ed. International Thomson Publishing France. 1996.
John Vacca.
Ed Sybex. 1996.
TCP/IP, règles et protocoles
W.R. Stevens.
Ed Addison Wesley
Java Clients/Serveur
C. Nicolas, C. Avare, F. Najman.
Ed. Eyrolles. 1998.
Java Facile.
Alexandre Maret.
T. Cormon, C. Leiserson, R. Rivest.
Ed. Dunod. 1994.
Ed. Addison Wesley. 1997.
P. Chaléat, D. Charnay
Le Macmillan TCP/IP
K. S. Siyan, Trad. : P. Naniche, Y. Schwartz
Ed. Simon & Schuster Macmillan.1998.
Contient les publications du Journal Officiel, les texte de loi, ...
http://www.netscape.com/assist/security/index.html
Contient notamment des descriptions de SSL, des moyens de protections par email,... Le téléchargement des API "sensibles" est impossible à partir de la France sur ce site.
http://www5.pair.com/jorgep/tracks/security/ipsec/
Pages contenant, des liens et les références sur IPsec, pour la création de VPN.
http://www.ncf.carleton.ca/~cd435/ob.html
Site recensant différents liens ayant trait à la cryptographie et à Internet, la propriété intellectuelle, ...
http://cwis.kub.nl/
Site recensant les points juridiques concernant le droit et la cryptographie, quelque soit le pays.
Site permettant de se connecter à plus de 170 sites sur la cryptographie. Descriptions des protocoles et autres algorithmes. C'est LE site de référence.
MOYENS ET PRESTATIONS OPERATIONS ( [1] · ) pour lesquelles la déclaration préalable se substitue à l'autorisation
1. Equipements dont le déchiffrement d'un message ou d'un fichier au moyen du parcours systématique de toutes les clés possibles ne requierent pas plus de 2 40 essais sur un test d'arrêt simple test d'arrêt simple F
2. Equipements conçus ou modifiés pour utiliser la cryptologie faisant appel à des technique analogiques telles que : F
a) Equipements utilisant des techniques de mélange de bandes "fixes" ne dépassant pas 8 bandes et où les changements de transposition ne s'effectuent pas plus d'une fois toutes les secondes
b) Equipements utilisant des techniques de mélanges de bandes "fixes" dépassant 8 bandes et où les changements de transposition ne s'effectuent pas plus d'une fois toutes les dix secondes
d) Equipements de fac-similé;
MOYENS ET PRESTATIONS OPERATIONS ( [2] · ) sans formalités préalables.
1. Equipements dont le déchiffrement d'un message ou d'un fichier au moyen du parcours systématique de toutes les clés possibles ne requierent pas plus de 2 40 essais sur un test d'arrêt simple U, I
2. Equipements conçus ou modifiés pour utiliser la cryptologie faisant appel à des techniques analogiques telles que : U, E, I
a) Equipements utilisant des techniques de mélange de bandes "fixes" ne dépassant pas 8 bandes et où les changements de transposition ne s'effectuent pasplus d'une fois toutes les secondes
3. Cartes à microprocesseur personnalisés ou leur composants spécialement conçus, incapables de chiffrer le trafic de messages ou les données fournies par l'utilisateur ou leur prestation de gestion de clés associées. F, U, E, I
4. Equipements de réception de télévision type grand public, sans capacité de chiffrement numérique où le déchiffrement numérique est limité aux informations vidéo, audio, informatique et de gestion F, U, E, I
5. Radiotéléphones portatifs ou mobiles destinés à l'usage civil qui ne sont pas en mesure de procéder au chiffrement de bout en bout. F, U, E, I
6. Equipements autonomes de lecture de disques vidéo numérique, de type grand public sans capacité de chiffrement où le déchiffrement est limité aux informations vidéo, audio, informatique et de gestion. F, U, E, I
7. Moyens matériels ou logiciels spécialement conçus pour assurer la protection des logiciels contre la copie ou l'utilisation illicite dont les fonctions de chiffrement ne sont pas accessibles à l'utilisateur F, U, E, I
8. Equipements de contrôle d'accès, tels que machines automatiques de distribution de billet, imprimantes libre-service de relevés de compte ou terminaux de points de vente protégeant les mots de passe, numéro d'identification personnel ou autre donnée F, U, E, I
9. Moyens ou prestations conçus pour protéger des mots de passes, des codes d'identification personnels ou des données d'authentification similaires, utilisés pour contrôler l'accès à des données, à des ressources, à des services où à des locaux. U, E, I
10. Moyens ou prestations conçus pour élaborer ou protéger une procédure de signature, une valeur de contrôle cryptographique, un code d'authentification de message ou une information similaire, pour vérifier la source des données, prouver la remise des clés. U, E, I
11. Systèmes de gestion de facturation inclus dans les dispositifs de relevés de compteur dont les fonctions de chiffrement sont directement liées au comptage. F, U, E, I
12 Equipements dotés de moyens de cryptologie lorsqu'ils accompagnent les personnalités étrangères sur invitation de l'Etat U, E, I
13. Stations de base de radiocommunications cellulaires commerciales civiles présentant toutes les caractéristiques suivantes :
a) Limitées au raccordement de radiotéléphones qui ne permettent pas d'appliquer des techniques cryptographiques au trafic de messages entre les terminaux mobiles, sauf sur les liens directs entre radiotéléphones et stations de bases. b) Et ne permettant pas d'appliquer des techniques cryptographiques au trafic de messages sauf sur l'interface radio.
Arrêté du 13 mars 1998, définissant la demande d'utilisation de la cryptographie.
Arrêté du 13 mars 1998 définissant la forme et le contenu du dossier
concernant les déclarations ou demandes d'autorisation relatives aux
NOR : PRMX9802729A
Vu la loi no 90-1170 du 29 décembre 1990 modifiée sur la réglementation des télécommunications, notamment son article 28 ; Vu le décret no 98-101 du 24 février 1998 définissant les conditions dans lesquelles sont souscrites les déclarations et accordées les autorisations concernant les moyens et prestations de cryptologie, notamment ses articles 5, 10 et 13,
La partie technique comprend une description conforme au modèle annexé au présent arrêté, en trois exemplaires. Les dossiers déposés dans le cadre du régime simplifié de déclaration prévu à l'article 9 du décret du 24 février 1998 susvisé ainsi que ceux déposés pour obtenir le renouvellement d'une autorisation ne comportent pas de partie technique. Celle-ci est remplacée par un engagement écrit de la personne déposant le dossier certifiant soit que l'impossibilité pour le moyen ou la prestation d'assurer des fonctions de confidentialité ne résulte pas d'un simple dispositif de verrouillage, soit que les caractéristiques techniques du moyen ou de la prestation sont inchangées par rapport à la description figurant dans la partie technique du dossier déposé lors de la première délivrance de l'autorisation.
Art. 2. - Sont portés à la connaissance du service central de la sécurité des systèmes d'information, au moins un mois à l'avance :
- tout changement de nature à modifier le contenu du dossier de déclaration ou de demande d'autorisation ;
- la cessation de l'activité déclarée ou autorisée.
Art. 3. - La secrétaire générale de la défense nationale est chargée de l'exécution du présent arrêté, qui sera publié au Journal officiel de la République française.
A N N E X E PREMIER MINISTRE
18, rue du Docteur-Zamenhof,
(téléphone : 01-41-46-37-00, fax : 01-41-46-37-01)Numéro de dossier (*) :
.................... Déclaration/demande d'autorisation concernant un moyenou une prestation de cryptologie
Partie administrative Cocher la ou les cases correspondantes :
Déclarationsimplifiée.de fourniture :en vue de l'utilisation générale ;en vue de l'exportation.d'importation en provenance de : ....................d'utilisation personnelle.
Demande d'autorisation de fourniture pour une durée de : ....................(cinq ans maximum) d'un moyen ou d'une prestation qui n'utilise que des conventions secrètes gérées par un organisme agréé.de fourniture pour une durée de .................... (cinq ans maximum) :en vue de l'utilisation générale ;en vue de l'utilisation collective.d'exportation pour une durée de .................... (cinq ans maximum).d'importation en provenance de ....................d'utilisation personnelle pour une durée de : ....................(dix ans maximum).(*) Réservé à l'administration.A.
- Déclarant ou demandeur d'autorisationA.1. Société Nom : ....................Raison sociale : ....................Nationalité : ....................Numéroté SIRET : ....................Adresse : ........................................Numéro detéléphone : ....................Numéro de télécopie : ....................Adresse du courrier électronique : ....................Personne chargée du dossier administratif
Nom et prénoms : ....................Adresse : ........................................Numéro de téléphone :....................Adresse du courrier électronique : ....................A.2. ParticulierNom et prénoms : ....................Nationalité : ....................Adresse : ........................................Numéro de téléphone : ....................Adresse du courrier électronique : ....................B.
- A renseigner selon les cas suivantsB.1. Demande d'autorisation de fourniture d'un moyen ou d'une prestation
qui utilise des conventions secrètes gérées par un organisme agréé.
Références de(s) organisme(s) agréé(s) : ................................................................................B.2. Demande d'autorisation de fourniture en vue de l'utilisation collective Catégories éventuelles d'utilisateurs auxquels le moyen ou la prestation est destiné :Administrations (à préciser) : ....................Grandes entreprises (préciser secteur d'activités) :....................Etablissements de crédit : ....................PME (préciser secteur d'activités) : ....................Autres (à préciser avec secteur d'activités) : ....................B.3. Demande d'autorisation d'utilisation personnelle.
Besoins justifiant la demande : ................................................................................Lieux d'utilisation du moyen de cryptologie : ................................................................................Le cas échéant, réseaux de télécommunications employés : ................................................................................C.
- Moyen ou prestation auquel s'appliquela déclaration ou la demande d'autorisationC.1. Moyen ou prestation de cryptologie Référence commerciale : ....................Référence constructeur : ....................Version : ....................Description succincte : ....................................................................................................Référence de l'agrément du moyen s'il a été soumis au ministère chargé des télécommunications : ....................C.2. Fabricant du moyen ou fournisseur de la prestationNom : ....................Raison sociale : ....................Adresse : ........................................Numéro de téléphone : ....................Numéro de télécopie : ....................Adresse du courrier électronique : ....................C.3. Personne chargée du dossier techniqueNom et prénoms : ....................Adresse : ........................................Numéro de téléphone : ....................Numéro de télécopie : ....................Adresse du courrier électronique : ....................C.4. DiversSi le moyen ou la prestation utilise des moyens ou prestations préalablement déclarés ou autorisés, préciser, pour chacun d'eux, leur identification, référence et date de notification de déclaration ou d'autorisation : ........................................C.5. Services de cryptologie fournis Authentification (*) : ....................Contrôle d'accès (*) : ....................Signature (*) : ....................Intégrité (*) : ....................Confidentialité (*) : ....................Téléphone télécopie messagerie transmissions de données (préciser le(s) type(s) de données chiffrées, par exemple données à caractère financier, médical, de gestion,...) : ....................Autre(s) à préciser : ....................Autre(s) à préciser (*) : ....................C.6.
Installation des algorithmes Logiciel.Matériel (à préciser) : ....................(*) Préciser le(s) nom(s) de(s) algorithme(s) utilisé(s).D.
- Attestation Je soussigné (nom, prénoms) .................... ,agissant en qualité de .................... ,représentant le fournisseur, exportateur, importateur, utilisateur (*), certifie que les renseignements figurant sur cette déclaration/ demande d'autorisation (*) sont exacts et ont été établis de bonne foi, toute fausse déclaration ou tout manquement aux engagements souscrits m'exposant aux sanctions prévues par l'article 28 de la loi no 90-1170 du 29 décembre 1990 modifiée et par le décret no 98-101 du 24 février 1998.
Date : ....................Signature(*)
Partie technique A joindre au dossier de déclaration ou de demande d'autorisation concernant les moyens et prestations de cryptologie. La partie technique comporte les informations suivantes :
- la référence commerciale du produit :
- la description générale du produit, le manuel utilisateur ;
- la description des services offerts par le produit ;
- la description des fonctions de cryptologie offertes par le produit (chiffrement, signature, gestion de clés,...) ;
- soit la description complète des procédés de cryptologie employés, sous la forme d'une description mathématique et d'une simulation dans un langage de haut niveau, C ou Pascal ou tout autre après accord préalable du service central de la sécurité des systèmes d'information, soit la référence à un dossier préalablement déposé pour un produit usant du même procédé de chiffrement ;
- une sortie de référence du produit effectuée à partir d'un texte clair et d'une clé délivrés sur simple demande faite au service central de la sécurité des systèmes d'information dans le but de vérifier la conformité de la mise en oeuvre du produit à la description de celui-ci ;
- une sortie de référence du procédé de chiffrement effectuée à partir d'un texte clair et d'une clé délivrés sur simple demande faite au service central de la sécurité des systèmes d'information, dans le but de vérifier la conformité de la mise en oeuvre du procédé par rapport à la description de celui-ci : cette sortie de référence est obtenue par la simple action du procédé de chiffrement sur le texte clair, paramétré par la clé fournie, ses mise en oeuvre d'aucun prétraitement sur le texte clair ou post-traitement sur le texte chiffré ;
- la description complète de la gestion des clés mises en oeuvre par le moyen incluant au moins :
- l'intégration au procédé de chiffrement ;
- l'architecture des clés employées ;
- la fréquence de changement des clés ;
- le format de conservation s'il y a lieu ;
- la description du dispositif de dépôt et de récupération de clés inclus, dans le cas où la gestion de clés du moyen ou de la prestation est effectuée par un organisme agréé ;
- la description des mesures techniques mises en oeuvre pour empêcher l'altération du procédé de chiffrement ou de la gestion de clés associée ;
- la description des prétraitements subis par les données claires avant leur chiffrement (compression, formatage, ajout d'un en-tête, etc.) ;
- la description des post-traitements des données chiffrées, après leur chiffrement (ajout d'un en-tête, formatage, mise en paquet, etc.).
Ces sources ne contiennent pas les algorithmes cryptographiques (Ceux-ci ne sont que la recopie d'algorithmes disponibles sur Internet, avec quelques modifications).
/* Made by Sebastien Hervet - 13/03/98
/* #### HEADERS #### */
/* Do not remove these lines */
#if __INTEL__ /* <-- defined by CodeWarrior (x86 project) */
/* #include <Windows.h> */
#elif WIN32 /* <-- defined by Visual C++ */
#include <ASIPORT.H> /*To use Altura headers (in the folder PPC_H, placed in the project folder)*/
#define USINGCBADDRESS 1
#include <SetupA4.h> /* <-- Needed for globals in 68k */
#include "Ext4D.h" /* <-- Extensions Kit Entete */
/* #### HEADERS END #### */
#include "CrypAlgo.h"
long Bits2Bytes(long );
/* #### PROTOTYPES #### */
/* The function declarations must not be changed */
UNMANGLE MAIN(long procNum, PackagePtr paramList,void **data, ResultValue *returnedValue);
void SH_Crypt_Blob(XHANDLE *returnedValue, XHANDLE *Data, long *Type);
void SH_DefineKey(short *returnedValue, TextBlock *KeyOne, TextBlock *KeyTwo, long *Type, long *Lg1, long *Lg2);
void SH_GenerateKey(short *returnedValue, TextBlock *KeyOne, TextBlock *KeyTwo, long *Type, long *Lg1, long *Lg2);
void SH_GiveKey(short *returnedValue, TextBlock *KeyOne, TextBlock *KeyTwo, long *Type, long *Lg1, long *Lg2);
void SH_Sign_Blob(TextBlock *returnedValue, XHANDLE *Data, long *Type, long *Longueur);
void SH_UnCrypt_Blob(XHANDLE *returnedValue, XHANDLE *Data, long *Type);
PACK_SH_Crypt_Blob = 1,
PACK_SH_DefineKey,
PACK_SH_GenerateKey,
PACK_SH_GiveKey,
PACK_SH_Sign_Blob,
PACK_SH_UnCrypt_Blob
/* #### PROTOTYPES END #### */
/* #### MANDATORY GLOBALS #### */
/* CALL4DVALUE is used by call 4D */
#if __MWERKS__ && (__MWERKS__ <= 0x1100)
static Call4DProcPtr CALL4DVALUE; /* Call4D can be used only in this file */
Call4DProcPtr CALL4DVALUE; /* Call4D can be used in any file */
/* DLL instance of the plug-in (Windows only) */
static HANDLE ghInst;
/* #### MANDATORY GLOBALS (END) #### */
/* #### MAIN #### */
/* Do not modify MAIN */
case kInitPackage:
case kDeinitPackage:
case PACK_SH_Crypt_Blob:
case PACK_SH_DefineKey:
case PACK_SH_GenerateKey:
case PACK_SH_GiveKey:
SH_GiveKey((short *)returnedValue,(TextBlock *)paramList[0],(TextBlock *)paramList[1],(long *)paramList[2],(long *)paramList[3],(long *)paramList[4]);
case PACK_SH_Sign_Blob:
SH_Sign_Blob((TextBlock *)*returnedValue,(XHANDLE *)paramList[0],(long *)paramList[1],(long *)paramList[2]);
case PACK_SH_UnCrypt_Blob:
SH_UnCrypt_Blob((XHANDLE *)returnedValue,(XHANDLE *)paramList[0],(long *)paramList[1]);
/* #### MAIN END #### */
Return un nouveau blob.
if (*Data) // s'il y a quelque chose a crypte
pData=(char *)**Data;
case 3: //DES
vRet=Crypt_DES(pData, LongData);
case 4: //RSA
vRet=Crypt_RSA(pData, LongData);
HUnlock(*Data);
//if (*returnedValue)
//DisposeHandle(*returnedValue); //Est-ce a faire ?
*returnedValue=NewHandle(_msize(vRet));
/* Le pendant de crypt :-) */
void SH_UnCrypt_Blob(XHANDLE *returnedValue, XHANDLE *Data, long *Type)
char *pData, *vRet;
if (*Data) // s'il ya quelque chose a decrypte
vRet=uCrypt_Decalage(pData, LongData);
case 2 : // RC5
vRet=uCrypt_RC5(pData, LongData);
vRet=uCrypt_DES(pData, LongData);
vRet=uCrypt_RSA(pData, LongData);
/* Permet de definir la cle utilisee par un algorithme
Returne un code d'erreur en cas de probleme */
void SH_DefineKey(short *returnedValue, TextBlock *KeyOne, TextBlock *KeyTwo, long *Type, long *Lg1, long *Lg2)
long Long1=0, Long2=0;
Long1=*Lg1;
Long2=*Lg2;
if (!Long1) Long1=KeyOne->fSize*8;
if (!Long2) Long2=KeyTwo->fSize*8;
if (((int) Long1/8)>KeyOne->fSize) Long1=KeyOne->fSize*8;
if (((int) Long2/8)>KeyTwo->fSize) Long2=KeyTwo->fSize*8;
if ((KeyOne->fData))
if (!(KeyTwo->fData))
KeyTwo->fData=NewHandle(0);
HLock(KeyOne->fData);
HLock(KeyTwo->fData);
case 1: //ici seule la clé un sera utilisé (Clé 2 sert a rien)
ModKey_Decalage( (*KeyOne->fData), Long1,(*KeyTwo->fData), Long2 );
HUnlock(KeyOne->fData);
HUnlock(KeyTwo->fData);
*returnedValue=0;
/* Creev une cle de Longueur Longueur de bits, par l'algorithme de generation de cle spécifie par type.
La (ou les cles) sont places dans KeyOne et KeyTwo */
void SH_GiveKey(short *returnedValue, TextBlock *KeyOne, TextBlock *KeyTwo, long *Type, long *Lg1, long *Lg2)
char *Key1, *Key2;
long LL1, LL2;
LL1=Bits2Bytes(*Lg1);
LL2=Bits2Bytes(*Lg2);
GiveKey_Decalage(&Key1,&Key2,Lg1, Lg2);
GiveKey_Decalage(&Key1, &Key2, Lg1, Lg2);
KeyOne->fSize=(short)LL1;
if (KeyOne->fData)
ReallocateHandle(KeyOne->fData,LL1);
KeyOne->fData=NewHandle(LL1);
KeyTwo->fSize=(short)LL2;
if (KeyTwo->fData)
ReallocateHandle(KeyTwo->fData,LL2);
KeyTwo->fData=NewHandle(LL2);
memcpy(*(KeyOne->fData), Key1,LL1);
memcpy(*(KeyTwo->fData), Key2,LL2);
free(Key1);
/* Genere une ou une paire de clef selon la methode precisee dans Type */
void SH_GenerateKey(short *returnedValue, TextBlock *KeyOne, TextBlock *KeyTwo, long *Type, long *Lg1, long *Lg2)
int LG1, LG2;
LG1=Bits2Bytes(*Lg1);
LG2=Bits2Bytes(*Lg2);
KeyOne->fSize=LG1;
ReallocateHandle(KeyOne->fData, LG1);
KeyOne->fData=NewHandle( LG1);
KeyTwo->fSize=LG2;
ReallocateHandle(KeyTwo->fData, LG2);
KeyTwo->fData=NewHandle(LG2);
KeyGen_Simple(*(KeyOne->fData), LG1);
KeyGen_Simple(*(KeyTwo->fData),LG2);
KeyGen_Simple(*(KeyTwo->fData), LG2);
*returnedValue=KeyOne->fSize;
/* # SH_Signe # */
/* Permet de retourner une cl de long bits sur un data */
void SH_Sign_Blob(TextBlock *returnedValue, XHANDLE *Data, long *Type, long *Longueur)
if (returnedValue->fData)
returnedValue->fSize=Bits2Bytes(*Longueur);
ReallocateHandle(returnedValue->fData, returnedValue->fSize);
returnedValue->fData=NewHandle(Bits2Bytes(*Longueur));
Signe_Simple(*(returnedValue->fData), **Data, *Longueur);
/* #### DLL INSTANCE (WINDOWS ONLY) #### */
BOOL WINAPI DllMain (HINSTANCE hInst,DWORD wDataSeg, LPVOID lpvReserved)
/* #### DLL INSTANCE END #### */
Chiffrement a la volée du flux HTTP.
Methode principale
Appelée par le serveur HTTP. Prends en charge l'insertion des javascript dans la page (Algorithme stocké dans le data, dont un exemple a été donné dans le mémoire).
C_BLOB($0;$1)
C_TEXTE($Flux;vAlgo)
$Flux:=BLOB vers texte($1;Texte sans longueur)
TABLEAU ALPHA(50;TabVar;0)
C_ALPHA(40;VVType)
VVType:=""
Si (<>vJava=Vrai)
$Flux:=Java2Pages ($Flux)
CHERCHER([Algos];[Algos]Type=VVType)
Si (Enregistrements trouves([Algos])>0)
vAlgo:=BLOB vers texte([Algos]JavaAlgo;Texte sans longueur)
$Flux:=Remplacer chaine($Flux;"</HEAD>";"</HEAD>"+vAlgo)
vAlgo:=""
Boucle ($i;1;Taille tableau(TabVar)
vAlgo:=vAlgo+"SH_Decrypte(document.forms[0]."+TabVar{$i}+");"+Caractere(13)
$Flux:=Remplacer chaine($Flux;"]HSB[";vAlgo)
vAlgo:="<Body Onload="+Caractere(34)+"Decrypte()"+Caractere(34)+" OnUnLoad="
vAlgo:=vAlgo+Caractere(34)+"Quitter()"+Caractere(34)+" "
$Flux:=Remplacer chaine($Flux;"<Body ";vAlgo)
TEXTE VERS BLOB($Flux;$0;Texte sans longueur)
Methode Java2Pages
Procédure chargé de découper les parties devant être chiffrées dans la page HTML.
C_ENTIER LONG($Tmp;$i;$j;$BornG;$BornD)
C_TEXTE($Tag1;$TagC)
$Tag1:=$1
`On recherche tous les fragments de codes à chiffrer
$BornG:=Position("<SHSecurity";$Tag1) `Ah, on a trouver`
$BornD:=0
Si ($BornG>0)
$Tag1:=Sous chaine($Tag1;$BornG)
$BornD:=Position("</SHSecurity>";$Tag1)
Si ($BornD>0)
$TagC:=Sous chaine($Tag1;1;$BornD)
$TagC:=$Tag1
$Tmp:=Position($TagC;$1)
$1:=Supprimer chaine($1;$Tmp;Longueur($TagC))
$1:=Inserer chaine($1;wChiffre ($TagC);$Tmp)
$Tag1:=Sous chaine($Tag1;$BornD)
$Tag1:=""
Jusque ($Tag1="")
Methode wChaine
Methode chargee de recuperer le mot de passe et le type de cryptographie à utiliser.
C_TEXTE($Tmp;$Tmp2)
C_ENTIER LONG($Pos;$Pos2)
C_TEXTE(PassWord)
$Tmp:=Sous chaine($1;1;30)
PassWord:=wRecupVal ("PassWord";$1)
Si (Longueur(PassWord)=0)
PassWord:="Default"
: (Position("Simple";$Tmp)>0)
VVType:="Simple"
$0:=wChiffreSimple ($1)
Methode wChiffreSimpe
Découpe la partie HTML en simple tags indépendants. Donne les tags à la partie de chiffrement
C_TEXTE($1;$0;$Tag;$TT;$Princip;$Gagne)
C_ENTIER($BornG;$BornD;$Tmp)
$TT:=$1
$BornG:=Position("<";$TT)
$princip:=Sous chaine($TT;$BornG)
$TT:=Sous chaine($TT;$BornG+1)
$BornD:=Position(">";$Princip)
$TT:=Sous chaine($TT;$BornD)
$Tag:=Sous chaine($princip;1;$BornD)
$Gagne:=wChiffreSimpleTag ($Tag)
Si (Longueur($Gagne)>0)
$Tmp:=Position($Tag;$1)
$1:=Supprimer chaine($1;$Tmp;Longueur($Tag))
$1:=Inserer chaine($1;$Gagne;$Tmp)
Jusque ($BornG<=0)
Methode ChiffreSimpleTag
Permet de chiffrer le tag passé en paramètre, selon la méthode et le mot de passe récupérée par les fonctions précédentes. Ne chiffre QUE les input text.
C_BLOB($bClair;$bCrypt)
C_ENTIER LONG($BornG;$BornD;$Tmp;$Err)
C_TEXTE($Last;$Crypt;$Name)
Si (Position("INPUT";$1)>0)
Si (Position("NAME";$1)>0)
Si (Position("Type";$1)>0)
Si (Position("text";$1)>0)
$Tmp:=Position("VALUE";$1)
Si ($Tmp>0)
INSERER LIGNES(TabVar;1)
TabVar{1}:=wRecupVal ("NAME";$1)
$Last:=Sous chaine($1;$Tmp)
$BornG:=Position(Caractere(34);$Last)+1
$Last:=Sous chaine($Last;$BornG)
$BornD:=$BornG+Position(Caractere(34);$Last)-1
Si (($BornD-$BornG)>=0)
$Last:=Sous chaine($Last;1;$BornD-$BornG)
TEXTE VERS BLOB($Last;bClair;Texte sans longueur)
$Err:=SH_DefineKey (PassWord;"";1;Longueur(PassWord)*8;0)
bCrypt:=SH_Crypt_Blob (bClair;1)
$Crypt:=BLOB vers texte(bCrypt;Texte sans longueur)
` $Crypt:=Txt2Hexa ($Crypt)
$Tmp:=Position($Last;$1)
$1:=Supprimer chaine($1;$Tmp;Longueur($Last))
$1:=Inserer chaine($1;Txt2Hexa ($Crypt);$Tmp)
Methode Générale
Methode appelée au lancement : créé des process d'attentes sur les sockets TCP/IP.
C_ENTIER LONG($pIn;$pOut;$pMaster)
`Lance 16 process pour 16 requetes simultanées sur le port d'entrée.
Boucle($i; 1; 16)
$pIn:=Nouveau process("SH_Filtre_In";32000;"Filtre In";1)
`process de traitement (chiffrement)
$pMaster:=Nouveau process("SH_Filtre_Master";32000;"Filtre Traitement";1)
`process de renvois des flux chiffrés
$pOut:=Nouveau process("SH_Filtre_Out";32000;"Filtre Out";1)
Methode SH_Filtre_In
Prends les "appels" en entrée et va les placer dans un tableau. Le socket est placé dans le tableau aussi, et sera utilisé pour le "retour". D'informations.
`Filtre en mode deconnecté.
`prends en parametre le numero
`Le numero de pile de traitement (8 MAxi, defini dans compiler_0)
`$1<- Numero de pile de traitement
C_TEXTE(request;$temp)
C_ENTIER LONG($err;FluxIn;$s)
C_BOOLEEN(Fin)
C_ALPHA(2;<>crlf)
Fin:=Faux
<>crlf:=Caractere(13)+Caractere(10)
FluxIn:=ITK_TCPListen (0;0;<>vPortIn{$1};32000) ` Ouvre un flux sur le port d'entree
Si (FluxIn # 0)
`Boucle d'attente d'éléments en entrée
$s:=ITK_TCPStatus (FluxIn)
Si ($s # 8)
ENDORMIR PROCESS(Numero du process courant;1)
Jusque (($s>=8) | ($s<0))
Si ($s=8) ` flux ouvert
Request:=""
$err:=ITK_TCPRcv (FluxIn;$temp)
request:=request+$temp
Jusque ((ITK_TCPStatus (FluxIn) # 8) | (Longueur(request)>0))
Si (ITK_TCPStatus (FluxIn)=8)
Tant que (Semaphore("PileIn")=Vrai)
InsertPile (-><>PileIn;$1;->request)
InsertPile (-><>vFluxIn;$1;->FluxIn)
EFFACER SEMAPHORE("PileIn")
Jusque (Fin)
Methode SH_Filtre_Out
Reprends les données traitées par le process maître, et renvoie au navigateur.
C_ENTIER LONG($FluxOut)
C_ENTIER LONG($err;$s)
C_TEXTE($request;$temp)
ENDORMIR PROCESS(Numero du process courant;2)
`Si avec tout ca 4D tourne en boucle ...
Si (Taille tableau(<>vFluxOut{$1})>0)
Si (<>vFLuxOut{$1}{Taille tableau(<>vFluxOut{$1})} # 0)
Tant que (Semaphore("PileOut")=Vrai)
$request:=<>PileOut{$1}{Taille tableau(<>PileOut{$1})}
$FluxOut:=<>vFluxOut{$1}{Taille tableau(<>vFluxOut{$1})}
SUPPRIMER LIGNES(<>PileOut{$1};Taille tableau(<>PileOut{$1}))
SUPPRIMER LIGNES(<>vFluxOut{$1};Taille tableau(<>vFluxOut{$1}))
EFFACER SEMAPHORE("PileOut")
$err:=ITK_TCPSend ($FluxOut;$request) `On retourne la réponse
`Ici la connexion doit être refermée par le client. Sinon on la ferme grace
`a la ligne ci dessous.
`$err:=ITK_TCPClose ($FluxOut)
$timeout:=0
$s:=ITK_TCPStatus ($FluxOut)
Si ($s>=12) `le client a fermé son flux
$s:=-1
$timeout:=$timeout+1
Jusque (($s<0) | ($timeout>(4*120))) ` 2mn timeout
` ferme le flux
$err:=ITK_TCPRelease ($FluxOut)
` ferme le flux et envoi OEF à l'app cliente.
[Note 1] ( · )F=Fourniture, U=Utilisation, E=Exportation, I=Importation
[Note 2] ( · )F=Fourniture, U=Utilisation, E=Exportation, I=Importation