Logical Secure Element Access Control on Shared Secure Hardware
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Mobile devices face challenges in efficiently supporting multiple secure elements from different Security Service Providers (SSPs) without increasing hardware footprint and cost, as physically swapping secure elements is inconvenient and risky, and integrating multiple physical slots complicates hardware design.
Innovation Solution
Implementing a firmware component on a single secure hardware platform to manage multiple logical secure elements (LSEs), using a mapping table and cryptographic keys to enforce security and isolation, allowing seamless switching between LSEs without additional hardware resources.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If multiple physical secure element slots are integrated into mobile devices to support multiple secure elements from different SSPs, then the device can access multiple security services simultaneously, but the hardware footprint and manufacturing cost increase significantly
Solution Approach 1:
A single secure element hardware platform is designed to perform multiple functions by hosting multiple logical secure elements (LSEs) from different SSPs. The firmware component enables the hardware to dynamically switch between different LSEs, allowing one physical slot to replace multiple physical slots while maintaining the ability to access various security services.
Solution Approach 2:
Multiple logical secure elements are created as virtual instances on a single physical secure element hardware platform. Each LSE is a software-based representation that mimics the functionality of a physical secure element, allowing multiple secure elements to coexist and be accessed sequentially through firmware management without requiring multiple physical copies.
2Ease of operation
If multiple physical secure element slots are provided in mobile devices, then users can physically swap between different secure elements, but the device complexity and manufacturing cost increase
Solution Approach 1:
The mechanical system of physically swapping secure element chips between multiple slots is replaced with a software-based system. The firmware component manages switching between multiple logical secure elements through software commands, eliminating the need for multiple physical slots and the associated mechanical complexity while maintaining the operational capability to switch between different secure elements.
3Area of stationary object
If a single secure element hardware platform hosts multiple logical secure elements, then hardware footprint is reduced, but security isolation and access control between different LSEs must be enforced
Solution Approach 1:
The single secure element hardware platform is logically segmented into multiple isolated logical secure elements. The firmware component implements segmentation by creating distinct virtual environments for each LSE, ensuring that each LSE operates in an isolated security context with its own access controls and permissions, preventing unauthorized cross-access between different SSPs.
Solution Approach 2:
The firmware component acts as an intermediary layer between the physical secure element hardware and multiple logical secure elements. It manages access control, authentication, and isolation between LSEs, mediating all interactions to ensure security requirements are met while enabling multiple secure elements to share the same hardware platform.
Data Source
AI summary
Techniques are described herein for applying access controls to logical secure elements (LSEs) running on the same secure element hardware platform. Embodiments include a firmware component that determines whether a message targeting an LSE is authorized to trigger an operation. For example, the firmware component may verify a signature of the received message using a public key, shared secret, or other access control key. Additionally or alternatively, access control policies may be defined to constrain the load of the LSEs on the SE platform hardware and/or to prioritize LSE access. For example, the access control policies may define usage thresholds, such as maximum threshold memory and/or processor utilization rates. As another example, the access controls may restrict the active time for an LSE to a threshold duration. If access constraints are violated or the message cannot be verified, then the firmware component may delay or deny the operation.


