WO2006048515A1 - Procede et systeme de communiction entre un dispositif de stockage securise d’informations et au moins un tiers, entite, dispositif et tiers correspondants - Google Patents

Procede et systeme de communiction entre un dispositif de stockage securise d’informations et au moins un tiers, entite, dispositif et tiers correspondants Download PDF

Info

Publication number
WO2006048515A1
WO2006048515A1 PCT/FR2005/002233 FR2005002233W WO2006048515A1 WO 2006048515 A1 WO2006048515 A1 WO 2006048515A1 FR 2005002233 W FR2005002233 W FR 2005002233W WO 2006048515 A1 WO2006048515 A1 WO 2006048515A1
Authority
WO
WIPO (PCT)
Prior art keywords
party
secure container
given
authorization
communicate
Prior art date
Application number
PCT/FR2005/002233
Other languages
English (en)
Inventor
Jean-Pierre Le Rouzic
Gilles Macario-Rat
Thierry Leclercq
Vincent Barnaud
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 JP2007538459A priority Critical patent/JP5595636B2/ja
Priority to AT05805605T priority patent/ATE534224T1/de
Priority to EP20050805605 priority patent/EP1805965B1/fr
Priority to KR1020077011679A priority patent/KR101276092B1/ko
Priority to US11/666,585 priority patent/US8739267B2/en
Priority to CN2005800374259A priority patent/CN101073239B/zh
Publication of WO2006048515A1 publication Critical patent/WO2006048515A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • 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/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/22—Arrangements for preventing the taking of data from a data transmission channel without authorisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources

Definitions

  • the field of the invention is that of secure storage of information devices, made available to individuals (also called carriers) by an entity that manages these devices (also called device operator).
  • the invention relates to a method and a communication system between a secure information storage device and at least one third.
  • a secure information storage device is for example made in the form of a smart card, a dongle (USB key for example), or any other hardware or software device. It typically includes at least one secure container, in which information (data and / or programs) for use by a third party when communicating with the device is stored to provide one or more functions.
  • entity means all the means (hardware and / or software) available to this entity to play its role in the system.
  • third party means all means (hardware and / or software) available to this third party to play its role in the system.
  • the entity, the third parties and the secure information storage devices are connected to one another via one or more communication networks.
  • each device can be connected to the network in different ways, such as for example: connection directly (for example it has a SOAP server in the case of an IP network), connection via a hardware element (as the interface of a mobile telephone), intermediation by a software (case of an ISO 7816 reader driver or PKCS).
  • connection directly for example it has a SOAP server in the case of an IP network
  • connection via a hardware element as the interface of a mobile telephone
  • intermediation by a software case of an ISO 7816 reader driver or PKCS.
  • the third party is, for example, a service provider, such as a bank, an administration, a company, etc.
  • carrier authentication functions by the third party for example, performing a strong authentication of the semi-permanent password type, one-time password (or OTP), secret key challenge (CS) , or differentiated use of the two keys of a bi-key (PKI)); electronic wallet functions; etc.
  • the secure information storage devices are authentication devices used by third parties to authenticate the carriers of these devices. It is clear, however, as already indicated above, that the invention applies regardless of the function or functions that can be offered to third parties the information contained in the secure storage devices information.
  • Applications that use secure access can be classified into two categories: those that use online (or synchronous) security, such as credit card applications and mobile phone applications (SIMs); those who use security by deferred control, such as secure e-mail or tax remote reporting.
  • online (or synchronous) security such as credit card applications and mobile phone applications (SIMs)
  • SIMs mobile phone applications
  • deferred control such as secure e-mail or tax remote reporting.
  • Authentication architectures implemented in both cases are different and fairly mutually exclusive.
  • the authentication architectures are centralized, in the second (securing by deferred control) they are decentralized.
  • Centralized architectures do not support the pooling of applications from different service providers because, by nature, there is only one centralized element that provides this authentication.
  • each third party implements authentication devices of its own which are specific to an authentication method (OTP, CS, PKI, etc.) and to an authentication infrastructure (centralized architecture or decentralized). Investment and operating costs are therefore not pooled between different third parties.
  • the management of authentication devices is cumbersome because these devices are hardware and each time requires a specific registration infrastructure, with specific learning costs and costs incurred by the lack of pooling.
  • one of the objectives of the present invention in at least one embodiment, is to provide a communication technique between a secure information storage device and at least one third, which allows the third party to file and and / or use and / or modify, in a secure manner and during the life cycle of the device, information in a secure container included in the device and which is specific to this third party.
  • the invention aims in particular, but not exclusively, at enabling a third party to perform, during the device's life cycle, a first personalization (which replaces a conventional pre-customization in the factory) or a post-personalization ( if a conventional pre-customization in the factory or a first personalization according to the invention has already been performed) of a secure container included in the device and assigned to this third party.
  • the invention also aims, in at least one embodiment, to provide such a technique that several thirds each have a specific secure container included in the same device (mutualization of the device), and such that each third party can deposit and / or use and / or modify information in the secure container that is specific to it, independently of other third parties.
  • each third party must be able to customize the contents of its secure container, independently of other third parties and the contents of other secure containers included in the same device.
  • the invention also aims, in at least one embodiment, to provide such a technique for prohibiting access to a secure container to the device management entity, as well as to other third parties (in the where the device includes multiple secure containers assigned to different third parties).
  • Another object of the invention in at least one embodiment, is to provide such a technique in which the device management entity (operator) plays the role of a responsible actor to which the device carriers can go. turn in case of problems with their devices (opposition, replacement, etc.), and which is the guarantor of the freedom and the protection of the privacy of the carriers (data protection of the carrier against unauthorized access, or even illegal, by some thirds).
  • a complementary objective of the invention in the case where the information stored in a secure container is used by a third party to authenticate the bearer of the device, is to provide such a technique which is not related to an authentication method and which does not impose a centralized or decentralized architecture model. 4.
  • Essential characteristics of the invention in the case where the information stored in a secure container is used by a third party to authenticate the bearer of the device, is to provide such a technique which is not related to an authentication method and which does not impose a centralized or decentralized architecture model. 4.
  • this method comprises the following steps: the entity deposits in a secure container, included in said device and specific to a given third party, an authorization to communicate between the secure container and said given third party; the entity sends to the given third party an identifier of the device, an address of the device within a communication network, an identifier of the secure container and said authorization to communicate; the given third party attempts to establish a communication with the secure container, using the device address, the device identifier, the secure container identifier and the communication permission; before accepting the communication between the given third party and the secure container, the device verifies that the authorization to communicate transmitted by the third party is acceptable in view of the authorization to communicate previously filed by the entity in the secure container.
  • the general principle of the invention is therefore, after the device has been delivered to a carrier, to deposit in a secure container included in this device a communication authorization between the secure container and a third party, this communication authorization conditioning any acceptance the device of a communication between this secure container and this third party.
  • the communication between the secure container and the third party is intended to allow the third party to deposit, use or modify information in the secure container. So, the invention allows a third party to perform a first personalization or post ⁇ customization of a secure container included in a device, after this device has been delivered to a carrier (that is to say by downloading).
  • the entity plays a vital role in the mechanism of depositing a communication authorization in the secure container, ensuring that the secure container is only used by the third party to whom it has been assigned.
  • the method further comprises the following steps, performed after the communication between the secure container and the given third party has been accepted: the given third sends to the secure container a first access authorization third party specific for the secure container; the secure container stores said first access authorization, so that only the given third party, who has the first access authorization, is subsequently authorized by the secure container, independently of the entity, to use and modify information contained therein in the secure container.
  • the information contained in the secure container is under the sole control of that third party and is inaccessible to both the entity and the others.
  • third party in the case where the device is shared between several third parties.
  • the given third party can therefore access his secure container directly, without the intervention of the entity, and therefore without again implementing the aforementioned mechanism (based on the deposit by the entity, in the secure container, of an authorization of communicate between the third party and the secure container).
  • the aspect related to the management of the device is decoupled from the aspect related to the function performed with the information contained in the secure container. Indeed, it is the entity (operator) that manages the device, while it is the third party that performs the aforementioned function.
  • This decoupling makes it possible to make the authentication architecture of the device by the entity, independent of the authentication method implemented by the third party to authenticate the bearer of the device.
  • the solution of the invention does not impose an architecture model (centralized or decentralized) and is not linked to an authentication method (OTP, CS, PKI ...) that would be common to all third parties.
  • the method further comprises the following steps: the entity sends the device a request for revocation of said first specific access authorization to the given third party for the secure container; the device revokes the first specific third party specific access authorization for the secure container.
  • the entity does not know the first access authorization specific to the third party, but it can revoke it, for example at the request of the holder of the device (in case of loss, theft, etc.) or the third party (in case revocation of the holder of the device or non-renewal of a contract between the entity and the third party).
  • the step of revoking the first access authorization is preceded by the following step: the device authenticates the entity, with a second access authorization previously provided by the entity and deposited in the device, before agree to revoke the first specific third party specific access authorization for the secure container.
  • the step of depositing the authorization to communicate in the secure container is preceded by the following steps: the entity transmits to the device a request to deposit said authorization to communicate in the secure container; the device authenticates the entity, with a third access authorization previously provided by the entity and deposited in the device, before accepting the deposit in the secure container of the authorization to communicate.
  • the step of depositing the authorization to communicate in the secure container is preceded by the following step: the given third party requests the entity to deposit in the secure container the authorization to communicate between the given third party and the secure container, the given third party providing the entity with the identifier of the device.
  • the given third party sends information to the secure container for the secure container to store.
  • the information stored in the secure container belongs to the group comprising data and programs.
  • the information stored in the secure container makes it possible to perform a function belonging to the group comprising: authentication by the given third party of a bearer of the device; electronic purse; authorization to use a device with which the device cooperates; maintenance of an apparatus with which the device cooperates; managing a feature of a device with which the device cooperates.
  • the given third party is a service provider.
  • the method allows communication between the device and at least two thirds, at least one container specific to each third is included in the device.
  • the device comprises several secure containers that are allocated to different third parties, with at least one container per third (mutualization of the device).
  • Each third party may deposit and / or use and / or modify information in the secure container that is specific to it, independently of other third parties (and even independently of the entity, in the preferential case where this third party has deposited in his secure container a first access authorization specific to it).
  • the invention also relates to a communication system between a secure information storage device and at least one third party with which said information is exchanged, an entity managing a plurality of secure information storage devices to which it belongs.
  • said device comprises
  • the entity comprises means for depositing in a secure container, included in said device and specific to a given third party, an authorization to communicate between the secure container and said given third party;
  • the entity comprises means for sending to the given third party an identifier of the device, an address of the device within a communication network, an identifier of the secure container and said authorization to communicate;
  • the given third includes means for attempting to establish communication with the secure container, using the device address, the device identifier, the secure container identifier, and the communication permission;
  • the device comprises verification means that the authorization to communicate transmitted by the given third party is acceptable in view of the authorization to communicate previously filed by the entity in the secure container, so that the device accepts the communication between the given third party and the secure container only if the means of verification decide that the authorization to communicate transmitted by the third party
  • the invention also relates to an entity managing a plurality of secure information storage devices, this entity comprising: depositing means in a secure container, included in a given device and specific to a given third party, of an authorization to communicate between the secure container and said given third party; means for sending to the given third party an identifier of the given device, an address of the given device within a communication network, an identifier of the secure container and said authorization to communicate; so that the given third party can attempt to establish a communication with the secure container, using the address of the given device, the identifier of the given device, the identifier of the secure container and the authorization to communicate, and that before to accept the communication between the given third party and the secure container, the given device can verify that the authorization to communicate transmitted by the third party is acceptable in view of the authorization to communicate previously filed by the entity in the secure container.
  • the invention also relates to a secure information storage device, of the type comprising means of communication with at least one third with which are exchanged said information, the device comprising: storage means in a secure container, included in said device and specific to a given third party, an authorization to communicate between the secure container and said given third party, said authorization to communicate being deposited by an entity managing a plurality of secure information storage devices to which said device; means of verification that an authorization to communicate transmitted by the given third party is acceptable in view of the authorization to communicate previously deposited by the entity in the secure container, so that the device does not accept communication between the given third party and the secure container only if the means of verification decide that the authorization to communicate transmitted by the third party is acceptable.
  • the invention also relates to a third party, of the type comprising means of communication with a secure information storage device, said third party comprising: reception means, coming from an entity managing a plurality of communication devices; secure storage of information to which said device belongs, an identifier of the device, an address of the device within a communication network, an identifier of a secure container, included in said device and specific to said third party, and a authorization to communicate between the secure container and said third party; means for attempting to establish communication with the secure container, using the device address, the device identifier, the secure container identifier and the communication authority; so that before accepting the communication between the third party and the secure container, the device can verify that the authorization to communicate transmitted by the third party is acceptable in view of an authorization to communicate previously filed by the entity in the secure container.
  • FIGS. FIGS. 1 to 3 each illustrate a distinct phase of a particular embodiment of the method according to the invention of communication between a secure information storage device and a third party, namely:
  • FIG. 4 shows a functional block diagram of a particular embodiment of the secure storage device according to the invention. 6. Description of an embodiment of the invention
  • the system of the invention comprises: a plurality of secure information storage devices, for example dongles, each comprising one or more secure containers; a plurality of carriers to whom are entrusted the secure information storage devices; an entity, hereinafter referred to as an operator, which manages (including the distribution) secure information storage devices; one or more third parties, for example service providers
  • identity providers or IDPs, for "Identity Provider” in English), possibly confused with the operator; one or more communication networks making it possible to connect the entity (operator), the third parties (service providers), the secure information storage devices (dongles) and the identity providers
  • IDP identity provider
  • the operator is the actor who deploys the system of the invention and equips the carriers. Each device being individualized from the outset by an authentication means of its own, the operator is able to identify and authenticate this device.
  • the operator offers its secure containers (included in the devices it entrusts to carriers) for rental or sale to service providers.
  • the operator is for example connected to different identity providers (IDPs), for example as remote identity providers, and responsible for the authentication of carriers.
  • the operator has an access authorization (for example a secret in the cryptographic sense) that is specific to him and allows him to manage the secure containers of a device entrusted to a carrier.
  • an access authorization for example a secret in the cryptographic sense
  • the operator may in particular authorize the acceptance by a given secure container of another access authorization, specific to a given access provider. It can also revoke a specific access authorization to an access provider, without needing to know it.
  • the operator remains the guarantor, vis-à-vis the wearer and the service providers, of the security, the tightness and the reliability of the overall system.
  • Carriers are individuals who have a device entrusted by the operator. The wearer uses the device and each secure container included in it as if it were so many separate devices. For example, secure containers can be accessed through standardized APIs such as ISO 7816, PKCS, or other applications.
  • the secure containers included in the devices have content readable or exploitable only by those who have access rights to these secure containers. These rights are delegated by the operator under the control of the holder.
  • the information contained in the secure containers are for example data and programs, such as for example non-specialized documents, certificates or small programs, or applets, for a variety of purposes (including but not limited to authentication). .
  • the service provider is an actor who contracts with the operator to be able to use the devices deployed by the operator.
  • the operator allows the service provider to offer the bearer to receive on his device (and more precisely in one of the secure containers of this device) information (data and / or programs) allowing then a direct relationship between the service provider and the carrier.
  • the device therefore provides a "signature holder" function for one or more service providers.
  • each service provider has the right to generate a specific access authorization itself (for example in the form of a secret), and after it has been authorized by the operator gives him direct access (that is to say independently of the operator) to a secure container.
  • the service provider must implement its own carrier registration mechanism as secure container users assigned to that service provider. This mechanism is particularly guarantee of the agreement of the carrier on the use of a secure container of its device by the service provider.
  • the service provider is identified by an identifier in the device entrusted to the bearer.
  • the service provider can access this device when he has obtained a network identification of the device, authenticated by an identity provider (IDP).
  • IDP identity provider
  • the identity provider is capable of authenticating a secure information storage device at a given network address.
  • the authentication method is irrelevant for the device.
  • the identity provider gives an anonymous pointer or not to the service provider in response to an authentication request.
  • the secure information storage device is a dongle (USB key for example). It is clear, however, that the invention also applies with any other type of embodiment, hardware or software, of this device (particularly in the form of a smart card).
  • This first phase is a phase of initialization of a service provider's access to a secure container included in the device.
  • the end user has a dongle 40 comprising several secure containers (three in the illustrated example) 44a, 44b and 44c.
  • This dongle 40 requires an identifier, possibly coinciding with the address of this dongle in a communication network 70.
  • a service provider 60 who wants to communicate with one of these secure containers (for example that referenced 44b) identifies the dongle 40. It is assumed here that the dongle carrier is a customer of this supplier Services.
  • the service provider 60 addresses an operator 50 who manages the dongles and the secure containers included therein, to ask him to file an authorization to communicate with a given secure container (by example that referenced 44b).
  • the service provider sends the operator at least the identification of the dongle (eg the serial number as printed on the customer's dongle, or the anonymous "handle" of an identity provider (IDP ), or the identification number as it could be read in the dongle identification certificate if the choice of implementation of a dongle identification by a PKI certificate or an anonymous authentication certificate was retained) .
  • the service provider 60 requests the operator 50 an identifier of the secure container 44b that is assigned to this service provider with respect to that client. This step is optional because in another implementation (option b), the operator gives this information to the service provider as soon as the contract that binds them is established.
  • a fourth step (4) the operator 50 makes the dongle 40 a request for deposit of information in the secure container 44b concerned.
  • the dongle 40 authenticates the operator 50 by means of an authorization of access (a secret) specific to the operator and which was filed to the personalization of the dongle, before its marketing.
  • a sixth step (6) the operator 50 deposits in the secure container 44b the authorization to communicate between the secure container and the service provider 60.
  • a seventh step (7) the operator 50 sends at least on the network 70, to the service provider 60, the identifier of the dongle 40 concerned, the address network of this dongle, the identifier of the secure container 44b, and the authorization to communicate above.
  • the service provider 60 addresses directly to the secure container 44b of the dongle 40, because it knows the identifier and the network address of this dongle and the identifier of the secure container 44b, and provides the authorization to communicate above.
  • a ninth step (9) the dongle 40 first verifies the aforementioned communication authorization, before accepting the communication between the secure container 44b and the service provider 60. More specifically, this verification is for example carried out by the system. operating the dongle, and in case of positive result the latter asks the operating system of the secure container to accept the secret that the service provider will provide him via the aforementioned communication (see description of Figure 4).
  • the service provider 60 transmits to the secure container 44b its own access authorization to this secure container, so that it is stored there for later use (i.e. each time the access provider again wants to communicate with the secure container 44b, see description of Figure 2). In this way, the access provider becomes independent of the operator. The operator does not know this specific authorization to the service provider. He can not borrow it without the knowledge of the service provider. It has the power to revoke (see description of Figure 3).
  • the service provider 60 can now deposit in the secure container 44b data and programs that will be under only control and inaccessible to the other service provider and the operator 50.
  • the device 40 comprises an operating system (or OS, for "Operating System” in English) 41, a memory zone 42 and three secure containers 44a, 44b and 44c.
  • OS operating system
  • the invention is of course not limited to this particular value of the number of secure containers.
  • the memory zone 42 stores in particular the access authorization 43 specific to the operator (see the discussion above relating to the fifth step (5) of the initialization phase illustrated in FIG. 1).
  • Each secure container 44a, 44b or 44c includes an operating system (OS) 441a, 441b or 441c, and a memory area 442a, 442b or 442c.
  • the operating system (OS) of each secure container can also be seen as the lower layers of a computer stack.
  • Each memory zone 442a, 442b or 442c stores in particular the access authorization 443a, 443b or 443c specific to the service provider (see the discussion above relating to the tenth step (10) of the initialization phase illustrated in FIG. figure 1).
  • the operating system (native program (OS)) 41 of the device 40 has for example features that are similar to that of an operating system itself support virtual operating systems as CP / CMS (also called VM / 370) or to an application server. Thus, it can run different virtual machines, corresponding to different secure containers, in memory spaces and completely virtual, separate and isolated file systems. In other words, each virtual machine is the support of a "secure container" function. It governs access to permanent or volatile data, as well as the execution of programs, for example using the ISO 7816 or PKCS APIs.
  • the operating system 41 of the device 40 is also responsible for the relationships with the service providers, the operator and the identity providers (IDPs). Each secure container knows the shared secret with the service provider. This secret has been downloaded under the control of the operating system 41 of the device 40. It is this operating system 41 that can authorize a secure container to accept a new secret shared with a service provider, without knowing what it is. secret that is in the field of the virtual machine and inaccessible, by construction of the device 40, to the operating system 41 of this device.
  • each secure container is completely inaccessible to another secure container.
  • Each virtual machine is therefore unaware of the existence of other virtual machines and thinks to enjoy the full potential of the device. If necessary, it is possible to reserve memory resources that will only be used by one of the secure containers.
  • Each secure container can accept or provide data from / to the outside ("Over The Air") in a secure way because there is a shared secret between this container and the container's (the service provider).
  • This secret can be changed by the operator, under the control of the operating system of the device, depending on the evolution of the assignors (service providers) of the secure containers.
  • this database contains a doublet including an identifier of the service provider, and the shared secret with this service provider.
  • a second phase of the particular embodiment of the method according to the invention namely an access phase of the service provider 60 to the secure container 44b that has been assigned to it, is now presented in connection with FIG.
  • a first step (21) the service provider 60 requests the bearer of the dongle 40 to identify himself to an identity provider (IDP) 80, in order to know the correspondence between the network address of the dongle and the identity of the wearer.
  • IDP identity provider
  • the advantage of the second solution (which is that described above and illustrated in FIG. 2) is that it makes it possible to prevent a service provider not linked to the operator from obtaining a form of authentication of the dongle.
  • the carrier either by sending a constant random, to always get the same response of a given dongle, or by accessing a read in a secure container that would be free in reading to find recurrent information. It is about preserving the commercial interests of service providers who have contracted with the operator.
  • a second step (22) if the service provider 60 has a relationship with the identity provider (IDP) 80, it establishes this authentication.
  • the identity provider informs the service provider that there is an identified bearer at this network address. This regardless of the authentication method (PKI, OTP, secret key challenge, etc.).
  • PKI authentication method
  • OTP secret key challenge
  • the transmission of this information to the service provider can be done either directly by an "out-of-band channel” or by a cookie on the browser, that is to say a couple (bearer identifier, network address of the dongle).
  • the service provider knows the dongle thanks to the identifier and knows how to address him through the network address.
  • the service provider 60 can therefore directly address the secure container 44b of the dongle, to request an operation, for example by means of ISO 7816 or PKCS API.
  • This request is greeted by the operating system (OS) of dongle 40 which will look for which secure container is the recipient of the request.
  • OS operating system
  • the fifth step (25) is described below.
  • the problem listed dongle 40 is to protect against attempts to access "illegal" to a secure container.
  • the operating system of the secure container is responsible for this control. For this, it must know the identity of the service provider 60. If it is one of the service providers authorized to access this secure container 44b, it is also necessary that the system of the secure container knows that this service provider 60 has legal access to this secure container 44b (this information was provided by the operator via the operating system of the dongle), and that it authenticates the service provider . It does this for example via a secret key challenge. To be able to do this challenge, it is necessary that the dongle can pass requests to the service provider via the network. Depending on the case, the dongle may have its own network interface, or use an external interface. Depending on whether this authentication succeeds or fails, the service provider 60 may or may not communicate with the secure container 44b.
  • the further exchange can be done by a conventional protocol such as ISO 7816, PKCS or other.
  • This protocol is supported by the operating system of the secure container 44b, via the operating system of the dongle 40, to give the experience to the service provider 60 to have to do to an actor element in the chosen protocol.
  • a third phase of the particular embodiment of the method according to the invention namely a phase of revocation of a specific access authorization previously assigned to the service provider 60 (third party), is now presented in connection with FIG. ) for a given secure container 44b of the dongle 40.
  • a first step (31) the operator 50 makes the dongle 40 a request for revocation of this access authorization specific to this service provider 60 for this secure container 44b.
  • the dongle 40 authenticates the operator 50 by means of an authorization of access (a secret) specific to the operator and which was deposited to the personalization of the dongle, before its marketing.
  • an authorization of access a secret
  • the operating system (OS) of the dongle passes this request to the secure container concerned 44b, and the latter performs the requested revocation.

Abstract

L'invention concerne un procédé de communication entre un dispositif de stockage sécurisé d'informations (40) et au moins un tiers (60) avec lequel sont échangées les informations. Une entité (50) assure la gestion d'une pluralité de dispositifs de stockage sécurisé d'informations à laquelle appartient ce dispositif. Ce procédé comprend les étapes suivantes : l'entité dépose (6) dans un conteneur sécurisé (44b), compris dans le dispositif et spécifique à un tiers donné, une autorisation de communiquer entre le conteneur sécurisé et le tiers donné ; l'entité envoie (7) au tiers donné un identifiant du dispositif, une adresse du dispositif, un identifiant du conteneur sécurisé et l'autorisation de communiquer ; le tiers donné tente d'établir (8) une communication avec le conteneur sécurisé, en utilisant l'adresse du dispositif, l'identifiant du dispositif, l'identifiant du conteneur sécurisé et l'autorisation de communiquer ; avant d'accepter cette communication, le dispositif vérifie (9) que l'autorisation de communiquer transmise par le tiers est acceptable au vu de l'autorisation de communiquer préalablement déposée par l'entité dans le conteneur sécurisé.

Description

Procédé et système de communication entre un dispositif de stockage sécurisé d'informations et au moins un tiers, entité, dispositif et tiers correspondants. 1. Domaine de l'invention
Le domaine de l'invention est celui des dispositifs de stockage sécurisé d'informations, mis à la disposition d'individus (aussi appelés porteurs) par une entité qui assure la gestion de ces dispositifs (aussi appelée opérateur des dispositifs).
Plus précisément, l'invention concerne un procédé et un système de communication entre un dispositif de stockage sécurisé d'informations et au moins un tiers.
Un dispositif de stockage sécurisé d'informations est par exemple réalisé sous la forme d'une carte à puce, d'un dongle (clef USB par exemple), ou de tout autre dispositif matériel ou logiciel. Il comprend typiquement au moins un conteneur sécurisé, dans lequel sont stockées des informations (données et/ou programmes) destinées à être utilisées par un tiers quand il communique avec ce dispositif, pour offrir une ou plusieurs fonctions.
Dans un souci de simplification, dans la suite de la description, on entend par entité tous les moyens (matériels et/ou logiciels) dont dispose cette entité pour jouer son rôle dans le système. De même, on entend par tiers tous les moyens (matériels et/ou logiciels) dont dispose ce tiers pour jouer son rôle dans le système.
L'entité, les tiers et les dispositifs de stockage sécurisé d'informations sont connectés entre eux via un ou plusieurs réseaux de communication.
Classiquement, chaque dispositif peut être connecté au réseau de différentes façons, telles que par exemple : branchement directement (par exemple il possède un serveur SOAP dans le cas d'un réseau IP), branchement par l'intermédiaire d'un élément matériel (comme l'interface d'un poste téléphonique mobile), intermédiation par un logiciel (cas d'un driver de lecteur ISO 7816 ou PKCS).
Le tiers est par exemple un fournisseur de services, tel qu'une banque, une administration, une entreprise, etc.
De nombreuses fonctions peuvent être envisagées, telles que notamment, mais non exclusivement : des fonctions d'authentification du porteur par le tiers (réalisant par exemple une authentification forte de type mot de passe semi permanent, mot de passe à usage unique (ou OTP, pour « One Time Password »), challenge de clé secrète (CS), ou encore usage différencié des deux clés d'une bi-clé (PKI)) ; des fonctions de porte-monnaie électronique ; etc. 2. Art antérieur
On discute maintenant les techniques de l'art antérieur, et leurs inconvénients, dans le cas particulier où les dispositifs de stockage sécurisé d'informations sont des dispositifs d'authentification utilisés par les tiers pour authentifier les porteurs de ces dispositifs. Il est clair cependant, comme déjà indiqué ci-dessus, que l'invention s'applique quelle que soit la ou les fonctions que permettent d'offrir aux tiers les informations contenues dans les dispositifs de stockage sécurisé d'informations.
On peut classer les applications utilisant un accès sécurisé en deux catégories : celles qui utilisent une sécurisation en ligne (ou synchrone), comme par exemple les applications à carte bancaire et les applications de téléphonie mobile (SIM) ; celles qui utilisent une sécurisation par contrôle en temps différé, comme par exemple les courriers électroniques sécurisés ou la télé-déclaration des impôts.
Les architectures d'authentification mises en œuvre dans les deux cas sont différentes et assez mutuellement exclusives. Dans le premier cas de figure (sécurisation en ligne), les architectures d'authentification sont centralisées, dans le deuxième (sécurisation par contrôle en temps différé) elles sont décentralisées. Les architectures centralisées supportent mal la mutualisation d'applications de différents fournisseurs de services, car par nature il y a un seul élément centralisé assurant cette authentification.
On a déjà mis en œuvre des dispositifs d'authentification forte (par exemple avec une double authentification : « ce que je sais », le code PIN, et « ce que je possède », la carte à puce ou le dongle) dans les deux types d'architecture, mais il n'y a pas de cas où un dispositif se prête bien à la fois aux différents types d'authentification forte (OTP, CS, PKI) et est capable d'être un élément d'authentification indifféremment dans des architectures centralisées ou décentralisées. Au contraire, les dispositifs d'authentification sont habituellement spécialisés à la fois dans un type d'authentification forte et une architecture donnée, sachant que l'on ne peut croiser tous les types d'authentification forte avec tous les types d'architecture.
En d'autres termes, chaque tiers met en œuvre des dispositifs d'authentification qui lui sont propres et qui sont spécifiques à une méthode d'authentification (OTP, CS, PKI...) et à une infrastructure d'authentification (architecture centralisée ou décentralisée). Les coûts d'investissement et d'exploitation ne sont donc pas mutualisés entre différents tiers. La gestion des dispositifs d'authentification est lourde car ces dispositifs sont matériels et il faut à chaque fois une infrastructure d'enregistrement spécifique, avec des coûts spécifiques d'apprentissage et des coûts induits par l'absence de mutualisation.
Afin de remédier à ce problème, il a été proposé plusieurs solutions techniques, comme par exemple celle appelée « Global Open Platform » (voir le document « Global Platform Smart Card Management System Functional requirements, version 4.0 »), permettant à plusieurs tiers (fournisseurs de services) d'utiliser un même dispositif d'authentification de type carte à puce (dispositif multi-applicatif), sans être lié à l'entité (aussi appelée opérateur) qui assure la gestion des cartes (notamment leur fourniture et leur émission).
Cependant, cette technique connue n'est pas optimale car, à i'issue de la phase de pré-personnalisation, elle fait appel à des tiers de confiance pour rendre indépendant de l'opérateur le tiers fournisseur de services.
En outre, cette technique connue est extrêmement rigide puisque l'émetteur de la carte doit si possible connaître à l'avance les applications qui seront déposées sur la carte. Il est possible de télécharger des nouvelles applications en cours de vie de la carte, mais c'est une image entière de la carte qui doit être rechargée. 3. Objectifs de l'invention
L'invention a notamment pour objectif de pallier ces différents inconvénients de l'état de la technique. Plus précisément, l'un des objectifs de la présente invention, dans au moins un mode de réalisation, est de fournir une technique de communication entre un dispositif de stockage sécurisé d'informations et au moins un tiers, qui permette au tiers de déposer et/ou utiliser et/ou modifier, de façon sécurisée et en cours de cycle de vie du dispositif, des informations dans un conteneur sécurisé compris dans le dispositif et qui est spécifique à ce tiers.
Ainsi, l'invention vise notamment, mais non exclusivement, à permettre à un tiers d'effectuer, en cours de cycle de vie du dispositif, une première personnalisation (qui remplace une pré-personnalisation classique en usine) ou une post-personnalisation (si une pré-personnalisation classique en usine ou une première personnalisation selon l'invention a déjà été effectuée) d'un conteneur sécurisé compris dans le dispositif et attribué à ce tiers.
L'invention a également pour objectif, dans au moins un mode de réalisation, de fournir une telle technique telle que plusieurs tiers disposent chacun d'un conteneur sécurisé spécifique compris dans un même dispositif (mutualisation du dispositif), et telle que chaque tiers peut déposer et/ou utiliser et/ou modifier des informations dans le conteneur sécurisé qui lui est spécifique, indépendamment des autres tiers. Notamment, mais non exclusivement, chaque tiers doit pouvoir personnaliser le contenu de son conteneur sécurisé, indépendamment des autres tiers et du contenu des autres conteneurs sécurisés compris dans le même dispositif.
L'invention a également pour objectif, dans au moins un mode de réalisation, de fournir une telle technique permettant d'interdire l'accès à un conteneur sécurisé à l'entité de gestion des dispositifs, ainsi qu'aux autres tiers (dans le cas où le dispositif comprend plusieurs conteneurs sécurisés attribués à différents tiers).
Un autre objectif de l'invention, dans au moins un mode de réalisation, est de fournir une telle technique dans laquelle l'entité de gestion des dispositifs (opérateur) joue le rôle d'un acteur responsable vers lequel les porteurs de dispositifs peuvent se tourner en cas de problème sur leurs dispositifs (opposition, remplacement, etc.), et qui est le garant de la liberté et la protection de la vie privée des porteurs (protection de données du porteur contre un accès non autorisé, voire illégal, par des tiers). Un objectif complémentaire de l'invention, dans le cas où les informations stockées dans un conteneur sécurisé sont utilisées par un tiers pour authentifier le porteur du dispositif, est de fournir une telle technique qui ne soit pas liée à une méthode d'authentification et qui n'impose pas un modèle d'architecture centralisé ou décentralisé. 4. Caractéristiques essentielles de l'invention
Ces différents objectifs, ainsi que d'autres qui apparaîtront par la suite, sont atteints selon l'invention à l'aide d'un procédé de communication entre un dispositif de stockage sécurisé d'informations et au moins un tiers avec lequel sont échangées lesdites informations, une entité assurant la gestion d'une pluralité de dispositifs de stockage sécurisé d'informations à laquelle appartient ledit dispositif. Selon l'invention, ce procédé comprend les étapes suivantes : l'entité dépose dans un conteneur sécurisé, compris dans ledit dispositif et spécifique à un tiers donné, une autorisation de communiquer entre le conteneur sécurisé et ledit tiers donné ; l'entité envoie au tiers donné un identifiant du dispositif, une adresse du dispositif au sein d'un réseau de communication, un identifiant du conteneur sécurisé et ladite autorisation de communiquer ; le tiers donné tente d'établir une communication avec le conteneur sécurisé, en utilisant l'adresse du dispositif, l'identifiant du dispositif, l'identifiant du conteneur sécurisé et l'autorisation de communiquer ; avant d'accepter la communication entre le tiers donné et le conteneur sécurisé, le dispositif vérifie que l'autorisation de communiquer transmise par le tiers est acceptable au vu de l'autorisation de communiquer préalablement déposée par l'entité dans le conteneur sécurisé.
Le principe général de l'invention consiste donc, après que le dispositif a été remis à un porteur, à déposer dans un conteneur sécurisé compris dans ce dispositif une autorisation de communication entre ce conteneur sécurisé et un tiers, cette autorisation de communication conditionnant toute acceptation ultérieure par le dispositif d'une communication entre ce conteneur sécurisé et ce tiers.
La communication entre le conteneur sécurisé et le tiers vise à permettre au tiers de déposer, utiliser ou modifier des informations dans le conteneur sécurisé. Ainsi, l'invention permet à un tiers d'effectuer une première personnalisation ou une post¬ personnalisation d'un conteneur sécurisé compris dans un dispositif, après que ce dispositif a été remis à un porteur (c'est-à-dire par téléchargement).
Il est important de noter que l'entité joue un rôle essentiel dans le mécanisme de dépôt d'une autorisation de communication dans le conteneur sécurisé, en garantissant que le conteneur sécurisé n'est utilisé que par le tiers à qui il a été affecté.
Dans un mode de réalisation préférentiel de l'invention, le procédé comprend en outre les étapes suivantes, effectuées après que la communication entre le conteneur sécurisé et le tiers donné a été acceptée : le tiers donné envoie au conteneur sécurisé une première autorisation d'accès spécifique au tiers donné pour le conteneur sécurisé ; le conteneur sécurisé stocke ladite première autorisation d'accès, de sorte que seul le tiers donné, qui dispose de la première autorisation d'accès, est ultérieurement autorisé par le conteneur sécurisé, indépendamment de l'entité, à utiliser et modifier des informations contenues dans le conteneur sécurisé.
De cette façon, après que le conteneur sécurisé a stocké la première autorisation d'accès spécifique au tiers donné, les informations contenues dans le conteneur sécurisé sont sous le seul contrôle de ce tiers et sont inaccessibles aussi bien à l'entité qu'aux autres tiers (dans le cas où le dispositif est mutualisé entre plusieurs tiers). Le tiers donné peut donc accéder directement à son conteneur sécurisé, sans intervention de l'entité, et donc sans mettre à nouveau en œuvre le mécanisme précité (basé sur le dépôt par l'entité, dans le conteneur sécurisé, d'une autorisation de communiquer entre le tiers et le conteneur sécurisé).
En d'autres termes, dans ce mode de réalisation préférentiel de l'invention, on découple l'aspect lié à la gestion du dispositif (et notamment l'émission de celui-ci), de l'aspect lié à la fonction réalisée avec les informations contenues dans le conteneur sécurisé. En effet, c'est l'entité (opérateur) qui assure la gestion du dispositif, alors que c'est le tiers qui assure la fonction précitée.
Ce découplage permet de rendre l'architecture d'authentification du dispositif par l'entité, indépendante de la méthode d'authentification mise en œuvre par le tiers pour authentifier le porteur du dispositif. En d'autres ternies, dans ce cas, la solution de l'invention n'impose pas un modèle d'architecture (centralisée ou décentralisée) et n'est pas liée à une méthode d'authentification (OTP, CS, PKI...) qui serait commune à tous les tiers.
De façon avantageuse, le procédé comprend en outre les étapes suivantes : l'entité envoie au dispositif une demande de révocation de ladite première autorisation d'accès spécifique au tiers donné pour le conteneur sécurisé ; le dispositif révoque la première autorisation d'accès spécifique au tiers donné pour le conteneur sécurisé.
Ainsi, l'entité ne connaît pas la première autorisation d'accès spécifique au tiers, mais elle peut la révoquer, par exemple à la demande du porteur du dispositif (en cas de perte, vol, etc.) ou du tiers (en cas de révocation du porteur du dispositif ou de non reconduction d'un contrat entre l'entité et le tiers).
Avantageusement, l'étape de révocation de la première autorisation d'accès est précédée de l'étape suivante : le dispositif authentifie l'entité, avec une seconde autorisation d'accès préalablement fournie par l'entité et déposée dans le dispositif, avant d'accepter de révoquer la première autorisation d'accès spécifique au tiers donné pour le conteneur sécurisé.
Selon une caractéristique avantageuse, l'étape de dépôt de l'autorisation de communiquer dans le conteneur sécurisé est précédée des étapes suivantes : l'entité transmet au dispositif une demande de dépôt de ladite autorisation de communiquer dans le conteneur sécurisé ; le dispositif authentifie l'entité, avec une troisième autorisation d'accès préalablement fournie par l'entité et déposée dans le dispositif, avant d'accepter le dépôt dans le conteneur sécurisé de l'autorisation de communiquer.
Il est à noter que les seconde et troisième autorisations d'accès, spécifiques à l'entité, peuvent être confondues.
Dans un mode de réalisation avantageux de l'invention, l'étape de dépôt de l'autorisation de communiquer dans le conteneur sécurisé est précédée de l'étape suivante : le tiers donné demande à l'entité de déposer dans le conteneur sécurisé l'autorisation de communiquer entre le tiers donné et le conteneur sécurisé, le tiers donné fournissant à l'entité l'identifiant du dispositif. Avantageusement, après que la communication entre le conteneur sécurisé et le tiers donné a été acceptée, le tiers donné envoie des informations au conteneur sécurisé afin que le conteneur sécurisé les stocke.
De façon préférentielle, les informations stockées dans le conteneur sécurisé appartiennent au groupe comprenant des données et des programmes.
De façon avantageuse, les informations stockées dans le conteneur sécurisé permettent de réaliser une fonction appartenant au groupe comprenant : authentification par le tiers donné d'un porteur du dispositif ; porte-monnaie électronique ; autorisation d'utilisation d'un appareil avec lequel coopère le dispositif ; maintenance d'un appareil avec lequel coopère le dispositif ; gestion d'une fonctionnalité d'un appareil avec lequel coopère le dispositif.
Cette liste est nullement exhaustive.
Avantageusement, le tiers donné est un fournisseur de services.
Dans un mode de réalisation particulier de l'invention, le procédé permet la communication entre le dispositif et au moins deux tiers, au moins un conteneur spécifique à chaque tiers étant compris dans le dispositif.
Ainsi, dans ce mode de réalisation particulier, le dispositif comprend plusieurs conteneurs sécurisés qui sont attribués à différents tiers, avec au moins un conteneur par tiers (mutualisation du dispositif). Chaque tiers peut déposer et/ou utiliser et/ou modifier des informations dans le conteneur sécurisé qui lui est spécifique, indépendamment des autres tiers (et même indépendamment de l'entité, dans le cas préférentiel où ce tiers a déposé dans son conteneur sécurisé une première autorisation d'accès qui lui est spécifique).
L'invention concerne également un système de communication entre un dispositif de stockage sécurisé d'informations et au moins un tiers avec lequel sont échangées lesdites informations, une entité assurant la gestion d'une pluralité de dispositifs de stockage sécurisé d'informations à laquelle appartient ledit dispositif. Ce système est tel que : l'entité comprend des moyens de dépôt dans un conteneur sécurisé, compris dans ledit dispositif et spécifique à un tiers donné, d'une autorisation de communiquer entre le conteneur sécurisé et ledit tiers donné ; l'entité comprend des moyens d'envoi au tiers donné d'un identifiant du dispositif, une adresse du dispositif au sein d'un réseau de communication, un identifiant du conteneur sécurisé et ladite autorisation de communiquer ; le tiers donné comprend des moyens permettant de tenter d'établir une communication avec le conteneur sécurisé, en utilisant l'adresse du dispositif, l'identifiant du dispositif, l'identifiant du conteneur sécurisé et l'autorisation de communiquer ; le dispositif comprend des moyens de vérification que l'autorisation de communiquer transmise par le tiers donné est acceptable au vu de l'autorisation de communiquer préalablement déposée par l'entité dans le conteneur sécurisé, de sorte que le dispositif n'accepte la communication entre le tiers donné et le conteneur sécurisé que si les moyens de vérification décident que l'autorisation de communiquer transmise par le tiers est acceptable.
L'invention concerne aussi un entité assurant la gestion d'une pluralité de dispositifs de stockage sécurisé d'informations, cette entité comprenant : des moyens de dépôt dans un conteneur sécurisé, compris dans un dispositif donné et spécifique à un tiers donné, d'une autorisation de communiquer entre le conteneur sécurisé et ledit tiers donné ; des moyens d'envoi au tiers donné d'un identifiant du dispositif donné, une adresse du dispositif donné au sein d'un réseau de communication, un identifiant du conteneur sécurisé et ladite autorisation de communiquer ; de sorte que le tiers donné puisse tenter d'établir une communication avec le conteneur sécurisé, en utilisant l'adresse du dispositif donné, l'identifiant du dispositif donné, l'identifiant du conteneur sécurisé et l'autorisation de communiquer, et que avant d'accepter la communication entre le tiers donné et le conteneur sécurisé, le dispositif donné puisse vérifier que l'autorisation de communiquer transmise par le tiers est acceptable au vu de l'autorisation de communiquer préalablement déposée par l'entité dans le conteneur sécurisé. L'invention concerne encore un dispositif de stockage sécurisé d'informations, du type comprenant des moyens de communication avec au moins un tiers avec lequel sont échangées lesdites informations, ce dispositif comprenant : des moyens de stockage dans un conteneur sécurisé, compris dans ledit dispositif et spécifique à un tiers donné, d'une autorisation de communiquer entre le conteneur sécurisé et ledit tiers donné, ladite autorisation de communiquer étant déposée par une entité assurant la gestion d'une pluralité de dispositifs de stockage sécurisé d'informations à laquelle appartient ledit dispositif ; des moyens de vérification qu'une autorisation de communiquer transmise par le tiers donné est acceptable au vu de l'autorisation de communiquer préalablement déposée par l'entité dans le conteneur sécurisé, de sorte que le dispositif n'accepte la communication entre le tiers donné et le conteneur sécurisé que si les moyens de vérification décident que l'autorisation de communiquer transmise par le tiers est acceptable. L'invention concerne aussi un tiers, du type comprenant des moyens de communication avec un dispositif de stockage sécurisé d'informations, ce tiers comprenant : des moyens de réception, en provenance d'une entité assurant la gestion d'une pluralité de dispositifs de stockage sécurisé d'informations à laquelle appartient ledit dispositif, d'un identifiant du dispositif, une adresse du dispositif au sein d'un réseau de communication, un identifiant d'un conteneur sécurisé, compris dans ledit dispositif et spécifique audit tiers, et une autorisation de communiquer entre le conteneur sécurisé et ledit tiers ; des moyens permettant de tenter d'établir une communication avec le conteneur sécurisé, en utilisant l'adresse du dispositif, l'identifiant du dispositif, l'identifiant du conteneur sécurisé et l'autorisation de communiquer ; de sorte qu'avant d'accepter la communication entre le tiers et le conteneur sécurisé, le dispositif puisse vérifier que l'autorisation de communiquer transmise par le tiers est acceptable au vu d'une autorisation de communiquer préalablement déposée par l'entité dans le conteneur sécurisé.
5. Liste des figures D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante d'un mode de réalisation préférentiel de l'invention, donné à titre d'exemple indicatif et non limitatif, et des dessins annexés, dans lesquels : les figures 1 à 3 illustrent chacune une phase distincte d'un mode de réalisation particulier du procédé selon l'invention de communication entre un dispositif de stockage sécurisé d'informations et un tiers, à savoir :
* sur la figure 1, une phase d'initialisation d'un accès du tiers à un conteneur sécurisé compris dans le dispositif ;
* sur la figure 2, une phase d'accès du tiers à ce conteneur sécurisé ;
* sur la figure 3, une phase de révocation d'une autorisation d'accès spécifique préalablement attribuée au tiers ; et la figure 4 présente un schéma bloc fonctionnel d'un mode de réalisation particulier du dispositif de stockage sécurisé selon l'invention. 6. Description d'un mode de réalisation de l'invention
Dans le mode de réalisation particulier de l'invention décrit ci-après, le système de l'invention comprend : une pluralité de dispositifs de stockage sécurisé d'informations, par exemple des dongles, comprenant chacun un ou plusieurs conteneurs sécurisés ; une pluralité de porteurs à qui sont confié les dispositifs de stockage sécurisé d'informations ; une entité, appelée ci-après opérateur, qui assure la gestion (y inclus la distribution) des dispositifs de stockage sécurisé d'informations ; un ou plusieurs tiers, qui sont par exemple des fournisseurs de services
(banques, administrations, entreprises, etc.) ; un ou plusieurs fournisseurs d'identité (ou IDP, pour « Identity Provider » en anglais), éventuellement confondus avec l'opérateur ; un ou plusieurs réseaux de communication permettant de connecter entre eux l'entité (opérateur), les tiers (fournisseurs de services), les dispositifs de stockage sécurisé d'informations (dongles) et les fournisseurs d'identité
(IDP). L'opérateur est l'acteur qui déploie le système de l'invention et équipe les porteurs. Chaque dispositif étant individualisé dès l'origine par un moyen d'authentification qui lui est propre, l'opérateur est capable d'identifier et authentifier ce dispositif. L'opérateur offre ses conteneurs sécurisés (compris dans les dispositifs qu'il confie aux porteurs) en location ou vente aux fournisseurs de services. L'opérateur est par exemple connecté à différents fournisseurs d'identité (IDP), par exemple en tant que fournisseurs d'identité déportés, et chargés de l'authentification des porteurs.
Comme expliqué en détail par la suite, l'opérateur possède une autorisation d'accès (par exemple un secret au sens cryptographique) qui lui est spécifique et lui permet de gérer les conteneurs sécurisés d'un dispositif confié à un porteur. Au moyen de cette autorisation d'accès qui lui est spécifique, l'opérateur peut notamment autoriser l'acceptation par un conteneur sécurisé donné d'une autre autorisation d'accès, spécifique à un fournisseur d'accès donné. Il peut également révoquer une autorisation d'accès spécifique à un fournisseur d'accès, sans avoir besoin de connaître celle-ci. D'une manière générale, l'opérateur reste garant, vis-à-vis du porteur et des fournisseurs de services, de la sécurité, l'étanchéité et la fiabilité du système global.
Les porteurs sont des individus qui disposent d'un dispositif confié par l'opérateur. Le porteur utilise le dispositif et chaque conteneur sécurisé compris dans celui-ci comme s'il s'agissait d'autant de dispositifs distincts. Par exemple, les conteneurs sécurisés sont accessibles par des interfaces de programmation (ou API, pour «application programming interface ») standardisées comme ISO 7816, PKCS ou autre.
Les conteneurs sécurisés compris dans les dispositifs possèdent un contenu lisible ou exploitable seulement par ceux qui possèdent des droits d'accès à ces conteneurs sécurisés. Ces droits sont délégués par l'opérateur sous le contrôle du porteur. Les informations contenues dans les conteneurs sécurisés sont par exemple des données et programmes, tels que par exemple des documents non spécialisés, des certificats ou des petits programmes, ou applets, dans le cadre de multiples usages (dont notamment mais non exclusivement l'authentification).
Le fournisseur de services est un acteur qui contracte avec l'opérateur pour pouvoir utiliser les dispositifs déployés par l'opérateur. L'opérateur permet au fournisseur de services de proposer au porteur de recevoir sur son dispositif (et plus précisément dans un des conteneurs sécurisés de ce dispositif) des informations (données et/ou programmes) permettant ensuite une relation directe entre le fournisseur de services et le porteur. Dans l'application particulière à l'authentification, le dispositif assure donc une fonction de « porte-signatures » pour un ou plusieurs fournisseurs de services.
Comme expliqué en détail par la suite, chaque fournisseur de services dispose du droit de générer lui-même une autorisation d'accès qui lui est spécifique (par exemple sous la forme d'un secret), et qui après qu'elle a été autorisée par l'opérateur lui donne accès directement (c'est-à-dire indépendamment de l'opérateur) à un conteneur sécurisé.
Le fournisseur de service doit mettre en œuvre son propre mécanisme d'enregistrement des porteurs, en tant qu'utilisateurs de conteneurs sécurisés attribués à ce fournisseur de services. Ce mécanisme est notamment garant de l'accord du porteur sur l'usage d'un conteneur sécurisé de son dispositif par le fournisseur de service.
Le fournisseur de service est identifié par un identifiant dans le dispositif confié au porteur. Le fournisseur de service peut accéder à ce dispositif quand il a obtenu une identification réseau du dispositif, authentifié par un fournisseur d'identité (IDP).
Le fournisseur d'identité est capable d'authentifier un dispositif de stockage sécurisé d'informations à une adresse réseau donnée. La méthode d'authentification est indifférente pour le dispositif. Le fournisseur d'identité donne un pointeur anonyme ou non au fournisseur de service en réponse à une requête d'authentification.
Dans la suite de la description, on considère à titre d'exemple que le dispositif de stockage sécurisé d'informations est un dongle (clef USB par exemple). Il est clair cependant que l'invention s'applique également avec tout autre type de réalisation, matériel ou logiciel, de ce dispositif (notamment sous la forme d'une carte à puce).
On présente maintenant, en relation avec la figure 1. une première phase d'un mode de réalisation particulier du procédé selon l'invention de communication entre un dispositif de stockage sécurisé d'informations (dongle) et un tiers (fournisseur de services). Cette première phase est une phase d'initialisation d'un accès du fournisseur de services à un conteneur sécurisé compris dans le dispositif.
Dans une première étape (non illustrée), l'utilisateur final (terminal) dispose d'un dongle 40 comprenant plusieurs conteneurs sécurisés (trois dans l'exemple illustré) 44a, 44b et 44c. Ce dongle 40 nécessite un identifiant, éventuellement confondu avec l'adresse de ce dongle dans un réseau de communication 70.
Dans une deuxième étape (2), un fournisseur de services 60 qui veut communiquer avec l'un de ces conteneurs sécurisés (par exemple celui référencé 44b) identifie le dongle 40. On suppose ici que le porteur du dongle est un client de ce fournisseur de services.
Dans une troisième étape (3), le fournisseur de services 60 s'adresse à un opérateur 50 qui gère les dongles et les conteneurs sécurisés compris dans ceux-ci, pour lui demander de déposer une autorisation de communiquer avec un conteneur sécurisé donné (par exemple celui référencé 44b). Le fournisseur de services envoie à l'opérateur au moins l'identification du dongle (par exemple le numéro de série tel qu'il est imprimé sur le dongle du client, ou le "handle" anonyme d'un fournisseur d'identité (IDP), ou encore le numéro d'identification tel qu'il pourrait être lu dans le certificat d'identification du dongle si le choix d'implémentation d'une identification du dongle par un certificat PKI ou un certificat d'authentification anonyme était retenu).
Dans une étape optionnelle (non illustrée) (option a), le fournisseur de services 60 demande à l'opérateur 50 un identifiant du conteneur sécurisé 44b qui est affecté à ce fournisseur de service en ce qui concerne ce client. Cette étape est optionnelle car dans une autre implémentation (option b), l'opérateur donne cette information au fournisseur de services dès l'établissement du contrat qui les lient.
Dans une quatrième étape (4), l'opérateur 50 fait au dongle 40 une demande de dépôt d'information dans le conteneur sécurisé 44b concerné.
Dans une cinquième étape (5), le dongle 40 authentifie l'opérateur 50 au moyen d'une autorisation d'accès (un secret) spécifique à l'opérateur et qui a été déposée à la personnalisation du dongle, avant sa commercialisation.
Dans une sixième étape (6), l'opérateur 50 dépose dans le conteneur sécurisé 44b l'autorisation de communiquer entre ce conteneur sécurisé et le fournisseur de services 60.
Dans une septième étape (7), l'opérateur 50 envoie au minimum sur le réseau 70, à destination du fournisseur de services 60, l'identifiant du dongle 40 concerné, l'adresse réseau de ce dongle, l'identifiant du conteneur sécurisé 44b, et l'autorisation de communiquer précitée.
Dans une huitième étape (8), le fournisseur de services 60 s'adresse directement au conteneur sécurisé 44b du dongle 40, du fait qu'il connaît l'identifiant et l'adresse réseau de ce dongle ainsi que l'identifiant du conteneur sécurisé 44b, et fournit l'autorisation de communiquer précitée.
Dans une neuvième étape (9), le dongle 40 vérifie préalablement l'autorisation de communiquer précitée, avant d'accepter la communication entre le conteneur sécurisé 44b et le fournisseur de services 60. Plus précisément, cette vérification est par exemple effectuée par le système d'exploitation du dongle, et en cas de résultat positif ce dernier demande au système d'exploitation du conteneur sécurisé d'accepter le secret que le fournisseur de services va lui fournir via la communication précitée (voir description de la figure 4).
Dans une dixième étape (10), le fournisseur de services 60 émet vers le conteneur sécurisé 44b sa propre autorisation d'accès à ce conteneur sécurisé, afin qu'elle y soit stockée pour être utilisée ultérieurement (c'est-à-dire à chaque fois que le fournisseur d'accès voudra à nouveau communiquer avec le conteneur sécurisé 44b ; voir description de la figure 2). De cette façon, le fournisseur d'accès devient indépendant de l'opérateur. L'opérateur ne connaît pas cette autorisation spécifique au fournisseur de services. Il ne peut donc l'emprunter à l'insu du fournisseur de service. Il a le pouvoir par contre de la révoquer (voir description de la figure 3).
Dans une onzième étape (11), le fournisseur de services 60 peut maintenant déposer dans le conteneur sécurisé 44b des données et programmes qui seront sous sont seul contrôle et inaccessible aux autres fournisseur de service ainsi qu'à l'opérateur 50.
Ainsi, c'est l'opérateur qui garantit l'étanchéité des conteneurs sécurisés. Seul le fournisseur de service qui a déposé des informations dans un conteneur sécurisé peut accéder à ces informations, et il ignore l'identité des fournisseurs de service qui utilisent les autres conteneurs sécurisés du même dongle et la nature des informations qu'ils y ont déposées.
On présente maintenant, en relation avec la figure 4. un mode de réalisation particulier du dispositif de stockage sécurisé selon l'invention. Dans ce mode de réalisation, le dispositif 40 comprend un système d'exploitation (ou OS, pour « Operating System » en anglais) 41, une zone mémoire 42 et trois conteneurs sécurisés 44a, 44b et 44c. L'invention n'est bien sûr pas limitée à cette valeur particulière du nombre de conteneurs sécurisés.
La zone mémoire 42 stocke notamment l'autorisation d'accès 43 spécifique à l'opérateur (voir la discussion ci-dessus relative à la cinquième étape (5) de la phase d'initialisation illustrée sur la figure 1).
Chaque conteneur sécurisé 44a, 44b ou 44c comprend un système d'exploitation (OS) 441a, 441b ou 441c, ainsi qu'une zone mémoire 442a, 442b ou 442c. Le système d'exploitation (OS) de chaque conteneur sécurisé peut aussi être vu comme les couches basses d'une pile informatique. Chaque zone mémoire 442a, 442b ou 442c stocke notamment l'autorisation d'accès 443a, 443b ou 443c spécifique au fournisseur de services (voir la discussion ci-dessus relative à la dixième étape (10) de la phase d'initialisation illustrée sur la figure 1).
Plus précisément, le système d'exploitation (programme natif (OS)) 41 du dispositif 40 possède par exemple des fonctionnalités qui s'apparentent à celle d'un système d'exploitation lui-même support de systèmes d'exploitation virtuels comme CP/CMS (nommé aussi VM/370) ou encore à un serveur d'application. Ainsi, il peut faire tourner différentes machines virtuelles, correspondant aux différents conteneurs sécurisés, dans des espaces mémoires et des systèmes de fichiers complètement virtuels, séparés et isolés. En d'autres termes, chaque machine virtuelle est le support d'une fonction « conteneur sécurisé ». Elle régit l'accès aux données permanentes ou volatiles, ainsi que l'exécution de programmes, par exemple au moyen des API ISO 7816 ou PKCS.
Le système d'exploitation 41 du dispositif 40 est aussi chargé des relations avec les fournisseurs de service, l'opérateur et les fournisseurs d'identité (IDP). Chaque conteneur sécurisé connaît le secret partagé avec le fournisseur de service. Ce secret a été téléchargé sous le contrôle du système d'exploitation 41 du dispositif 40. C'est ce système d'exploitation 41 qui peut autoriser un conteneur sécurisé à accepter un nouveau secret partagé avec un fournisseur de service, sans pour autant connaître ce secret qui est dans le domaine de la machine virtuelle et inaccessible, par construction du dispositif 40, au système d'exploitation 41 de ce dispositif.
L'espace mémoire de travail de chaque conteneur sécurisé est complètement inaccessible à un autre conteneur sécurisé. Chaque machine virtuelle est donc inconsciente de l'existence d'autres machines virtuelles et pense jouir de tout le potentiel du dispositif. Le cas échéant il est possible de réserver des ressources mémoire qui ne seront utilisées que par l'un des conteneurs sécurisés.
Chaque conteneur sécurisé peut accepter ou fournir des données de/à l'extérieur (« Over The Air ») de façon sécurisée car il y a un secret partagé entre ce conteneur et Paffectataire de ce conteneur (le fournisseur de service). Ce secret peut être changé par l'opérateur, sous le contrôle du système d'exploitation du dispositif, en fonction de l'évolution des affectataires (les fournisseurs de service) des conteneurs sécurisés. Il existe par exemple une base de donnée dans le dispositif pour connaître l'identification des fournisseurs de service habilités à utiliser un conteneur sécurisé. Pour chaque conteneur sécurisé, cette base contient un doublet comprenant un identifiant du fournisseur de service, et le secret partagé avec ce fournisseur de service. Pour permettre la mise à jour des secrets d'accès aux conteneurs sécurisé, il y a aussi une authentification de la plateforme de l'opérateur au moyen d'un autre secret partagé. Celui-ci est implanté à la fabrication dans une zone protégée. Pour que l'affectataire d'un conteneur sécurisé puisse communiquer avec celui-ci, il faut qu'il est un identifiant de dispositif, qui peut être obtenu via le système d'authentification de l'opérateur.
On présente maintenant, en relation avec la figure 2. une deuxième phase du mode de réalisation particulier du procédé selon l'invention, à savoir une phase d'accès du fournisseur de service 60 au conteneur sécurisé 44b qui lui a été attribué.
On suppose que la première phase décrite ci-dessus en relation avec la figure 1 a déjà été effectuée, et donc que le conteneur sécurisé 44b stocke notamment l'autorisation d'accès spécifique au fournisseur de services 60.
Dans une première étape (21), le fournisseur de service 60 demande au porteur du dongle 40 de s'identifier auprès d'un fournisseur d'identité (IDP) 80, afin de connaître la correspondance entre l'adresse réseau du dongle et l'identité du porteur. II est à noter qu'il y a deux méthodes d'accès au dongle 40 pour un fournisseur de service 60 : soit le fournisseur de service est capable de dialoguer directement avec le dongle en ligne, soit le fournisseur de service demande à l'opérateur de procéder à l'authentification du dongle (lui-même ou par l'intermédiaire d'un IDP). L'intérêt de la deuxième solution (qui est celle décrite ci-dessus et illustrée sur la figure 2) est qu'elle permet d'empêcher un fournisseur de service non lié à l'opérateur d'obtenir une forme d'authentification du dongle, et donc du porteur : soit en envoyant un aléa constant, permettant d'obtenir toujours le même réponse d'un dongle donné, soit en accédant en lecture à un conteneur sécurisé qui serait libre en lecture pour y trouver des informations récurrentes. Il s'agit de préserver les intérêts commerciaux des fournisseurs de service qui ont contracté avec l'opérateur.
Dans une deuxième étape (22), si le fournisseur de service 60 possède une relation avec le fournisseur d'identité (IDP) 80, celui-ci établit cette authentification.
Dans une troisième étape (23), si cette authentification est valide, le fournisseur d'identité (IDP) informe le fournisseur de service qu'à cette adresse réseau il y a un porteur identifié. Ceci quelle que soit la méthode d'authentification (PKI, OTP, challenge clé secrète, etc). La transmission de cette information au fournisseur de service peut se faire soit directement par un "canal hors bande", soit par un cookie sur le navigateur, c'est-à-dire un couple (identifiant du porteur, adresse réseau du dongle). Le fournisseur de service connaît donc le dongle grâce a l'identifiant et sait comment s'adresser à lui grâce à l'adresse réseau.
Dans une quatrième étape (24), le fournisseur de service 60 peut donc s'adresser directement au conteneur sécurisé 44b du dongle, pour lui demander une opération, par exemple au moyen des API ISO 7816 ou PKCS. Cette requête est accueillie par le système d'exploitation (OS) du dongle 40 qui va chercher quel conteneur sécurisé est destinataire de la requête.
On décrit ci-après la cinquième étape (25). Le problème coté dongle 40, c'est de se protéger contre les tentatives d'accès "illégales" à un conteneur sécurisé. Le système d'exploitation du conteneur sécurisé est chargé de ce contrôle. Pour cela, il faut qu'il connaisse l'identité du fournisseur de service 60. Si celui-ci fait partie des fournisseurs de service autorisés à accéder à ce conteneur sécurisé 44b, il faut en outre que le système d'exploitation du conteneur sécurisé sache que ce fournisseur de service 60 a légalement accès à ce conteneur sécurisé 44b (cette information a été fournie par l'opérateur via le système d'exploitation du dongle), et qu'il authentifie le fournisseur de service. Il le fait par exemple via un challenge de clé secrète. Pour pouvoir faire ce challenge, il faut que le dongle puisse passer des requêtes à destination du fournisseur de service via le réseau. Suivant le cas, le dongle peut posséder sa propre interface réseau, ou faire appel à une interface extérieure. Selon que cette authentification réussit ou échoue, le fournisseur de service 60 peut ou non communiquer avec le conteneur sécurisé 44b.
Dans une sixième étape (26), dans le cas où la communication est possible, la suite de l'échange peut se faire par un protocole classique comme ISO 7816, PKCS ou autre. Ce protocole est supporté par le système d'exploitation du conteneur sécurisé 44b, via le système d'exploitation du dongle 40, pour donner l'expérience au fournisseur de service 60 d'avoir à faire à un élément acteur dans le protocole choisi.
On présente maintenant, en relation avec la figure 3. une troisième phase du mode de réalisation particulier du procédé selon l'invention, à savoir une phase de révocation d'une autorisation d'accès spécifique, préalablement attribuée au fournisseur de service 60 (tiers) pour un conteneur sécurisé donné 44b du dongle 40.
On suppose que la première phase décrite ci-dessus en relation avec la figure 1 a déjà été effectuée, et donc que le conteneur sécurisé 44b stocke notamment l'autorisation d'accès spécifique au fournisseur de services 60.
Dans une première étape (31), l'opéraxeur 50 fait au dongle 40 une demande de révocation de cette autorisation d'accès spécifique à ce fournisseur de services 60 pour ce conteneur sécurisé 44b.
Dans une deuxième étape (32), le dongle 40 authentifie l'opérateur 50 au moyen d'une autorisation d'accès (un secret) spécifique à l'opérateur et qui a été déposée à la personnalisation du dongle, avant sa commercialisation.
Dans une troisième étape (33), le système d'exploitation (OS) du dongle répercute cette demande au conteneur sécurisé concerné 44b, et ce dernier effectue la révocation demandée.
Bien que l'invention ait été décrite ci-dessus en relation avec un nombre limité de modes de réalisation, l'homme du métier, à la lecture de la présente description, comprendra que d'autres modes de réalisation peuvent être imaginés sans sortir du cadre de la présente invention. En conséquence, la portée de l'invention n'est limitée que par les revendications ci-jointes.

Claims

REVENDICATIONS
1. Procédé de communication entre un dispositif de stockage sécurisé d'informations (40) et au moins un tiers (60) avec lequel sont échangées lesdites informations, une entité (50) assurant la gestion d'une pluralité de dispositifs de stockage sécurisé d'informations à laquelle appartient ledit dispositif, caractérisé en ce qu'il comprend les étapes suivantes : l'entité dépose (6) dans un conteneur sécurisé (44b), compris dans ledit dispositif et spécifique à un tiers donné, une autorisation de communiquer entre le conteneur sécurisé et ledit tiers donné ; l'entité envoie (7) au tiers donné un identifiant du dispositif, une adresse du dispositif au sein d'un réseau de communication, un identifiant du conteneur sécurisé et ladite autorisation de communiquer ; le tiers donné tente d'établir (8) une communication avec le conteneur sécurisé, en utilisant l'adresse du dispositif, l'identifiant du dispositif, l'identifiant du conteneur sécurisé et l'autorisation de communiquer ; avant d'accepter la communication entre le tiers donné et le conteneur sécurisé, le dispositif vérifie (9) que l'autorisation de communiquer transmise par le tiers est acceptable au vu de l'autorisation de communiquer préalablement déposée par l'entité dans le conteneur sécurisé.
2. Procédé selon la revendication 1, caractérisé en ce qu'il comprend en outre les étapes suivantes (10), effectuées après que la communication entre le conteneur sécurisé et le tiers donné a été acceptée : le tiers donné envoie au conteneur sécurisé une première autorisation d'accès spécifique au tiers donné pour le conteneur sécurisé ; le conteneur sécurisé stocke ladite première autorisation d'accès, de sorte que seul Ie tiers donné, qui dispose de la première autorisation d'accès, est ultérieurement autorisé par le conteneur sécurisé, indépendamment de l'entité, à utiliser et modifier des informations contenues dans le conteneur sécurisé.
3. Procédé selon la revendication 2, caractérisé en ce qu'il comprend en outre les étapes suivantes : l'entité envoie (31) au dispositif une demande de révocation de ladite première autorisation d'accès spécifique au. tiers donné pour le conteneur sécurisé ; le dispositif révoque (33) la première autorisation d'accès spécifique au tiers donné pour le conteneur sécurisé.
4. Procédé selon la revendication 3, caractérisé en ce que l'étape de révocation de la première autorisation d'accès est précédée de l'étape suivante : le dispositif authentifie (32) l'entité, avec une seconde autorisation d'accès préalablement fournie par l'entité et déposée dans le dispositif, avant d'accepter de révoquer la première autorisation d'accès spécifique au tiers donné pour le conteneur sécurisé.
5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que l'étape de dépôt de l'autorisation de communiquer dans le conteneur sécurisé est précédée des étapes suivantes : l'entité transmet (4) au dispositif une demande de dépôt de ladite autorisation de communiquer dans le conteneur sécurisé ; le dispositif authentifie (5) l'entité, avec une troisième autorisation d'accès préalablement fournie par l'entité et déposée dans le dispositif, avant d'accepter le dépôt dans le conteneur sécurisé de l'autorisation de communiquer.
6. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que l'étape de dépôt de l'autorisation de communiquer dans le conteneur sécurisé est précédée de l'étape suivante : le tiers donné demande (3) à l'entité de déposer dans le conteneur sécurisé l'autorisation de communiquer entre le tiers donné et le conteneur sécurisé, le tiers donné fournissant à l'entité l'identifiant du dispositif.
7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que, après que la communication entre le conteneur sécurisé et le tiers donné a été acceptée, le tiers donné envoie (11) des informations au conteneur sécurisé afin que le conteneur sécurisé les stocke.
8. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que les informations stockées dans le conteneur sécurisé appartiennent au groupe comprenant des données et des programmes.
9. Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce que les informations stockées dans le conteneur sécurisé permettent de réaliser une fonction appartenant au groupe comprenant : authentification par le tiers donné d'un porteur du dispositif ; porte-monnaie électronique ; autorisation d'utilisation d'un appareil avec lequel coopère le dispositif ; maintenance d'un appareil avec lequel coopère le dispositif ; gestion d'une fonctionnalité d'un appareil avec lequel coopère le dispositif.
10. Procédé selon l'une quelconque des revendications 1 à 9, caractérisé en ce que le tiers donné (60) est un fournisseur de services.
11. Procédé selon l'une quelconque des revendications 1 à 10, caractérisé en ce qu'il permet la communication entre le dispositif et au moins deux tiers, au moins un conteneur spécifique à chaque tiers étant compris dans le dispositif.
12. Système de communication entre un dispositif de stockage sécurisé d'informations et au moins un tiers avec lequel sont échangées lesdites informations, une entité assurant la gestion d'une pluralité de dispositifs de stockage sécurisé d'informations à laquelle appartient ledit dispositif, caractérisé en ce que : l'entité comprend des moyens de dépôt dans un conteneur sécurisé, compris dans ledit dispositif et spécifique à un tiers donné, d'une autorisation de communiquer entre le conteneur sécurisé et ledit tiers donné ; l'entité comprend des moyens d'envoi au tiers donné d'un identifiant du dispositif, une adresse du dispositif au sein d'un réseau de communication, un identifiant du conteneur sécurisé et ladite autorisation de communiquer ; le tiers donné comprend des moyens permettant de tenter d'établir une communication avec le conteneur sécurisé, en utilisant l'adresse du dispositif, l'identifiant du dispositif, l'identifiant du conteneur sécurisé et l'autorisation de communiquer ; le dispositif comprend des moyens de vérification que l'autorisation de communiquer transmise par le tiers donné est acceptable au vu de l'autorisation de communiquer préalablement déposée par l'entité dans le conteneur sécurisé, de sorte que le dispositif n'accepte la communication entre le tiers donné et le conteneur sécurisé que si les moyens de vérification décident que l'autorisation de communiquer transmise par le tiers est acceptable.
13. Entité assurant la gestion d'une pluralité de dispositifs de stockage sécurisé d'informations, caractérisée en ce qu'elle comprend : des moyens de dépôt dans un conteneur sécurisé, compris dans un dispositif donné et spécifique à un tiers donné, d'une autorisation de communiquer entre le conteneur sécurisé et ledit tiers donné ; des moyens d'envoi au tiers donné d'un identifiant du dispositif donné, une adresse du dispositif donné au sein d'un réseau de communication, un identifiant du conteneur sécurisé et ladite autorisation de communiquer ; de sorte que le tiers donné puisse tenter d'établir une communication avec le conteneur sécurisé, en utilisant l'adresse du dispositif donné, l'identifiant du dispositif donné, l'identifiant du conteneur sécurisé et l'autorisation de communiquer, et que avant d'accepter la communication entre le tiers donné et le conteneur sécurisé, le dispositif donné puisse vérifier que l'autorisation de communiquer transmise par le tiers est acceptable au vu de l'autorisation de communiquer préalablement déposée par l'entité dans le conteneur sécurisé.
14. Dispositif de stockage sécurisé d'informations, du type comprenant des moyens de communication avec au moins un tiers avec lequel sont échangées lesdites informations, caractérisé en ce qu'il comprend : des moyens de stockage dans un conteneur sécurisé, compris dans ledit dispositif et spécifique à un tiers donné, d'une autorisation de communiquer entre le conteneur sécurisé et ledit tiers donné, ladite autorisation de communiquer étant déposée par une entité assurant la gestion d'une pluralité de dispositifs de stockage sécurisé d'informations à laquelle appartient ledit dispositif ; des moyens de vérification qu'une autorisation de communiquer transmise par le tiers donné est acceptable au vu de l'autorisation de communiquer préalablement déposée par l'entité dans le conteneur sécurisé, de sorte que le dispositif n'accepte la communication entre le tiers donné et le conteneur sécurisé que si les moyens de vérification décident que l'autorisation de communiquer transmise par le tiers est acceptable.
15. Tiers, du type comprenant des moyens de communication avec un dispositif de stockage sécurisé d'informations, caractérisé en ce qu'il comprend : des moyens de réception, en provenance d'une entité assurant la gestion d'une pluralité de dispositifs de stockage sécurisé d'informations à laquelle appartient ledit dispositif, d'un identifiant du dispositif, une adresse du dispositif au sein d'un réseau de communication, un identifiant d'un conteneur sécurisé, compris dans ledit dispositif et spécifique audit tiers, et une autorisation de communiquer entre le conteneur sécurisé et ledit tiers ; des moyens permettant de tenter d'établir une communication avec Ie conteneur sécurisé, en utilisant l'adresse du dispositif, l'identifiant du dispositif, l'identifiant du conteneur sécurisé et l'autorisation de communiquer ; de sorte qu'avant d'accepter la communication entre le tiers et le conteneur sécurisé, le dispositif puisse vérifier que l'autorisation de communiquer transmise par le tiers est acceptable au vu d'une autorisation de communiquer préalablement déposée par l'entité dans le conteneur sécurisé.
PCT/FR2005/002233 2004-10-29 2005-09-07 Procede et systeme de communiction entre un dispositif de stockage securise d’informations et au moins un tiers, entite, dispositif et tiers correspondants WO2006048515A1 (fr)

Priority Applications (6)

Application Number Priority Date Filing Date Title
JP2007538459A JP5595636B2 (ja) 2004-10-29 2005-09-07 安全な情報記憶デバイスと少なくとも１つのサードパーティとの間の通信、対応するエンティティ、情報記憶デバイス、及びサードパーティのための方法及びシステム
AT05805605T ATE534224T1 (de) 2004-10-29 2005-09-07 Verfahren und system zur kommunikation zwischen einem sicheren informationsspeichergerät und mindestens einer dritten instanz, entsprechende einrichtung, gerät und dritte instanz
EP20050805605 EP1805965B1 (fr) 2004-10-29 2005-09-07 Procede et systeme de communiction entre un dispositif de stockage securise d'informations et au moins un tiers, entite, dispositif et tiers correspondants
KR1020077011679A KR101276092B1 (ko) 2004-10-29 2005-09-07 보안 정보 저장 장치와 적어도 하나의 제３자 사이의 통신방법 및 시스템, 그리고 이에 대응되는 개체, 장치 및제３자
US11/666,585 US8739267B2 (en) 2004-10-29 2005-09-07 Method and system for communication between a secure information storage device and at least one third party, and corresponding entity, device and third party
CN2005800374259A CN101073239B (zh) 2004-10-29 2005-09-07 安全信息存储装置与至少一个第三方之间的通信方法和系统、相应实体、装置和第三方

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0411625 2004-10-29
FR0411625 2004-10-29

Publications (1)

Publication Number Publication Date
WO2006048515A1 true WO2006048515A1 (fr) 2006-05-11

Family

ID=34954067

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2005/002233 WO2006048515A1 (fr) 2004-10-29 2005-09-07 Procede et systeme de communiction entre un dispositif de stockage securise d’informations et au moins un tiers, entite, dispositif et tiers correspondants

Country Status (7)

Country Link
US (1) US8739267B2 (fr)
EP (1) EP1805965B1 (fr)
JP (1) JP5595636B2 (fr)
KR (1) KR101276092B1 (fr)
CN (1) CN101073239B (fr)
AT (1) ATE534224T1 (fr)
WO (1) WO2006048515A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008003586A1 (fr) * 2006-07-04 2008-01-10 Oberthur Technologies Boitier pour clef electronique et systeme comportant un tel boitier
FR2912522A1 (fr) * 2007-02-12 2008-08-15 Oberthur Card Syst Sa Entite electronique portable et procede de communication.
EP2096570A1 (fr) * 2008-02-29 2009-09-02 Micon e.V. - Verein zur Förderung der Mobilität im Internet und in Kommunikationsnetzen e.V. Système informatique mobile destiné à exécuter des transactions sécurisées par l'intermédiaire d'un réseau de communication non sécurisé
US10257131B2 (en) * 2015-06-26 2019-04-09 Blackberry Limited Private text chatting sessions
CN112115451A (zh) * 2020-09-28 2020-12-22 天地伟业技术有限公司 一种在ARM架构的Docker容器中识别热插拔硬件USB加密狗的方法

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110104705A1 (en) * 2006-09-30 2011-05-05 Takeda Pharmaceutical Company Limited Musclin receptor and use thereof
US20100280858A1 (en) * 2009-04-30 2010-11-04 Embarq Holdings Company, Llc System and method for a small form pluggable ethernet demarcation device
US8321956B2 (en) * 2009-06-17 2012-11-27 Microsoft Corporation Remote access control of storage devices
FI20115313A0 (fi) 2011-03-31 2011-03-31 Meontrust Oy Autentikointimenetelmä ja -järjestelmä
CN102855422B (zh) * 2012-08-21 2015-03-04 飞天诚信科技股份有限公司 一种盗版加密锁的识别方法和装置
US8959537B2 (en) * 2012-09-28 2015-02-17 Sap Se Configurable generation of proxies for backend APIs
US20140250186A1 (en) * 2013-03-01 2014-09-04 Prolifiq Software Inc. Facilitated third-party communication
CN103905443A (zh) * 2014-03-31 2014-07-02 北京握奇数据系统有限公司 一种验证装置、系统及注册、验证方法
US9692788B2 (en) * 2014-05-29 2017-06-27 Blackberry Limited Method and system for domain creation and bootstrapping
CN105550576B (zh) * 2015-12-11 2018-09-11 华为技术服务有限公司 容器间通信的方法与装置
US10140159B1 (en) 2016-03-04 2018-11-27 Quest Software Inc. Systems and methods for dynamic creation of container manifests
US10127030B1 (en) 2016-03-04 2018-11-13 Quest Software Inc. Systems and methods for controlled container execution
US10270841B1 (en) 2016-03-04 2019-04-23 Quest Software Inc. Systems and methods of real-time container deployment
US10289457B1 (en) 2016-03-30 2019-05-14 Quest Software Inc. Systems and methods for dynamic discovery of container-based microservices
US10057061B1 (en) 2016-09-13 2018-08-21 Wells Fargo Bank, N.A. Secure digital communications
US10075300B1 (en) * 2016-09-13 2018-09-11 Wells Fargo Bank, N.A. Secure digital communications
US10853798B1 (en) 2016-11-28 2020-12-01 Wells Fargo Bank, N.A. Secure wallet-to-wallet transactions
US10057225B1 (en) 2016-12-29 2018-08-21 Wells Fargo Bank, N.A. Wireless peer to peer mobile wallet connections
CN108322307B (zh) * 2017-01-16 2021-02-09 中标软件有限公司 基于内核内存共享的容器间通讯系统及方法
US10776777B1 (en) 2017-08-04 2020-09-15 Wells Fargo Bank, N.A. Consolidating application access in a mobile wallet

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4849614A (en) * 1985-12-27 1989-07-18 Toppan Moore Company, Ltd. Composite IC card
EP1117077A2 (fr) * 2000-01-07 2001-07-18 Sony Corporation Système de traitement de données, dispositif portable électronique, appareil d'accès au dispositif portable électronique, et méthode d'utilisation d'espace mémoire
US20020040438A1 (en) * 2000-05-05 2002-04-04 Fisher David Landis Method to securely load and manage multiple applications on a conventional file system smart card

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6473609B1 (en) * 1995-12-11 2002-10-29 Openwave Systems Inc. Method and architecture for interactive two-way communication devices to interact with a network
CA2305249A1 (fr) * 2000-04-14 2001-10-14 Branko Sarcanin Coffre-fort virtuel
US7310734B2 (en) * 2001-02-01 2007-12-18 3M Innovative Properties Company Method and system for securing a computer network and personal identification device used therein for controlling access to network components
JP4118032B2 (ja) * 2001-04-10 2008-07-16 日本電信電話株式会社 Ｉｃカード運用管理システム
US7697920B1 (en) * 2006-05-05 2010-04-13 Boojum Mobile System and method for providing authentication and authorization utilizing a personal wireless communication device
US20040097217A1 (en) * 2002-08-06 2004-05-20 Mcclain Fred System and method for providing authentication and authorization utilizing a personal wireless communication device
US8966579B2 (en) * 2003-12-30 2015-02-24 Entrust, Inc. Method and apparatus for providing authentication between a sending unit and a recipient based on challenge usage data
US7707039B2 (en) * 2004-02-15 2010-04-27 Exbiblio B.V. Automatic modification of web pages
US20050269402A1 (en) * 2004-06-03 2005-12-08 Tyfone, Inc. System and method for securing financial transactions
US20070082703A1 (en) * 2004-10-28 2007-04-12 Koninklijke Kpn N.V. Method and system for providing wireless identification

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4849614A (en) * 1985-12-27 1989-07-18 Toppan Moore Company, Ltd. Composite IC card
EP1117077A2 (fr) * 2000-01-07 2001-07-18 Sony Corporation Système de traitement de données, dispositif portable électronique, appareil d'accès au dispositif portable électronique, et méthode d'utilisation d'espace mémoire
US20020040438A1 (en) * 2000-05-05 2002-04-04 Fisher David Landis Method to securely load and manage multiple applications on a conventional file system smart card

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008003586A1 (fr) * 2006-07-04 2008-01-10 Oberthur Technologies Boitier pour clef electronique et systeme comportant un tel boitier
FR2903514A1 (fr) * 2006-07-04 2008-01-11 Oberthur Card Syst Sa Boitier pour clef electronique et systeme comportant un tel boitier
US8225986B2 (en) 2006-07-04 2012-07-24 Oberthur Technologies Casing for electronic key and system comprising such a casing
FR2912522A1 (fr) * 2007-02-12 2008-08-15 Oberthur Card Syst Sa Entite electronique portable et procede de communication.
WO2008102082A1 (fr) * 2007-02-12 2008-08-28 Oberthur Technologies Entité électronique portable et procède de communication
US8190898B2 (en) 2007-02-12 2012-05-29 Oberthur Technologies Portable electronic entity and communication method
EP2096570A1 (fr) * 2008-02-29 2009-09-02 Micon e.V. - Verein zur Förderung der Mobilität im Internet und in Kommunikationsnetzen e.V. Système informatique mobile destiné à exécuter des transactions sécurisées par l'intermédiaire d'un réseau de communication non sécurisé
US10257131B2 (en) * 2015-06-26 2019-04-09 Blackberry Limited Private text chatting sessions
CN112115451A (zh) * 2020-09-28 2020-12-22 天地伟业技术有限公司 一种在ARM架构的Docker容器中识别热插拔硬件USB加密狗的方法
CN112115451B (zh) * 2020-09-28 2024-04-12 天地伟业技术有限公司 一种在ARM架构的Docker容器中识别热插拔硬件USB加密狗的方法

Also Published As

Publication number Publication date
US20090049521A1 (en) 2009-02-19
CN101073239B (zh) 2012-08-01
KR101276092B1 (ko) 2013-06-18
JP5595636B2 (ja) 2014-09-24
CN101073239A (zh) 2007-11-14
ATE534224T1 (de) 2011-12-15
KR20070070234A (ko) 2007-07-03
JP2008518343A (ja) 2008-05-29
US8739267B2 (en) 2014-05-27
EP1805965A1 (fr) 2007-07-11
EP1805965B1 (fr) 2011-11-16

Similar Documents

Publication Publication Date Title
EP1805965B1 (fr) Procede et systeme de communiction entre un dispositif de stockage securise d'informations et au moins un tiers, entite, dispositif et tiers correspondants
EP2405378B1 (fr) Procédé d'exécution d'une application sécurisée dans un dispositif NFC
US7925878B2 (en) System and method for creating a trusted network capable of facilitating secure open network transactions using batch credentials
CA2647248C (fr) Procede et serveur de coffres-forts electroniques avec mutualisation d'informations
WO2003056750A2 (fr) Systeme cryptographique de signature de groupe
WO2011117486A1 (fr) Infrastructure non hierarchique de gestion de bi-cles de securite de personnes physiques
EP1908215A1 (fr) Procédé de contrôle de transactions sécurisées mettant en oeuvre un dispositif physique unique à bi-clés multiples, dispositif physique, système et programme d'ordinateur correspondants
FR2751104A1 (fr) Procede de controle de transactions securisees independantes utilisant un dispositif physique unique
EP2801052A1 (fr) Procede d'execution d'une application dans un dispositif nfc
EP1911194A1 (fr) Procede de controle de transactions securisees mettant en oeuvre un dispositif physique unique, dispositif physique, systeme, et programme d'ordinateur correspondants
US20150178711A1 (en) Method for creating a payment system
EP1636767B1 (fr) Methode d'allocation de ressources securisees dans un modue de securite
EP1413158B1 (fr) Procede d'acces a un service specifique propose par un operateur virtuel et carte a puce d'un dispositif correspondant
CA2647239C (fr) Procede et serveur pour l'acces a un coffre-fort electronique via plusieurs entites
WO2022208016A1 (fr) Procédé et système informatique de stockage decentralisé et de partage de fichiers numériques certifiés
WO2021123527A1 (fr) Procede et dispositif de gestion d'une autorisation d'acces a un service de paiement fourni a un utilisateur
WO2022269179A1 (fr) Procede et dispositif de paiement par chaines de blocs
FR3114714A1 (fr) Procédé d’accès à un ensemble de données d’un utilisateur.
FR2927750A1 (fr) Terminal de paiement electronique pour l'echange de donnees securise sur un reseau ouvert
FR3008516A1 (fr) Methode de realisation de transaction, terminal et programme d'ordinateur correspondant.

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 KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM 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): BW GH 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 IS IT LT LU LV 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
WWE Wipo information: entry into national phase

Ref document number: 2005805605

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 3189/DELNP/2007

Country of ref document: IN

WWE Wipo information: entry into national phase

Ref document number: 200580037425.9

Country of ref document: CN

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2007538459

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 1020077011679

Country of ref document: KR

WWP Wipo information: published in national office

Ref document number: 2005805605

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 11666585

Country of ref document: US