• Chapitre I. Problématique.
• Chapitre II. Rappel et définitions.
• 1 Les différentes techniques de chiffrement.
• 1.1 Général.
• 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é.
• (i) Principe.
• (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
• Webographie
• ANNEXES
• 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.

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.

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.

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.

Dans le décret

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.

SCSSI

18 rue du Docteur Zamenhof

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.

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.

Le modèle de référence OSI

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.

Simplification.

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.

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

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_Crypt( Donnée_en_Clair ; Type)

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.

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">

Tags HTML

</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.

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

EnterCodeResource();

PrepareCallback(); /* <--Callbacks MUST be located in this file */

#endif

switch(procNum)

{

case kInitPackage: //Initialisation du plugIn

SETCALL4D(paramList);

Init_Decalage();

*returnedValue = kDontPurgePackage;

break;

case kDeinitPackage: //On quitte 4D.

// DeInit_Decalage;

break;

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]);

break;

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]);

break;

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]);

break;

…

}

#if GENERATING68K

ExitCodeResource(); //Spécifique processeurs motorola

#endif

}

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 # */

void SH_Crypt_Blob(XHANDLE *returnedValue, XHANDLE *Data, long *Type)

{

long LongData;

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);

break;

case 2: // RC5

vRet=Crypt_RC5(pData, LongData);

break;

default :

vRet=Crypt_Decalage(pData, LongData);

}

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)

{

long i;

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)

for (i=0;i<Longueur;i++)

Retour[i]=Ptr[i]+vClef[i%lClef]; //Algorithme lui même.

else

for (i=0;i<Longueur;i++)

Retour[i]=Ptr[i];

return(Retour);

}

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 :

<SCRIPT LANGUAGE="JavaScript1.2">

function Txt2Num(Para)

{

return(eval('0x'+Para));

}

function Num2Txt(Param)

{

var Tmp, res;

res='';

Tmp=Param/16;

Tmp=Math.floor(Tmp);

if (Tmp>=10)

res=unescape("%"+(41+Tmp-10));

else

res=unescape("%"+(30+Tmp));

Tmp=Param%16;

Tmp=Math.floor(Tmp);

if (Tmp>=10)

res=res+unescape("%"+(41+Tmp-10));

else

res=res+unescape("%"+(30+Tmp));

return(res);

}

function Hexa2Txt(Parai)

{

var i;

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 i;

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;

if (lClef>0)

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);

}

else

for (i=0;i<Longueur;i++)

vretour=vretour+Ptr.value;

Ptr.value=vretour;

}

</SCRIPT>

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:

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 :

Tant que (vrai)

Ecouter sur le port d'entrée

Vérifier l'état de la connexion

Lire les données sur port d'entree

Fin de si

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 :

Exemples de trames :

avec :

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.

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.

4D 20, 34

algorithmes 21

algorithmes restreint 6

Apache 19

applets 23

attaque 6

Attaque active 12

Attaque passive 11

authentifier 25

base de données 20

Base de données 22

BLOB 22

C/C++ 20

Cassage complet 6

chiffrement 5

chiffrement asymétrique 13

clé asymétrique 7

Clé publique 10

clé secrète 7

Clé secrète 7

Complexité 7

connexion 36

container 27, 28

contrôle de clé 34

cookie 31

cookies 23

CryptoAPI 11

cryptographie symétrique 7

décret 13

DES 13

DLL 11

domaine public 15

Enigma 13

Filtre Cryptographique 34

firewalls 18

gestions des clés. 27

Handle 28

hits 33

HTML 23

HTTP 20, 36

implémentation 34

Internet Explorer 19

Internet Tool Kit 21

IP 18

IPSEC 18

Javascript 20

JavaScript 20, 21, 30, 31

Journal Officiel 13

légaux 15

législation 13

Main 28

masque jetable 30

MD5 18

Message Digest 18

Microsoft 19

mot de passe 23

multiprocess 34

Netscape 19

niveau de protection 18

Obtention globale 6

Obtention locale 6

OSI 16

password 31

PEM 17

PGP 12, 17

plateforme 32

Plug-In 21, 27

proxy 21, 25, 35

publication 32

RC4 18

Réseaux Virtuels Privés 18

royalties 15

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

VPN 18

Windows NT4.0 11

World Wide Web 4

Cryptographie Appliquée

Bruce Schneier, Trad. Laurent Viennot.

Ed. International Thomson Publishing France. 1996.

John Vacca.

Ed Sybex. 1996.

W.R. Stevens.

Ed Addison Wesley

C. Nicolas, C. Avare, F. Najman.

Ed. Eyrolles. 1998.

Alexandre Maret.

Ed. Marabout.

T. Cormon, C. Leiserson, R. Rivest.

Ed. Dunod. 1994.

R. E. Smith

Ed. Addison Wesley. 1997.

P. Chaléat, D. Charnay

Ed. Eyrolles.

K. S. Siyan, Trad. : P. Naniche, Y. Schwartz

Ed. Simon & Schuster Macmillan.1998.

http://www.legifrance.gouv.fr/

Contient les publications du Journal Officiel, les texte de loi, ...

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.

Pages contenant, des liens et les références sur IPsec, pour la création de VPN.

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.

http://www.cryptography.com/

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.

Tableau 1

NOR : PRMX9802729A

Le Premier ministre,

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,

Arrête :

Art. 1er. - Le dossier de déclaration ou de demande d'autorisation concernant un moyen ou une prestation de cryptologie comporte une partie administrative et une partie technique.

La partie administrative comprend une déclaration ou une demande d'autorisation conforme au modèle annexé au présent arrêté, en trois exemplaires.

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.

Fait à Paris, le 13 mars 1998.

Lionel Jospin

A N N E X E PREMIER MINISTRE

Service central de la sécurité des systèmes d'information

18, rue du Docteur-Zamenhof,

92131 Issy-les-Moulineaux Cedex

(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(*)

Rayer les mentions inutiles.

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 :

- nom ;

- numéro de la version ;

- 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 :

- le mode de distribution ;

- l'intégration au procédé de chiffrement ;

- l'architecture des clés employées ;

- le procédé de génération des clés ;

- 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) */

/* #pragma once */

/* #include "ansi_prefix.win32.h" */

/* #include <Windows.h> */

/* Use pre-compiled header instead */

#elif WIN32 /* <-- defined by Visual C++ */

#include <Windows.h>

#endif

#if WINVER

#undef COLOR_WINDOWFRAME

#undef COLOR_BTNSHADOW

#undef COLOR_BTNFACE

#undef COLOR_BTNHIGHLIGHT

#undef COLOR_BTNTEXT

#undef InsertMenuItem

#undef InsertMenu

#undef AppendMenu

#include <ASIPORT.H> /*To use Altura headers (in the folder PPC_H, placed in the project folder)*/

#endif

#if GENERATING68K

#define USINGCBADDRESS 1

#include <SetupA4.h> /* <-- Needed for globals in 68k */

#include <A4Stuff.h>

#endif

#include "Ext4D.h" /* <-- Extensions Kit Entete */

/* #### HEADERS END #### */

#include "Malloc.h"

#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);

enum {

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 */

#else

Call4DProcPtr CALL4DVALUE; /* Call4D can be used in any file */

#endif

/* DLL instance of the plug-in (Windows only) */

#if WINVER

#if __MWERKS__ && (__MWERKS__ <= 0x1100)

static HANDLE ghInst;

#else

HANDLE ghInst;

#endif

#endif

/* #### MANDATORY GLOBALS (END) #### */

/* #### MAIN #### */

/* Do not modify MAIN */

UNMANGLE MAIN(long procNum, PackagePtr paramList,void **data, ResultValue *returnedValue)

{

#if GENERATING68K

EnterCodeResource();

PrepareCallback(); /* <--Callbacks MUST be located in this file */

#endif

switch(procNum)

{

case kInitPackage:

SETCALL4D(paramList);

Init_Decalage();

*returnedValue = kDontPurgePackage;

break;

case kDeinitPackage:

// DeInit_Decalage;

break;

case PACK_SH_Crypt_Blob:

SH_Crypt_Blob((XHANDLE *)returnedValue,(XHANDLE *)paramList[0],(long *)paramList[1]);

break;

case PACK_SH_DefineKey:

SH_DefineKey((short *)returnedValue,(TextBlock *)paramList[0],(TextBlock *)paramList[1],(long *)paramList[2],(long *)paramList[3],(long *)paramList[4]);

break;

case PACK_SH_GenerateKey:

SH_GenerateKey((short *)returnedValue,(TextBlock *)paramList[0],(TextBlock *)paramList[1],(long *)paramList[2],(long *)paramList[3],(long *)paramList[4]);

break;

case PACK_SH_GiveKey:

SH_GiveKey((short *)returnedValue,(TextBlock *)paramList[0],(TextBlock *)paramList[1],(long *)paramList[2],(long *)paramList[3],(long *)paramList[4]);

break;

case PACK_SH_Sign_Blob:

SH_Sign_Blob((TextBlock *)*returnedValue,(XHANDLE *)paramList[0],(long *)paramList[1],(long *)paramList[2]);

break;

case PACK_SH_UnCrypt_Blob:

SH_UnCrypt_Blob((XHANDLE *)returnedValue,(XHANDLE *)paramList[0],(long *)paramList[1]);

break;

}

#if GENERATING68K

ExitCodeResource();

#endif

}

/* #### MAIN END #### */

/* # SH_Crypt # */

/* Procedure de cryptage d'un blob.

Return 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)

{

long LongData;

char * pData, *vRet;

if (*Data) // s'il y a quelque chose a crypte

{

LongData=GetHandleSize(*Data);

HLock(*Data);

pData=(char *)**Data;

switch(*Type) // type de cryptographie

{

case 1 : // Simple decalage

vRet=Crypt_Decalage(pData, LongData);

break;

case 2: // RC5

vRet=Crypt_RC5(pData, LongData);

break;

case 3: //DES

vRet=Crypt_DES(pData, LongData);

break;

case 4: //RSA

vRet=Crypt_RSA(pData, LongData);

default :

vRet=Crypt_Decalage(pData, LongData);

}

HUnlock(*Data);

//if (*returnedValue)

//DisposeHandle(*returnedValue); //Est-ce a faire ?

*returnedValue=NewHandle(_msize(vRet));

HLock(*returnedValue);

memcpy(**returnedValue, vRet, _msize(vRet));

free(vRet);

HUnlock(*returnedValue);

}

}

/* Le pendant de crypt :-) */

void SH_UnCrypt_Blob(XHANDLE *returnedValue, XHANDLE *Data, long *Type)

{

long LongData;

char *pData, *vRet;

if (*Data) // s'il ya quelque chose a decrypte

{

LongData=GetHandleSize(*Data);

HLock(*Data);

pData=(char *)**Data;

switch(*Type) // type de cryptographie

{

case 1 : // simple decalage

vRet=uCrypt_Decalage(pData, LongData);

break;

case 2 : // RC5

vRet=uCrypt_RC5(pData, LongData);

break;

case 3: //DES

vRet=uCrypt_DES(pData, LongData);

break;

case 4: //RSA

vRet=uCrypt_RSA(pData, LongData);

default :

vRet=uCrypt_Decalage(pData, LongData);

}

HUnlock(*Data);

*returnedValue=NewHandle(_msize(vRet));

HLock(*returnedValue);

memcpy(**returnedValue, vRet, _msize(vRet));

free(vRet);

HUnlock(*returnedValue);

}

}

/* Permet de definir la cle utilisee par un algorithme

Key

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);

switch(*Type)

{

case 1: //ici seule la clé un sera utilisé (Clé 2 sert a rien)

ModKey_Decalage( (*KeyOne->fData), Long1,(*KeyTwo->fData), Long2 );

break;

default:

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);

switch(*Type)

{

case 1 :

GiveKey_Decalage(&Key1,&Key2,Lg1, Lg2);

break;

default :

GiveKey_Decalage(&Key1, &Key2, Lg1, Lg2);

}

LL1=Bits2Bytes(*Lg1);

LL2=Bits2Bytes(*Lg2);

KeyOne->fSize=(short)LL1;

if (KeyOne->fData)

ReallocateHandle(KeyOne->fData,LL1);

else

KeyOne->fData=NewHandle(LL1);

KeyTwo->fSize=(short)LL2;

if (KeyTwo->fData)

ReallocateHandle(KeyTwo->fData,LL2);

else

KeyTwo->fData=NewHandle(LL2);

HLock(KeyOne->fData);

HLock(KeyTwo->fData);

memcpy(*(KeyOne->fData), Key1,LL1);

memcpy(*(KeyTwo->fData), Key2,LL2);

HUnlock(KeyOne->fData);

HUnlock(KeyTwo->fData);

free(Key1);

free(Key2);

*returnedValue=0;

}

/* 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;

if (KeyOne->fData)

ReallocateHandle(KeyOne->fData, LG1);

else

KeyOne->fData=NewHandle( LG1);

KeyTwo->fSize=LG2;

if (KeyTwo->fData)

ReallocateHandle(KeyTwo->fData, LG2);

else

KeyTwo->fData=NewHandle(LG2);

switch(*Type)

{

case 1:

KeyGen_Simple(*(KeyOne->fData), LG1);

KeyGen_Simple(*(KeyTwo->fData),LG2);

default :

KeyGen_Simple(*(KeyOne->fData), LG1);

KeyGen_Simple(*(KeyTwo->fData), LG2);

}

HUnlock(KeyOne->fData);

HUnlock(KeyTwo->fData);

*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);

}

else

{

returnedValue->fSize=Bits2Bytes(*Longueur);

returnedValue->fData=NewHandle(Bits2Bytes(*Longueur));

}

HLock(*Data);

switch(*Type)

{

case 1 :

Signe_Simple(*(returnedValue->fData), **Data, *Longueur);

break;

default :

;

}

HUnlock(*Data);

}

/* #### DLL INSTANCE (WINDOWS ONLY) #### */

#if WINVER

UNMANGLE

BOOL WINAPI DllMain (HINSTANCE hInst,DWORD wDataSeg, LPVOID lpvReserved)

{

ghInst = hInst;

return 1;

}

#endif

/* #### DLL INSTANCE END #### */

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)

C_ENTIER LONG($Pos)

$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)

Fin de boucle

$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)

Fin de si

Fin de si

TEXTE VERS BLOB($Flux;$0;Texte sans longueur)

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($1)

C_TEXTE($Tag1;$TagC)

$Tag1:=$1

  `On recherche tous les fragments de codes à chiffrer

Repeter

$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)

Sinon

$TagC:=$Tag1

Fin de si

$Tmp:=Position($TagC;$1)

$1:=Supprimer chaine($1;$Tmp;Longueur($TagC))

$1:=Inserer chaine($1;wChiffre ($TagC);$Tmp)

Fin de si

Si ($BornD>0)

$Tag1:=Sous chaine($Tag1;$BornD)

Sinon

$Tag1:=""

Fin de si

Jusque ($Tag1="")

$0:=$1

Methode chargee de recuperer le mot de passe et le type de cryptographie à utiliser.

C_TEXTE($1;$0)

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"

Fin de si

Au cas ou

: (Position("Simple";$Tmp)>0)

VVType:="Simple"

$0:=wChiffreSimple ($1)

Fin de cas

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

Repeter

$BornG:=Position("<";$TT)

Si ($BornG>0)

$princip:=Sous chaine($TT;$BornG)

$TT:=Sous chaine($TT;$BornG+1)

$BornD:=Position(">";$Princip)

Si ($BornD>0)

$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)

Fin de si

Fin de si

Fin de si

Jusque ($BornG<=0)

$0:=$1

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_TEXTE($1;$0)

C_BLOB($bClair;$bCrypt)

C_ENTIER LONG($BornG;$BornD;$Tmp;$Err)

C_TEXTE($Last;$Crypt;$Name)

$0:=""

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)

$0:=$1

Fin de si

Fin de si

Fin de si

Fin de si

Fin de si

Fin de si

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)

fin de boucle

`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.

Si (Faux)

  `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

Fin de si

C_TEXTE(request;$temp)

C_ENTIER LONG($err;FluxIn;$s)

C_BOOLEEN(Fin)

C_ALPHA(2;<>crlf)

Fin:=Faux

<>crlf:=Caractere(13)+Caractere(10)

Repeter

APPELER 4D

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

Repeter

$s:=ITK_TCPStatus (FluxIn)

Si ($s # 8)

ENDORMIR PROCESS(Numero du process courant;1)

APPELER 4D

Fin de si

Jusque (($s>=8) | ($s<0))

Si ($s=8)  ` flux ouvert

Request:=""

Repeter

$err:=ITK_TCPRcv (FluxIn;$temp)

request:=request+$temp

APPELER 4D

$s:=ITK_TCPStatus (FluxIn)

Jusque ((ITK_TCPStatus (FluxIn) # 8) | (Longueur(request)>0))

Si (ITK_TCPStatus (FluxIn)=8)

Tant que (Semaphore("PileIn")=Vrai)

ENDORMIR PROCESS(Numero du process courant;1)

Fin tant que

InsertPile (-><>PileIn;$1;->request)

InsertPile (-><>vFluxIn;$1;->FluxIn)

EFFACER SEMAPHORE("PileIn")

Fin de si

APPELER 4D

Fin de si

Fin de si

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)

C_BOOLEEN(Fin)

Fin:=Faux

Repeter

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)

ENDORMIR PROCESS(Numero du process courant;1)

Fin tant que

$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

Repeter

$s:=ITK_TCPStatus ($FluxOut)

Si ($s>=12)  `le client a fermé son flux

$s:=-1

Sinon

ENDORMIR PROCESS(Numero du process courant;1)

$timeout:=$timeout+1

Fin de si

Jusque (($s<0) | ($timeout>(4*120)))  ` 2mn timeout

  ` ferme le flux

$err:=ITK_TCPRelease ($FluxOut)

  ` ferme le flux et envoi OEF à l'app cliente.

Fin de si

Fin de si

Jusque (Fin)

Notes

[Note 1] ( · )F=Fourniture, U=Utilisation, E=Exportation, I=Importation

[Note 2] ( · )F=Fourniture, U=Utilisation, E=Exportation, I=Importation