Brevet FR2916592A1 — publié le 20081128

Procédé de sécurisation d'échange d'information, dispositif, et produit programme d'ordinateur correspondant. 1 DOMAINE DE L'INVENTION La présente invention se rapporte au domaine de la gestion des échanges d'informations réalisées entre deux entités d'un réseau de communication. Plus particulièrement, la présente invention se rapporte à la sécurisation de tels échanges. De nombreuses applications, notamment de commerce ou d'accès à des informations confidentielles, utilisent les protocoles SSL (de l'anglais Secure Socket Layer pour Couche d'encapsulation sécurisée ) ou TLS (de l'anglais Transport Layer Security pour couche de transport sécurisée ) pour échanger des données de manière sécurisée. Bien que des preuves mathématiques existent pour ces protocoles, leur réalisation intégrale par des systèmes informatiques peu sure, permet des attaques qui diminuent la confiance que l'on doit légitimement apporter aux procédures d'échange mettant en oeuvre ces protocoles. 2 SOLUTIONS DE L'ART ANTERIEUR 2.1 Art antérieur La mise en oeuvre d'une connexion sécurisée entre deux entités d'un réseau de communication passe par l'initiation d'une session sécurisée basée soit sur le protocole SSL, soit sur le protocole TLS. Ainsi, pour l'établissement d'une telle session, les deux entités utilisent des mécanismes qui sont censés assurer que la session crée ne pourra pas faire l'objet d'un piratage ou d'un espionnage. On décrit par la suite le fonctionnement des protocoles SSL et TLS. Bien que cette description soit plus particulièrement dédiée au protocole TLS, elle s'applique également au protocole SSL. Le protocole TLS est organisé sur la base d'un ensemble de cinq entités logicielles coopérant entre elles : APPLICATION, HANDSHAKE, CCS, ALERT et RECORD. L'entité APPLICATION fait référence à une application logicielle qui désire mettre en oeuvre une session de communication sécurisée (couche 7 du modèle OSI). Les entités HANDSHAKE , CCS , ALERT et RECORD (également appelées couches) sont des entités qui sont mises en oeuvre dans le cadre d'une application du protocole TLS, dont une description détaillée sera trouvée sous la référence RFC 2246 par l'intermédiaire du comité IETF ( Internet Engineering Task Force pour Groupe de Travail d'Ingénierie de l'Internet ). Une telle application du protocole TLS est réalisée au niveau de la couche 5 du modèle OSI. L'architecture d'une pile TLS peut être décrite ainsi : la couche gérée par l'entité RECORD (également appelée couche RECORD ) transporte les messages produits par les entités APPLICATION HANDSHAKE CCS et ALERT , à l'aide d'un entête de 5 octets qui précise l'entité qui génère le message, la version du protocole TLS utilisé, et la longueur du message. Les messages en tant que tels comportent également un entête qui indique le type du message et la longueur des données associées. Cependant la structure des messages APPLICATION n'est pas définie par le standard TLS. En effet, chaque application échange des messages dont la structure est définie par le protocole applicatif, tel que dans le cadre des messages du protocole HTTPS (de l'anglais Hypertext Transfer Protocol Secured pour protocole de transfert hypertexte sécurisé ). Ainsi, une application APPLICATION utilise les services offerts par le protocole TLS qui réalise la confidentialité (chiffrement) et la confidentialité des données transportées à l'aide du protocole TCP (de l'anglais Transmission Control Protocol pour protocole de contrôle de transmissions ) qui agit au niveau de la couche transport. La mise en oeuvre du canal sécurisé par TLS s'effectue en deux étapes, une phase d'authentification et de calcul de clés, suivie en cas de succès, d'une phase d'usage d'un canal de communication sécurisé, qui utilise le jeu de clés précédemment déterminées. L'entité de la couche HANDSHAKE (également appelée couche HANDSHAKE ) réalise les procédures d'authentification et de calcul des clés. Il existe deux modes d'authentification le mode complet (appelé Full Session ) et un mode rapide (appelé Session Resumption ). Ces deux modes seront plus précisément décrits ultérieurement. La couche HANDSHAKE négocie les algorithmes de chiffrement et d'intégrité mis en oeuvre par l'entité de la couche RECORD (également appelée couche RECORD ), qui sont identifiés par un nombre dénommé cipher_suite . Au terme d'une procédure d'authentification réussie, la couche RECORD détermine une valeur appelée master secret. A l'aide de deux nombres aléatoires produits par l'entité cliente (client_random) et l'entité serveur (server_random) elle calcule un ensemble de clés (le keys_bloc), utilisées pour le chiffrement et l'intégrité des données reçues et émises : keys_block = PRF(master secret, "key expansion"; server random client random); PRF (Pseudo Random Function) est une fonction générant des données pseudo aléatoire; le symbole indique une opération de concaténation. De manière simplifiée le paramètre keys_bloc est un couple de deux paires de clés (KcRx, KiRx) et (KcTx, KiTx) utilisées respectivement pour le chiffrement (préfixe Kc) et l'intégrité (préfixe Ki) des données reçues (suffixe Rx) et émises (suffixe Tx). La couche CCS (Change Cipher Spec) signale à l'entité RECORD les modifications des paramètres de sécurité. Elle active la mise en fonction des procédures de chiffrement et d'intégrité des données, utilisant les paramètres keys_bloc et cipher_suite . L'entité de la couche ALERT (également appelée couche ALERT ) signale des erreurs détectées par l'entité HANDSHAKE (en cas d'échec de l'authentification)., ou par la couche RECORD (détection d'un défaut d'intégrité, ou une fin de session). La couche RECORD assure quatre types d'opérations : une fragmentation des données en blocs dont la taille maximum est de 214 30 octets ; une compression optionnelle des données; ce service n'est généralement pas assuré ; une génération de signatures (basée sur l'algorithme HMAC, défini par la RFC 2104) ; un chiffrement des données. L'ensemble des paramètres nécessaires au fonctionnement de la couche RECORD est dénommé security_parameters et comporte entre autre les valeurs du keys_bloc produit par l'entité HANDSHAKE. Les messages échangés entre la couche application et la couche TCP sont 10 chiffrés et déchiffrés par la couche RECORD à l'aide d'un jeu de deux paires de clés (KcRx, KiRx) et (KcTx, KiTx) préalablement décrit. Les messages reçus par la couche RECORD sont chiffrés par la clé KcRx ({M}KcRx) et muni d'une signature HMAC(KiRx, M) associée à la clé KiRx. Cette dernière vérifie la signature HMAC et restitue la valeur 15 déchiffrée à la couche application. Les messages émis par la couche application sont chiffrés par la couche RECORD à l'aide de la clé KcTx ({M}KcTx) et muni d'une signature HMAC(M, KiTx) associée à la clé KiTx. Lorsque le mode de chiffrement est activé, le fonctionnement de la couche 20 RECORD est le suivant : un MESSAGE émis/reçu par une entité telle que HANDSHAKE ou APPLICATION est muni d'un entête comportant trois paramètres : type, version, longueur. L'ensemble MESSAGE , signature HMAC et octets de bourrage est chiffré à l'aide de l'algorithme négocié durant la phase d'authentification et d'une clé Kc. 25 La signature HMAC est calculée à partir de l'entête, du MESSAGE et d'un numéro de trame (seq_num) (initialisé à la valeur 0 et incrémenté à chaque usage de la couche RECORD ) selon la relation suivante : HMAC (Ki, seq_num 1 Type 1 Version 1 Longueur 1 MESSAGE) Ainsi que cela a été évoqué précédemment, il existe deux modes 30 d'ouverture de session TLS appelés Full Session et Session Resumption . Ainsi, par exemple, dans le cas de l'ouverture d'une session Full Session , utilisant l'algorithme RSA, avec mutuelle authentification ("Client Authentication Handshake"), entre une entité cliente et une entité serveur, l'entité cliente initie cette dernière par un message ClientHello . L'entité serveur répond par un ensemble de messages ServerHello , Certificate , CertificateRequest , ServerHelloDone . L'entité cliente délivre alors les messages Certificate , CertificateVerify , ClientKeyExchange , ChangeCipherSpec , et Finished . Dans cette procédure l'entité cliente vérifie la validité du certificat du serveur, en extrait sa clé publique RSA, puis lui transmet une valeur baptisée pre_master secret chiffrée de cette clé. Le master_secret est calculé partir des éléments Client-Random , Server-Random et pre-master-secret . Le message CertificateVerify contient une signature réalisée avec la clé privée RSA du client, qui prouve l'identité de ce dernier (son certificat présent dans le message Certificate ). Au terme de cette procédure d'authentification l'entité cliente et l'entité serveur disposent d'une nouvelle valeur master_secret à partir de laquelle sont déduites les clés du keys_bloc . Un paramètre SessionlD transmis dans le message ServerHello fournit un index du master_secret . Par la suite les données générées par la couche APPLICATION sont transportées par l'entité RECORD , quai en assure la confidentialité et l'intégrité grâce aux clés Kc et Ki. Dans le cas d'une ouverture d'une session Session Resumption , une procédure précédente Full Session a déjà permis d'obtenir un master_secret identifié par un index SessionlD . La phase d'authentification est simplifiée et consiste pour les deux parties (l'entité cliente et l'entité serveur) à prouver leur connaissance de la valeur master secret . L'entité cliente ouvre la session TLS par un message ClientHello contenant l'index ( SessionlD ) d'une session précédente. L'entité serveur répond par un ensemble de messages ServerHello , ChangeCipherSpec , et Finished . Il indique la reprise de session en insérant une valeur SessionlD dans le message ServerHello identique à celle contenue dans le message ClientHello . L'entité cliente délivre alors les messages ChangeCipherSpec , et Finished . Le master_secret n'est pas recalculé, cependant un nouvel ensemble keys_bloc est obtenu à partir des éléments master_secret , ClientRandom et ServerRandom par l'application de la fonction suivante : Keys_block = PRF(master secret, "key expansion"; server_random client_random). Par la suite les données générées par la couche APPLICATION sont 10 transportées par l'entité RECORD , qui en assure la confidentialité et l'intégrité grâce aux clés Kc et Ki. Le mécanisme de Session Resumption simplifie l'échange d'information lors d'une session TLS. Une première Full Session effectue l'authentification simple ou mutuelle des deux extrémités (client et serveur) et 15 produit un master_secret . Les sessions suivantes, basée sur le mécanisme de Session Resumption réutilisent le master_secret pour le calcul de nouvelles clés de chiffrement et d'intégrité. 2.2 Inconvénients de l'art antérieur Ainsi décrit les mécanismes d'établissement de session TLS, il a été mis 20 en évidence deux étapes pour l'échange d'information sécurisée : une étape d'authentification permettant l'obtention du master_secret et le calcul des clés de session (keys_bloc) ; et une étape de transfert d'informations protégées par la couche RECORD en mode chiffré. 25 Bien que les données applicatives soient échangées entre les entités client et serveur, la phase d'authentification est le processus le plus critique puis qu'il établit l'identité des deux parties, vérifie leurs certificats et calcule les clés cryptographiques. Un inconvénient de cette technique de l'art antérieur est lié au fait que la 30 pile TLS (c'est-à-dire l'enchaînement des étapes menant à l'échange d'informations) est intégralement exécutée sur le même ordinateur et ne permet donc pas de séparer les procédures d'authentification et d'échange d'informations. Il n'y a donc pas d'assurance que l'ordinateur sur lequel est exécutée cette pile TLS soit entièrement sécurisé et qu'une usurpation de clés ne puisse pas se produire durant les phases critiques d'authentification et de transfert d' informations protégées. Or de nombreuses applications, par exemple les réseaux virtuels (VPN) basés sur SSL/TLS, les grilles de calculs, ou les réseaux de type overlays, nécessite des garanties de sécurité particulières, afin d'interdire les usurpations d'identité, c'est-à-dire l'usage illicite de services par des pirates informatiques (ou hackers). Les systèmes d'exploitation complexes des ordinateurs actuels permettent l'exécution de logiciels malveillants tels que chevaux de Troie, vers, virus, capables de collecter les identités et les clés RSA des utilisateurs. Pour pallier ces problèmes, il a été proposé de nombreuses solutions basées notamment sur des cartes à puce ou des dispositifs externes qui contiennent des preuves de l'identité physique de l'utilisateur ou de la machine qui souhaite établir une session sécurisée (par l'intermédiaire notamment du stockage, au sein de la carte à puce de clés privées et publiques). De telles solutions permettent effectivement de s'assurer de l'identité de l'entité qui souhaite se connecter, mais ne sécurisent en rien la machine sur laquelle la procédure d'authentification est réalisée. 3 RESUME DE L'INVENTION L'invention propose une solution nouvelle qui permet de résoudre ces inconvénients de l'art antérieur, sous la forme d'un procédé de production de données de sécurisation, permettant la mise en oeuvre d'une session sécurisée entre une première et au moins une deuxième entité, selon un protocole d'établissement de sessions sécurisées. Selon l'invention, un tel procédé comprend : - une étape d'initialisation d'une troisième entité sécurisée, liée à ladite première entité ; une étape de génération d'au moins une partie desdites données de sécurisation au sein de ladite troisième entité ; une étape de transmission desdites données de sécurisation de ladite troisième entité sécurisée vers ladite première entité. Ainsi, à la différence des techniques de l'art antérieur qui ne permettent la production des données de session que sur l'entité qui va effectivement mettre en oeuvre la session sécurisée, l'invention autorise la production de telles données au sein d'une troisième entité différente de la première. Cette troisième entité peut être attachée soit mécaniquement à la première, soit par le biais d'une interface d'un réseau, tel qu'un réseau local. La génération des données permettant la mise en oeuvre de la session sécurisée n'est donc plus réalisée par l'entité qui met en oeuvre la session sécurisée, mais par une entité tierce, évitant ainsi les différentes attaques qui peuvent être conduites vis-à-vis de la première entité. Le procédé selon l'invention permet donc de remplacer la première entité lors de la production de données de sessions sécurisée. Une telle substitution autorise la conduite d'au moins une partie des opérations de définition des données permettant l'établissement de la session au sein de la troisième entité qui peut donc prendre la place de la première et ainsi sécuriser la procédure de création des données au sein d'un environnement sûr. Selon un mode de réalisation original de l'invention, ladite troisième entité est une carte à puce de type JavaCard . Ainsi, l'invention permet de dissocier le dispositif qui est chargé de mettre en oeuvre le protocole de sécurité du dispositif souhaitant disposer d'une connexion sécurisée. De plus, l'utilisation d'une carte à puce de type JavaCard assure que cette entité chargée de mettre en oeuvre le protocole de sécurité est inviolable et totalement sécurisée. Un niveau de sécurisation supplémentaire, issu des travaux menés par les inventeurs, est donc ajouté à l'ensemble du protocole de sécurité. Selon une caractéristique particulière de l'invention, ledit protocole d'établissement de sessions sécurisées est le protocole SSL. Ainsi, l'invention prend en charge l'établissement d'une session sécurisée respectant le protocole SSL, qui est un des protocoles majeurs dans ce domaine. Selon une caractéristique particulière de l'invention, ledit protocole d'établissement de sessions sécurisées est le protocole TLS. Ainsi, l'invention prend en charge l'établissement d'une session sécurisée respectant le protocole TLS, qui est un des protocoles les plus utilisés dans ce domaine. Selon un mode de réalisation particulier de l'invention, ledit procédé de production comprend en outre : une étape de transmission, par ladite première entité, d'au moins un message à destination d'une couche RECORD mise en oeuvre au sein de ladite troisième entité ; - une étape de réception, par ladite première entité, d'au moins un message en provenance de ladite couche RECORD ; une étape de calcul d'un ensemble de clés par ladite troisième entité ; une étape de collecte dudit ensemble de clés disponibles par ladite première entité auprès de ladite troisième entité ; - une étape de récupération d'un identifiant de session de communication sécurisée. Ainsi, l'invention permet de conserver la conformité des installations existantes en réalisant un transfert de messages en lieu et place de l'exécution des étapes de production sur la première entité, qui peut être soumise aux attaques. L'invention concerne également un dispositif de production de données de sécurisation, permettant la mise en oeuvre d'une session sécurisée entre une première et au moins une deuxième entité, selon un protocole d'établissement de sessions sécurisées. Selon l'invention, un tel dispositif comprend : des moyens d'initialisation, attachée à ladite première entité ; - des moyens de génération d'au moins une partie desdites données de sécurisation ; des moyens de transmission desdites données de sécurisation vers ladite première entité. De façon générale, un tel dispositif comprend des moyens lui permettant de mettre en oeuvre les étapes du procédé de production tel que décrit précédemment. Selon un mode de réalisation original de l'invention, lesdits moyens de génération et lesdits moyens de transmission sont regroupés dans une carte à puce. Ainsi, un tel dispositif selon l'invention dispose de moyens de résistance aux attaques malveillantes. Dans un autre mode de réalisation, l'invention concerne également un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur. Selon l'invention, dans au moins un mode de réalisation, un tel produit programme d'ordinateur comprend des instructions de code de programme pour l'exécution du procédé de production tel que décrit précédemment. 4 LISTE DES FIGURES D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la figure 1 présente un synoptique du procédé de production de données sécurisées selon l'invention ; - la figure 2 illustre un exemple de mise en oeuvre du procédé de production au sein d'un module de sécurité selon l'invention ; la figure 3 décrit un mode de mise en oeuvre du procédé de production par deux entités à l'aide de deux modules de sécurité dans un mode dit de full session ; - la figure 4 décrit un mode de mise en oeuvre du procédé de production par deux entités à l'aide de deux modules de sécurité dans un mode dit de Session Resumption ; la figure 5 décrit également un mode de mise en oeuvre du procédé de production par deux entités à l'aide de deux modules de sécurité dans un 5 mode dit de Session Resumption ; la figure 6 décrit une architecture d'un dispositif de production de données de sécurisation, également appelé module de sécurité. DESCRIPTION DETAILLEE DE L'INVENTION 5.1 Rappel du principe de l'invention L'invention permet donc de résoudre les problèmes liés à l'insécurité intrinsèque des entités sur lesquelles sont mis en oeuvre les protocoles SSL et TLS. En effet, ces entités sont, de manière générale, des serveurs fonctionnant sur des systèmes d'exploitation propriétaires ou issus du monde libre ou des ordinateurs personnels d'utilisateurs classiques. Si on accorde la plupart du temps une confiance relativement large dans la catégorie des serveurs , les ordinateurs personnels des utilisateurs individuels n'ont pas le même niveau de sécurisation que les serveurs et sont donc plus souvent (mais non exclusivement) soumis aux risques d'attaques. Ainsi, quand bien même les protocoles de sécurisation de session de communication tels que TLS et SSL remplissent correctement leurs fonctions, il est fort probable qu'une attaque visant un poste de travail ou un entité serveur à l'aide de logiciels malfaisant puisse s'introduire dans une pile logicielle ou encore modifier des fichiers du système d'exploitation. Une telle introduction est alors réalisée dans l'objectif de pouvoir prendre le contrôle ultérieur de sessions initiées par des utilisateurs. Pour éviter ces attaques ultérieures, l'invention permet de mettre en oeuvre au moins certaines étapes d'authentification dans une entité tierce solidaire de l'entité qui met généralement en oeuvre cette phase d'authentification. Une telle entité tierce, qui est un dispositif de production d'informations de sécurisation selon l'invention, est également appelée module de sécurité . Cette entité met ensuite à disposition les informations nécessaires à la poursuite de la session d'authentification. De telles informations peuvent par exemple, être les clés de session (keys_bloc) ou le master secret (selon le niveau de sécurité requis) pour un logiciel qui a besoin d'un échange d'information sécurisée par les protocoles SSL/TLS. Le principe général de l'invention repose sur une délocalisation, au sein d'une entité de confiance, tel qu'un module de sécurité, d'au moins certaines étapes d'un protocole, tel qu'un protocole d'authentification, à mettre en oeuvre. En effet, bien que les données applicatives soient échangées entre les entités client et serveur, la phase d'authentification est le processus le plus critique puis qu'il établit l'identité des deux parties, vérifie leurs certificats et calcule les clés cryptographiques. L'invention se distingue des techniques de l'art antérieur, qui mettent en oeuvre des cartes à puce, par le fait que ces mécanismes antérieurs ne proposent pas, au sein de la carte en question, une exécution de logiciels, mais un simple stockage de données telles que des certificats ou des clés. Une entité selon l'invention, au contraire, ne renferme pas, dans sa fonction première, des données, mais un ensemble de mécanismes permettant l'exécution, de manière indépendante, d'au moins certaines étapes d'un protocole sécurisé. On présente, en relation avec la figure 1, le procédé de production de données sécurisées selon l'invention. Il comprend : une étape d'initialisation (100) du module de sécurité (par exemple une carte à puce), attachée à une première entité (par exemple un ordinateur personnel) ; une étape de génération (101) d'une partie des données de sécurisation au sein du module de sécurité ; une étape de transmission (102) des données de sécurisation du module de sécurité vers la première entité. Par la suite, on présente notamment le cas d'un module de sécurité mettant en oeuvre le procédé selon l'invention pour les étapes d'authentification des protocoles SSL/TLS. Il est clair cependant que l'invention ne se limite pas à cette application particulière, mais peut également être mise en oeuvre dans de nombreux autres domaines, et par exemple dans des entités qui pourraient mettre en oeuvre des mécanismes d'initialisation ou de démarrage d'autres entités, tels que des véhicules par exemple et plus généralement dans tous les cas où les avantages procurés par l'invention sont intéressants. 5.2 Description d'un mode de réalisation On présente dans ce mode de réalisation, la mise en oeuvre du procédé selon l'invention au sein d'une carte à puce embarquant des moyens d'exécution de programmes d'ordinateurs (module de sécurité). Il peut par exemple s'agir d'une JavaCard c'est-à-dire d'une carte à puce qui intègre une machine virtuelle Java. De telles cartes à puce présentent l'avantage d'être résistantes aux attaques. Cela signifie que ces cartes possèdent des caractéristiques physiques qui diminuent de manière drastiques les risques et les possibilités de piratage. Elles sont donc particulièrement bien indiquées pour la mise en oeuvre de procédures sécurisées. Dans ce mode de réalisation, le procédé selon l'invention permet de 20 délocaliser la mise en oeuvre du protocole SSL ou TLS au sein de ce module de sécurité. Dans l'état de l'art actuel la pile TLS (c'est-à-dire l'enchaînement des étapes du processus conduisant à l'authentification) est intégralement exécutée sur le même ordinateur et ne permet donc pas de séparer les procédures 25 d'authentification et d'échange d'informations. Cependant de nombreuses applications, par exemple les réseaux virtuels (VPN) basés sur SSL/TLS, les grilles de calculs, ou les réseaux de type overlays (de l'anglais, pour recouvrement ), nécessite des garanties de sécurité particulières, afin d'interdire les usurpations d'identité, c'est-à-dire 30 l'usage illicite de services par des pirates informatiques (ou hackers ). Les systèmes d'exploitation complexes des ordinateurs actuels permettent l'exécution de logiciels malveillants tels que chevaux de Troie, vers, virus, capables de collecter les identités et les clés RSA des utilisateurs. Un module de sécurité mettant en oeuvre le procédé selon l'invention comprend donc des fonctionnalités originales qui lui permettent de réaliser la phase d'authentification du protocole TLS, et de transférer le droit, à une application, d'utiliser le tunnel sécurisé préalablement établi. Un module de sécurité mettant en oeuvre le procédé selon l'invention réalise les fonctions de client ou de entité serveur TLS. Ainsi, Dans ce mode de réalisation particulier, le procédé selon l'invention met en oeuvre les entités HANDSHAKE , ALERT , CCS et RECORD décrites précédemment. On présente, en relation avec la figure 2 un module de sécurité (210) mettant en oeuvre le protocole TLS selon le procédé de production de l'invention et une entité utilisatrice (200), c'est-à-dire une application (2000) comprenant un sous ensemble de la pile TLS, a savoir de manière obligatoire les couches RECORD (2004) et ALERT (2002) et de manière optionnelle les couches CCS (2003) et HANDSHAKE (2001). La couche RECORD (2004) présente une interface de communication avec la couche TCP (2005). Dans ce mode de réalisation, un tel module de sécurité offre une interface fonctionnelle (220) qui comprend huit commandes : SET-Credentials , Start , Process-TLS , GET-Keys_bloc , Compute-Keys_bloc , GETCipher_suite , GET-SessionlD , GET-Master_secret . De telles commandes peuvent être réalisées en suivant la norme ISO 7816 selon un codage couramment dénommé APDUs (de l'anglais Application Protocol Data Unit pour Unité de données (PDU) de la couche sept (Application) du modèle OSI ). Le module de sécurité (210) qui met en oeuvre le procédéde production selon l'invention comprend les entités nécessaires à la mise en oeuvre du procédé de sécurisation à savoir les couches RECORD (2104) et ALERT (2102) et de manière optionnelle les couches CCS (2103) et HANDSHAKE (2101). L'interface fonctionnelle (220) permet à l'entité utilisatrice (200) de faire appel au module de sécurité (210) pour la production de données de sécurisation. 5.3 Description des commandes 5.3.1 Commande SET- Credentials Le rôle du module, c'est-à-dire son comportement client ou entité serveur ainsi que les différents paramètres nécessaires à son fonctionnement, qualifiés usuellement de lettres de crédits ou credentials en langue anglaise (certificats X509, clé privé RSA) est activé par la commande SET-Credentials(), SET-Credentials(Credentials, rôle) 5.3.2 Start(Unix-Time) Dans ce mode de réalisation, une commande Start initialise une session TLS; puisque les modules de sécurité ne comportent pas en règle générale d'horloge elle renseigne également l'heure GMT au format dit UNIX, c'est-à-dire un nombre de 32 bits qui mesure le nombre de secondes écoulées depuis le lier janvier 1970. 5.3.3 Process-TLS Les paquets TLS, c'est-à-dire les messages produits par une l'entité 20 RECORD, sont transmis au module de sécurité à l'aide de la commande Process-TLS(Record-Packets) qui retourne un ou plusieurs messages RECORD. Record-Packets = Process-TLS(Record-Packets) 5.3.4 GET-Keys bloc Lorsque un module de sécurité TLS a conduit avec succès 25 l'authentification de son interlocuteur il calcule le keys_bloc, la couche RECORD bascule en mode chiffré, et délivre les messages CCS et FINISHED. La commande GET-Keys_bloc collecte alors l'ensemble des clés disponibles, keys_bloc = GET-Keys_bloc() L'utilisateur des services du module de sécurité peut alors gérer de 30 manière autonome (sans l'aide du module de sécurité) sa propre couche RECORD. En effet il connaît les clés du canal sécurisé (keys_bloc) et la valeur courante du paramètre seq_num égale à 1 (la valeur 0 a été utilisé pour le calcul d'intégrité HMAC du message FINISHED). 5.3.5 Compute-Keys bloc La commande Compute-Keys_bloc() associée aux nombres aléatoires générés par l'entité cliente et l'entité serveur (Client-Random et Server-Random) permet de calculer le paramètre keys_bloc . Elle est utile lors d'une session de type Session Resumption , ou l'utilisateur du module de sécurité emploie ce dernier, uniquement pour l'obtention du keys_bloc. keys_bloc = Compute-Keys_bloc(Client-Random, Server-Random) Il est important de remarquer que dans ce cas le module de sécurité n'exporte pas la valeur du master_secret . Il est donc impossible de conduire une session de type Session Resumption en l'absence du module de sécurité, qui garantit donc la bonne foi de l'usager du service. 5.3.6 GET-Cipher suite Une commande GET-Cipher_suite permet de connaître les paramètres de sécurité, indexés par le nombre cipher_suite, associé à l'entité RECORD cipher_suite = Get-Cipher_suite() 5.3.7 GET-SessionID La commande GET-SessionID retourne le paramètre SessionID associé à la session courante ou à la session précédente. C'est une information utile pour l'utilisateur qui désire gérer partiellement un Session Resumption . SessionID = GET-SessionID() 5.3.8 GET- Master secret La commande GET-Master_secret() collecte le master_secret associé au SessionID de la session courante ou précédente. Elle est optionnelle et correspond à une politique de gestion des Session Resumption pour laquelle l'utilisateur n'utilise pas le service de calcul du keys_bloc . master_secret = GET-Master_secret() 5.4 Mises en oeuvre du protocole A l'aide des huit commandes décrites précédemment il est possible mettre en oeuvre au moins trois modes principaux d'usage, par un utilisateur, d'un module de sécurité TLS. Un premier mode est illustré par la figure 3. Il s'agit de la mise en oeuvre du procédé selon l'invention appliqué à une ouverture de session en mode dit de full session utilisant l'algorithme RSA, avec mutuelle authentification ("Client Authentication Handshake"). Une entité cliente (350) initie cette dernière par un message ClientHello (301). Une entité entité serveur (360) répond par un ensemble de messages ServerHello (302), Certificate (303), CertificateRequest (304), ServerHelloDone (305). L'entité cliente délivre alors les messages Certificate (306), CertificateVerify (307), ClientKeyExchange (308), ChangeCipherSpec (309), et Finished (310). Dans cette procédure l'entité cliente vérifie la validité du certificat du serveur, en extrait sa clé publique RSA, puis lui transmet une valeur baptisée pre_master_secret chiffrée de cette clé. Le master_secret est calculé partir des éléments Client-Random, Server-Random et pre-master-secret. Le message CertificateVerify (307) contient une signature réalisée avec la clé privée RSA du client, qui prouve l'identité de ce dernier (son certificat présent dans le message Certificate (306)). Au terme de cette procédure d'authentification l'entité cliente et l'entité serveur disposent d'une nouvelle valeur master_secret à partir de laquelle sont déduites les clés du keys_bloc. Un paramètre SessionlD transmis dans le message ServerHello fournit un index du master_secret. Par la suite les données générées par la couche APPLICATION sont transportées par l'entité RECORD (313) (313), qui en assure la confidentialité et l'intégrité grâce aux clés Kc et Ki. Les étapes précédemment décrites sont mise en oeuvre au sein de modules de sécurité : un pour l'entité cliente (35) et un pour l'entité entité serveur (36). Ainsi que cela est représenté sur la figure 3, les étapes précédemment décrites ne sont pas mises en oeuvre au sein des entités clientes (350) et des entités entité serveur (360) mais ne font que transiter par ces entités). La mise en oeuvre effective est réalisée au sien des modules de sécurité à l'aide de commandes de l'interface fonctionnelle du module. Dans chacun des deux modules de sécurité mis en oeuvre, quatre commandes sont utilisées : Start (3001, 3002) pour l'initialisation d'une session TLS, Process-TLS traite les paquets TLS (non représentée), GET-keys_bloc (3003, 3004) collecte les clés de la couche RECORD et GETCipher_suite (3005, 3006) indique la liste des algorithmes cryptographiques employés pour la gestion du canal sécurisé. L'entité cliente ouvre une session TLS avec une entité serveur écoutant typiquement sur le port TCP 443. Dans cette illustration, un module de sécurité est mis en oeuvre du côté de l'entité cliente (350) et du côté de l'entité entité serveur (360). Un deuxième mode est présenté à la figure 4. Dans ce cas une précédente session de type Full Session a permis d'obtenir un master_secret identifié par un index SessionlD . La phase d'authentification est simplifiée et consiste pour les deux parties (entité cliente et serveur) à prouver leur connaissance de la valeur master_secret. L'entité cliente (440) ouvre la session TLS par un message ClientHello (401) contenant l'index (SessionlD) d'une session précédente. L'entité serveur (460) répond par un ensemble de messages ServerHello (402), ChangeCipherSpec (403), et Finished (404). Il indique la reprise de session en insérant une valeur SessionID dans le message ServerHello identique à celle contenue dans le message ClientHello . L'entité cliente délivre alors les messages, ChangeCipherSpec (405), et Finished (406). Le master_secret n'est pas recalculé, cependant un nouvel ensemble keys_bloc est obtenu à partir des éléments master_secret , ClientRandom et ServerRandom . Keys_block = PRF(master_secret, "key expansion", server_random 1 client_random). Par la suite les données générées par la couche APPLICATION sont transportées par l'entité RECORD (407) (408), qui en assure la confidentialité et l'intégrité grâce aux clés Kc et Ki. Le mécanisme dit de Session Resumption simplifie l'échange d'information lors d'une session TLS. Une première Full Session effectue l'authentification simple ou mutuelle des deux extrémités (entité cliente et serveur) et produit un master_secret. Les sessions suivantes, basées sur le mécanisme de reprise de session réutilisent le master_secret pour le calcul de nouvelles clés de chiffrement et d'intégrité. Dans ce mode de réalisation, une session de type Session Resumption est négociée entre une entité cliente et une entité serveur. La valeur du master_secret est protégée par le module de sécurité côté entité cliente et/ou serveur. Trois commandes sont nécessaires; Start (4001, 4002) initialise un module de sécurité; GET-SessionlD (4003, 4005) récupère le SessionlD d'un précédente session qui peut être inséré dans le message Client-Hello (4001) ou permettre la vérification de l'existence d'un master_secret côté serveur (4003) Compute-Keys_bloc() calcule le keys_bloc à l'aide des nombres aléatoires échangés par l'entité cliente (4004) et l'entité serveur (4006). Un troisième mode est explicité par la figure 5. Une session de type Session Resumption est négociée entre une entité cliente (550) et une entité serveur (560). La valeur du master_secret est stockée par le module de sécurité côté client (55) et/ou serveur (56). Trois commandes sont nécessaires; Start (5001, 5002) initialise un module de sécurité; GET-SessionlD récupère le SessionlD d'un précédente session qui peut être inséré dans le message ClientHello (5003) ou permettre la vérification de l'existence d'un master_secret côté serveur (5005). GET-Master-secret retourne la valeur du master-secret (5004, 5006). Ce mode de fonctionnement est compatible avec des logiciels tels que OpenSSL qui utilisent des objets SESSION stockés dans des fichiers. Le module de sécurité joue dans ce cas un rôle de cache amovible de la valeur du master_secret . Les étapes 401 à 408 sont identiques à celle décrites en relation avec la figure 4. 5.5 Description d'un module de sécurité selon l'invention On présente, en relation avec la figure 6, un module de sécurité sous la forme d'un circuit intégré de silicium (600), qualifié usuellement de "Tamper Resistant Device", littéralement un "composant qui résiste aux attaques", tel que par exemple le composant ST22 (produit par la société ST Microelectronics) et disponible sous différents formats tels que des cartes en PVC, (cartes à puce, carte SIM,...) intégrées dans des jetons USB, ou dans des mémoires MMC (MultiMedia Card). Un tel module de sécurité incorpore tous les moyens sécurisés de stockage de données, et permet également l'exécution de logiciels dans un environnement sûr et protégé. Plus précisément il comporte une unité centrale (CPU, 601), une mémoire ROM stockant le code du système d'exploitation (602), de la mémoire RAM (603), et une mémoire non volatile (NVR, 604), utilisée comme dispositif de stockage analogue à une disque dur, et qui contient par exemple un logiciel embarqué TLS. Un bus système (610) relie les différents organes du module sécurisé. L'interface avec le monde extérieur (620) est assuré par un port IO d'entrée/sortie (605), conforme à des standards tels que IS06816, USB, USBOTG, IS06816-12, MMC, IEEE 802.3, IEEE 802.11, etc. Les cartes à puces JAVA, communément désignées par le terme JAVACARD, sont une classe particulière de module de sécurité.25 REVENDICATIONS 1. Procédé de production de données de sécurisation, permettant la mise en oeuvre d'une session sécurisée entre une première et au moins une deuxième entité, selon un protocole d'établissement de sessions sécurisées, caractérisé en ce qu'il comprend : une étape d'initialisation d'une troisième entité sécurisée, liée à ladite première entité ; une étape de génération d'au moins une partie desdites données de sécurisation au sein de ladite troisième entité ; - une étape de transmission desdites données de sécurisation de ladite troisième entité sécurisée vers ladite première entité. 2. Procédé de production selon la revendication 1, caractérisé en ce que ladite troisième entité est une carte à puce de type JavaCard . 3. Procédé de production selon l'une quelconque des revendications 1 et 2, caractérisé en ce que ledit protocole d'établissement de sessions sécurisées est le protocole SSL. 4. Procédé de production selon l'une quelconque des revendications 1 et 2, caractérisé en ce que ledit protocole d'établissement de sessions sécurisées est le protocole TLS. 5. Procédé de production selon la revendication 4, caractérisé en ce que ladite en ce qu'il comprend en outre : une étape de transmission, par ladite première entité, d'au moins un message à destination d'une couche RECORD mise en oeuvre au sein de ladite troisième entité ; - une étape de réception, par ladite première entité, d'au moins un message en provenance de ladite couche RECORD ; une étape d,e calcul d'un ensemble de clés par ladite troisième entité ; une étape de collecte dudit ensemble de clés disponibles par ladite première entité auprès de ladite troisième entité ; - une étape de récupération d'un identifiant de session de communicationsécurisée. 6. Dispositif de production de données de sécurisation, permettant la mise en oeuvre d'une session sécurisée entre une première et au moins une deuxième entité, selon un protocole d'établissement de sessions sécurisées, caractérisé en ce qu'il comprend : des moyens d'initialisation, attachée à ladite première entité ; des moyens de génération d'au moins une partie desdites données de sécurisation ; des moyens de transmission desdites données de sécurisation vers ladite 10 première entité. 7. Dispositif cle production de données de sécurisation selon la revendication 6, caractérisé en ce que lesdits moyens de génération et lesdits moyens de transmission sont regroupés dans une carte à puce. 8. Produit programme d'ordinateur téléchargeable depuis un réseau de 15 communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution du procédé de production selon l'une au moins des revendications 1 à 5, lorsqu'il est exécuté sur un ordinateur. 20