FR3121240A1

FR3121240A1 - Procédé permettant de garantir l’intégrité des données informatiques gérées par une application tout en préservant leur confidentialité

Info

Publication number: FR3121240A1
Application number: FR2102993A
Authority: FR
Inventors: Samuel Liard; Olivier TEISSERE
Original assignee: Orange SA
Current assignee: Orange SA
Priority date: 2021-03-25
Filing date: 2021-03-25
Publication date: 2022-09-30

Abstract

Procédé permettant de garantir l’intégrité des données informatiques gérées par une application tout en préservant leur confidentialité L’invention se rapporte à un procédé de gestion de données par une application (100) dans un système informatique (SYS) comprenant un ensemble de nœuds distribués (200, 210), ledit procédé étant composé des phases suivantes : une phase d’inscription (REG) de l’application (100) auprès d’un des nœuds parmi l’ensemble des nœuds distribués ;une phase de production (PROD) de signatures de données gérées par l’application (100) et de regroupement des signatures dans un bloc ; une phase de soumission (SUB) par l’application (100) au nœud principal (200) d’un bloc ;une phase de distribution (DIS) par le nœud principal (200) à d’autres nœuds (210) du bloc soumis par l’application (100) ;une phase d’enregistrement (REC) par le nœud principal (200) et par les nœuds secondaires (210) du bloc distribué. Figure 1

Description

Procédé permettant de garantir l’intégrité des données informatiques gérées par une application tout en préservant leur confidentialité

Le domaine technique est celui de la gestion des données informatiques.

Plus précisément, l’invention se rapporte à un procédé permettant de garantir l’intégrité de données informatiques gérées par une application tout en préservant leur confidentialité.

Les données dont il est question sont d’abord des journaux informatiques. Les journaux informatiques sont des fichiers regroupant les traces de fonctionnement de tous types de systèmes informatiques, par exemple des systèmes d’exploitation, des machines virtuelles, des applications, mais aussi des équipements tels que des machines physiques ou des disques mémoires. Un système informatique produit de façon routinière des journaux (appeléslogsen anglais) qui consistent généralement en des concaténations de lignes, chaque ligne comprenant d’une part une date et heure précise, et d’autre part un texte décrivant un événement survenu à cette date et heure précise. Tout système informatique maintient un ou plusieurs journaux qui enregistrent les événements pertinents survenus au cours du fonctionnement du système. C’est également le cas de nombreuses applications informatiques qui maintiennent des journaux qui enregistrent l’ensemble des opérations effectuées par l’application au cours de son fonctionnement. L’invention s’applique tout particulièrement aux journaux informatiques, mais peut s’appliquer à toute donnée informatique gérée par une application à partir du moment où elle peut être sauvegardée sous la forme d’un fichier. Une fois sauvegardée sous forme de fichier, la donnée dont il est question peut disposer de deux éléments qui seront utilisés par l’invention, à savoir d’une part un identifiant qui peut être par exemple le nom du fichier, et d’autre part une signature qui peut être par exemple le résultat d’une fonction de hachage appliquée au fichier. La signature d’une donnée est une suite de caractères qui est caractéristique de la donnée, qui sera donc modifiée si la donnée est modifiée, mais qui ne permet pas de retrouver la donnée elle-même si la signature est connue.

Comme les journaux informatiques regroupent les traces de fonctionnement des systèmes et des applications informatiques, ils sont utiles pour analysera posteriorile fonctionnement de tout système ou toute application informatique. Les journaux peuvent être par exemple utilisés pour déboguer des systèmes informatiques ou bien pour détecter des attaques de personnes malveillantes sur les systèmes. Les journaux informatiques peuvent être utilisés comme preuves dans des contextes judiciaires, quand il faut obtenir des preuves des opérations effectuées par des utilisateurs sur des applications ou des systèmes informatiques, ou bien pour obtenir des preuves de transactions effectuées par des applications informatiques. Cela implique l’intérêt de pouvoir garantir leur intégrité, c’est-à-dire que ces journaux n’ont pas été modifiés après leur création.

Par ailleurs, les journaux informatiques regroupent des données qui ont vocation à rester confidentielles. Par exemple, le journal d’un système de contrôle d’accès regroupera les dates et heures des connexions des utilisateurs du système, qui sont typiquement des données personnelles qui doivent rester confidentielles. L’invention est un procédé qui va à la fois permettre de garantir l’intégrité de journaux informatiques tout en préservant leur confidentialité. Il faut noter que le fait de diffuser la signature d’une donnée ne viole pas sa confidentialité. Si l’invention a d’abord été créée pour s’appliquer à des journaux informatiques, elle peut s’appliquer à tout type de donnée informatique gérée par un système ou une application.

Etat de la technique

La sauvegarde de journaux informatiques utilise les techniques standards de sauvegarde utilisées pour les autres données informatiques. Cependant, comme nous l’avons vu, il est nécessaire de pouvoir garantir l’intégrité des journaux informatiques. Cela implique l’utilisation de techniques nouvelles.

Une technique récente permettant de sauvegarder des données en garantissant leur intégrité est celle de la chaîne de blocs (blockchainen anglais). Cette technique est en particulier utilisée pour implémenter des devises électroniques de façon décentralisée et en particulier lebitcoin. Un bloc est formé à partir d’un ensemble de données ; dans le cas d’une devise électronique, une donnée sera une transaction élémentaire et plusieurs transactions seront regroupées dans un bloc. Un bloc comprendra ou bien directement des données, ou bien uniquement la signature des données si on souhaite préserver la confidentialité des données. Une chaîne de blocs unique est utilisée pour enregistrer toutes les transactions ayant lieu avec cette devise électronique. Un bloc donné comprend la signature d’un bloc précédent avant que soit produite sa propre signature qui sera insérée dans le bloc suivant, ce qui réalise un chaînage dans une chaîne de blocs. La chaîne de blocs est distribuée parmi des nœuds indépendants qui peuvent enregistrer des transactions sur la devise électronique. La technologie de la chaîne de blocs garantit que les transactions enregistrées ne peuvent pas être modifiées sauf si un attaquant arrive à prendre le contrôle de la majorité des nœuds. L’intégrité des données enregistrées par la chaîne de blocs dans ce cas, à savoir la liste des transactions effectuées dans la devise électroniquebitcoin, est indispensable pour garantir le bon fonctionnement de cette devise et éviter la possibilité de créer de la fausse monnaie.

Comme la technologie de la chaîne de blocs permet de garantir l’intégrité d’un ensemble de données, il est naturel qu’elle soit utilisée dans d’autres contextes que les devises électroniques.

La demande de brevet international WO202000722, déposée par la société Ping An Technology, publiée le 26 septembre 2018, utilise une chaîne de blocs unique pour sauvegarder les données produites par des systèmes distincts.

L’utilisation d’une chaîne de blocs unique implique qu’une application ou système va soumettre les données qu’elle gère à des nœuds externes afin de produire cette chaîne de blocs uniques en intégrant ses données. Ce faisant, la confidentialité des données gérées par l’application est nécessairement perdue. Ceci n’est pas un problème dans le contexte de la gestion d’une devise électronique. Les transactions avec une devise donnée n’ont pas à rester confidentielles du moment que les acteurs des transactions ont une identité anonyme. Dans d’autres contextes par contre, et en particulier pour la sauvegarde de journaux informatiques de tous types, il est indispensable de préserver la confidentialité des données.

Il est possible à une application de soumettre à une chaîne de blocs unique des blocs qui ne comprennent plus directement les données gérées, mais des signatures de ces données. De cette manière, la confidentialité est améliorée aux dépens du fait qu’une application puisse soumettre une signature qui ne corresponde pas aux données qu’elle gère.

Un autre défaut de la chaîne de blocs unique demeure cependant dans tous les cas, à savoir la complexité de l’insertion. Tous les nœuds doivent mettre en œuvre un algorithme de consensus avant d’insérer un nouveau bloc. Quand l’algorithme de consensus se base sur une preuve de calcul, la consommation énergétique de l’algorithme sera très élevée.

Par ailleurs, un autre défaut de la chaîne de blocs unique est qu’elle est sous le contrôle d’une entité unique, par exemple une seule entreprise, qui peut ensuite disposer de facilités pour modifier des données et répercuter ces modifications dans la chaîne de blocs.

Même si la technique de la chaîne de blocs garantit l’intégrité des données gérées par une application, quand des applications différentes confient la sauvegarde de leurs données à une seule chaîne de blocs, cela implique une insertion complexe et coûteuse énergétiquement quand tous les nœuds travaillent sur une seule chaîne de blocs. Cela peut également annuler la confidentialité des données si ce sont les données qui sont directement insérées dans les blocs et pas leurs signatures.

L’invention vient améliorer la situation.

L’invention

Selon un premier aspect fonctionnel, l’invention a trait à un procédé de gestion de données par une application dans un système informatique comprenant un ensemble de nœuds distribués et connectés entre eux par un réseau de communication, ledit procédé étant caractérisé en ce qu’il est composé des phases suivantes :

une phase d’inscription de l’application auprès d’un des nœuds parmi l’ensemble des nœuds distribués, ce nœud étant dit nœud principal, et de calcul par l’application d’un identifiant unique et d’une adresse de contact ;
une phase de production de signatures de données gérées par l’application et de regroupement des signatures associées à des identifiants des données signées dans un bloc de données ;
une phase de soumission par l’application au nœud principal auprès duquel elle s’est inscrite d’un bloc regroupant des signatures de données et les identifiants des données signées ;
une phase de distribution par le nœud principal à d’autres nœuds parmi l’ensemble des nœuds distribués, ces autres nœuds étant dits nœuds secondaires, du bloc soumis par l’application, ce bloc étant étiqueté par l’identifiant unique de l’application dans le système et son adresse de contact ;
une phase d’enregistrement par le nœud principal et par les nœuds secondaires du bloc distribué par le nœud principal et de son étiquetage avec l’identifiant unique de l’application et son adresse de contact.

Grâce à l’invention, l’application produit des signatures des données qu’elle gère. Ces signatures permettent de s’assurer que les données n’ont pas été modifiées après leur production en comparant les signatures distribuées dans un bloc aux différents nœuds de gestion avec des signatures des données calculées de nouveau. De cette manière, l’intégrité des données gérées par l’application est garantie puisqu’il est possible de détecter des modifications a posteriori des données gérées par l’application. Comme le bloc comprenant les signatures de données est distribuée à tout un ensemble de nœuds, il est quasiment impossible pour un attaquant de changer toutes ces valeurs de signatures pour les coordonner avec une modification des données gérées par l’application.

De plus, contrairement aux solutions qui utilisent une chaîne de blocs unique, l’invention ne distribue pas les données qu’elle gère pour les intégrer à une chaîne de blocs commune à tout un ensemble d’applications, ce qui peut violer la confidentialité des données. Ce qui est distribué en dehors de l’application est une signature des données gérée par l’application, pas les données elle-même. De cette manière, l’invention préserve bien la confidentialité des données gérées par l’application.

On voit donc que l’invention permettra de réaliser des audits sur les données gérées par les applications, en réalisant des calculs de signatures et en les comparant avec les signatures des données distribuées précédemment. Ces phases d’audits, indépendantes des autres phases, ne font pas partie de l’invention elle-même.

Le fait qu’un identifiant unique soit calculé par l’application lors de son inscription permet à l’invention de s’appliquer à tout un ensemble d’applications au sein du système. Chaque nœud va jouer de façon parallèle les rôles de nœud principal vis-à-vis de certaines applications, qui s’inscrivent auprès de lui dans le système, et de nœud secondaire auprès des autres applications. De cette manière, le système permet à plusieurs entités, par exemple des entreprises différentes, de coopérer pour garantir l’intégrité de leurs applications respectives. L’identifiant unique des applications sera nécessaire pour attribuer à chaque application les signatures de données qu’elle aura produite dans ce système non centralisé. L’identifiant unique de l’application dans le système lui permettra aussi d’interagir directement avec des nœuds secondaires, sans passer par le nœud principal, dans certains modes de réalisation de l’invention. L’adresse de contact de l’application permettra également à tous les nœuds du système de pouvoir interagir directement avec l’application sans passer par le nœud principal.

Selon encore un premier mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec le mode précédent, les étapes b) à e) sont exécutées dès que l’application gère de nouvelles données.

Grâce à ce premier mode, l’invention permet à l’application de garantir l’intégrité des données gérées tout au long de son cycle de vie. En effet, au fur et à mesure que l’application gère de nouvelles données dont on souhaite garantir l’intégrité, de nouveaux blocs sont produits qui comprennent les signatures de ces nouvelles données. Ces blocs sont ensuite distribués et enregistrés par l’ensemble des nœuds qui les reçoivent, soit parce que les blocs leur sont soumis directement par l’application, soit parce qu’ils leur sont distribués par d’autres nœuds.

Selon un deuxième mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les modes précédents, les blocs produits par l’application comprennent, en plus des signatures de données et des identifiants de données signées, d’une part une signature du bloc précédemment produit par l’application, le premier bloc produit par l’application comprenant une signature d’un bloc fictif, et d’autre part une signature de l’ensemble des éléments du bloc.

Dans ce deuxième mode de réalisation, l’invention utilise une technique de chaînage de blocs. L’avantage de cette technique est de rendre très difficile la modification des données gérées par l’application. En effet, un attaquant qui souhaiterait modifier une donnée devrait également modifier d’abord la signature de la donnée dans le bloc dans lequel elle est incluse, puis la signature de tous les blocs qui sont enchaînés à ce bloc, car le changement d’une signature dans un bloc implique de changer la signature de ce bloc lui-même, qui est incluse dans le bloc suivant, et donc la signature de ce bloc suivant, puis de tous les blocs ultérieurs. Cette technique de chaînage de blocs rend donc très difficile la modification de données une fois qu’elles ont été signées et les signatures regroupées dans un bloc par l’invention.

Selon un troisième mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les modes précédents, la signature du bloc est effectuée par l’application au fur et à mesure de l’ajout de signatures de données, et, lorsqu’une quantité déterminée de signatures de données a été inscrite dans le bloc, une dernière opération de signature du bloc est effectuée par l’application, puis le bloc est soumis par l’application au nœud principal.

L’avantage de ce troisième mode de réalisation est de pouvoir faire varier la taille des blocs et de ne pas devoir créer un nouveau bloc à chaque nouvel ajout d’une donnée par l’application. De cette manière, il est possible d’optimiser le système en s’assurant que les nœuds ne sont pas trop sollicités, de même que le réseau qui permet de distribuer les blocs.

Selon un quatrième mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les modes précédents, les nœuds secondaires distribuent à d’autres nœuds les blocs reçus par eux jusqu’à ce que l’ensemble des nœuds accessibles du système aient tous reçu le bloc distribué initialement par le nœud principal.

Grâce à ce quatrième mode de réalisation de l’invention, les blocs ne sont pas distribués uniquement aux nœuds secondaires qui sont en contact immédiat avec le nœud principal. Les blocs de l’application sont distribués de proche en proche à l’ensemble des nœuds, dans tout le système. Cela rend là encore la modification de données par un attaquant encore plus difficile, car l’attaquant devrait modifier les signatures présentes dans les blocs dans tous les nœuds du système. De plus, la distribution à l’ensemble des nœuds du système d’un bloc de l’application permet aux nœuds de connaître l’identifiant et l’adresse de contact de l’application qui étiquettent le bloc. De cette manière, les nœuds secondaires ont connaissance des informations qui leur permettront d’interagir directement avec l’application, sans passer par le nœud principal.

Selon un cinquième mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les modes précédents, l’application soumet un bloc à un autre nœud que le nœud principal.

Grâce à ce cinquième mode de réalisation de l’invention, l’application n’est pas limitée à interagir uniquement avec le nœud principal. Si cela devient plus pratique à un moment donné pour l’application, celle-ci peut soumettre un bloc à n’importe quel nœud dans le système. Comme l’application a calculé un identifiant unique dans le système, le nœud pourra bien attribuer le bloc à l’application concernée. L’adresse de contact permet au nœud secondaire de retrouver l’application pour des interactions ultérieures.

Selon un sixième mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les modes précédents, les nœuds, qu’ils soient principal ou secondaire, suite à la réception d’un bloc, d’une part comparent la signature du bloc précédent qu’ils ont enregistré avec la signature du bloc précédent qui est comprise dans le bloc reçu, d’autre part calculent la signature de l’ensemble des éléments du bloc et la comparent avec la signature de l’ensemble des éléments du bloc qui est comprise dans le bloc reçu, et refusent d’enregistrer et de transmettre le bloc soumis si les deux paires de signatures ne correspondent pas.

Grâce à ce sixième mode de réalisation de l’invention, les nœuds valident les blocs qui leur sont soumis par l’application ou distribués par d’autres nœuds. Là encore, l’objectif est de rendre plus difficile de modifier une donnée après qu’une signature de la donnée ait été enregistrée dans un bloc, et ce bloc soumis puis distribué aux nœuds. En effet, si un attaquant réussit à modifier une donnée au niveau de l’application, les signatures de cette donnée et donc la signature du bloc qui la comprend, seront modifiées. Quand un nouveau bloc est distribué, comme il comprend les signatures des blocs passés, il y aura une divergence entre la signature passée de la donnée qui se retrouve dans la signature des blocs, et la nouvelle signature de la donnée modifiée. Cette divergence permet de détecter que des modifications de donnée ont eu lieu. L’algorithme de détection est très simple si on le compare aux algorithmes de consensus utilisés dans les chaînes de blocs.

Selon un septième mode de mise œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les modes précédents, l’application soumet une signature de bloc à un nœud, dit nœud initial, qu’il soit principal ou secondaire. Dans ce mode, le nœud compare la signature enregistrée par le nœud initial à la signature soumise par l’application, puis le nœud initial diffuse la signature soumise par l’application aux autres nœuds et recueille le résultat des comparaisons effectuées par l’ensemble des nœuds, puis le nœud initial transmet à l’application le résultat des comparaisons.

Grâce à ce septième mode, l’invention permet à l’application de valider un bloc qu’elle a produit. L’application peut soumettre à n’importe quel nœud une signature d’un bloc donné, et ce nœud, en regroupant les réponses d’autres nœuds, pourra dire à l’application s’il y a des divergences entre la signature soumise et les signatures enregistrées par les nœuds. Cette validation permet à l’application de détecter de possibles modifications d’une donnée enregistrée dans le bloc, que cette modification soit faite au niveau de l’application, ou bien au niveau des blocs distribués aux nœuds. Les actions que l’application peut ensuite mettre en œuvre une fois cette détection faite ne font pas partie de l’invention en elle-même.

Selon un huitième mode de mise œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les modes précédents, un utilisateur du système soumet une signature de bloc, l’identifiant du bloc et l’identifiant de l’application à un nœud, dit nœud initial, qu’il soit principal ou secondaire. Dans ce mode, le nœud initial compare la signature enregistrée par le nœud initial à la signature soumise par l’utilisateur, puis le nœud initial diffuse la signature soumise par l’utilisateur avec l’identifiant du bloc et celui de l’application aux autres nœuds et recueille le résultat des comparaisons effectuées par l’ensemble des nœuds, puis le nœud initial transmet à l’utilisateur du système le résultat des comparaisons.

Grâce à ce huitième mode de mise en œuvre particulier de l’invention, il sera possible de demander au système de valider un bloc produit par l’application. Pour cela, un utilisateur devra connaître l’identifiant du bloc et celui de l’application. Un utilisateur du système pourra requêter un nœud en lui soumettant une signature d’un bloc, l’identifiant du bloc et l’identifiant de l’application concernée pour que le nœud puisse retrouver le bloc parmi ceux qu’il a enregistrés, réaliser la comparaison entre la signature soumise et la signature enregistrée, diffuser la requête aux autres nœuds et fournir une compilation des résultats à l’utilisateur. Cette procédure permettra à un utilisateur de vérifier l’intégrité des données gérées par l’application indépendamment de l’application elle-même. De cette manière, l’intégrité des données est garantie même si l’on suppose que l’application puisse vouloir camoufler des modifications faites a posteriori sur les données qu’elle gère.

Selon un neuvième mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les modes précédents, le résultat des comparaisons que le nœud initial transmet à l’application ou à l’utilisateur du système comprend une quantité de nœuds pour lesquels la comparaison a échoué et une quantité pour lesquels elle a réussi.

Grâce à ce neuvième mode, les informations permettant à l’application ou à l’utilisateur de détecter des modifications des données sont transmises par le nœud initial. La politique que l’application ou l’utilisateur mettront ensuite en œuvre pour répondre à une éventuelle modification est en dehors du périmètre de l’invention.

Selon un dixième mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les modes précédents, la signature des données et celle des blocs sont réalisées par des fonctions de hachage.

Grâce à ce dixième mode, on s’assure que les signatures réalisées dans le cadre de l’invention présentent bien de bonnes propriétés. Avec des signatures réalisées par des fonctions de hachage, on est sûr qu’une modification de la donnée ou d’un bloc va impliquer une modification de la signature. On est sûr également que des données différentes auront bien des signatures différentes. Enfin, on est sûr qu’il sera impossible à un attaquant de trouver une donnée ou un bloc qui produise une signature voulue.

Selon un aspect matériel, l’invention se rapporte à un système informatique comprenant au moins une application s’exécutant sur un serveur et des nœuds distribués, s’exécutant sur des serveurs, connectés entre eux par un réseau de communication, système caractérisé en ce que l’application comprend :

un module permettant l’inscription de l’application auprès d’un des nœuds du système, ce nœud étant dit nœud principal ;
un module de production d’une signature des données gérées par l’application et de regroupement de ces signatures, associées à des identifiants des données signées, dans des blocs ;
un module de soumission au nœud principal des blocs regroupant les signatures des données, et les identifiants des données signées ;

et caractérisé en ce qu’un nœud comprend :

un module de distribution aux autres nœuds des blocs regroupant les signatures de données gérées par les applications ;
un module d’enregistrement des blocs regroupant les signatures de données distribués par les autres nœuds.

Selon un autre aspect matériel, l’invention a trait à un programme d'ordinateur apte à être mis en œuvre par un serveur, le programme comprenant des instructions de code qui, lorsqu’il est exécuté par un processeur, réalise les étapes mises en œuvre par l’application du procédé de gestion défini ci-dessus.

Selon un autre aspect matériel, l’invention a trait à un programme d'ordinateur apte à être mis en œuvre par un serveur, le programme comprenant des instructions de code qui, lorsqu’il est exécuté par un processeur, réalise les étapes mises en œuvre par un nœud du procédé de gestion défini ci-dessus.

Enfin, selon un autre aspect matériel, l’invention a trait à des supports de données sur lesquels sont enregistrés des programmes d’ordinateurs comprenant des séquences d’instructions pour la mise en œuvre des étapes du procédé de gestion défini ci-dessus.

Les supports de données peuvent être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, les supports peuvent comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique tel qu’un un disque dur. D'autre part, les supports peuvent être des supports transmissibles tels qu'un signal électrique ou optique, qui peuvent être acheminés via un câble électrique ou optique, par radio ou par d'autres moyens. Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.

L'invention sera mieux comprise à la lecture de la description qui suit, donnée à titre d'exemple, et faite en référence aux dessins annexées sur lesquels :

représente un système composé d’une application, d’un nœud principal et d’un nœud secondaire sur lequel est illustré un exemple de réalisation de l’invention.

décrit un exemple de structure d’un bloc de données, illustrant le chaînage des blocs.

décrit un exemple d’algorithme utilisé par un nœud pour valider un bloc de données.

décrit un autre exemple d’algorithme que le système peut mettre en œuvre.

Description détaillée d’un ou plusieurs exemples de réalisation de l'invention

La représente un système informatique SYS incluant une application informatique 100. Cette application pourra être par exemple une application bancaire, une application de commerce électronique ou bien une application de contrôle d’accès d’utilisateurs, ou bien un système d’exploitation. Il peut s’agir de n’importe quelle application qui manipule des données. Les données en question ne sont pas représentées dans la figure, mais il s’agit là aussi de tout type de donnée possible, par exemple des traces de transaction électroniques, des journaux retraçant le fonctionnement de l’application ou bien des fichiers édités par l’application. L’invention va permettre de garantir l’intégrité des données manipulées par l’application tout en préservant leur confidentialité, et ceci pour tout type d’application informatique et tout type de donnée manipulée.

L’application 100 s’exécute sur un serveur non représenté sur la . Ce serveur présente l’architecture matérielle d’un ordinateur conventionnel. Il comporte notamment un processeur, une mémoire vive de type RAM et une mémoire morte telle qu’une mémoire de type Flash, ROM, (non représentés sur la figure) et il peut comporter des dispositifs d’entrée-sortie tels que claviers et/ou écrans (non représentés sur la figure).

Le système SYS comprend également des nœuds de calcul distribués qui permettent de réaliser l’invention. Dans la , on représente deux nœuds 200 et 210. Dans notre exemple, ces nœuds sont identiques entre eux, mais jouent un rôle distinct vis-à-vis de l’application 100. Le nœud 200 est le nœud principal car c’est le premier nœud qui se trouve en relation avec l’application 100 lors de la mise en œuvre de l’invention. Le nœud 210 est pour sa part un nœud secondaire.

La représente une seule application 100 et deux nœuds 200 et 210, le nœud 200 étant nœud principal et le nœud 210 étant nœud secondaire, mais un déploiement typique de l’invention par un système SYS comprendra plusieurs applications et plusieurs nœuds, les nœuds pouvant jouer indifféremment le rôle de nœud principal pour certaines applications et de nœud secondaire pour d’autres. La seule contrainte est que pour une application 100 présente dans le système SYS, il existera un et un seul nœud principal 200.

Les nœuds 200 et 210 s’exécutent sur des serveurs non représentés sur la . Ces serveurs présentent l’architecture matérielle d’un ordinateur conventionnel. Ils comportent notamment des processeurs, des mémoires vives de type RAM et des mémoires mortes telles que mémoires de type Flash ou ROM. Les serveurs peuvent également comporter des dispositifs d’entrée-sortie tels que claviers et/ou écrans.

Les nœuds 200 et 210 peuvent s’exécuter chacun sur un serveur séparé ou bien sur le même serveur. Plusieurs nœuds peuvent s’exécuter sur un même serveur sans limitation particulière. De même, l’application 100 peut s’exécuter sur un serveur séparé ou bien partager son serveur avec un nœud ou une autre application. Là encore, plusieurs applications et plusieurs nœuds peuvent s’exécuter sur un même serveur sans limitation particulière.

Dans notre exemple décrit par la , les nœuds 200 et 210 du système SYS sont reliés entre eux par un réseau de communication 300. Ce réseau de communication peut être tout type de réseau de communication comme par exemple le réseau Internet, mais aussi un réseau de communication privé, uniquement utilisé par le système SYS. L’ensemble des nœuds et des applications du système SYS peuvent faire partie d’un seul réseau de communication 300 ou bien ils peuvent être reliés entre eux par plusieurs réseaux de communication, qui peuvent être Internet ou des réseaux privés. Par ailleurs, on peut considérer que des applications et des nœuds qui s’exécutent sur un même serveur peuvent communiquer entre eux sans passer par un réseau de communication. Par exemple, dans la , l’application 100 n’appartient pas au réseau de communication 300 mais elle peut communiquer avec le nœud principal 200 car l’application 100 et le nœud principal 200 s’exécutent sur un même serveur non représenté sur la figure. En variante, l’application 100 pourrait communiquer avec le nœud 200 par une liaison de communication de courte portée telle qu’une liaison Bluetooth, RFID (Radio Frequency Identification), ou bien une liaison filaire Ethernet, ou tout autre type de liaison. De même, en variante, la liaison entre les nœuds 200 et 210 pourrait être une liaison à courte portée, ou bien même les nœuds 200 et 210 pourraient s’exécuter sur un même serveur et communiquer directement.

L’invention nécessite que l’application 100 s’inscrive auprès du nœud principal 200. La phase d’inscription REG est effectuée par un module 101 de l’application, module permettant l’inscription de l’application 100 auprès du nœud principal 200.

Il est important de noter que, dans notre exemple, le nœud principal 200 n’est en lui-même pas différent du nœud secondaire 210 et des autres nœuds secondaires présents dans le système SYS. C’est la phase d’inscription REG qui confère la nature de nœud principal au nœud 200 et cela pour l’application 100. Pour d’autres applications présentes dans le système SYS mais non représentées sur la , le nœud 200 jouera le rôle de nœud secondaire, car ces autres applications auront réalisé la phase d’inscription REG auprès d’autres nœuds qui joueront alors le rôle de nœud principal pour ces applications.

La phase d’inscription REG comprend le calcul par l’application 100 d’un identifiant unique de l’application 100 dans le système SYS et d’une adresse de contact pour l’application 100. Cet identifiant et cette adresse de contact ne sont pas représentés dans la .

Le calcul de l’identifiant pourra utiliser le même algorithme que celui utilisé dans les techniques de monnaie électronique. Par exemple, l’application pourra générer une paire de clés cryptographiques RSA (pour Rivest, Shamir, Adleman, les trois inventeurs de cet algorithme), l’une publique et l’autre privée. A partir de la clé publique de l’application, la combinaison de fonctions de hachage et de fonctions de troncature pourra produire un identifiant unique de l’application 100 dans le système SYS. C’est cette technique qui est utilisée par la technologie de chaînage de blocsbitcoin. D’autres techniques de génération d’un identifiant unique peuvent être utilisées, comme l’utilisation d’un générateur aléatoire, en combinaison ou non avec la technique précédente. Au final, l’identifiant de l’application 100 dans le système SYS sera une suite de longueur suffisante de caractères alphanumériques.

De manière similaire, l’application 100 va calculer lors de la phase d’inscription REG son adresse de contact. Par des méthodes similaires à celles utilisées pour dériver son identifiant, l’application 100 va calculer une chaîne de caractères alphanumériques qui sera utilisée ensuite comme adresse de contact dans un protocole de communication quelconque. L’adresse de contact peut par exemple être une adresse de messagerie électronique, ou bien une adresse du protocole FTP (File Transfer Protocol), ou bien une adresse permettant de faire des requêtes d’API (Application Programming Interface).

L’application 100 produit au cours de son fonctionnement tous types de données. Par exemple, si l’application 100 est une application bancaire, l’application 100 va enregistrer l’ensemble des opérations qu’elle aura traitées. De même si l’application 100 est une application de commerce électronique, l’application 100 va enregistrer l’ensemble des transactions effectuées. Si l’application 100 est un système de contrôle d’accès, elle va enregistrer les accès des utilisateurs qui sont contrôlés par l’application 100. Quelle que soit l’application 100, elle va produire au cours de son fonctionnement des journaux informatiques qui enregistrent régulièrement toutes les traces de fonctionnement de l’application 100. Indépendamment du domaine fonctionnel de l’application 100, l’application 100 produit des données dont il sera intéressant de garantir l’intégrité, c’est-à-dire de garantir qu’elles n’ont pas été modifiées après leur création, tout en préservant leur confidentialité.

Pour ces données dont on souhaite préserver l’intégrité, l’application 100 va procéder, indépendamment de son fonctionnement habituel, à une phase de production PROD de signature de données gérées par l’application, données dont on souhaite préserver l’intégrité, et de regroupement des signatures associées à des identifiants des données signées dans un bloc de données. Cette phase de production PROD est réalisée par un module de production 102. L’algorithme utilisé pour réaliser les signatures de données peut être de type varié. L’important est qu’une modification de la donnée implique ensuite une modification de la signature, pour pouvoir détecter cette modification en effectuant une nouvelle signature. Le plus simple est l’application d’une fonction de hachage à la donnée, par exemple une parmi les fonctions standardisées MD4, MD5, SHA128, SHA256 ou SHA512, ou toute autre fonction de hachage. Il est possible également de combiner des fonctions de hachage en utilisant un arbre de hachage ou arbre de Merkle ou toute autre combinaison. Il est possible également d’utiliser des fonctions de cryptographie symétrique ou asymétrique. Il est possible également de combiner les fonctions de hachage avec des fonctions de troncature pour limiter la taille des signatures obtenues si besoin.

Une fois obtenu la signature d’une donnée, le module de production 102 va combiner celle-ci durant la phase de production PROD avec d’autres signatures d’autres données dans un bloc de données. La structure du bloc de données peut être là aussi de tout type, mais il est nécessaire d’associer la signature d’une donnée avec un identifiant de la donnée signée pour pouvoir retrouver la donnée concernée. Cet identifiant sera par exemple un nom de fichier, ou bien un nom de variable. L’identifiant pourra contenir la date ou même l’instant de création de la donnée pour pouvoir retrouver cette information ultérieurement. Le nombre de signatures de données présentes dans un bloc de données peut être variable. Il pourra dépendre du rythme de production de données par l’application 100, et de la taille attendue d’un bloc pour être ensuite manipulé par les nœuds 200 et 210. L’application 100 va procéder ensuite à une phase de soumission SUB du bloc produit au nœud principal 200. Cette phase de soumission SUB est effectuée conjointement par le module de soumission 103 de l’application 100 et le module de distribution 202 du nœud principal 200. La phase de soumission SUB peut se répéter après chaque nouvelle phase de production PROD réalisée par l’application 100, ou bien l’application 100 peut effectuer des phases de soumission SUB de façon désynchronisée des phases de production PROD de blocs de données.

L’avantage de l’invention apparaît clairement ici. Un bloc de données va regrouper des signatures de données dont on veut garantir l’intégrité. Si une donnée est modifiée, sa signature sera différente de celle présente dans le bloc de données. Comme le bloc de données est soumis au nœud principal 200, il sera possible d’auditer la donnée, en refaisant l’opération de signature, pour voir si la donnée a été modifiée a posteriori. Cette opération d’audit permet de garantir l’intégrité de la donnée car une modification est détectable.

Par ailleurs, un autre avantage de l’invention consiste en la préservation de la confidentialité de la donnée. En effet, c’est une signature de la donnée qui est présente dans le bloc de données et soumise au nœud principal 200. La confidentialité de la donnée reste donc garantie en dehors de l’application 100.

Une fois un bloc de données soumis au module de distribution 202 du nœud principal 200, celui-ci va procéder à deux phases, une phase de distribution DIS et une phase d’enregistrement REC. Ces deux phases peuvent être effectuées de façon simultanée, ou bien de façon séquentielle, dans un ordre indifférent.

Le module de distribution 202 du nœud principal 200 va ainsi procéder à une phase de distribution DIS du bloc de données à d’autres nœuds du système, dits nœuds secondaires, ce bloc de données étant étiqueté par l’identifiant unique de l’application 100 dans le système SYS et par l’adresse de contact de l’application. Dans la , un seul nœud secondaire 210 du système SYS est représenté, et le module de distribution 202 du nœud principal 200 effectue la phase de distribution DIS du bloc de données au module d’enregistrement 211 du nœud secondaire 210.

Le module d’enregistrement 201 du nœud principal 200 et le module d’enregistrement 211 du nœud secondaire 210 vont également procéder à une phase d’enregistrement REC du bloc de données, ce bloc de données étant étiqueté par l’identifiant unique de l’application 100 dans le système SYS et par l’adresse de contact de l’application.

Les phases de distribution DIS et d’enregistrement REC améliorent encore l’avantage principal de l’invention, à savoir la préservation de l’intégrité de données gérées par l’application 100. En effet, en diffusant le bloc de données au-delà du nœud principal 200 vers le nœud secondaire 210, et en enregistrant le bloc de données au-delà du nœud principal 200, l’invention permet d’avoir des copies distribuées du bloc de données. Un attaquant qui souhaiterait modifier les données a posteriori devrait donc modifier le bloc de données non seulement au niveau de l’application 100 et du nœud principal 200 mais aussi au sein du nœud secondaire 210. Ceci augmente grandement la difficulté d’une attaque et donc améliore les garanties d’intégrité de la donnée à protéger. Par ailleurs, comme c’est toujours la signature de la donnée qui est présente dans le bloc de données, la confidentialité de la donnée est toujours garantie.

Selon un autre mode de réalisation de l’invention, les phases de production PROD, de soumission SUB, de distribution DIS et d’enregistrement REC sont exécutées dès que l’application 100 gère de nouvelles données.

L’avantage de ce mode de réalisation est que les protections apportées par l’invention sont présentes tout au long du cycle de vie de l’application 100. Quand de nouvelles données sont produites par l’application 100, elles vont être signées, et la signature insérée dans un bloc de données, ce qui correspond à la phase PROD ; puis lorsqu’une taille de bloc suffisante est atteinte, le bloc de données est soumis au nœud principal 200 lors de la phase de soumission SUB, puis distribué au nœud secondaire 210 lors de la phase de distribution DIS, puis enregistré par le nœud principal 200 et le nœud secondaire 210 lors de la phase d’enregistrement REC.

Selon un autre mode de réalisation de l’invention, le nœud secondaire 210 distribue à d’autres nœuds secondaires, non représentés sur la , les blocs reçus par lui jusqu’à ce que l’ensemble des nœuds accessibles du système aient tous reçu le bloc distribué initialement par le nœud principal 200.

Grâce à ce mode de réalisation, l’invention va permettre de répartir le plus vite possible les blocs produits par l’application 100 dans un maximum de nœuds, qu’il s’agisse du nœud principal 200 ou de nœuds secondaires 210. De cette façon, et comme vu précédemment, un attaquant qui souhaiterait modifier les données a posteriori devrait donc modifier le bloc de données non seulement au niveau de l’application 100 et du nœud principal 200 mais aussi au sein des nœuds secondaires 210. Ceci augmente grandement la difficulté d’une attaque et donc améliore les garanties d’intégrité de la donnée à protéger. Par ailleurs, comme c’est toujours la signature de la donnée qui est présente dans le bloc de données, la confidentialité de la donnée est toujours garantie.

Selon un autre mode de réalisation de l’invention, lors de la phase de soumission SUB, l’application soumet un bloc à un autre nœud que le nœud principal 200.

Grâce à ce mode de réalisation, l’avantage vu précédemment de l’invention est renforcé. L’application 100 va en effet ainsi pouvoir distribuer plus rapidement les blocs de données aux nœuds 200 et 210 ce qui améliore les garanties de protection de l’intégrité des données dont les signatures sont présentes dans les blocs de données.

La présente un autre mode de réalisation de l’invention. En particulier, la présente une structure possible du bloc de données. La présente trois blocs de données. Ces trois blocs présentent, ce qui est commun à tous les modes de réalisation de l’invention, une liste d’identifiants de données, associées à des signatures des données identifiées. Dans le bloc de gauche, les identifiants de données vont de i1 à iN, et les signatures associées de données sont Sig_i1 à Sig_iN, respectivement. Dans le bloc du milieu, les identifiants vont de j1 à jM, et les signatures associées de Sig_j1 à Sig_jM, respectivement. Et enfin, dans le bloc de droite, les identifiants vont de k1 à kL et les signatures de Sig_k1 à Sig_kL, respectivement. Les trois blocs comprennent également l’identifiant unique de l’application, à savoir App_X, et l’adresse de contact, à savoir Address_X.

Il est possible également de rajouter d’autres informations dans les blocs de données. Dans la , deux informations supplémentaires sont ajoutées dans les blocs à fins d’illustration. Tout d’abord, un identifiant du bloc est ajouté à chaque bloc ; cet identifiant est B1 pour le bloc de gauche, B2 pour le bloc du centre, B3 pour le bloc de droite. Ensuite, une date de création est ajoutée à chaque bloc ; cette date est date1 pour le bloc de droite, date2 pour le bloc du centre, date3 pour le bloc de droite. D’autres informations peuvent être rajoutées aux blocs de données dans d’autres modes de réalisation de l’invention, mais ne sont pas représentés dans la . Il serait possible par exemple de rajouter une heure précise de création du bloc en plus de la date, ou bien une signature globale de l’ensemble des signatures de données regroupées dans le bloc, par exemple avec un hachage de Merkle, ou bien un numéro de version des opérations de signature des données ou des blocs, ou bien un moyen de contacter un responsable humain des données concernées, ou toute autre information qui serait jugée pertinente.

Dans le mode de réalisation de l’invention représenté par la , les blocs sont chaînés entre eux. Pour cela, il est nécessaire d’ajouter aux blocs de données une signature de bloc. Pour le bloc B1, qui est le premier créé dans l’exemple représenté par la , une signature fictive est créée, qui est dénommée Sig_B0 dans la . Cette signature fictive reprend le format attendu comme résultat de l’opération de signature de données choisie dans l’invention. Le format attendu sera donc une suite de caractères alphanumériques d’une longueur donnée. Comme vu précédemment, l’opération de signature peut consister en l’application d’une fonction de hachage, ou bien d’une fonction de cryptographie symétrique ou asymétrique. Plusieurs fonctions peuvent être combinées, avec également des fonctions de troncature. Il faut noter que l’opération de signature choisie pour signer les données dont on souhaite garantir l’intégrité et l’opération de signature choisie pour signer un bloc de données peuvent être deux opérations différentes.

A partir d’un certain nombre de signatures de données inscrites dans le bloc B1, il sera nécessaire de créer un nouveau bloc de données B2. Dans le mode de réalisation de l’invention représenté dans la , cela implique de procéder à une opération de chaînage des blocs. Pour cela, comme déjà indiqué, une signature fictive Sig_B0 est créée, et l’opération de signature est appliquée à une concaténation de la signature fictive Sig_B0 et des différents identifiants et signatures présents dans le bloc B1. Le résultat de cette opération de signature est dénommé Sig_B1 et est la signature du bloc B1. L’opération de signature est représentée par une accolade à l’intérieur du bloc B1 qui prend en compte la signature fictive Sig_B0 et les différents identifiants et signatures présents dans le bloc B1, et qui produit en résultat Sig_B1. Cette signature du bloc B1 est insérée dans le bloc B2.

De façon similaire, quand le bloc B2 comprend un certain nombre de signatures de données, il est procédé à la signature du bloc B2, en appliquant l’opération de signature à la concaténation de la signature Sig_B1 du bloc B1 et des identifiants et signatures de données présents dans le bloc B2. L’opération de signature est également représentée par une accolade et le résultat de cette opération de signature est la signature du bloc B2, dénommée Sig_B2, qui est insérée dans le bloc B3. On a représenté dans la la signature du bloc B3 qui produit de façon similaire le résultat Sig_B3.

Il faut noter que, dans ce mode de réalisation de l’invention, il est impossible de rajouter des signatures de données dans un bloc de données une fois que l’opération de signature du bloc a été effectuée et que le résultat de la signature du bloc a été inséré dans le bloc suivant. En effet, rajouter une nouvelle signature de données dans un bloc déjà signé impliquerait que la signature du bloc devrait être changée.

Ce mode de réalisation de l’invention met en avant l’avantage de l’invention qui permet de préserver l’intégrité de données gérées par l’application. En effet, si un attaquant arrive à modifier une donnée, s’il veut rendre cette modification indétectable, il devra ensuite modifier la signature de la donnée modifiée. Or, cette signature est distribuée, comme nous l’avons vu, à l’ensemble des nœuds du système. Par ailleurs, avec le chaînage des blocs, il ne suffit plus de modifier un seul bloc pour rendre indétectable la modification d’une donnée. En effet, le changement d’une signature de donnée implique qu’il faille ensuite changer la signature du bloc lui-même pour rendre la modification de la donnée indétectable, et donc implique qu’il faille également changer toutes les signatures de blocs qui comprenne la signature modifiée du bloc suite aux opérations de chaînage.

Dans un autre mode de réalisation de l’invention, la signature du bloc est effectuée par l’application au fur et à mesure de l’ajout de signatures de données, et, lorsqu’une quantité déterminée de signatures de données a été inscrite dans le bloc, une dernière opération de signature du bloc est effectuée par l’application, puis le bloc est soumis au nœud principal ou à un des nœuds secondaires.

L’avantage de ce mode de réalisation est qu’il est possible, lors d’une phase d’audit, de vérifier si une signature de données présente dans le bloc a été modifié, en recalculant la signature globale du bloc de données, avant qu’il soit distribué. Une fois que le bloc est distribué, il ne peut plus être modifié et donc sa signature ne doit plus être calculée.

Un autre avantage de ce mode de réalisation est qu’il est possible de faire varier la taille des blocs, et donc la fréquence à laquelle ils vont être soumis par l’application (100) aux nœuds (200, 210). Cela permet d’optimiser la taille des chaînes de blocs, ainsi que la charge de calcul des nœuds (200, 210) et également la charge du réseau de communication (300).

La présente un autre mode de réalisation de l’invention.

Dans ce mode, lorsqu’un nœud principal 200 ou secondaire 210 reçoit un bloc de données dont l’identifiant est Bi, que ce bloc soit soumis par l’application 100 ou par un autre nœud principal 200 ou secondaire 210, le nœud principal 200 ou secondaire 210 va d’abord extraire la signature Sig_Bi-1 du bloc précédent dont l’identifiant est Bi-1, signature présente dans le bloc Bi qui vient d’être soumis. Le nœud principal 200 ou secondaire 210 va également récupérer la signature Sig_Bi-1 à partir du bloc Bi-1 que le nœud principal 200 ou secondaire 210 a précédemment enregistré lors d’une phase précédente d’enregistrement REC. Ces deux signatures Sig_Bi-1 sont comparées par le nœud principal 200 ou secondaire 210, lors d’une première opération de comparaison, ce qui est représenté dans la par un losange présentant l’étiquette « = ?1 ».

Si ces deux signatures Sig_Bi-1 sont bien égales lors de l’opération de comparaison « = ?1 », le nœud principal ou secondaire procède à une seconde opération de comparaison, ce qui est représenté dans la par un losange présentant l’étiquette « = ?2 ».

Lors de cette seconde opération de comparaison, le nœud principal 200 ou secondaire 210 va d’une part extraire la signature Sig_Bi présente dans le bloc Bi qui vient d’être soumis par l’application 100 ou par un nœud principal 200 ou secondaire 210, et d’autre part, refaire l’opération de signature de l’ensemble des identifiants et signatures de données présents dans le bloc Bi qui vient d’être soumis, cette nouvelle opération de signature étant représentée dans la par une accolade située à l’extérieur du bloc et produisant une autre signature Sig_Bi de la concaténation de la signature Sig_Bi-1 et des identifiants et signatures de données présents dans le bloc Bi.

Si ces deux signatures Sig_Bi (à savoir celle extraite du bloc Bi qui vient d’être soumis par l’application 100 ou par un nœud principal 200 ou secondaire 210 et celle qui vient d’être recalculée par le nœud principal 200 ou secondaire 210 à partir de la concaténation de la signature Sig_Bi-1 et des identifiants et signatures de données présents dans le bloc Bi) sont bien égales lors de l’opération de comparaison « = ?2 », le nœud principal 200 ou secondaire 210 va procéder à l’exécution des phases d’enregistrement REC et distribution DIS du bloc Bi qui vient d’être soumis par l’application 100 ou un nœud principal 200 ou secondaire 210, ce qui est représenté dans la par la sortie étiquetée OK du losange «= ?2 ».

Si au contraire, une des deux opérations de comparaison « = ?1 » ou « = ?2 » entre les paires de signature Sig_Bi-1 et Sig_Bi échoue, le nœud principal 200 ou secondaire 210 va refuser de procéder aux phases d’enregistrement REC et de distribution DIS du bloc Bi qui vient de lui être soumis par l’application 100 ou par un nœud principal ou secondaire 210. Ce refus est représenté dans la par les deux sorties étiquetées NOK des losanges « = ?1 » et « = ?2 » qui mènent à une étiquette REF.

L’avantage de ce mode de réalisation est qu’il permet la détection de modifications de données réalisées a posteriori. En effet, si une donnée présente dans le bloc Bi-1 ou le bloc Bi a été modifiée entre la phase d’enregistrement REC du bloc Bi-1 par le nœud principal 200 ou secondaire 210 et la phase de soumission SUB ou de distribution DIS du bloc Bi au même nœud principal 200 ou secondaire 210, la phase de comparaison des deux versions de la signature Sig_Bi-1 va le révéler. De même, si une signature de données a été modifiée dans le bloc Bi entre la phase de production PROD du bloc Bi par l’application 100 et la phase de soumission SUB ou de distribution DIS du bloc Bi au nœud principal 200 ou secondaire 210, la phase de comparaison des deux versions de la signature Sig_Bi va le révéler. De cette manière, les modifications intempestives des blocs sont détectées lors de leurs soumissions SUB ou distributions DIS au nœud principal 200 ou secondaire 210.

La présente un autre mode de réalisation de l’invention.

Dans ce mode de réalisation, l’application 100 peut soumettre une signature de bloc Sig_Bi à un nœud principal 200 ou secondaire 210. Le nœud principal 200 ou secondaire 210 va comparer la signature Sig_Bi enregistrée par le nœud principal 200 ou secondaire 210 à la signature Sig_Bi soumise par l’application 100, ce qui est représenté dans la par le losange étiqueté par « = ? ». Si la comparaison réussit, le nœud principal 200 ou secondaire 210 en prend note en augmentant un compteur OK de 1, ce qui est noté dans la par l’étiquette « OK++ » et si la comparaison échoue, le nœud principal 200 ou secondaire 210 en prend note en augmentant un compteur NOK de 1, ce qui est noté dans la par l’étiquette « NOK++ ». Puis, le nœud principal 200 ou secondaire 210 va diffuser la signature Sig_Bi soumise par l’application 100 aux autres nœuds principaux 200 ou secondaires 210, ce qui est noté dans la par l’étiquette DIS, puis regrouper le résultat des comparaisons effectuées par l’ensemble des nœuds, ce qui est noté dans la par l’étiquette GRP, dans lequel les compteurs OK et NOK sont augmentées de 1 à chaque réponse positive ou négative de la comparaison faite par les nœuds principaux 200 ou secondaires 210. Enfin, le nœud principal 200 ou secondaire 210 auquel l’application 100 a soumis la signature Sig_Bi va fournir en réponse à l’application 100 le résultat des comparaisons, ce qui est noté dans la par l’étiquette ANS.

Ce résultat peut être, dans un mode particulier de réalisation de l’invention, une quantité de nœuds principaux 200 ou secondaires 210 pour lesquels la comparaison a échoué et une quantité pour lesquels elle a réussi.

L’avantage de ces modes de réalisation est là encore de permettre de détecter a posteriori des modifications de données en comparant la signature d’un bloc, qui comprend les signatures de données, avec les signatures du même bloc enregistrées par le nœud principal 200 ou les nœuds secondaires 210. La réponse ANS donnant un nombre de nœuds principaux 200 ou secondaires 210 qui confirment ou infirment la signature permet à l’application 100 de décider de sa réaction suivant toute politique que l’application 100 souhaitera appliquer.

Un autre mode de réalisation de l’invention est également représenté par la . Les phases de ce mode de réalisation de l’invention sont identiques à celui présenté précédemment à la différence que

c’est un utilisateur du système SYS qui va soumettre une signature de bloc Sig_Bi à un nœud principal 200 ou secondaire 210, étant entendu que l’utilisateur interagit avec le système SYS via un terminal utilisateur non représenté sur la , et que
la réponse ANS donnant le résultat des comparaisons est fournie à l’utilisateur du système SYS, par l’intermédiaire d’un terminal utilisateur non représenté dans la .

Ce résultat des comparaisons peut être là encore une quantité de nœuds principaux 200 ou secondaires 210 pour lesquels la comparaison a échoué et une quantité pour lesquels elle a réussi.

L’avantage de ce mode de réalisation est, comme pour le mode précédent, de permettre de détecter a posteriori des modifications de données dont la signature a été intégrée dans un bloc de données. L’avantage supplémentaire de ce mode par rapport au mode précédent est que la possibilité de détection de modification de données est ouverte à tout utilisateur du système SYS et pas seulement à l’application 100. L’utilisateur du système SYS interagit avec celui-ci par tout type de programme, de terminal ou de logiciel adapté qui lui permette de réaliser des requêtes sur les nœuds (200, 210) du système SYS.

Selon un autre mode de réalisation, la signature des données et celle des blocs est réalisée par des fonctions de hachage. Le plus simple est l’application d’une fonction de hachage à la donnée ou aux éléments du bloc, par exemple une parmi les fonctions standardisées MD4, MD5, SHA128, SHA256 ou SHA512, ou toute autre fonction de hachage.

L’avantage de ce mode de réalisation est d’assurer qu’une modification de la donnée ou bien des éléments du bloc pourra ensuite être détecté car il impliquera un changement de la signature de la donnée ou de la signature des éléments du bloc qui la contient.

Signalons enfin ici que, dans le présent texte, le terme « module » peut correspondre aussi bien à un composant logiciel qu’à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d’ordinateur ou de manière plus générale à tout élément d’un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions telles que décrites pour les modules concernés. De la même manière, un composant matériel correspond à tout élément d’un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions pour le module concerné (circuit intégré, carte à puce, carte à mémoire, etc.).

Claims

Procédé de gestion de données par une application (100) dans un système informatique (SYS) comprenant un ensemble de nœuds distribués (200, 210) et connectés entre eux par un réseau de communication (300), ledit procédé étant caractérisé en ce qu’il est composé des phases suivantes :
une phase d’inscription (REG) de l’application auprès d’un des nœuds parmi l’ensemble des nœuds distribués, ce nœud (200) étant dit nœud principal, et de calcul par l’application (100) d’un identifiant unique et d’une adresse de contact ;

une phase de production (PROD) de signatures de données gérées par l’application (100) et de regroupement des signatures associées à des identifiants des données signées dans un bloc de données ;

une phase de soumission (SUB) par l’application (100) au nœud principal (200) auprès duquel elle s’est inscrite d’un bloc regroupant des signatures de données et des identifiants des données signées ;

une phase de distribution (DIS) par le nœud principal (200) à d’autres nœuds (210) parmi l’ensemble des nœuds distribués, ces autres nœuds étant dits nœuds secondaires, du bloc soumis par l’application (100), ce bloc étant étiqueté par l’identifiant unique de l’application (100) dans le système (SYS) et par l’adresse de contact de l’application (100) ;

une phase d’enregistrement (REC) par le nœud principal (200) et par les nœuds secondaires (210) du bloc distribué par le nœud principal (200) et de son étiquetage avec l’identifiant unique et l’adresse de contact de l’application (100).
Procédé de gestion selon la revendication 1, caractérisé en ce que les étapes b) à e) sont exécutées dès que l’application (100) gère de nouvelles données.
Procédé de gestion selon la revendication 1, caractérisé en ce qu’un bloc produit par l’application (100) comprend, en plus des signatures de données et des identifiants de données signées, d’une part une signature du bloc précédemment produit par l’application (100), le premier bloc produit par l’application (100) comprenant une signature d’un bloc fictif, et d’autre part une signature de l’ensemble des éléments du bloc.
Procédé de gestion selon les revendications 1 et 3, caractérisé en ce que la signature du bloc est effectuée par l’application (100) au fur et à mesure de l’ajout de signatures de données, et, lorsqu’une quantité déterminée de signatures de données a été inscrite dans le bloc, une dernière opération de signature du bloc est effectuée par l’application (100), puis le bloc est soumis (SUB) par l’application (100) au nœud principal (200).
Procédé de gestion selon la revendication 1, caractérisé en ce que les nœuds secondaires (210) distribuent à d’autres nœuds les blocs reçus par eux jusqu’à ce que l’ensemble des nœuds accessibles du système aient tous reçu le bloc distribué initialement par le nœud principal (200).
Procédé de gestion selon les revendications 1 et 4, caractérisé en ce que l’application (100) soumet un bloc à un nœud secondaire (210), ledit bloc étant différent de celui initialement soumis au nœud principal (200).
Procédé de gestion selon les revendications 1 à 6, caractérisé en ce que suite à la réception d’un bloc, les nœuds, qu’ils soient principal (200) ou secondaire (210), d’une part comparent la signature du bloc précédent qu’ils ont enregistré avec la signature du bloc précédent qui est comprise dans le bloc reçu, d’autre part calculent la signature de l’ensemble des éléments du bloc et la comparent avec la signature de l’ensemble des éléments du bloc qui est comprise dans le bloc reçu, et refusent d’enregistrer et de transmettre le bloc soumis si les deux paires de signatures ne correspondent pas.
Procédé de gestion selon les revendications 1 à 6, caractérisé en ce que l’application (100) soumet une signature de bloc à un nœud, dit nœud initial, qu’il soit principal (200) ou secondaire (210), en ce que le nœud initial compare la signature enregistrée par le nœud initial à la signature soumise par l’application (100), en ce que le nœud initial diffuse la signature soumise par l’application (100) aux autres nœuds (200, 210) et recueille le résultat des comparaisons effectuées par l’ensemble des nœuds (200, 210), et en ce que le nœud initial transmet à l’application le résultat des comparaisons.
Procédé de gestion selon les revendications 1 à 6, caractérisé en ce qu’un utilisateur du système (SYS) soumet une signature de bloc, l’identifiant du bloc et l’identifiant de l’application (100) à un nœud, dit nœud initial, qu’il soit principal (200) ou secondaire (210), en ce que le nœud initial compare la signature enregistrée par le nœud initial à la signature soumise par l’utilisateur, en ce que le nœud initial diffuse la signature soumise par l’utilisateur avec l’identifiant du bloc et celui de l’application (100) aux autres nœuds (200, 210) et recueille le résultat des comparaisons effectuées par l’ensemble des nœuds (200, 210), et en ce que le nœud initial transmet à l’utilisateur du système (SYS) le résultat des comparaisons.
Procédé selon les revendications 8 ou 9, caractérisé en ce que le résultat des comparaisons que le nœud initial transmet à l’application (100) ou à l’utilisateur du système (SYS) comprend une quantité de nœuds pour lesquels la comparaison a échoué et une quantité pour lesquels elle a réussi.
Procédé selon les revendications 1 à 10, caractérisé en ce que la signature des données et celle des blocs sont réalisées par des fonctions de hachage.
Système informatique (SYS) comprenant au moins une application (100) s’exécutant sur un serveur et des nœuds distribués (200, 210), s’exécutant sur des serveurs, connectés entre eux par un réseau de communication (300), système caractérisé en ce que l’application (100) comprend :
un module (101) permettant l’inscription de l’application (100) auprès d’un des nœuds du système, ce nœud (200) étant dit nœud principal ;

un module de production (102) d’une signature des données gérées par l’application (100) et de regroupement de ces signatures, associées à des identifiants des données signées, dans des blocs ;

un module de soumission (103) au nœud principal (200) des blocs regroupant les signatures des données, et les identifiants des données signées ;
et caractérisé en ce qu’un nœud (200) comprend :
un module de distribution (202) aux autres nœuds (210) des blocs regroupant les signatures de données gérées par les applications (100) ;

un module d’enregistrement (201) des blocs regroupant les signatures de données soumis par l’application (100) ou distribués par les autres nœuds (210).
Programme d'ordinateur apte à être mis en œuvre par un serveur, le programme comprenant des instructions de code qui, lorsqu’il est exécuté par un processeur, réalise les étapes du procédé de gestion mises en œuvre par l’application (100) dans les revendications 1, 2, 3, 4 et 6.
Programme d’ordinateur apte à être mis en œuvre par un serveur, le programme comprenant des instructions de code qui, lorsqu’il est exécuté par un processeur, réalise les étapes du procédé de gestion mises en œuvre par un nœud principal (200) ou secondaire (210) dans les revendications 1, 5, 7, 8, 9 et 10.
Support de données, sur lequel est enregistré un programme d’ordinateur comprenant une séquence d’instructions pour la mise en œuvre du procédé de gestion par l’application (100) conforme aux revendications 1, 2, 3, 4 et 6, lorsqu’il est chargé dans et exécuté par un processeur.
Support de données, sur lequel est enregistré un programme d’ordinateur comprenant une séquence d’instructions pour la mise en œuvre du procédé de gestion par un nœud principal (200) ou secondaire (210) conforme aux revendications 1, 5, 7, 8, 9 et 10, lorsqu’il est chargé dans et exécuté par un processeur.