WO2006072692A1 - Procede pour accomplir des fonctions cryptographiques dans une application informatique ecrite en langage a code mobile, et application informatique correspondante - Google Patents

Procede pour accomplir des fonctions cryptographiques dans une application informatique ecrite en langage a code mobile, et application informatique correspondante Download PDF

Info

Publication number
WO2006072692A1
WO2006072692A1 PCT/FR2005/003234 FR2005003234W WO2006072692A1 WO 2006072692 A1 WO2006072692 A1 WO 2006072692A1 FR 2005003234 W FR2005003234 W FR 2005003234W WO 2006072692 A1 WO2006072692 A1 WO 2006072692A1
Authority
WO
WIPO (PCT)
Prior art keywords
cryptographic
module
modules
resource
formatting
Prior art date
Application number
PCT/FR2005/003234
Other languages
English (en)
Inventor
Anne-Sophie Pignol
Laurent Frisch
Joseph Hamze
Original Assignee
France Telecom
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom filed Critical France Telecom
Publication of WO2006072692A1 publication Critical patent/WO2006072692A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services

Definitions

  • the present invention relates to the implementation of cryptographic techniques by computer applications.
  • RC cryptographic resources
  • LCM applications concerned by the invention mention may be made, for example, of tele-procedure, workflow, e-mail, document publication, etc. applications. They can run on a wide variety of computer platforms, for example on the Windows 95/98 / ME / NT / 2000 / XP operating system with an Internet Explorer, Netscape, Mozilla browser, under the Windows system. MacOS 8/9 / X operating with Internet Explorer browser, Netscape, Mozilla, Opera, on a Sun Solaris platform with a WebSphere server, etc.
  • Application security services that must be offered to applications are, for example, electronic signature, electronic signature verification, encryption, decryption, timestamping, time stamp verification, secure protocol services. , authentication, etc. They use various types of CR such as cryptographic keys, certificates, algorithms to use them, etc.
  • the cryptographic supports can be of the smart card type, module connectable to a USB port ("Universal Serial Bus") called "USB token", crypto-hardware card, PCMCIA card ("Personal Computer Memory International Card Association”), software store, etc.
  • USB port Universal Serial Bus
  • crypto-hardware card crypto-hardware card
  • PCMCIA card Personal Computer Memory International Card Association
  • PKCS # 11 For access to cryptographic (CR) resources, high level interfaces such as PKCS # 11 or CAPI (Microsoft
  • Mobile-language languages are programming languages whose resulting code is not dependent on a microprocessor or an operating system. To run, the program needs to find a similar executing environment on the different computers on which it runs.
  • LCMs that interest us in the first place are those that can also realize web applications.
  • the most common is the Java language of Sun Microsystems, Inc. Java web applications running in a browser environment are called applets.
  • Another more recently developed LCM is the C # language of Microsoft Corporation.
  • the example that will be considered more particularly in this application is that of Java, but the concepts apply to any other LCM.
  • FR-A-2,840,134 describes a method of controlling access to cryptographic resources from an application in LCM, which makes it possible to take this disparity into account, by presenting to the application a pooled interface independent of the sources and their interfaces respective accesses.
  • a translation module is placed between the shared interface and each access interface to a cryptographic source to ensure access cryptographic resources from the application through the shared interface.
  • the sources are identified by the translation module downstream of the shared interface.
  • the cryptographic operations that are not executed in the sources themselves are in a module of primitives belonging to a cryptographic toolbox upstream of the shared interface.
  • An object of the present invention is to enable an LCM program to access a heterogeneous or non-heterogeneous set of RC, via identical or different access interfaces, while having great flexibility in terms of openness and reliability. extensibility.
  • the invention thus proposes a method for performing cryptographic functions in a computer application written in a mobile code language, in which the application is provided with a cryptographic toolbox comprising:
  • a cryptographic resource management module controlled by the functional module, for recording the resource modules of said set and for determining properties of the registered modules; and a cryptographic operations management module for routing calls received from the functional module to resource modules registered by the cryptographic resource management module.
  • the resource management modules and cryptographic operations communicate with the resource modules of the set via a mutualized interface substantially independent of the cryptographic sources and their respective access interfaces.
  • Another aspect of the present invention relates to a computer application written in LCM, in which cryptographic functions are performed in accordance with the above method.
  • the proposed architecture homogenizes the methods of access to the RC, by the modules of resource management and cryptographic operations. It is possible to define in advance or not the RC that the user wishes to take into account, which increases the modularity of the architecture.
  • Access to resources is achieved through a common interface that provides simple access, with a pragmatic interface to low-level cryptographic functions.
  • the resources are not manipulated directly by the LCM application, but are accessible through the resource management modules and cryptographic operations via a single implementation of the pooled API.
  • the invention provides cryptographic functions with simple Cryptography Service Provider access (CSP in the CAPI context) to the available cryptographic resources.
  • CSP Cryptography Service Provider access
  • the resulting architecture is open and ready for the evolution of techniques (platforms, cryptographic techniques, algorithms, key sizes, ...), cryptographic supports, cryptographic standards (for example PKIX, XML, PGP, etc. .), application security services, applications based on these application security services, etc.
  • FIGS. 1 and 2 are block diagrams of examples of LCM applications made according to the invention.
  • the system illustrated in FIG. 1 comprises several cryptographic sources 3, each having its own API 4 for access to the RCs. they contain.
  • These APIs 4 can be of the same nature (for example PKCS # 11, CAPI, PC / SC, etc.) or of different natures.
  • the application written in LCM is provided with a cryptographic toolbox 2 that incorporates a pooling API 5.
  • This cryptographic toolbox 2 communicates with the rest of the application (in the example represented a Java applet 9) via a functional interface 11.
  • I 1 mutualization API 5 complies with the interface format with this browser.
  • this interface format can be JNI ("Java Native Interface”, Sun Microsystems, Inc.), JRI ("Java Runtime Interface", Netscape Communications Corporation) or RNI ("Raw Native Interface”) ", Microsoft Corporation).
  • the toolbox 2 comprises a module 6 which, for the application, constitutes a cryptographic resource accessible by the pooling API 5.
  • This module 6 provides the required translations between the access API 4 and the pooling API 5. It controls the recovery of cryptographic data stored in the source 3 in response to instructions received on the pooling API 5. These instructions are in a format independent of the source type. They may contain a request to perform cryptographic calculations. In this case, the resource module 6 will generally perform the requested calculations after obtaining the necessary elements via the API 4. It is nevertheless possible that all or part of these calculations are to be executed by protected circuits included in the source 3 in which case the resource module 6 requests the execution of these calculations via the API 4, eventually completes them by other calculations that it executes itself and formats the result to return it to the API of 5. In the illustration of FIG.
  • one of the resource modules 7 cooperating with I 1 mutualization API 5 directly accesses cryptographic data stored in a file 8 recorded in the platform. computer execution of the application, for example on hard disk. This file 8 then constitutes a local source of cryptographic data accessible via an internal interface.
  • the proposed architecture ensures homogeneous processing between internal and external sources through the pooling API 5.
  • the cryptographic toolbox 2 Apart from the cryptographic toolbox 2, the rest of the program (applet 9 in the example shown in Figure 2) is written by an LCM developer who is in a business other than cryptography.
  • the cryptographic toolbox 2 comprises a functional module 10 which presents to the applet 9 an interface 11 called "functional API".
  • the functional module 10 realizes the general algorithmic of the security functions by relying on the modules 12-14 described below.
  • the security functions thus offered by the functional API are, for example, electronic signature, electronic signature verification, encryption, decryption, time stamping, time stamp verification, secure protocols, authentication, etc.
  • the resources are not manipulated directly by the LCM application or the functional module 10. They are accessible through modules 12, 13 for managing resources and operations via the pooling API 5.
  • the resource manager 12 presents the functional module 10 with a resource management interface 15 for identifying, locating and selecting available resources or objects for which they are responsible. It allows: - to recover certificates or keys;
  • the resource manager 12 after having established a session with all the available RCs, can possess and transmit to the operations manager 13 a list of keys, a list of the available stores, which allows for example to know the store in which a key generation is possible.
  • each resource module 6, 7 is responsible for the method employed.
  • the resource manager 12 only manages sessions with the resource modules. It thus offers a unique entrance.
  • the resource manager 12 also provides filtering mechanisms, both on the resources themselves and on all the objects for which they are responsible.
  • the resource manager 12 can extract a selection after having applied the filter requested by the program via the resource management interface 15.
  • the resource manager 12 may only use, depending on the needs of the LCM application, a portion of the available RCs.
  • the operations manager 13 uses the object lists to route the operation to the right resource or object.
  • the cryptographic router 13 is the mandatory entry point for any cryptographic call on the store, the provider, the resource or the key concerned.
  • the operations transmitted by the LCM application via the shared API 5 are treated in a unique way or not, in a single provider or in several distinct. These various possibilities are configurable.
  • the cryptographic router 13 can retrieve the responses of providers, stores, resources that have performed the operation, and possibly retransmit them to the LCM application via the service API 16.
  • the modules 12, 13 of resource management and operations has a character “plug-and-play” since it allows to add dynamic new RC.
  • this architecture will allow the use of any provider meeting the standard JCA / JCE ("Java Cryptography").
  • the cryptographic toolbox 2 further comprises a data format manipulation module 14 and a utilities module 17.
  • the utilities module 17 may be called by any of the other modules of the toolbox 2. It supports the following features:
  • the data format manipulation module 14 is a library of objects allowing the manipulation of cryptographic data and messages in standard formats such as for example PKCS # 7 / CMS, PGP, XML-DSig, X.509 certificates, lists of revocation X.509
  • the manipulation of data formats include a module or encoders / decoders ASN. 1 and the types described in PKIX.
  • the module 14 is most often invoked by the functional module 10 to format the elements to return to the applet, including the results of cryptographic operations. It can also be invoked by the resource manager 12, in particular to format certificates.
  • the following is an illustration of the case of a Java applet
  • This key generation requires a first step of searching for the "stores" (cryptographic key container) available on the computer.
  • the resource manager 12 instantiates all available cryptographic resources and asks them for a list of the stores they have via the pooling API 5. This request is made transparently for the program. Once the resources are instantiated, the method respects the JNI interface of access to each cryptographic resource. Each resource can thus register its available stores and return their references to the resource manager.
  • the PKCS # 11 dynamic link library (dll) returns the reference of its key container with key generation capability.
  • the first step of certificate generation is the generation of a bi-key.
  • This request is transmitted to the cryptographic router 13 with the specific parameters, such as the algorithm, the length of keys.
  • the reference of the store is transmitted to the cryptographic router 13 which can thus route the key generation request to the right resource.
  • the PKCS # 11 source performs the 1024-bit RSA public / private key pair generation operation.
  • the public key is sent back to the cryptographic router 13 which retransmits it via I 1 API 16.
  • the "skeleton" of a PKCS # 10 certificate is generated by the functional module 10 from this public key and sent back to the cryptographic router. The latter will make it possible to finalize the certificate generation by routing the signature request of the skeleton, specifying the store concerned.
  • the recipient cryptographic source signs this skeleton with its private key to complete the PKCS # 10 certificate which is returned to the cryptographic router 13. It requests the PKCS # 11 source to copy this object into its key container.
  • the data format library 14 can be directly invoked by the functional module 10.
  • the functional module 10 must then take into account the different possible data formats.
  • the functional module can be split into two sub-modules 19, 20 as shown in FIG.
  • Sub-module 19 constitutes an intermediate layer ("middleware") called "unifying”. It cooperates with the submodule 20 constituting the heart or the upper part of the functional module. This upper part 20 implements the functions themselves, independently of the data format.
  • the federator 19 lists one or more data format provider modules 18 ("providers"), each of which accesses the format library 14. The federator 19 selects an appropriate provider 18 for each formatting request received from the functional module, and outputs these queries to the selected provider that performs the formatting operation.
  • This architecture according to FIG. 2 makes it possible to develop the core 20 of the functional module without having to take into account the different possible data formats. New formats appearing on the market can easily be taken into account by simply enriching the library 14 and adding a specific provider module 18.
  • the embodiments of the invention that have been described can still have many variants.
  • resource manager 12 may restrict access to a single type of access interface 4 or even a single source 3, for example, to a single type of smart card.
  • the described modules may not be partitioned for volume reasons of the implementation. Conversely, the modules can be even more partitioned according to the cryptographic operations, the parameters, the objects to be counted.
  • the cryptographic toolbox 2 cooperates through I 1 functional API 11 with one or more Java servlets executed in the Java virtual machine of a servlet engine (example “Tomcat” or "WebSphere”) .
  • L 1 functional API 11 can also be presented in written standalone applications in Java or another LCM (eg CaML or C #).

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

On munit l'application écrite dans un langage à code mobile d'une boîte à outils cryptographiques (2) comportant: un module fonctionnel (10) présentant une interface fonctionnelle (11) avec le reste de l'application (9); un ensemble de modules de ressource cryptographique (6, 7) communiquant avec des sources respectives de données cryptographiques (3) ayant chacune une interface d'accès propre (4) ; un module de gestion de ressources cryptographiques (12) commandé par le module fonctionnel, pour enregistrer les modules dudit ensemble et déterminer des propriétés des modules enregistrés; et un module de gestion d'opérations cryptographiques (13) pour router des appels reçus du module fonctionnel vers des modules de ressource enregistrés. Les modules de gestion de ressources et d'opérations cryptographiques (12, 13) communiquent avec les modules de ressource cryptographique par l'intermédiaire d'une interface mutualisée (5) indépendante des sources et de leurs interfaces d'accès respectives.

Description

PROCÉDÉ POUR ACCOMPLIR DES FONCTIONS CRYPTOGRAPHIQUES
DANS UNE APPLICATION INFORMATIQUE ÉCRITE EN LANGAGE À CODE MOBILE. ET APPLICATION INFORMATIQUE CORRESPONDANTE
La présente invention concerne la mise en œuvre de techniques cryptographiques par des applications informatiques.
Elle vise plus particulièrement à offrir des services de sécurité applicative à différentes applications, écrites dans un langage à code mobile (LCM en abrégé) et s'exécutant sur diverses plates-formes informatiques. Ces services de sécurité applicative peuvent nécessiter l'accès à divers types de ressources cryptographiques (RC en abrégé) fournies à partir de supports cryptographiques variés. On cherche ainsi à pouvoir mutualiser ces RC entre les applications, par une architecture ouverte et prête à l'évolution des techniques employées, notamment des plates-formes, des méthodes cryptographiques (algorithmes, tailles de clés, ...), des supports et standards cryptographiques, des services de sécurité applicative, des applications reposant sur ces services de sécurité applicative, etc.
Parmi les applications en LCM concernées par l'invention, on peut citer par exemple des applications télé-procédure, de gestion de travaux ("workflow"), de courrier électronique, de publication de document, etc. Elles peuvent s'exécuter sur des plates-formes informatiques très variées, par exemple sous le système d'exploitation Windows 95/98/ME/NT/2000/XP muni d'un navigateur Internet Explorer, Netscape, Mozilla, sous le système d'exploitation MacOS 8/9/X muni d'un navigateur Internet Explorer, Netscape, Mozilla, Opéra, sur une plate-forme Sun Solaris muni d'un serveur WebSphere, etc.
Les services de sécurité applicative qu'il s'agit d'offrir aux applications sont par exemple des services de signature électronique, de vérification de signature électronique, de chiffrement, de déchiffrement, d'horodatage, de vérification d'horodatage, de protocole sécurisé, d'authentification, etc. Ils font appel à divers types de RC tels que clés cryptographiques, certificats, algorithmes permettant de les utiliser, etc.
Les supports cryptographiques peuvent être de type carte à puce, module raccordable à un port USB ("Universal Sériai Bus") appelé "token USB", carte crypto-hardware, carte PCMCIA ("Personal Computer Memory Card International Association"), magasin logiciel, etc.
Il existe de nombreux standards cryptographiques concernant les algorithmes de cryptographie, la génération de clé, le format des messages de nature cryptographiques, les protocoles sécurisés, etc.
Pour l'accès à des ressources cryptographiques (RC), on connaît des interfaces de haut niveau, telles que PKCS#11 ou CAPI (Microsoft
Corporation), qui offrent un niveau d'abstraction par rapport au support des éléments cryptographiques gérés, et des interfaces d'accès de plus bas niveau telles que le standard PC/SC ("Personal Computer / Smart Card").
Les langages à code mobile (LCM) sont des langages de programmation dont le code résultant n'est pas dépendant d'un microprocesseur ou d'un système d'exploitation. Pour s'exécuter, le programme a besoin de retrouver un environnement d'exécution similaire sur les différents ordinateurs sur lesquels il est amené à s'exécuter.
Les LCM qui nous intéressent en premier lieu sont ceux qui permettent de réaliser aussi des applications web. Le plus répandu est le langage Java de la société Sun Microsystems, Inc.. Les applications web Java s'exécutant dans l'environnement d'un navigateur s'appellent des applets. Un autre LCM apparu plus récemment est le langage C# de la société Microsoft Corporation. L'exemple qui sera considéré plus particulièrement dans la présente demande est celui de Java, mais les concepts s'appliquent à tout autre LCM.
La mise en œuvre de techniques cryptographiques dans des applications en LCM, notamment dans des applications web sécurisées, fait appel à des briques disparates.
FR-A-2 840 134 décrit un procédé de contrôle d'accès à des ressources cryptographiques depuis une application en LCM, qui permet de prendre en compte cette disparité, en présentant à l'application une interface mutualisée indépendante des sources et de leurs interfaces d'accès respectives. Un module de traduction est placé entre l'interface mutualisée et chaque interface d'accès à une source cryptographique pour assurer l'accès aux ressources cryptographiques depuis l'application à travers l'interface mutualisée. Les sources sont recensées par le module de traduction en aval de l'interface mutualisée. Les opérations cryptographiques qui ne sont pas exécutées dans les sources elles-mêmes le sont dans un module de primitives appartenant à une boîte à outils cryptographiques en amont de l'interface mutualisée.
Du fait de cette architecture, il est délicat de distinguer les objets cryptographiques (ressources, opérations). De plus, le catalogue fixé à l'avance d'algorithmes et protocoles que supporte le module de primitives limite les possibilités d'ajouter dynamiquement des nouveaux algorithmes ou de nouvelles implémentations d'algorithmes existants. Ce procédé entraîne aussi des manipulations différentes pour des ressources internes et des ressources externes.
Un but de la présente invention est de permettre à un programme en LCM d'accéder à un ensemble hétérogène ou non de RC, via des interfaces d'accès identiques ou non, tout en présentant une grande souplesse en termes d'ouverture et d'extensibilité.
L'invention propose ainsi un procédé pour accomplir des fonctions cryptographiques dans une application informatique écrite dans un langage à code mobile, dans lequel on munit l'application d'une boîte à outils cryptographiques comportant:
- un module fonctionnel présentant une interface fonctionnelle avec le reste de l'application;
- un ensemble de modules de ressource cryptographique communiquant avec des sources respectives de données cryptographiques ayant chacune une interface d'accès propre;
- un module de gestion de ressources cryptographiques commandé par le module fonctionnel, pour enregistrer les modules de ressource dudit ensemble et déterminer des propriétés des modules enregistrés; et - un module de gestion d'opérations cryptographiques pour router des appels reçus du module fonctionnel vers des modules de ressource enregistrés par le module de gestion de ressources cryptographiques. - A -
Les modules de gestion de ressources et d'opérations cryptographiques communiquent avec les modules de ressource de l'ensemble par l'intermédiaire d'une interface mutualisée sensiblement indépendante des sources cryptographiques et de leurs interfaces d'accès respectives. Un autre aspect de la présente invention se rapporte à une application informatique écrite en LCM, dans laquelle des fonctions cryptographiques sont accomplies conformément au procédé ci-dessus.
L'architecture proposée homogénéise les méthodes d'accès aux RC, par les modules de gestion de ressources et d'opérations cryptographiques. Il est possible de définir à l'avance ou non les RC que l'utilisateur souhaite prendre en compte, ce qui augmente la modularité de l'architecture.
L'accès aux ressources est réalisé au travers d'une interface commune qui offre des accès simples, avec une interface pragmatique aux fonctions cryptographiques de bas niveau. Les ressources ne sont pas manipulées directement par l'application LCM, mais sont accessibles à travers les modules de gestion de ressources et d'opérations cryptographiques via une unique implémentation de l'API mutualisée.
L'invention offre aux fonctions cryptographiques un accès simple de niveau "Cryptographie Service Provider" (CSP dans le contexte CAPI) aux ressources cryptographiques disponibles. L'architecture résultant est ouverte et prête à l'évolution des techniques (plates-formes, techniques cryptographiques, algorithmes, tailles de clés, ...), des supports cryptographiques, des standards cryptographiques (par exemple PKIX, XML, PGP, etc.), des services de sécurité applicative, des applications reposant sur ces services de sécurité applicative, etc.
D'autres particularités et avantages de la présente invention apparaîtront dans la description ci-après d'exemples de réalisation non limitatifs, en référence aux dessins annexés, dans lesquels :
- les figures 1 et 2 sont des schémas synoptiques d'exemples d'applications en LCM réalisées selon l'invention.
Le système illustré par la figure 1 comporte plusieurs sources cryptographiques 3 présentant chacune une API propre 4 pour l'accès aux RC qu'elles contiennent. Ces API 4 peuvent être de même nature (par exemple PKCS#11 , CAPI, PC/SC, ...) ou de natures différentes.
Pour supporter des fonctions de sécurité, l'application écrite en LCM est munie d'une boîte à outils cryptographiques 2 qui incorpore une API de mutualisation 5. Cette boîte à outils cryptographiques 2 communique avec le reste de l'application (dans l'exemple représenté une applet Java 9) par l'intermédiaire d'une interface fonctionnelle 11.
Dans le cas où l'application s'exécute au sein d'un navigateur, I1API de mutualisation 5 respecte le format d'interface avec ce navigateur. Dans le cas où le LCM est Java, ce format d'interface peut être JNI ("Java Native Interface", Sun Microsystems, Inc.), JRI ("Java Runtime Interface", Netscape Communications Corporation) ou RNI ("Raw Native Interface", Microsoft Corporation).
Entre l'API de mutualisation 5 et chaque API 4 d'accès à une source cryptographique, la boîte à outils 2 comporte un module 6 qui, pour l'application, constitue une ressource cryptographique accessible par l'API de mutualisation 5.
Ce module 6 assure les traductions requises entre l'API d'accès 4 et l'API de mutualisation 5. Il commande la récupération de données cryptographiques stockées dans la source 3 en réponse à des instructions reçues sur l'API de mutualisation 5. Ces instructions sont dans un format indépendant du type de source. Elles peuvent contenir une demande d'exécution de calculs cryptographiques. Dans ce cas, le module de ressource 6 exécutera en général les calculs demandés après avoir obtenu les éléments nécessaires via l'API 4. Il se peut néanmoins que tout ou partie de ces calculs soient à exécuter par des circuits protégés inclus dans la source 3, auquel cas le module de ressource 6 demande l'exécution de ces calculs via l'API 4, les complète éventuellement par d'autres calculs qu'il exécute lui-même et met en forme le résultat pour le retourner sur l'API de mutualisation 5. Dans l'illustration de la figure 1 , l'un des modules de ressource 7 coopérant avec I1API de mutualisation 5 accède directement à des données cryptographiques stockées dans un fichier 8 enregistré dans la plate-forme informatique d'exécution de l'application, par exemple sur disque dur. Ce fichier 8 constitue alors uns source locale de données cryptographiques accessible par une interface interne. L'architecture proposée assure une homogénéité de traitement entre les sources internes et externes à travers l'API de mutualisation 5.
De façon générale, dès qu'il faut ajouter une source cryptographique pour les besoins de l'application, il suffit de compléter celle-ci avec un module de ressource présentant I1API de mutualisation 5 et l'interface appropriée vers cette source. Cette nouvelle source sera enregistrée et deviendra utilisable à l'aide des dispositions décrites ci-après. De même, il est très aisé de retirer une source qui n'est plus nécessaire. Le procédé selon l'invention permet donc très facilement d'adapter l'application Java aux évolutions des sources disponibles.
En dehors de la boîte à outils cryptographiques 2, le reste du programme (applet 9 dans l'exemple illustré par la figure 2) est écrit par un développeur en LCM qui est d'un métier autre que la cryptographie. La boîte à outils cryptographiques 2 comprend un module fonctionnel 10 qui présente à l'applet 9 une interface 11 appelée "API fonctionnelle". Le module fonctionnel 10 réalise l'algorithmique générale des fonctions de sécurité en reposant sur les modules 12-14 décrits ci-dessous. Les fonctions de sécurité ainsi offertes par l'API fonctionnelle sont par exemple signature électronique, vérification de signature électronique, chiffrement, déchiffrement, horodatage, vérification d'horodatage, protocoles sécurisés, authentification, etc.
Les ressources ne sont pas manipulées directement par l'application LCM ou le module fonctionnel 10. Elles sont accessibles à travers des modules 12, 13 de gestion de ressources et d'opérations via l'API de mutualisation 5.
Le gestionnaire de ressources 12 présente au module fonctionnel 10 une interface de gestion des ressources 15 pour recenser, localiser et sélectionner des ressources disponibles ou des objets dont ils sont responsables. Il permet ainsi: - de récupérer des certificats ou des clés;
- de recenser des "stores" (localisations d'objets cryptographiques tels que certificats ou clés, correspondant aux magasins de stockage ou conteneur de clés pour chaque RC) ou des "providers" (organes gérés par des RC pour effectuer les opérations de cryptographie; CSP sur les interfaces CAPI);
- d'obtenir d'un module de ressource 6, 7 les capacités dont il dispose (liste des fonctionnalités gérées par une RC: algorithmes pour les providers; capacité de lecture et d'écriture pour les stores).
Ainsi le gestionnaire de ressources 12, après avoir établi une session avec ensemble des RC disponibles, peut posséder et transmettre au gestionnaire d'opérations 13 une liste de clés, une liste des stores disponibles ce qui permet par exemple de connaître le magasin dans lequel une génération de clés est possible.
Lors des mécanismes de recensement, chaque module de ressource 6, 7 est responsable de la méthode employée. Le gestionnaire de ressources 12 ne fait que gérer des sessions avec les modules de ressources. Il offre ainsi une entrée unique.
Le gestionnaire de ressources 12 offre également des mécanismes de filtrage, aussi bien sur les ressources en elles-mêmes que sur l'ensemble des objets dont elles sont responsables.
Ainsi, à partir d'une base de ressources recensée, le gestionnaire de ressources 12 peut en extraire une sélection après avoir appliqué le filtre demandé par le programme via l'interface de gestion des ressources 15.
Grâce à la modularité de l'architecture, le gestionnaire de ressources 12 peut ne faire appel, selon les besoins de l'application LCM, qu'à une partie des RC disponibles. Le gestionnaire d'opérations 13, également appelé "routeur cryptographique", présente au module fonctionnel 10 une interface de service 16 qui offre des méthodes d'appel aux opérations cryptographiques. Son rôle est de gérer le routage des appels d'opérations cryptographiques (signature, hash, vérification de signature, chiffrement, déchiffrement, horodatage, protocole sécurisé, etc.) vers la bonne ressource (module 6 ou 7). Cette ressource est choisie parmi celles recensées au préalable par le gestionnaire de ressources 12. Ainsi, les deux gestionnaires 12, 13 communiquent entre eux. Le gestionnaire d'opérations 13 utilise les listes d'objets afin de router l'opération vers la bonne ressource ou le bon objet.
Le routeur cryptographique 13 est le point d'entrée obligatoire de tout appel cryptographique sur le store, le provider, la ressource ou la clé concernée.
Les opérations transmises par l'application LCM via l'API mutualisée 5 sont traitées de manière unique ou non, dans un seul provider ou dans plusieurs distincts. Ces diverses possibilités sont configurables. Le routeur cryptographique 13 peut récupérer les réponses des providers, stores, ressources ayant effectué l'opération, et éventuellement les retransmettre à l'application LCM via l'API de service 16.
Les modules 12, 13 de gestion des ressources et opérations a un caractère "plug-and-play" puisqu'il permet de rajouter en dynamique de nouvelles RC. Ainsi, par exemple, cette architecture permettra l'utilisation de tout provider répondant au standard JCA/JCE ("Java Cryptography
Architecture" / "Java Cryptography Extension").
La boîte à outils cryptographiques 2 comprend en outre un module de manipulation de formats de données 14 et un module d'utilitaires 17. Le module d'utilitaires 17 peut être appelé par l'un quelconque des autres modules de la boîte à outils 2. Il a en charge les fonctionnalités suivantes:
- gérer les écarts des plates-formes aux spécifications du LCM ainsi que les spécificités du système d'exploitation utilisés dans ces plates-formes;
- manipuler les différentes formes d'encodage possibles (par exemple conversions entre binaire, Base64, PEM, etc.); - le cas échéant, gérer la journalisation, l'auto-installation de la boîte à outils 2, sa mise à jour, etc.
Le module de manipulation de formats de données 14 est une bibliothèque d'objets permettant la manipulation de données et messages cryptographiques dans des formats standard tels que par exemple PKCS#7/CMS, PGP, XML-DSig, certificats X.509, listes de révocation X.509
(CRL, "Certificate Revocation List"), OCSP, etc.
Par exemple, pour les standards issus du groupe de travail sur les infrastructures à clé publique de I1IETF (PKIX) dont les formats de données sont décrits en ASN.1 ("Abstract Syntax Notation N° 1"), le module de manipulation de formats de données comprendra un ou des encodeurs/décodeurs ASN.1 ainsi que les types décrits dans PKIX. Le module 14 est le plus souvent invoqué par le module fonctionnel 10 pour mettre en forme les éléments à retourner à l'applet, notamment les résultats d'opérations cryptographiques. Il peut aussi être invoqué par le gestionnaire de ressources 12, notamment pour mettre en forme des certificats. On considère ci-dessous, à titre d'illustration, le cas d'une applet Java
9 exécutée dans un environnement "Windows" pour demander la génération d'un certificat PKCS#11 RSA de 1024 bits dans une ressource cryptographique matérielle PKCS#11. La demande est effectuée grâce à des gestionnaires de ressources et d'opérations 12, 13 développés en Java afin de répondre aux besoins d'utilisation de fonctions de sécurité à partir d'un client léger, type applet Java s'exécutant dans la machine virtuelle de Sun.
Cette génération de clé nécessite une première étape de recherche des "stores" (conteneur de clés cryptographiques) disponibles sur le poste. Le gestionnaire de ressources 12 instancie l'ensemble des ressources cryptographiques disponibles et leur demande la liste des stores dont ils disposent via l'API de mutualisation 5. Cette demande s'effectue de manière transparente pour le programme. Une fois les ressources instanciées, le procédé respecte l'interface JNI d'accès à chaque ressource cryptographique. Chaque ressource peut ainsi recenser ses stores disponibles et renvoyer leurs références au gestionnaire de ressources. La bibliothèque de liens dynamiques (dll) PKCS#11 renvoie la référence de son conteneur de clés disposant de la capacité de génération de clés.
La première étape de génération de certificat est la génération d'une bi-clef. Cette demande est transmise au routeur cryptographique 13 avec les paramètres spécifiques, comme l'algorithme, la longueur de clés. La référence du store est transmise au routeur cryptographique 13 qui peut ainsi router la demande de génération de clés à la bonne ressource. La source PKCS#11 θffectue l'opération de génération de couple de clé publique/privée RSA de longueur 1024 bits. La clé publique est renvoyée au routeur cryptographique 13 qui la retransmet via I1API 16. Le "squelette" d'un certificat PKCS#10 est généré par le module fonctionnel 10 à partir de cette clé publique et renvoyé au routeur cryptographique. Ce dernier va permettre de finaliser la génération de certificat en routant la demande de signature du squelette, en précisant le store concerné. La source cryptographique destinataire signe ce squelette grâce à sa clé privée pour compléter le certificat PKCS#10 qui est retourné au routeur cryptographique 13. Celui-ci demande à la source PKCS#11 de copier cet objet dans son conteneur de clés.
Dans l'application schématisée sur la figure 1 , la bibliothèque de formats de données 14 est invocable directement par le module fonctionnel 10.
Le module fonctionnel 10 doit alors prendre en compte les différents formats de données possibles. En variante, on peut scinder le module fonctionnel en deux sous-modules 19, 20 comme représenté sur la figure 2.
Le sous-module 19 constitue une couche intermédiaire ("middleware") appelée "fédérateur". Il coopère avec le sous-module 20 constituant le cœur ou la partie haute du module fonctionnel. Cette partie haute 20 implémente les fonctions proprement dites, de manière indépendante du format des données. Le fédérateur 19 recense un ou plusieurs modules fournisseurs de formats de données 18 ("providers") qui accèdent chacun à la bibliothèque de formats 14. Le fédérateur 19 sélectionne un fournisseur approprié 18 pour chaque requête de formatage reçue du module fonctionnel, et aiguille ces requêtes vers le fournisseur sélectionné qui se charge de l'opération de formatage. Cette architecture selon la figure 2 permet de développer le cœur 20 du module fonctionnel sans avoir à prendre en compte les différents formats de données possibles. De nouveaux formats apparaissant sur le marché peuvent aisément être pris en compte en enrichissant simplement la bibliothèque 14 et en ajoutant un module fournisseur spécifique 18. Les modes de réalisation de l'invention qui ont été décrits peuvent encore présenter de nombreuses variantes.
Par exemple, le gestionnaire de ressources 12 peut restreindre l'accès à un seul type d'interface d'accès 4, voire à une seule source 3, par exemple, à un seul type de carte à puce.
Les modules décrits peuvent ne pas être cloisonnés pour des raisons de volume de l'implémentation. Inversement, les modules peuvent être encore plus cloisonnés en fonction des opérations cryptographiques, des paramètres, des objets à recenser.
Pour les applications exécutées dans des serveurs, la boîte à outils cryptographiques 2 coopère à travers I1API fonctionnelle 11 avec une ou plusieurs servlets Java exécutées dans la machine virtuelle Java d'un moteur de servlet (exemple "Tomcat" ou "WebSphere").
L1API fonctionnelle 11 peut aussi être présentée à des applications autonomes écrites en Java ou en un autre LCM (exemple CaML ou C#).

Claims

R E V E N D I C A T I O N S
1. Procédé pour accomplir des fonctions cryptographiques dans une application informatique écrite dans un langage à code mobile, dans lequel on munit l'application d'une boîte à outils cryptographiques (2) comportant un module fonctionnel (10, 20) présentant une interface fonctionnelle (11) avec le reste de l'application (9), caractérisé en ce que la boîte à outils comporte en outre:
- un ensemble de modules de ressource cryptographique (6, 7) communiquant avec des sources respectives de données cryptographiques (3) ayant chacune une interface d'accès propre (4);
- un module de gestion de ressources cryptographiques (12) commandé par le module fonctionnel, pour enregistrer les modules de ressource dudit ensemble et déterminer des propriétés des modules enregistrés; et
- un module de gestion d'opérations cryptographiques (13) pour router des appels reçus du module fonctionnel vers des modules de ressource enregistrés par le module de gestion de ressources cryptographiques, et en ce que les modules (12, 13) de gestion de ressources et d'opérations cryptographiques communiquent avec les modules de ressource (6, 7) dudit ensemble par l'intermédiaire d'une interface mutualisée (5) sensiblement indépendante des sources cryptographiques (3) et de leurs interfaces d'accès respectives (4).
2. Procédé selon la revendication 1 , dans lequel la boîte à outils cryptographiques (2) comporte en outre une bibliothèque (14) de formats de données utilisables pour mettre en forme des résultats d'opérations cryptographiques appelées par le module fonctionnel (10, 20).
3. Procédé selon la revendication 2, dans lequel la bibliothèque de formats de données (14) est invocable directement par le module fonctionnel (10).
4. Procédé selon la revendication 2, dans lequel la boîte à outils cryptographiques (2) comporte en outre un ensemble de modules (18) de mise en forme de résultats d'opérations cryptographiques, et un module de fédération (19) pour sélectionner un module de mise en forme dudit ensemble en réponse à une commande de formatage reçue du module fonctionnel (20), le module de mise en forme sélectionné accédant à la bibliothèque de formats de données (14) pour effectuer le formatage demandé.
5. Application informatique écrite dans un langage à code mobile, comprenant une boîte à outils cryptographiques (2) comportant un module fonctionnel (10, 20) présentant une interface fonctionnelle (11) avec le reste de l'application (9), caractérisé en ce que la boîte à outils comporte en outre:
- un ensemble de modules de ressource cryptographique (6, 7) communiquant avec des sources respectives de données cryptographiques (3) ayant chacune une interface d'accès propre (4); - un module de gestion de ressources cryptographiques (12) commandé par le module fonctionnel, pour enregistrer les modules de ressource dudit ensemble et déterminer des propriétés des modules enregistrés; et
- un module de gestion d'opérations cryptographiques (13) pour router des appels reçus du module fonctionnel vers des modules de ressource enregistrés par le module de gestion de ressources cryptographiques, et en ce que les modules de gestion de ressources et d'opérations cryptographiques (12, 13) communiquent avec les modules de ressource (6, 7) dudit ensemble par l'intermédiaire d'une interface mutualisée (5) sensiblement indépendante des sources cryptographiques (3) et de leurs interfaces d'accès respectives (4).
6. Application informatique selon la revendication 5, dans lequel au moins un module de ressource cryptographique (7) de l'ensemble communique avec une source interne de données cryptographiques (8) directement accessible par le langage à code mobile.
7. Application informatique selon la revendication 5 ou 6, dans lequel au moins un module de ressource cryptographique (6) de l'ensemble communique avec une source externe (3) de données cryptographiques. 8. Application informatique selon l'une quelconque des revendications
5 à 7, dans lequel la boîte à outils cryptographiques (2) comporte en outre une bibliothèque (14) de formats de données utilisables pour mettre en forme des résultats d'opérations cryptographiques appelées par le module fonctionnel (10, 20).
θ. Application informatique selon la revendication 8, dans lequel la bibliothèque de formats de données (14) est invocable directement par le module fonctionnel (10).
10. Application informatique selon la revendication 8, dans lequel la boîte à outils cryptographiques (2) comporte en outre un ensemble de modules
(18) de mise en forme de résultats d'opérations cryptographiques, et un module de fédération (19) pour sélectionner un module de mise en forme dudit ensemble en réponse à une commande de formatage reçue du module fonctionnel (20), le module de mise en forme sélectionné accédant à la bibliothèque de formats de données (14) pour effectuer le formatage demandé.
PCT/FR2005/003234 2005-01-03 2005-12-21 Procede pour accomplir des fonctions cryptographiques dans une application informatique ecrite en langage a code mobile, et application informatique correspondante WO2006072692A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0500019 2005-01-03
FR0500019 2005-01-03

Publications (1)

Publication Number Publication Date
WO2006072692A1 true WO2006072692A1 (fr) 2006-07-13

Family

ID=34979528

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2005/003234 WO2006072692A1 (fr) 2005-01-03 2005-12-21 Procede pour accomplir des fonctions cryptographiques dans une application informatique ecrite en langage a code mobile, et application informatique correspondante

Country Status (1)

Country Link
WO (1) WO2006072692A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7496199B2 (en) * 2002-05-21 2009-02-24 France Telecom Method of controlling access to cryptographic resources
EP2911082A1 (fr) * 2014-02-23 2015-08-26 Samsung Electronics Co., Ltd Appareil, procédé et système permettant d'accéder à et de gérer des bibliothèques de sécurité

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6389534B1 (en) * 1997-06-30 2002-05-14 Taher Elgamal Cryptographic policy filters and policy control method and apparatus
WO2002093468A1 (fr) * 2001-05-11 2002-11-21 M-Systems Flash Disk Pioneers Limited Configuration automatique pour dispositifs portables
FR2840134A1 (fr) * 2002-05-21 2003-11-28 France Telecom Procede de controle d'acces a des ressources cryptographiques, plate-forme informatique et module logiciel utilisables dans la mise en oeuvre du procede

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6389534B1 (en) * 1997-06-30 2002-05-14 Taher Elgamal Cryptographic policy filters and policy control method and apparatus
WO2002093468A1 (fr) * 2001-05-11 2002-11-21 M-Systems Flash Disk Pioneers Limited Configuration automatique pour dispositifs portables
FR2840134A1 (fr) * 2002-05-21 2003-11-28 France Telecom Procede de controle d'acces a des ressources cryptographiques, plate-forme informatique et module logiciel utilisables dans la mise en oeuvre du procede

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7496199B2 (en) * 2002-05-21 2009-02-24 France Telecom Method of controlling access to cryptographic resources
EP2911082A1 (fr) * 2014-02-23 2015-08-26 Samsung Electronics Co., Ltd Appareil, procédé et système permettant d'accéder à et de gérer des bibliothèques de sécurité
US10277560B2 (en) 2014-02-23 2019-04-30 Samsung Electronics Co., Ltd. Apparatus, method, and system for accessing and managing security libraries

Similar Documents

Publication Publication Date Title
WO2009130089A1 (fr) Procede de diffusion securisee de donnees numeriques vers un tiers autorise
JP2008276756A (ja) ウェブ・サービス仲介装置
US20170371625A1 (en) Content delivery method
FR3048530B1 (fr) Systeme ouvert et securise de signature electronique et procede associe
US8290152B2 (en) Management system for web service developer keys
EP2301187A1 (fr) Terminal d'authentification forte d'un utilisateur
FR3013541A1 (fr) Procede et dispositif pour la connexion a un service distant
CA3142763A1 (fr) Procede de chiffrement et de stockage de fichiers informatiques et dispositif de chiffrement et de stockage associe.
EP2124153B1 (fr) Procédés et dispositif de mise en oeuvre de périphériques multifonction avec un gestionnaire de périphérique standard unique
EP1506480B1 (fr) Procede de controle d'acces a des ressources cryptographiques
WO2006072692A1 (fr) Procede pour accomplir des fonctions cryptographiques dans une application informatique ecrite en langage a code mobile, et application informatique correspondante
CA2306677A1 (fr) Systeme de traitement de l'information permettant la securisation des communications entre composants logiciels
FR2840135A1 (fr) Procede pour accomplir des fonctions cryptographiques dans une application informatique, et application adaptee a la mise en oeuvre du procede
EP2912598B1 (fr) Procédé de téléchargement d'au moins un composant logiciel dans un appareil informatique, produit programme d'ordinateur, appareil informatique et système informatique associés
EP3231152B1 (fr) Procédé de chiffrement dynamique de données, et procédé de contrôle de droits de déchiffrement associé
Bhandari et al. Review Paper on Web Service Security
EP3340096B1 (fr) Procédé de configuration d'un programme cryptographique destiné à être exécuté par un terminal
EP4078922B1 (fr) Procédé d'obtention d'une commande relative à un profil d'accès réseau d'un module de sécurité de type euicc
WO2012156365A1 (fr) Procede de securisation d'une platforme d'authentification, dispositifs materiels et logiciels correspondants
EP1384366B1 (fr) Systeme et procede de communication entre stations traitant des dossiers communs
EP4241416A1 (fr) Procede de delegation d'acces a une chaine de blocs
WO2020193583A1 (fr) Procédé d'exécution de code sécurisé, dispositifs, système et programmes correspondants
EP3912065A1 (fr) Autorisation du chargement d'une application dans un élément de sécurité
FR3108818A1 (fr) Procédé et dispositif d’authentification d’un utilisateur auprès d’une application.
EP3360293A1 (fr) Moyens de gestion d'accès à des données

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 05850576

Country of ref document: EP

Kind code of ref document: A1

WWW Wipo information: withdrawn in national office

Ref document number: 5850576

Country of ref document: EP