eUICC Provisioning via Negotiated CI Database
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In the context of remote SIM provisioning, there is a challenge in managing embedded universal integrated circuit cards (eUICCs) where eSIM servers and eUICCs must trust a common certificate issuer (CI) for secure provisioning, but existing systems often stall or delay due to trust relationship issues between multiple CIs in the RSP ecosystem.
Innovation Solution
The solution involves establishing a negotiated database of trusted CIs between MNOs and eSIM server operators, which allows eSIM servers to select a trusted CI for provisioning by using a list of public key identifiers (PKIDs) derived from this database, ensuring mutual trust between the eSIM server and the eUICC during profile provisioning.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a single certificate issuer (CI) is used for authentication, then trust relationship is simplified, but system adaptability and versatility are reduced
Solution Approach 1:
The eSIM server is designed to support multiple CIs by maintaining a database of trusted CI identifiers and selecting an appropriate CI based on the eUICC's capabilities. This allows the server to function universally with different CIs while maintaining reliable authentication through the selected match.
Solution Approach 2:
The system performs preliminary matching between the eSIM server's trusted CI list and the eUICC's supported CI list before provisioning begins. This advance compatibility check ensures that a mutual CI is identified in advance, preventing authentication failures during the provisioning process.
2Adaptability or versatility
If multiple certificate issuers (CIs) are supported, then system adaptability and versatility are improved, but device complexity and information loss increase
Solution Approach 1:
The system segments the CI management into two distinct components: the eSIM server maintains a database of multiple trusted CI identifiers, while the eUICC stores its supported CI identifiers. This segmentation allows each component to manage CIs independently, reducing overall system complexity while maintaining versatility.
Solution Approach 2:
The activation code acts as an intermediary that carries the eUICC's supported CI identifiers to the eSIM server. This intermediary mechanism simplifies the information exchange process, allowing the server to efficiently match CIs without complex direct communication protocols between eSIM and eUICC.
3Reliability
If CI matching is performed during provisioning, then authentication reliability is improved, but provisioning time and transaction delays increase
Solution Approach 1:
The CI matching process is performed as a preliminary step at the beginning of the provisioning flow, before any profile data is transferred. By identifying the mutual CI early in the process, the system avoids repeated authentication attempts and delays that would occur if matching were performed later in the provisioning sequence.
Solution Approach 2:
The eUICC actively provides its supported CI identifiers to the eSIM server during the initial connection. This self-service approach allows the server to quickly determine compatibility without needing to query or test multiple CIs sequentially, significantly reducing the time required for CI matching.
Data Source
AI summary
Embodiments provided herein identify a certificate issuer (CI) to be relied on as a trusted third party by an electronic subscriber identity module (eSIM) server in remote SIM provisioning (RSP) transactions with an embedded universal integrated circuit card (eUICC). In an RSP ecosystem, multiple CIs may exist. Parties rely on public key infrastructure (PKI) techniques for establishment of trust. Trust may be established based on a trusted third party such as a CI. Parties need to agree on the CI in order for some PKI techniques to be useful. Embodiments provided herein describe approaches for an eUICC and an eSIM server to arrive at an agreed-on CI. Candidate or negotiated CIs may be indicated on a public key identifier (PKID) list. A PKID list is distributed, in some embodiments, by means of a discovery server, via an activation code (AC) and/or during the establishment of a profile provisioning session.