FR2805691A1

FR2805691A1 - Procede de controle d'integrite de fichiers informatiques et equipement pour la mise en oeuvre de ce procede

Info

Publication number: FR2805691A1
Application number: FR0002564A
Authority: FR
Inventors: De Nicolas Pomereu
Original assignee: SAFELOGIC
Current assignee: SAFELOGIC
Priority date: 2000-02-29
Filing date: 2000-02-29
Publication date: 2001-08-31
Anticipated expiration: 2020-02-29
Also published as: FR2805691B1

Abstract

Procédé de contrôle d'intégrité de fichiers informatiques d'un poste client comportant une étape d'enregistrement sur le poste client d'une valeur de hachage de référence associée à chaque fichier et des procédures de comparaison de ladite valeur de hachage enregistrée avec une valeur de hachage calculée périodiquement au moment du contrôle du fichier caractérisé en ce que les valeurs de hachage de référence sont enregistrées dans un dictionnaire local signé par un moyen cryptographique, le dictionnaire comprenant une liste de séquences formées par une adresse associée au fichier à contrôler et par la valeur de hachage prédéterminée, et en ce que la procédure de comparaison est réalisée par un équipement distant communiquant avec le poste client par le protocole TCP/ IP.

Description

Procédé de contrôle d'intégrité de fichiers informatiques et équipement pour la mise en #uvre de ce procédé.

La présente invention concerne le domaine du contrôle d'intégrité de fichiers informatiques.

On connaît, dans l'état de la technique, différentes solutions de contrôle d'intégrité de fichiers et de supervision des tentatives d'intrusions. Le brevet US5961644 décrit par exemple un procédé pour tester l'intégrité de fichiers et le déclenchement d'une alarme consistant à simuler des attaques et à vérifier si l'attaque a été détectée.

Le brevet PCT W09940702 concerne un procédé permettant de signer et de vérifier des données. La signature des données consiste à diviser un ensemble de données en paquets, à hacher ces données dans chacun des paquets de manière à produire un bloc de hachage comprenant des valeurs de hachage et à appliquer une signature numérique audit bloc de hachage. Le procédé de vérification consiste à recevoir un paquet comprenant des données, un bloc de hachage et une signature numérique, à vérifier la signature numérique, à hacher les données de manière à produire des valeurs de hachage et à comparer les valeurs de hachage aux valeurs du bloc de hachage.

Le brevet US5944821 propose un autre procédé pour vérifier l'intégrité de données consistant à enregistrer dans une table locale une valeur de hachage et de comparer localement cette valeur.

Le but de la présente invention est de proposer un procédé permettant de vérifier en permanence et automatiquement l'intégrité des données d'un poste client, notamment d'un serveur de production, sans pour autant

perturber le fonctionnement du poste client par une consommation intempestive des ressources locales.

A cet effet, l'invention concerne selon son acception la plus générale un procédé de contrôle d'intégrité de fichiers informatiques d'un poste client comportant une étape d'enregistrement sur le poste client d'une valeur de hachage de référence pour chacun desdits fichiers et des procédures de comparaison de ladite valeur de hachage enregistrée avec une valeur de hachage calculée périodiquement au moment du contrôle du fichier caractérisé en ce que les valeurs de hachage de référence sont enregistrées dans un dictionnaire local signé par un moyen cryptographique, le dictionnaire comprenant une liste de séquences formées par l'adresse du fichier à contrôler associé à la valeur de hachage prédéterminée, et en ce que la procédure de comparaison est réalisée par un équipement distant communiquant avec le poste client par le protocole TCP/IP, la procédure comportant une étape d'ouverture d'un socket TCP/IP, une étape de lecture et de contrôle de la signature dudit dictionnaire, une étape de comparaison de la signature de référence de chaque fichier du dictionnaire avec une signature du fichier correspond à l'adresse associée, calculée dynamiquement, et une étape de notification d'un message d'acquittement ou d'alarme en fonction du résultat respectivement positif ou négatif de l'étape de comparaison, ledit message étant signé.

Avantageusement, le procédé comporte une étape de signature sur le poste client du dictionnaire local un moyen cryptographique, et en ce que la procédure de contrôle comporte une étape de lecture et de contrôle de la signature dudit dictionnaire.

Selon un mode de mise en #uvre préféré, la procédure de contrôle est périodiquement interrompue.

De préférence, le procédé selon l'invention comporte une étape d'ouverture d'un premier socket TCP/IP pour les données relatives à la lecture du dictionnaire, et d'un deuxième socket TCP/IP pour les données relatives au balayage des fichiers dudit dictionnaire et au calcul des signatures.

Selon un mode de mise en #uvre particulier, il comporte une étape de génération d'une bi-clé cryptographique KRU1, KPU1 pour la signature du dictionnaire et la signature de chaque fichier du dictionnaire.

Avantageusement, il comporte en outre une étape de génération d' une bi-clé cryptographique RUC, KPUC pour la signature des message d'acquittement ou d'alarme.

Selon une variante particulière, il comporte une étape de propagation de la bi-clé cryptographique KRU1, KPU1 entre une pluralité de postes clients.

Avantageusement, les bi-clés cryptographiques KRU1, KPU1 et KRUC, Kpuc sont identiques.

Selon un mode de réalisation préféré, l'étape d'enregistrement sur le poste client d'une valeur de hachage de référence associée à chaque fichier consiste à calculer pour ledit fichier un peigne par une extraction de données dudit fichier et à calculer la valeur de hachage dudit peigne, l'étape de comparaison consistant à comparer la signature de référence associée à chaque peigne avec une signature du peigne correspond à l'adresse associée au fichier à contrôler, calculée dynamiquement.

L'invention concerne également un équipement pour le contrôle d'intégrité de fichiers informatiques d'un poste client selon le procédé objet de la revendication 1 caractérisé en ce qu'il est constitué par une station de contrôle comportant des moyens de communication avec au moins un poste client par un réseau informatique, une mémoire l'enregistrement des données transitoires résultant

de l'étape de comparaison des signatures et des moyens pour la signature automatique des messages d'acquittement ou d'alerte.

L'invention sera mieux comprise à la lecture de la description d'un mode de réalisation non limitatif qui suit, se référant à un exemple de mise en #uvre de l'invention. Elle est illustrée par la figure unique représentant l'architecture d'une infrastructure pour la mise en #uvre du procédé.

La description qui suit concerne l'utilisation et l'administration d'un équipement pour la mise en #uvre de l'invention en mode client-serveur.

Le procédé est destiné à contrôler en permanence les signatures de fichiers d'un serveur de réseau, Intranet ou Internet. L'objectif est de solliciter les ressources du serveur contrôlé le moins possible, par le déport des opérations consommatrices en calcul/CPU d'un serveur contrôlé vers une machine dédiée, c'est-à-dire l'équipement de contrôle.

Le poste client (1) est constitué par un microordinateur avec une mémoire, par exemple un disque dur, sur lequel sont enregistrés les fichiers (2,3) à contrôler et une base de données (4) comprenant les signatures de référence et les adresses des fichiers (2,3) à contrôler.

Le poste client (1) comprend par ailleurs un module de communication TCP/IP (5) permettant d'ouvrir des sessions sécurisées avec un poste contrôleur (6) par l'intermédiaire d'un réseau (7) intranet ou internet.

Ce poste contrôleur (6) comporte un calculateur pour les traitements du procédé de contrôle d'intégrité selon l'invention, ainsi que des fichiers (9,10) pour mémoriser les résultats des contrôles.

Le procédé selon l'invention permet de réduire fortement le recours du calculateur du poste client lors du

process de contrôle. Ainsi, les ressources systèmes du serveur contrôlé sont très peu pénalisées.

Du point de vue des ressources systèmes, le procédé utilise le calculateur du poste client comme indiqué dans le tableau ci-dessous :

<tb>
<tb> Type <SEP> de <SEP> Type <SEP> Partie <SEP> de <SEP> l'opération
<tb> consommati <SEP> d'opéra
<tb> on <SEP> tion
<tb> I/O <SEP> N 1 <SEP> Lecture <SEP> du <SEP> Dictionnaire <SEP> Signé.
<tb>

I/O <SEP> N 2 <SEP> Lecture <SEP> de <SEP> chaque <SEP> fichier <SEP> à
<tb> contrôler.
<tb>

I/O <SEP> N 3 <SEP> Ecriture <SEP> du <SEP> fichier <SEP> Log
<tb> CPU <SEP> N 1 <SEP> Calcul <SEP> final <SEP> de <SEP> la <SEP> signature
<tb> cryptographique <SEP> du
<tb> Dictionnaire <SEP> Signé.
<tb>

CPU <SEP> N 2 <SEP> Calcul <SEP> final <SEP> de <SEP> la <SEP> valeur <SEP> hash
<tb> du <SEP> fichier <SEP> à <SEP> contrôler
<tb> CPU <SEP> N 3 <SEP> Calcul <SEP> final <SEP> de <SEP> la <SEP> signature
<tb> du <SEP> fichier <SEP> de <SEP> log.
<tb>

Le procédé selon l'invention utilise des techniques de cryptographie pour contrôler l'intégrité des fichiers : # Chaque Administrateur dispose d'une paire de clés privée/publique RSA ou DSA. Nous verrons plus bas les différentes utilisations de la paire de clés.

# L'intégrité d'un fichier est contrôlée en calculant sa valeur de hachage ou hash avec l'algorithme SHA-1 et en comparant cette valeur avec une valeur stockée dans un fichier appelé le Dictionnaire Signé .

# Le Dictionnaire Signé contient :

# La liste des adresses des fichiers à contrôler à partir d'un Dictionnaire Texte.

# Accolé à chaque nom de fichier : la valeur hash SHA-1.

# Lorsque l'Administrateur génère un
Dictionnaire Signé, le système lui demande la clé privée associée (protégée par une passphrase). Ce principe permet de signer le Dictionnaire Signé avec la clé privée de l'Administrateur.

# L'Administrateur lance le contrôle d'un
Dictionnaire Signé. Le process de contrôle effectue les étapes : # Contrôle de la signature du dictionnaire en utilisant la clé publique de l'Administrateur.

# Contrôle de l'intégrité de chaque fichier du dictionnaire avec calcul dynamique de son SHA-1 et comparaison avec la valeur stockée.

# Si le contrôle est OK : Génération d'un ACK (acquittement) signé, avec la clé privée de l'Administrateur.

# Si une anomalie quelconque est détectée : le process émet un NACK (message d'Alarme) sous forme de fichier Texte ou HTML et d'émission d'e mail(s).

# L'Administrateur a la possibilité à tout moment : # D'arrêter le processus de contrôle d'un
Dictionnaire Signé.

# D'arrêter tous les process de contrôle, c'est à dire de stopper Lastwall.

Cas d'émission d'une Alarme
Le procédé émet une Alarme (fichier Texte/HTML et e mail(s)) signée pour les tentatives d'attaque suivantes :

# Modification du contenu ou suppression du
Dictionnaire Signé.

# Modification du contenu ou suppression d'un des fichiers à contrôler. gen~keys : Génération d'une paire de clés
La génération d'une paire de clés privée/publique servira : # A signer les dictionnaires textes (Administrateur) .

# A contrôler la validité de signature d'un dictionnaire (process Lastwall).

La génération d'au moins une paire de clés est obligatoire. On a les caractéristiques : # Chaque paire de clés est associée à un E mail.

# Les clés sont stockées dans le répertoire clw~keys~dir défini dans le fichier lastwall.ini.

# Les clés privées sont chiffrées avec une passphrase avant le stockage sur disque. Il est indispensable de rappeler cette passphrase pour toute opération qui nécessite l'utilisation de la clé privée.

# Une interface demande la génération d'une valeur seed ou d'initialisation. Cette valeur est utilisée pour initialiser un générateur de nombres pseudo aléatoires.

# Si la passphrase n'est pas passée en paramètre, elle est demandée, avec confirmation, par une interface graphique.

Lors de la première utilisation sur une machine, gen~keys lance un programme destiné à collecter des nombres aléatoires. a) Génération des nombres aléatoires sous Unix.

Le programme demande de frapper lentement sur la touche <entrée> 128 fois : c'est la différence de temps entre les

frappes qui sert à fabriquer la séquence de nombres aléatoires. Veuillez espacer suffisamment longtemps (au moins 1 seconde) vos frappes sur la touche<entrée> afin de fabriquer une séquence de nombres réellement aléatoires. b) Génération des nombres aléatoires sous
Windows NT. Une fenêtre s'affiche avec un indicateur de progression. Il suffit d'appuyer au hasard et lentement des touches pendant quelques secondes sur le clavier pour créer la séquence aléatoire.

Création d'un Dictionnaire Texte add~files permet de rajouter facilement des fichiers à un Dictionnaire Texte . Le dictionnaire texte est la source qui permet de générer un Dictionnaire
Signé .

Un Dictionnaire Texte est donc composé de noms de fichiers, avec les caractéristiques : # Les noms de fichiers sont complets et incluent unité et directories.

# Chaque nom de fichier occupe une ligne.

Voici un exemple de Dictionnaire Texte sous
Windows NT:

<tb>
<tb> c:\aroot\lastwall\exemplel.txt
<tb> c:\aroot\lastwall\exemple2.txt
<tb> c:\aroot\lastwall\exemple3.txt
<tb>

La création du Dictionnaire texte c:\aroot\lastwall\lwdic text.txt est effectué par la commande :

<tb>
<tb> add <SEP> files <SEP> c:\aroot\lastwall\lwdic <SEP> source.txt <SEP>
<tb> c:\aroot\lastwall\lwdic <SEP> text.txt <SEP>
<tb>

Après e x é c u t i o n , c:\aroot\lastwall\lwdic~text.txt contient :

<tb>
<tb> c:\aroot\lastwall\exemplel.txt
<tb> c:\aroot\lastwall\exemple2.txt
<tb> c:\aroot\lastwall\exemple3.txt
<tb>
gen~signed~dic permet de générer un
Dictionnaire Signé à partir : # D'un Dictionnaire Texte précédemment créé.

# D'une clé privée Lastwall, identifiée par le couple : # E mail identifiant la clé privée.

# Passphrase de protection par chiffrement de la clé privée.

Un Dictionnaire Signé contient la liste des fichiers du Dictionnaire Texte, avec les caractéristiques suivantes : # A chaque fichier est accolée sa valeur SHA-
1 sous forme hexadécimale.

# Le Dictionnaire est signé avec la clé privée correspondant à un e mail email@domain.net Cela signifie que le Dictionnaire Signé contient une zone qui permet à un process qui connaît la clé publique de :
1) Vérifier que le Dictionnaire a bien été signé par email@domain.net .

2) Vérifier que le contenu du Dictionnaire n'a pas été altéré par un tiers (intégrité).

Usage :

<tb>
<tb> gen~signed~dic <SEP> <option <SEP> switches> <SEP> <text <SEP> dictionnary> <SEP> <signed
<tb> dictionnary> <SEP> <error <SEP> file> <SEP> <signing <SEP> e <SEP> mail> <SEP> [passphrase]
<tb>
Avec : - option switches : <+d[r]#-d> <+d[r]#-d> : expand directories [r]=recurse do not expand directories

- text dictionnary : full name of input text dictionnary - signed dictionnary : fullname of signed dictionnary to create - error file : file containing reporting errors - signing e mail e mail corresponding to a LW private key - passphrase : e mail private key passphrase Exemple : Voici un exemple de Dictionnaire Signé correspondant au Dictionnaire Texte décrit dans le script précédent (gen~signed~dic) :

<tb>
<tb> 
<tb> // <SEP> Lastwall <SEP> (R) <SEP> Copyright <SEP> (C) <SEP> SafeLogic <SEP> 2000
<tb> // <SEP> c:\aroot\lastwall\lwdic~sign.txt <SEP> Signed <SEP> Dictionnary
<tb> Creation <SEP> at <SEP> 17/2/2000 <SEP> 19:33:20
<tb> //
<tb> //BEGIN <SEP> LW <SEP> FIELDS
<tb> key~id=info@safelogic.com
<tb> key~algo=MD5/RSA/PKCS#l
<tb> crypto~algo=Blowfish/CBC/PKCS5Padding
<tb> crypto~iv=8215A2C54127E18A
<tb> //END <SEP> LW <SEP> FIELDS
<tb> //
<tb> LW <SEP> FILE: <SEP>
<tb> c <SEP> :\aroot\lastwall\exemplel.txt=ABD77AAC92E4113F1205FD1AC56E
<tb> DD85F4509BB9 <SEP> LW <SEP> LENGTH: <SEP> 19
<tb> LW <SEP> FILE: <SEP>
<tb> c:\aroot\lastwall\exemple2.txt=ABD77AAC92E4133F1205FD1AC56E
<tb> DD85F4509BB9 <SEP> LW <SEP> LENGTH: <SEP> 19
<tb> LW <SEP> FILE: <SEP>
<tb> c:\aroot\lastwall\exemple3.txt=8CC1FA4C1FA603725982DD3D8BCB
<tb> F26409681EA7 <SEP> LW <SEP> LENGTH: <SEP> 19
<tb> <!--//BEGIN <SEP> LW <SEP> SIGNATURE
<tb>

<tb>
<tb> 19DFB548BAEA0579A5B4E23309135BCC524C9765AAB30EAB7CBF2226B29
<tb> 4E25E4E13A2310CECB94C403B9262C568D3B814ECC95ADFA9821DFDDB3B
<tb> 7628F8BEC9AFA1BEE8FCE1B4422F505C663BD1FDEBA6D638424282569DD
<tb> 7A82E7B1A247EDBF2DA640AF87502593EOD22A8F923B9559C5575069E5F
<tb> F1C55C9D663D534AC4DC
<tb> //END <SEP> LW <SEP> SIGNATURE-->
<tb>
Note : il s'agit d'un Dictionnaire Signé non chiffré (configuration par défaut).

Le script disp~crypt permet d'afficher les Dictionnaires
Signés qui sont cryptés au moment de la génération.

1. 1 disp~crypt : affichage d'un Dictionnaire Signé crypté
Si le Dictionnaire Signé a été crypté à la génération, disp~crypt, permet de l'afficher en mode décrypté. Il faut lancer le process en passant comme paramètres : *Le nom du Dictionnaire Signé.

*Le nom de l'e mail de signature/chiffrement.

'La passphrase associée à 1 e mail de signature/chiffrement.

Usage :

<tb>
<tb> disp~crypt <SEP> <signed <SEP> dictionnary> <SEP> <signing <SEP> e <SEP> mail>
<tb> [passphrase]
<tb>
Avec : - signed dic. signed dictionnary to display - signing e mail e mail corresponding to a LW private key - passphrase e mail private key passphrase Note : disp~crypt n'est à utiliser que si le paramètre clw~crypt~sign~dic de votre fichier d'initialisation est valorisé à true.

1. 2 check~dic : lancement d'un process de contrôle

check~dic permet de lancer un process de contrôle en une fois ou continu d'un dictionnaire, en précisant : *Une série de switchs pour indiquer : -Contrôle en boucle ou en un seul passage.

*Alerte immédiate à la première erreur ou alerte à la fin du parcours du Dictionnaire Signé.

*Affichage ou non du contrôle sur la console.

*Trace de l'activité où non dans un fichier de trace.

*L'adresse IP du serveur contenant le Dictionnaire Signé
Version Mono-Server ou utiliser la valeur localhost qui indique le host local.

Version Full . utiliser l'adresse IP de la machine du Socket Server.

*Le nom du Dictionnaire Signé.

*L'adresse IP d'un serveur de Logging qui contient le
Fichier de Logging Dynamique.

Version Mono-Server : utiliser la valeur localhost qui indique le host local.

Version Full . utiliser l'adresse IP de la machine du Socket Server.

*Un fichier de Logging Dynamique Texte ou HTML qui est rafraîchi en permanence.

*Un intervalle en secondes, c'est à dire un mode sleep du process entre deux contrôles du Dictionnaire.

'Le nom complet, avec le chemin d'accès, du fichier d'initialisation à utiliser. Cette option permet d'utiliser des clones du fichier d'initialisation par défaut, avec des valeurs différentes pour chaque dictionnaire à contrôler.

La valeur default permet d'utiliser le nom de fichier ini par défaut. (lastwall.ini).

#L'e mail correspondant à la clé privée de signature.

*La passphrase correspondant à la clé privée de signature du process/dictionnaire.
Usage :

<tb>
<tb> check~dic <SEP> <option <SEP> switches> <SEP> <host> <SEP> <signed <SEP> dictionnary>
<tb> <logging <SEP> host>
<tb> <logging <SEP> file> <SEP> <interval> <SEP> <ini <SEP> file> <SEP> <signing <SEP> e <SEP> mail>
<tb> [passphrase]
<tb>
Avec : - option switches <-11+1> <-cl+c> <-sl+s> <-fl+f> +11-1 : continuous checks in loop mode one pass check +cl-c : continue stop when file integrity error detected +sl-s : trace check on screen do not trace check on screen +fl-f : trace activity in file do not trace activity in file - host localhost or IP address of Signed Dic. location - signed dictionnary : Dictionnary containing the files to check - logging host : localhost or IP adress of logging file location - logging file : full name of logging file - interval : interval in seconds between two Dictionnary Check - ini file : special ini file to use or "default" for normal usage - signing e mail e mail corresponding to a LW private key - passphrase : e mail private key passphrase Notes :

1) Paramètres restreints
En version Mono-Server , les paramètres suivants sont restreints : - host : Seule la valeur localhost est autorisée.

- logging host : Seule la valeur localhost est autorisée.

2) Signature des e mails
Les e mails d'Alerte sont signés. Il est dont possible de vérifier leur authenticité avec le script :

<tb>
<tb> check~sign <SEP> <signed~file <SEP> >
<tb>
Avec .

- signed file : file or e mail content signed by Lastwall
Pour vérifier l'authenticité d'un e mail, il suffit de copier son contenu (corps) dans un fichier et d'appliquer check~sign au fichier créé. check~sign affiche true si la signature de l'e mail est correcte.

3) Cas de déclenchement d'une Alarme
Une Alerte se déclenche (terminal et e mail) dans les cas suivants : *Modification ou suppression d'un Dictionnaire Signé.

*Modification ou suppression d'un des fichiers référencés à contrôler dans un Dictionnaire Signé.

1.3 check~stop . arrêt d'un process de contrôle
L'arrêt d'un process de contrôle doit passer par check~stop afin de signer et authentifier la demande d'arrêt.

*Une Alarme console sera déclenchée.

*Un e mail d'Alarme sera envoyé aux destinataires spécifiés dans check~dic. check~stop permet de préciser : *L'adresse IP du serveur qui contient le Dictionnaire Signé dont il faut arrêter le process (mode client/serveur).

Version Mono-Server : utiliser la valeur localhost qui indique le host local.

Version Full : utiliser l'adresse IP de la machine du Socket Server.

*L'arrêt des contrôles pourr tous les Dictionnaires Signés, ou pour un Dictionnaire précis.

Usage :

<tb>
<tb> check <SEP> stop <SEP> <option <SEP> switches> <SEP> <llr> <SEP> <host> <SEP> <signed
<tb> dictionnarylall> <SEP> <signing <SEP> e <SEP> mail> <SEP> [passphrase]
<tb>
Avec : - option switches <-sl+s> <-fl+f> +sl-s : trace stop on screen do not trace stop on screen +fl-f : trace activity in file do not trace activity in file - llr : (l)ocal stop or (r) emote Socket Server stop - host : localhost or IP address of Signed Die. location - signed dic. #all : check to stop : signeddictionnary all dictionnaries - signing e mail e mail corresponding to a LW private key - passphrase : e mail private key passphrase 1) Paramètres restreints En version Mono-Server , les paramètres suivants sont restreints : l#r : Seule la valeur 1 est autorisée. host : Seule la valeur localhost est autorisée.

Le procédé selon une variante de réalisation se décompose en deux procédures distinctes dans leur rôle un process de contrôle :

#Sous-process client . chargé d'effectuer les opérations de calcul consommatrices en CPU sur une machine dédiée.

#Sous-process serveur . il tourne en tâche de fond sur le serveur dont on veut surveiller les fichiers et communique avec le sous-process client pour les opérations de I/O sur les fichiers.

Nous appellerons Monitor un sous-process client et
Socket Server un sous-process serveur .

Le tableau suivant décrit les rôles des deux composants de
Lastwall Client-Serveur dans le cas d'un process de contrôle :

<tb>
<tb> Composant <SEP> Rôle <SEP> / <SEP> Activité
<tb> Monitor <SEP> * <SEP> Etablit <SEP> un <SEP> lien <SEP> persistant <SEP> et <SEP> synchrone <SEP> en
<tb> mode <SEP> Sockets <SEP> TCP/IP <SEP> avec <SEP> Socket <SEP> Server.
<tb>

#Lit <SEP> les <SEP> contenus <SEP> des <SEP> fichiers <SEP> sur <SEP> une <SEP> Socket
<tb> TCP/IP.
<tb>

-Contrôle <SEP> de <SEP> signature <SEP> du <SEP> Dictionnaire <SEP> Signé.
<tb>

*Calcul <SEP> de <SEP> la <SEP> valeur <SEP> <SEP> hash <SEP> <SEP> (ou <SEP> de <SEP> hachage)
<tb> de <SEP> chaque <SEP> fichier <SEP> à <SEP> contrôler.
<tb>

* <SEP> Ecriture <SEP> et <SEP> signature <SEP> du <SEP> fichier <SEP> de <SEP> Log.
<tb>

Socket <SEP> *Etablit <SEP> un <SEP> lien <SEP> persistant <SEP> et <SEP> synchrone <SEP> en
<tb> Server <SEP> mode <SEP> Sockets <SEP> TCP/IP <SEP> avec <SEP> Monitor
<tb> * <SEP> Ecrit <SEP> les <SEP> contenus <SEP> des <SEP> fichiers <SEP> à <SEP> surveiller
<tb> sur <SEP> une <SEP> Socket <SEP> TCP/IP.
<tb>
Le tableau suivant décrit les caractéristiques systèmes de chaque composant :

<tb>
<tb> Composant <SEP> Rôle <SEP> système <SEP> & <SEP> consommation
<tb> Monitor <SEP> # <SEP> Calculateur <SEP> <SEP> cryptographique.
<tb>

*Forte <SEP> consommation <SEP> de <SEP> CPU.
<tb>

Socket <SEP> *Diffusion <SEP> de <SEP> fichiers <SEP> (broadcast).
<tb>

<tb>
<tb> Server <SEP> *Fonctionnement <SEP> en <SEP> mode <SEP> multi-thread.
<tb>

-Consommation <SEP> de <SEP> CPU <SEP> très <SEP> réduite.
<tb>

Selon un exemple de mise en #uvre, une machine de contrôle avec Monitor est reliée par une Socket TCP/IP à un serveur à contrôler : 1. 3.1 Instances multiples de Monitor
Dans l'exemple ci-dessous, une machine dédiée sous Linux surveille à la fois : *Un serveur sous Windows NT.

*Un serveur sous Linux.

Deux instances indépendantes de Monitor s'exécutent sous la machine de contrôle. Il n'y a pas de limite théorique au nombre de serveurs que peut surveiller une machine de contrôle qui exécute des process Monitor.

1. 3.2 Multi-threading de Socket Server
Dans ce cas, plusieurs Socket Server s'exécutent de façon multi-threadée sous le serveur à surveiller : *Il n'y a qu'un seul processus Socket Server de lancé.

-Chaque client Monitor lance un sous-thread fils du processus père Socket Server.

*Cette configuration fonctionne avec un ou plusieurs processeurs clients de surveillance.

Le mode multi-threading permet de discriminer des process de surveillances sur un serveur, en particulier de jouer sur les fréquences de contrôle.

#1) un premier process lastwall qui surveillera très régulièrement et avec une pause rapide de quelques secondes les fichiers systèmes vitaux de/etc ou c:\wint\system32 pour éviter les attaques très graves sur root avec un rootkit.

#2) Un deuxième process, avec une fréquence d'activité moins élevée, sera consacré à la surveillance des programmes Web (CGI, ASP, Servlet, etc. ) les plus importants.

#3) Un troisième process avec un temps de pose beaucoup plus élevé (plusieurs minutes ou même heures) surveillera les fichiers applicatifs moins sensibles de type pages HTML de second niveau ou images non vitales, etc.

1. 4 Mode opératoire en Client-Serveur
Nous distinguerons quatre étapes successives dans le mode opératoire : #1) Préparation des process de contrôle.

#2) Lancement du Socket Server @ #3) Lancement et arrêt des process de contrôle.

#4) Arrêt du Socket Server.

1. 4.1 Préparation des process de contrôle 1. 4.1.1 Scripts
La préparation de process est constituée des scripts et étapes suivantes décrits dans le document [lw~doc~admin~gene]:

<tb>
<tb> Script <SEP> Etape/ <SEP> description <SEP> du <SEP> script
<tb> gen~userid <SEP> Génération <SEP> d'un <SEP> couple <SEP> userid <SEP> password
<tb> gen~keys <SEP> Génération <SEP> d'une <SEP> paire <SEP> de <SEP> clés
<tb> add <SEP> files <SEP> Création <SEP> d'un <SEP> Dictionnaire <SEP> Texte
<tb> gen~signed~ <SEP> Génération <SEP> d'un <SEP> Dictionnaire <SEP> Signé
<tb> dic
<tb> disp~crypt <SEP> affichage <SEP> d'un <SEP> Dictionnaire <SEP> Signé
<tb> crypté
<tb>
Il est indispensable de transférer sur la (ou les) machine(s) de monitoring les jeux de clés privées/publiques de Lastwall générées sur le Serveur à contrôler.

Il existe un et un seul jeu de clés Lastwall à utiliser : 1) Le jeu de clés privées/publiques de références est celui qui correspond au serveur à surveiller (machine avec Socket Server).

2) Il faut transférer ce jeu de clés sur toutes les machines de monitoring (machines avec Monitor).

3) S'il existe plusieurs serveurs à surveiller : il faut créer un jeu de clés unique sur un des serveurs et le transférer sur les autres.

Il existe deux clés associées à un e mail et à une passphrase : *Une clé publique *Une clé privée chiffrée (avec une clé privée dérivée de la valeur de la passphrase).

Le transfert du jeu de clés entre ordinateurs ne pose pas de problème de confidentialité car la clé privée est chiffrée avec un algorithme symétrique fort et une clé longue de 128 bits.

Les nomenclatures des deux fichiers-clé publique et clé privée sont :

<tb>
<tb> <clw <SEP> keys <SEP> dir>RSA <SEP> <e <SEP> mail <SEP> de <SEP> la <SEP> clé>.pkf <SEP>
<tb> <clw~keys~dir>RSA~<e~mail~de~la~clé>.skf
<tb>
Avec : <clw~keys~dir> : directory de localisation des clés correspondant au champ clw~keys~dir de clw~base~unix.ini ou clw~base~wnt.ini.

<e~mail~de~la~clé> :
Paramètre <identity e mail> du script de génération de clé gen~keys.

Rappel des valeurs par défaut de clw~keys~dir : *Unix /home/lastwall/keys/ # Windows NT : c :\aroot\lastwall\keys\ Exemple :
Si l'e mail email@domain.net sert d'e mail d'identité du jeu de clés, on aura par défaut les deux fichiers clés :

<tb>
<tb> OS <SEP> Fichiers <SEP> clés <SEP> pour <SEP> email@domain.net
<tb>

<tb>
<tb> Unix <SEP> /home/lastwall/keys/RSA~email@domain.net.pkf
<tb> /home/lastwall/keys/RSA~email@domain.net.skf
<tb> Wind <SEP> c:\aroot\lastwall\keys\RSA~email@domain.net.pkf
<tb> ows <SEP> c:\aroot\lastwall\keys\RSA~email@domain.net.skf
<tb> NT
<tb>
1. 4.2 start~server : lancement du Socket Server Usage :

<tb>
<tb> start~server <SEP> [+v]
<tb>
Avec : - +v : verbose mode Notes : Le mode +v (verbose on) permet d'afficher en détail l'activité de start~server. En version 1. 01, +v est surtout un mode de debug.

Après le lancement, le Socket Server affiche les lignes suivantes et se met en attente des connexions des clients Monitor :

<tb>
<tb> Lastwall <SEP> (R) <SEP> Vl.OOA <SEP> 23/11/1999 <SEP> (jdk <SEP> 1. <SEP> 1.8) <SEP> Copyright <SEP> (C)
<tb> SafeLogic, <SEP> 1999
<tb> http://www.safelogic.com
<tb> Lastwall <SEP> Socket <SEP> Server <SEP> - <SEP> ** <SEP> multi <SEP> thread <SEP> version <SEP> **
<tb>
Rappel : Il ne faut lancer qu'une seule fois start~server, même si plusieurs machines se connectent en mode Monitor.

1. 4.3 Lancement et arrêt des process de contrôle
La troisième et quatrième étape se déroulent entièrement sur la ou les machine(s) de contrôle qui exécutent les process clients Lastwall Monitor.

Il s'agit des deux scripts :

<tb>
<tb> Script <SEP> Etape/ <SEP> description <SEP> du <SEP> script
<tb> check~dic <SEP> Lancement <SEP> d'un <SEP> process <SEP> de <SEP> contrôle
<tb> check~stop <SEP> Arrêt <SEP> d'un <SEP> processus <SEP> de <SEP> contrôle <SEP> en
<tb> client-serveur.
<tb>

Les modes opératoires sont identiques à ceux de Lastwall
Mono-Server et décrits dans [lw~doc~admin~gene]. Se référer à cette documentation pour la syntaxe et le fonctionnement de gen~userid et check~stop.

1. 4.3.1 check~dic : lancement d'un process Monitor de contrôle
Usage :
Cf. [lw~doc~admin~gene].

Equivalent Web :
Cf. [lw~doc~admin~gene].

Notes :
Seul change le deuxième paramètre en mode client-serveur :

<tb>
<tb> host <SEP> : <SEP> : <SEP> localhost <SEP> or <SEP> IP <SEP> address <SEP> of <SEP> Signed <SEP> Dic.
<tb> location
<tb>
Il prend la valeur de l'adresse IP de la machine où est lancé le Socket Server.

Exemple : 192. 168.0.1 Le logging s'effectue sur la machine de contrôle, i. e la machine de lancement de Monitor et du script check~userid. En version 1.01A, le paramètre numéro 4 logging host prend toujours la valeur localhost :

<tb>
<tb> - <SEP> logging <SEP> host <SEP> : <SEP> localhost <SEP> or <SEP> IP <SEP> adress <SEP> of <SEP> logging
<tb> file <SEP> location
<tb>
~.4.3.2 check~stop . arrêt d'un process Monitor de contrôle
Usage :
Cf. [lw~doc~admin~gene].

Equivalent Web :
Cf. [lw~doc~admin~gene].

Notes :
Seul change le troisième paramètre en mode client-serveur

<tb>
<tb> - <SEP> host <SEP> localhost <SEP> or <SEP> IP <SEP> address <SEP> of <SEP> Signe
<tb> Dic. <SEP> location)
<tb>

Il prend la valeur de l'adresse IP de la machine dont on veut stopper proprement le Socket Server.

Exemple : 192. 168.0.1 1. 4.4 check~stop . arrêt du Socket Server
L'arrêt du Socket Server sur une machine se fait en utilisant le process check~dic de façon particulière.

Usage :

<tb>
<tb> check <SEP> stop <SEP> <option <SEP> switches> <SEP> "r" <SEP> <host> <SEP> "all" <SEP> <signing <SEP> e
<tb> mail> <SEP> [passphrase]
<tb>
Avec : - option switches : <-sl+s> <-fl+f> +sl-s : trace stop on screen do not trace stop on screen +fl-f : trace activity in file do not trace activity in file - r : (r) emote Socket Server stop - host : IP address of Signed Die. location - ail : check to stop ail dictionnaries

- signing e mail e mail corresponding to a LW private key - passphrase : e mail private key passphrase Exemple : L'arrêt du Socket Server de la machine 192. 168.0.1 se fait avec la commande :

<tb>
<tb> check-stop <SEP> +s+f <SEP> r <SEP> 192.168.0.1 <SEP> all <SEP> email@domain.net
<tb>
Notes :

<tb>
<tb> Tous <SEP> les <SEP> process <SEP> Monitor <SEP> de <SEP> toutes <SEP> les <SEP> machines <SEP> connectées
<tb> seront <SEP> automatiquement <SEP> arrêtés <SEP> si <SEP> un <SEP> Socket <SEP> Server <SEP> est
<tb> arrêté.
<tb>

2 INTERFACE HTML D'ADMINISTRATION 2. 1 Objectifs
L'interface HTML a pour but d'offrir un mode opératoire graphique pour chaque script décrit dans [lw~doc~admin~gene] et cette documentation.

Par exemple, le script gen~userid de génération du dictionnaire signé sera remplacé par une page HTML avec des champs à remplir et un CGI associé.

Les traitements de base appelés sont les mêmes que pour les scripts ; seule change l'interface.

L'interface HTML est utilisable pour l'administration et l'exécution de Lastwall en mode mono-serveur et en mode client-serveur.

L'interface HTML offre deux avantages importants par rapport au mode scripting : #1) Possibilité de déporter via un réseau TCP/IP non sécurisé l'administration sur tout hardware qui supporte l'utilisation d'un navigateur en HTML 3.2.

#2) Mise en #uvre d'une interface graphique.

2. 2 Configuration de lastwall.ini
Le fichier lastwall. ini comporte des paramètres spécifiques à l'interface HTML.

Se référer à [lw~doc~admin~gene] pour la localisation de lastwall. ini sur votre disque dur. Voici la liste des paramètres de lastwall. ini à mettre à jour pour utiliser l'interface HTML :

<tb>
<tb> Paramètre <SEP> Rôle <SEP> Valeur <SEP> par
<tb> défaut
<tb>

<tb>
<tb> clw <SEP> screen <SEP> Largeur <SEP> de <SEP> l'interface <SEP> 800
<tb> HTML <SEP> de
<tb> l'Administrateur <SEP> : <SEP> 800
<tb> ou <SEP> 600 <SEP> pixels.
<tb>

Directories <SEP> et <SEP> fichiers <SEP> virtuels <SEP> (HTTP)
<tb> clw~cgi- <SEP> Adresse <SEP> Web <SEP> des <SEP> CGI <SEP> en <SEP> /cgi-bin/
<tb> bin <SEP> dir <SEP> Java
<tb> clw <SEP> servlet <SEP> d <SEP> Adresse <SEP> Web <SEP> des <SEP> Servlet <SEP> /servlet/
<tb> ir <SEP> Java
<tb> clw~alarm~way <SEP> Adresse <SEP> Web <SEP> du <SEP> Signal <SEP> /lastwall/
<tb> sonore <SEP> d'Alarme <SEP> ringout.wa
<tb> v
<tb> clw~img~alias <SEP> Adresse <SEP> Web <SEP> du <SEP> dossier/lastwall/
<tb> ~dir <SEP> images <SEP> des <SEP> pictos <SEP> images
<tb> Paramètres <SEP> SMTP/POP3
<tb> clw <SEP> email <SEP> E <SEP> mail <SEP> du <SEP> WebMaster <SEP> A <SEP> modifier
<tb> Gestion <SEP> des <SEP> Process
<tb> Lastwall
<tb> clw~elapsed~m <SEP> Durée <SEP> maximum <SEP> autorisée <SEP> 600
<tb> ax <SEP> en <SEP> secondes <SEP> d'inactivité
<tb> du <SEP> process <SEP> Lastwall.
<tb>
2. 3 Configuration des droits de l'utilisateur Serveur Web le Serveur Web doit avoir les droits suivants sur les directories correspondants aux paramètres suivants (notation des droits en mode Unix ) :

<tb>
<tb> Paramètre <SEP> Valeur <SEP> par <SEP> Valeur <SEP> par <SEP> Dro
<tb> de <SEP> défaut <SEP> défaut <SEP> its
<tb> directory <SEP> Unix <SEP> Windows <SEP> NT
<tb> physique
<tb> clw~swap~di <SEP> /home/lastwa <SEP> c <SEP> :\aroot\lastwa
<tb> r <SEP> 11/swap/ <SEP> ll\swap\ <SEP> -
<tb>

<tb>
<tb> clw~keys~di <SEP> /home/lastwa <SEP> c <SEP> :\aroot\lastwa
<tb> r <SEP> 11/keys/ <SEP> ll\keys\ <SEP> clw <SEP> random <SEP> /home/lastwa <SEP> c <SEP> :\aroot\lastwa
<tb> +rwbin <SEP> dir <SEP> 11/swap/ <SEP> ll\swap\ <SEP> clw <SEP> trace <SEP> d <SEP> /home/lastwa <SEP> c <SEP> :\aroot\lastwa
<tb> ir <SEP> 11/swap/ <SEP> ll\swap\ <SEP> -
<tb>
Note Unix : Il est préférable d'attribuer par un chown ces directories à l'utilisateur serveur Web.

Le Server Web doit aussi avoir un droit en lecture et écriture sur le fichier lastwall. ini, si vous souhaitez le modifier en mode HTML.

Fichie <SEP> Localisation <SEP> Localisation <SEP> par <SEP> Dro
<tb> r <SEP> par <SEP> défaut <SEP> Unix <SEP> défaut <SEP> its
<tb> Windows <SEP> NT
<tb> lastwa/com/safelogic/ <SEP> c <SEP> :\com\safelogic\ <SEP> +rw
<tb> ll.ini <SEP> servlet/ <SEP> servlet\-
<tb>
2. 4 Mapping entre Serveur HTTP et directories physiques
Si on prend comme références : *Pour le stockage des objets HTML le répertoire /home/lastwall/html/ ou c :\aroot\lastwall\html\ par défaut à l'installation (Cf. votre Documentation d'Installation Lastwall) *Les valeurs par défaut des champs clw~img~alias~dir et clw alarm wav.

On doit alors avoir le mapping suivants sur le Serveur HTTP sous Unix ou Windows NT :

<tb>
<tb> Directories <SEP> Unix <SEP> Alias <SEP> http <SEP> Commentaire
<tb> /home/lastwall/html/ <SEP> /lastwall/ <SEP> Répertoire <SEP> de
<tb> stockage <SEP> du
<tb>

<tb>
<tb> fichier <SEP> son <SEP> du
<tb> paramètre <SEP> : <SEP>
<tb> clw <SEP> alarm <SEP> wav <SEP>
<tb> /home/lastwall/html/i/lastwall/ <SEP> Répertoire <SEP> de
<tb> mages/ <SEP> images/ <SEP> stockage <SEP> des
<tb> images <SEP> du
<tb> paramètre <SEP> : <SEP>
<tb> clw~img~alias~dir
<tb> Directories <SEP> Windows <SEP> Alias <SEP> http <SEP> Commentaire
<tb> NT
<tb> c <SEP> :\aroot\lastwall\htm <SEP> /lastwall/ <SEP> Répertoire <SEP> de
<tb> 1\ <SEP> stockage <SEP> du
<tb> fichier <SEP> son <SEP> du
<tb> paramètre <SEP> : <SEP>
<tb> clw <SEP> alarm <SEP> wav <SEP>
<tb> c <SEP> :\aroot\lastwall\htm <SEP> /lastwall/ <SEP> Répertoire <SEP> de
<tb> l\images\ <SEP> images/ <SEP> stockage <SEP> des
<tb> images <SEP> du
<tb> paramètre <SEP> : <SEP>
<tb> clw~img~alias <SEP> dir <SEP>
<tb>
Utilisation de l'interface HTML Les URLs d'appel de l'interface HTML sont :

<tb>
<tb> OS <SEP> URL <SEP> d'appel <SEP> de <SEP> l'interface <SEP> HTML
<tb> Unix <SEP> http://localhost/lastwall/cgiu~lwmain2.htm
<tb> Wind <SEP> http://localhost/lastwall/cgiw~lwmain2.htm
<tb> ows
<tb> NT
<tb>

L'interface HTML est auto-documentée. Voici une capture d'écran du menu général :
A chaque script décrit dans [lw~doc~admin~gene] correspond une ligne d'un sous-menu d'accès HTML.

On <SEP> a <SEP> la <SEP> table <SEP> de <SEP> correspondance <SEP> : <SEP>
<tb> Script <SEP> Sous <SEP> - <SEP> Menu <SEP> & <SEP> Ligne <SEP> d'accès
<tb> gen <SEP> userid <SEP> Pas <SEP> de <SEP> correspondance <SEP> pour <SEP> des <SEP> raisons
<tb> de <SEP> sécurité.
<tb> gen~keys <SEP> Clés
<tb> Création
<tb> add <SEP> files <SEP> Dictionnaire
<tb> Texte
<tb> Création <SEP> auto.
<tb> gen~signed~di <SEP> Dictionnaire
<tb> c <SEP> Signé
<tb> Génération
<tb> disp <SEP> crypt <SEP> Dictionnaire
<tb> Signé
<tb> Affichage
<tb> check <SEP> dic <SEP> Contrôles
<tb> Lancement
<tb> check <SEP> stop <SEP> Contrôles
<tb> Arrêt
<tb>

Une variante de mise en #uvre préférée de l'invention consiste à échanger entre le client et le serveur non pas l'intégralité des fichiers à vérifier, mais un extrait seulement de ces fichiers.

L'objectif visé par la réalisation de cette variante mettant en #uvre le calcul d'un peigne est de réduire le flot de données transférées entre le client ( Monitor ) et le serveur Lastwall ( Socket Server ).

Pour cela on n'utilisera qu'une partie des données de chacun des fichiers à signer et à contrôler.

Cette sélection sera faite par le client avant envoi vers le serveur.

Ce module doit prendre en compte les aspects suivants :

# Assurer une faible consommation des ressources du client.

# Etre rapide.

# Préserver la sécurité (séquence de données non prévisible).

# Permettre de sauvegarder et de transporter aisément le peigne.

Comme on laisse des zones de blanc dans le fichier (parties non sélectionnées), un attaquant pourrait modifier ces parties sans être détecté. Il est donc primordial que les parties non sélectionnées ne soient pas prévisibles.

Définition d'un peigne
On souhaite transporter moins de données concernant le fichier à signer mais on ne peut pas faire de compression sinon on chargerait la machine serveur (celle qui exécute le Socket Server) en calcul, ce que l'on veut justement éviter par déportation en fonctionnant en client / serveur.

On va donc se contenter d'accéder au fichier et de lire seulement quelques parties de son contenu. On doit cependant à chaque lecture extraire le même contenu si l'on veut que la signature soit juste.

On va utiliser un peigne pour lire ce fichier, c'est-à-dire certaines valeurs de début de séquence de lecture et une taille de bloc lu fixe. On extraira ainsi toujours les mêmes données du fichier.

Ce qui va constituer un peigne a été évoqué précédemment : # Une séquence de positions de départ pour les lectures ; # Une taille de bloc fixe de lecture à partir de ces positions ; # Le taux de données extraites (pourcentage).

Les différents calculs à effectuer pour déterminer un peigne concernent tout d'abord, la taille du buffer contenant les données extraites :
Taille~totale~extraits =Taille~globale~fichier x Taux~requis / 100 ;
Pour déterminer la séquence de lecture, on va ensuite avoir besoin des valeurs suivantes :
Nombre~lectures~requis = Taille~totale~extraits / Taille bloc ; Nombre~lectures~possible = Taille~globale~fichier / Taille~bloc ;
On devra donc effectuer Nombre~lectures~requis tirages dans un ensemble à Nombre~lectures~p ossible éléments.

Ces tirages devront être effectuées aléatoirement et les valeurs ne seront pas triées afin de garantir une meilleur sécurité (données moins prévisibles).

CLASSES JAVA DU MODULE PEIGNE
Le peigne : CSaComb
Pour pouvoir aisément utiliser et manipuler le peigne, nous avons créé une classe peigne : CSaComb. Elle sert au stockage des informations d'un peigne.

On va donc y retrouver des fonctions set (regroupées en fait sous forme d'un constructeur) et des fonctions get pour les attributs, ainsi que des méthodes permettant de manipuler un peigne sous forme de String (constructeur appelant setFromValue() et méthode toString() surchargée).

Le générateur de peigne : CSaCombGenerator
Il s'agit de l'équivalent d'une Factory qui permet de créer un nouveau peigne pour un fichier.

Le constructeur permet d'initialiser le générateur de nombres aléatoires pour le fichier spécifié.

Notons que le générateur n'est valide que pour le fichier pour lequel il est créé.

Le générateur permet de créer un nouveau peigne grâce à la méthode getComb(), celle-ci appelant generateSequence() pour créer la séquence de positions aléatoires.

Le lecteur : CSaCombReader
Ce lecteur permet de lire un fichier à l'aide d'un peigne. C'est à ce niveau que va donc se passer l'extraction.

Cette classe et ses méthodes de lectures ne doivent être utilisées qu'avec un peigne généré pour le fichier en question par le générateur.

Il existe deux modes de lecture :
Lecture de tous les extraits et renvoie d'un buffer contenant le tout ;
Lecture extrait par extrait (streaming).

L'intérêt est de pouvoir adapter la lecture à l'utilisation que l'on va en faire. En effet, dans le cas d'une émission de ces données (vocation première de ce module), on va pouvoir lire et envoyer en continu plutôt que de tout lire puis d'envoyer. Ceci accélérera le processus et évitera une bufferisation.

Outre le constructeur, on dispose donc d'une méthode de lecture globale, readAll(), et d'un jeu de méthodes pour la lecture en continu : prepareStream() pour préparer le flot ; isAvailable() pour s'assurer qu'il y a encore au moins une lecture à faire ; streamingReadNext() pour lire le prochain extrait.

Enfin la méthode close() doit être appelée dans tous les cas pour fermer le Reader.

Cette classe s'appuie sur la classe RandomAccessFile pour effectuer ses lectures mais n'en hérite pas.

Emulateur de test : CSaCombTest
Cette classe permet de tester le module. Il suffit de l'appeler et la syntaxe correcte s'affiche, ce qui vous permettra de l'utiliser.

L'algorithme utilisé pour cette conversion est un algorithme de type Horner qui va effectuer des décalages successifs dans les registres que constituent les octets, calculer la puissance de deux correspondante et la sommer au résultat qui sera retourné.

Claims

REVENDICATIONS

1 - Procédé de contrôle d'intégrité de fichiers informatiques d'un poste client comportant une étape d'enregistrement sur le poste client d'une valeur de hachage de référence associée à chaque fichier et des procédures de comparaison de ladite valeur de hachage enregistrée avec une valeur de hachage calculée périodiquement au moment du contrôle du fichier caractérisé en ce que les valeurs de hachage de référence sont enregistrées dans un dictionnaire local signé par un moyen cryptographique, le dictionnaire comprenant une liste de séquences formées par une adresse associée au fichier à contrôler et par la valeur de hachage prédéterminée, et en ce que la procédure de comparaison est réalisée par un équipement distant communiquant avec le poste client par le protocole TCP/IP, la procédure comportant une étape d'ouverture d'un socket TCP/IP, une étape de lecture et de contrôle de la signature dudit dictionnaire, une étape de comparaison de la signature de référence associée à chaque fichier du dictionnaire avec une signature du fichier correspond à l'adresse associée, calculée dynamiquement, et une étape de notification d'un message d'acquittement ou d'alarme en fonction du résultat respectivement positif ou négatif de l'étape de comparaison, ledit message étant signé.

2 - Procédé de contrôle d'intégrité de fichiers informatiques d'un poste client selon la revendication 1 caractérisé en ce qu'il comporte une étape de signature sur le poste client du dictionnaire local un moyen cryptographique, et en ce que la procédure de contrôle comporte une étape de lecture et de contrôle de la signature dudit dictionnaire,

3 - Procédé de contrôle d'intégrité de fichiers informatiques d'un poste client selon la revendication 1 ou 2 caractérisé en ce que la procédure de contrôle est périodiquement interrompue.

4 - Procédé de contrôle d'intégrité de fichiers informatiques d'un poste client selon l'une quelconque des revendications précédentes caractérisé en ce qu'il comporte une étape d'ouverture d'un premier socket TCP/IP pour les données relatives à la lecture du dictionnaire, et d'un deuxième socket TCP/IP pour les données relatives au balayage des fichiers dudit dictionnaire et au calcul des signatures.

5 - Procédé de contrôle d'intégrité de fichiers informatiques d'un poste client selon l'une quelconque des revendications précédentes caractérisé en ce qu'il comporte une étape de génération d' une bi-clé cryptographique KPU1, KPU1 pour la signature du dictionnaire et la signature de chaque fichier du dictionnaire.

6 - Procédé de contrôle d'intégrité de fichiers informatiques d'un poste client selon l'une quelconque des revendications précédentes caractérisé en ce qu'il comporte une étape de génération d'une bi-clé cryptographique KRUC, Kpuc pour la signature des message d'acquittement ou d'alarme.

7 - Procédé de contrôle d'intégrité de fichiers informatiques d'un poste client selon l'une quelconque des revendications précédentes caractérisé en ce qu'il comporte une étape de propagation de la bi-clé cryptographique KPU1, KPU1 entre une pluralité de postes clients.

8 - Procédé de contrôle d'intégrité de fichiers informatiques d'un poste client selon l'une quelconque des revendications précédentes caractérisé en ce que les biclés cryptographiques KPU1, KPU1 et KRUC, Kpuc sont identiques.

9 - Procédé de contrôle d'intégrité de fichiers informatiques d'un poste client selon l'une quelconque des revendications précédentes caractérisé en ce que l'étape d'enregistrement sur le poste client d'une valeur de hachage de référence associée à chaque fichier consiste à calculer pour ledit fichier un peigne par une extraction de données dudit fichier et à calculer la valeur de hachage dudit peigne, l'étape de comparaison consistant à comparer la signature de référence associée à chaque peigne avec une signature du peigne correspond à l'adresse associée au fichier à contrôler, calculée dynamiquement.

10 - Equipement pour le contrôle d'intégrité de fichiers informatiques d'un poste client selon le procédé objet de la revendication 1 caractérisé en ce qu'il est constitué par une station de contrôle comportant des moyens de communication avec au moins un poste client par un réseau informatique, une mémoire l'enregistrement des données transitoires résultant de l'étape de comparaison des signatures et des moyens pour la signature automatique des messages d'acquittement ou d'alerte.