Do-It-Yourself eSIM RSP (part IV)

Now that you know about the ingredients of an RSP solution, let’s look at the tasks required to build a scalable, flexible and reliable RSP service for eSIM management.

 

Putting the infrastructure in place

This is where it starts and becomes only as complicated as you need it to be. Even a light-weight RSP software needs servers, racks, an HSM, storage and power back-up, as well as firewalls, backup tools and the like. All this must be installed in a secure site with things like CCTV, access control readers, fire and water protection equipment and so forth.

Alternatively, you create an account with an SAS-SM certified public cloud provider like Amazon AWS, Microsoft Azure or Google Cloud and order on-demand services with a couple of
clicks, spinning up your infrastructure near instantly.

 

Deploying the RSP system

Once the infrastructure is in place, you can start deploying the RSP staging system. This pre-production system is crucial for the lifetime of the RSP service since it remains accessible to your RSP software provider who will play a key role during deployment and service operation. The system fulfils vital functions during release testing and incident resolution but also for the initial SAS-SM audit before you have received the signed certificates for the final production system. The architecture digram below will vary depending on the service configuration that you decide to build.

 

The system requires the configuration of the following components:

  • Container Registry (Docker container storage)
  • Kubernetes Cluster (RSP Application cluster)
  • Worker Nodes for Kubernetes cluster (Virtual Machines)
  • Proxy Nodes (Virtual Machines)
  • Database Services
  • HSM (High Security Module)
  • Firewalls

Cluster management nodes are responsible for the entire cluster health and perform orchestration of all running services. The logging cluster can host Elasticsearch nodes to store system logs and provides access for the log monitoring software.

The HSM must be FIPS 140-2 level 3 certified (a standard required in many regulated industries that store and transfer sensitive information such as Banking, Health and Government institutions).

The RSP software is deployed in the form of containers in the virtual environment managed by the container management software. For the deployment to be performed efficiently, the right design of the software is essential.

This is hard to judge from outside the code and requires a software provider experienced with state-of-the-art cloud development and deployment practises. The following major elements should be covered. The software should be light-weight with a small application footprint, designed to have small memory and CPU usage, and a low usage of system resources in general. To achieve this, the software must avoid code bloat and have optimised algorithm efficiency. Rather than a one-time effort, this requires the right design from the start and continuous optimisation over all releases of the software.

Second, the software should be developed according to Continuous Integration (CI) principles. CI avoids the long release cycles of traditional software development practices. These are prone to a high risk of errors arising without developers noticing them, which makes it near impossible to correct them quickly and can lead to severe, prolonged service disruption.

Not least, as the final GSMA-certified production environment will be only accessible to your Ops team, you will want the software deployment process to be as straight forward and reliable as possible.

To achieve this, make sure your RSP software provider is following these principles:

  • Staging System as a cloned, scalable version of the production environment to avoid failures due to significant differences
  • Version Control to maintain a code repository
  • Build Automation for source code compilation
  • Self-testing to confirm - once the code is built - that it behaves as expected
  • Test Cases hat reproduce every identified bug
  • Fast & secure delivery making builds readily available to your Ops team

 

Integrating systems and processes

After the RSP solution is deployed, it is time to look at how service functions can be exposed to other systems. Each RSP deployment will have different requirements depending on the target service. GSMA has specified several interfaces to ensure all components within the eSIM ecosystem can exchange information in an interoperable, standardised way.

 

The scope of integration for the consumer solution is rather simple:

  • ES2+ interface is used by the MNO to order profile downloads and to receive operation notifications
  • ES12 and ES15 interfaces allow a device the automated discovery of a pre-registered profile, if the optional GSMA Discovery Service is to be used

The M2M solution requires a more extended integration:

  • EIS1 interface is used for provisioning of eSIM data to SM-SR
  • ES2 interface is employed by the MNO to order profile downloads from SM-DP and to pass profile state management commands to SM-SR
  • ES3 interface is an internal interface between SM-DP and SM-SR and only exposed when external RSP components are integrated
  • ES4 interface is used by the MNO or an associated IoT Service Provider to manage profile states and to configure eSIM parameters on SM-SR
  • ES7 interface enables the “SM-SR Change” procedure to move a provisioned eSIM device from one SM-SR to another (rarely used due to commercial complexities)

One key function for SM-DP(+) has not been specified by GSMA - the provisioning of MNO profiles - and is therefore performed utilising a proprietary interface. Since Mobile Network
Operators have established processes to manage subscriber personalisation data for SIM manufacturing, like network authentication keys, subscription identifiers, and network parameters, the RSP solution ideally supports a two-step procedure, that can mimic existing procedures. In a first step, a pre-developed profile template is imported into the RSP system. As a second step, the profile personalisation data are imported. The RSP system can then create the profiles for eSIM download by merging the template with the personalisation data.

Beyond the integration of GSMA-specified interfaces, there is a multitude of possibilities depending on the chosen business and service model. Your RSP software provider should expose a wide range of functions with REST (Representational State Transfer), that provides a simple method of accessing its services. For the system to be future-proof, choose a software provider that is capable to deliver customisation and new features based on an agile development process that allows for quick release and deployment cycles.

 

The GSMA security audit

Now is the time to perform the GSMA security audit that is necessary before you can request the signed certificates from the authorised Certificate Issuers (CI). This chapter provides a brief overview of the related assessment scheme, SAS-SM (Security Accreditation Scheme for Subscription Management).

SAS-SM covers the following activities within eSIM Remote Provisioning and Management:

  • eSIM life cycle and processes in the scope of SM-SR
  • Profile life cycle and processes in the scope of SM-DP and SM-DP+
  • SM-DS processes

Each system component involves specific assets that need to be protected. These assets can be of the following types:

  • Information (files, metadata, keys...)
  • Processes
  • Systems

All assets must be controlled and closely supervised to ensure secure storage and handling. To consider processes as being secure certain requirements must be met. These requirements are specified in the “SAS Consolidated Security Requirements” document and cover the following areas:

  • Policy, strategy, and documentation, including business continuity planning
  • Organisation and responsibility
  • Information
  • Personnel security
  • Physical security
  • Certificate and key management
  • Sensitive process data management
  • SM-DP, SM-SR, SM-DP+, and SM-DS service management
  • Computer and network management

As part of the audit, the RSP Service Provider must show that the requirements are met by established processes for which evidence of correct operation exists.

The GSMA audit procedure involves three phases:

  • Dry Audit: to obtain SAS-SM provisional certification valid for 9 months using test data
  • Wet Audit: to upgrade the provisional certification to full certification using live data
  • Renewal Audit: to maintain certification at the end of the full certification period

Audits for SAS-SM certification are conducted on behalf of GSMA by NCC Group and SRC Security Research & Consulting GmbH.

 

Going live with the production system

When the SAS-SM dry audit has been passed successfully, preparation of the live service can begin. The production system is deployed as a clone of the staging system and its firewalls are configured in line with the expected security level. The RSP Service Provider can now generate all needed system certificates and send the Certificate Signing Requests (CSR) to the designated Certificate Issuers. This implies a significant cost for the RSP Service Provider, an area currently lacking transparency. With more companies joining the list of certified RSP providers, however, there are signs that GSMA is going to adopt its rules to safeguard an equal-level playing field between established RSP providers and those entering the market.

Once the signed certificates have been installed in the production system, approval testing can be performed. It involves the following elements for the consumer RSP solution:

  • Open-market, eSIM capable consumer devices
  • MNO profile
  • MNO subscription personalisation data
  • Test cases

The M2M RSP solution additionally requires:

  • eSIM capable IoT device/modem (or eSIM in a removable form factor)
  • eSIM data for SM-SR provisioning
  • Destination Address for SM-SR
  • SMS-C (SMS Centre) link for SMS
  • APN (Access Point Name) for HTTPS

With the system approval testing completed successfully, the RSP Service Provider can start to on-board MNO customers – the RSP service is ready for live operation.

 

Go back





get in touch