FR3030163A1 - Procede de generation d’un fichier journal - Google Patents

Procede de generation d’un fichier journal Download PDF

Info

Publication number
FR3030163A1
FR3030163A1 FR1462353A FR1462353A FR3030163A1 FR 3030163 A1 FR3030163 A1 FR 3030163A1 FR 1462353 A FR1462353 A FR 1462353A FR 1462353 A FR1462353 A FR 1462353A FR 3030163 A1 FR3030163 A1 FR 3030163A1
Authority
FR
France
Prior art keywords
cryptographic
symmetric
verification data
key
record
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR1462353A
Other languages
English (en)
Other versions
FR3030163B1 (fr
Inventor
Xavier Declerck
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Oberthur Card Systems SA Philippines
Original Assignee
Oberthur Card Systems SA Philippines
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Oberthur Card Systems SA Philippines filed Critical Oberthur Card Systems SA Philippines
Priority to FR1462353A priority Critical patent/FR3030163B1/fr
Publication of FR3030163A1 publication Critical patent/FR3030163A1/fr
Application granted granted Critical
Publication of FR3030163B1 publication Critical patent/FR3030163B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3242Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/64Protecting data integrity, e.g. using checksums, certificates or signatures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

Abstract

L'invention concerne un procédé de génération d'un fichier journal comprenant au moins un enregistrement (Ii) correspondant à un évènement horodaté dans un système informatique (S), caractérisé en ce qu'il comprend les étapes suivantes : - application (E10) à l'enregistrement (Ii) d'un algorithme cryptographique à clé symétrique utilisant une clé cryptographique symétrique de façon à produire des données de vérification (MACi) ; - mémorisation (E16) des données de vérification (MACi) ; - vérification ultérieure (T3) de l'intégrité de l'enregistrement par lecture de l'enregistrement et au moyen de la clé cryptographique symétrique et des données de vérification (MACk) ; - en cas de vérification positive, génération (E28) d'une signature (SIG) relative au moins audit enregistrement, par application d'un algorithme de cryptographie asymétrique utilisant une clé cryptographique privée ; - mémorisation (E32) de la signature (SIG) en association avec l'enregistrement.

Description

1 DOMAINE TECHNIQUE AUQUEL SE RAPPORTE L'INVENTION La présente invention concerne la journalisation des évènements dans un système informatique. Elle concerne plus particulièrement un procédé de génération d'un fichier journal. L'invention s'applique particulièrement avantageusement dans le cas où un système cryptographique est en communication avec le système informatique.
ARRIERE-PLAN TECHNOLOGIQUE On connaît, par exemple du document US 2010/218 002, un procédé de génération d'un fichier journal comprenant au moins un enregistrement correspondant à un évènement horodaté dans un système informatique. Dans ce document, les enregistrements sont sécurisés au moyen d'un 15 algorithme de type HMAC (pour "key-Hash-based Message Authentication Code"), c'est-à-dire un algorithme de génération de code d'authentification de message utilisant une fonction de hachage cryptographique. Ce type de sécurisation permet de vérifier l'intégrité et l'authenticité des enregistrements et de détecter d'éventuelles modifications (généralement 20 frauduleuses) de ces enregistrements. L'utilisation d'un code d'authentification de message ne permet pas en revanche d'assurer la non-répudiation et il n'est donc pas possible dans ce cas de faire vérifier les données par un tiers. La cryptographie asymétrique est par ailleurs mal adaptée à la 25 sécurisation de fichier journal du fait de la lenteur des algorithmes de cryptographique asymétrique, incompatible avec la création fréquente de nouveaux enregistrements usuellement rencontrée dans un fichier journal. OBJET DE L'INVENTION Dans ce contexte, la présente invention propose un procédé de 30 génération d'un fichier journal comprenant au moins un enregistrement correspondant à un évènement horodaté dans un système informatique, caractérisé en ce qu'il comprend les étapes suivantes : - application à l'enregistrement d'un algorithme cryptographique à clé symétrique utilisant une clé cryptographique symétrique de façon à produire des 3030163 2 données de vérification ; - mémorisation des données de vérification ; - vérification ultérieure de l'intégrité de l'enregistrement par lecture de l'enregistrement et au moyen de la clé cryptographique symétrique et des 5 données de vérification ; - en cas de vérification positive, génération d'une signature relative au moins audit enregistrement, par application d'un algorithme de cryptographie asymétrique utilisant une clé cryptographique privée ; - mémorisation de la signature (par exemple dans le fichier journal) en 10 association avec l'enregistrement. Selon ce procédé, on applique tout d'abord à l'enregistrement un algorithme cryptographique à clé symétrique dont la rapidité de mise en oeuvre est bien adaptée à la survenance fréquente d'évènements à consigner en tant qu'enregistrements dans un fichier journal.
Ultérieurement (par exemple à intervalles réguliers, ou, en pratique, après une durée prédéterminée comme expliqué dans la description qui suit), la clé symétrique est utilisée pour vérifier l'intégrité de l'enregistrement à l'instant courant. Si le résultat de cette vérification est positif, l'enregistrement est signé au moyen de l'algorithme de cryptographique asymétrique utilisant la clé cryptographique privée, ce qui permet une vérification de l'intégrité de l'enregistrement par un tiers (en utilisant la clé cryptographique publique associée à la clé cryptographique privée). L'algorithme de cryptographie asymétrique n'est ainsi appliqué que de temps à autre, et peut d'ailleurs alors être appliqué à une pluralité d'enregistrements, comme décrit dans la description qui suit. Selon d'autres caractéristiques optionnelles (et donc non limitatives) : - un système cryptographique en communication avec le système informatique met en oeuvre l'étape d'application d'un algorithme cryptographique à clé symétrique et l'étape de génération d'une signature ; - le système cryptographique est un module de sécurité matériel ou une carte à microcircuit ; - la clé cryptographique symétrique et la clé cryptographique privée sont mémorisées dans le système cryptographique ; - les données de vérification sont mémorisées dans le système 3030163 3 cryptographique ; - les données de vérification sont mémorisées dans le système informatique ; - l'étape de vérification comprend une étape de comparaison des 5 données de vérification et de nouvelles données de vérification obtenues par application à l'enregistrement lu de l'algorithme cryptographique à clé symétrique utilisant la clé cryptographique symétrique ; - l'étape de vérification est mise en oeuvre au sein du système informatique ; 10 - l'étape de vérification est mise en oeuvre au sein du système cryptographique ; - les données de vérification sont obtenues au moyen d'un algorithme de génération d'un code d'authentification de message basé sur l'algorithme cryptographique à clé symétrique utilisant la clé cryptographique symétrique ; 15 - les données de vérification sont obtenues par chiffrement de l'enregistrement au moyen de l'algorithme cryptographique à clé symétrique utilisant la clé cryptographique symétrique ; - l'algorithme cryptographique à clé symétrique est appliqué à la création de l'enregistrement ; 20 - une durée prédéterminée est prévue entre deux itérations successives des étapes de vérification ultérieure et de génération de la signature ; - la signature générée est relative à une pluralité d'enregistrements générés entre les deux itérations successives (voire à l'ensemble des enregistrements générés entre les deux itérations successives) ; 25 - la durée prédéterminée est supérieure à 1 heure (voire supérieure à 12 heures). De manière générale, la signature générée peut être relative à une pluralité d'enregistrements générés entre deux itérations successives de l'étape de génération de la signature, ce qui permet de maintenir le niveau de sécurité 30 associé à ce type de signature, sans induire le coût calculatoire élevé qui aurait classiquement été généré par l'application successive de l'algorithme de cryptographie asymétrique à chaque création d'un nouvel enregistrement. DESCRIPTION DETAILLEE D'UN EXEMPLE DE REALISATION La description qui va suivre en regard des dessins annexés, donnés à 3030163 4 titre d'exemples non limitatifs, fera bien comprendre en quoi consiste l'invention et comment elle peut être réalisée. Sur les dessins annexés : - la figure 1 représente un exemple de contexte dans lequel peut être 5 mise en oeuvre l'invention et qui comprend un système informatique et un système cryptographique ; - la figure 2 représente sous forme de modules fonctionnels le système informatique et le système cryptographique de la figure 1 ; - la figure 3 représente les étapes principales d'un exemple de procédé 10 de génération de fichier journal conforme à l'invention ; et - la figure 4 illustre un exemple d'algorithme permettant de produire des données de vérification utilisées par le procédé de la figure 3. La figure 1 représente un exemple de contexte dans lequel peut être mise en oeuvre l'invention.
15 Un système informatique S (en anglais : "computer system") comprend un microprocesseur MP, une mémoire volatile V (par exemple une mémoire vive), une mémoire non-volatile NV (par exemple un disque dur ou une mémoire non-volatile réinscriptible de type EEPROM ou Flash), un élément de décompte du temps T (en anglais : "time source") et un module de communication COM conçu 20 par exemple pour établir une connexion USB avec un dispositif extérieur. L'élément de décompte du temps T est par exemple tel qu'envisagé dans la norme RFC3161 ou dans la norme ISO/IEC 18014. Il peut s'agir en pratique d'une horloge. Les différents composants du système informatique S sont reliés au 25 microprocesseur MP, soit directement comme représenté schématiquement en figure 1, soit au moyen d'un bus. Un système cryptographique C (en anglais : "cryptographic system") comprend un microprocesseur MP', une mémoire volatile V' (par exemple une mémoire vive), une mémoire non-volatile NV' et un module de communication 30 COM'. Le système cryptographique C est par exemple un module matériel de sécurité (ou HSM de l'anglais "Hardware Security Module"); la mémoire non-volatile NV' peut dans ce cas être réalisée sous la forme d'une mémoire non-volatile réinscriptible de type EEPROM (pour "Electrically Erasable and 3030163 5 Programmable Read-Only Memory") ou Flash, ou en variante sous la forme d'un disque dur. Par ailleurs, dans l'exemple décrit ici, le module de communication COM' est conçu pour établir une connexion USB avec un dispositif extérieur, ce qui permet donc dans le cas représenté en figure 1 un échange de données entre 5 le système informatique S et le système cryptographique C (c'est-à-dire en pratique entre le microprocesseur MP du système informatique et le microprocesseur MP' du système cryptographique C). En variante, le système cryptographique C pourrait être une carte à microcircuit ; la mémoire non-volatile NV' peut par exemple être réalisée dans ce 10 cas par une mémoire non-volatile réinscriptible de type EEPROM ou Flash. Le système cryptographique C est de préférence conçu pour être conforme aux Critères Communs, avec un niveau 4 ou supérieur, ou à la norme FIPS 140-2, avec un niveau 3 ou supérieur. Les différents composants du système cryptographique C sont reliés au 15 microprocesseur MP', soit directement comme représenté schématiquement en figure 1, soit au moyen d'un bus. La mémoire non-volatile NV du système informatique S (ainsi qu'éventuellement, à certains instants du fonctionnement, la mémoire volatile V du système informatique S) mémorise des instructions de programme d'ordinateur 20 qui permettent, lorsque ces instructions sont exécutées par le microprocesseur MP du système informatique S, de mettre en oeuvre les procédés et les fonctionnalités du système informatique S décrites ci-dessous. De même, la mémoire non-volatile NV' du système cryptographique C (ainsi qu'éventuellement, à certains instants du fonctionnement, la mémoire 25 volatile V' du système cryptographique C) mémorise des instructions de programme d'ordinateur qui permettent, lorsque ces instructions sont exécutées par le microprocesseur MP' du système cryptographique C, de mettre en oeuvre les procédés et les fonctionnalités du système cryptographique C décrites ci-dessous.
30 La figure 2 représente sous forme de modules fonctionnels le système informatique S et le système cryptographique C de la figure 1. Comme il vient d'être indiqué, le système informatique S et le système cryptographique C sont chacun conçus pour mettre en oeuvre ces modules fonctionnels du fait de l'exécution d'instructions de programme d'ordinateur par le 3030163 6 microprocesseur concerné MP, MP' et de la coopération du microprocesseur concerné MP, MP' avec les composants du système concerné S, C présentés ci-dessus en référence à la figure 1. Le système informatique S met ainsi en oeuvre un module applicatif 5 APPL (qui correspond à l'exécution d'une application par le microprocesseur MP) et un module de journalisation LOG qui gère un fichier journal A (en anglais : "log file" ou "log archive"). Comme expliqué dans la suite, le module applicatif APPL est conçu pour transmettre des données E indicatives de la survenance d'un évènement au 10 module de journalisation LOG, qui consulte alors le module de décompte du temps T afin d'horodater l'évènement. Les données E indicatives de la survenance d'un évènement peuvent être générées du fait de l'exécution de l'application associée au module applicatif APPL ou du fait de la surveillance d'un autre programme par l'application associée au module applicatif APPL.
15 Comme cela ressortira de la description qui suit, le fichier journal A comprend une archive de court terme Al et une archive de long terme A2. Ces archives Ai, A2 comprennent des enregistrements I; qui mémorisent chacun un évènement horodaté produit par le module de journalisation LOG, par exemple sous la forme d'une ligne comprenant un code d'évènement, ainsi que la date et 20 l'heure de l'évènement. Le système cryptographique C met quant à lui en oeuvre un module de chiffrement CRYPT conçu d'une part pour appliquer un algorithme de chiffrement de cryptographie symétrique au moyen d'une clé cryptographique symétrique Kc et d'autre part pour appliquer un algorithme de chiffrement de cryptographie 25 asymétrique au moyen d'une clé cryptographique privée Ko. La clé cryptographique symétrique Kc et la clé cryptographique privée Ko sont mémorisées dans la mémoire non-volatile NV' du système cryptographique C. Par ailleurs, dans certains modes de réalisation, le système 30 cryptographique C mémorise dans la mémoire non-volatile NV', au sein d'un emplacement mémoire M, des données de vérification produites par le système cryptographique C sur la base d'enregistrements l, comme expliqué plus loin. La figure 3 représente les étapes principales d'un exemple de procédé de génération de fichier journal conforme à l'invention.
3030163 7 Ce procédé débute à l'étape E2 par l'envoi par le système informatique S de données d'authentification à destination du système cryptographique C. Ces données d'authentification sont par exemple une code personnel (ou PIN de l'anglais "Personal Identification Number") saisi par l'utilisateur du système 5 informatique S au moyen d'une interface homme-machine (non représentée) de ce système informatique S. En variante, il pourrait s'agir de données biométriques. Les données d'authentification sont reçues par le système cryptographique C à l'étape E4 et sont traitées (par exemple par comparaison avec des données correspondantes mémorisées dans la mémoire non-volatile NV' 10 du système cryptographique C) afin de permettre l'authentification de l'utilisateur auprès du système cryptographique C et ainsi d'autoriser l'utilisation du système cryptographique C par l'utilisateur. En variante les données d'authentification (code personnel ou données biométriques) pourraient être fournies directement par l'utilisateur au système cryptographique.
15 Une fois cette authentification effectuée, le système informatique S (c'est-à-dire en pratique le microprocesseur MP) effectue un premier test Ti afin de déterminer (au moyen du module de décompte de temps T) si une durée (temporelle) prédéterminée (par exemple égale à une durée de 24 heures) s'est écoulée depuis le dernier saut à l'étape E18. Selon une possibilité de réalisation, 20 le premier test Ti pourrait consulter d'autres paramètres (par exemple l'activité du microprocesseur MP, afin de lancer l'étape E18 lorsque l'activité du système informatique S et/ou du système cryptographique C est réduite). Si le résultat du premier test Ti est positif (flèche P), on procède à l'étape E18 décrite plus bas afin de générer une signature relative à l'ensemble 25 des enregistrements l créés au cours des dernières 24 heures. Si le résultat du premier test Ti est négatif (flèche N), on procède à un second test T2 afin de déterminer si un nouvel évènement horodaté a été généré par le module de journalisation LOG. Si le résultat du second test T2 est négatif (flèche N), le procédé retourne 30 au premier test Ti. Autrement dit, le procédé boucle sur les tests Ti, T2 en attendant soit un nouvel évènement horodaté, soit le dépassement de la durée prédéterminée. Naturellement, cette inactivité du système informatique S ne concerne que le procédé de génération de fichier journal décrit ici ; le système informatique S peut mettre en oeuvre en parallèle d'autres processus, dont 3030163 8 certains aboutissent justement à la création d'un évènement E. Si le résultat du second test T2 est positif (flèche P), le procédé se poursuit à l'étape E6 à laquelle le module de journalisation LOG du système informatique S crée un enregistrement l correspondant au nouvel évènement 5 horodaté et envoie cet enregistrement l au système cryptographique C (par émission au moyen du module de communication COM). Le système cryptographique C reçoit ainsi l'enregistrement l à l'étape E8 (au moyen de son module de communication COM'). Le système cryptographique C génère alors (au moyen notamment du 10 module de chiffrement CRYPT) des données de vérification (étape E10) par application à l'enregistrement reçu I; d'un traitement comprenant un algorithme cryptographique de cryptographie symétrique utilisant la clé cryptographique symétrique K. Comme déjà indiqué, la clé cryptographique symétrique Kc est 15 mémorisée dans la mémoire non-volatile NV' du système cryptographique S, sauf (dans l'exemple décrit ici) lors de la première mise en oeuvre de l'étape El 0 pendant la durée prédéterminée (c'est-à-dire depuis le dernier saut à l'étape E18). On prévoit en effet ici, comme indiqué plus bas (étape E34), que le système informatique S commande périodiquement au système cryptographique C 20 l'effacement de la clé cryptographique symétrique Kc mémorisée dans la mémoire non-volatile NV' du système cryptographique C. Lorsque la clé cryptographique symétrique n'est pas disponible dans la mémoire non-volatile NV' (du fait de son effacement préalable comme il vient d'être indiqué et comme expliqué plus bas en référence à l'étape E34), le système 25 cryptographique C procède à la génération de cette clé cryptographique symétrique Kc (par exemple sur la base d'une clé maître et d'une valeur aléatoire) avant de générer les données de vérification et mémorise la clé cryptographique symétrique Kc générée dans la mémoire non-volatile NV' (pour utilisation lors du prochain passage à l'étape El 0).
30 Les données de vérification sont par exemple un code d'authentification de message (ou MAC de l'anglais "Message Authentication Code"), produit par application d'un algorithme de génération de code d'authentification à l'enregistrement reçu l, en utilisant la clé cryptographique symétrique K. On peut utiliser notamment un algorithme de type HMAC (c'est-à-dire un algorithme de 3030163 9 génération de code d'authentification utilisant une fonction de hachage cryptographique, ici avec la clé cryptographique symétrique Kc) ou un algorithme de type CMAC (c'est-à-dire un algorithme de génération de code d'authentification utilisant un algorithme de chiffrement, ici avec la clé cryptographique symétrique 5 Kc), tel que l'algorithme CBC-MAC (pour "Cipher Block Chaining - Message Authentication Code"). Comme représenté en figure 4, l'enregistrement reçu 1; est dans ce cas scindé en n blocs -1M , m2, --- mn de dimension prédéterminée. Le premier bloc m1 est combiné par une opération de ou exclusif (ou 10 XOR de l'anglais "eXclusive OR", ou encore somme booléenne) au code d'authentification MAC;_i déterminée lors du précédent passage à l'étape E10 (ou à un vecteur d'initialisation lors du premier passage à l'étape E10 suivant un saut à l'étape E18). Une fonction cryptographique F (par exemple de type AES) est appliquée au résultat de cette combinaison, en utilisant la clé cryptographique 15 symétrique Kc, ce qui permet d'obtenir un résultat partiel r1. Chacun des autres blocs m; (i=2, n) est combiné au résultat partiel r1_1 obtenu sur la base du bloc précédent m1_1, puis transformé par application de la fonction cryptographique F en utilisant la clé cryptographique symétrique Kc, ce qui permet d'obtenir un résultat partiel ri associé au bloc courant mi.
20 Le résultat partiel rn associé au dernier bloc mn constitue le code d'authentification MAC; associé à l'enregistrement reçu l. En variante, les données de vérification pourraient être obtenues par chiffrement de l'enregistrement reçu 1; lui-même, au moyen d'un algorithme de chiffrement à clé symétrique utilisant la clé cryptographique symétrique K.
25 Selon une première possibilité de réalisation, un tel algorithme de chiffrement est appliqué à l'enregistrement courant 1; indépendamment des enregistrements précédents. Si on note par exemple ENC la fonction cryptographique utilisée (par exemple l'algorithme AES), les données de vérification associées à l'enregistrement 1; sont : ENC(Kc,1;).
30 Selon une seconde possibilité de réalisation, on utilise un mode d'opération de type CBC (pour "Cipher Block Chaining") pour combiner les chiffrements par bloc appliqués aux différents enregistrements lors des passages successifs à l'étape E10. Un tel algorithme de chiffrement prévoit de combiner par somme booléenne l'enregistrement courant 1; et les données de vérification 3030163 10 obtenues lors du précédent passage à l'étape E10, puis d'appliquer à la combinaison obtenue une fonction cryptographique (par exemple un algorithme 3DES, également dénommé Triple DES) afin d'obtenir les données de vérification associées à l'enregistrement courant l.
5 Dans le mode de réalisation décrit ici, les données de vérification MAC; obtenues à l'étape El 0 sont envoyées (au moyen du module de communication COM') par le système cryptographique C à destination du système informatique S à l'étape E12. En variante, les données de vérification pourraient être seulement 10 mémorisées (par exemple à l'emplacement mémoire M dans la mémoire non-volatile NV') au sein du système cryptographique C. Dans ce cas, l'étape E12 consiste par exemple à émettre un accusé de réception du système cryptographique C au système informatique S afin de confirmer que l'enregistrement l; a bien été pris en compte.
15 Dans l'exemple de réalisation de la figure 4, les données de vérification MAC; calculées à l'étape El° sont reçues par le système informatique S (au moyen du module de communication COM) l'étape E14. Le système informatique S (en pratique, le module de journalisation LOG) peut alors mémoriser dans l'archive de court terme Al l'enregistrement 20 courant l; et les données de vérification MAC; associées (étape E16). Le procédé boucle alors au premier test Ti déjà décrit. On décrit à présent le processus mis en oeuvre lorsque le premier test Ti a un résultat positif, c'est-à-dire lorsqu'une durée prédéterminée s'est écoulée depuis le dernier saut à l'étape E18, durée pendant laquelle tout nouvel 25 enregistrement l; a été inscrit dans l'archive de court terme Al du fichier journal A, avec association de données de vérification MAC; (mémorisées quant à elles dans l'archive de court terme Al ou, en variante, dans le système cryptographique C). Dans ce cas, comme déjà indiqué, on procède à l'étape E18 à laquelle le module de journalisation LOG lit dans l'archive de court terme Al les 30 enregistrements lb lk inscrits lors des passages successifs à l'étape E16 depuis le dernier passage à l'étape E34, ainsi qu'éventuellement (comme notamment dans l'exemple de réalisation de la figure 3) les données de vérification MACk associées à l'un au moins de ces enregistrements lk. On remarque à cet égard que, comme expliqué plus bas, les données de 3030163 11 vérification nécessaires à la vérification de l'intégrité des enregistrements lb lk (voir troisième test T3 ci-dessous) sont variables en fonction de l'algorithme utilisé pour générer ces données de vérification. Le système informatique S envoie (au moyen du module de 5 communication COM) les données lues (ici les enregistrements lb lk et les données de vérification MACk associées au dernier enregistrement lk) au système cryptographique C (étape E20). On comprend que, dans certains cas, aucune donnée de vérification n'est transmise ; c'est le cas en particulier dans la variante déjà mentionnée où les 10 données de vérification MAC; sont mémorisées dans le système cryptographique C, ou dans une autre variante où l'intégrité des enregistrements est vérifiée au sein du système informatique S, comme expliqué plus bas. Le système cryptographique C reçoit à l'étape E22 les données envoyées et procède à l'étape E24 à un nouveau calcul des données de 15 vérification (pour obtenir par exemple un nouveau code d'authentification MAC') sur la base des enregistrements lb lk reçus à l'étape E22. L'algorithme mis en oeuvre à l'étape E24 pour déterminer les nouvelles données de vérification MAC' est identique à celui de l'étape E10 et utilise la clé cryptographique symétrique Kc (à ceci près que sont mises en oeuvre à l'étape 20 E24 toutes les itérations de l'étape El 0 successivement appliquées aux enregistrements lb lk lors des passages successifs à l'étape El 0). En temps normal, si les enregistrements li,...,1k sont intègres (c'est-à-dire s'ils n'ont pas été altérés au cours de leur mémorisation dans l'archive de court terme Ai), les données de vérification obtenues à l'étape E24 sont égales à celles 25 précédemment obtenues à l'étape E10. Ceci est vérifié par le système cryptographique C par le troisième test T3 qui vise ainsi à déterminer si les données de vérification obtenues à l'étape E24 sont égales aux données de vérification obtenues à l'étape E10. Dans l'exemple de réalisation de la figure 3, ce troisième test T3 est mis 30 en oeuvre en comparant les données de vérification (ici un code d'authentification) MAC' obtenues à l'étape E24 aux données de vérification MACk reçues à l'étape E22. Dans la variante déjà mentionnée où les données de vérification sont mémorisées dans l'emplacement mémoire M, le troisième test T3 est réalisé en 3030163 12 pratique en comparant les données de vérification MAC' obtenues à l'étape E24 aux données de vérification mémorisées dans l'emplacement mémoire M. On remarque que, dans le cas où les données de vérification sont obtenues au moyen d'un algorithme chaîné (qui utilise les données de vérification 5 MAC;_i associées à un enregistrement précédent l;_i pour obtenir les données de vérification MAC; associé à l'enregistrement courant I;) comme dans le mode de réalisation de la figure 3 (voir ci-dessus la description relative à la figure 4), la vérification de l'intégrité des enregistrements li,...,1k peut se limiter à comparer les données de vérification MACk associées au dernier enregistrement lk aux données 10 de vérification MAC' obtenues à l'étape E24 (puisque, grâce au chaînage, toute modification dans l'un des enregistrements li,...,1k se répercute sur les données de vérification MACk associées au dernier enregistrement lk). En revanche, dans d'autres modes de réalisation, et notamment dans le cas mentionné ci-dessus où un chiffrement enregistrement par enregistrement est 15 appliqué, qui produit des données de vérification ENC(Kc,I;) associées chacune à un enregistrement I; indépendamment des autres enregistrements, le troisième test T3 comprend, pour chaque enregistrement I', la comparaison des données de vérification produites pour l'enregistrement I; à l'étape E10 aux données de vérification produites pour l'enregistrement I; à l'étape E24 (ce qui permet de 20 localiser précisément un enregistrement qui aurait été altéré). Par ailleurs, selon une possibilité de réalisation envisageable dans le cas de l'utilisation d'un algorithme de chiffrement réversible au moyen de la clé cryptographique symétrique Kc, la vérification de l'intégrité des enregistrements li,...,1k (troisième test T3) pourrait être réalisée en déchiffrant les données de 25 vérification produites lors de l'étape E10 (sans nouveau calcul des données de vérification comme prévu à l'étape E24 précitée) et en comparant les données déchiffrées aux enregistrements li,...,1k reçus à l'étape E22. Si le troisième test T3 a un résultat négatif (flèche N en figure 3), on procède à une étape E26 de traitement de l'erreur détectée. Un message d'erreur 30 (non représenté en figure 3) est par exemple dans ce cas envoyé au système informatique S. Le système cryptographique C ne procède pas en revanche à la signature des enregistrements. Si le troisième test T3 a un résultat positif, le procédé se poursuit à l'étape E28 à laquelle le module de chiffrement CRYPT du système 3030163 13 cryptographique C génère, par application d'un algorithme de chiffrement de cryptographie asymétrique utilisant la clé cryptographique privée Ko à l'ensemble des enregistrements li,...,1k reçus à l'étape E22, une signature électronique SIG. On peut éventuellement ajouter un nombre généré par un compteur 5 (incrémenté à chaque passage à l'étape E28) et un horodatage aux enregistrements li,...,1k à signer afin de sécuriser encore le fonctionnement du système (puisque la signature SIG atteste dans ce cas également de la valeur du compteur et du moment de la signature). D'autres informations complémentaires peuvent ainsi être utilisées lors de la signature, par exemple la date de la 10 signature et un identifiant des enregistrements, par exemple un numéro de page dans l'archive. Le système cryptographique C envoie alors la signature électronique SIG ainsi générée au système informatique S à l'étape E30. On remarque que, selon une variante envisageable lorsque les données 15 de vérification MAC; sont envoyées au système informatique S à l'étape E12 et mémorisées au sein du système informatique S (par exemple dans l'archive de court terme A1), la comparaison entre les données de vérification MACk produites à l'étape E10 et les nouvelles données de vérification MAC' produites à l'étape E24 peut être réalisée au sein du système informatique S (par exemple par le 20 module de journalisation LOG). Dans un tel cas, les nouvelles données de vérification MAC' produites à l'étape E24 sont renvoyées au système informatique S, où elles sont comparées avec les données de vérification MACk produites à l'étape E10, puis, en cas de résultat positif de la comparaison seulement, les enregistrements li,...,1k sont à 25 nouveau envoyés du système informatique S au système cryptographique C pour signature (cf. étape E28 décrite ci-dessus). On considère dans cette variante qu'aucune altération des enregistrements li,...,1k n'est possible entre leur envoi de l'étape E20 pour génération de nouvelles données de vérification (étape E24) et leur envoi ultérieur 30 pour signature. On peut prévoir pour ce faire de mémoriser momentanément les enregistrements dans la mémoire vive V du système informatique S. La signature électronique SIG envoyée par le système cryptographique à l'étape E30 est reçue par le système informatique S à l'étape E32 et mémorisée, en association avec les enregistrements concernés li,...,1k, dans l'archive de long 3030163 14 terme A2. Le module de journalisation LOG peut ainsi procéder à l'étape E34, dans l'archive de court terme Ai, à la suppression des enregistrements li,...,1k (pour lesquels une signature est à présent disponible dans l'archive de long terme A2), 5 ainsi qu'éventuellement à la suppression des données de vérification MACi,...,MACk respectivement associés à ces enregistrements li,...,1k. Le système informatique S (par exemple le module de journalisation LOG) peut en outre commander au système cryptographique C (par exemple par envoi d'une instruction dédiée, non représentée sur la figure 3), lors de cette étape 10 E34, de supprimer la clé cryptographique symétrique Kc utilisée notamment pour générer les données de vérification à l'étape E10 (ce qui aura pour conséquence, comme expliqué plus haut, la génération d'une nouvelle clé cryptographique symétrique par le système cryptographique C lors du prochain passage à l'étape E10).
15 Selon une variante envisageable, le système informatique S peut commander à l'étape E34 non seulement la suppression de la clé cryptographique symétrique Kc mais également la génération d'une nouvelle clé cryptographique symétrique (cette génération n'étant dans ce cas plus nécessaire à l'étape El 0). Dans les deux cas, l'effacement régulier de la clé cryptographique 20 symétrique Kc permet de réduire les risques d'attaque. Les enregistrements li,...,1k mémorisés dans l'archive de long terme A2 avec la signature SIG qui leur est associée pourront ainsi être vérifiés par un tiers, par exemple un auditeur. Pour ce faire, les enregistrements li,...,1k mémorisés dans l'archive de long terme A2 et la signature SIG seront par exemple envoyées 25 au tiers (en pratique à un serveur dédié) avec un certificat associé à la clé cryptographique privée Ko. Un tel certificat comprend la clé cryptographique publique Kpu associée à la clé cryptographique privée Kpi (mémorisée dans le système cryptographique C) et la signature SlGcA de cette clé cryptographique publique Kpi, par une autorité de 30 certification. Le serveur dédié du tiers peut ainsi vérifier la clé cryptographique publique Kpu au moyen de la signature SIGcA, appliquer un algorithme cryptographique utilisant la clé cryptographique publique Kpu à la signature SIG des enregistrements et vérifier ainsi que les enregistrements li,...,1k reçus sont bien 3030163 15 identiques à ceux qui ont été signés (avec la clé cryptographique privée Kp1) par le système cryptographique C à l'étape E28. Dans les exemples décrits ci-dessus, on utilise un système cryptographique dédié C (distinct du système informatique S) pour réaliser les 5 fonctionnalités cryptographiques nécessaires à la mise en oeuvre du procédé. En variante, l'ensemble des étapes de ce procédé pourraient toutefois être mises en oeuvre au sein d'un seul système qui réaliserait à la fois les fonctions effectuées par le système informatique S et celles effectuées par le système cryptographique C dans les exemples décrits ci-dessus.

Claims (15)

  1. REVENDICATIONS1. Procédé de génération d'un fichier journal (A) comprenant au moins un enregistrement (I;) correspondant à un évènement horodaté dans un système informatique (S), caractérisé en ce qu'il comprend les étapes suivantes : - application (E10) à l'enregistrement (Ii) d'un algorithme cryptographique à clé symétrique utilisant une clé cryptographique symétrique (Kc) de façon à produire des données de vérification (MAC;) ; - mémorisation (E16) des données de vérification (MAC;) ; - vérification ultérieure (T3) de l'intégrité de l'enregistrement par lecture de l'enregistrement et au moyen de la clé cryptographique symétrique (Kc) et des données de vérification (MACk) ; - en cas de vérification positive, génération (E28) d'une signature (SIG) relative au moins audit enregistrement, par application d'un algorithme de cryptographie asymétrique utilisant une clé cryptographique privée (Kp1) ; - mémorisation (E32) de la signature (SIG) en association avec l'enregistrement.
  2. 2. Procédé selon la revendication 1, dans lequel un système cryptographique (C) en communication avec le système informatique (S) met en oeuvre l'étape d'application d'un algorithme cryptographique à clé symétrique et l'étape de génération d'une signature.
  3. 3. Procédé selon la revendication 2, dans lequel le système cryptographique (C) est un module de sécurité matériel ou une carte à microcircuit.
  4. 4. Procédé selon la revendication 2 ou 3, dans lequel la clé cryptographique symétrique (1<c) et la clé cryptographique privée (Ko) sont mémorisées dans le système cryptographique (C).
  5. 5. Procédé selon l'une des revendications 2 à 4, dans lequel les données de vérification (MACi) sont mémorisées dans le système cryptographique (C).
  6. 6. Procédé selon l'une des revendications 1 à 4, dans lequel les données de vérification (MAC;) sont mémorisées dans le système informatique (S).
  7. 7. Procédé selon l'une des revendications 1 à 6, dans lequel l'étape de vérification (T3) comprend une étape de comparaison des données de vérification (MACk) et de nouvelles données de vérification obtenues par application à 3030163 17 l'enregistrement lu (1k) de l'algorithme cryptographique à clé symétrique utilisant la clé cryptographique symétrique (Kc).
  8. 8. Procédé selon l'une des revendications 1 à 7, dans lequel l'étape de vérification est mise en oeuvre au sein du système informatique (S). 5
  9. 9. Procédé selon l'une des revendications 1 à 7, les revendications 6 et 7 étant prises dans la dépendance directe ou indirecte de la revendication 2, dans lequel l'étape de vérification (T3) est mise en oeuvre au sein du système cryptographique (G).
  10. 10. Procédé selon l'une des revendications 1 à 9, dans lequel les 10 données de vérification (MACi) sont obtenues au moyen d'un algorithme de génération d'un code d'authentification de message basé sur l'algorithme cryptographique à clé symétrique utilisant la clé cryptographique symétrique (Kc).
  11. 11. Procédé selon l'une des revendications 1 à 9, dans lequel les données de vérification sont obtenues par chiffrement de l'enregistrement (1i) au 15 moyen de l'algorithme cryptographique à clé symétrique utilisant la clé cryptographique symétrique (Kc).
  12. 12. Procédé selon l'une des revendications 1 à 11, dans lequel l'algorithme cryptographique à clé symétrique est appliqué à la création de l'enregistrement (1i). 20
  13. 13. Procédé selon l'une des revendications 1 à 12, dans lequel une durée prédéterminée est prévue entre deux itérations successives des étapes de vérification ultérieure (T3) et de génération (E28) de la signature (SIG).
  14. 14. Procédé selon la revendication 13, dans lequel la durée prédéterminée est supérieure à 1 heure. 25
  15. 15. Procédé selon l'une des revendications 1 à 14, dans lequel la signature générée est relative à une pluralité d'enregistrements générés entre deux itérations successives de l'étape de génération (E28) de la signature (SIG).
FR1462353A 2014-12-12 2014-12-12 Procede de generation d’un fichier journal Active FR3030163B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR1462353A FR3030163B1 (fr) 2014-12-12 2014-12-12 Procede de generation d’un fichier journal

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1462353A FR3030163B1 (fr) 2014-12-12 2014-12-12 Procede de generation d’un fichier journal

Publications (2)

Publication Number Publication Date
FR3030163A1 true FR3030163A1 (fr) 2016-06-17
FR3030163B1 FR3030163B1 (fr) 2016-12-30

Family

ID=52807899

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1462353A Active FR3030163B1 (fr) 2014-12-12 2014-12-12 Procede de generation d’un fichier journal

Country Status (1)

Country Link
FR (1) FR3030163B1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050086472A1 (en) * 1998-08-21 2005-04-21 Peha Jon M. Methods of generating a verifiable audit record and performing an audit
US20050234909A1 (en) * 2004-04-15 2005-10-20 International Business Machines Corporation Method, computer program product, and data processing system for source verifiable audit logging
US20090328218A1 (en) * 2006-08-28 2009-12-31 Mitsubishi Electric Corporation Data processing system, data processing method, and program
US20100218002A1 (en) * 2009-02-20 2010-08-26 International Business Machines Corporation Securing computer log files

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050086472A1 (en) * 1998-08-21 2005-04-21 Peha Jon M. Methods of generating a verifiable audit record and performing an audit
US20050234909A1 (en) * 2004-04-15 2005-10-20 International Business Machines Corporation Method, computer program product, and data processing system for source verifiable audit logging
US20090328218A1 (en) * 2006-08-28 2009-12-31 Mitsubishi Electric Corporation Data processing system, data processing method, and program
US20100218002A1 (en) * 2009-02-20 2010-08-26 International Business Machines Corporation Securing computer log files

Also Published As

Publication number Publication date
FR3030163B1 (fr) 2016-12-30

Similar Documents

Publication Publication Date Title
EP2876574B1 (fr) Attestation de désinfection de données
US9613038B2 (en) Digital data retention management
FR2986631A1 (fr) Dispositif et procede de production d&#39;un code d&#39;authentification d&#39;un message
WO2016045548A1 (fr) Procédé et dispositif de synchronisation de données
FR2933216A1 (fr) Procede et systeme de validation d&#39;une succession d&#39;evenements vecus par un dispositif
US8631235B2 (en) System and method for storing data using a virtual worm file system
CA2988265C (fr) Securisation de donnees numeriques
WO2016102833A1 (fr) Entité électronique sécurisée, appareil électronique et procédé de vérification de l&#39;intégrité de données mémorisées dans une telle entité électronique sécurisée
EP2100250B1 (fr) Système et procédé de sécurisation de données
FR3030163A1 (fr) Procede de generation d’un fichier journal
EP2859497B1 (fr) Procede de sauvegarde de donnees a l&#39;exterieur d&#39;un microcircuit securise
EP2285042A1 (fr) Module logiciel de sécurisation utilisant le chiffrement du haché d&#39;un mot de passe concaténé avec une graine
FR3050044B1 (fr) Procede de verification automatique d&#39;un fichier informatique cible par rapport a un fichier informatique de reference
WO2015197930A1 (fr) Procédé de partage de fichiers numériques entre plusieurs ordinateurs, et ordinateur, ensemble de stockage de données et système de partage de fichiers numériques associés
EP3021515B1 (fr) Amélioration de l&#39;intégrité authentique de données à l&#39;aide du dernier bloc chiffrant ces données en mode cbc
CA2969495A1 (fr) Procede mis en oeuvre dans un document d&#39;identite et document d&#39;identite associe
EP3493182B1 (fr) Procédé et dispositif de traitement cryptographique de données
FR3038414A1 (fr) Procede et systeme de controle d&#39;acces a un service via un media mobile.
EP3706020A1 (fr) Calcul de signature et vérification d&#39;intégrité de données numériques
FR3097666A1 (fr) Procédé de stockage de données d’authentification de documents
WO2016034812A1 (fr) Sécurisation de clés de cryptage pour transaction sur un dispositif dépourvu de module sécurisé
WO2021084026A1 (fr) Procede mis en œuvre par ordinateur d&#39;etablissement securise d&#39;un document de transfert de responsabilite d&#39;un bien
FR3060807A1 (fr) Procede de verification de l&#39;integrite d&#39;un programme, entite electronique associee et appareil electronique comprenant une telle entite electronique
FR3020909A1 (fr) Entite electronique et procede de generation de cle de session
FR3061384A1 (fr) Procede de traitement de donnees

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20160617

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 6

PLFP Fee payment

Year of fee payment: 7

PLFP Fee payment

Year of fee payment: 8