WO2006000653A1 - Procede et plate-forme de manipulation de donnees securisees - Google Patents

Procede et plate-forme de manipulation de donnees securisees Download PDF

Info

Publication number
WO2006000653A1
WO2006000653A1 PCT/FR2004/001306 FR2004001306W WO2006000653A1 WO 2006000653 A1 WO2006000653 A1 WO 2006000653A1 FR 2004001306 W FR2004001306 W FR 2004001306W WO 2006000653 A1 WO2006000653 A1 WO 2006000653A1
Authority
WO
WIPO (PCT)
Prior art keywords
format
layer
module
mediation
type
Prior art date
Application number
PCT/FR2004/001306
Other languages
English (en)
Inventor
Loïc HOUSSIER
Anne-Sophie Gironde
Laurent Frisch
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
Priority to PCT/FR2004/001306 priority Critical patent/WO2006000653A1/fr
Publication of WO2006000653A1 publication Critical patent/WO2006000653A1/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 field of the implementation of security functions by computer applications.
  • these applications there may be mentioned, among others, tele-procedure, work management (“workflow”), electronic mail, document publication applications.
  • a security function is a function which provides a level of security based in particular on cryptographic algorithms (symmetric algorithms, asymmetric algorithms, condensation or hash functions, message authentication code, etc.).
  • cryptographic algorithms symmetric algorithms, asymmetric algorithms, condensation or hash functions, message authentication code, etc.
  • the two most common asymmetric algorithms are RSA (“Rivest Shamir Adelman”) and DSA (“Digital Signature Algorithm”).
  • the most used hashing algorithms are SHA-1 and MD5.
  • DES Digital Encryption Standard
  • Triple DES Triple DES
  • AES Advanced Encryption Standard
  • IDEA International Data Encryption Algorithm
  • electronic signature consists of an authentication of an entity and proof of a falsifiable link between a document and the identity of the entity. Encryption helps keep a document confidential. Timestamping makes it possible to guarantee a certain time and to link it by a falsifiable link to a document.
  • the signed data resulting from the standard security function includes a document which typically collects the signature (or the signatures if there are several signatories), information on the algorithms used (for example an asymmetric cryptographic algorithm such as RSA which uses the signer's private key) and possibly other information.
  • a signature is the result of the act of signing carried out by a signatory and is composed of sub-elements comprising the result of the cryptographic calculation, information on the signatory (for example his X.509 certificate or elements making it possible to find this certificate), possibly information on the time of signature, on the context of signature, on the non-revocation of the certificate at the time of signature , etc.
  • the signature elements are then assembled and formatted according to a data format defined in advance, then they are communicated. Indeed, so that the data resulting from a standard security function can be exchanged on the one hand, and stored on the other hand, they must respect a format agreed between the parties using the security function, and adapted to the function of security.
  • These formats are generally standardized but can nevertheless be proprietary.
  • the most used standard formats are: PKCS # 7, published by RSA Security, Inc.
  • RFC 2315 which has been included in CMS ( “Cryptography Message Syntax”, see RFC 2630 of IMETF)
  • PGP corresponding to signed messages originating from the software PGP (“Pretty Good Privacy” marketed by the company Networks Associates Technology, Inc.) and its analogues, XML-DSig, making part of the family of XML data formats ("eXtended Markup Language”) (see RFC 3275), XAdES (“XML Advanced Electronic Signatures”) also belonging to the family of XML data formats and taking into account the clarifications requested by European directives.
  • PKCS # 7, - CMS For encryption, the most used standard formats are: PKCS # 7, - CMS, XLM-Enc being part of the family of XML data formats (see http://www.w3.org/TR/xmlenc-core) , PGP.
  • TSP Time Stamping Profile
  • Some formats use syntaxes based on the international standard ASN.1 ("Abstract Syntax Notation number One"), such as PKCS # 7 and CMS.
  • Others are XML-based, such as XML-DSig, XAdES, XML-Enc.
  • the invention provides a method for handling secure data in a system comprising at least one application calling on security functions in various formats.
  • the method comprises a step according to which the application is organized into an application layer, a format management layer and a mediation layer separating the application and format management layers. Layer of mediation presents to the application layer an interface independent of the format.
  • the format management layer includes at least one formatting module.
  • the method further comprises the steps according to which: - on supply by the application layer to the mediation layer through the format independent interface, of a request relating to formatting comprising an indication of the type of security function and a format indication, a formatting module is selected in the mediation layer as a function of said indications at least, - and a request is made from the mediation layer to the selected formatting module, relating to the type of security function and to the format indicated , for the supply to the application layer of data corresponding to the type of security function indicated and formatted in the format indicated.
  • a method according to the invention makes it possible to manipulate in the application layer secure elements (for example a signed message, an encrypted message etc.) independently of the particular format of these elements.
  • Software applications using the security functions can thus be designed independently of a specific format.
  • the invention provides a platform for handling secure data in a system comprising at least one application using security functions in various formats.
  • the platform comprises an application layer, a format management layer comprising at least one formatting module, a mediation layer disposed between the application layer and the format management layer and presenting to the application layer an interface independent of the format , and means for implementing a method according to the first object of the invention.
  • the single figure represents a system in one embodiment of the invention.
  • a platform 1 for handling secure data in a first embodiment of the invention.
  • the platform 1 comprises an application layer 2 comprising several security functions, such as electronic signature, encryption, cryptographic algorithms implemented in the context of various applications.
  • the platform 1 further comprises a format management layer 4.
  • the platform 1 comprises a mediation layer 3 hereinafter called the Federator, located between the application layer 2 and the format management layer 4.
  • the management layer format 4 includes format management modules 5 to 18. These modules are capable of formatting the set consisting of raw secure data resulting from certain standard security functions in some of the formats suitable for these security functions.
  • the Federator 3 communicates with the application layer 2 via a high-level programming software interface 20 (API, “Application Programming Interface”).
  • API Application Programming Interface
  • This interface is independent of the format used in the exchanges between the Federator 3 and the security functions called in the application layer 2.
  • applications from the application layer 2 transmit via TAPI 20 to the Federator 3 requests that contain separate raw data relating to the typical security functions, awaiting a specific format adapted to the function.
  • An indication of the type of format desired for the formatting of the set consisting of this raw data resulting from the standard security functions is also provided via TAPI 20 to the Federator 3. The latter then selects according to the raw data of the transmitted security function in the request and the format indication received, a module from among modules 5 to 18.
  • the Federator 3 transmits the raw data to the selected formatting module.
  • the indication appearing in the formatting request on the type of format requested for the security function includes the designation of the desired format. It can also include parameters specifying possible format options, for example the precision for a given format of the encoding type (for example BER, binary DER, DER encoded in Base 64, DER encoded in Base 64 with PEM tag) .
  • the Federator 3 communicates with the format management modules via low-level software interfaces. Each module is associated with a respective list of pairs indicating the functions and formats it is able to process. Each pair is made up of a type of safety function and a format corresponding to this type of safety function.
  • the format in a pair of the list of a module of the mediation layer can also be specified by specific parameters. It may for example be the precision for a given format of the type of encoding that the format management module is able to provide.
  • the format management modules according to the embodiment represented in the single figure are capable of constructing data formatted in a certain format, on the basis of a request which is supplied to them by the Federator 3 and comprising raw data relating to a function security, when the couple, made up of this format and this standard security function, appears in the list of couples associated with this module.
  • the Federator 3 lists in a directory 19 all of the lists of couples associated with the modules of the format management layer 4.
  • the Federator 3 as well as the modules 5 to 18 of the management layer of format 4 are produced in Java language (see “The Java Language Specification” published by the company Sun Microsystems, Inc.).
  • the Federator 3 selects from its directory 19 a module from modules 5 to 18, the couples list of which includes the couple (S, F). Then the Federator 3 transmits the raw data to the module of the selected format management layer for formatting in format F.
  • the selected module then processes the request by putting the raw data in the format indicated with specificities if necessary.
  • the list of each module comprises a single pair.
  • the list of a module of the mediation platform 4 could include several couples.
  • the list L5 associated with module 5 is composed of the pair ⁇ Signature, PKCS 7SignedData BER ⁇ .
  • the list L6 associated with module 6 is ⁇ Signature, PKCS # 7SignedData respecting RFC 3126 ⁇ .
  • the L7 list associated with module 7 is ⁇ Encryption, PKCS # 7EnvelopedData ⁇ .
  • the L8 list associated with module 8 is ⁇ Timestamp, PKCS # 7SignedData complying with RFC 3161 ⁇ .
  • the list L9 of module 9 is ⁇ Signature, XMLDSig ⁇ .
  • the list L10 of module 10 is ⁇ Signature, XMLDSig enveloping ⁇ .
  • the list L11 of module 11 is ⁇ Signature, XMLDSig X5O9Data ⁇ .
  • the L12 list of module 12 is ⁇ Signature, XMLDSig RSAKeyValue ⁇ .
  • the list L13 of module 13 is ⁇ Signature, XMLDSig wrapped ⁇ .
  • the list L14 of module 14 is ⁇ Encryption, XMLENC ⁇ .
  • the list L15 of module 15 is ⁇ Signature, XAdES-X ⁇ .
  • the L16 list of module 16 is ⁇ Signature, XAdES-XL ⁇ .
  • the list L17 of module 17 is ⁇ Signature, XAdES-T ⁇ .
  • the list L18 of module 18 is ⁇ Signature, XAdES ⁇ .
  • the Federator therefore selects module 5 whose list L5 contains the pair ⁇ Signature, PKCS # 7SignedData BER ⁇ corresponding to the request received by API 20. Then it relays this request to the selected module 5, which processes the information by formatting it in PKCS # 7SignedData format with BER encoding, then sends the formatted data to Federator 3, which in turn relays it to application layer 2.
  • the Federator 3 receives by the API 20 the following data: the encrypted elements, the encryption algorithm used, the session key and the recipients' certificates.
  • the Federator 3 therefore selects the module 7 whose list L7 contains the pair ⁇ Encryption, PKCS # 7EnvelopedData ⁇ corresponding to the request received by the API 20. Then it relays this request to the selected module 7, which processes the set constituted data received by formatting it in PKCS # 7EnvelopedData format, then sends the formatted security function data to Federator 3, which in turn relays it to application layer 2.
  • Federator 3 receives by API 20 the following raw secure data: time, time signature and signer's certificate in X509 format.
  • the Federator 3 therefore selects the module 8 whose list L8 contains the pair ⁇ Timestamp, PKCS # 7SignedData complying with RFC 3161 ⁇ corresponding to the request received by the API 20. Then it relays this request to the selected module 8, which processes the information by formatting it in PKCS # 7SignedData format complying with RFC 3161, then sends the formatted data to Federator 3, which in turn relays it to application layer 2.
  • applications from the application layer also transmit via the high API to the Federator, requests that contain data relating to standard security functions, formatted according to a security function format and awaiting extraction of the separate raw data corresponding to this formatted data. This type of operation is the reverse of the operations discussed above: this is called "deformatting".
  • the format management layer comprises extraction modules.
  • extraction modules are associated with a list of couples similar to that described above. They are capable of extracting raw data relating to security functions, from a request provided to them by the Federator and comprising formatted data relating to a security function, when the pair made up of this format and this function safety is included in the list of couples associated with this module.
  • the Federator on reception of a request transmitted by the high API and comprising data formatted in a format F 'relating to a security function S' (the format indication relating to the function security is then implicit since it is defined by the formatted data themselves), the Federator selects, in a directory similar to the directory 19 listing modules performing the extraction and each associated with a list of couples (function of security / secure data format), a module among the extraction modules whose list of couples includes the couple (S ', F'). Then the Federator 3 transmits the raw data to the module of the format management layer selected for extraction, via the low API allowing exchanges between the selected module and the Federator.
  • the selected module then processes the request by extracting from the formatted data received, the corresponding separate elements, possibly according to the specificities indicated. It then provides the secure data extracted to the Federator, who then relays it to the application that initiated the request.
  • the modules carrying out the formatting and those carrying out the extraction can be separate modules or not. Some platforms can be dedicated to formatting and only include formatting modules. Conversely, some platforms can be dedicated to extraction and only include extraction modules. Other platforms can perform both formatting and extraction operations. In addition, some platforms may have only one module, performing formatting and / or extraction, in the format management layer. In one implementation mode, the modules can also carry out additional processing before supplying the formatted (or extracted) secure data to the Federator, by using entities linked to the platform 1. They can call especially at cryptographic functions.
  • a module receiving data relating to a signature function can add to this data before formatting it, a timestamp token.
  • the selection of a module of the management layer by the Federator will be done as a function of the security type function, of the format indication indicated for the result of the security function as indicated above, and further depending on the format of some of the data provided via the high API to the Federator.
  • the list of each module will include pairs each composed of a security function format (with options possibly specified, for example the desired encoding as described above) and of a standard security function with specified options relating to the formats accepted by the module for each of the separate elements, the whole of which constitutes the data, the set of data having to be formatted by the module.
  • a certificate is delivered.
  • the certificate can be provided in several formats: X509, PGP etc.
  • This arrangement thus makes it possible to select a module capable of processing the format of the data received.
  • the format management layer does not directly manipulate the raw secure data to format or formatted secure data from which raw data must be extracted. But the modules of the format management layer associated with respective lists of couples are able to create objects within the meaning of Object Oriented Programming (OOP), which are then directly managed by the applications.
  • OOP Object Oriented Programming
  • Each object is associated with a unique pair (S, F) from the list of the module that created it. If it is designed to format data, it will know how to format in raw format separate raw data relating to the security function S, which will be supplied to it. If it is designed to extract data, it will be able to extract from data formatted in format F, the separate raw data relating to the corresponding security function S.
  • an application transmits to the Federator a request relating to the formatting (or even to the extraction) and comprising the indication of a type of function S1 (signature, encryption, timestamp ... ) and an F1 data format corresponding to this typical security function.
  • the federator selects, in the same way as that described with reference to the single figure, a module of the format management layer from a directory similar to the directory 19 obtained by a census of the modules of the management layer and transmits to it a request including the indication of the standard security function and the format.
  • the selected module then defines an object corresponding to the format F1 and to the security function type S1, creates the object and supplies the object created to the Federator, who then takes care of making it available to the application on the initiative of the request. Data exchanges then take place directly between the application and the object.
  • the raw data relating to the security function F1 associated with the object is supplied to it by the application.
  • the object processes this data and then returns the data formatted in F1 format directly to the application.
  • the data secured in format F1 of security function S1 and relating to security function S1 is supplied to this object by the application directly.
  • the object processes this data and then returns the raw data relating to the security function S1 directly to the application.
  • the present invention makes it possible to manipulate in the application layer secure elements resulting from the security function independently of the particular output format finally retained for the security function. Taking into account a new format comes down to the creation of a new module adapted in the mediation layer; the applications in which we wish to use this new format do not have to be re-developed. The consideration of a new application is treated in the application layer only. Thus the impact of format or application modifications on software developments is significantly reduced

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)
  • Storage Device Security (AREA)

Abstract

Procédé de manipulation de données sécurisées dans un système comportant des applications faisant appel à des fonctions de sécurité selon des formats variés, comportant les étapes selon lesquelles on organise l’application en une couche applicative (2), une couche de gestion de format (4) comportant au moin un module de formatage ; et une couche de médiation (3) séparant lesdites couches applicative et de gestion de format, la couche de médiation présentant à la couche applicative une interface (20) indépendante du format : sur fourniture par la couche applicative à la couche de médiation à travers l’interface indépendante du format, d’une requête de formatage indiquant un type de fonction de sécurité et un format, on sélectionne dans la couche de médiation un module de formatage (5-18) et on présente depuis la couche de médiation au module de formatage sélectionné, une requête relative au type de fonction de sécurité et au format indiqués, pour la fourniture à la couche applicative de données formatées au format indiqué.

Description

PROCEDE ET PLATE-FORME DE MANIPULATION DE DONNEES SECURISEES
La présente invention concerne le domaine de la mise en œuvre de fonctions de sécurité par des applications informatiques. Parmi ces applications, on peut citer entre autres, des applications de télé-procédure, de gestion de travaux (« workflow »), de courrier électronique, de publication de documents. Une fonction de sécurité est une fonction qui apporte un niveau de sécurité en reposant notamment sur des algorithmes cryptographiques (algorithmes symétriques, algorithmes asymétriques, fonctions de condensation ou hachage, code d'authentification de messages, etc). Les deux algorithmes asymétriques les plus répandus sont RSA (« Rivest Shamir Adelman ») et DSA (« Digital Signature Algorithm »). Les algorithmes de hachage les plus utilisés sont le SHA-1 et MD5. Parmi les algorithmes symétriques les plus répandus figurent DES (« Digital Encryption Standard »), Triple DES, AES (« Adavanced Encryption Standard »), IDEA (« International Data Encryption Algorithm »). Parmi les fonctions de sécurité qui reposent sur des algorithmes cryptographiques asymétriques figurent par exemple la signature électronique, la vérification de signature électronique, le chiffrement, le déchiffrement, l'horodatage, la vérification d'horodatage. La signature électronique consiste en une authentification d'une entité et une preuve d'un lien infalsifiable entre un document et l'identité de l'entité. Le chiffrement permet de garantir la confidentialité d'un document. L'horodatage permet de garantir une certaine heure et de la lier par un lien infalsifiable à un document. Dans le cas d'une application utilisant la signature électronique, les données signées résultant de la fonction de sécurité type comportent un document qui rassemble typiquement la signature (ou les signatures s'il y a plusieurs signataires), des informations sur les algorithmes utilisés ( par exemple un algorithme cryptographique asymétrique tel que RSA qui utilise la clé privée du signataire) et éventuellement d'autres informations. Une signature est le résultat de l'acte de signer effectué par un signataire et est composée de sous-éléments comportant le résultat du calcul cryptographique, des informations sur le signataire (par exemple son certificat X.509 ou des éléments permettant de retrouver ce certificat), éventuellement des informations sur l'heure de signature, sur le contexte de signature, sur la non- révocation du certificat au moment de la signature, etc. Les éléments de signature sont ensuite assemblés et mis en forme selon un format de données défini à l'avance, puis ils sont communiqués. En effet, afin que les données résultant d'une fonction de sécurité type puissent être échangées d'une part, et conservées d'autre part, elles doivent respecter un format convenu entre les parties utilisant la fonction de sécurité, et adapté à la fonction de sécurité. Ces formats sont en général standardisés mais peuvent néanmoins être propriétaires. Pour la signature électronique, les formats standards les plus utilisés sont : PKCS#7, publié par la société RSA Security, Inc. et par l'Internet Engineering Task Force (IETF) en tant que RFC 2315, qui a été repris dans CMS (« Cryptographie Message Syntax », voir RFC 2630 de IMETF), PGP, correspondant aux messages signés issus du logiciel PGP (« Pretty Good Privacy » commercialisé par la société Networks Associates Technology, Inc.) et de ses analogues, XML-DSig, faisant partie de la famille des formats de données XML (« eXtended Markup Language ») (voir RFC 3275), XAdES ("XML Advanced Electronic Signatures") faisant également partie de la famille des formats de données XML et prenant en compte des précisions demandées par des directives européennes. Pour le chiffrement, les formats standards les plus utilisés sont : PKCS#7, - CMS, XLM-Enc faisant partie de la famille des formats de données XML (voir http://www.w3.org/TR/xmlenc-core), PGP. Pour l'horodatage, le format standard le plus utilisé est TSP (« Time Stamping Profile », voir RFC 3161). Certains formats utilisent des syntaxes à base de la norme internationale ASN.1 (« Abstract Syntax Notation number One »), comme PKCS#7 et CMS. D'autres sont à base de XML, comme XML-DSig, XAdES, XML-Enc. Il existe en outre des formats définis à partir de types de syntaxes standards moins connus, voire des formats propriétaires, parfois publiés. Dans la mise en œuvre de fonctions de sécurité dans des applications informatiques dans l'art antérieur, le traitement des données sécurisées dépend fortement du format de ces données. Une fonction est irrémédiablement liée à un format de données particulier. Un développeur de services sécurisés n'implémente ses fonctions de sécurité qu'en connaissant le format souhaité des données en sortie. Or les processus de traitement sont les mêmes. Par exemple, on vérifie toujours une signature électronique de la même façon, qu'elle ait été véhiculée au format CMS ou au format XML-DSig. Dans tous les cas, on valide le ou les certificats du ou des signataires. On vérifie la signature cryptographique. On peut en outre vérifier des éléments complémentaires (heure de signature, etc.), et ce, quel que soit le format de données retenu. Le fait qu'une application faisant appel à des fonctions de sécurité soit développée et implémentée en étant liée d'office à un format spécifique implique des développements importants spécifiques pour un même type d'application faisant appel à différents formats ou encore lors de l'apparition d'un nouveau format. Il en résulte que les travaux de développement sont lourds et peuvent prendre beaucoup de temps. Un but de la présente invention est de pallier ces limitations de l'art antérieur. A cette fin, suivant un premier objet, l'invention propose un procédé de manipulation de données sécurisées dans un système comportant au moins une application faisant appel à des fonctions de sécurité selon des formats variés. Le procédé comporte une étape selon laquelle on organise l'application en une couche applicative, une couche de gestion de format et une couche de médiation séparant les couches applicative et de gestion de format. La couche de médiation présente à la couche applicative une interface indépendante du format. La couche de gestion de format comporte au moins un module de formatage. Le procédé comporte en outre les étapes selon lesquelles : - sur fourniture par la couche applicative à la couche de médiation à travers l'interface indépendante du format, d'une requête relative à du formatage comportant une indication de type de fonction de sécurité et une indication de format, on sélectionne dans la couche de médiation un module de formatage en fonction desdites indications au moins, - et on présente depuis la couche de médiation au module de formatage sélectionné, une requête relative au type de fonction de sécurité et au format indiqués, pour la fourniture à la couche applicative de données correspondant au type de fonction de sécurité indiqué et formatées au format indiqué. Ainsi un procédé selon l'invention permet de manipuler dans la couche applicative des éléments sécurisés (par exemple un message signé, un message chiffré etc) indépendamment du format particulier de ces éléments. Les applications logicielles utilisant les fonctions de sécurité peuvent ainsi être conçues indépendamment d'un format spécifique. Ceci permet en outre de faire migrer ces applications aisément d'un format à l'autre et de prendre en compte facilement un nouveau format. Un tel procédé permet également de faire coopérer aisément des applications distinctes. Suivant un second objet, l'invention propose une plate-forme de manipulation de données sécurisées dans un système comportant au moins une application faisant appel à des fonctions de sécurité selon des formats variés. La plate-forme comporte une couche applicative, une couche de gestion de format comportant au moins un module de formatage, une couche de médiation disposée entre la couche applicative et la couche de gestion de format et présentant à la couche applicative une interface indépendante du format, et des moyens pour mettre en œuvre un procédé selon le premier objet de l'invention. D'autres caractéristiques et avantages de l'invention apparaîtront encore à la lecture de la description qui va suivre. Celle-ci est purement illustrative et doit être lue en regard des dessins annexés sur lesquels : la figure unique représente un système dans un mode de réalisation de l'invention. Sur la figure unique est représentée une plate-forme 1 de manipulation de données sécurisées dans un premier mode de réalisation de l'invention. La plate-forme 1 comporte une couche applicative 2 comportant plusieurs fonctions de sécurité, telles que signature électronique, chiffrement, algorithmes cryptographiques mises en œuvre dans le cadre d'applications diverses. La plate forme 1 comporte en outre une couche de gestion de format 4. La plate forme 1 comporte une couche de médiation 3 ci-après nommé Fédérateur, située entre la couche applicative 2 et la couche de gestion de format 4. La couche de gestion de format 4 comporte des modules de gestion de format 5 à 18. Ces modules sont aptes à formater l'ensemble constitué des données sécurisées brutes résultant de certaines fonctions de sécurité type dans certains des formats adaptés à ces fonctions de sécurité. Le Fédérateur 3 communique avec la couche applicative 2 par l'intermédiaire d'une interface logicielle de programmation 20 (API, « Application Programming Interface ») de haut niveau. Cette interface est indépendante du format retenu dans les échanges entre le Fédérateur 3 et les fonctions de sécurité appelées dans la couche applicative 2. Dans le mode de réalisation représenté en figure unique, des applications de la couche applicative 2 transmettent via TAPI 20 au Fédérateur 3 des requêtes qui contiennent des données brutes séparées relatives aux fonctions de sécurité type, en attente d'une mise à un format spécifique adapté à la fonction. Une indication sur le type de format souhaité pour la mise en forme de l'ensemble constitué de ces données brutes résultant des fonctions de sécurité type est également fournie via TAPI 20 au Fédérateur 3. Celui-ci sélectionne ensuite en fonction des données brutes de la fonction de sécurité transmises dans la requête et de l'indication de format reçues, un module parmi les modules 5 à 18. Puis le Fédérateur 3 transmet les données brutes au module de formatage sélectionné. L'indication figurant dans la requête de formatage sur le type de format demandé pour la fonction de sécurité comporte la désignation du format souhaité. Elle peut en outre comporter des paramètres spécifiant des options possibles du format, par exemple la précision pour un format donné du type d'encodage ( par exemple BER, DER binaire, DER encodé en Base 64, DER encodé en Base 64 avec balise PEM). Le Fédérateur 3 communique avec les modules de gestion de formats par l'intermédiaire d'interfaces logicielles de niveau bas. A chaque module est associée une liste respective de couples indiquant les fonctions et formats qu'il est apte à traiter. Chaque couple est composé d'un type de fonction de sécurité et d'un format correspondant à ce type de fonction de sécurité. Le format dans un couple de la liste d'un module de la couche de médiation peut en outre être précisé par des paramètres spécifiques. Il peut s'agir par exemple de la précision pour un format donné du type d'encodage que le module de gestion de format est apte à fournir. Les modules de gestion de format selon le mode de réalisation représenté en figure unique sont capables de construire des données formatées à un certain format, à partir d'une requête qui leur est fournie par le Fédérateur 3 et comportant des données brutes relatives à une fonction de sécurité, quand le couple, composé de ce format et de cette fonction de sécurité type, figure dans la liste de couples associée à ce module. Lors d'une initialisation de la plate-forme 1 , le Fédérateur 3 recense dans un annuaire 19 l'ensemble des listes de couples associées aux modules de la couche de gestion de format 4. Dans le mode de réalisation considéré sur la figure unique, le Fédérateur 3 ainsi que les modules 5 à 18 de la couche de gestion de format 4 sont réalisés en langage Java (voir « The Java Language Spécification » publié par la société Sun Microsystems, Inc.). Sur réception d'une requête transmise par l'API 20 et comportant des données brutes à formater selon un format F (éventuellement complété par des paramètres précisant des options du format de sortie) indiqué et relatives à une fonction de sécurité S, le Fédérateur 3 sélectionne dans son annuaire 19 un module parmi les modules 5 à 18, dont la liste de couples comporte le couple (S, F). Puis le Fédérateur 3 transmet les données brutes au module de la couche de gestion de format sélectionné pour formatage au format F. Le module sélectionné traite alors la requête en mettant au format indiqué avec des spécificités le cas échéant, les données brutes. Il fournit par la suite les données sécurisées formatées au Fédérateur 3, qui les relaie ensuite à la fonction de sécurité qui avait initié la requête. Dans le mode de réalisation représenté en figure unique, la liste de chaque module comporte un unique couple. Dans un mode de mise en œuvre différent de l'invention, la liste d'un module de la plate-forme de médiation 4 pourrait comporter plusieurs couples. Ainsi la liste L5 associée au module 5 est composé du couple {Signature, PKCS#7SignedData BER}. La liste L6 associée au module 6 est {Signature, PKCS#7SignedData respectant la RFC 3126}. La liste L7 associée au module 7 est {Chiffrement, PKCS#7EnvelopedData}. La liste L8 associée au module 8 est {Horodatage, PKCS#7SignedData respectant la RFC 3161}. La liste L9 du module 9 est {Signature, XMLDSig}. La liste L10 du module 10 est {Signature, XMLDSig enveloppante}. La liste L11 du module 11 est {Signature, XMLDSig X5O9Data}. La liste L12 du module 12 est {Signature, XMLDSig RSAKeyValue}. La liste L13 du module 13 est {Signature, XMLDSig enveloppée}. La liste L14 du module 14 est {Chiffrement, XMLENC}. La liste L15 du module 15 est {Signature, XAdES-X}. La liste L16 du module 16 est {Signature, XAdES-X-L}. La liste L17 du module 17 est {Signature, XAdES-T}. La liste L18 du module 18 est {Signature, XAdES}. Lors d'une requête pour une mise au format PKCS#7SignedData précisant que l'encodage doit être de type BER, une fonction type de signature va transmettre au Fédérateur 3 les données suivantes : les éléments signés, la signature proprement dite et le certificat au format X509. Le Fédérateur sélectionne donc le module 5 dont la liste L5 contient le couple {Signature, PKCS#7SignedData BER} correspondant à la requête reçue par l'API 20. Puis il relaie cette requête vers le module 5 sélectionné, lequel traite les informations en les formatant au format PKCS#7SignedData avec encodage BER, puis envoie les données formatées au Fédérateur 3, qui les relaie à son tour à la couche applicative 2. Lors d'une requête pour une mise au format PKCS#7EnvelopedData relative à une fonction de chiffrement, le Fédérateur 3 reçoit par l'API 20 les données suivantes : les éléments chiffrés, l'algorithme de chiffrement utilisé, la clef de session et les certificats des destinataires. Le Fédérateur 3 sélectionne donc le module 7 dont la liste L7 contient le couple {Chiffrement, PKCS#7EnvelopedData} correspondant à la requête reçue par l'API 20. Puis il relaie cette requête vers le module 7 sélectionné, lequel traite l'ensemble constitué des données reçues en le formatant au format PKCS#7EnvelopedData, puis envoie les données de la fonction de sécurité formatées au Fédérateur 3, qui les relaie à son tour à la couche applicative 2. Lors d'une autre requête pour une mise au format PKCS#7SignedData respectant la RFC 3161 relative à une fonction d'horodatage, le Fédérateur 3 reçoit par l'API 20 les données sécurisées brutes suivantes : l'heure, la signature de l'heure et le certificat du signataire au format X509. Le Fédérateur 3 sélectionne donc le module 8 dont la liste L8 contient le couple {Horodatage, PKCS#7SignedData respectant la RFC 3161} correspondant à la requête reçue par l'API 20. Puis il relaie cette requête vers le module 8 sélectionné, lequel traite les informations en les formatant au format PKCS#7SignedData respectant la RFC 3161 , puis envoie les données formatées au Fédérateur 3, qui les relaie à son tour à la couche applicative 2. Dans un mode de réalisation, des applications de la couche applicative transmettent également via l'API haute au Fédérateur des requêtes qui contiennent des données relatives à des fonctions de sécurité types, formatées selon un format de fonction de sécurité et en attente d'une extraction des données brutes séparées correspondant à ces données formatées. Ce type d'opérations constituent l'inverse des opérations commentées ci-avant : il s'agit ici d'un « déformatage ». Dans un tel mode de réalisation, la couche de gestion de format comprend des modules d'extraction. De tels modules d'extraction sont associés à une liste de couples similaire à celle décrite plus haut. Ils sont capables d'extraire des données brutes relatives à des fonctions de sécurité, à partir d'une requête qui leur est fournie par le Fédérateur et comportant des données formatées relatives à une fonction de sécurité, quand le couple composé de ce format et de cette fonction de sécurité figure dans la liste de couples associée à ce module. De la même façon que décrit ci-dessus, sur réception d'une requête transmise par l'API haute et comportant des données formatées selon un format F' relatives à une fonction de sécurité S' (l'indication de format relatif à la fonction de sécurité est alors implicite puisqu'il est défini par les données formatées elles-mêmes), le Fédérateur sélectionne, dans un annuaire similaire à l'annuaire 19 recensant des modules réalisant l'extraction et associés chacun à une liste de couples (fonction de sécurité/format de données sécurisées), un module parmi les modules d'extraction dont la liste de couples comporte le couple (S', F'). Puis le Fédérateur 3 transmet les données brutes au module de la couche de gestion de format sélectionné pour extraction, via l'API basse permettant les échanges entre le module sélectionné et le Fédérateur. Le module sélectionné traite alors la requête en extrayant à partir des données formatées reçues, les éléments séparés correspondants, selon éventuellement des spécificités indiquées. Il fournit par la suite les données sécurisées extraites au Fédérateur, qui les relaie ensuite à l'application qui avait initié la requête. Les modules réalisant le formatage et ceux réalisant l'extraction peuvent être des modules séparés ou non. Certaines plates-formes peuvent être dédiées au formatage et ne comporter que des modules de formatage. Inversement, certaines plates-formes peuvent être dédiées à l'extraction et ne comporter que des modules d'extraction. D'autres plates-formes peuvent réaliser à la fois des opérations de formatage et d'extraction. De plus, certaines plates-formes peuvent ne comporter qu'un unique module, réalisant le formatage et/ou l'extraction, dans la couche de gestion de format. Dans un mode de mise en œuvre, les modules peuvent en outre réaliser des traitements supplémentaires avant de fournir les données sécurisées formatées (ou extraites) au Fédérateur, en faisant appel à des entités en liaison avec la plate-forme 1. Ils peuvent faire appel notamment à des fonctions cryptographiques. Par exemple, un module recevant des données relatives à une fonction de signature peut ajouter à ces données avant de les formater, un jeton d'horodatage. Dans un mode de mise en œuvre particulier, la sélection d'un module de la couche de gestion par le Fédérateur se fera en fonction de la fonction type de sécurité, de l'indication de format indiqué pour le résultat de la fonction de sécurité comme indiqué ci-dessus, et en outre en fonction du format de certaines des données fournies via l'API haute au Fédérateur. Ainsi la liste de chaque module comportera des couples composés chacun d'un format de fonction de sécurité (avec des options éventuellement précisées par exemple l'encodage souhaité comme décrit plus haut) et d'une fonction de sécurité type avec des options précisées portant sur les formats acceptés par le module pour chacun des éléments séparés dont l'ensemble constitue les données, l'ensemble de données devant être formaté par le module. Par exemple, lors de la fourniture au Fédérateur par la couche applicative, des données sécurisées brutes relatives à une signature, un certificat est remis. Le certificat peut être fourni sous plusieurs formats : X509, PGP etc. Cette disposition permet ainsi de sélectionner un module capable de traiter le format des données reçues. Dans un mode de mise en œuvre différent mettant en œuvre le même type d'architecture en trois couches selon l'invention, qui permet de dissocier les aspects applicatifs des aspects de gestion de format, la couche de gestion de format ne manipule pas directement les données sécurisées brutes à formater ou encore les données sécurisées formatées dont il faut extraire les données brutes. Mais les modules de la couche de gestion de format associés à des listes respectives de couples sont aptes à créer des objets au sens de la Programmation Orientée Objet (POO), qui sont ensuite directement gérés par les applications. Chaque objet est associé à un unique couple (S, F) de la liste du module qui l'a créé. Il saura, s'il est conçu pour formater des données, formater au format F des données séparées brutes relatives à la fonction de sécurité S, qui lui seront fournies. S'il est conçu pour extraire des données, il saura extraire de données formatées au format F, les données séparées brutes relatives à la fonction de sécurité S correspondantes. Dans un tel mode de réalisation de l'invention, une application transmet au Fédérateur une requête relative au formatage (ou encore à l'extraction) et comportant l'indication d'un type de fonction S1 (signature, chiffrement, horodatage ...) et un format de données F1 correspondant à cette fonction de sécurité type. Le fédérateur sélectionne, de la même manière que celle décrite en référence à la figure unique, un module de la couche de gestion de format depuis un annuaire similaire à l'annuaire 19 obtenu par un recensement des modules de la couche de gestion et lui transmet une requête comportant l'indication de la fonction de sécurité type et du format. Le module sélectionné définit alors un objet correspondant au format F1 et à la fonction de sécurité type S1 , crée l'objet et fournit l'objet créé au Fédérateur, qui se charge alors de le mettre à disposition de l'application à l'initiative de la requête. Les échanges de données ont lieu ensuite directement entre l'application et l'objet. Dans le cas du formatage, les données brutes relatives à la fonction de sécurité F1 associée à l'objet lui sont fournies par l'application. L'objet traite ces données et retourne ensuite les données formatées au format F1 directement à l'application. Dans le cas de l'extraction, les données sécurisées au format F1 de fonction de sécurité S1 et relatives à la fonction de sécurité S1 sont fournies à cet objet par l'application directement. L'objet traite ces données et retourne ensuite les données brutes relatives à la fonction de sécurité S1 directement à l'application. Ainsi la présente invention permet de manipuler dans la couche applicative des éléments sécurisés résultant de fonction de sécurité indépendamment du format de sortie particulier finalement retenu pour la fonction de sécurité. La prise en compte d'un nouveau format se résume à la constitution d'un nouveau module adapté dans la couche de médiation ; les applications dans lesquelles on souhaite utiliser ce nouveau format n'ont pas à être re-développées. La prise en compte d'une nouvelle application se traite en couche applicative uniquement. Ainsi les impacts de modifications de format ou d'applications sur les développements logiciels sont nettement diminués

Claims

REVENDICATIONS
1. Procédé de manipulation de données sécurisées dans un système comportant au moins une application faisant appel à des fonctions de sécurité selon des formats variés,
ledit procédé comportant une étape selon laquelle :
- on organise l'application en une couche applicative (2), une couche de gestion de format (4) et une couche de médiation (3) séparant lesdites couches applicative et de gestion de format, ladite couche de médiation présentant à la couche applicative une interface (20) indépendante du format et ladite couche de gestion de format comportant au moins un module de formatage ;
ledit procédé comportant en outre les étapes selon lesquelles :
- sur fourniture par la couche applicative à la couche de médiation à travers l'interface indépendante du format, d'une requête relative à du formatage comportant une indication de type de fonction de sécurité et une indication de format, on sélectionne dans la couche de médiation un module de formatage (5-18) en fonction d'au moins lesdites indications,
- et on présente depuis la couche de médiation au module de formatage sélectionné, une requête relative au type de fonction de sécurité et au format indiqués, pour la fourniture à la couche applicative de données correspondant au type de fonction de sécurité indiqué et formatées au format indiqué.
2. Procédé selon la revendication 1 , selon lequel la requête présentée par la couche de médiation (2) à un module de formatage (5-18) sélectionné comporte des données sécurisées brutes relatives au type de fonction de sécurité indiqué, le procédé comportant en outre les étapes selon lesquelles : - au sein du module de formatage sélectionné, on formate au format indiqué les données sécurisées brutes relatives au type de fonction de sécurité indiqué,
- et on fournit les données formatées à la couche de médiation (3), qui les délivre à la couche applicative (2).
3. Procédé selon la revendication 1 , selon lequel suite à la requête présentée par la couche de médiation (3) à un module de formatage (5-18) sélectionné
- on définit et on crée un objet dans ledit module de formatage,
- et on le délivre à la couche de médiation qui le fournit à la couche applicative (2), ledit objet étant apte à transformer au format indiqué des données sécurisées brutes relatives au type de fonction de sécurité indiquée qui lui sont présentées.
4. Procédé selon l'une quelconque des revendications précédentes, selon lequel la couche de gestion de format (4) comporte en outre au moins un module d'extraction,
ledit procédé comportant en outre les étapes selon lesquelles :
- sur fourniture par la couche applicative (2) à la couche de médiation (3) à travers l'interface (20) indépendante du format, d'une requête relative à de l'extraction comportant une indication de type de fonction de sécurité et une indication de format, on sélectionne dans la couche de médiation un module d'extraction,
- et on présente depuis la couche de médiation au module d'extraction sélectionné, une requête relative au type de fonction de sécurité et au format indiqués, pour la fourniture à la couche applicative de données correspondant au type de fonction de sécurité indiqué et extraites conformément au format indiqué.
5. Procédé selon la revendication 4, selon lequel la requête relative à l'extraction présentée par la couche de médiation (3) au module d'extraction sélectionné comporte en outre des données sécurisées relatives au type de fonction de sécurité indiqué qui sont formatées selon un format donné, le procédé comportant en outre les étapes selon lesquelles :
- au sein du module d'extraction sélectionné, on extrait les données sécurisées brutes relatives au type de fonction de sécurité indiqué,
- et on fournit les données brutes à la couche de médiation, qui les délivre à la couche applicative.
6. Procédé selon la revendication 4, selon lequel suite à la requête d'extraction présentée par la couche de médiation (3) à un module d'extraction sélectionné,
- on définit et on créé, au sein dudit module d'extraction, un objet ;
- on fournit à la couche de médiation ledit objet ;
- et la couche de médiation fournit ledit objet à la couche applicative, ledit objet étant apte à extraire depuis des données sécurisées formatées qui lui sont présentées au format indiqué, des données sécurisées brutes relatives au type de fonction de sécurité indiqué.
7. Procédé selon l'une quelconque des revendications 4 à 6 selon lequel l'indication de format est définie par les données formatées elles-mêmes.
8. Procédé selon l'une quelconque des revendications précédentes, selon lequel
- on associe à chaque module (5-18) de la couche (4) de gestion de format à une liste (L5-L18) respective de couples, chaque couple étant composé d'un type de fonction de sécurité et d'un format, - et l'étape de sélection d'un module par la couche de médiatioh est telle que ledit type de fonction et ledit format indiqué correspond à un couple de la liste associée audit module sélectionné.
9. Procédé selon l'une quelconque des revendications précédentes, selon lequel on effectue, depuis la couche de médiation (3) et auprès des modules (5-18) de la couche de gestion de format, un recensement des listes (L5-L18) de couples et on sélectionne dans la couche de médiation les modules en fonction des listes recensées.
10. Plate-forme (1) de manipulation de données sécurisées dans un système comportant au moins une application faisant appel à des fonctions de sécurité selon des formats variés, ladite plate-forme comportant :
- une couche applicative (2),
- une couche de gestion de format (4) comportant au moins un rnodule de formatage (5-18),
- une couche de médiation (3) disposée entre ladite couche applicative et ladite couche de gestion de format et présentant à la couche applicative une interface (20)indépendante du format ,
ladite plate-forme comportant des moyens pour mettre en oeuvre un procédé selon l'une des revendications 1 , 2, 3, 8, 9.
11. Plate-forme selon la revendication 10, dans laquelle la couche de gestion comporte en outre au moins un module d'extraction, ladite plate-forme comportant en outre des moyens pour mettre en œuvre un procédé selon l'une des revendications 4 à 9.
PCT/FR2004/001306 2004-05-26 2004-05-26 Procede et plate-forme de manipulation de donnees securisees WO2006000653A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/FR2004/001306 WO2006000653A1 (fr) 2004-05-26 2004-05-26 Procede et plate-forme de manipulation de donnees securisees

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/FR2004/001306 WO2006000653A1 (fr) 2004-05-26 2004-05-26 Procede et plate-forme de manipulation de donnees securisees

Publications (1)

Publication Number Publication Date
WO2006000653A1 true WO2006000653A1 (fr) 2006-01-05

Family

ID=34958342

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2004/001306 WO2006000653A1 (fr) 2004-05-26 2004-05-26 Procede et plate-forme de manipulation de donnees securisees

Country Status (1)

Country Link
WO (1) WO2006000653A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100859030B1 (ko) * 2006-12-06 2008-09-17 엘지이노텍 주식회사 엘이디 백라이트유닛

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5119465A (en) * 1989-06-19 1992-06-02 Digital Equipment Corporation System for selectively converting plurality of source data structures through corresponding source intermediate structures, and target intermediate structures into selected target structure
WO2000052875A1 (fr) * 1999-03-01 2000-09-08 Maz Technologies, Inc. Cryptage et decryptage transparents a l'aide d'un moteur cryptographique ne dependant pas d'algorithmes et permettant une conteneurisation des fichiers cryptes
WO2000057613A1 (fr) * 1999-03-22 2000-09-28 Microvault Corp. Procede et appareil permettant de securiser un systeme de transmission de donnees
EP1091536A2 (fr) * 1999-10-04 2001-04-11 Microsoft Corporation Procedées et systèmes pour la conversion du format des données
WO2001046773A2 (fr) * 1999-12-20 2001-06-28 Evelocity Corporation Procede et dispositif de transmission de donnees
WO2003036887A1 (fr) * 2001-10-25 2003-05-01 Research In Motion Limited Systeme et procede en plusieurs phases pour le traitement de messages codes
US20030152220A1 (en) * 2000-04-28 2003-08-14 Dake He Digital data transforming method

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5119465A (en) * 1989-06-19 1992-06-02 Digital Equipment Corporation System for selectively converting plurality of source data structures through corresponding source intermediate structures, and target intermediate structures into selected target structure
WO2000052875A1 (fr) * 1999-03-01 2000-09-08 Maz Technologies, Inc. Cryptage et decryptage transparents a l'aide d'un moteur cryptographique ne dependant pas d'algorithmes et permettant une conteneurisation des fichiers cryptes
WO2000057613A1 (fr) * 1999-03-22 2000-09-28 Microvault Corp. Procede et appareil permettant de securiser un systeme de transmission de donnees
EP1091536A2 (fr) * 1999-10-04 2001-04-11 Microsoft Corporation Procedées et systèmes pour la conversion du format des données
WO2001046773A2 (fr) * 1999-12-20 2001-06-28 Evelocity Corporation Procede et dispositif de transmission de donnees
US20030152220A1 (en) * 2000-04-28 2003-08-14 Dake He Digital data transforming method
WO2003036887A1 (fr) * 2001-10-25 2003-05-01 Research In Motion Limited Systeme et procede en plusieurs phases pour le traitement de messages codes

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100859030B1 (ko) * 2006-12-06 2008-09-17 엘지이노텍 주식회사 엘이디 백라이트유닛

Similar Documents

Publication Publication Date Title
EP1072124B1 (fr) Procede de verification de l'usage de cles publiques engendrees par un systeme embarque
CA2221016C (fr) Procede de recuperation de cles mis en oeuvre pour un chiffrement fort de message
US20080098227A1 (en) Method of enabling secure transfer of a package of information
WO2009130089A1 (fr) Procede de diffusion securisee de donnees numeriques vers un tiers autorise
FR2952778A1 (fr) Procede de transmission de donnees securise et systeme de chiffrement et de dechiffrement permettant une telle transmission
FR2746566A1 (fr) Methode pour etablir des communications securisees et systeme de chiffrement/dechiffrement associe
US8422673B2 (en) Method and system for protecting against unity keys
CN1832398A (zh) 文件加密共享的方法和系统
FR2930391A1 (fr) Terminal d'authentification d'un utilisateur.
WO2018211026A1 (fr) Procede de securisation d'une communication sans gestion d'etats
WO2006000653A1 (fr) Procede et plate-forme de manipulation de donnees securisees
EP1506480B1 (fr) Procede de controle d'acces a des ressources cryptographiques
WO2019180335A1 (fr) Procede d'emission de donnees depuis un vehicule automobile et procede de reception desdites donnees par un autre vehicule, a travers un canal de communication radio
EP1506479A2 (fr) Procede pour accomplir des fonctions cryptographiques dans une application informatique
EP1992104B1 (fr) Authentification d'un dispositif informatique au niveau utilisateur
EP1642413B1 (fr) Procede de chiffrement/dechiffrement d un message et disposi tif associe
WO2021156078A1 (fr) Procédé et dispositif d'évaluation de correspondance d'ensembles de données structurées protégées par le chiffrement
EP1280295A1 (fr) Procédé pour le transfert securisé d'un paquet d'informations
WO2021240120A1 (fr) Procede de derivation d'une signature partielle avec verification partielle
EP4340292A1 (fr) Adaptation dynamique du format de transmission d'un chiffrement de données basé sur les attributs
FR3141020A1 (fr) Procédé de mise en œuvre d’un service d’une chaîne de services et dispositif électronique associé
WO2023203301A1 (fr) Procédé et système de gestion des droits d'accès dans une transaction équitable de données numériques
FR3141021A1 (fr) Procédé de mise en œuvre d’un service d’une chaîne de services et dispositif électronique associé
AU2007200817A1 (en) A method of enabling secure transfer of a package of information
FR3102024A1 (fr) Procédé de gestion d’une base de données de clés publiques, procédé d’authentification de clés publiques, et dispositifs serveur et client mettant en œuvre ces procédés

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

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

WWW Wipo information: withdrawn in national office

Country of ref document: DE

122 Ep: pct application non-entry in european phase