HK1092971B - Method for the authentication of applications - Google Patents

Description

The present invention relates to the field of mobile networks, also known as cellular networks, and in particular to the application security management implemented with a security module associated with a mobile mobile telephone equipment.

Err1:Expecting ',' delimiter: line 1 column 128 (char 127)GPRS (General Packet Radio System) or UMTS (Universal Mobile Telecommunications System).In addition, a mobile device is characterized by a Software Version Number (SVN) software version indicating the updated status of the basic software installed on the mobile device.Combining the type and serial number identification of the mobile device with the software version (SVN) gives a new identification, called IMEISV (International Mobile Equipment Identifier and Software Number Version).The same identification concept also applies to WLAN (Wireless LAN) or two-way cable TV.The physical identifier may be a Media Access Control (MAC) address that corresponds to the unique IP address of a user's hardware configuration on an Internet Protocol (IP) network and may be transmitted over a higher layer of software protocols.

Err1:Expecting ',' delimiter: line 1 column 60 (char 59)

When a mobile device is put into service, particularly when connected to an operator's network, information including identification data is exchanged between the mobile device and the operator's control centre which authorises or does not authorise its use. Currently, a mobile device offers the user, in addition to its usual function of establishing telephone conversations through access to a mobile network, the use of many other additional value-added services such as consulting various information, remote banking, e-commerce, accessing multimedia content, etc. These services require an increasingly high level of security to protect users from fraud caused by third parties seeking to exploit security flaws that may appear on mobile devices.

Verification is therefore necessary at least at two levels: first, at the level of the mobile equipment itself and, second, at the level of the software applications that enable 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.

The subscriber module may contain confidential information such as a bank account number or password. An application running on the mobile device will be responsible for using this personal data in order to provide the expected service. However, an application could misuse this personal data for purposes other than dialogue with the relevant application provider. This may result in significant harm to the owner of the subscriber module.

These applications run in the mobile device using resources available in the subscriber module. Resources are various functions and data necessary for the proper functioning of an application. Some of these resources may be common to several applications, including security-related functions. The subscriber module may block or alter the operation of certain applications for which the security conditions established by the operator and/or application providers in the mobile device in question are not met or the rights of the user of the mobile device are insufficient.

FR2831362 describes a secure transaction method between a mobile phone equipped with a SIM card and an application server.

The process involves first establishing a trust between the server and the SIM card by securely exchanging public keys, then purchasing an application by transmitting a request file from the mobile device to the server. The latter partially or fully encrypts the application and transmits to the mobile device a cryptogram formed by the encryption key and a command, all encrypted with a known public key of the SIM card. Upon receipt by the mobile device, this cryptogram is decrypted and the key stored in the SIM card.

The process of using the application in a mobile device is based on the principle that the rights to use the application in the mobile device are protected by the trust relationship established between the device and the server prior to the transaction. The role of the server is focused on the management of the rights or DRM (Digital Rights Management) of users of an application in a mobile device.

The purpose of the present invention is to provide a method for authenticating applications in a mobile device both when downloaded and when run, to reduce the risk of misuse of a subscriber module by applications that do not meet certain security criteria or by mobile devices that do not meet certain pre-established security criteria.

Another purpose is to protect the user of the mobile equipment and the relevant application providers against abuse resulting from the use of unauthorised applications.

Those purposes shall be achieved by a method of authentication of at least one application running on a networked equipment connected to a control server, that equipment being locally connected to a security module, that application being loaded and/or executed by means of an application execution environment on the equipment and using resources stored in the security module, including the following preliminary steps: receipt of data including at least the equipment identifier and the security module identifier via the network by the control server,analysis and verification by the control server of such data,generation of a cryptogram comprising an application fingerprint, data identifying the equipment and the security module and instructions for that module,transmission of that cryptogram via the network and the equipment to the security module,verification of the application by comparing the fingerprint extracted from the received cryptogram with a fingerprint determined by the security module, that method is characterised by the security module executing the instructions extracted from the cryptogram when the application is initialized and/or activated and either releasing or blocking access to certain resources of that security module, depending on the result of the application-specific verification performed beforehand.

The security module resources are blocked or released in a targeted manner, this with the aim of making certain applications usable or not. Applications from the mobile device are not blocked or released directly: applications are acted on indirectly, i.e. the blocking or release effect will only be manifested when the mobile device tries to run these applications.

This method is preferably applied to the mobile network. Therefore, the equipment is, for example, a mobile phone equipment and the security module is a subscriber module or SIM card. This set connects to a mobile network of the type GSM (Global System for Mobile communications), GPRS (General Packet Radio Service), UMTS (Universal Mobile Telecommunications System) or other, managed by an operator control server. Software applications are installed in the mobile equipment and configured in such a way as to use necessary resources (data or functions) present in the subscriber module. They can therefore not be used in their entirety only if the load conditions are met according to criteria set by the operator and/or application provider. This verification of the security criteria serves to ensure the proper functioning of the application.

The data from these resources may include information such as account number, programs (in the form of code that can be installed in the mobile equipment), encryption/decryption keys, access rights to content, etc.

The functions of these resources may include cryptographic algorithms, verification processes, digital signature generation processes, encryption processes, authentication processes, data validation processes, access control processes, data backup processes, payment processes and so on.

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 a mobile device connected to a network.

Unlike the process described in FR2831362, partial or complete encryption of the application before downloading to the mobile device is not necessary. According to the method of the invention, the link between the server and the security module (or subscriber module) serves to optimally control its resources and decide whether or not to use them in relation to applications running on the mobile device.

Err1:Expecting ',' delimiter: line 1 column 136 (char 135)

In the first embodiment, the cryptogram is transmitted to the subscriber module during application loading. In the second embodiment, the application will fetch the cryptogram from the control server when first used.

The method of authentication of the invention also applies when an application is run by the mobile device, which makes it possible to ensure, by means of the subscriber module, that the application is authorized to access certain resources (data or functions) contained in the said subscriber module.

For example, the insertion of a user's subscriber module into another mobile device will influence the operation of certain applications without preventing the establishment of conventional telephone communications. e barrier acts as a sort of filter to eliminate unauthorised mobile devices or applications from sources not authorised by the operator or a partner application provider.

A third party modification of the application is also detected by the subscriber module which will refuse to execute certain received orders resulting in blocking or limitations of the application execution.

The control server therefore plays a key role in managing the trust or security elements linked to the entire mobile equipment/subscriber module.

The server receiving the identity information of a mobile device and its subscriber module, including IMEISV and IMSI identifiers, decides, according to certain criteria, whether a new instruction should be sent to the subscriber module to redefine a new protection profile defining the resources of the subscriber module that can be used by applications running on the mobile device. The criteria may refer, for example, to the update of the software version installed on the mobile device, the download of new applications on the mobile device, the period of updating of the protection profile, the number of network connections, the technology used for network access, the network accuracy of the user or the network access. They may also take into account the different risks associated with the hardware/software provided and the user/telephone network access.

The cryptogram verification may be performed at the first start or at the first use of an application or at each start of an application.

In one variant, it can be run periodically at a given rate according to instructions from the control server.

When an application is loaded into a mobile device, the encrypted encryption that accompanies the application usually includes an application fingerprint, i.e. a block of data calculated from the application code using a one-way mathematical hash function.

When the subscriber module checks the validity of the cryptogram, it also indirectly identifies the mobile device and makes sure that the data actually comes from the control server. In other words, by this cryptogram, the control server implicitly gives assurance to the subscriber module that the type and version of the software of the mobile device have been taken into account, that the application load has been checked and that the application is authentic. According to instructions received in advance, the subscriber module decides whether to allow or refuse requests or orders from the application.

Err1:Expecting ',' delimiter: line 1 column 429 (char 428)

The invention also relates to a security module comprising resources intended to be locally accessed by at least one application installed in a networked equipment, such equipment comprising means of reading and transmitting data comprising at least the equipment identifier and the security module identifier, such module is characterized by the fact that it includes means of receiving, storing and analyzing a cryptogram containing, among other data, an imprint of the said application and instructions, means of verifying said application, and means of extracting and executing instructions contained in the cryptogram, freeing or blocking certain resources depending on the outcome of the verification of the application.

This security module is used, for example, as a subscriber module or SIM card connected to a mobile device.

The invention will be better understood by the following detailed description, which refers to the figures given in the annex as a non-limiting example, namely: Figure 1a shows a block diagram showing the process of installing an application in a first embodiment where the cryptogram is delivered via the application runtime environment.Figure 1b shows the process of verifying the cryptogram in the mode of Figure 1a.Figure 1c shows the process of running the application using subscriber module resources in the mode of Figure 1a.Figure 2a shows a block diagram showing the process of installing an application in a second embodiment where the application alone is downloaded.Figure 2b illustrates the verification process where the application requests a cryptogram from the control server in the mode of Figure 2a.Figure 2c illustrates the process of running the application using subscriber module resources in the mode of Figure 2a.Figure 3a illustrates a block diagram showing the process of installing an application in a third mode where the application alone is downloaded. - What? Figure 3b illustrates the verification process where the application requests a cryptogram and application fingerprint from the control server in the manner shown in Figure 3a. - What? Figure 3c illustrates the process of running the application using the subscriber module resources in the mode shown in Figure 3a.- What? Figure 4 illustrates the structure of an example cryptogram.

The block diagrams in Figures 1a, 1b, 1c, 2a, 2b, 2c, 3a, 3b, 3c show a mobile equipment (CB) package, subscriber module (SIM) containing resources (RES) connected via a mobile network (NET) to a control server (CSE) administered by an operator.

Mobile equipment (CB) includes one or more software applications (APPs) running in a runtime environment (REU). These applications (APPs) either come from the application provider (AP) associated with the operator's control server (CSE) or they may be originally programmed by the mobile equipment manufacturer (CB). In the latter case, it is sometimes necessary to download updates which are also verified by the subscriber module (SIM).

In the first embodiment illustrated in Figures 1a, 1b, 1c, the cryptogram (CRY) of an application (APP) is delivered to the subscriber module (SIM) via the application execution environment (AEE) during the application installation process (APP).

Figure 1a illustrates the installation process where the mobile device (CB) first transmits subscriber module identification (SIM) data which is verified by the control server (CSE). This identification (ID) is performed from the subscriber module identifier (IMSI) and the unique mobile device identifier (IMEISV) of the 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 (EE) for verification as shown in Figure 1b.

It should be noted that the supplier (FA) is considered trustworthy by the operator, i.e. the applications (APP) are approved and operate without causing any harm to the user and/or operator.

The method according to the invention applies to several forms of applications (APPs) running in different types of runtime environments (AEEs). For example, many mobile phones have features derived from Java applications that are run by a Java virtual machine (VM) serving as a processor and environment. The following description is based on the example of Java applications. Of course, other environments or operating systems such as Symbian OS, Windows, Palm OS, Linux, etc. can be used as application support.

When running, see Figure 1c, a Java application requests the subscriber module (SIM) and informs the execution environment (AEE) by sending it requests or commands (CMD). The execution environment (AEE) calculates the application's fingerprint (FIN2) and sends it to the subscriber module (SIM). The cryptogram (CRY) that has been generated by the control server (CSE) and then loaded into the mobile device (CB) with the application (APP) (or separately) is stored in the subscriber module (SIM). The latter first checks that it can actually have the data necessary to decide whether to respond to the application's requests or use the commands (APP) or not. In these cases, the application (APP) allows the user to control the functions or functions (APP) loaded from the application (APP).

If these rights are present, the subscriber module (SIM) verifies the print (FIN1) from the stored cryptogram (CRY) by comparing it with the print (FIN2) associated with the application (APP) and provided by the application environment (AEE). This cryptogram (CRY) may be in the form of a block encrypted by a private key of the RSA type (Rivest, Shamir, Adelman). This block represented in Figure 4 contains, among other data, for example, the IMSI ID_SIM of the subscriber module (SIM) block, the IMEIS ID_CBID of the external equipment (CBID), a public key ID (AP_CID_SEP), while the application ID_CID_SIM would serve as the key for controlling the private resources of the SIM (SIM_RESP), and the user ID_RESP (SIM_RESP) would be used for the control of the private resources of the application (CBID_SEP), while the application ID_CID would be used for the control of the user ID_RESP (SIM_RESP), and the user ID_RESP (SIM_RESP) of the mobile application (SIM_RESP) would be used for the control of the resources of the application (SIM_RESP) and the user (SIM_RESP).

Of course, other asymmetric key algorithms such as DSA (Digital Signature Algorithm), and ECC (Elliptic Curve Cryptography) can be alternatives to RSA.

The use of symmetric key algorithms may be preferred for reasons of simplicity, speed of verification or lower manufacturing and implementation costs. In this case, the key would be known from the server (CSE) and subscriber module (SIM), for example an IDEA (International Data Encryption Algorithm) could be used to sign the block (IMSI, IMEISV, application identifier, application footprint, resource identifiers, SIM resource lock/release instructions).

In these two asymmetric and symmetric key variants, the subscriber module (SIM) checks the concordance of the different fields appearing in the cryptogram (CRY), in particular it controls the application identifiers (ID_APP) and application fingerprints (FIN1) that are authorized or not to use its resources (RES) (data or functions).

In one variant, the cryptogram (CRY) may include a counter to prevent duplication of the same cryptogram addressed to the subscriber module (SIM) (replay attack). Two applications of the same type may carry the same identifier and have the same fingerprint (FIN1).

A variant of the meter is to use a random number generated by the subscriber module (SIM). This is transmitted with the data sent to the control server (CSE). The latter returns this allele 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 meter or an alley.

In another variant 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, SIM resource lock/release instructions). 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, which is present in both the control server (CSE) and the subscriber module (SIM), can be loaded when the subscriber module (SIM) is customized or when certain resources (RES) are installed in the subscriber module (SIM).

The cryptogram (CRY) thus allows the subscriber module (SIM) to know which resource (s) (RES) can be released or blocked in the subscriber module (SIM) for the corresponding mobile equipment (CB).

The two fingerprints used (FIN1 and FIN2 respectively) are crucial because they constitute a means of cryptographic control of the application (APP) by the mobile device (CB) and by the subscriber module (SIM). Such control is necessary to prevent a third-party application from authenticating with a given cryptogram (CRY). Indeed, if cryptogram A authenticates application A to subscriber module A in a mobile device A, it is necessary to prevent another application B from authenticating improperly with the same cryptogram A to subscriber module A in mobile device A.

In addition, the application (APP) can be customized for a given load in such a way that the application (FIN1) printed in the cryptogram (CRY) and the application (FIN2) printed by the runtime module (AE) remain identical but depend on the authenticity of the AAE. Such an authentication is necessary to prevent the AAE from being compromised in the same way as the AAE. In order to prevent authentication with the AAE, the AAE must be connected to another BAE. In order to prevent authentication with the AAE, the AAE must be connected to the AAE in the same way as the AAE.

In another variant, each application (Java type) is accompanied by two cryptograms: a Java cryptogram for the virtual machine (VM) and a cryptogram (CRY) for the subscriber module (SIM). These two cryptograms include, among other things, the same application fingerprint (here called FIN2) which is that of the Java application code. Thus, when the subscriber module (SIM) needs to verify the cryptogram (CRY) of an application, it expects the virtual machine (VM) the fingerprint (FIN2) associated with the application (APP) in question that it must have calculated beforehand.The mobile device (CB) cannot cheat until it knows the expected fingerprint from the subscriber module (SIM); if so, this would require the calculation of the fingerprint function, usually a hash function, reversible or other fingerprint function giving the same cryptogram (CRY) which is impossible to find.

Figure 1b shows the cryptogram verification (CRY) process which can be performed either regularly, for example before each request of the relevant application (APP), or preferably only once before installation or first use. If the cryptogram (CRY) is valid, the subscriber module (SIM) sends an OK message to the runtime environment (AEE). The application (APP) can then send its requests or commands (CMD) to the subscriber module (SIM) via the runtime environment (AEE) and use the resources (RES) of the subscriber module (SIM). The latter accepts the commands (CMD) by sending the appropriate responses (RSP) to the application (APP) via the runtime environment (AEE), Figure 1.

In the case of an invalid cryptogram (CRY), the subscriber module (SIM) sends a denial message (NOK) to the runtime environment (EEA). In such a case, the runtime environment (EEA) can either cancel the application installation process (APP) or the application (APP) is installed and its requests or commands (CMD) to the subscriber module (SIM) via the runtime environment (AEE) will remain unanswered (RSP) and the resources (RES) of the subscriber module (SIM) cannot be used.

In both OK and NOK cases, the application execution environment (AEE) can relay the response to the control server (CSE). The subscriber module can thus indirectly return a CRY confirmation (CF) to the control server (CSE) and allow end-to-end control of the operation, see Figure 1b. The confirmation (CF) includes at least one operation success or error code and a counter for protection against repeat attacks. This message also allows the control server (CSE) to keep the counter associated with the subscriber module (SIM) up to date.

In the second embodiment illustrated by Figures 2a, 2b, 2c, the application (APP) is downloaded alone, after identification (ID) of the mobile equipment (CB), without cryptogram (CRY), see Figure 2a.

In the verification process, Figure 2b, the application (APP) requests, when launched by the user, a cryptogram (CRY) including the resource rights (RES) for the 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 run 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 run environment (AEE) as in the implementation mode. In this case, the mode of the first run mode (AEE) is only a relay between the subscriber and the application (APP).

The application execution process (APP) after cryptogram verification (CRY), see Figure 2c, is carried out in the same way as in the first mode illustrated in Figure 1c and described above.

Figures 3a, 3b, 3c show a third variant where the APP application is downloaded alone, after identification (ID) of the mobile equipment (CB), from the control server (CSE) or from an intermediate application download server (APP) see Figure 3a. During the verification process (Figure 3b), the application loads the cryptogram (CRY) and the fingerprint (FIN2) directly from the server (CSE) or from an intermediate application download server (APP). In this case, unlike the previous two variants, the application environment (AEE) no longer calculates the fingerprint (FIN2) which is calculated by an external unit either by the control server or by an application download server (APP).

The application execution process (APP) after cryptogram verification (CRY), see Figure 3c, is carried out in the same way as in the two previous modes illustrated in Figures 1c and 2c.

This third embodiment may be preferred because its advantage is that it does not require any change to the runtime environment (EEE) as currently defined for Java applications installed in mobile phones, i.e. no change to existing standards is necessary.

Moreover, the constraint of the first variant that both cryptograms use the same fingerprint is removed as the cryptogram verification (CRY) and application installation processes are completely independent.

In order to customize the fingerprints calculated on the applications, one possibility is to add a different data for each mobile device to the application code before it is loaded into the mobile device. Thus, when the fingerprint is calculated by the application environment of the mobile device, this fingerprint is unique and cannot be used on another mobile device. The cryptogram will of course be calculated by the control server based on the original data of the application and this unique data.

In one variant of the invention, mobile equipment can be replaced with non-mobile equipment such as a pay TV set-top box 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 checked when commissioned 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.

Claims (18)

1. Authentication method of at least one application (APP) working in a equipment (CB) connected by a network (NET) to a control server (CSE), said equipment (CB) being locally connected to a security module (SIM), said application (APP) is loaded and/or executed by means of an application execution environment (AEE) of the equipment (CB) and uses resources (RES) stored in the security module (SIM), comprising the following preliminary steps:

   - reception by the control server (CSE), via the network (NET), of data comprising at least the identifier (IMEISV) of the equipment (CB) and the identifier (IMSI) of the security module (SIM),

   - analysis and verification by the control server (CSE) of said data,

   - generation of a cryptogram (CRY) comprising a digest (FIN1) of the application (APP), data identifying the equipment (CB) and the security module (SIM) and instructions (INS RES) intended for said module,

   - transmission of said cryptogram (CRY), via the network (NET) and the equipment (CB), to the security module (SIM),

   - verification of the application (APP) by comparing the digest (FIN1) extracted from the cryptogram (CRY) received with a digest (FIN2) determined by the security module (SIM),

   said method is characterized in that, during the initialization and/or the activation of the application (APP), the security module (SIM) executes the instructions (INS_RES) extracted from the cryptogram (CRY) and releases, respectively blocks the access to certain resources (RES) of said security module (SIM) according to the result of the verification suited to this application (APP) carried out previously.
2. Method according to claim 1 characterized in that the equipment is a mobile equipment (CB) of mobile telephony.
3. Method according to claim 1 characterized in that the network (NET) is a mobile network of the type GSM or GPRS or UMTS.
4. Method according to claim 1 or 2, characterized in that the security module (SIM) is a subscriber module inserted into the mobile equipment (CB) of mobile telephony of the SIM card type.
5. Method according to claims 1 or 4 characterized in that the identification (ID) of the set mobile equipment (CB) / subscriber module (SIM) is carried out from the identifier (IMEISV) of the mobile equipment (CB) and from the identifier of the subscriber module (SIM) suited to a subscriber to the network (NET).
6. Method according to claim 1 characterized in that the instructions included in the cryptogram (CRY) received by the security module (SIM) condition the use of the applications (APP) according to criteria established previously by the operator an/or the application supplier (FA) and/or the user of the equipment.
7. Method according to claim 6 characterized in that the criteria defining the limits of use of an application (APP) according to the risks associated with the software of said application (APP) or with the hardware of the equipment (CB) that the operator desires to take into account.
8. Method according to claim 1 characterized in that the verification of the application (APP) with the cryptogram (CRY) is carried out at the time of the first initialization or at the time of the first use of said application (APP).
9. Method according to claim 1 characterized in that the verification of the application (APP) with the cryptogram (CRY) is periodically carried out at a given rate according to instructions originating from the control server (CSE).
10. Method according to claim 1 characterized in that the verification of the application (APP) with the cryptogram (CRY) is carried out at the time of each initialization of said application (APP) on the equipment (CB).
11. Method according to claim 1 characterized in that the cryptogram (CRY) is generated with the aid of an asymmetrical or symmetrical encryption key from a data set containing, among other data, the identifier (IMEISV) of the equipment (CB), the identifier (IMSI) of the security module (SIM), an identifier of the application (APP), the digest (FIN1) of the application (APP) calculated with an unidirectional hash function and identifiers (RES_ID) of the resources of the security module (SIM) and instructions (INS_RES) for locking/releasing of resources of the security module (SIM).
12. Method according to claim 11 characterized in that the cryptogram (CRY) includes a variable that is predictable by the security module (SIM) avoiding the double use of a same cryptogram (CRY), the value of said variable being controlled by the security module (SIM) by making a comparison with that of a reference value stored in said module and regularly updated.
13. Method according to claim 1 characterized in that the security module (SIM) transmits to the control server (CSE), via the equipment (CB) and the network (NET), a confirmation message (CF) when said security module (SIM) has accepted or refused a cryptogram (CRY) of an application (APP).
14. Method according to the claim 1 characterized in that the cryptogram (CRY) is transmitted to the security module (SIM) at the same time as the application (APP) is loaded into the equipment (CB) via the execution environment of the applications (AEE).
15. Method according to claim 1 characterized in that the application (APP), once loaded into the equipment (CB) from the control server (CSE) via the network (NET), requests a cryptogram (CRY) from the server (CSE) at the time of its initialization and transmits said cryptogram (CRY) to the security module (SIM), the confirmation message (CF) of acceptance or refusal of the cryptogram (CRY) being transmitted by the security module (SIM) to the server via the application (APP).
16. Method according to claim 1, characterized in that the equipment is a Pay-TV decoder or a computer to which the security module is connected.
17. Security module comprising resources (RES) intended to be accessed locally by at least one application (APP) installed in an equipment (CB) connected to a network (NET), said equipment (CB) comprising means for reading and transmission data comprising at least the identifier (IMEISV) of the equipment (CB) and the identifier (IMSI) of the security module (SIM), said module is characterized in that it includes means for reception, storage and analysis of a cryptogram (CRY) containing among other data, a digest (FIN1) of said application (APP) and instructions (INS_RES), as well as means for verification of said application (APP), and means for extraction and execution of the instructions (INS_RES) contained in the cryptogram (CRY) releasing or blocking certain resources (RES) according to the result of the verification of the application (APP).
18. Security module according to claim 17, characterized in that it is of the "subscriber module " or " SIM card" type intended to be connected to a mobile equipment.