FR3128040A1

FR3128040A1 - Application de sécurité pour un dispositif informatique, système de sécurité et architecture de sécurité correspondante

Info

Publication number: FR3128040A1
Application number: FR2110521A
Authority: FR
Inventors: Jean-Louis Olie
Original assignee: Cyferall
Current assignee: Cyferall
Priority date: 2021-10-08
Filing date: 2021-10-08
Publication date: 2023-04-14
Anticipated expiration: 2041-10-08
Also published as: US20240356747A1; EP4413479A1; WO2023057652A1; FR3128040B1

Abstract

La présente invention concerne un système de sécurité (100) pour des dispositifs informatiques (150), le système de sécurité étant adapté pour : - permettre à une application de sécurité (104) de définir une enclave de la mémoire vive (RAM) à laquelle seule l’application de sécurité (104) peut avoir accès, cette enclave étant éventuellement située au sein d’un zone protégée plus large résultant de la mise en œuvre d’une machine virtuelle capable d’abriter des logiciels tiers devant coopérer avec les services sécurisés et les pilotes des périphériques de création et de restitution de l’information ; et - exploiter cette application de sécurité (104) sur la machine physique ou sur la machine virtuelle, dans laquelle l'application de sécurité contrôle l'accès à l’enclave et l’utilise pour y stocker les données en clair à protéger. Figure de l’abrégé : [Fig. 3 ]

Description

Application de sécurité pour un dispositif informatique, système de sécurité et architecture de sécurité correspondante

Cette invention concerne un système de sécurité pour un ou des dispositifs informatiques, une application de sécurité, un point de décision de politique de sécurité, et une architecture de sécurité comprenant l'application de sécurité, le point de décision de politique de sécurité et un serveur de routage des échanges de données chiffrées.

Le National Institute of Standards and Technology (NIST) a promu une architecture de réseau qu'il appelle "Zero Trust". L'objectif de la confiance zéro est de fournir des conseils à l'industrie sur la manière de configurer une architecture de réseau capable de résister aux intrusions non autorisées et aux cyber-attaques. La notion de confiance zéro vient de l'idée que, traditionnellement, on peut faire confiance aux utilisateurs qui se trouvent dans un réseau privé parce qu'ils ont été authentifiés, mais dans un modèle de confiance zéro, même les utilisateurs qui se déplacent dans un réseau privé ne sont pas considérés comme des "entités de confiance" et sont soumis aux mêmes vérifications que les "étrangers".

Selon la publication spéciale 800-207 Zero-Trust Architecture du NIST, l'un des composants fondamentaux d'une telle architecture est le « Policy Enforcement Point », où l'accès de la zone non fiable à la zone fiable est contrôlé selon des règles strictement définies. Lorsque l'on applique cette architecture à un ensemble de plusieurs dispositifs informatiques distants entre eux, chacun de ces dispositifs pouvant expédier ou recevoir des données chiffrées, ce « Policy Enforcement Point » doit être physiquement divisé en plusieurs composants : (i) plusieurs points d'application de la politique de sécurité (PAPS) dans chacun des dispositifs informatiques, et (ii) un serveur de routage (SR) gérant l'acheminement des informations chiffrées vers les destinataires authentifiés. Un autre composant indispensable d'une telle architecture est le point de décision de la politique de sécurité (PDPS). Il comprendra deux sous-composants, qui ne se trouveront pas nécessairement dans le même ordinateur : (i) le moteur de politique de sécurité qui prend la décision d'accorder l'accès aux utilisateurs, et (ii) l'administrateur de politique de sécurité qui exécute la décision du moteur de politique de sécurité par le biais de commandes envoyées aux PAPS via le SR.

La présente invention a pour but de remédier à un ou plusieurs des inconvénients associés à l'art antérieur.

Conformément aux présentes inventions, il est prévu une application de sécurité pour un dispositif informatique, ladite application étant adaptée pour :

donner à un utilisateur du dispositif informatique sur lequel est installé ladite application de sécurité, accès à un ensemble de services sécurisés dans lesquels sont échangées des données chiffrées avec d’autres applications de sécurité installées sur d’autres dispositif informatiques distants ;
disposer d’une zone sécurisée de la RAM à laquelle seule l’application de sécurité peut avoir accès, l’enclave ;
être dotée d’un processus d’initialisation permettant notamment de recueillir des données d’identification de l’utilisateur qui ne quittent jamais l’enclave avant d’être détruites et de mettre en place des clés nécessaires au chiffrement des données échangées ;
être dotée d’un processus de connexion permettant de vérifier les données d’identification lors des utilisations de l’application de sécurité ultérieures à l’initialisation, sans que ces données d’identification ne quittent l’enclave avant d’être détruites, une vérification étant le préalable pour que l’utilisateur du dispositif informatique puisse accéder aux services sécurisés ;
calculer, à partir des données d’identification, lors de l’initialisation une première fois puis à chaque connexion de façon conforme, dans un processus collaboratif avec un point de décision de politique de sécurité distant, une clé maîtresse qui ne quitte jamais l’enclave avant d’être détruite et qui est indispensable pour que l’application de sécurité puisse accéder aux clés de chiffrement.

La présente invention concerne également un système de sécurité pour des dispositifs informatiques, le système de sécurité étant adapté pour :
- mettre en œuvre une machine virtuelle dans la mémoire vive, RAM, du dispositif informatique de telle sorte qu'une partie de la RAM est attribuée à la machine virtuelle, dans laquelle la partie attribuée de la RAM définit une zone sécurisée et de telle sorte que la machine virtuelle attribue à son tour ladite application de sécurité précédemment décrite, une partie de la RAM, cette dernière partie de RAM définissant une enclave ; et
- exploiter cette application de sécurité sur la machine virtuelle, dans laquelle l'application de sécurité contrôle l'accès à l’enclave.
Avantageusement, le système de sécurité est adapté pour :
- mettre en œuvre une machine physique attribuant à l’application de sécurité précédemment décrite, une partie de la RAM, cette partie de la RAM attribuée définissant une zone sécurisée, l’enclave ; et
- exploiter cette application de sécurité sur la machine physique, dans laquelle l’application de sécurité contrôle l’accès à l’enclave.
Selon une caractéristique, l’enclave est utilisée pour le stockage de données non chiffrées avant le chiffrement ou après le déchiffrement.
En outre, l’enclave est aussi utilisée pour stocker des clés de chiffrement si ces dernières doivent être gardées confidentielles.et est aussi utilisée pour mettre en œuvre l'application de sécurité.
Avantageusement, la machine virtuelle est implémentée et comprend des pilotes pour des dispositifs périphériques du dispositif informatique, où les dispositifs périphériques sont utilisés pour traiter des données non chiffrées.
En outre, la machine virtuelle est implémentée et comprend un ou des logiciels tiers pour traiter des données non chiffrées.
Selon une caractéristique, l'application de sécurité est adaptée pour mettre en œuvre un point d'application de politique de sécurité.
Également, l'application de sécurité est adaptée pour vérifier que toute donnée entrant ou sortant de l’enclave est chiffrée et si nécessaire signée d'une manière prédéterminée.
En outre, un algorithme (CD) de chiffrement a été défini pour chiffrer les données confidentielles.
Plus précisément, deux algorithmes de chiffrement asymétriques ont été définis, un premier algorithme (CASY) pour chiffrer les clés de l’algorithme CD ou des données d’initialisation et un second algorithme (SASY) pour signer le chiffrement de ces clés ou de ces données ; ainsi que deux algorithmes d’initialisation des paires (clé publique, clé privée) sont également associés aux chiffrements asymétriques, un troisième algorithme (CIN) pour CASY et un quatrième algorithme (SIN) pour SASY. Les algorithmes CIN et SIN peuvent éventuellement être décomposés en deux parties, CIN1 et CIN2 pour le premier, SIN1 et SIN2 pour le second.
Avantageusement, l'application de sécurité est adaptée pour communiquer avec un point de décision de la politique de sécurité (PDPS) distant par l’intermédiaire d’un serveur de routage (SR) sous le contrôle du PDPS., l'application de sécurité étant adaptée pour mettre œuvre les algorithmes CD, CASY, CIN, SASY et SIN.
L’invention concerne également une architecture de sécurité comprenant le système de sécurité précédemment décrit et les serveurs PDPS et SR distants, dans laquelle chaque dispositif informatique reçoit un numéro d'utilisateur unique et les clés publiques des algorithmes CASY et SASY du PDPS en provenance du serveur SR distant.
Avantageusement, dans cette architecture de sécurité, le processus d’initialisation de l'application de sécurité reçoit d’un utilisateur un mot de passe, pwd, ou des données d’identification pouvant se condenser en une donnée unique pwd, lui applique une fonction de hachage à sens unique, H, et stocke le résultat du hachage, H(pwd), dans l’enclave.
En outre, dans cette architecture de sécurité, l'application de sécurité est adaptée dans ce cas pour faire en sorte qu'une demande d’initialisation définie comme la version chiffrée de la concaténation d'une clé pseudo-aléatoire, M, d'une certaine longueur binaire, du numéro d'utilisateur unique, et d'une valeur h étant la version hachée du mot de passe haché, où h = H(H(pwd)) soit transmise au PDPS distant via le SR, dans laquelle cette concaténation est chiffrée en utilisant la clé de chiffrement publique de l’algorithme CASY du PDPS.
Avantageusement, dans cette architecture de sécurité, à réception d’une demande d’initialisation en provenance d’une application de sécurité, le PDPS crée une valeur secrète s, et la stocke conjointement avec la valeur reçue pour h et le numéro d'utilisateur unique.
En outre, dans cette architecture de sécurité, le serveur PDPS est adapté pour

créer des données d'initialisation, vides si les algorithmes CIN et SIN ne sont pas décomposés en deux parties et comprenant les données de sortie des algorithmes CIN1 et SIN1 dans le cas contraire ; chiffrer les données d'initialisation concaténées à la valeur secrète s à l'aide d'un chiffrement symétrique utilisant la clé M ; et
transmettre le résultat chiffré à l'application de sécurité à l’origine de la demande via SR.

Également, dans cette architecture de sécurité, à la réception des données d'initialisation chiffrées, l'application de sécurité est adaptée pour déchiffrer les données d'initialisation et la valeur s à l’aide d’un chiffrement symétrique en utilisant la clé M et générer les deux paires de clés publique-privée des algorithmes CASY et SASY en utilisant une valeur secrète t, inconnue du PDPS, comme donnée d’entrée des algorithmes CIN et SIN si les données d’initialisation sont vides et cette valeur secrète t conjointement avec les données d’initialisation comme donnés d’entrée des algorithmes CIN2 et SIN2 dans le cas contraire. L’application de sécurité est également adaptée pour transmettre au SR les deux clés publiques des algorithmes CASY et SASY ainsi calculées.
Avantageusement, dans cette architecture de sécurité, l'application de sécurité calcule une clé maîtresse basée sur la valeur secrète s, et la version hachée du mot de passe H(pwd).
Précisément, dans cette architecture de sécurité, la clé maîtresse est calculée selon H(s ^ H(pwd)) et un témoin T est calculé selon H(s ^ H(s ^ H(pwd))) et stocké sur le disque dur local pour réutilisation ultérieure où H est la fonction de hachage à sens unique, s est la valeur secrète, et ^ est une opération OU exclusif (XOR).
Également, dans cette architecture de sécurité, l'application de sécurité est adaptée pour utiliser la clé maîtresse pour chiffrer des données confidentielles et des clés de chiffrement de l’algorithme CD, pour un stockage sur le disque dur.
Également, dans cette architecture de sécurité, le processus de connexion de l'application de sécurité est adapté pour vérifier l'identité de l'utilisateur lors d’une nouvelle connexion selon le processus suivant :

recevoir un mot de passe de connexion, lgpwd, de l'utilisateur ;
calculer une fonction de hachage, H, du mot de passe de connexion, lgpwd, ou des données d’identification condensées en une donnée unique lgpwd, H(lgpwd), puis calculer une valeur lgh à partir d'une fonction de hachage du résultat, de sorte que lgh=H(H(lgpwd)) ;
obtenir une valeur pseudo-aléatoire D, d'une certaine longueur de bits ;
calculer une valeur S, où S = H(M ^ lgh) ; en concaténant le numéro d'utilisateur unique, et les valeurs D, M, et S ;

en chiffrant la concaténation avec la clé publique de l’algorithme CASY du PDPS ; et

faire en sorte que la concaténation chiffrée soit transmise au PDPS comme une demande de connexion, via le SR.

En outre, dans cette architecture de sécurité, le PDPS est adapté pour qu’à réception de la demande de connexion, ce PDPS puisse :

déchiffrer cette demande de connexion en utilisant sa clé privée de l’algorithme CASY ;
vérifier le numéro d'utilisateur unique ;
si le numéro d'utilisateur unique est valide, vérifier que la valeur reçue S satisfait l'égalité S = H(M ^ h) ;
si S est vérifié, chiffrer la valeur secrète s à l'aide d'un chiffrement symétrique en utilisant la clé M, la concaténer avec le résultat du chiffrement de D avec l’algorithme CASY en utilisant la clé publique de l'application de sécurité à l’origine de la demande de connexion et transmettre cette concaténation à cette application, où une valeur vide si une des vérifications a échoué, via SR ;

Également, dans cette architecture de sécurité, l’application de sécurité est adaptée pour permettre, à réception de la concaténation en réponse à une demande de connexion, de :

vérifier que cette concaténation provient bien du PDPS en vérifiant que le déchiffrement de la seconde partie de la concaténation en utilisant sa clé privée de l’algorithme CASY redonne bien la valeur D ;
déchiffrer la première partie de la concaténation avec l’algorithme symétrique et la clé M, le résultat de cette opération étant s ;
recalculer la clé maîtresse comme étant égale à H(s ^ H(lgpwd)) ;
vérifier que H(s ^ H(s ^ H(lgpwd))) est bien égale à la valeur témoin T stockée lors de l’initialisation
autoriser l’utilisation des services sécurisés du dispositif informatique concerné si la concaténation n’est pas vide, si elle provient bien du PDPS et si la valeur du témoin a bien été retrouvée.

Avantageusement, dans une architecture de sécurité ainsi dotée des processus d’initialisation et de connexion tels que décrits, l’autorisation d’accès aux services sécurisés ne peut pas être forcée par une modification du code de l’application de sécurité qui rendrait par exemple la vérification du témoin T toujours positive. Ce témoin n’est qu’une indication pour l’utilisateur pour lui signifier que le mot de passe est correct ou non. Si le mot de passe est incorrect, la valeur calculée de la clé maîtresse est nécessairement erronée et les clés de chiffrement le l’algorithme CD et les clés privées des algorithme CASY et SASY ne pourront pas être déchiffrées, rendant ainsi impossible l’utilisation des services sécurisés, même si la reconnaissance du témoin a été forcée à positive.
Également, dans cette architecture de sécurité, le PDPS distant est adapté pour mettre en œuvre les fonctions d’un point de décision de politique de sécurité, comprenant un moteur de politique de sécurité et un administrateur de politique de sécurité.
Avantageusement, dans cette architecture de sécurité, le SR distant est adapté pour effectuer les opérations de routage en tenant les données chiffrées à disposition des destinataires pendant une certaine période de temps, tenir les clés publiques des algorithmes CASY et SASY du PDPS et des applications de sécurité initialisées à la disposition de toute application de sécurité ou du PDPS qui en ferait la demande et agir sous le contrôle du PDPS qui peut lui interdire de router certains échanges en application de la politique de sécurité.

Dans le cadre de la présente demande, il est expressément prévu que les divers aspects, modes de réalisation, exemples et variantes exposés dans les paragraphes précédents, dans les revendications et/ou dans la description et les dessins qui suivent, et en particulier les caractéristiques individuelles de ceux-ci, peuvent être pris indépendamment ou en toute combinaison. C'est-à-dire que tous les modes de réalisation et/ou les caractéristiques de tout mode de réalisation peuvent être combinés de n'importe quelle manière et/ou combinaison, à moins que ces caractéristiques ne soient incompatibles. Le demandeur se réserve le droit de modifier toute revendication déposée à l'origine ou de déposer toute nouvelle revendication en conséquence, y compris le droit de modifier toute revendication déposée à l'origine pour dépendre de et/ou incorporer toute caractéristique de toute autre revendication bien qu'elle n'ait pas été revendiquée à l'origine de cette manière.

BRÈVE DESCRIPTION DES FIGURES

Des modes de réalisation de l'invention sont décrits ci-après en référence aux dessins annexés, dans lesquels :
est un schéma fonctionnel d'un exemple de système de sécurité selon l’invention ;
est un schéma fonctionnel d'un exemple de dispositif informatique exploitant un système de sécurité selon l’invention ;
est un schéma fonctionnel d'un autre exemple de dispositif informatique exploitant un système de sécurité selon l’invention ;
est un schéma fonctionnel d'un autre exemple de dispositif informatique exploitant un système de sécurité selon l’invention ;
est un schéma fonctionnel d'un exemple d'architecture de sécurité selon l’invention ;
est un schéma fonctionnel d'un autre exemple d'architecture de sécurité selon l’invention ;
est un schéma fonctionnel illustrant l'architecture de sécurité selon l’invention.

Claims

Application de sécurité (104) pour un dispositif informatique (150), caractérisé en ce que ladite application est adaptée pour :
donner à un utilisateur du dispositif informatique sur lequel est installé ladite application de sécurité, accès à un ensemble de services sécurisé dans lesquels sont échangées des données chiffrées avec d’autres applications de sécurité installées sur d’autres dispositif informatiques distants ;

disposer d’une zone sécurisée dans une mémoire vive (RAM) dudit dispositif informatique, zone sécurisée à laquelle seule l’application de sécurité peut avoir accès, l’enclave ;

être dotée d’un processus d’initialisation permettant notamment de recueillir des données d’identification de l’utilisateur qui ne quittent jamais l’enclave avant d’être détruites et de mettre en place des clés nécessaires au chiffrement des données échangées ;

être dotée d’un processus de connexion permettant de vérifier les données d’identification lors des utilisations de l’application de sécurité ultérieures à l’initialisation, sans que ces données d’identification ne quittent l’enclave avant d’être détruites, une vérification étant le préalable pour que l’utilisateur du dispositif informatique puisse accéder aux services sécurisés ;

calculer, à partir des données d’identification, lors de l’initialisation une première fois puis à chaque connexion de façon conforme, dans un processus collaboratif avec un point de décision de politique de sécurité distant, une clé maîtresse qui ne quitte jamais l’enclave avant d’être détruite et qui est indispensable pour que l’application de sécurité puisse accéder aux clés de chiffrement.
Un système de sécurité (100) pour des dispositifs informatiques, le système de sécurité étant adapté pour :
- mettre en œuvre une machine virtuelle dans la mémoire vive (RAM) du dispositif informatique de telle sorte qu'une partie de la mémoire vive (RAM) est attribuée à la machine virtuelle, dans laquelle la partie attribuée de la mémoire vive (RAM) définit une zone sécurisée et de telle sorte que la machine virtuelle attribue à son tour à une application de sécurité selon la revendication 1, une partie de la mémoire vive (RAM), cette dernière partie de la mémoire vive (RAM) définissant une enclave ; et
- exploiter cette application de sécurité sur la machine virtuelle, dans laquelle l'application de sécurité contrôle l'accès à l’enclave.
Un système de sécurité pour des dispositifs informatiques, le système de sécurité étant adapté pour :
- mettre en œuvre une machine physique (102b) attribuant à une application de sécurité selon la revendication 1, une partie de la mémoire vive (RAM), cette partie de la mémoire vive (RAM) attribuée définissant une zone sécurisée, l’enclave ; et
- exploiter cette application de sécurité sur la machine physique (102b), dans laquelle l’application de sécurité contrôle l’accès à l’enclave.
Système de sécurité selon les revendications 2 ou 3, dans lequel l’enclave est utilisée pour le stockage de données non chiffrées avant le chiffrement ou après le déchiffrement.
Système de sécurité selon la revendication 4, dans lequel l’enclave est aussi utilisée pour stocker des clés de chiffrement si ces dernières doivent être gardées confidentielles.
Système de sécurité selon la revendication 4 ou 5, dans lequel l’enclave est aussi utilisée pour mettre en œuvre l'application de sécurité.
Système de sécurité (100) selon l'une quelconque des revendications 2 à 6, dans lequel la machine virtuelle est implémentée et comprend des pilotes pour des dispositifs périphériques du dispositif informatique, où les dispositifs périphériques sont utilisés pour traiter des données non chiffrées.
Système de sécurité selon l'une quelconque des revendications 2 à 7, dans lequel la machine virtuelle est implémentée et comprend un ou des logiciels tiers pour traiter des données non chiffrées.
Système de sécurité selon l'une quelconque des revendications 2 à 8, dans lequel l'application de sécurité est adaptée pour mettre en œuvre un point d'application de politique de sécurité.
Système de sécurité selon l'une quelconque des revendications 2 à 9, dans lequel l'application de sécurité est adaptée pour vérifier que toute donnée entrant ou sortant de l’enclave est chiffrée et si nécessaire signée d'une manière prédéterminée.
Système de sécurité selon la revendication 10, dans lequel un algorithme (CD) de chiffrement a été défini pour chiffrer les données confidentielles.
Système de sécurité selon la revendication 11, dans lequel
- deux algorithmes de chiffrement asymétriques ont été définis, un premier algorithme (CASY) pour chiffrer les clés de l’algorithme (CD) ou des données d’initialisation et un second algorithme (SASY) pour signer le chiffrement de ces clés ou de ces données ;
- deux algorithmes d’initialisation de paires de clés sont également associés aux chiffrements asymétriques, un troisième algorithme (CIN) associé au premier algorithme (CASY) et un quatrième algorithme (SIN) associé au second algorithme (SASY) ;
les troisième et quatrième algorithmes (CIN ; SIN) pouvant être décomposés en deux parties, (CIN1, CIN2) pour le troisième algorithme, (SIN1, SIN2) pour le quatrième algorithme.
Système de sécurité selon l'une quelconque des revendications 2 à 12, dans lequel l'application de sécurité est adaptée pour communiquer avec un point de décision de la politique de sécurité (PDPS) distant par l’intermédiaire d’un serveur de routage (SR) sous le contrôle du point de décision de la politique de sécurité (PDPS)
Système de sécurité selon la revendication 13, dans lequel l'application de sécurité est adaptée pour mettre œuvre l’algorithme de chiffrement (CD), les algorithmes de chiffrement asymétriques (CASY ; SASY) et les algorithmes d’initialisation de paires de clés (CIN ; SIN)
Architecture de sécurité selon l’une quelconque des revendications 2 à 14 comprenant le système de sécurité et les serveurs point de décision de la politique de sécurité et de routage (PDPS ; SR) distants.
Architecture de sécurité selon la revendication 15, dans laquelle chaque dispositif informatique reçoit un numéro d'utilisateur unique et les clés publiques des algorithmes de chiffrement asymétriques (CASY ; SASY) du PDPS en provenance du serveur de routage (SR) distant.
Architecture de sécurité selon la revendication 16, dans laquelle un processus d’initialisation de l'application de sécurité :
reçoit d’un utilisateur un mot de passe (pwd) ou des données d’identification pouvant se condenser en une donnée unique (pwd),

lui applique une fonction de hachage à sens unique (H) ;

et stocke le résultat du hachage (H(pwd)) dans l’enclave.
Architecture de sécurité selon la revendication 17, dans laquelle l'application de sécurité est adaptée pour faire en sorte qu'une demande d’initialisation définie comme la version chiffrée de la concaténation d'une clé pseudo-aléatoire (M) d'une certaine longueur binaire, du numéro d'utilisateur unique, et d'une valeur (h) correspondant à la version hachée du mot de passe haché, et définie par h = H(H(pwd)), ladite valeur (h) étant transmise au PDPS distant via le serveur de routage (SR), dans laquelle cette concaténation est chiffrée en utilisant la clé de chiffrement publique de l’algorithme de chiffrement asymétrique (CASY) du PDPS.
Architecture de sécurité selon la revendication 18, dans laquelle, à réception d’une demande d’initialisation en provenance d’une application de sécurité, le PDPS crée une valeur secrète (s), et la stocke conjointement avec la valeur reçue pour (h) et le numéro d'utilisateur unique.
Architecture de sécurité selon la revendication 19, dans laquelle le point de décision de la politique de sécurité (PDPS) est adapté pour :
créer des données d'initialisation qui sont vides si les algorithmes d’initialisation de paires de clés (CIN ; SIN) ne sont pas décomposés en deux parties ou bien qui comprennent les données de sortie des algorithmes (CIN1 ; SIN1 dans le cas contraire ;

chiffrer les données d'initialisation concaténées à la valeur secrète (s) à l'aide d'un chiffrement de type symétrique utilisant la clé M ; et

transmettre le résultat chiffré à l'application de sécurité à l’origine de la demande via le serveur de routage (SR).
Architecture de sécurité selon la revendication 20, dans laquelle, à la réception des données d'initialisation chiffrées, l'application de sécurité est adaptée pour déchiffrer les données d'initialisation et la valeur (s) à l’aide du chiffrement (symétrique) en utilisant la clé (M) et générer les deux paires de clés publique-privée des algorithmes de chiffrement asymétrique (CASY ; SASY) en utilisant une valeur secrète (t), inconnue du point de décision de la politique de sécurité (PDPS), comme donnée d’entrée des algorithmes d’initialisation de paires de clés (CIN ; SIN) si les données d’initialisation sont vides ; et cette valeur secrète (t) conjointement avec les données d’initialisation comme donnés d’entrée des algorithmes (CIN2 ; SIN2) dans le cas contraire, l’application de sécurité étant également adaptée pour transmettre au serveur de routage (SR) les deux clés publiques des algorithmes de chiffrement asymétrique (CASY ; SASY)
Architecture de sécurité selon la revendication 21, dans laquelle l'application de sécurité calcule une clé maîtresse basée sur la valeur secrète (s), et la version hachée du mot de passe H(pwd).
Architecture de sécurité selon la revendication 22, dans laquelle la clé maîtresse est calculée selon H(s ^ H(pwd)) et un témoin T est calculé selon H(s ^ H(s ^ H(pwd))) et stocké sur le disque dur local pour réutilisation ultérieure où H est la fonction de hachage à sens unique, s est la valeur secrète, et ^ est une opération OU exclusif (XOR).
Architecture de sécurité selon l'une quelconque des revendications 15 à 23, dans laquelle l'application de sécurité est adaptée pour utiliser la clé maîtresse pour chiffrer des données confidentielles et des clés de chiffrement de l’algorithme (CD), pour un stockage sur le disque dur, rendant ainsi impossible l’accès à ces données confidentielles et à ces clés si le calcul de la clé maîtresse est erroné.
Architecture de sécurité selon l'une quelconque des revendications 15 à 24, dans laquelle le processus de connexion de l'application de sécurité est adaptée pour vérifier l'identité de l'utilisateur lors d’une nouvelle connexion :
recevoir un mot de passe de connexion (lgpwd) de l'utilisateur ;

calculer une fonction de hachage (H) du mot de passe de connexion, (lgpwd), ou des données d’identification condensées en une donnée unique lgpwd, H(lgpwd), puis calculer une valeur (lgh) à partir d'une fonction de hachage du résultat, de sorte que lgh=H(H(lgpwd)) ;

obtenir une valeur pseudo-aléatoire (D), d'une certaine longueur de bits ;

calculer une valeur (S), où S = H(M ^ lgh) ;

en concaténant le numéro d'utilisateur unique, et les valeurs D, M, et S ;

en chiffrant la concaténation avec la clé publique de l’algorithme de chiffrement asymétrique (CASY) du point de décision de la politique de sécurité (PDPS) ; et

faire en sorte que la concaténation chiffrée soit transmise au point de décision de la politique de sécurité (PDPS) comme une demande de connexion, via le serveur de routage (SR).
Architecture de sécurité selon la revendication 25, dans laquelle, le point de décision de la politique de sécurité (PDPS) est adapté pour qu’à réception de la demande de connexion, ce point de décision de la politique de sécurité (PDPS) puisse :
déchiffrer cette demande de connexion en utilisant sa clé privée de l’algorithme de chiffrement asymétrique (CASY) ;

vérifier le numéro d'utilisateur unique ;

si le numéro d'utilisateur unique est valide, vérifier que la valeur reçue S satisfait l'égalité S = H(M ^ h) ; et

si S est vérifié, chiffrer la valeur secrète s à l'aide d'un chiffrement symétrique en utilisant la clé (M), la concaténer avec le résultat du chiffrement de (D) avec l’algorithme de chiffrement asymétrique (CASY) en utilisant la clé publique de l'application de sécurité à l’origine de la demande de connexion ;

et transmettre, via le serveur de routage (SR) cette concaténation à cette application ou une valeur vide si une des vérifications a échoué.
Architecture de sécurité selon la revendication 26, dans laquelle l’application de sécurité est adaptée pour permettre, à réception de la concaténation en réponse à une demande de connexion, de :
vérifier que cette concaténation provient bien du point de décision de la politique de sécurité (PDPS) en vérifiant que le déchiffrement de la seconde partie de la concaténation en utilisant sa clé privée de l’algorithme de chiffrement asymétrique (CASY) redonne bien la valeur D ;

déchiffrer la première partie de la concaténation avec l’algorithme symétrique et la clé M, le résultat de cette opération étant s ;

recalculer la clé maîtresse comme étant égale à H(s ^ H(lgpwd)) ;

vérifier que H(s ^ H(s ^ H(lgpwd))) est bien égale à la valeur témoin T stockée lors de l’initialisation ;

autoriser l’utilisation des services sécurisés du dispositif informatique concerné si la concaténation n’est pas vide, si elle provient bien du point de décision de la politique de sécurité (PDPS) et si la valeur du témoin a bien été retrouvée.
Architecture de sécurité selon l'une quelconque des revendications 15 à 27, dans laquelle le point de décision de la politique de sécurité (PDPS) distant est adapté pour mettre en œuvre les fonctions d’un point de décision de politique de sécurité, comprenant un moteur de politique de sécurité et un administrateur de politique de sécurité.
Architecture de sécurité selon la revendication 28, dans laquelle le serveur de routage (SR) distant est adapté pour effectuer les opérations de routage en tenant les données chiffrées à disposition des destinataires pendant une certaine période de temps, tenir les clés publiques des algorithmes de chiffrement asymétrique (CASY ; SASY) du point de décision de la politique de sécurité (PDPS) et des applications de sécurité initialisées à la disposition de toute application de sécurité ou du point de décision de la politique de sécurité (PDPS) qui en ferait la demande et agir sous le contrôle du point de décision de la politique de sécurité (PDPS) qui peut lui interdire de router certains échanges en application de la politique de sécurité.