WO2021058933A1

WO2021058933A1 - An apparatus and method for controlling access to security modules

Info

Publication number: WO2021058933A1
Application number: PCT/GB2020/051776
Authority: WO
Inventors: Paul James Reid; Kyle CLARKE
Original assignee: Kigen (Uk) Limited
Priority date: 2019-09-24
Filing date: 2020-07-24
Publication date: 2021-04-01
Also published as: GB201913746D0; GB2587610B; GB2587610A

Abstract

A technique is provided for controlling access to security modules. An apparatus has a first interface circuitry for establishing connections with a plurality of security modules, wherein at least one security module in the plurality of security modules has a different owner to at least one other security module in the plurality of security modules. Second interface circuitry is then used to establish communication with a plurality of subscription management servers. A storage stores ownership- based access control information for the plurality of security modules, where that information identifies the owner of each security module and which subscription management servers are allowed access to the security modules of each owner. Access control circuitry is then responsive to a request for a given subscription management server to have access to an identified security module, to reference the ownership-based access control information in order to determine whether to allow the given subscription management server to access the identified security module. Such an approach allows multi-tenanted systems to be provided, thereby amortising the costs involved in providing an apparatus to manage secure communication with security modules.

Description

AN APPARATUS AND METHOD FOR CONTROLLING ACCESS TO

SECURITY MODULES

BACKGROUND The present technique relates to an apparatus and method for controlling access to security modules.

Security modules may be associated with devices in order to control access by those devices to network infrastructure provided by a network operator. The security module may for example be implemented by a Subscriber Identity Module (SIM), which may also be referred to as a Universal Integrated Circuit Card (UICC). Modern security modules may be embedded or integrated within the device, and may be able to store multiple subscription profiles, where each subscription profile is associated with a network operator.

The organisation and structure of such security modules may be defined by certain Telecommunications Standards, for example by GSMA Standards, and those Standards may define the use of an access control apparatus such as a server to provide a secure path for accessing security modules. For example, in accordance with the GSMA Standards, such an access control apparatus may be referred to as a Subscription Manager Secure Routing (SM-SR) server. Typically a plurality of security modules may be associated with such an access control apparatus, and then other entities in the system that want to interact with those security modules, for example to download a new subscription profile to one or more of those security modules, will need to contact the access control apparatus in order to seek to establish a secure communication with the relevant security module. Traditionally, all of the security modules associated with such an access control apparatus would typically be owned by the same entity, and indeed that entity would also typically operate the access control apparatus used to establish a secure routing with those security modules. Thus, the owning entity can establish global rules applied by the access control apparatus in order to control which entities can access the security modules falling under the control of that access control apparatus.

However, the provision of an apparatus such an SM-SR server is very costly, due to the high levels of security and integrity that need to be achieved by that apparatus. Accordingly, it would be desirable to allow a single such access control apparatus to control access to a plurality of security modules that are not all owned by the same owning entity, so as to enable amortisation of some of the costs associated with providing such an access control apparatus. However, different owners may have different requirements as to the entities that are allowed to access their security modules, and this can impact the ability to adopt the above approach.

SUMMARY

In one example arrangement, there is provided an apparatus comprising: first interface circuitry to establish connections with a plurality of security modules, wherein at least one security module in said plurality of security modules has a different owner to at least one other security module in said plurality of security modules; second interface circuitry to establish communication with a plurality of subscription management servers; a storage to store ownership-based access control information for said plurality of security modules, the ownership-based access control information identifying the owner of each security module and identifying which subscription management servers in said plurality of subscription management servers are allowed access to the security modules of each owner; and access control circuitry responsive to a request for a given subscription management server to have access to an identified security module in said plurality of security modules, to reference the ownership-based access control information in order to determine whether to allow the given subscription management server to access the identified security module.

In another example arrangement, there is provided a device operated by an owner of a first security module, comprising: access determination circuitry to determine which of a plurality of subscription management servers the owner wishes to grant access to the first security module; and a communication interface to issue an authorisation request, providing an owner indication and an indication of an identified subscription management server, to an apparatus used to establish connections with a plurality of security modules that includes the first security module, to enable the apparatus to allow the identified subscription management server to have access to the first security module via the apparatus when the apparatus receives a request for access from the identified subscription management server. In a still further example arrangement, there is provided a device operated by a manufacturer of a first security module, comprising: owner determination circuitry to determine an owner for the first security module; and a communication interface arranged, when the first security module is allocated to an apparatus used to establish connections with a plurality of security modules, to issue a registration request to the apparatus identifying the first security module and providing an owner indication, to cause the apparatus to update ownership-based access control information stored therein in order to identify the owner of the first security module.

In a yet further example arrangement, there is provided a method of operating an apparatus to control access to a plurality of security modules, comprising: employing first interface circuitry to establish connections with the plurality of security modules, wherein at least one security module in said plurality of security modules has a different owner to at least one other security module in said plurality of security modules; employing second interface circuitry to establish communication with a plurality of subscription management servers; storing ownership-based access control information for said plurality of security modules, the ownership-based access control information identifying the owner of each security module and identifying which subscription management servers in said plurality of subscription management servers are allowed access to the security modules of each owner; and responsive to a request for a given subscription management server to have access to an identified security module in said plurality of security modules, referencing the ownership-based access control information in order to determine whether to allow the given subscription management server to access the identified security module.

In another example arrangement, there is provided an apparatus comprising: first interface means for establishing connections with a plurality of security modules, wherein at least one security module in said plurality of security modules has a different owner to at least one other security module in said plurality of security modules; second interface means for establishing communication with a plurality of subscription management servers; storage means for storing ownership-based access control information for said plurality of security modules, the ownership-based access control information identifying the owner of each security module and identifying which subscription management servers in said plurality of subscription management servers are allowed access to the security modules of each owner; and access control means, responsive to a request for a given subscription management server to have access to an identified security module in said plurality of security modules, for referencing the ownership-based access control information in order to determine whether to allow the given subscription management server to access the identified security module.

BRIEF DESCRIPTION OF THE DRAWINGS

The present technique will be described further, by way of illustration only, with reference to examples thereof as illustrated in the accompanying drawings, in which:

Figure 1 is a block diagram of a system in accordance with one example arrangement;

Figure 2 is a block diagram illustrating components provided within a security module in one example arrangement;

Figure 3 illustrates the form of ownership-based access control information that can be utilised in accordance with one example implementation;

Figure 4A illustrates fields that may be provided within a registration request issued to an access control apparatus in order to seek to register a given security module with that apparatus, and Figure 4B is a flow diagram illustrating steps performed by the access control apparatus upon receipt of the registration request, in accordance with one example arrangement;

Figure 5A illustrates fields provided within an authorisation request that may be issued to an access control apparatus used to control access to a number of different security modules, Figure 5B illustrates in more detail the information that may be provided within such fields, and Figure 5C is a flow diagram illustrating steps performed by the access control apparatus upon receipt of such an authorisation request;

Figure 6 is a flow diagram illustrating steps performed by an access control apparatus that is used to control access to a plurality of security modules, upon receipt of an access request, in accordance with one example arrangement;

Figure 7 is a flow diagram illustrating steps performed by such an apparatus upon receipt of an access request in accordance with one specific implementation; Figure 8 is a block diagram of an authorisation request issuing device in accordance with one example implementation; and

Figure 9 is a block diagram of a registration request issuing device in accordance with one example implementation.

DESCRIPTION OF EXAMPLES

In accordance with the techniques described herein, an apparatus is described that can be used to control access to a plurality of security modules that are not all owned by the same owner. The apparatus can take a variety of forms, but in accordance with the GSMA Standard, for example, such an apparatus may be implemented as an SM-SR server. Such an apparatus is used to establish a secure connection with the security modules that fall under its control, and that secure connection may be used by other entities within the system, for example by an entity used to download a subscription profile to one of those security modules. When the apparatus used to establish the secure connection with the various security modules is under the direct control of the owning entity of all of the security modules registered with that apparatus, then it is possible to define global rules that can be implemented by the apparatus in order to control which entities within the system are allowed to access those security modules via the apparatus, and in particular which of those entities are allowed to use the secure routing mechanism that may be implemented by that apparatus.

However, in order to amortise the cost associated with providing such an apparatus, it would be desirable to provide for a “multi-tenanted” system where such an apparatus can be used to control access to a plurality of security modules, but where not all of those security modules are owned by the same owner. Whilst global rules could still be enforced in such a situation, this could significantly impact the ability to establish such multi -tenanted systems, since it would only be possible in situations where the various owners of the security modules that are to be controlled by that apparatus are able to take a common approach as to which other entities are to be allowed access to the security modules, and in many instances this may be an impractical limitation.

In accordance with the techniques described herein, a mechanism is provided that allows for the accesses to the various security modules that fall under the control of the apparatus to be controlled by the apparatus taking into account restrictions imposed on an owner-by-owner basis.

In particular, in one example implementation the apparatus has first interface circuitry used to establish connections with a plurality of security modules, wherein at least one security module in the plurality of security modules has a different owner to at least one other security module in the plurality of security modules. By way of example, this first interface circuitry can hence be used to establish secure connections with individual security modules in the plurality, with the security of those connections conforming to a specified Telecommunications Standard, for example the earlier mentioned GSMA Standard.

In addition, the apparatus has second interface circuitry for establishing communication with a plurality of subscription management servers. These individual subscription management servers can be owned by a variety of different entities, and hence for example some may be owned by network operators whilst others may be owned by service providers (where a service provider is an entity that an owner of a device incorporating a security module may enter into an agreement with for the provision of network services, rather than dealing directly with a particular network operator).

The apparatus has a storage to store ownership-based access control information for the plurality of security modules, the ownership-based access control information identifying the owner of each security module and identifying which subscription management servers in the plurality of subscription management servers are allowed access to the security modules of each owner. This hence provides a fine grained level of information as to which subscription management servers are authorised by which owners and which security modules are owned by which owners. This can then be used to police requests received by particular subscription management servers.

In particular, the apparatus further has access control circuitry that is responsive to a request for a given subscription management server to have access to an identified security module in the plurality of security modules, to reference the ownership-based access control information in order to determine whether to allow the given subscription management server to access the identified security module. Hence, individual requests received from a subscription management server can be processed by the apparatus taking into account the owner of the security module being targeted by that request, and information identifying which subscription management servers are allowed access to the security modules of that owner. By providing this information in association with the apparatus, this significantly increases the opportunity for providing multi -tenanted systems, by allowing the freedom for different owners to set different access control rights but still share the same apparatus used to control access to their security modules.

The requests that are policed by the access control circuitry of the apparatus can take a variety of forms. In one example implementation, each security module has profile storage that is used to store one or more subscription profiles, where each subscription profile is associated with a network operator and used to control access via the security module to network infrastructure provided by that network operator. In such instances, the request for the given subscription management server to have access may be a profile download request seeking to provide the given subscription management server with access to the identified security module in order to enable the given subscription management server to download a subscription profile to the identified security module via the first interface circuitry. Hence, a plurality of different owners can have their security modules falling under the control of the same access control apparatus but authorise different entities to download profiles to those security modules via the apparatus.

The first interface of the apparatus can then be configured to provide a secure connection for the downloading of subscription profiles to the plurality of security modules, but with the access control circuitry policing the various download requests received, so as to ensure that a request to download a subscription profile to an identified security module is only allowed to proceed if the owner of that identified security module has authorised the entity that is issuing the download request.

The manner in which the various subscription profiles are stored within a security module may vary dependent on implementation. In one example implementation, each security module provides one or more security domains within the profile storage, where each security domain is used to host an associated subscription profile, and the subscription profile of an enabled security domain within a given security module is used to control access via that given security module to network infrastructure provided by the network operator with which the subscription profile of that enabled security domain is associated. Hence, at any point in time, a particular one of the security domains can be enabled, and then the associated subscription profile for that enabled security domain is used to control access to the network by the device that is using that security module.

In such implementations, the processing of the profile download request may require a new security domain to be established within the profile storage of the identified security module into which the given subscription management server will then download the subscription profile. The access control circuitry can then be arranged to be responsive to detecting from the ownership-based access control information that the given subscription management server has not been granted access to the identified security module by the owner of the identified security module, to prevent establishment of the new security domain within the profile storage of the identified security module. Hence, the new security domain will not be established, and the download of the new profile will be prevented.

Whilst in the above examples the given subscription management server that is issuing the request to access an identified security module may be a subscription management server used to download subscription profiles to the security module, the techniques described herein are not limited to use in association with such subscription management servers. For example, in one implementation the given subscription management server may be a server used to control access to a plurality of other security modules, and the request for the given subscription management server to have access is a transfer request issued by an issuing element to seek to transfer management of access control for the identified security module from the apparatus to the given subscription management server. The access control circuitry may then be responsive to the transfer request to prevent transfer of the management of access control for the identified security module unless the ownership-based access control information identifies that the issuing element has been granted a right to issue the transfer request by the owner of the identified security module. Hence, in this instance the request that is being processed may be a transfer request to actually move the security module from being under the control of the current apparatus to being under the control of another subscription management server. The issuing element that issues the transfer request may in one example implementation be the other subscription management server that is seeking to manage access control for the identified security module, or in an alternative implementation may be another element that issues that transfer request on behalf of the other subscription management server, for example a mobile network operator that has a profile downloaded on the identified security module and has been granted the right by the owner of the identified security module to issue such a transfer request . Again, the access control circuitry can police such a request, so that such a transfer will only occur if the owner of the identified security module has indicated that such a transfer of access control management should be allowed.

The ownership-based access control information stored in the storage of the apparatus can be maintained in a variety of ways. In one example implementation the apparatus has ownership information maintenance circuitry for maintaining such ownership-based access control information, and the ownership information maintenance circuitry is responsive to an authorisation request providing an owner indication and an indication of an identified subscription management server, to update the ownership- based access control information to indicate that the identified subscription management server is now allowed access to the security modules associated with the owner indicated by the owner indication. Hence, the ownership information maintenance circuitry can effectively maintain a list, by owner, of the various subscription management servers that are allowed to access the security module associated with that owner.

In order to increase flexibility, at least one security module owning party may be allocated multiple owner indications to allow the ownership-based access control information to be set separately for different subsets of security modules owned by that security module owning party.

Hence, by way of example, in such a situation the authorisation request may provide, as said owner indication, an owner identifier for the security module owning party and a type indication associated with a given subset of security modules owned by that security module owning party. The ownership-based access control information can then be stored for each combination of owner identifier and type indication provided for that owner identifier. In one example implementation, the identified subscription management server to which the authorisation request relates may be indicated by a subscription management server value provided in the authorisation request. Thus, in one implementation, separate authorisation requests may be issued by an owner for each subscription management server that it wishes to authorise to access its security modules. However, in one example implementation, a predetermined value can be reserved that can be associated with multiple subscription management servers. For example, when the subscription management server value has a predetermined value, the ownership information maintenance circuitry may be responsive to the authorisation request to update the ownership-based access control information to indicate that all of the plurality of subscription management servers are now allowed access to the security modules associated with the owner indicated by the owner indication. By such an approach, this enables a single authorisation request to be used to authorise all of the subscription management servers to be allowed access to the security modules of a particular owner.

In some implementations, the authorisation request may further comprise at least one additional item of information pertaining to the access being granted by the authorisation request. For example, such an additional item of information may indicate a duration for which the access is being granted. By such an approach, this enables the granting of such access to have an associated lifetime, after which that access right will expire. As another example of such an additional item of information, one or more types of access that are being granted by the authorisation request may be specified. For example, it may be the case that in principle a particular subscription management server may seek to access a security module to perform one of a number of different activities, and it may be that not all of those activities are to be authorised. Hence, the authorisation request can in those instances be used to identify exactly which types of access are to be granted.

As mentioned above, in some instances an access that is granted by an authorisation request may be time limited, so that it naturally expires after a period of time. However, if desired, rather than relying on expiry of the access after a period of time, the ownership information maintenance circuitry may be responsive to a deauthorisation request providing an owner indication and an identified subscription management server, to update the ownership-based access control information to indicate that the identified subscription management server is no longer allowed access to the security modules associated with the owner indicated by the owner indication. Hence, access rights can be positively removed after they have been granted if desired.

The authorisation requests may be issued from a variety of entities within the system, but in one example implementation such authorisation requests are issued by the owner associated with the owner indication specified in the authorisation request.

In addition to using the above described authorisation requests as a way of updating the ownership-based access control information, the ownership information maintenance circuitry can also be responsive to other types of request. For example, when a given security module is allocated to the apparatus to form one of the plurality of security modules, the ownership information maintenance circuitry may be responsive to a registration request identifying the given security module and providing an owner indication, to update the ownership-based access control information to identify the owner of the given security module. Hence, at the time a given security module is registered with the apparatus, its owner can be identified in the registration request, such that the owner can be identified in the ownership-based accessed control information at that point. In one example implementation, one or more authorisation requests can then be used in addition to identify which subscription management servers are being authorised by that owner.

In a similar way to discussed earlier with reference to the authorisation request, a particular owner may have more than one owner indication, so as to allow access rights to be set for particular subsets of security modules owned by that owner. Hence, the registration request may provide, as the owner indication, an owner identifier for a security module owning party and a type indication associated with a given subset of security modules owned by that security module owning party.

The registration request can be issued via a variety of entities within the system, but in one example is issued by a manufacturer of the given security module.

In some instances, the request for the given subscription management server to have access may provide an identified owner of the given subscription management server. In one example implementation, this additional information can enable some of the checks performed by the access control circuitry to be bypassed in certain instances. In particular, the access control circuitry may be arranged to grant the given subscription management server access to the identified security module when the identified security module is also owned by that identified owner, without positively needing to check the ownership-based access control information. In particular, it is assumed that if the subscription management server is owned by the party that also owns the security module, then an access by that subscription management server is to be allowed.

The security modules can take a variety of forms. Whilst traditionally a security module may be a separate smart card inserted into a device, which may for example provide a single predetermined subscription profile, it is becoming more common for such a security module to be embedded within the device at manufacture, and to be capable of hosting multiple profiles in associated security domains. For example, the security module may be an embedded UICC (eUICC) where the UICC is provided as a chip mounted onto the circuit board of a device, or an integrated UICC (iUICC) incorporated as one of the modules within a System-on-Chip (SoC).

In one example implementation, the storage may be further arranged to store profile management information identifying the network operator associated with each subscription profile and an indication of one or more entities allowed to perform at least one management operation on the subscription profiles of each network operator. Such profile management information hence allows a network operator to devolve certain profile management operations to other entities if desired. The ability to specify such profile management information is discussed with reference to Profile Lifecycle Management Authorisations (PLMAs) in the GSMA Official Document SGP.02- “Remote Provisioning Architecture of Embedded UICC Technical Specification”, Version 4, dated 25 February 2019. This allows some basic commands to be performed in respect of subscription profiles stored on a security module (for example enable, disable, update or delete) but assumes that those subscription profiles are already present on the security module. However, as will be apparent from the earlier discussion, an issue that can arise is how to control the ability to download those subscription profiles in the first place, and the techniques described herein enable such control to be achieved through the use of the earlier-discussed ownership-based access control information, thereby allowing security modules for multiple different owners to fall under the control of a single access control apparatus whilst enabling the individual owners to specify which subscription management servers are allowed access to their security modules. As will be apparent from the above discussion, in order to maintain the ownership-based access control information, one or more entities may be arranged to issue requests to the apparatus, for example the earlier-discussed authorisation requests and registration requests. Hence, for example, a device operated by an owner of a first security module may comprise access determination circuitry that is used to determine which of a plurality of subscription management servers the owner wishes to grant access to the first security module. That device can then be provided with a communication interface to issue an authorisation request, providing an owner indication and an indication of an identified subscription management server, to an apparatus used to establish connections with a plurality of security modules that includes the first security module, to enable the apparatus to allow the identified subscription management server to have access to the first security module via the apparatus when the apparatus receives a request for access from the identified subscription management server.

Similarly, a device operated by a manufacturer of a first security module may comprise owner determination circuitry to determine an owner for the first security module, and a communication interface that is arranged, when the first security module is allocated to an apparatus used to establish connections with a plurality of security modules, to issue a registration request to the apparatus identifying the first security module and providing an owner indication, to cause the apparatus to update ownership- based access control information stored therein in order to identify the owner of the first security module.

Particular examples will now be described with reference to the Figures.

Figure 1 is a block diagram of a system in accordance with one example arrangement. An access control apparatus 10 is provided for controlling access to a plurality of security modules 22, 24, 26 within a group 20 of security modules falling under the control of the apparatus 10. Each security module will typically be registered with the apparatus 10, and thereafter the apparatus 10 can be used to control access to each registered security module by one or more other entities within the system. For the purposes of the following description, each security module will be considered to be a Universal Integrated Circuit Card (UICC) and particular will be considered to be an embedded UICC or an integrated UICC that is capable of storing a plurality of subscription profiles, where each subscription profile is associated with a network operator.

Such security modules are being used in a wide variety of different devices, as it becomes more and more common to connect individual devices to networks in order to facilitate reporting of information by those devices, and performance of certain management operations in respect of those devices. Hence, whilst such security modules may traditionally have been owned by mobile network operators, with the advent of the Internet of Things (IoT), allowing the possibility for a wide variety of devices to be provided with connectivity to a network, such security modules are now being owned by a wider variety of different entities. Purely by way of example, a smart card company may own security modules which can be located in their energy meters to report back information to the smart meter company.

However, the relevant Telecommunications Standards controlling the use of security modules such as UICCs requires very stringent controls over those security modules, including the manner in which they are accessed. For example, the GSMA Standards define how an access control apparatus such as the apparatus 10 shown in Figure 1 should function, in accordance with the GSMA Standards such an apparatus being referred to as a Subscription Manager Secure Routing (SM-SR) apparatus or server. The SM-SR server 10 is used to establish secure connections with the various security modules registered with it via an intervening communication network 30. To comply with the GSMA’s SAS-SM (Security Accreditation Scheme for Subscription Management), data within an SM-SR server is subject to the highest standards of integrity and confidentiality. This requires the use of hardware security modules (HSMs) 72, which are extremely expensive items of equipment. This expense can be further compounded by additional instances required to comply with service level agreements (SLAs) relating to high availability, business continuity and disaster recovery.

Whilst such an SM-SR server might traditionally be under the control of a particular network operator, and used to manage connections to that network operator’s UICCs, as the diversity of owners of UICCs increases, then it can become impractical for those individual owners to provide their own SM-SR server. Accordingly, it would be desirable to support a multi-tenant system, where a single SM-SR server can be used to control access to a plurality of security modules that are not all owned by the same owning entity. The techniques described herein aim to assist in the development of such multi-tenant systems, by supporting the ability for individual owners to control which other entities within the system are to be given access rights to their security modules.

As discussed earlier, modern embedded or integrated UICCs are able to store a plurality of different subscription profiles, and these subscription profiles can be downloaded from other components within the system. In particular, in accordance with the above mentioned GSMA Standards, a Subscription Manager Data Preparation (SM-DP) server can be used to download profiles to security modules via the SM-SR server that controls access to those security modules. As shown in Figure 1, the system may include a variety of different profile download servers 45, for example the particular subscription management servers 50, 52, 54 (SM-DP servers) shown in Figure 1. Whilst some of those subscription management servers may be owned by particular mobile network operators, as for example is the case for the two servers 50, 52 shown in Figure 1, other subscription management servers may be owned by other entities, for example a service provider, as for example is the case for the server 54. As mentioned earlier, an owner of a device incorporating a security module may enter into an agreement with a service provider rather than a specific mobile network operator, with the service provider then downloading appropriate subscription profiles to that owner’s security module, for example taking into account the jurisdiction in which the device incorporating the security module is deployed.

The SM-SR server may include a first interface 15 via which it establishes secure communications with the security modules 22, 24, 26 falling under its control, and may also have a second interface 35 via which it can communicate with devices such as the profile download servers 45. As shown in Figure 1 for example, via the second interface the SM-SR server may communicate over the Internet 40 with such profile download servers 45, and hence can receive requests from those profile download servers seeking to download a profile to an identified one of the security modules 22, 24, 26. Such requests can be received by access control circuitry 60, which can then establish a secure connection with the relevant security module 22, 24, 26 via the first interface and the communication network 30, in order to allow a download of a profile to that security module.

However, it may be that an owner of particular security modules may wish to restrict which profile download servers are able to interact with its security modules. Further it may be the case that different owners have different requirements in this respect, and accordingly in a multi-tenanted system it would not be possible for the access control circuitry 60 to apply a global set of rules that would apply to all of the security modules under its control. In accordance with the techniques described herein, the SM-SR server is adapted so that it is able to maintain ownership-based access control information 70 that can be referenced by the access control circuitry 60 when processing individual requests from external entities such as the profile download servers 45. This enables the access control circuitry 60 to control access to an individual security module taking into account the owner of that security module, and an indication as to whether that owner has authorised the entity making the request to access its security modules.

As will be discussed in more detail later, at the time an individual security module is registered with the SM-SR server 10, then a registration request can be submitted via the Internet 40 to the second interface 35 providing certain information about the security module being registered. Such a registration request can be passed to the ownership information maintenance circuitry 65 for processing. Such a registration request could in principle come from a number of different entities within the system, but as shown in Figure 1 in one example implementation the security module manufacturer (referred to in the GSMA Standards as the EUM (eUICC manufacturer)) may be arranged to issue the registration request. The registration request can take a variety of forms, but in one example is formed by supplementing a RegisterEis request provided by the GSMA Standards. Such a request can provide a variety of information about a security module (also referred to herein as a card), for example metadata including free memory, bootstrap profile details, etc. Also included may be symmetric keys which can be used to open a secure channel between the SM- SR and the card, such symmetric keys being stored within the HSM 72 of the SM-SR server. In addition, an extensibility point may be provided within the request to specify additional properties. When employing a multi -tenanted system, then an eSIM owner value could be provided as such an additional property in order to identify the owner of the security module that is being registered. Whilst an individual owner may be provided with only a single owner indication value, if desired the owner indication can include both an owner identifier and a type indication associated with a given subset of the security modules owned by that security module owning party. By allowing an individual owner to have more than one owner indication, this allows that owner to set up different access rules for different subsets of the security modules that it owns.

When such a registration request is received by the ownership information maintenance circuitry 65, it can extract the owner information and add it to the ownership-based access control information 70. In particular, it can identify that the security module being registered by the registration request is owned by the particular owner identified within the registration request. By such a process, it will be appreciated that the SM-SR server can maintain a record of which security modules are owned by which owners.

In addition, in order to be able to apply different access constraints to different security modules dependent on their ownership, it is necessary for the ownership- based access control information 70 to be supplemented with such access constraint information. In one example implementation this is achieved through the issuance of authorisation requests to the SM-SR, whereby a particular owner can authorise a particular entity within the system to access its security modules. Whilst such authorisation requests could in principle be issued by a number of different entities, as shown in Figure 1 it is anticipated that the owning entities 75, 80 will issue such authorisation requests, which may be routed via the Internet 40 to the second interface 35 of the SM-SR server, where those requests are then passed on to the ownership information maintenance circuitry 65. As will be discussed in more detail later, an individual request might typically identify a single entity that is to be allowed access, and that information will be extracted from the request, and then used to modify the ownership-based access control information. For example, if owner A issues an authorisation request authorising the subscription management server 50 to access its security modules, then the ownership-based access control information can be supplemented to identify that owner A has allowed subscription management server 50 to access its security modules.

Accordingly, it will be appreciated that when one of the profile download servers 45 issues a request to access a particular security module, the access control circuitry 60 can access the ownership-based access control information to determine who the owner of the targeted security module is, and whether that owner has authorised the profile download server that is making the request. The access control circuitry can then prevent the access if desired, in the event that the profile download server making the request is not authorised by the owner of the security module.

Whilst for the above explanation, consideration has been given to the issue of downloading new profiles to security modules, the mechanism can be used to police various different types of the access that may sought to be made in respect of security modules by other entities within the system, and indeed the authorisation request can, if desired, specify the type of access that is being authorised.

Purely by way of example of another entity that may wish to access a security module falling under the control of the SM-SR server 10, another subscription management server for secure connection management 56 may be provided, which could for example be another SM-SR server. Such a server 56 may issue a request to the SM-SR server 10 identifying a particular security module, in effect requesting that the control of access to that security module is migrated from the current SM-SR server 10 to the requesting server 56 (such a request also being referred to herein as a swap request or a transfer request). Again, individual owners can, through the use of the authorisation request, identify whether such a migration is to be allowed, and accordingly the SM-SR server 10 can reference the ownership-based access control information 70 when deciding whether to grant the access to the security module being requested by the server 56.

In another example implementation, the authorisation request issued by an owner might grant another element, such as a mobile network operator, the right to issue such a swap request. This could for example be a particular mobile network operator that has a profile downloaded on the security module in question. The swap request would then be issued by the mobile network operator entity (e.g. element 90 in Figure 1) to the subscription management server 10, identifying the target subscription management server 56, and when the access control circuitry 60 determines with reference to the ownership-based access control information 70 that such a transfer is allowed, the subscription management server 10 may contact the subscription management server 56 to initiate the transfer of the particular security module.

Herein, the authorisation requests issued by the owning devices 75, 80 may be referred to as eSIM Lifecycle Management Authorisations (ELMAs). Such ELMAs can be used to develop an ownership-based access control database within an SM-SR server that is used to control access to multiple security modules that are not all owned by the same owning party, so that the ability to access a security module can be policed taking into account which entities within the system have been authorised by the relevant owner to access that security module.

In the GSMA official document SGP.02-“Remote Provisioning Architecture for Embedded UICC Technical Specification”, Version 4.0, 25 February 2019, another form of authorisation is described that can be issued by a mobile network operator to control the extent to which parties other than the mobile network operator may perform functions on subscription profiles of that mobile network operator. Such authorisations are referred to as Profile Lifecycle Management Authorisations (PLMAs) in the above document, and can if desired be used in addition to the ELMAs described herein. In particular, PLMAs can be viewed as an entirely orthogonal set of authorisations, relating to the activities that can be undertaken in respect of particular subscription profiles, whereas the ELMAs described herein relate to control of access to particular security modules, irrespective of the subscription profiles stored thereon, and take into account access rights granted by the owners of those individual security modules. Both ELMAs and PLMAs can be processed independently within a system such as shown in Figure 1 and hence the introduction of the ELMA feature described herein does not impact on the ability to use existing functions defined by the GSMA Standards. Hence, as shown in Figure 1, a network operator 90 may issue a PLMA request to the SM-SR server, whereby that network operator can grant authorisation to a service provider to perform certain operations, or receive certain notifications, related to one or more subscription profiles of that mobile network operator. This could for example allow a service provider to perform certain basic functions in respect of a profile, such as enabling the profile, disabling the profile, updating the profile or deleting the profile.

However, the ELMA mechanism described herein is not concerned with the management of the profiles themselves, but instead enables the SM-SR to maintain information about the actual ownership of individual security modules, irrespective of the subscription profiles stored thereon, and in particular allows an owner to constrain which entities within the system are able to access its security modules. Such a mechanism hence significantly improves the feasibility of providing multi -tenanted systems, by allowing for the recognition of an entity with overall ownership responsibility for a security module. Whilst the PLMA mechanism described in the above mentioned GSMA Standard introduces the possibility for a profile to be operated on by a party other than the issuing mobile network operator, no formal mechanism was provided for controlling the download of such profiles on to a security module in the first place. However, through use of the ELMA techniques described herein, it is possible to capture ownership information about each security module, and further capture information about which entities within the system have been authorised to access each owner’s security modules. Such information can then for example be used by the access control circuitry 60 to control which entities within the system are allowed to download subscription profiles on to a security module owned by a particular owner.

Figure 2 is a diagram schematically illustrating a security module 100, in this example a eUICC. The security module 100 includes profile storage 102 in which to store a plurality of subscription profiles. In particular, security domains 105, 110, 115 can be established within the profile storage 102, where each security domain is used to host an associated subscription profile. The subscription profile of an enabled security domain within the security module is then used to control access via that security module to network infrastructure provided by the network operator with which the subscription profile of that enabled security domain is associated. When a profile download request is received by the SM-SR server 10 from one of the profile download servers 45, this may require a new security domain to be established within the profile storage 102, whereafter the subscription profile is downloaded into that security domain. In accordance with the GSMA terminology, such a security domain may be referred to as an Issuer Security Domain Profile (ISD-P).

As shown in Figure 2, an Issuer Security Domain Root (ISD-R) element 125 can be provided to communicate with the SM-SR 10 in order to establish the secure communication used when downloading a profile to the device. The ISD-R element will hence for example create a new ISD-P when a new profile is to be downloaded.

The ECASD (eUICC Controlling Authority Security Domain) element 120 is arranged to establish a trust route with the relevant profile download server during the download process, and can for example be used to authenticate profiles being downloaded to the security module 100. One of its functions is to establish key sets during the profile download process.

Figure 3 is a diagram illustrating the form of the ownership-based access control information maintained within the database 70 of the SM-SR server 10 in accordance with one example implementation. Whilst the information can be logically stored in a variety of ways, it can be viewed as being formed of two tables. A first table 150 maintains within a field 155 a record of the security module identifier (ID) for each of the security modules falling under the control of the SM-SR server 10, whilst an owner indication field 160 then provides ownership information for the security module identified by each security module ID. There may be one owner ID for each owner, and the owner ID may by itself form the owner indication. However, as discussed earlier, it is possible in some implementations to give an individual owner more than one owner indication, and in particular the owner indication in that event will be formed by both the owner ID and an optional type indication, effectively enabling security modules owned by an owner to be grouped into particular subsets. As will be apparent from the earlier discussion of Figure 1, the information populated within the table 150 can be maintained in response to registration requests received by the SM-SR server 10.

As also shown in Figure 3, a further table 170 can be maintained that provides an owner indication field 175, populated with the same information as in the owner indication field 160 of the first table 150. In addition, for each owner indication, a list can be maintained of the subscription management servers that have been authorised by that owner to access that owner’s security modules. Hence, as shown in Figure 3, in one implementation there may be a separate sub-field provided for each possible subscription management server (in this example it being assumed that there are N subscription management servers). As a particular owner issues an authorisation request authorising a particular subscription management server, then the corresponding field in the table 170 can be set. It will be appreciated from the earlier discussion of Figure 1 that the table 170 may be populated in response to authorisation requests issued by the various owning entities.

In situations where the authorisation requests provide additional information relevant to the authorisation being granted, such as the types of access being authorised or any additional properties such as the duration of the authorisation (as will for example be discussed later with reference to Figure 5 A), then table 170 can be expanded in order to capture that additional information in respect of each server that has been authorised.

Figure 4A schematically illustrates fields that may be provided within a registration request 200, which as discussed earlier in one example may be implemented by adding further information to a RegisterEis call from an EUM to the SM-SR server 10. As shown in Figure 4A, a request 200 will include a field 205 identifying a security module ID for the security module that is being registered. One or more fields 210 will then provide certain metadata such as free memory, bootstrap profile details, etc. Symmetric keys can then be specified within the field 215, which are used to enable a secure channel to be established between the SM-SR and the security module. In particular, the security module will hold those keys, and those keys will also be registered with the HSM 72 within the SM-SR server 10 as part of the registration process.

An additional properties field 220 will also be provided, and in accordance with the implementations described herein can be used to hold an owner ID, and optionally type information used to encode the owner indication, i.e. identify the owner of the security module being registered.

Figure 4B is a flow diagram illustrating a process performed by the SM-SR server 10 upon receipt of such a registration request. In particular, once a registration request is received at step 250, then the details of the security module are stored within the SM-SR server. These will for example include the metadata discussed earlier with reference to the field 210. The HSM will also be updated to store the symmetric keys at step 260. However, in addition to these two standard steps 255 and 260 associated with a registration request, at step 265 an entry is also made in the ownership-based access control information 70 to identify the security module ID and the associated owner indication (which as discussed earlier will include at least an owner ID and may optionally include type information). Accordingly, with reference to Figure 3, it will be seen that a row in the table 150 is populated at step 265 to identify the security module being registered.

Figure 5A is a diagram schematically illustrating fields provided within an authorisation request (which as discussed earlier can also be referred to herein as an ELMA request). A first field 305 provides an owner indication, which will include at least an owner ID and optionally also type information. A second field 310 will provide an indication of the subscription management server that is being authorised by the request. Typically, this will be a specific value identifying one of the possible subscription management servers 50, 52, 54, 56 within the system. However, in one example implementation, a predetermined value will be reserved for use in this field, and if that predetermined value is used, this indicates that all of the subscription management servers within the system are being authorised.

Optionally, a further field 315 can be used to identify the types of access that are being authorised. In particular, the mechanism described herein can be used if desired to police multiple different types of access. For example, whilst in one example implementation it could be used solely to police profile download functions, in which case there may be no need for a type of access to be identified in a separate field, in another implementation it could be used to additionally control various other accesses that may be performed by entities within the system, and in that event the types of access being authorised by the ELMA request can be specified within the request. If desired, one or more additional properties can be provided within one or more additional fields 320. These could for example be used to specify a duration for which the authorisation is active, so that after that period has elapsed the authorisation will lapse, and the access right will no longer be granted.

Figure 5B provides a more detailed specific implementation of the authorisation request illustrated schematically in Figure 5A. In particular, this figure shows the type of data that may be stored within each field or sub-field, an indication of the size of each field, and whether that field is mandatory (M) or optional (O).

Figure 5C is a flow diagram illustrating steps taken by the SM-SR server 10 upon receipt of an authorisation request. Once an authorisation request is received at step 350, then the owner indication information is extracted at step 355, as is the indication of the authorised subscription management server. Thereafter, at step 360, the list of authorised subscription management servers allowed to access the security modules associated with the owner indication is updated. With reference to Figure 3, it will be appreciated that this may involve identifying the row within the table 170 that matches the owner indication information, and then setting the relevant field associated with the subscription management server that is being authorised by the request. If the authorisation request is a first request pertaining to the particular owner indication, then it may be necessary at that stage to populate a new row within the table 170 to identify the owner indication information, and then set the appropriate field within the row to identify the subscription management server that is being authorised. As discussed earlier, if a predetermined value is provided within the field 310, then this may indicate that all of the subscription management servers are allowed, and hence all of the fields within the relevant row of the table 170 may be set.

As indicated at step 365 certain optional information may also be captured in the ownership-based access control information, for example the type of access allowed, or duration/expiry information, where that information is provided within the authorisation request. That additional information can also be referred to by the access control circuitry 60 when processing any particular request made by a subscription management server for access to a particular security module.

Figure 6 is a flow diagram illustrating the steps performed by the SM-SR server 10 upon receipt of an access request from a subscription management server within the system, seeking to access a specified security module. At step 400, receipt of such an access request is awaited. As discussed earlier, such an access request may be a profile download request, for example from one of the profile download servers 50, 52, 54, but in principle could be another type of request, such as a swap request from the subscription management server 56 seeking to migrate access control for the specified security module from the current SM-SR server 10 to the server 56. As mentioned earlier, such a swap request could also be issued by another entity on behalf of the subscription management server 56.

Once an access request is received, then at step 405 the security module that is sought to be accessed is determined from the access request, as is the subscription management server that is making the access request. Then, at step 410 the owner for the identified security module is determined with reference to the ownership-based access control information. Hence, considering the specific example of Figure 3, it will be appreciated that the table 150 can be accessed using the determined security module ID, in order to derive the owner indication.

Once the owner indication has been determined, then at step 415 the allowed subscription management servers associated with the identified owner can be determined. Again with reference to Figure 3, this can be determined by accessing the relevant row within the table 170.

Thereafter, at step 420 it is determined whether the subscription management server making the request is allowed to perform the access requested. If so, then the process proceeds to step 425 where the request is allowed to proceed, but otherwise the request is rejected at step 430.

Figure 7 is a flow diagram illustrating a particular implementation of the process described with reference to Figure 6, for the situation where the request is seeking to download a new profile, and assuming the system conforms to the GSMA Standard. At step 450, an incoming Create ISD-P web service request is received, this being a request seeking to download a subscription profile to a security module identified within the request. At step 455, it is determined whether the mobile network operator identifier is provided in the request. In particular, in accordance with version 4 of the GSMA Standard, such a request should include a mobile network operator ID, and in particular the request will not just merely identify the SM-DP server that is making the request, but also identify the mobile network operator on behalf of which that server is acting.

If a mobile network operator identifier is provided, then the process can proceed to step 460, where it can be checked whether the targeted security module is also owned by that same mobile network operator. In particular, this can be derived by looking in the table 150 of Figure 3. Assuming the identified mobile network operator is the same as the mobile network operator owning the security module, then the process merely proceeds to step 475 where the download process is allowed to continue. In particular, it is assumed that a request that has effectively been authorised directly by the mobile network operator should be allowed to proceed without needing to perform any additional checks.

However, if the mobile network operator does not match at step 460, then the process proceeds to step 465, where the above described checks with reference to the table 170 forming part of the ownership-based access control information is performed. As also shown in Figure 7, if the original request did not include a mobile network operator identifier, for example because the request was not version 4 compliant with respect to the GSMA Standard, then the process also proceeds directly to step 465. At this point, the owner of the targeted security module is determined with reference to the table 150, and then the table 170 is referenced in order to determine whether the entity requesting to perform the download has been authorised. As shown in Figure 7, the smdp-id information identifies the SM-DP and corresponding information can be stored in the table 170 in order to allow determination as to whether the requesting subscription management server is authorised. However, in accordance with the V4 Standard, the request can also provide a service provider identifier (referred to in the figure as an m2m-spid) and that information can also be captured within the table 170 to identify the requesting subscription management server. In one example implementation, a specific form of the authorisation request can authorise all service providers to initiate download requests.

As shown in Figure 7, if the ELMA check is passed at step 465, then the download procedure proceeds at step 475, whereas otherwise it is rejected at step 470.

Figure 8 is a block diagram schematically illustrating components provided within an authorisation request issuing device 500, such as the devices 75, 80 shown in Figure 1. The device 500 includes access determination circuitry 510 for determining which of a plurality of subscription management servers the owner wishes to grant access to its security modules. In one embodiment, the device 500 is operated by the owner, and accordingly the owner’s requirements with regards to accessibility to its security modules by subscription management servers can be input into the device for processing by the access determination circuitry 510. This information can then be populated into an authorisation request which is issued via the communication interface 520 for receipt by the SM-SR server 10. Any suitable communication interface can be used, and as shown in Figure 1 in one example the request is propagated via the Internet 40 to the second interface 35 of the SM-SR server 10, after which it is processed in order to update the ownership-based access control information.

Figure 9 similarly shows components provided within a registration request issuing device 530, which may for example take the form of the security module manufacturer device 85. At the time a new security module is to be registered with the SM-SR server 10, then owner determination circuitry 540 is used to determine the owner of that security module, and to form a registration request which is then output via the communication interface 550 to the SM-SR server 10. Again, any suitable communication network can be used, but as shown in Figure 1 such a request may be routed via the Internet 40 to the second interface 35 of the SM-SR server 10, where it is then used to update the contents of the ownership-based access control information 70.

Whilst in the above described examples, the authorisation requests are used to specifically grant rights to particular subscription management servers, if desired equivalent de-authorisation requests can also be provided, in order to allow an owner to remove an authorisation of one or more subscription management servers if desired. This can be used as an additional mechanism to, or instead of, the use of the duration mechanism provided with authorisation requests, in order to constrain the extent to which authorisations are granted.

The above described techniques provide a mechanism that allows for the recognition of an entity with overall ownership rights for particular security modules, and in particular allows such an entity to qualify which other entities within the system should be allowed to access its security modules via an associated access control server, such an SM-SR server as provided by the GSMA Standard. The mechanisms described herein can be provided in a way that is additive to the existing GSMA techniques, and hence will not interfere with existing mechanisms already provided by the GSMA Standard. Through the use of such a mechanism as described herein, this improves the feasibility of deploying multi -tenanted systems, allowing the costs associated with the provision of SM-SR servers to be amortised across multiple owners. For example, the costs of HSMs can be shared across multiple owners (who can become customers for the entity providing the SM-SR). Further, efficiencies in hardware and software licensing expenditure can be realised by mutualising the costs for database technologies and application servers, etc. In addition to direct costs, operational efficiencies can be gained from managing a single environment and maintaining a single version of software. Techniques such as elastic scaling to meet peak commands and avoiding redundant capacity are also made more achievable.

In the present application, the words “configured to...” are used to mean that an element of an apparatus has a configuration able to carry out the defined operation. In this context, a “configuration” means an arrangement or manner of interconnection of hardware or software. For example, the apparatus may have dedicated hardware which provides the defined operation, or a processor or other processing device may be programmed to perform the function. “Configured to” does not imply that the apparatus element needs to be changed in any way in order to provide the defined operation.

Although illustrative embodiments of the invention have been described in detail herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various changes, additions and modifications can be effected therein by one skilled in the art without departing from the scope and spirit of the invention as defined by the appended claims. For example, various combinations of the features of the dependent claims could be made with the features of the independent claims without departing from the scope of the present invention.

Claims

1. An apparatus comprising: first interface circuitry to establish connections with a plurality of security modules, wherein at least one security module in said plurality of security modules has a different owner to at least one other security module in said plurality of security modules; second interface circuitry to establish communication with a plurality of subscription management servers; a storage to store ownership-based access control information for said plurality of security modules, the ownership-based access control information identifying the owner of each security module and identifying which subscription management servers in said plurality of subscription management servers are allowed access to the security modules of each owner; and access control circuitry responsive to a request for a given subscription management server to have access to an identified security module in said plurality of security modules, to reference the ownership-based access control information in order to determine whether to allow the given subscription management server to access the identified security module.

2. An apparatus as claimed in Claim 1, wherein: each security module has profile storage to store one or more subscription profiles, where each subscription profile is associated with a network operator and used to control access via the security module to network infrastructure provided by that network operator; and the request for the given subscription management server to have access is a profile download request seeking to provide the given subscription management server with access to the identified security module in order to download a subscription profile to the identified security module via the first interface circuitry.

3. An apparatus as claimed in Claim 2, wherein the first interface is configured to provide a secure connection for the downloading of subscription profiles to the plurality of security modules.

4. An apparatus as claimed in Claim 2 or Claim 3, wherein: each security module provides one or more security domains within the profile storage, where each security domain is used to host an associated subscription profile, and the subscription profile of an enabled security domain within a given security module is used to control access via that given security module to network infrastructure provided by the network operator with which the subscription profile of that enabled security domain is associated.

5. An apparatus as claimed in Claim 4, wherein: processing of the profile download request requires a new security domain to be established within the profile storage of the identified security module into which the given subscription management server will then download the subscription profile; and the access control circuitry is responsive to detecting from the ownership-based access control information that the given subscription management server has not been granted access to the identified security module by the owner of the identified security module, to prevent establishment of the new security domain within the profile storage of the identified security module.

6. An apparatus as claimed in any preceding claim, wherein: the given subscription management server is a server used to control access to a plurality of other security modules, and the request for the given subscription management server to have access is a transfer request issued by an issuing element to seek to transfer management of access control for the identified security module from the apparatus to the given subscription management server; and the access control circuitry is responsive to the transfer request to prevent transfer of the management of access control for the identified security module unless the ownership-based access control information identifies that the issuing element has been granted a right to issue the transfer request by the owner of the identified security module.

7. An apparatus as claimed in any preceding claim, further comprising: ownership information maintenance circuitry to maintain the ownership-based access control information stored in the storage; wherein the ownership information maintenance circuitry is responsive to an authorisation request providing an owner indication and an indication of an identified subscription management server, to update the ownership-based access control information to indicate that the identified subscription management server is now allowed access to the security modules associated with the owner indicated by the owner indication.

8. An apparatus as claimed in Claim 7, wherein at least one security module owning party is allocated multiple owner indications to allow the ownership-based access control information to be set separately for different subsets of security modules owned by that security module owning party.

9. An apparatus as claimed in Claim 8, wherein the authorisation request provides, as said owner indication, an owner identifier for the security module owning party and a type indication associated with a given subset of security modules owned by that security module owning party.

10. An apparatus as claimed in any of claims 7 to 9, wherein: the identified subscription management server is indicated by a subscription management server value provided in the authorisation request; and when the subscription management server value has a predetermined value, the ownership information maintenance circuitry is responsive to the authorisation request to update the ownership-based access control information to indicate that all of the plurality of subscription management servers are now allowed access to the security modules associated with the owner indicated by the owner indication.

11. An apparatus as claimed in any of claims 7 to 10, wherein the authorisation request further comprises at least one additional item of information pertaining to the access being granted by the authorisation request.

12. An apparatus as claimed in Claim 11, wherein the at least one additional item of information indicates a duration for which the access is being granted.

13. An apparatus as claimed in Claim 11 or Claim 12, wherein the at least one additional item of information indicates one or more types of access that are being granted by the authorisation request.

14. An apparatus as claimed in any of claims 7 to 13, wherein the ownership information maintenance circuitry is responsive to a deauthorisation request providing an owner indication and an identified subscription management server, to update the ownership-based access control information to indicate that the identified subscription management server is no longer allowed access to the security modules associated with the owner indicated by the owner indication.

15. An apparatus as claimed in any of claims 7 to 14, wherein the authorisation request is issued by the owner associated with the owner indication.

16. An apparatus as claimed in any of claims 7 to 15, wherein when a given security module is allocated to the apparatus to form one of the plurality of security modules, the ownership information maintenance circuitry is responsive to a registration request identifying the given security module and providing an owner indication, to update the ownership-based access control information to identify the owner of the given security module.

17. An apparatus as claimed in Claim 16, wherein the registration request provides, as said owner indication, an owner identifier for a security module owning party and a type indication associated with a given subset of security modules owned by that security module owning party.

18. An apparatus as claimed in Claim 16 or Claim 17, wherein the registration request is issued by a manufacturer of the given security module.

19. An apparatus as claimed in any preceding claim, wherein when the request for the given subscription management server to have access provides an identified owner of the given subscription management server, the access control circuitry is arranged to grant the given subscription management server access to the identified security module when the identified security module is also owned by that identified owner.

20. An apparatus as claimed in any preceding claim, wherein each security modules is one of an embedded universal integrated-circuit card (eUICC) and an integrated UICC (iUICC) capable of storing a plurality of subscription profiles.

21. An apparatus as claimed in any preceding claim when dependent on Claim 2, wherein the storage is further arranged to store profile management information identifying the network operator associated with each subscription profile and an indication of one or more entities allowed to perform at least one management operation on the subscription profiles of each network operator.

22. A device operated by an owner of a first security module, comprising: access determination circuitry to determine which of a plurality of subscription management servers the owner wishes to grant access to the first security module; and a communication interface to issue an authorisation request, providing an owner indication and an indication of an identified subscription management server, to an apparatus used to establish connections with a plurality of security modules that includes the first security module, to enable the apparatus to allow the identified subscription management server to have access to the first security module via the apparatus when the apparatus receives a request for access from the identified subscription management server.

23. A device operated by a manufacturer of a first security module, comprising: owner determination circuitry to determine an owner for the first security module; and a communication interface arranged, when the first security module is allocated to an apparatus used to establish connections with a plurality of security modules, to issue a registration request to the apparatus identifying the first security module and providing an owner indication, to cause the apparatus to update ownership-based access control information stored therein in order to identify the owner of the first security module.

24. A method of operating an apparatus to control access to a plurality of security modules, comprising: employing first interface circuitry to establish connections with the plurality of security modules, wherein at least one security module in said plurality of security modules has a different owner to at least one other security module in said plurality of security modules; employing second interface circuitry to establish communication with a plurality of subscription management servers; storing ownership-based access control information for said plurality of security modules, the ownership-based access control information identifying the owner of each security module and identifying which subscription management servers in said plurality of subscription management servers are allowed access to the security modules of each owner; and responsive to a request for a given subscription management server to have access to an identified security module in said plurality of security modules, referencing the ownership-based access control information in order to determine whether to allow the given subscription management server to access the identified security module.