WO2005053263A2 - Méthode d'authentification d'applications - Google Patents

Méthode d'authentification d'applications Download PDF

Info

Publication number
WO2005053263A2
WO2005053263A2 PCT/EP2004/053116 EP2004053116W WO2005053263A2 WO 2005053263 A2 WO2005053263 A2 WO 2005053263A2 EP 2004053116 W EP2004053116 W EP 2004053116W WO 2005053263 A2 WO2005053263 A2 WO 2005053263A2
Authority
WO
WIPO (PCT)
Prior art keywords
application
sim
app
cryptogram
equipment
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/EP2004/053116
Other languages
English (en)
Other versions
WO2005053263A3 (fr
Inventor
Rached Ksontini
Renato Cantini
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Swisscom Mobile AG
NagraCard SA
Original Assignee
Swisscom Mobile AG
NagraCard SA
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
Priority to EP04804580A priority Critical patent/EP1687953B1/fr
Priority to BRPI0415788-5A priority patent/BRPI0415788A/pt
Priority to JP2006540462A priority patent/JP2007519308A/ja
Priority to US10/577,857 priority patent/US8261365B2/en
Priority to AU2004310512A priority patent/AU2004310512A1/en
Priority to HK06112494.0A priority patent/HK1092971B/xx
Priority to DE602004011559T priority patent/DE602004011559T2/de
Priority to CA002545159A priority patent/CA2545159A1/fr
Application filed by Swisscom Mobile AG, NagraCard SA filed Critical Swisscom Mobile AG
Publication of WO2005053263A2 publication Critical patent/WO2005053263A2/fr
Publication of WO2005053263A3 publication Critical patent/WO2005053263A3/fr
Priority to IL175255A priority patent/IL175255A0/en
Priority to ZA2006/04290A priority patent/ZA200604290B/en
Anticipated expiration legal-status Critical
Priority to US13/557,266 priority patent/US8813253B2/en
Priority to US14/332,946 priority patent/US9143888B2/en
Priority to US14/825,664 priority patent/US9531681B2/en
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/30—Security of mobile devices; Security of mobile applications
    • H04W12/35—Protecting application or service provisioning, e.g. securing SIM application provisioning
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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 OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/554—Detecting local intrusion or implementing counter-measures involving event detection and direct action
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • 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/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • 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
    • 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
    • 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/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/60—Subscription-based services using application servers or record carriers, e.g. SIM application toolkits
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2107—File encryption
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2153—Using hardware token as a secondary aspect
    • 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/12—Applying verification of the received information

Definitions

  • the present invention relates to the field of mobile networks also called cellular networks. It relates more particularly to the management of application security implemented with a security module associated with mobile equipment of mobile telephony.
  • the security module of a mobile or portable telephone is known by the name "SIM card” (Subscriber Identity Module) constituting the central element of the security of these telephones.
  • SIM card Subscriber Identity Module
  • the telephone operator introduces, during manufacture and / or during a personalization phase, a number called IMSI (International Mobile Subscriber Identification) used to identify in a safe and unique way each subscriber wishing to connect to a mobile network .
  • IMSI International Mobile Subscriber Identification
  • Each mobile phone, called mobile equipment below, is physically identified by a number stored in a non-volatile memory of the mobile equipment.
  • IMEI International Mobile Equipment Identifier
  • GSM Global System for Mobile communications
  • GPRS General Packet Radio System
  • UMTS Universal Mobile Telecommunications System
  • a mobile device is characterized by a software version SVN (Software Version Number) indicating the update status of the basic software installed on the mobile device.
  • SVN Software Version Number
  • IMEISV International Mobile Equipment Identifier and Software Version Number
  • WLAN Wireless LAN
  • the physical identifier can be a MAC address (Media Access Control) which corresponds to the unique address identifying the configuration of a user's hardware on an IP (Internet Protocol) network and the software version can be transmitted by protocols. IP-based top layer.
  • the ETSI standards (“European Telecommunications Standards Institute") define a mobile station (MS, mobile station) composed of mobile equipment (ME, mobile equipment) and a subscriber module (SIM, subscriber identity module). This the subscriber module is generally removable, that is to say it can be either removed or transferred from one mobile device to another.
  • Verification therefore becomes necessary at least on two levels: on the one hand at the level of the mobile equipment itself and on the other hand at that of the software applications allowing the operation of the various services offered by the operator or third parties .
  • These applications are usually downloaded from the server of an application provider, which implies the need to verify this download. It is therefore a question of ensuring that the subscriber module provides information only to authorized applications once this module has been recognized by the control server as being able to operate with the mobile equipment in which it is inserted.
  • the subscriber module can contain confidential information such as a bank account number or a password.
  • An application running on mobile equipment will be in charge of using this personal data in order to provide the expected service. However, an application could divert this personal data for purposes other than dialogue with the application provider concerned. This may result in significant harm to the owner of the subscriber module.
  • These applications executed in the mobile equipment use resources available in the subscriber module. By resources, we mean various functions and data necessary for the proper functioning of an application. Some of these resources may be common to several applications, in particular security-related functions. The subscriber module can thus block or alter the operation of certain applications for which the security conditions established by the operator and / or the application providers are not respected in the mobile equipment in question or the rights of the user. of mobile equipment are insufficient.
  • the document FR2831362 describes a secure transaction method between a mobile telephone provided with a SIM card and an application server. The purpose of this process is to protect the rights linked to the use of applications downloaded from the server by means of the SIM card.
  • a link of trust is first established between the server and the SIM card by the secure exchange of public keys, then a purchase of an application is made by the transmission of a request file by the mobile equipment to the server.
  • This partially or fully encrypts the application and transmits to the mobile equipment a cryptogram formed by the encryption key and a command, all encrypted with a public key known to the SIM card.
  • this cryptogram is decrypted and the key stored in the SIM card.
  • the execution of the command results in the downloading to the mobile equipment of the application partially or fully encrypted by the server.
  • the application is decrypted by the key stored in the SIM card and then installed in the mobile equipment.
  • the rights to use the application in the mobile equipment are protected due to the bond of trust established initially between the equipment and the server and preceding the transaction.
  • the role played by the server is concentrated here rather in the rights management or DRM (Digital Rights Management) of the users of an application in a mobile device.
  • DRM Digital Rights Management
  • the solution developed below is rather oriented towards Risk Management. account by the operator, application provider or user in relation to an application.
  • the object of the present invention is to propose a method of authenticating one or more applications in mobile equipment both during their downloading and during their execution. This is to limit the risks linked to the fact that a subscriber module is misused either by applications that do not meet certain security criteria, or by mobile equipment that does not meet certain pre-established security criteria.
  • Another purpose is to protect the user of the mobile equipment as well as the application providers concerned against abuses resulting from the use of unauthorized applications.
  • a cryptogram comprising a fingerprint of the application, data identifying the equipment and the security module and instructions intended for said module, transmission of said cryptogram, via the network and the equipment, to the security module, verification of the application by comparing the fingerprint extracted from the cryptogram received with a fingerprint determined by the security module, said method is characterized in that, during the initialization and / or activation of the application, the module security executes the instructions extracted from the cryptogram and frees, respectively blocks access to certain resources of said security module according to the result of the verification specific to this application carried out beforehand.
  • the resources of the security module are blocked or released in a targeted manner, this in order to make certain applications usable or not. We do not directly block or release applications from mobile equipment: we act indirectly on applications, that is to say that the blocking or release effect will only appear when the mobile equipment will try to run these applications.
  • the equipment is, for example, mobile telephone equipment and the security module a subscriber module or SIM card.
  • This set is connected to a mobile network of the GSM (Global System for Mobile communications), GPRS (General Packet Radio Service), UMTS (Universal Mobile Telecommunications System) or other type, managed by an operator control server.
  • Software applications are installed in the mobile equipment and configured so as to use the resources (data or functions) present in the subscriber module. They cannot therefore be used in their entirety only if the security conditions are satisfied according to criteria predetermined by the operator and / or the application supplier. This verification of the criteria is the responsibility of the control server.
  • the application following the instructions sent by the control server, is ultimately the responsibility of the security module which can leave free or block access to resources necessary for the proper functioning of an application installed in the mobile equipment.
  • the data of these resources can include information such as account number, programs (in the form of code that can be installed in mobile equipment), encryption / decryption keys, access rights to content, etc. .
  • the functions of these resources can include cryptographic algorithms, verification processes, digital signature generation processes, encryption processes, authentication processes, data validation processes, access control processes, data backup processes, payment processes etc.
  • the method according to the invention is based on the fact that an application is associated with a cryptogram which conditions the use of the application on mobile equipment connected to a network.
  • the link between the server and the security module is used to optimally control its resources and to decide whether or not to put them into service in relation to the applications executed. in mobile equipment.
  • the command received from the server in the process of the cited document, makes it possible to control the use of the application installed in the mobile equipment, while in the present method, it makes it possible to activate or deactivate resources of the security module .
  • this reduction may relate to the maximum amount authorized for the purchase of services and moreover, these services could only be obtained in a given place (shopping center, stadium, station, airport, etc.)
  • the cryptogram is transmitted to the subscriber module during the loading of the application.
  • it is the application which will seek the cryptogram on the control server during its first use.
  • the authentication method according to the invention also applies during the execution of an application by the mobile equipment, which makes it possible to ensure, using the subscriber module, that this application is authorized to access certain resources (data or functions) contained in said subscriber module.
  • the subscriber module can regularly check the cryptogram attached to an application during the execution of said application. For example, the insertion of a user's subscriber module into other mobile equipment will influence the operation of certain applications without preventing the establishment of conventional telephone communications.
  • This barrier acts as a filter to eliminate unauthorized mobile equipment or applications from sources not approved by the operator or a partner application supplier.
  • a modification of the application by a third party is also detected by the subscriber module, which will refuse to execute certain commands received, thus resulting in the blocking or limitations of the execution of the application.
  • the control server therefore plays an essential role in managing the elements of trust or security linked to the mobile equipment / subscriber module assembly. It interprets the data transmitted to it by the mobile equipment in order to control or limit the use of applications thanks to the resources (data or functions) stored in the subscriber module.
  • the server receiving the identity information of a mobile device and its subscriber module and comprising the identifiers IMEISV and the IMSI decides, according to certain criteria, if a new instruction must be sent to the subscriber module to redefine a new protection profile defining the resources of the subscriber module that can be used by the applications executed in the mobile equipment.
  • the criteria can refer, for example, to the update of the software version installed on the mobile equipment, to the downloading of new applications on the mobile equipment, to the period of update of the protection profile, to the number of connections to the network, to the technology used for network access, to the identity of the access network used. They are also linked to various risks associated with the hardware or software used that the operator and / or the application provider and / or the user of the mobile equipment wish to take into account.
  • Verification of the cryptogram can be carried out during the first start-up or when using an application for the first time or each time it is started. According to a variant, it can be executed periodically at a given rate according to instructions from the control server.
  • the attached cryptogram accompanying the application generally includes a fingerprint of the application itself, i.e. a data block calculated from the code of the application using a one-way hash mathematical function.
  • the subscriber module verifies the validity of the cryptogram, it also identifies, indirectly, the mobile equipment and ensures that the data actually come from the control server. In other words, by this cryptogram, the control server implicitly gives the subscriber module the assurance that the type and version of software of the mobile equipment have been taken into account, that the loading of the application has been controlled. and that the application is authentic. According to instructions previously received, the subscriber module will decide to authorize or refuse requests or commands from the application.
  • the mobile equipment plays a relay role in this verification step by establishing an almost direct dialogue between the subscriber module and the control server.
  • the security of the messages exchanged is ensured from end to end between the control server and the subscriber module via the execution environment of the applications of the mobile equipment. This therefore cannot "cheat” or transform the data vis-à-vis the subscriber module.
  • the present invention also relates to a security module comprising resources intended to be locally accessed by at least one application installed in equipment connected to a network, said equipment comprising means for reading and transmitting data comprising at least the identifier of the equipment and the identifier of the security module, said module is characterized in that it comprises means for receiving, storing and analyzing a cryptogram containing among other data a fingerprint of said application and instructions, means for verifying said application and means for extracting and executing the instructions contained in the cryptogram releasing or blocking certain resources according to the result of the verification of the application.
  • This security module is used for example as a subscriber module or SIM card connected to mobile equipment.
  • FIG. 1a illustrates a block diagram showing the process of installing an application according to a first embodiment where the cryptogram is delivered via the application execution environment.
  • Figure 1b illustrates the cryptogram verification process according to the mode of Figure 1a.
  • Figure 1c illustrates the process of executing the application using the resources of the subscriber module according to the mode of Figure 1a.
  • FIG. 2a illustrates a block diagram showing the process of installing an application according to a second mode where the application alone is downloaded.
  • Figure 2b illustrates the verification process where the application requests a cryptogram from the control server according to the mode of Figure 2a.
  • Figure 2c illustrates the process of executing the application using the resources of the subscriber module according to the mode of Figure 2a.
  • FIG. 3a illustrates a block diagram showing the process of installing an application according to a third mode where the application alone is downloaded.
  • FIG. 3b illustrates the verification process where the application requests a cryptogram and a fingerprint of the application from the control server according to the mode of FIG. 3a.
  • FIG. 3c illustrates the process of the execution of the application using the resources of the subscriber module according to the mode of FIG. 3a.
  • FIG. 4 illustrates the structure of an example cryptogram.
  • the block diagrams of Figures 1a, 1b, 1c, 2a, 2b, 2c, 3a, 3b, 3c show a set of mobile equipment (CB) subscriber module (SIM) containing resources (RES) connected via a mobile network (NET) to a control server (CSE) administered by an operator.
  • This server (CSE) is connected to one or more application providers (FA).
  • the mobile equipment (CB) includes one or more software applications (APP) operating in an execution environment (AEE).
  • APP software applications
  • AEE execution environment
  • These applications (APP) come either from the application supplier (FA) associated with the operator's control server (CSE), or they can be programmed from the manufacturer of the mobile equipment (CB). In the latter case, it is sometimes necessary to download updates which are also checked by the subscriber module (SIM).
  • the cryptogram (CRY) of an application is delivered to the subscriber module (SIM) via the application execution environment (AEE ) during the application installation process (APP).
  • FIG 1a illustrates the installation process where the mobile equipment (CB) first transmits data used for identification (ID) of the subscriber module (SIM) that the control server (CSE) checks.
  • This identification (ID) is carried out from the identifier (IMSI) of the subscriber module (SIM) and the unique identifier (IMEISV) of the mobile equipment (CB).
  • An application (APP) is then downloaded from the server (CSE) accompanied by a cryptogram (CRY) which will be transmitted to the subscriber module (SIM) via the execution environment (AEE) for verification as illustrated in the figure 1 b.
  • the supplier (FA) is considered trustworthy by the operator, that is to say that the applications (APP) are approved and operate without causing any harm to the user and / or to the operator.
  • the method according to the invention applies to several forms of applications (APP) executed in different types of execution environment (AEE).
  • AEE execution environment
  • many mobile phones have features from Java applications that are executed by a Java virtual machine (VM) serving as processor and environment.
  • VM Java virtual machine
  • the description below is based on the example of Java applications.
  • other environments or operating systems such as Symbian OS, Windows, Palm OS, Linux etc. can be used as application support.
  • a Java application requests the subscriber module (SIM), it informs the execution environment (AEE) by sending requests or commands (CMD).
  • the execution environment (AEE) calculates the fingerprint (FIN2) of the application (APP) and sends it to the subscriber module (SIM).
  • the cryptogram (CRY) which has been generated by the control server (CSE) and then loaded into the mobile equipment (CB) with the application (APP) (or separately), is stored in the subscriber module (SIM) .
  • the latter first checks that he actually has the necessary data allowing him to decide whether to respond to requests or commands (CMD) from the application (APP).
  • the subscriber module checks the fingerprint (FINI) from the stored cryptogram (CRY) by comparing it with the fingerprint (FIN2) associated with the application (APP) and provided by the application environment (AEE).
  • This cryptogram (CRY) can be constituted in the form of a block encrypted by a private key of the RSA type (Rivest, Shamir, Adelman).
  • This block represented by FIG. 4 contains for example, among other data, the IMSI identifier (ID_SIM) of the subscriber module (SIM), the identifier IMEISV (ID_CB) of the mobile equipment (CB), an identifier ( App_id) of the application, the fingerprint
  • This private key would only be known to the control server (CSE), while its public part would be known to the subscriber module (SIM).
  • SIM subscriber module
  • the advantage of using of asymmetric keys resides in the fact that the key used to create cryptograms is not outside the control server (CSE).
  • the key would be known to the server (CSE) and the subscriber module (SIM), for example an IDEA algorithm (International Data Encryption Algorithm) could be used to sign the block (IMSI, IMEISV, identifier of the application, application fingerprint, SIM resource identifiers, instructions for blocking / releasing SIM resources).
  • IDEA International Data Encryption Algorithm
  • TDES Triple Data Encryption Standard
  • AES Advanced Encryption Standard
  • the subscriber module checks the concordance of the different fields appearing in the cryptogram (CRY), in particular it checks the application identifiers (ID_APP) and the application fingerprints ( FINISHED) who are authorized or not to use its resources (RES) (data or functions).
  • ID_APP application identifiers
  • FINISHED application fingerprints
  • the cryptogram can include a counter used to prevent the double use of the same cryptogram addressed to the subscriber module (SIM) (replay attack).
  • SIM subscriber module
  • two applications of the same type can have the same identifier and have the same fingerprint (FINISHED).
  • the subscriber module (SIM) will also control the value of this counter by comparison with that of a reference counter stored and regularly updated.
  • a variant of the counter is to use a random number (random number) generated by the subscriber module (SIM). This hazard is transmitted with the data sent to the control server (CSE). The latter returns this hazard in the response message and the subscriber module (SIM) can verify that it is indeed a new message. More generally, in order to avoid any risk of using an old cryptogram (CRY), the latter includes a variable predictable by the subscriber module (SIM), either a counter or a hazard.
  • the cryptogram (CRY) generated using a key of the RSA or IDEA type can be replaced by a block generated with a shared key HMAC (Keyed-Hashing for Message Authentication) from the set ( IMSI, IMEISV, application identifier, application fingerprint, SIM resource identifiers, instructions for blocking / releasing SIM resources).
  • HMAC is a mechanism for authenticating messages by using cryptographic hash functions such as MD5 (Message Digest) or SHA-1 (Secure Hash Algorithm), in combination with a shared key.
  • This key present both in the control server (CSE) and in the subscriber module (SIM) can be loaded during the customization of the subscriber module (SIM) or during the installation of certain resources (RES ) in the subscriber module (SIM).
  • each resource (RES) or group of resources in the subscriber module (SIM) can be associated with a different key, or else, the key can be global for all resources (RES) and unique for a given subscriber module (SIM).
  • the cryptogram (CRY) thus allows the subscriber module (SIM) to know the resource or resources (RES) that can be released or blocked in the subscriber module (SIM) for the corresponding mobile equipment (CB).
  • the two fingerprints used are decisive elements because they constitute a means of cryptographic control of the application (APP) by the mobile equipment (CB) and by the subscriber module (SIM). Such control is necessary in order to prevent a third-party application from authenticating with a given cryptogram (CRY).
  • the cryptogram A authenticates the application A with the subscriber module A in a mobile device A
  • another application B authenticates unduly with this same cryptogram A with the subscriber module A in mobile equipment A.
  • the fingerprint of the application (FINI) included in the cryptogram (CRY) remains confidential from start to finish between the control server (CSE) and the subscriber module (SIM).
  • the fingerprint (FINI) is encrypted by the control server (CSE) and decrypted by the subscriber module (SIM).
  • the application (APP) can be personalized for a given load so that the fingerprint (FINI) included in the cryptogram (CRY) and the fingerprint (FIN2) of the application (APP) calculated by the execution environment (AEE) remains identical but depends on the identity of the mobile equipment (CB).
  • Such a measure is necessary if one wishes to prevent a third-party application from authenticating with a given fingerprint in another application execution environment (AEE) whose interface with the subscriber module (SIM) would be compromised. Indeed, if the fingerprint A authenticates the application A with the subscriber module A in a mobile device A, it is necessary to avoid that another application B authenticates unduly with this same fingerprint A with the subscriber module B in mobile equipment B.
  • each application (of the Java type) is accompanied by two cryptograms: a Java cryptogram intended for the virtual machine (VM) and a cryptogram (CRY) intended for the subscriber module (SIM).
  • These two cryptograms include, among other things, the same application fingerprint (here called FIN2) which is that of the code of the Java application.
  • FIN2 application fingerprint
  • the subscriber module (SIM) must verify the cryptogram (CRY) of an application, it expects from the virtual machine (VM) the fingerprint (FIN2) associated with the application (APP) in question. it will necessarily have calculated before.
  • the fingerprint of the application is transmitted by the mobile equipment (CB) to the subscriber module (SIM).
  • This fingerprint does not come from the control server, it is calculated by the application execution environment (AEE) of the mobile equipment (CB) after the download of the application (APP).
  • the mobile equipment (CB) transmits the cryptogram (CRY) previously loaded in addition to the application from the control server to the subscriber module.
  • the latter can verify the fingerprint received by comparison.
  • Mobile equipment (CB) cannot cheat until it knows the footprint expected by the subscriber module (SIM); if necessary, this would require rendering the footprint calculation function, usually a hash function, reversible or to find another fingerprint giving the same cryptogram (CRY) which is almost impossible.
  • FIG 1b shows the cryptogram verification process (CRY) which can be carried out either regularly, for example before each request of the application (APP) concerned, or, preferably, only once before its installation or before its first use.
  • the subscriber module (SIM) transmits an acceptance message (OK) to the execution environment (AEE).
  • the application (APP) can then send its requests or commands (CMD) to the subscriber module (SIM) via the execution environment (AEE) and use the resources (RES) of the subscriber module (SIM).
  • CMS requests or commands
  • the latter accepts commands (CMD) by transmitting the appropriate responses (RSP) to the application (APP) via the execution environment (AEE), see Figure 1c.
  • the subscriber module (SIM) transmits a refusal message (NOK) to the execution environment (AEE).
  • the execution environment (AEE) can either cancel the application installation process (APP), or the application (APP) is installed and its requests or commands (CMD) addressed to the module subscriber (SIM) via the execution environment (AEE) will remain unanswered (RSP) and the resources (RES) of the subscriber module (SIM) cannot be used.
  • the application execution environment (AEE) can relay the response to the control server (CSE).
  • the subscriber module can thus indirectly send a confirmation (CF) of receipt of the cryptogram (CRY) to the control server (CSE) and allow end-to-end control of the operation, see FIG. 1b.
  • the confirmation (CF) includes at least one success or error code for the operation as well as a counter used to protect against repetitive attacks.
  • This message also allows the control server (CSE) to keep the counter associated with the subscriber module (SIM) up to date.
  • the application (APP) is downloaded alone, after identification (ID) of the mobile equipment (CB), without cryptogram (CRY), see Figure 2a.
  • the application requests, when it is launched by the user, a cryptogram (CRY) comprising the rights of use of resources (RES) for said application.
  • This cryptogram (CRY) is downloaded from the control server (CSE) directly by the application (APP) which transmits it to the subscriber module (SIM) via the execution environment (AEE).
  • the subscriber module (SIM) transmits a confirmation (CF) of receipt of the cryptogram (CRY) to the server (CSE), through the application (APP) and not through the execution environment ( AEE) as in the case of the first embodiment.
  • the execution environment (AEE) only plays a relay role between the application (APP) and the subscriber module (SIM).
  • Figures 3a, 3b, 3c show a third variant where the application APP is downloaded alone, after identification (ID) of the mobile equipment (CB), from the control server (CSE) or from an intermediate download server d 'applications (APP) see Figure 3a.
  • the application loads the cryptogram (CRY) and the fingerprint (FIN2) directly from the server (CSE) or from an intermediate application download server (APP).
  • the application environment (AEE) no longer calculates the fingerprint (FIN2) which is calculated by an external unit either by the CSE control server or by an intermediate server application download (APP).
  • This third embodiment may be preferred since its advantage is that it does not require any modification of the execution environment (AEE) as it is currently defined for Java applications installed in mobile phones, that is to say say that modification of existing standards is not necessary.
  • the mobile equipment can be replaced by non-mobile equipment such as a pay-TV decoder or a computer.
  • Applications can be downloaded into the equipment from a server via a telecommunications network.
  • a cryptogram associated with the application is stored in the security module and verified during commissioning or each time an application is started. The result of this verification conditions the operation of the application by freeing or blocking resources in the security module.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Technology Law (AREA)
  • Multimedia (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Crystals, And After-Treatments Of Crystals (AREA)
  • Adhesives Or Adhesive Processes (AREA)
  • Storage Device Security (AREA)
  • Telephone Function (AREA)
  • Saccharide Compounds (AREA)
  • Preparation Of Compounds By Using Micro-Organisms (AREA)
  • Computer And Data Communications (AREA)
  • Vending Machines For Individual Products (AREA)

Abstract

Le but de la présente invention est de proposer une méthode la gestion de la sécurité d'applications mise en oeuvre avec un module de sécurité associé à un équipement mobile. Ce but est atteint par une méthode d'authentification d'au moins une application (APP) fonctionnant dans un équipement (CB) connecté par un réseau (NET) à un serveur de contrôle (CSE), ledit équipement (CB) étant localement connecté à un module de sécurité (SIM), ladite application (APP) est chargée et/ou exécutée au moyen d'un environnement d'exécution d'applications (AEE) de l'équipement (CB) et utilise des ressources (RES) stockées dans le module de sécurité (SIM), comprenant les étapes préliminaires suivantes: réception de données comprenant au moins l'identifiant (IMEISV) de l'équipement (CB) et l'identifiant (IMSI) du module de sécurité (SIM), via le réseau (NET), par le serveur de contrôle (CSE) analyse et vérification par le serveur de contrôle (CSE) desdites données, génération d'un cryptogramme (CRY) comprenant une empreinte (FINI) de l'application (APP), des données identifiant l'équipement (CB) et le module de sécurité (SIM) et des instructions (INS RES) destinées audit module, transmission dudit cryptogramme (CRY), via le réseau (NET) et l'équipement (CB), au module de sécurité (SIM), vérification de l'application (APP) en comparant l'empreinte (FINI) extraite du cryptogramme (CRY) reçu avec une empreinte (FIN2) déterminée par le module de sécurité (SIM), ladite méthode est caractérisée en ce que, lors de l'initialisation et/ou de l'activation de l'application (APP), le module de sécurité (SIM) exécute les instructions (INS RES) extraites du cryptogramme (CRY) et libère, respectivement bloque l'accès à certaines ressources (RES) dudit module de sécurité (SIM) en fonction du résultat de la vérification propre à cette application (APP) effectuée préalablement.

Description

MÉTHODE D'AUTHENTIFICATION D'APPLICATIONS
La présente invention concerne le domaine des réseaux mobiles appelés aussi réseaux cellulaires. Elle concerne plus particulièrement la gestion de la sécurité d'applications mise en œuvre avec un module de sécurité associé à un équipement mobile de téléphonie mobile.
Le module de sécurité d'un téléphone mobile ou portable est connu sous l'appellation "carte SIM" (Subscriber Identity Module) constituant l'élément central de la sécurité de ces téléphones. L'opérateur de téléphonie introduit, à la fabrication et/ou lors d'une phase de personnalisation, un numéro appelé IMSI (International Mobile Subscriber Identification) servant à identifier d'une manière sûre et unique chaque abonné désirant se connecter sur un réseau mobile. Chaque téléphone mobile, appelé équipement mobile ci-après, est identifié physiquement par un numéro stocké dans une mémoire non volatile de l'équipement mobile. Ce numéro, appelé IMEI, (International Mobile Equipment Identifier) contient une identification du type d'équipement mobile et un numéro de série servant à identifier de manière unique un équipement mobile donné sur un réseau du type GSM (Global System for Mobile communications), GPRS (General Packet Radio System) ou UMTS (Universal Mobile Télécommunications System). De plus, un équipement mobile est caractérisé par une version de logiciel SVN (Software Version Number) indiquant l'état de mise à jour du logiciel de base installé sur l'équipement mobile. La combinaison de l'identification du type et du numéro de série de l'équipement mobile avec la version de logiciel (SVN) donne une nouvelle identification, appelée IMEISV (International Mobile Equipment Identifier and Software Version Number). Le même concept d'identification s'applique également au WLAN (Wireless LAN) ou au câble TV bidirectionnel. L'identifiant physique peut être une adresse MAC (Media Access Control) qui correspond à l'adresse unique identifiant la configuration du matériel d'un utilisateur sur un réseau IP (Internet Protocol) et la version de logiciel peut être transmise par des protocoles de couche supérieure basés sur IP.
Les normes ETSI ("European Télécommunications Standards Institute"), définissent une station mobile (MS, mobile station) composée d'un équipement mobile (ME, mobile equipment) et d'un module d'abonné (SIM, subscriber identity module). Ce module d'abonné est en général amovible c'est-à-dire qu'il peut être soit retiré soit transféré d'un équipement mobile à un autre.
Lors de la mise en service d'un équipement mobile, plus particulièrement lors de sa connexion au réseau d'un opérateur, des informations comprenant les données d'identification sont échangées entre l'équipement mobile et le centre de gestion de l'opérateur qui autorise ou non son utilisation. Actuellement un équipement mobile offre à l'utilisateur, en plus de sa fonction usuelle d'établissement de conversations téléphoniques par le biais d'un accès à un réseau mobile, l'utilisation de nombreux autres services supplémentaires à valeur ajoutée tels que la consultation de diverses informations, les opérations bancaires à distance, le commerce électronique, l'accès à du contenu multimédia, etc. Ces services évolués nécessitent un niveau de sécurité de plus en plus élevé afin de prémunir les utilisateurs contre les fraudes éventuelles causées par des tiers cherchant à exploiter des failles de sécurité qui peuvent apparaître sur les équipements mobiles.
Une vérification devient donc nécessaire au moins à deux niveaux: d'une part au niveau de l'équipement mobile lui-même et d'autre part à celui des applications logicielles permettant le fonctionnement des différents services proposés par l'opérateur ou des parties tierces. Ces applications sont en général téléchargées depuis le serveur d'un fournisseur d'applications, ce qui implique la nécessité de vérifier ce téléchargement. Il s'agit donc de garantir que le module d'abonné ne fournit des informations qu'à des applications autorisées une fois que ce module a été reconnu par le serveur de contrôle comme pouvant fonctionner avec l'équipement mobile dans lequel il est inséré.
Le module d'abonné peut contenir des informations confidentielles tels qu'un numéro de compte bancaire ou un mot de passe. Une application fonctionnant sur l'équipement mobile sera en charge d'utiliser ces données personnelles afin de fournir le service attendu. Néanmoins, une application pourrait détourner ces données personnelles à d'autres fins que le dialogue avec le fournisseur d'application concerné. Il peut en résulter un préjudice important pour le propriétaire du module d'abonné. Ces applications exécutées dans l'équipement mobile utilisent des ressources disponibles dans le module d'abonné. Par ressources, on entend diverses fonctions et données nécessaires au bon fonctionnement d'une application. Certaines de ces ressources peuvent être communes à plusieurs applications, notamment les fonctions liées à la sécurité. Le module d'abonné peut ainsi bloquer ou altérer le fonctionnement de certaines applications pour lesquelles les conditions de sécurité établies par l'opérateur et/ou les fournisseurs d'applications ne sont pas respectées dans l'équipement mobile en question ou les droits de l'utilisateur de l'équipement mobile sont insuffisants.
Le document FR2831362 décrit un procédé de transaction sécurisée entre un téléphone mobile muni d'une carte SIM et un serveur d'applications. Le but de ce procédé est de protéger des droits liés à l'utilisation d'applications téléchargées depuis le serveur au moyen de la carte SIM.
Selon ce procédé, un lien de confiance est d'abord établi entre le serveur et la carte SIM par l'échange sécurisé de clés publiques, puis un achat d'une application est effectué par la transmission d'un fichier de demande par l'équipement mobile au serveur. Celui-ci encrypte partiellement ou entièrement l'application et transmet à l'équipement mobile un cryptogramme formé par la clé d'encryption et une commande, le tout crypté avec une clé publique connue de la carte SIM. A la réception par l'équipement mobile, ce cryptogramme est décrypté et la clé stockée dans la carte SIM. L'exécution de la commande entraîne le téléchargement dans l'équipement mobile de l'application partiellement ou entièrement encryptée par le serveur. Une fois chargée, l'application est décryptée par la clé stockée dans la carte SIM puis installée dans l'équipement mobile.
Selon ce procédé, les droits d'utiliser l'application dans l'équipement mobile sont protégés du fait du lien de confiance établi initialement entre l'équipement et le serveur et précédant la transaction. Le rôle joué par le serveur se concentre ici plutôt dans la gestion des droits ou DRM (Digital Rights Management) des utilisateurs d'une application dans un équipement mobile. La solution développée ci- après est orientée plutôt vers la gestion des risques (Risk Management) pris en compte par l'opérateur, le fournisseur d'application ou l'utilisateur par rapport à une application.
Le but de la présente invention est de proposer une méthode d'authentification de ou des applications dans un équipement mobile tant lors de leur téléchargement que lors de leur exécution. Il s'agit de limiter les risques liés au fait qu'un module d'abonné soit utilisé à mauvais escient soit par des applications ne remplissant pas certains critères de sécurité, soit par des équipements mobiles ne remplissant pas certains critères de sécurité préétablis.
Un autre but est de protéger l'utilisateur de l'équipement mobile ainsi que les fournisseurs d'applications concernés contre les abus résultants de l'usage d'applications non autorisées.
Ces buts sont atteints par une méthode d'authentification d'au moins une application fonctionnant dans un équipement connecté par un réseau à un serveur de contrôle, ledit équipement étant localement connecté à un module de sécurité, ladite application est chargée et/ou exécutée au moyen d'un environnement d'exécution d'applications de l'équipement et utilise des ressources stockées dans le module de sécurité, comprenant les étapes préliminaires suivantes: réception de données comprenant au moins l'identifiant de l'équipement et l'identifiant du module de sécurité, via le réseau, par le serveur de contrôle, - analyse et vérification par le serveur de contrôle desdites données,
- génération d'un cryptogramme comprenant une empreinte de l'application, des données identifiant l'équipement et le module de sécurité et des instructions destinées audit module, transmission dudit cryptogramme, via le réseau et l'équipement, au module de sécurité, vérification de l'application en comparant l'empreinte extraite du cryptogramme reçu avec une empreinte déterminée par le module de sécurité, ladite méthode est caractérisée en ce que, lors de l'initialisation et ou de l'activation de l'application, le module de sécurité exécute les instructions extraites du cryptogramme et libère, respectivement bloque l'accès à certaines ressources dudit module de sécurité en fonction du résultat de la vérification propre à cette application effectuée préalablement. Les ressources du module de sécurité sont bloquées ou libérées de manière ciblée, ceci dans le but de rendre certaines applications utilisables ou non. On ne bloque pas ou libère pas directement des applications de l'équipement mobile: on agit de manière indirecte sur les applications, c'est-à-dire que l'effet de blocage ou de libération va se manifester uniquement lorsque l'équipement mobile essaiera d'exécuter ces applications.
Cette méthode s'applique de préférence au réseau mobile. Par conséquent, l'équipement est, par exemple, un équipement de téléphonie mobile et le module de sécurité un module d'abonné ou carte SIM. Cet ensemble se connecte à un réseau mobile du type GSM (Global System for Mobile communications), GPRS (General Packet Radio Service), UMTS (Universal Mobile Télécommunications System) ou autre, géré par un serveur de contrôle d'un opérateur. Des applications logicielles sont installées dans l'équipement mobile et configurées de manière à utiliser des ressources (données ou fonctions) présentes dans le module d'abonné. Elles ne peuvent donc être utilisées dans leur intégralité seulement si les conditions de sécurités sont satisfaites selon des critères préétablis par l'opérateur et/ou le fournisseur d'applications. Cette vérification des critères est à la charge du serveur de contrôle. L'application, suite aux instructions envoyées par le serveur de contrôle, est finalement à la charge du module de sécurité qui peut laisser libre ou bloquer l'accès à des ressources nécessaires au bon fonctionnement d'une application installée dans l'équipement mobile.
Les données de ces ressources peuvent comprendre des informations tels que numéro de comptes, des programmes (sous forme de code pouvant être installé dans l'équipement mobile), des clés d'encryption/décryption, des droits d'accès à du contenu, etc.
Les fonctions de ces ressources peuvent comprendre des algorithmes cryptographiques, des processus de vérification, des processus de génération de signatures digitales, des processus d'encryptage, des processus d'authentification, des processus de validation de données, des processus de contrôle d'accès, des processus de sauvegarde de données, des processus de paiement etc.
La méthode selon l'invention est basée sur le fait qu'à une application on associe un cryptogramme qui conditionne l'utilisation de l'application sur un équipement mobile connecté à un réseau.
A la différence du procédé décrit dans le document FR2831362, l'encryption partielle ou entière de l'application, avant téléchargement dans l'équipement mobile, n'est pas nécessaire. En effet, selon la méthode de l'invention, la liaison entre le serveur et le module de sécurité (ou module d'abonné) sert à contrôler de manière optimale ses ressources et à décider leur mise en service ou non par rapport aux applications exécutées dans l'équipement mobile. La commande reçue du serveur, dans le procédé du document cité, permet de contrôler l'utilisation de l'application installée dans l'équipement mobile, tandis que dans la présente méthode, elle permet d'activer ou désactiver des ressources du module de sécurité.
Par exemple, lorsque des ressources sont désactivées, l'application fonctionnera d'une façon "minimale" laissant un nombre réduit de possibilités à l'utilisateur. Dans un exemple de réalisation, cette réduction peut porter sur le montant maximum autorisé pour l'achat de services et de plus, ces services ne pourraient être obtenus que dans un lieu donné (centre commercial, stade, gare, aéroport, etc.)
Dans un premier mode de réalisation, le cryptogramme est transmis au module d'abonné pendant le chargement de l'application. Dans un second mode de réalisation, c'est l'application qui va chercher le cryptogramme sur le serveur de contrôle lors de sa première utilisation.
La méthode d'authentification selon l'invention s'applique également lors de l'exécution d'une application par l'équipement mobile, ce qui permet de s'assurer, à l'aide du module d'abonné, que cette application est autorisée à accéder certaines ressources (données ou fonctions) contenues dans ledit module d'abonné. En particulier, le module d'abonné peut vérifier régulièrement le cryptogramme attaché à une application au cours de l'exécution de ladite application. Par exemple, l'insertion d'un module d'abonné d'un utilisateur dans un autre équipement mobile influencera le fonctionnement de certaines applications sans empêcher l'établissement de communications téléphoniques classiques. Cette barrière agit en quelque sorte comme un filtre visant à éliminer des équipements mobiles non autorisés ou encore des applications provenant de sources non agréées par l'opérateur ou un fournisseur d'application partenaire.
Une modification de l'application par un tiers est également détectée par le module d'abonné qui refusera d'exécuter certaines commandes reçues entraînant ainsi le blocage ou des limitations de l'exécution de l'application.
Le serveur de contrôle joue donc un rôle essentiel en gérant les éléments de confiance ou de sécurité liés à l'ensemble équipement mobile/module d'abonné. Il interprète les données qui lui sont transmises par l'équipement mobile afin de contrôler ou limiter l'utilisation d'applications grâce aux ressources (données ou fonctions) stockées dans le module d'abonné.
Le serveur recevant les informations d'identité d'un équipement mobile et de son module d'abonné et comprenant les identifiants IMEISV et l'IMSI décide, selon certains critères, si une nouvelle instruction doit être envoyée au module d'abonné pour redéfinir un nouveau profil de protection définissant les ressources du module d'abonné pouvant être utilisées par les applications exécutées dans l'équipement mobile. Les critères peuvent se référer, par exemple, à la mise à jour de la version de logiciel installée sur l'équipement mobile, au téléchargement de nouvelles applications sur l'équipement mobile, à la période de mise à jour du profil de protection, au nombre de connexions au réseau, à la technologie utilisée pour l'accès au réseau, à l'identité du réseau d'accès utilisé. Ils sont également liés à différents risques associés au matériel ou aux logiciels utilisés que l'opérateur et/ou le fournisseur d'applications et/ou l'utilisateur de l'équipement mobile désirent prendre en compte.
La vérification du cryptogramme peut s'effectuer lors du premier démarrage ou lors de la première utilisation d'une application ou à chaque démarrage de celle-ci. Selon une variante, elle peut être exécutée périodiquement à un rythme donné selon des instructions provenant du serveur de contrôle.
Lors d'un chargement d'une application dans un équipement mobile, le cryptogramme attaché accompagnant l'application inclut en général une empreinte de l'application elle-même, c'est à dire un bloc de données calculé à partir du code de l'application à l'aide d'une fonction mathématique unidirectionnelle de hachage.
Lorsque le module d'abonné vérifie la validité du cryptogramme, il identifie aussi, de manière indirecte, l'équipement mobile et s'assure que les données viennent effectivement du serveur de contrôle. Autrement dit, par ce cryptogramme, le serveur de contrôle donne implicitement l'assurance au module d'abonné que le type et la version de logiciel de l'équipement mobile ont été pris en compte, que le chargement de l'application a été contrôlé et que l'application est authentique. Selon des instructions préalablement reçues, le module d'abonné décidera d'autoriser ou de refuser des requêtes ou des commandes venant de l'application.
L'équipement mobile joue un rôle de relais dans cette étape de vérification en établissant un dialogue quasi direct entre le module d'abonné et le serveur de contrôle. Ainsi la sécurité des messages échangés est assurée de bout en bout entre le serveur de contrôle et le module d'abonné via l'environnement d'exécution des applications de l'équipement mobile. Celui-ci ne peut donc pas "tricher" ou transformer les données vis-à-vis du module d'abonné.
La présente invention concerne également un module de sécurité comprenant des ressources destinées à être localement accédées par au moins une application installée dans un équipement relié à un réseau, ledit équipement comprenant des moyens de lecture et de transmission de données comprenant au moins l'identifiant de l'équipement et l'identifiant du module de sécurité, ledit module est caractérisé en ce qu'il comprend des moyens de réception, de stockage et d'analyse d'un cryptogramme contenant entre autre données une empreinte de ladite application et des instructions, des moyens de vérification de ladite application et des moyens d'extraction et d'exécution des instructions contenues dans le cryptogramme libérant ou bloquant certaines ressources selon le résultat de la vérification de l'application. Ce module de sécurité est utilisé par exemple comme module d'abonné ou carte SIM connecté à un équipement mobile.
L'invention sera mieux comprise grâce à la description détaillée qui va suivre et qui se réfère aux figures annexées données à titre d'exemple nullement limitatif, à savoir:
- La figure 1a illustre un schéma bloc montrant le processus d'installation d'une application selon un premier mode de réalisation où le cryptogramme est délivré via l'environnement d'exécution d'applications.
- La figure 1 b illustre le processus de vérification du cryptogramme selon le mode de la figure 1a.
- La figure 1c illustre le processus de l'exécution de l'application utilisant les ressources du module d'abonné selon le mode de la figure 1a.
- La figure 2a illustre un schéma bloc montrant le processus d'installation d'une application selon un second mode où l'application seule est téléchargée.
- La figure 2b illustre le processus de vérification où l'application sollicite un cryptogramme auprès du serveur de contrôle selon le mode de la figure 2a.
- La figure 2c illustre le processus de l'exécution de l'application utilisant les ressources du module d'abonné selon le mode de la figure 2a.
- La figure 3a illustre un schéma bloc montrant le processus d'installation d'une application selon un troisième mode où l'application seule est téléchargée.
La figure 3b illustre le processus de vérification où l'application sollicite un cryptogramme et une empreinte de l'application auprès du serveur de contrôle selon le mode de la figure 3a.
La figure 3c illustre le processus de l'exécution de l'application utilisant les ressources du module d'abonné selon le mode de la figure 3a.
- La figure 4 illustre la structure d'un exemple de cryptogramme. Les schémas blocs des figures 1a, 1 b, 1c, 2a, 2b, 2c, 3a, 3b, 3c montrent un ensemble équipement mobile (CB) module d'abonné (SIM) contenant des ressources (RES) relié via un réseau mobile (NET) à un serveur de contrôle (CSE) administré par un opérateur. Ce serveur (CSE) est connecté à un ou plusieurs fournisseurs d'applications (FA).
L'équipement mobile (CB) inclut une ou plusieurs applications (APP) logicielles fonctionnant dans un environnement d'exécution (AEE). Ces applications (APP) proviennent, soit du fournisseur d'applications (FA) associé au serveur de contrôle (CSE) de l'opérateur, soit, elles peuvent être programmées d'origine par le fabricant de l'équipement mobile (CB). Dans ce dernier cas, il est parfois nécessaire de télécharger des mises à jour qui sont également vérifiées par le module d'abonné (SIM).
Selon le premier mode de réalisation illustré par les figures 1a, 1b, 1c, le cryptogramme (CRY) d'une application (APP) est délivré au module d'abonné (SIM) via l'environnement d'exécution d'applications (AEE) lors du processus d'installation de l'application (APP).
La figure 1a illustre le processus d'installation où l'équipement mobile (CB) transmet d'abord des données servant à l'identification (ID) du module d'abonné (SIM) que le serveur de contrôle (CSE) vérifie. Cette identification (ID) est effectuée à partir de l'identifiant (IMSI) du module d'abonné (SIM) et de l'identifiant (IMEISV) unique de l'équipement mobile (CB). Une application (APP) est ensuite téléchargée depuis le serveur (CSE) accompagnée d'un cryptogramme (CRY) qui sera transmis vers le module d'abonné (SIM) via l'environnement d'exécution (AEE) pour vérification comme illustré dans la figure 1 b.
II est à noter que le fournisseur (FA) est considéré comme digne de confiance par l'opérateur, c'est-à-dire que les applications (APP) sont homologuées et fonctionnent sans causer un quelconque préjudice à l'utilisateur et/ou à l'opérateur.
La méthode selon l'invention s'applique à plusieurs formes d'applications (APP) exécutées dans différents types d'environnement d'exécution (AEE). Par exemple, de nombreux téléphones mobiles possèdent des fonctionnalités issues d'applications Java qui sont exécutées par une machine virtuelle (VM) Java servant de processeur et d'environnement. La description ci-après se base sur l'exemple d'applications Java. Bien entendu, d'autres environnements ou systèmes d'exploitations tels que Symbian OS, Windows, Palm OS, Linux etc. peuvent être utilisés comme support d'applications.
Lors de son exécution, voir figure 1c, une application Java sollicite le module d'abonné (SIM), elle en informe l'environnement d'exécution (AEE) en lui adressant des requêtes ou commandes (CMD). L'environnement d'exécution (AEE) calcule l'empreinte (FIN2) de l'application (APP) et l'envoie au module d'abonné (SIM). Le cryptogramme (CRY) qui a été généré par le serveur de contrôle (CSE) puis chargé dans l'équipement mobile (CB) avec l'application (APP) (ou séparément), est stocké dans le module d'abonné (SIM). Ce dernier vérifie d'abord qu'il possède effectivement les données nécessaires lui permettant de décider s'il doit répondre à des requêtes ou commandes (CMD) de l'application (APP). Ces données, faisant office de droits chargés à partir du serveur de contrôle (CSE) lors du chargement de l'application (APP), permettent de contrôler le fonctionnement de l'application (APP). En cas d'absence de ces droits, l'application (APP) ne pourra utiliser les ressources (RES) (données ou fonctions) du module d'abonné (SIM).
Dans le cas où ces droits sont présents, le module d'abonné (SIM) vérifie l'empreinte (FINI) issue du cryptogramme (CRY) stocké en la comparant avec l'empreinte (FIN2) associée à l'application (APP) et fournie par l'environnement d'application (AEE). Ce cryptogramme (CRY) peut se constituer sous la forme d'un bloc encrypté par une clé privée du type RSA (Rivest, Shamir, Adelman). Ce bloc représenté par la figure 4 contient par exemple, entre autres données, l'identifiant IMSI (ID_SIM) du module (SIM) d'abonné, l'identifiant IMEISV (ID_CB) de l'équipement mobile (CB), un identificateur (ID_APP) de l'application, l'empreinte
(FINI) de l'application (APP), des identificateurs SIM (RESJD) des ressources
(RES) et des instructions (INS_RES) de blocage/libération des ressources SIM.
Cette clé privée ne serait connue que du serveur de contrôle (CSE), alors que sa partie publique serait connue du module d'abonné (SIM). L'avantage de l'utilisation de clés asymétriques réside en ce que la clé servant à créer des cryptogrammes ne se trouve pas à l'extérieur du serveur de contrôle (CSE).
Bien entendu, d'autres algorithmes à clés asymétriques tels que par exemple DSA (Digital Signature Algorithm), et ECC (Elliptic Curve Cryptography) peuvent constituer des alternatives à RSA
L'usage d'algorithme à clés symétriques peut être préféré pour des raisons de simplicité, de rapidité des vérifications ou de coûts de fabrication et de mise en œuvre plus faibles. Dans ce cas, la clé serait connue du serveur (CSE) et du module d'abonné (SIM), par exemple un algorithme IDEA (International Data Encryption Algorithm) pourrait être utilisé pour signer le bloc (IMSI, IMEISV, identificateur de l'application, empreinte de l'application, identificateurs des ressources SIM, instructions de blocage/libération des ressources SIM). Comme alternative à l'algorithme IDEA, des algorithmes tels que, par exemple, TDES (Triple Data Encryption Standard) et AES (Advanced Encryption Standard) peuvent auss i être utilisés.
Dans ces deux variantes à clés asymétriques et symétriques, le module d'abonné (SIM) vérifie la concordance des différents champs apparaissant dans le cryptogramme (CRY), notamment il contrôle les identificateurs d'applications (ID_APP) et les empreintes d'applications (FINI) qui sont autorisées ou non à utiliser ses ressources (RES) (données ou fonctions).
Dans une variante, le cryptogramme (CRY) peut inclure un compteur servant à empêcher le double usage d'un même cryptogramme adressé au module d'abonné (SIM) (replay attack). En effet deux applications du même type peuvent porter le même identificateur et avoir la même empreinte (FINI). Dans ce cas, le module d'abonné (SIM) contrôlera aussi la valeur de ce compteur par comparaison avec celle d'un compteur de référence stocké et régulièrement mis à jour.
Une variante au compteur est d'utiliser un aléa (nombre aléatoire) généré par le module d'abonné (SIM). Cet aléa est transmis avec les données envoyées au serveur de contrôle (CSE). Ce dernier renvoie cet aléa dans le message de réponse et le module d'abonné (SIM) peut vérifier qu'il s'agit bien d'un nouveau message. Plus généralement, afin d'éviter tout risqué d'usage d'un ancien cryptogramme (CRY), cette dernière comprend une variable prédictible par le module d'abonné (SIM), soit un compteur ou un aléa.
Dans une autre variante le cryptogramme (CRY) généré à l'aide d'une clé du type RSA ou IDEA peut être remplacée par un bloc généré avec une clé partagée HMAC (Keyed-Hashing for Message Authentication) à partir de l'ensemble (IMSI, IMEISV, identificateur de l'application, empreinte de l'application, identificateurs des ressources SIM, instructions de blocage/libération des ressources SIM). HMAC est un mécanisme pour l'authentification de messages par l'utilisation de fonctions de hachage cryptographiques telles que MD5 (Message Digest) ou SHA-1 (Secure Hash Algorithm), en combinaison avec une clé partagée.
Cette clé présente à la fois dans le serveur de contrôle (CSE) et dans le module d'abonné (SIM) peut être chargée lors de la personnalisation du module d'abonné (SIM) ou lors de l'installation de certaines ressources (RES) dans le module d'abonné (SIM). Selon les options, à chaque ressource (RES) ou groupe de ressources du module d'abonné (SIM) peut être associée une clé différente, ou bien, la clé peut être globale pour l'ensemble des ressources (RES) et unique pour un module d'abonné (SIM) donné.
Le cryptogramme (CRY) permet ainsi au module d'abonné (SIM) de connaître la ou les ressources (RES) pouvant être libérées ou bloquées dans le module d'abonné (SIM) pour l'équipement mobile (CB) correspondant.
Les deux empreintes utilisées (FINI, respectivement FIN2) sont des éléments déterminants car elles constituent un moyen de contrôle cryptographique de l'application (APP) par l'équipement mobile (CB) et par le module d'abonné (SIM). Un tel contrôle est nécessaire afin d'empêcher qu'une application tierce s'authentifie avec un cryptogramme (CRY) donné. En effet, si le cryptogramme A authentifie l'application A auprès du module d'abonné A dans un équipement mobile A, il faut éviter qu'une autre application B s'authentifie indûment avec ce même cryptogramme A auprès du module d'abonné A dans l'équipement mobile A. Selon une variante, l'empreinte de l'application (FINI) incluse dans le cryptogramme (CRY) reste confidentielle de bout en bout entre le serveur de contrôle (CSE) et le module d'abonné (SIM). Pour ce faire l'empreinte (FINI) est encryptée par le serveur de contrôle (CSE) et décryptée par le module d'abonné (SIM). De plus, l'application (APP) peut être personnalisée pour un chargement donné de manière à ce que l'empreinte (FINI) incluse dans le cryptogramme (CRY) et l'empreinte (FIN2) de l'application (APP) calculée par l'environnement d'exécution (AEE) restent identiques mais dépendent de l'identité de l'équipement mobile (CB). Une telle mesure est nécessaire si l'on désire empêcher qu'une application tierce s'authentifie avec une empreinte donnée dans un autre environnement d'exécution d'applications (AEE) dont l'interface avec le module d'abonné (SIM) serait compromise. En effet, si l'empreinte A authentifie l'application A auprès du module d'abonné A dans un équipement mobile A, il faut éviter qu'une autre application B s'authentifie indûment avec cette même empreinte A auprès du module d'abonné B dans l'équipement mobile B.
Selon une autre variante, chaque application (du type Java) est accompagnée de deux cryptogrammes: un cryptogramme Java destiné à la machine virtuelle (VM) et un cryptogramme (CRY) destiné au module d'abonné (SIM). Ces deux cryptogrammes comprennent entre autre la même empreinte d'application (ici appelée FIN2) qui est celle du code de l'application Java. Ainsi, lorsque le module d'abonné (SIM) doit vérifier le cryptogramme (CRY) d'une application, il attend de la machine virtuelle (VM) l'empreinte (FIN2) associée à l'application (APP) en question qu'elle aura forcément calculée auparavant. L'empreinte de l'application est transmise par l'équipement mobile (CB) au module d'abonné (SIM). Cette empreinte ne provient pas du serveur de contrôle, elle est calculée par l'environnement d'exécution d'applications (AEE) de l'équipement mobile (CB) après le téléchargement de l'application (APP). Par contre, l'équipement mobile (CB) transmet le cryptogramme (CRY) préalablement chargé en sus de l'application depuis le serveur de contrôle au module d'abonné. Ainsi, ce dernier peut vérifier l'empreinte reçue par comparaison. L'équipement mobile (CB) ne peut pas tricher tant qu'il ne connaît pas l'empreinte attendue par le module d'abonné (SIM); le cas échéant, cela nécessiterait de rendre la fonction de calcul de l'empreinte, habituellement une fonction de hachage, réversible ou de trouver une autre empreinte donnant le même cryptogramme (CRY) ce qui est quasiment impossible.
La figure 1 b montre le processus de vérification du cryptogramme (CRY) qui peut s'effectuer soit régulièrement, par exemple avant chaque sollicitation de l'application (APP) concernée, soit, de préférence, une seule fois avant son installation ou avant sa première utilisation. Si le cryptogramme (CRY) est valide, le module d'abonné (SIM) transmet un message d'acceptation (OK) à l'environnement d'exécution (AEE). L'application (APP) peut alors adresser ses requêtes ou commandes (CMD) au module d'abonné (SIM) via l'environnement d'exécution (AEE) et utiliser les ressources (RES) du module d'abonné (SIM). Ce dernier accepte les commandes (CMD) en transmettant les réponses (RSP) adéquates à l'application (APP) via l'environnement d'exécution (AEE), voir figure 1c.
Dans le cas d'un cryptogramme (CRY) non valide, le module d'abonné (SIM) transmet un message de refus (NOK) à l'environnement d'exécution (AEE). Dans un tel cas l'environnement d'exécution (AEE) peut soit annuler le processus d'installation de l'application (APP), soit l'application (APP) est installée et ses requêtes ou ses commandes (CMD) adressées au module d'abonné (SIM) via l'environnement d'exécution (AEE) resteront sans réponse (RSP) et les ressources (RES) du module d'abonné (SIM) ne pourront être utilisées.
Dans les deux cas d'acceptation et de refus (OK et NOK) l'environnement d'exécution d'application (AEE) peut relayer la réponse au serveur de contrôle (CSE). Le module d'abonné peut ainsi indirectement renvoyer une confirmation (CF) de réception du cryptogramme (CRY) au serveur de contrôle (CSE) et permettre un contrôle de bout en bout de l'opération, voir figure 1b. La confirmation (CF) comprend au moins un code de succès ou d'erreur de l'opération ainsi qu'un compteur servant à la protection contre des attaques par répétition. Ce message permet aussi au serveur de contrôle (CSE) de tenir à jour le compteur associé au module d'abonné (SIM). Selon le second mode de réalisation illustré par les figures 2a, 2b, 2c, l'application (APP) est téléchargée seule, après identification (ID) de l'équipement mobile (CB), sans cryptogramme (CRY), voir figure 2a.
Lors du processus de vérification, figure 2b, l'application (APP) sollicite, lors de son lancement par l'utilisateur, un cryptogramme (CRY) comprenant les droits d'utilisation de ressources (RES) pour ladite application. Ce cryptogramme (CRY) est téléchargé, depuis le serveur (CSE) de contrôle, directement par l'application (APP) qui le transmet au module d'abonné (SIM) via l'environnement d'exécution (AEE). Le module d'abonné (SIM) transmet une confirmation (CF) de réception du cryptogramme (CRY) au serveur (CSE), par le biais de l'application (APP) et non par le biais de l'environnement d'exécution (AEE) comme dans le cas du premier mode de réalisation. Dans ce mode, l'environnement d'exécution (AEE) ne joue qu'un rôle de relais entre l'application (APP) et le module d'abonné (SIM).
Le processus d'exécution de l'application (APP) après vérification du cryptogramme (CRY), voir figure 2c, se déroule de la même manière que dans le premier mode illustré par la figure 1c et décrit plus haut.
Les figures 3a, 3b, 3c montrent une troisième variante où l'application APP est téléchargée seule, après identification (ID) de l'équipement mobile (CB), depuis le serveur de contrôle (CSE) ou depuis un serveur intermédiaire de téléchargement d'applications (APP) voir figure 3a. Lors du processus de vérification (figure 3b), l'application charge le cryptogramme (CRY) et l'empreinte (FIN2) directement à partir du serveur (CSE) ou depuis un serveur intermédiaire de téléchargement d'applications (APP). Dans ce cas, à la différence des deux variantes précédentes, l'environnement d'application (AEE) ne calcule plus l'empreinte (FIN2) qui est calculée par une unité externe soit par le serveur de contrôle CSE, soit par un serveur intermédiaire de téléchargement d'applications (APP).
Le processus d'exécution de l'application (APP) après vérification du cryptogramme (CRY), voir figure 3c, se déroule de la même manière que dans les deux modes précédents illustrés par les figures 1c et 2c. Ce troisième mode de réalisation peut être préféré car son avantage est de ne demander aucune modification de l'environnement d'exécution (AEE) tel qu'il est défini actuellement pour les applications Java installées dans les téléphones mobiles, c'est-à-dire qu'une modification des normes existantes n'est pas nécessaire.
De plus, la contrainte de la première variante voulant que les deux cryptogrammes utilisent la même empreinte tombe étant donné que les processus de vérification du cryptogramme (CRY) et celui de l'installation de l'application sont totalement indépendants.
Afin de personnaliser les empreintes calculées sur les applications, une possibilité consiste à ajouter au code de l'application, avant son chargement dans l'équipement mobile, une donnée différente pour chaque équipement mobile. Ainsi, lorsque l'empreinte est calculée par l'environnement d'application de l'équipement mobile, cette empreinte est unique et ne peut servir à un autre équipement mobile. Le cryptogramme va bien entendu être calculé par le serveur de contrôle sur la base des données d'origine de l'application et de cette donnée unique.
Dans une variante de l'invention, l'équipement mobile peut être remplacé par un équipement non mobile tel qu'un décodeur de télévision à péage ou un ordinateur. Des applications peuvent être téléchargées dans l'équipement à partir d'un serveur via un réseau de télécommunications. Un cryptogramme associé à l'application est stocké dans le module de sécurité et vérifié lors de la mise en service ou lors de chaque démarrage d'une application. Le résultat de cette vérification conditionne le fonctionnement de l'application en libérant ou en bloquant des ressources dans le module de sécurité.

Claims

REVENDICATIONS
1. Méthode d'authentification d'au moins une application (APP) fonctionnant dans un équipement (CB) connecté par un réseau (NET) à un serveur de contrôle (CSE), ledit équipement (CB) étant localement connecté à un module de sécurité (SIM), ladite application (APP) est chargée et/ou exécutée au moyen d'un environnement d'exécution d'applications (AEE) de l'équipement (CB) et utilise des ressources (RES) stockées dans le module de sécurité (SIM), comprenant les étapes préliminaires suivantes: réception de données comprenant au moins l'identifiant (IMEISV) de l'équipement (CB) et l'identifiant (IMSI) du module de sécurité (SIM), via le réseau (NET), par le serveur de contrôle (CSE) analyse et vérification par le serveur de contrôle (CSE) desdites données, génération d'un cryptogramme (CRY) comprenant une empreinte (FINI) de l'application (APP), des données identifiant l'équipement (CB) et le module de sécurité (SIM) et des instructions (INS_RES) destinées audit module, transmission dudit cryptogramme (CRY), via le réseau (NET) et l'équipement (CB), au module de sécurité (SIM), vérification de l'application (APP) en comparant l'empreinte (FINI) extraite du cryptogramme (CRY) reçu avec une empreinte (FIN2) déterminée par le module de sécurité (SIM), ladite méthode est caractérisée en ce que, lors de l'initialisation et ou de l'activation de l'application (APP), le module de sécurité (SIM) exécute les instructions (INS_RES) extraites du cryptogramme (CRY) et libère, respectivement bloque l'accès à certaines ressources (RES) dudit module de sécurité (SIM) en fonction du résultat de la vérification propre à cette application (APP) effectuée préalablement.
2. Méthode selon la revendication 1 caractérisée en ce que l'équipement est un équipement mobile (CB) de téléphonie mobile.
3. Méthode selon la revendication 1 caractérisée en ce que le réseau (NET) est un réseau mobile du type GSM ou GPRS ou UMTS.
4. Méthode selon la revendication 1 ou 2, caractérisée en ce que le module de sécurité (SIM) est un module d'abonné inséré dans l'équipement mobile (CB) de téléphonie mobile de type carte SIM.
5. Méthode selon la revendication 1 ou 4 caractérisée en ce que l'identification (ID) de l'ensemble équipement mobile (CB) / module d'abonné (SIM) est effectuée à partir de l'identifiant (IMEISV) de l'équipement mobile (CB) et de l'identifiant (IMSI) du module d'abonné (SIM) propre à un abonné au réseau (NET).
6. Méthode selon la revendication 1 caractérisée en ce que les instructions incluses dans le cryptogramme (CRY) reçu par le module de sécurité (SIM) conditionnent l'utilisation des applications (APP) selon des critères préétablis par l'opérateur et/ou le fournisseur d'applications (FA) et/ou l'utilisateur de l'équipement.
7. Méthode selon la revendication 6 caractérisée en ce que les critères définissent des limites d'utilisation d'une application (APP) selon des risques associés au logiciel de ladite application (APP) ou au matériel de l'équipement (CB) que l'opérateur désire prendre en compte.
8. Méthode selon la revendication 1 caractérisée en ce que la vérification de l'application (APP) avec le cryptogramme (CRY) s'effectue lors du premier démarrage ou lors de la première utilisation de ladite application (APP).
9. Méthode selon la revendication 1 caractérisée en ce que la vérification de l'application (APP) avec le cryptogramme (CRY) s'effectue périodiquement à un rythme donné selon des instructions provenant du serveur de contrôle (CSE).
10. Méthode selon la revendication 1 caractérisée en ce que la vérification de l'application (APP) avec le cryptogramme (CRY) s'effectue lors de chaque démarrage de ladite application (APP) sur l'équipement (CB).
11. Méthode selon la revendication 1 caractérisée en ce que le cryptogramme (CRY) est généré à l'aide d'une clé d'encryption asymétrique ou symétrique à partir d'un ensemble de données contenant, entre autres données, l'identifiant (IMEISV) de l'équipement (CB), l'identifiant (IMSI) du module de sécurité (SIM), un identificateur de l'application (APP), l'empreinte (FINI) de l'application (APP) calculée avec une fonction unidirectionnelle de hachage, des identificateurs (RESJD) des ressources du module de sécurité (SIM) et des instructions (INS_RES) de blocage/libération des ressources (RES) du module de sécurité (SIM).
12. Méthode selon la revendication 11 caractérisée en ce que le cryptogramme (CRY) comprend une variable prédictible par le module de sécurité (SIM) évitant le double usage d'un même cryptogramme (CRY), la valeur de ladite variable étant contrôlée par le module de sécurité (SIM) par comparaison avec celle d'une valeur de référence stockée dans ledit module et régulièrement mise à jour.
13. Méthode selon la revendication 1 caractérisée en ce que le module de sécurité (SIM) transmet au serveur de contrôle (CSE), via l'équipement (CB) et le réseau (NET), un message de confirmation (CF) lorsque ledit module de sécurité (SIM) a accepté ou refusé un cryptogramme (CRY) d'une application (APP).
14. Méthode selon la revendication 1 caractérisée en ce que le cryptogramme (CRY) est transmis au module de sécurité (SIM) en même temps que l'application (APP) est chargée dans l'équipement (CB) via l'environnement d'exécution des applications (AEE).
15. Méthode selon la revendication 1 caractérisée en ce que l'application (APP), une fois chargée dans l'équipement (CB) depuis le serveur (CSE) de contrôle via le réseau (NET), sollicite un cryptogramme (CRY) au serveur (CSE) lors de son initialisation et transmet ledit cryptogramme (CRY) au module de sécurité (SIM), le message de confirmation (CF) d'acceptation ou de refus du cryptogramme (CRY) étant transmis par le module de sécurité (SIM) au serveur via l'application (APP).
16. Méthode selon la revendication 1, caractérisée en ce que l'équipement est un décodeur de télévision à péage ou un ordinateur auquel est connecté le module de sécurité.
17. Module de sécurité comprenant des ressources (RES) destinées à être localement accédées par au moins une application (APP) installée dans un équipement (CB) relié à un réseau (NET), ledit équipement (CB) comprenant des moyens de lecture et de transmission de données comprenant au moins l'identifiant (IMEISV) de l'équipement (CB) et l'identifiant (IMSI) du module de sécurité (SIM), ledit module est caractérisé en ce qu'il comprend des moyens de réception, de stockage et d'analyse d'un cryptogramme (CRY) contenant entre autre données une empreinte (FINI) de ladite application (APP) et des instructions (INS_RES), des moyens de vérification de ladite application (APP) et des moyens d'extraction et d'exécution des instructions (INS_RES) contenues dans le cryptogramme (CRY) libérant ou bloquant certaines ressources (RES) selon le résultat de la vérification de l'application (APP).
18. Module de sécurité selon la revendication 17, caractérisé en ce qu'il est du type "module d'abonné" ou "carte SIM" destiné à être relié à un équipement mobile.
PCT/EP2004/053116 2003-11-27 2004-11-26 Méthode d'authentification d'applications Ceased WO2005053263A2 (fr)

Priority Applications (13)

Application Number Priority Date Filing Date Title
CA002545159A CA2545159A1 (fr) 2003-11-27 2004-11-26 Methode d'authentification d'applications
BRPI0415788-5A BRPI0415788A (pt) 2003-11-27 2004-11-26 método para autenticar aplicativos
JP2006540462A JP2007519308A (ja) 2003-11-27 2004-11-26 アプリケーションの認証方法
US10/577,857 US8261365B2 (en) 2003-11-27 2004-11-26 Method for the authentication of applications
AU2004310512A AU2004310512A1 (en) 2003-11-27 2004-11-26 Method for the authentication of applications
HK06112494.0A HK1092971B (en) 2003-11-27 2004-11-26 Method for the authentication of applications
DE602004011559T DE602004011559T2 (de) 2003-11-27 2004-11-26 Verfahren zur authentifikation von anwendungen
EP04804580A EP1687953B1 (fr) 2003-11-27 2004-11-26 Méthode d'authentification d'applications
IL175255A IL175255A0 (en) 2003-11-27 2006-04-27 Method for the authentication of applications
ZA2006/04290A ZA200604290B (en) 2003-11-27 2006-05-26 Method for the authentication of applications
US13/557,266 US8813253B2 (en) 2003-11-27 2012-07-25 Method for the authentication of applications
US14/332,946 US9143888B2 (en) 2003-11-27 2014-07-16 Method for the authentication of applications
US14/825,664 US9531681B2 (en) 2003-11-27 2015-08-13 Method for the authentication of applications

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP03104412.6 2003-11-27
EP03104412A EP1536606A1 (fr) 2003-11-27 2003-11-27 Méthode d'authentification d'applications

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US10/577,857 A-371-Of-International US8261365B2 (en) 2003-11-27 2004-11-26 Method for the authentication of applications
US13/557,266 Continuation US8813253B2 (en) 2003-11-27 2012-07-25 Method for the authentication of applications

Publications (2)

Publication Number Publication Date
WO2005053263A2 true WO2005053263A2 (fr) 2005-06-09
WO2005053263A3 WO2005053263A3 (fr) 2005-10-06

Family

ID=34443058

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2004/053116 Ceased WO2005053263A2 (fr) 2003-11-27 2004-11-26 Méthode d'authentification d'applications

Country Status (16)

Country Link
US (4) US8261365B2 (fr)
EP (2) EP1536606A1 (fr)
JP (1) JP2007519308A (fr)
KR (1) KR20060116822A (fr)
CN (1) CN1886963A (fr)
AT (1) ATE385120T1 (fr)
AU (1) AU2004310512A1 (fr)
BR (1) BRPI0415788A (fr)
CA (1) CA2545159A1 (fr)
DE (1) DE602004011559T2 (fr)
ES (1) ES2299898T3 (fr)
IL (1) IL175255A0 (fr)
RU (1) RU2364049C2 (fr)
TW (1) TW200531493A (fr)
WO (1) WO2005053263A2 (fr)
ZA (1) ZA200604290B (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008046212A1 (fr) * 2006-10-20 2008-04-24 Research In Motion Limited Procédé et appareil de commande d'utilisation d'applications sur des dispositifs portatifs basés sur un service réseau
CN103546887A (zh) * 2013-10-29 2014-01-29 小米科技有限责任公司 一种应用软件传输方法、装置、终端及服务器

Families Citing this family (83)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB0319918D0 (en) * 2003-08-23 2003-09-24 Ibm Method system and device for mobile subscription content access
US8401002B2 (en) 2005-06-22 2013-03-19 Research In Motion Limited Exchange and use of globally unique device identifiers for circuit-switched and packet switched integration
US8799757B2 (en) 2005-07-01 2014-08-05 Microsoft Corporation Synchronization aspects of interactive multimedia presentation management
US8656268B2 (en) 2005-07-01 2014-02-18 Microsoft Corporation Queueing events in an interactive media environment
US8305398B2 (en) * 2005-07-01 2012-11-06 Microsoft Corporation Rendering and compositing multiple applications in an interactive media environment
US7941522B2 (en) * 2005-07-01 2011-05-10 Microsoft Corporation Application security in an interactive media environment
US8108787B2 (en) * 2005-07-01 2012-01-31 Microsoft Corporation Distributing input events to multiple applications in an interactive media environment
US8020084B2 (en) * 2005-07-01 2011-09-13 Microsoft Corporation Synchronization aspects of interactive multimedia presentation management
US7721308B2 (en) * 2005-07-01 2010-05-18 Microsoft Corproation Synchronization aspects of interactive multimedia presentation management
WO2007032996A2 (fr) 2005-09-07 2007-03-22 Ace*Comm Corporation Solution de communications mobiles configurable par le consommateur
ES2328708T3 (es) * 2005-10-04 2009-11-17 Swisscom Ag Procedimiento para adaptar los reglajes de seguridad de una estacion de comunicaciones y estacion de comunicaciones.
US8522025B2 (en) * 2006-03-28 2013-08-27 Nokia Corporation Authenticating an application
US20080065746A1 (en) * 2006-09-07 2008-03-13 Ace*Comm Corporation Consumer configurable mobile communication web filtering solution
EP1916598A1 (fr) * 2006-10-23 2008-04-30 Nagravision S.A. Méthode de chargement et de gestion d'une application dans un équipement mobile
JP4828441B2 (ja) * 2007-01-22 2011-11-30 株式会社エクセディ 一方向クラッチの支持構造
DE102007022941A1 (de) 2007-05-16 2008-11-20 Giesecke & Devrient Gmbh Verfahren zum Ausführen einer Software auf einem Endgerät
EP2073510A1 (fr) * 2007-12-21 2009-06-24 Gemplus Procédé d'enrichissement d'un annuaire électronique provoqué par un changement dans le téléphone associé, et dispositif lié
EP2128830A1 (fr) * 2008-05-30 2009-12-02 Gemplus Procédé et dispositif électronique pour transférer des données d'application depuis un dispositif électronique source vers un dispositif électronique de destination
JP5397380B2 (ja) * 2008-09-30 2014-01-22 日本電気株式会社 アクセス制御システム、アクセス制御方法および通信端末
US8266684B2 (en) 2008-09-30 2012-09-11 General Instrument Corporation Tokenized resource access
US20100162240A1 (en) * 2008-12-23 2010-06-24 Samsung Electronics Co., Ltd. Consistent security enforcement for safer computing systems
KR101224717B1 (ko) * 2008-12-26 2013-01-21 에스케이플래닛 주식회사 소프트웨어 라이센스 보호 방법과 그를 위한 시스템, 서버,단말기 및 컴퓨터로 읽을 수 있는 기록매체
US8713705B2 (en) 2009-08-03 2014-04-29 Eisst Ltd. Application authentication system and method
DE102009037223A1 (de) * 2009-08-12 2011-02-17 Deutsche Telekom Ag Verfahren und Vorrichtung zum Ausführen von Anwendungen in einer sicheren, autonomen Umgebung
US8255991B1 (en) * 2009-08-17 2012-08-28 Google Inc. Computer application pre-permissioning
CN102103651B (zh) * 2009-12-21 2012-11-14 中国移动通信集团公司 一种一卡通系统的实现方法和系统以及一种智能卡
CA2787072A1 (fr) * 2010-01-19 2011-07-28 Visa International Service Association Mecanisme de verification
CN102375953B (zh) * 2010-08-10 2015-03-18 上海贝尔股份有限公司 软件认证方法和软件认证设备
RU2470358C2 (ru) * 2010-09-30 2012-12-20 Закрытое акционерное общество "Нордавинд" Способ защиты программного обеспечения от несанкционированной активации и копирования
US20120204254A1 (en) * 2011-02-04 2012-08-09 Motorola Mobility, Inc. Method and apparatus for managing security state transitions
EP2506175B1 (fr) * 2011-03-30 2019-01-30 Irdeto B.V. Activation d'une application logicielle à exécuter sur une station mobile
KR101266037B1 (ko) * 2011-06-08 2013-05-21 충남대학교산학협력단 휴대단말에서 악성행위 처리 방법 및 장치
RU2464628C1 (ru) * 2011-06-24 2012-10-20 Федеральное государственное военное образовательное учреждение высшего профессионального образования "Военная академия связи имени маршала Советского Союза С.М. Буденного" Министерства обороны Российской Федерации Способ контроля функционирования программного обеспечения
DE102011085050A1 (de) * 2011-10-21 2013-04-25 Vodafone Holding Gmbh Verwaltung von Lizenzinformationen für ein Kommunikationsendgerät
CN102404706B (zh) * 2011-11-24 2014-08-13 中兴通讯股份有限公司 一种管理资费安全的方法及移动终端
FR2985343B1 (fr) * 2012-01-03 2014-01-03 Inside Secure Procede d'execution d'une application dans un dispositif nfc
KR20130104515A (ko) * 2012-03-14 2013-09-25 에스케이플래닛 주식회사 서비스 사용자 인증 시스템 및 방법
JP5620937B2 (ja) * 2012-03-29 2014-11-05 富士フイルム株式会社 制御システムおよび被制御装置ならびにそれらの動作制御方法
US9027088B2 (en) * 2012-06-14 2015-05-05 Ericsson Modems Sa Systems and methods for protection of a SIP back-to-back user agent on modems
US20140006781A1 (en) * 2012-06-23 2014-01-02 Pomian & Corella, Llc Encapsulating the complexity of cryptographic authentication in black-boxes
US9141783B2 (en) 2012-06-26 2015-09-22 Ologn Technologies Ag Systems, methods and apparatuses for the application-specific identification of devices
EP2723111B1 (fr) * 2012-10-16 2017-12-06 Deutsche Telekom AG Authentification multifactorielle pour terminaux mobiles
US9143383B2 (en) * 2012-11-01 2015-09-22 Miiicasa Taiwan Inc. Method and system for managing device identification
RU2546585C2 (ru) 2013-08-07 2015-04-10 Закрытое акционерное общество "Лаборатория Касперского" Система и способ предоставления прав доступа приложениям к файлам компьютера
US10129242B2 (en) 2013-09-16 2018-11-13 Airwatch Llc Multi-persona devices and management
CN105765951B (zh) * 2013-10-10 2019-09-13 谷歌有限责任公司 用于管理通信的系统、方法和计算机程序产品
US20150106871A1 (en) * 2013-10-15 2015-04-16 Electronics And Telecommunications Research Institute System and method for controlling access to security engine of mobile terminal
KR102201218B1 (ko) * 2013-10-15 2021-01-12 한국전자통신연구원 모바일 단말의 보안 엔진의 접근 제어 시스템 및 방법
US9270469B2 (en) * 2014-02-20 2016-02-23 Xilinx, Inc. Authentication using public keys and session keys
CN105228111A (zh) * 2014-06-13 2016-01-06 中兴通讯股份有限公司 资源订阅处理方法及装置
BR112017002747A2 (pt) 2014-08-29 2018-01-30 Visa Int Service Ass método implementado por computador, e, sistema de computador.
CN104268485B (zh) * 2014-09-29 2017-11-17 西安酷派软件科技有限公司 Se中访问控制规则的访问方法和访问装置及终端
CN104537299B (zh) * 2014-12-10 2017-10-24 深圳先进技术研究院 一种电子设备检测方法及其系统、相关设备
US10205710B2 (en) * 2015-01-08 2019-02-12 Intertrust Technologies Corporation Cryptographic systems and methods
CN107210914B (zh) 2015-01-27 2020-11-03 维萨国际服务协会 用于安全凭证供应的方法
GB201506045D0 (en) * 2015-04-09 2015-05-27 Vodafone Ip Licensing Ltd SIM security
CN104935577B (zh) * 2015-04-30 2019-02-15 努比亚技术有限公司 鉴权认证方法、智能卡云端、app云端、装置及系统
US10382426B2 (en) * 2015-07-02 2019-08-13 Adobe Inc. Authentication context transfer for accessing computing resources via single sign-on with single use access tokens
US10218698B2 (en) * 2015-10-29 2019-02-26 Verizon Patent And Licensing Inc. Using a mobile device number (MDN) service in multifactor authentication
ES2877142T3 (es) 2015-12-01 2021-11-16 Ericsson Telefon Ab L M Anuncio de planificación de conocimiento de aplicación
US11831654B2 (en) * 2015-12-22 2023-11-28 Mcafee, Llc Secure over-the-air updates
WO2017115114A1 (fr) * 2015-12-31 2017-07-06 Pismo Labs Technology Ltd Procédés et systèmes permettant de transférer des informations de carte sim
US20170230184A1 (en) * 2016-02-08 2017-08-10 Ebay Inc. Granting access through app instance-specific cryptography
US10225241B2 (en) * 2016-02-12 2019-03-05 Jpu.Io Ltd Mobile security offloader
CN106971103B (zh) * 2016-02-25 2018-12-14 三星半导体(中国)研究开发有限公司 在电子终端中管理应用程序权限的方法
EP3247136A1 (fr) * 2016-05-16 2017-11-22 Gemalto Sa Procédé d'approvisionnement d'une mini-application de justificatifs d'identité d'une application de terminal fournie par un serveur d'application et plate-forme ota correspondante
US10621333B2 (en) * 2016-08-08 2020-04-14 International Business Machines Corporation Install-time security analysis of mobile applications
CN106446719B (zh) * 2016-09-29 2020-09-11 宇龙计算机通信科技(深圳)有限公司 一种防止eSIM文件被篡改的方法及移动终端
US9680653B1 (en) * 2016-10-13 2017-06-13 International Business Machines Corporation Cipher message with authentication instruction
CN106572523B (zh) * 2016-10-31 2022-04-19 宇龙计算机通信科技(深圳)有限公司 应用程序的运行控制方法、装置和终端
DE102017204218A1 (de) 2017-03-14 2018-09-20 Robert Bosch Gmbh Verfahren und Vorrichtung zum Absichern eines Gerätes
US10230527B2 (en) * 2017-04-19 2019-03-12 Continental Automotive Systems, Inc. Method and apparatus to quickly authenticate program using a security element
US10657239B2 (en) * 2017-05-25 2020-05-19 Oracle International Corporation Limiting access to application features in cloud applications
CN109428723A (zh) * 2017-09-05 2019-03-05 中国电信股份有限公司 验证方法、用户卡和验证系统
CN107919960A (zh) * 2017-12-04 2018-04-17 北京深思数盾科技股份有限公司 一种应用程序的认证方法和系统
CN108460273B (zh) * 2017-12-27 2022-10-14 中国银联股份有限公司 一种终端的应用管理方法、应用服务器及终端
DE102018000471A1 (de) * 2018-01-22 2019-07-25 Giesecke+Devrient Mobile Security Gmbh Blockchain-basiertes Identitätssystem
US11102180B2 (en) * 2018-01-31 2021-08-24 The Toronto-Dominion Bank Real-time authentication and authorization based on dynamically generated cryptographic data
US11140158B1 (en) * 2018-08-07 2021-10-05 United Services Automobile Association (Usaa) Authentication for application downloads
CN111132163B (zh) * 2019-12-28 2022-11-04 飞天诚信科技股份有限公司 一种无线安全设备与应用程序的认证方法和系统
CN115174577B (zh) * 2022-07-11 2023-10-27 中汽创智科技有限公司 一种资源访问方法、装置、设备及存储介质
US12488103B2 (en) * 2023-08-30 2025-12-02 Gen Digital, Inc. Protecting against malicious application encounters on mobile devices
US12613991B2 (en) * 2023-12-07 2026-04-28 Cvs Pharmacy, Inc. Credential to guarantee identity

Family Cites Families (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5600708A (en) * 1995-08-04 1997-02-04 Nokia Mobile Phones Limited Over the air locking of user identity modules for mobile telephones
JP3660101B2 (ja) * 1996-11-14 2005-06-15 松下電器産業株式会社 パーソナル電子決済システム
US6381741B1 (en) * 1998-05-18 2002-04-30 Liberate Technologies Secure data downloading, recovery and upgrading
US20020062451A1 (en) * 1998-09-01 2002-05-23 Scheidt Edward M. System and method of providing communication security
US6609199B1 (en) * 1998-10-26 2003-08-19 Microsoft Corporation Method and apparatus for authenticating an open system application to a portable IC device
US7139915B2 (en) * 1998-10-26 2006-11-21 Microsoft Corporation Method and apparatus for authenticating an open system application to a portable IC device
FR2794595B1 (fr) * 1999-06-03 2002-03-15 Gemplus Card Int Pre-controle d'un programme dans une carte a puce additionnelle d'un terminal
US6513121B1 (en) * 1999-07-20 2003-01-28 Avaya Technology Corp. Securing feature activation in a telecommunication system
US6775536B1 (en) * 1999-11-03 2004-08-10 Motorola, Inc Method for validating an application for use in a mobile communication device
US6832230B1 (en) * 1999-12-22 2004-12-14 Nokia Corporation Apparatus and associated method for downloading an application with a variable lifetime to a mobile terminal
FI20000760A0 (fi) * 2000-03-31 2000-03-31 Nokia Corp Autentikointi pakettidataverkossa
JP4274675B2 (ja) * 2000-04-28 2009-06-10 株式会社エヌ・ティ・ティ・データ カードシステム、ｉｃカード及び記録媒体
US6931550B2 (en) * 2000-06-09 2005-08-16 Aramira Corporation Mobile application security system and method
JP2002152196A (ja) 2000-09-01 2002-05-24 Nec Corp 秘密鍵なしプログラム認証方法，プログラムｉｄ通信処理制御方法、プログラムｉｄ通信範囲制御方法および公開鍵毎通信路提供方法
US7143441B2 (en) * 2001-05-08 2006-11-28 Aramira Corporation Wireless device mobile application security system
US6714778B2 (en) * 2001-05-15 2004-03-30 Nokia Corporation Context sensitive web services
US7065783B2 (en) * 2001-07-06 2006-06-20 Aramira Corporation Mobile application access control list security system
FR2831362B1 (fr) * 2001-10-19 2004-02-27 Babel Software Procede de transaction securisee entre un telephone mobile equipe d'un module d'identification d'abonne (carte sim) et un serveur d'application
RU2190884C1 (ru) * 2001-11-16 2002-10-10 Закрытое акционерное общество "Аргус Просистем" Способ записи данных на носитель информации с возможностью идентификации
JP4145118B2 (ja) * 2001-11-26 2008-09-03 松下電器産業株式会社 アプリケーション認証システム
EP1338938A1 (fr) * 2002-02-22 2003-08-27 SCHLUMBERGER Systèmes Protection contre l'exécution non-autorisée d'un logiciel dans une carte à puce
EP1492040A4 (fr) * 2002-03-29 2006-05-31 Matsushita Electric Industrial Co Ltd Appareil de reproduction de contenu et procede de commande de reproduction de contenu
GB2387505B (en) * 2002-04-12 2005-11-23 Vodafone Plc Communication systems
JP2003317070A (ja) * 2002-04-23 2003-11-07 Ntt Docomo Inc Ｉｃカード、携帯端末、及びアクセス制御方法
SE0202451D0 (sv) * 2002-08-15 2002-08-15 Ericsson Telefon Ab L M Flexible Sim-Based DRM agent and architecture
AU2003265034A1 (en) * 2002-10-07 2004-04-23 Telefonaktiebolaget Lm Ericsson (Publ) Security and privacy enhancements for security devices
US7440571B2 (en) * 2002-12-03 2008-10-21 Nagravision S.A. Method for securing software updates
JP4067985B2 (ja) * 2003-02-28 2008-03-26 松下電器産業株式会社 アプリケーション認証システムと装置
SE0300670L (sv) * 2003-03-10 2004-08-17 Smarttrust Ab Förfarande för säker nedladdning av applikationer
US20040199787A1 (en) * 2003-04-02 2004-10-07 Sun Microsystems, Inc., A Delaware Corporation Card device resource access control
US7269732B2 (en) * 2003-06-05 2007-09-11 Sap Aktiengesellschaft Securing access to an application service based on a proximity token
EP1492061A1 (fr) * 2003-06-25 2004-12-29 Nagracard S.A. Méthode d'allocation de ressources sécurisées dans un module de sécurité
EP1654712A1 (fr) * 2003-07-02 2006-05-10 Mobipay International, S.A. Systeme de transactions et de paiements par telephone mobile numerique
FI20031482A7 (fi) * 2003-10-10 2005-04-11 Open Bit Oy Ltd Maksutapahtumatietojen prosessointi
EP1530392A1 (fr) * 2003-11-04 2005-05-11 Nagracard S.A. Méthode de gestion de la sécurité d'applications avec un module de sécurité
US20050097053A1 (en) * 2003-11-04 2005-05-05 Nokia Corporation System and associated terminal, method and computer program product for protecting content
JP2008002152A (ja) * 2006-06-22 2008-01-10 Shigeru Yaguchi 先組み鉄筋ユニット及び該ユニット形成用の連結金具

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008046212A1 (fr) * 2006-10-20 2008-04-24 Research In Motion Limited Procédé et appareil de commande d'utilisation d'applications sur des dispositifs portatifs basés sur un service réseau
CN103546887A (zh) * 2013-10-29 2014-01-29 小米科技有限责任公司 一种应用软件传输方法、装置、终端及服务器

Also Published As

Publication number Publication date
US9531681B2 (en) 2016-12-27
WO2005053263A3 (fr) 2005-10-06
TW200531493A (en) 2005-09-16
RU2006114721A (ru) 2008-01-10
ES2299898T3 (es) 2008-06-01
ZA200604290B (en) 2008-01-08
DE602004011559T2 (de) 2009-01-29
DE602004011559D1 (de) 2008-03-13
EP1687953A2 (fr) 2006-08-09
CA2545159A1 (fr) 2005-06-09
JP2007519308A (ja) 2007-07-12
US8813253B2 (en) 2014-08-19
ATE385120T1 (de) 2008-02-15
EP1687953B1 (fr) 2008-01-23
RU2364049C2 (ru) 2009-08-10
US20070198834A1 (en) 2007-08-23
US8261365B2 (en) 2012-09-04
AU2004310512A1 (en) 2005-06-09
US20140321646A1 (en) 2014-10-30
US9143888B2 (en) 2015-09-22
IL175255A0 (en) 2006-09-05
HK1092971A1 (en) 2007-02-16
US20150350169A1 (en) 2015-12-03
EP1536606A1 (fr) 2005-06-01
US20120314859A1 (en) 2012-12-13
KR20060116822A (ko) 2006-11-15
CN1886963A (zh) 2006-12-27
BRPI0415788A (pt) 2006-12-26

Similar Documents

Publication Publication Date Title
EP1687953B1 (fr) Méthode d'authentification d'applications
EP1683388B1 (fr) Methode de gestion de la sécurité d'applications avec un module de sécurité
EP1427231B1 (fr) Procédé d'établissement et de gestion d'un modèle de confiance entre une carte à puce et un terminal radio
EP2884716B1 (fr) Mécanisme d'authentificaiton par jeton
CN102413224B (zh) 绑定、运行安全数码卡的方法、系统及设备
EP2741466B1 (fr) Procédé et système de gestion d'un élément sécurisé intégré ese
EP2912594B1 (fr) Procédé de fourniture d'un service sécurisé
EP2084604A2 (fr) Méthode de chargement et de gestion d'une application dans un équipement mobile
CA2637632A1 (fr) Systeme de securite de reseau et procede associe
TWI469655B (zh) 電子存取用戶端之大規模散佈之方法及裝置
EP1393527A1 (fr) Procede d'authentification entre un objet de telecommunication portable et une borne d'acces public
EP2491735A1 (fr) Dispositif et procédé de gestion des droits d'accès à un réseau sans fil
WO2006056669A1 (fr) Procede de securisation d'un terminal de telecommunication connecte a un module d'identification d'un utilisateur du terminal
CN112805702A (zh) 仿冒app识别方法及装置
EP1393272A1 (fr) Proc d et dispositif de certification d'une transaction
US20060048235A1 (en) Method and system for managing authentication and payment for use of broadcast material
EP2911365B1 (fr) Procédé et système de sécurisation de transactions offertes par une pluralité de services entre un appareil mobile d'un utilisateur et un point d'acceptation
WO2011023554A1 (fr) Dispositif électronique nomade configuré pour établir une communication sans fil sécurisé
CN117897700A (zh) 用于控制对软件资产的访问的方法和装置
WO2006051197A1 (fr) Procédé d'autorisation d'accès d'un terminal client d'un réseau nominal à un réseau de communication différent du réseau nominal, système, serveur d'authentification et programme informatique correspondants
HK1092971B (en) Method for the authentication of applications
MXPA06005437A (es) Metodo de autentificacion de aplicaciones

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200480034606.1

Country of ref document: CN

AK Designated states

Kind code of ref document: A2

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

AL Designated countries for regional patents

Kind code of ref document: A2

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 LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 482/MUMNP/2006

Country of ref document: IN

WWE Wipo information: entry into national phase

Ref document number: 175255

Country of ref document: IL

WWE Wipo information: entry into national phase

Ref document number: 2545159

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: PA/a/2006/005437

Country of ref document: MX

WWE Wipo information: entry into national phase

Ref document number: 1020067009600

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 2006540462

Country of ref document: JP

Ref document number: 2004310512

Country of ref document: AU

WWE Wipo information: entry into national phase

Ref document number: 2006/04290

Country of ref document: ZA

Ref document number: 200604290

Country of ref document: ZA

WWE Wipo information: entry into national phase

Ref document number: 2004804580

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Ref document number: DE

ENP Entry into the national phase

Ref document number: 2004310512

Country of ref document: AU

Date of ref document: 20041126

Kind code of ref document: A

WWP Wipo information: published in national office

Ref document number: 2004310512

Country of ref document: AU

WWE Wipo information: entry into national phase

Ref document number: 2006114721

Country of ref document: RU

WWP Wipo information: published in national office

Ref document number: 2004804580

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 1020067009600

Country of ref document: KR

ENP Entry into the national phase

Ref document number: PI0415788

Country of ref document: BR

WWE Wipo information: entry into national phase

Ref document number: 10577857

Country of ref document: US

Ref document number: 2007198834

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 10577857

Country of ref document: US

WWG Wipo information: grant in national office

Ref document number: 2004804580

Country of ref document: EP