Method for managing a profile for accessing a communication network

Abstract

The invention relates to a method for managing, by a security module (10), a configuration file for accessing a communication network. The security module receives a request originating from a management entity (21, 22, 23) to perform a management action related to an access configuration file. The request comprises a certificate from the management entity. The security module verifies whether the received certificate is legitimate and whether the certificate carries information indicating that the entity is authorized to request the action, and if so, sends an authorization to jointly perform the action with the management entity. Otherwise, the security module rejects the request.

Description

Technical Field

[0001] This invention relates to the general telecommunications field.

[0002] The present invention relates more particularly to a technique for managing configuration files for accessing a communication network via a security module and a management entity. Background Technology

[0003] Management techniques are applicable to the field of mobile communication terminals, and more specifically to eUICC (eUICC is an abbreviation for Embedded Universal Integrated Circuit Card). Embedded eUICCs allow remote management of subscriptions to operators, enabling mobile devices to access mobile communication networks. The eUICC may be non-removable.

[0004] The GSMA (Global System for Mobile Communications Association) is developing technical specifications for "eUICC" type cards, which will function as security modules and are designed to be embedded in mobile user equipment. These security modules may be non-removable, thus necessitating remote actions—such as downloading configuration files for accessing the operator's network, or even managing those configuration files. In the context of M2M services (Machine-to-Machine), the GSMA technical specification "SGP.02 - Remote Configuration Architecture for Embedded UICC Technical Specification" version 4.0, dated February 25, 2019, specifies an architecture for remotely managing the configuration of eUICCs (or security modules). In this architecture, an SM-DP entity (SM-DP stands for Subscription Manager-Data Preparation) is configured to prepare network access configuration files for the eUICC security module, and an SM-SR entity (SM-SR stands for Subscription Manager-Security Router) controls access to the eUICC module to allow the SM-DP entity to install the access configuration file. In addition to this access control function, the SM-SR entity is also responsible for managing the configuration file after its installation via actions such as enabling (“Enable”), disabling (“Disable”), or even deleting (“Delete”). The SM-SR entity is the entry point used by the M2M service provider (M2M-SP) to access the eUICC module. It can be seen that in this architecture, the SM-SR entity acts as a checkpoint between the network operator and the eUICC module, as well as between the network operator and the M2M service provider. Therefore, for the M2M service provider, modifying the SM-SR entity is extremely complex. Summary of the Invention

[0005] One of the objectives of this invention is to overcome the deficiencies / disadvantages of the prior art and / or to improve upon it.

[0006] According to a first aspect, one subject of the present invention is a method for managing configuration files used to access a communication network via a security module. This method includes:

[0007] - Receive a request from the management entity to perform management actions related to the access profile, the request including the entity's certificate;

[0008] - Once the received certificate is verified to be valid and contains information indicating that the entity is authorized to request the execution of the action, an authorization to cooperate with the management entity to execute the action is sent;

[0009] - In the opposite case, send a rejection of the execution request.

[0010] In a corresponding manner, another aspect of the present invention is a method for managing configuration files used to access a communication network through a management entity. This method includes:

[0011] - Send a request to the security module to perform a management action related to the access configuration file, the request including the entity's certificate, the certificate containing information indicating that the entity is authorized to request the execution of the action;

[0012] - When the security module verifies that the certificate is valid and that the certificate contains the information, it receives authorization to cooperate with the security module to perform the action.

[0013] This invention aims to address identified shortcomings by implementing an M2M architecture. In addition to this M2M architecture, the GSMA provides different B2C architectures (B2C stands for Business to Consumer), which are not interoperable with the M2M architecture. The proposed technology enables the merging of these two architectures. The GSMA technical specification "SGP.22 - Remote Sim Configuration (RSP) Architecture for Consumer Devices" v.2.2.1, dated December 18, 2018, specifies an architecture for remotely managing security modules embedded in devices (directly controlled by the end user of the device). It specifies that users or consumers can subscribe directly through their user device's human-machine interface or by going to an operator's store, and / or install network access profiles. It also specifies that users or consumers can switch operators in the same way. To this end, the GSMA provides an architecture in which the user device obtains an access profile from an SM-DP+ server (SM-DP+ stands for Subscription Manager-Data Preparation+) responsible for preparing subscription-management data, in order to download the access profile already prepared for it. Users can then interact with their user devices to perform operations to manage that user's access profile. This architecture cannot be used to perform access profile management operations in M2M use cases.

[0014] Therefore, by modifying the B2C architecture provided by GSMA, the proposed technology enables support for M2M use cases. With this technology, M2M service providers can easily define an entity responsible for management actions such as enabling, disabling, and deleting access profiles. The M2M service provider can also subsequently modify this management entity. The entity responsible for downloading access profiles is managed by the operator of the communication network associated with the access profile. In M2M use cases, it is no longer necessary to download access profiles to communicate with the security module via the SM-SR server.

[0015] Therefore, the proposed technology enables the differentiation of roles among different management entities based on their interactions with operators or M2M service providers.

[0016] Therefore, the security module verifies whether the management entity requesting the management action actually possesses the permissions associated with the role assigned to it. In the M2M architecture, only the SM-SR server has the permission to establish a secure link with the security module. The proposed technique authorizes the entity requesting the management action based on the role contained in the certificate associated with other management entities. The request to perform a management action may correspond to a request to authorize the execution of an action, or it may implicitly contain a request to authorize the execution of an action.

[0017] An access profile corresponds to a set of data and a set of applications. Once the profile is enabled, this set of data and applications allows the mobile terminal to access the operator's network.

[0018] Two types of management entities can be defined:

[0019] - The first type of management entity is associated with downloading access configuration files to the security module. This first type of entity is typically under the control of the network operator.

[0020] - The second type of management entity is associated with the downloaded management access configuration file. This second type of entity is typically under the control of the M2M service provider.

[0021] Therefore, various management entities can be defined, and a role can be assigned to each management entity.

[0022] The various embodiments or features mentioned below can be added independently or in combination to the management access configuration file method as defined above.

[0023] In one particular embodiment, the certificate includes a field indicating authorization to perform the action.

[0024] This allows the security module to directly verify, based on this field, that the management entity indeed possesses the necessary permissions to request the action. The certificate is signed with the master entity's secret key and verified using the public key associated with that master entity. For example, the security module is initialized with this public key in the factory. This embodiment remains very simple to implement. The master entity is the entity that proves the role assigned to the management entity.

[0025] In one particular embodiment, the certificate is signed by a secret key associated with the action, which instructs a certificate authorizing the execution of the action.

[0026] This allows the security module to verify that a management entity has the necessary permissions based on the public key associated with a role and required to perform management actions. For example, the security module is initialized in the factory with one or more public keys, each associated with a role. The master entity is the entity that proves the role assigned to the management entity.

[0027] In one particular embodiment, the action belongs to the group that includes at least the following: downloading the access configuration file, enabling the access configuration file, disabling the access configuration file, and deleting the access configuration file.

[0028] Therefore, various management entities can be defined based on the defined roles.

[0029] According to a second aspect, the present invention relates to a security module configured to store a configuration file for accessing a communication network in a memory. The module includes:

[0030] - A configuration file management module, configured to: receive a request from a management entity to perform a management action related to an access configuration file, the request including the entity's certificate; authorize the entity to cooperate with the management entity to perform the action when the received certificate is verified to be valid and contains information indicating that the entity is authorized to request the action; and reject the request otherwise.

[0031] The advantages mentioned in the first aspect of the management method can be directly transferred to the security module.

[0032] The security module may, in terms of its structure, include various features related to the management methods described above, which may be implemented in combination or individually.

[0033] According to a third aspect, the present invention relates to a management entity for managing configuration files for accessing a communication network, the entity including a control module configured to: send a request to a security module to perform a management action related to the access configuration file, the request including a certificate of the entity containing information indicating that the entity is authorized to request the execution of the action; and receive authorization to cooperate with the security module to perform the action when the security module verifies that the certificate is valid and that the certificate contains the information.

[0034] The advantages mentioned in the management approach of the first aspect can be directly transferred to the management entity.

[0035] The management entity may, in terms of structure, include various features related to the management methods described above, which may be implemented in combination or individually.

[0036] According to a fourth aspect, the present invention relates to a management system for managing configuration files for accessing a communication network, the system comprising a management entity according to a third aspect and a master entity configured to sign a certificate of the management entity, the certificate containing information indicating that the entity is authorized to request to perform the action.

[0037] The advantages mentioned in the management method of the first aspect can be directly transferred to the management system.

[0038] The management system may, in terms of its structure, include various features related to the management methods described above, which may be implemented in combination or individually.

[0039] According to a fifth aspect, the present invention relates to: a program for a security module, the program comprising program code instructions intended for commanding the execution of steps of a method for managing access configuration files as described above, when the program is implemented by the security module; and a storage medium readable by the security module, on which the program for the security module is stored.

[0040] The advantages mentioned regarding the method of managing access configuration files according to the first aspect can be directly transferred to the program used for the security module and the storage medium.

[0041] According to a sixth aspect, the present invention relates to: a program for a management entity, the program comprising program code instructions intended for commanding the execution of steps of a method for managing an access configuration file as described above when the program is executed by the management entity; and a storage medium readable by the management entity, on which the program for the management entity is stored.

[0042] The advantages mentioned in the management method of the first aspect can be directly transferred to the program used to manage the entity and the storage medium. Attached Figure Description

[0043] The technique for managing access configuration files will be better understood through the following description of specific embodiments given with reference to the accompanying drawings, in which:

[0044] - Figure 1 A system is shown that implements a method for managing access profiles in a particular embodiment;

[0045] - Figure 2A The steps of a method for managing access profiles implemented by a security module according to a specific embodiment are shown;

[0046] - Figure 2B The steps of a method for implementing a management access profile by a management entity according to a specific embodiment are shown;

[0047] - Figure 3A The certificate tree in the first specific embodiment is shown;

[0048] - Figure 3B The certificate tree in the second specific embodiment is shown;

[0049] - Figure 4A A security module in a particular embodiment is shown;

[0050] - Figure 4B The management entity in a particular embodiment is shown. Detailed Implementation

[0051] The remainder of the specification describes examples of several embodiments applicable to eUICC security modules (such as those currently being standardized by the GSMA), but the methods for managing access profiles are also applicable to other types of security modules. More generally, a security module is an inviolable, dedicated platform, comprising hardware and software capable of securely hosting applications and their confidential and encrypted data and providing a secure execution environment for applications, and, for example, a UICC-type card.

[0052] The following description should be read within the context of, for example, technical specifications defined by the GSMA. More specifically, the architecture for remote configuration management is defined in technical specification “SGP.21 RSP Architecture” version 2.2 dated September 1, 2017, and the procedures are defined in GSMA technical specification “SGP.22 - Remote Sim Configuration (RSP) Architecture for Consumer Devices” v.2.2.1 dated December 18, 2018.

[0053] Figure 1An environment in which a method for managing access configuration files is implemented in a particular embodiment is shown.

[0054] User equipment associated with security module 10 (in) Figure 1 (Not shown in the image) is configured to access the operator's network via a network access profile generated by the mobile operator for this security module. The access profile corresponds to a set of data and a set of applications; once the profile is enabled, this data and these applications allow the mobile terminal to access the operator's network. The user equipment and the security module together form the mobile terminal. More precisely, the access profile is generated by a server associated with the operator for managing subscription data (in...). Figure 1 The server (not shown) generates this for the security module. The access profile includes the application used to access the network and associated access data (also known as credentials), such as algorithms and encryption keys. The access profile specifically allows the mobile terminal (more precisely, security module 10) to be authenticated during access to the operator's network.

[0055] Security module 10 is typically an eUICC type card (eUICC is an abbreviation for Embedded Universal Integrated Circuit Card), also known as an eSIM (eSIM is an abbreviation for Embedded Subscriber Identity Module) or a non-removable SIM card. There are no restrictions on the type of card. In one particular embodiment, security module 10 is a chip card with an operating system providing eUICC functionality. In another particular embodiment, security module 10 is integrated into the terminal, thus forming a single entity. Figure 1 A single security module 10 is shown in the image. It should be understood that this is merely an illustrative example.

[0056] Figure 1 Four management entities are shown:

[0057] -The main entity 20, whose primary role is to assign roles to management entities 21, 22, and 23;

[0058] - Install Entity 21, whose main role is to download the access configuration file to the security module;

[0059] - Enable / disable entity 22, whose main role is to enable or disable access configuration files stored in the memory on the security module;

[0060] - Delete entity 22, whose main role is to delete the access configuration file stored in the memory on the security module.

[0061] These management entities are described as functional entities, consisting of one main entity and three management entities. Roles are assigned by the main entity to each of the three management entities. This role assignment is unrestricted. Multiple management entities can be grouped together within the same server. A single management entity can also be assigned multiple roles. Figure 1 In this document, each role to be assigned is represented by a single management entity. It should be understood that the same role can be assigned to multiple management entities. Specifically, the M2M service provider defines the management entity that will manage the security modules used for delivering M2M services. Figure 1 The number of management entities shown is unlimited. As many management entities as are needed to perform management actions related to the access configuration file can be defined.

[0062] In a B2C architecture, an SM-DP+ server (SM-DP+ stands for Subscription Manager-Data Preparation+) can be selected to prepare subscription-management data, accommodating these different functional management entities. This server's role is to deliver the data by downloading the access configuration file prepared for the security module. The server's role is:

[0063] -Prepare configuration file groups

[0064] - Securely store the configuration file protection key in memory and group the protected configuration files in the memory area, and

[0065] - Assign configuration file groups based on security module identifiers.

[0066] The SM-DP+ server associates protected configuration file groups with the security module and, after establishing a secure download session, downloads one or more access configuration files via the LPA application (LPA stands for Local Profile Assistant). Depending on the embodiment, the LPA application may be executed on the user device or within security module 10.

[0067] The main entity 20 and management entities 21 to 23 form the management system 1.

[0068] Reference Figure 3A and Figure 3B Two implementations of a certificate tree are described.

[0069] The two diagrams illustrate the Certificate Authority (CA). This CA has a key pair stored in memory: a private key GlobalCA_SK and an associated public key GlobalCA_PK.

[0070] In the embodiments described below, the public key certificate is in X.509 format. An X.509 certificate is a digital identity that associates an authenticated public key with a physical entity. The certificate is issued by a Certificate Authority (CA) according to a secure process. Once the certificate is issued, services implementing security functions can use the authenticated public key. A public key certificate includes many fields, in particular:

[0071] -The identity of the certificate issuing authority that issued the certificate.

[0072] - Certificate signing algorithm: Certificate Authorities use this algorithm to sign certificates.

[0073] -Certificate validity period,

[0074] -Certificate holder's name

[0075] - Information about the public key: the algorithm used with the public key, the public key itself,

[0076] - The certificate issuing authority's signing of the certificate,

[0077] - Optional information.

[0078] Main entity 20 (in Figure 3A and Figure 3B The certificate (represented as SM-DPM) has a key pair stored in memory: a private key CertMaster_SK and an associated public key CertMaster_PK. The Certificate Authority GlobalCA has issued a public key certificate CertMaster to certify the public key CertMaster_PK. The Certificate Authority then signs the master entity's certificate CertMaster using its private key GlobalCA_SK.

[0079] Security module 10 has a pair of keys stored in memory: a security module-specific private key EUICC_SK; and an associated public key EUICC_PK. The certificate authority GlobalCA or the card manufacturer has issued a public key certificate, CerteUICC, to verify the public key EUICC_PK; the card manufacturer is referred to as EUM (representing the eUICC manufacturer). In the latter case, the EUM certificate is signed by the GSMA certificate authority GlobalCA. This allows security module 10 to be authenticated by any entity that identifies the certificate authority GlobalCA.

[0080] Installing entity 21 (in) Figure 3A and Figure 3B The private key (referred to as SM-DPI) has a pair of keys stored in memory: CertDPI_SK and the associated public key CertDPI_PK.

[0081] Enable / disable entity 22 (in Figure 3A and Figure 3B The private key (represented as SM-DPED) has a pair of keys stored in memory: the private key CertDPED_SK and the associated public key CertDPED_PK.

[0082] Delete entity 23 (in Figure 3A and Figure 3B The private key (referred to as SM-DPD) has a pair of keys stored in memory: CertDPD_SK and the associated public key CertDPD_PK.

[0083] There are no restrictions on the type of certificate. In particular, the certificate can be another type, such as an SSL certificate (SSL stands for Secure Sockets Layer). This description can be easily applied to any type of certificate.

[0084] Now refer to Figure 3A The first embodiment is described. In this embodiment, the certificates of management entities 21, 22, and 23 include fields indicating authorization to perform management actions on access profiles. More specifically, this field specifies the role assigned to the management entity associated with the certificate. This role corresponds to authorization to perform management actions. In the described case, this involves installing access profiles, enabling or disabling access profiles, and / or deleting access profiles. This list of management actions is non-limiting.

[0085] In this first embodiment, the certificate of the management entity is signed by the master entity 20. The certificate of the installation entity 21 is represented as (CertDPI). CertMaster Enabling / disabling the certificate for entity 22 is represented as (CertDPED). CertMaster The certificate for deleting entity 23 is represented as (CertDPD). CertMaster .

[0086] In this first embodiment, security module 10 has two public keys stored in memory: the public key GlobalCA_PK of the certificate authority GlobalCA and the public key CertMaster_PK of the master entity 20. These public keys are configured, for example, in a factory.

[0087] In another embodiment, the certificate of the managing entity is signed by the certificate authority GlobalCA.

[0088] Now refer to Figure 3BThe second embodiment is described. In this embodiment, the certificates of management entities 21, 22, and 23 are signed with a secret key of a certificate associated with a management action related to the access profile (which instructs authorization to perform the action). More specifically, the main entity 20 has three available certificates, each associated with a role:

[0089] -CertInstall is a certificate associated with the role in the installation access configuration file. The secret key of this certificate, CertInstall, is used to sign the certificate CertDPI for installation entity 21. The latter certificate is represented as (CertDPI). CertInstall ;

[0090] -CertEnD is a certificate associated with the role in the Enable / Disable Access Profile. The secret key of this certificate CertEnD is used to sign the certificate CertDPED for Enable / Disable Entity 22. The latter certificate is represented as (CertDPED). CertEnD ;

[0091] -CertDel is the certificate associated with the role in the deleted access profile. The secret key of this CertDel certificate is used to sign the CertDPD certificate for deleted entity 23. The latter certificate is represented as (CertDPD). CertDel .

[0092] Therefore, the role assigned to a management entity corresponds to the role associated with the certificate used to sign the certificate for that management entity. This role corresponds to the authorization to perform management actions. In the described case, this involves installing access profiles, enabling or disabling access profiles, and / or deleting access profiles.

[0093] In this second embodiment, security module 10 has five public keys stored in memory: GlobalCA_PK (public key of the certificate authority GlobalCA), CertMaster_PK (public key of the master entity 20), CertInstall_PK, CertEnD_PK, and CertDel_PK (public key of the master entity 20). These public keys are configured, for example, in a factory.

[0094] Therefore, the main entity 20 has the role of assigning permissions to each administrative entity, namely, in the described case, to the installation entity 21, the enable / disable entity 22, and the delete entity 23. This permission assignment is performed using certificates associated with the relevant administrative entities.

[0095] As can be seen, in both embodiments, the security module 10 is able to verify whether the certificate provided by the management entity actually contains information instructing the entity to be authorized to request the execution of management actions related to the access profile: in the first embodiment, verification is performed by directly accessing the field containing the information, while in the second embodiment, verification is performed based on the certificate used to sign the certificate provided by the management entity.

[0096] Below, a request to perform a management action can correspond to: an exchange that includes requesting authorization to perform the action, followed by the execution itself; or simply an execution request, the latter of which implicitly includes requesting authorization to perform the action.

[0097] Now refer to Figure 2A This describes the steps of a method for managing access profiles implemented by a security module according to a specific embodiment. For its part, the steps of a method for managing access profiles implemented by a management entity are referenced. Figure 2B The following description will consider the case where installation entity 21 requests an action to download the access configuration file to security module 10. In the described embodiment, it will be recalled that the management action belongs to at least the following group: downloading the access configuration file, enabling the access configuration file, disabling the access configuration file, and deleting the access configuration file. This example is non-limiting, and this description can be readily transferred to enabling / disabling entity 22 for enabling / disabling the access configuration file, deleting entity 23 for deleting the access configuration file, or even any management action related to the access configuration file.

[0098] In one particular embodiment, the execution of these steps is triggered by a principal (e.g., an operator) who sends a request to the installation entity 21 to download the access configuration file to the security module by providing the information required to identify the security module.

[0099] After a secure download session is established, installation entity 21 (step F1) and security module 10 (step E1) initialize the download process as described in reference specifications SGP.21 and SGP.22. This download session relies on a secure TLS connection (TLS stands for Transport Layer Security) and follows mutual authentication between installation entity 21 and security module 10.

[0100] In step F2, the installation entity 21 sends a request to the security module 10 to perform a management action related to the access configuration file. More specifically, in the described example, this management action corresponds to downloading the access configuration file. The request includes the certificate of the installation entity 21, such as a public key certificate. The sent certificate contains information indicating that the installation entity is authorized to request the download action. In the first embodiment, this certificate (CertDPI) CertMasterThis includes fields that instruct authorization to perform the download action. In the second embodiment, this is the certificate (CertDPI). CertInstall Signed using the secret key of the certificate CertInstall, which is specific to the download role.

[0101] In step E2, the security module 10 receives a request from the installation entity 21 to perform management actions related to the access profile, the request including a certificate, such as a public key certificate.

[0102] In step E3, security module 10 verifies the validity of the received certificate, and more specifically, security module 10 verifies the validity of the certificate provided by installation entity 21 using the corresponding public key CertDPI_PK installed in security module 10. If this is not the case, security module 10 disauthorizes the execution of the request by sending a rejection and interrupts the download process.

[0103] If the verification shows that the received certificate is valid, then in step E4, the security module 10 verifies whether the received certificate contains information indicating that the entity 21 is authorized to request to perform a download action. In the first embodiment, this is to verify the certificate (CertDPI). CertMaster The question is whether to include a field instructing authorization to perform the download action. In the second embodiment, this involves verifying the certificate (CertDPI). CertInstall The question concerns whether the signing was performed using a secret key of a certificate specific to the download role. To perform this verification, security module 10 has a public key, CertInstall_PK, of a certificate specific to the download role, stored in memory. If security module 10 determines that the received certificate does not contain information indicating that entity 21 is authorized to request the download action, security module 10 denies the request by sending a rejection and interrupts the download process.

[0104] If security module 10 verifies that the received certificate contains information indicating that entity 21 is authorized to request to perform a download action, then in step E5, security module 10 sends authorization to cooperate with installation entity 21 to perform the download action (this authorization is received in step F3). The process of performing the action (i.e., downloading) continues as described in technical specifications SGP.21 and SGP.22.

[0105] As can be seen, the proposed architectural modifications allow for the management of security modules for both M2M and B2C services. These security modules interact with the management entity using the same technology. By assigning roles to the management entity, the M2M and B2C architectures are merged into a single architecture. Specifically, the M2M service provider gains the freedom to choose its collaborators, outsourcing the implementation of operations for managing access profiles to those collaborators.

[0106] Figure 4A A security module 10 in a particular embodiment is illustrated schematically. The security module 10 specifically includes:

[0107] - Hardware processor 101, used to execute code instructions of software modules;

[0108] - Memory region 103 is configured to store a program including code instructions for implementing steps of a method for managing access configuration files;

[0109] - Storage memory 104 is configured to store data used during the implementation of the management access configuration file, such as parameters for calculations performed by processor 101, intermediate data of calculations performed by processor 101, etc.

[0110] - Network interface 102;

[0111] - The configuration file management submodule 105 is configured to download and install access configuration files and store them in a secure container. This module corresponds to, for example, the ISD-P module defined by GSMA (ISD-P stands for Issuer Security Domain Configuration File);

[0112] - Security Control Submodule 106. This module corresponds to, for example, the ECASD module defined by GSMA (ECASD stands for Embedded UICC Control Authority Security Domain);

[0113] These components are connected to each other via bus 100.

[0114] Of course, the components of the security module 10 can also be connected via a connection method other than the bus.

[0115] It should be emphasized here that security module 10 also includes other processing submodules ( Figure 4A (Not shown in the image), these processing submodules are configured to implement various security module functions.

[0116] Processor 101 commands the operation of the security module. Memory region 103 stores at least one computer program code, which, when executed by processor 101, implements various functions of the security module. Processor 101 can be formed by any known and suitable hardware or software, or a combination of hardware and software. For example, processor 101 can be formed by dedicated hardware such as processing circuitry, or by a programmable processing unit such as a central processing unit that executes programs stored in its memory.

[0117] Memory region 103 can be formed of any suitable means capable of storing a program in a computer-readable manner. Examples of memory region 103 include computer-readable non-transitory storage media, such as semiconductor memory devices; and magnetic, optical, or magneto-optical storage media loaded into the read-write unit. The program causes processor 101 to execute a method for managing access profiles according to a particular embodiment.

[0118] Network interface 102 provides a connection between the security module and the management entity via a communication network based on the underlying access network.

[0119] The security control submodule 106 is configured to securely store authentication data in memory and provide the following services to the configuration file management submodule 105: sign the data provided to it with its secret key CerteUICC_SK, and verify the certificate with the public key GlobalCA_PK of the certificate authority or the public key CertMaster_PK of the master entity upon request from the submodule.

[0120] Specifically, the following authentication data is stored in the memory of the security control submodule 106:

[0121] - The security module's private key CerteUICC_SK and its public key certificate CerteUICC, which includes the public key CerteUICC_PK; and

[0122] - The public key of the certificate authority, GlobalCA_PK, or the public key of the master entity, CertMaster_PK.

[0123] In the second embodiment, the security control submodule 106 further includes public key CertInstall_PK, public key CertEnD_PK, and public key CertDel_PK.

[0124] Specifically, the security control submodule 106 is configured to verify whether the certificate for a request received from the management entity to perform an action related to the access profile is valid, and to verify whether the certificate contains information indicating that the entity is authorized to request the performance of the action.

[0125] Figure 4B The diagram schematically illustrates management entities 20, 21, 22, and 23 in a specific embodiment. Management entity 20 specifically includes:

[0126] - Hardware processor 201, used to execute code instructions of software modules;

[0127] - Memory region 203 is configured to store a program including code instructions for implementing steps of a method for managing access configuration files;

[0128] - Storage memory 204 is configured to store data used during the implementation of the management access configuration file, such as parameters for calculations performed by processor 201, intermediate data of calculations performed by processor 201, etc.

[0129] -Network interface 202;

[0130] -Control module 205;

[0131] These components are connected to each other via bus 200.

[0132] Of course, the components of the management entity can also be connected via connection methods other than the bus.

[0133] It should be emphasized here that the management entity also includes other processing sub-modules ( Figure 4B (Not shown in the image), these processing submodules are configured to implement various management entity functions.

[0134] Processor 201 commands the operation of the management entity. Memory region 203 stores at least one computer program code, which, when executed by processor 201, implements various functions of the management entity. Processor 201 can be formed by any known and suitable hardware or software, or a combination of hardware and software. For example, processor 201 can be formed by dedicated hardware such as processing circuitry, or by a programmable processing unit such as a central processing unit that executes programs stored in its memory.

[0135] Memory region 203 can be formed of any suitable means capable of storing a program in a computer-readable manner. Examples of memory region 203 include computer-readable non-transitory storage media, such as semiconductor memory devices; and magnetic, optical, or magneto-optical storage media loaded into the read-write unit. The program causes processor 201 to execute a method for managing access profiles according to a particular embodiment.

[0136] Network interface 202 provides a connection between the management entity and the security module via a communication network based on the underlying access network.

[0137] In the main entity 20, the control module 205 is specifically configured to sign the public key certificate of the management entity, which contains information indicating that the entity is authorized to request to perform management actions related to the access profile.

[0138] Other management entities 21, 22, and 23 have a structure similar to that described above with reference to management entity 20. In these entities, control module 205 is then configured to: send a request to the security module to perform a management action related to the access profile, the request including the entity's certificate containing information indicating that the entity is authorized to request the action; and receive authorization to cooperate with the security module in performing the action when the security module verifies that the certificate is valid and contains the information.

[0139] The technology for managing access profiles is implemented through software components and / or hardware components. In this regard, the term "module" in this document may be equivalent to a software component, a hardware component, or a set of hardware components and / or software components that are capable of implementing a function or a set of functions as described above regarding modules.

[0140] A software component corresponds to one or more computer programs, one or more subroutines of a program, or more generally, any element of a program or software. Such a software component is stored in memory and then loaded and executed by the data processor of a physical entity, and has access to the hardware resources of that physical entity (memory, recording media, communication bus, electronic input / output card, user interface, etc.).

[0141] In the same way, a hardware component corresponds to any element of a hardware assembly. A hardware component can be programmable or non-programmable, and may or may not have an integrated processor for executing software. Examples include integrated circuits, chip cards, electronic cards for executing firmware, etc.

[0142] In one particular embodiment, modules 105 and 106 are configured to implement steps of a method for managing access profiles, said steps being performed by a security module. These are preferably software modules comprising software instructions for performing the steps (or actions) of the aforementioned method for managing access profiles, said steps (or actions) being performed by the security module. Therefore, the invention also relates to:

[0143] - A program for a security module, the program including program code instructions that are intended to be used to command the steps (or actions) of the method for managing access configuration files described above when the program is executed by the security module;

[0144] - A storage medium readable by the security module, on which a program for the security module is stored.

[0145] In one particular embodiment, module 205 is configured to implement steps of a method for managing access profiles, said steps being performed by a management entity. These are preferably software modules comprising software instructions for performing the steps (or actions) of the management method described above, said steps (or actions) being performed by a management entity. Therefore, the invention also relates to:

[0146] - A program for managing an entity, the program including program code instructions that are intended to be used to command the steps (or actions) of the management access configuration file method described above when the program is executed by the management entity;

[0147] - A storage medium readable by the management entity, on which programs for such an entity are stored.

[0148] These software modules can be stored in or transmitted by a data medium. The data medium can be a hardware storage medium (such as a CD-ROM, floppy disk, or hard disk) or other transmission medium (such as electrical signals, optical signals, radio signals, or telecommunications networks).

[0149] Therefore, the present invention also relates to a security module configured to store a configuration file for accessing a communication network in a memory, the module including a processor configured to:

[0150] - Receive a request from the management entity to perform management actions related to the access profile, the request including the entity's certificate;

[0151] - Once the received certificate is verified to be valid and contains information indicating that the entity is authorized to request the execution of the action, an authorization to cooperate with the management entity to execute the action is sent;

[0152] - In the opposite case, send a rejection of the execution request.

[0153] Therefore, the present invention also relates to a management entity configured to manage configuration files for accessing a communication network, the method comprising:

[0154] - Send a request to the security module to perform a management action related to the access configuration file, the request including the entity's certificate, the certificate containing information indicating that the entity is authorized to request the execution of the action;

[0155] - When the security module verifies that the certificate is valid and that the certificate contains the information, it receives authorization to cooperate with the security module to perform the action.

Claims

1. A method of managing, by a security module, a profile for accessing a communication network, the method comprising: receiving, from a management entity, a request to perform a management action related to an access profile, the request comprising a certificate of the entity, the certificate being signed by a secret key of a master entity attesting a role assigned to the management entity, the role corresponding to an authorization to perform the management action, and being verified by a public key associated with the master entity; when it is verified that the received certificate is legitimate and that the received certificate contains information indicating that the role assigned to the management entity corresponds to an authorization to perform the management action, sending to the management entity an authorization to perform the action in collaboration with the management entity; in the opposite case, sending to the management entity a refusal to perform the request.

2. A method of managing, by a management entity, a profile for accessing a communication network, the method comprising: sending, to a security module, a request to perform a management action related to an access profile, the request comprising a certificate of the entity, the certificate containing information indicating a role assigned to the management entity, the certificate being signed by a secret key of a master entity attesting the role of the management entity, the role corresponding to an authorization to perform the management action, and being verified by a public key associated with the master entity; when it is verified by the security module that the certificate is legitimate and that the certificate contains the information, receiving, from the security module, an authorization to perform the action in collaboration with the security module.

3. The method of any one of claims 1 and 2, wherein, the certificate comprises a field indicating the authorization to perform the action.

4. The method of any one of claims 1 and 2, wherein, the secret key is a secret key of a certificate associated with the role assigned to the management entity.

5. The method of any one of claims 1 and 2, wherein, the action belongs to a group comprising at least: downloading an access profile, enabling an access profile, disabling an access profile, and deleting an access profile.

6. A security module configured to store, in a memory, a profile for accessing a communication network, the module comprising: a profile management module configured to: receive, from a management entity, a request to perform a management action related to an access profile, the request comprising a certificate of the entity, the certificate being signed by a secret key of a master entity attesting a role assigned to the management entity, the role corresponding to an authorization to perform the management action, and being verified by a public key associated with the master entity; when it is verified that the received certificate is legitimate and that the certificate contains information indicating that the role assigned to the management entity corresponds to an authorization to perform the management action, send to the management entity an authorization to perform the action in collaboration with the management entity; in the opposite case, send to the management entity a refusal to perform the request.

7. A management entity managing a configuration file for accessing a communication network, said entity comprising a control module configured to send to a security module a request to perform a management action related to the access configuration file, said request comprising a certificate of said entity containing information indicating a role assigned to said management entity, said certificate being signed by a secret key of a master entity attesting the role assigned to the management entity and being verified by a public key associated with the master entity, said role corresponding to an authorization to perform said management action; and to receive an authorization to perform the action in collaboration with the security module when the security module has verified that the certificate is legitimate and contains said information.

8. A management system managing a configuration file for accessing a communication network, said system comprising a management entity as claimed in claim 7 and a master entity configured to sign a certificate of the management entity, said certificate containing information indicating that said entity is authorized to request the performance of said action.

9. A storage medium readable by a security module, on which is stored a program comprising program code instructions intended to instruct, when said program is executed by said security module, the implementation of the steps of the method of managing a configuration file for accessing a communication network as claimed in one of claims 1 and 3 to 5, said steps being implemented by the security module.

10. A storage medium readable by a management entity, on which is stored a program comprising program code instructions intended to instruct, when said program is executed by said entity, the implementation of the steps of the method of managing a configuration file for accessing a communication network as claimed in one of claims 2 to 5, said steps being implemented by the management entity.

Images