Backup for a secure element or euicc

Abstract

The present invention relates to a backup device for securely transferring state data from a first secure element to a second secure element, the device comprising: - a communication interface configured to establish a secure communication link with the first secure element of a user device, wherein the user device is a smartphone or tablet comprising an eUICC; - a processing unit configured to issue a backup command to the first secure element and receive a backup payload in response - a second secure element configured to store said backup payload; wherein the processing unit is further configured to process the backup payload as a data structure representative of internal state information, secret keys, secret phrases, identity data, cryptographic counters, parts of an eSIM profile, and / or applets executed on or stored in the first secure element, and wherein the backup payload is encrypted by the first secure element using a symmetric key derived from a shared cryptographic session and / or the processing unit is configured to perform a key agreement protocol with the first secure element.

Description

Kratz / de Plasse / SHLD-X Sept. 2, 2025 KDP200025WOBackup for a Secure Element or eUlCC

[0001] The present invention relates to a device for backing up information, program code and applets on an eUlCC, specifically for backing up computer programs and cryptographic keys being part of an eSIM profile and / or stored data or information in said eSIM profile and / or the eSIM profile as such.

[0002] A Secure Element (SE) is a high-security microprocessor chip designed to store and process sensitive data securely. These chips are found in a variety of devices and applications, from smartphones and payment cards to identity documents and loT devices. When an SE is embedded within a chip, it is often referred to as an embedded Secure Element (eSE).

[0003] The primary function of a Secure Element is to protect digital keys and other confidential information. It is dedicated hardware, designed to resist various types of attacks, including physical tampering and software-based attacks. Unlike software-based security solutions, which run on the main processor of a device and can be vulnerable to malware and hacking, a Secure Element offers an isolated environment that physically and logically separates sensitive data and operations from other parts of the system.

[0004] One of the key features of a Secure Element is its ability to securely manage cryptographic keys. It can generate, store, and manage cryptographic keys used for various security functions, such as encryption, digital signatures, and authentication. These keys are protected within the SE’s secure environment and are inaccessible to external processes or users.

[0005] Communication between the Secure Element and the rest of the system is conducted through carefully defined and secure interfaces. The SE ensures that only authorized applications and processes can access its services and stored data, typically enforced through strict authentication protocols and access control mechanisms.

[0006] Another advantage of the Secure Element is its resilience to physical attacks. These chips are often designed to detect and respond to tampering attempts, such as erasing stored keys or disabling the chip to protect the data.Kratz / de Plasse / SHLD-X Sept. 2, 2025 KDP200025WO

[0007] The use of a Secure Element provides several benefits. First, it significantly enhances the security of stored data and executed operations, as it is more resistant to both physical and software-based attacks. Second, it enables secure authentication and transaction processing, which is especially important for applications in finance, mobile payments, and digital identity verification. Third, it aids in complying with data privacy and security regulations, providing a robust solution for data security.

[0008] In the context of the Internet of Things (loT), the Secure Element provides an essential security component for connected devices. As loT devices increasingly collect and transmit sensitive data, it is crucial to protect that data. A Secure Element can serve as a trusted anchor to ensure the integrity and confidentiality of transmitted information.

[0009] A Secure Element, as referenced in this invention, can be viewed as a standalone microcomputer, equipped with its own processor and memory. It offers an isolated, secure environment, physically and logically separated from other components of the host device (such as a smartphone or payment card).

[0010] An eSIM (embedded SIM) is a SIM card embedded into a device. Unlike a physical SIM card, which must be manually inserted into a device and replaced as needed, the eSIM is soldered into the device and provides the same functionality as a traditional SIM card. This integration allows devices to be smaller and more resistant to environmental factors, as there is no need for additional slots or holders for SIM cards.

[0011] eSIM profiles are configurable profiles stored on an eSIM. Each profile contains the necessary information for authentication and service provisioning of a mobile network operator, similar to a traditional SIM card. The main advantage of eSIM profiles is that they can be remotely activated, deactivated, or exchanged over the internet and / or mobile network, eliminating the need to physically swap SIM cards. This allows users to switch easily between mobile operators or activate additional data plans without replacing the physical SIM card.

[0012] The eSIM resides on a chip, fundamentally functioning as a Secure Element and referred to as an embedded Universal Integrated Circuit Card (eUlCC).Kratz / de Plasse / SHLD-X Sept. 2, 2025 KDP200025WO

[0013] The use of the eUlCC inherently provides the same level of security as a Secure Element, ensuring that eSIM data retains its integrity and that communication with the mobile network is secure. This is critical for functions such as authentication within the mobile network.

[0014] For the purposes of the present invention — and as generally understood — the terms SE, eSE, and eUlCC are used interchangeably to refer to the core function of securely storing data and algorithms in either a general (SE, eSE) or specialized (eUlCC) form.

[0015] A key issue is that an eSE is typically controlled by the manufacturer. Although an eSE is generally capable of storing all necessary programs and information, the manufacturer predefines which functions are available.

[0016] The objective of the present invention is to enable the user to locally back up data from an eUlCC, SE, or eSE in a hardware-encrypted manner, while the backup process itself is secured to prevent fraudulent backups.

[0017] This problem is solved by a backup device for securely transferring state data from a first secure element to a second secure element, the device comprising:- a communication interface configured to establish a secure communication link with the first secure element of a user device, wherein the user device is a smartphone or tablet comprising an eUlCC;- a processing unit configured to issue a backup command to the first secure element and receive a backup payload in response;- a second secure element configured to store said backup payload; wherein the processing unit is further configured to process the backup payload as a data structure representative of internal state information, secret keys, secret phrases, identity data, cryptographic counters, parts of an eSIM profile, and / or applets executed on or stored in the first secure element, and wherein the backup payload is encrypted by the first secure element using a symmetric key derived from a shared cryptographic session and / or the processing unit is configured to perform a key agreement protocol with the first secure element.Kratz / de Plasse / SHLD-X Sept. 2, 2025 KDP200025WO

[0018] The surprising finding of the present invention is that a secure and user-controlled backup of cryptographic applications and data stored in a secure element, such as an elllCC integrated in a smartphone or tablet, can be achieved without relying on any external network infrastructure. By combining a secure communication interface — preferably NFC — with an embedded second secure element, a processing unit, and a cryptographic key agreement protocol, it becomes possible to selectively extract, encrypt, and transfer sensitive applet states, internal counters, identity credentials, or eSIM profile components to a tamper-resistant backup device.

[0019] The core inventive idea lies in enabling this transfer in a fraud-resistant manner that may include user participation (e.g. via split-key entry), authentication and mutual trust verification, while preserving the confidentiality and structural integrity of the original secure element contents. This approach allows the user to locally replicate security-critical data without loss of control or exposure to third-party risks.

[0020] The communication interface allows the backup device to interact securely with a secure element (SE) of the user device. This includes elllCC chips embedded in smartphones or tablets, using protocols such as ISO / IEC 7816 over NFC or other transport layers. This ensures flexibility across various physical implementations (NFC, USB, BLE).

[0021] The processing unit serves as the control logic for initiating the backup process. It sends a specific backup command and processes the response. This allows the system to trigger backups only upon user authorization, improving security and preventing unauthorized duplication.

[0022] The second secure element acts as a tamper-resistant storage component. It securely stores the backup payload, which can include cryptographic material and applet state data. By embedding this in the backup device, the sensitive information is never exposed in unprotected memory or software environments.

[0023] The backup payload structure allows for selective or complete replication of the internal state of the first SE, including cryptographic counters, keys, identityKratz / de Plasse / SHLD-X Sept. 2, 2025 KDP200025WO credentials, or even full applets. This provides maximum flexibility for restoring trusted state, even if the user device is lost or replaced.

[0024] The encryption using a symmetric key ensures that the backup is confidential during transmission. By deriving the key through a cryptographic session or key agreement protocol (e.g., ECDH), no static keys need to be stored or exchanged in advance, thus enhancing the security of the scheme.

[0025] Overall, this combination allows for a secure, user-controlled, decentralized backup mechanism for SE-based environments without relying on external servers or cloud infrastructure.

[0026] According to one embodiment of the present invention, the communication interface comprises an NFC communication module.

[0027] NFC is a widely available and standardized short-range communication protocol, making it ideal for secure and intentional peer-to-peer communication between the user device and the backup device.

[0028] Technically, this allows reuse of existing mobile hardware interfaces (such as the NFC controller in smartphones) and simplifies user interaction — for example, by initiating backup through a tap gesture.

[0029] NFC inherently supports ISO / IEC 14443 and 7816-4 protocols, which are compatible with APDU-based smartcard communication. This allows seamless integration with secure elements and elllCCs.

[0030] From a security perspective, NFC’s short range reduces the risk of interception during key exchange or payload transmission.

[0031] Therefore, the present example ensures practical implementability of the invention in consumer hardware environments, while still maintaining a high level of physical and cryptographic security.

[0032] Furthermore, it may be preferred that the processing unit is further configured to verify a digital signature, a public key, and / or an authentication token received from the first secure element prior to accepting the backup payload.

[0033] This feature introduces an authentication step to ensure that the source of the backup payload (i.e., the first secure element) is legitimate and authorized.Kratz / de Plasse / SHLD-X Sept. 2, 2025 KDP200025WO

[0034] The verification may be performed using cryptographic mechanisms such as X.509 certificates, signed challenge-response pairs, or HMAC-authenticated tokens.

[0035] This ensures that the backup device does not blindly trust incoming payloads but instead performs cryptographic validation, thereby reducing the risk of spoofing or tampering.

[0036] It supports integration into a PKI (Public Key Infrastructure), enabling compatibility with enterprise security systems and scalable key management frameworks.

[0037] In particular, an individual public-private key pair may be derived from a master key pair using a deterministic derivation function, such as a hierarchical key derivation scheme based on elliptic curve cryptography. This allows verification that a given public key is authentically derived from a trusted root, namely the master public key, without requiring direct knowledge of the individual private key.

[0038] Such derivation enables scalable and verifiable key assignment, for example to associate individual user devices or applets with specific cryptographic identities while maintaining centralized trust management. Alternatively, individual key pairs or precomputed shared secrets may be provisioned into the secure element of the backup device during manufacturing or personalization, either through direct key injection or secure enrollment protocols.

[0039] These mechanisms allow the system to verify the authenticity and authorization of devices during the backup or restore process, while preserving the secrecy and integrity of key material at all times. It may in particular be possible that the master key(s) are stored on a sever externally and the individual keys are checked for authenticity with that public master key(s) online.

[0040] By enforcing trust validation, the invention also supports auditability, as only verifiably signed payloads are accepted for storage.

[0041] According to one embodiment it may be preffered the processing unit is further configured to transmit a second digital signature, a second public key, and / or a second authentication token stored in the second secure element to the user device, wherein the token is encrypted using the key derived from the shared key agreement session.Kratz / de Plasse / SHLD-X Sept. 2, 2025 KDP200025WO

[0042] This embodiment specifies that mutual authentication is performed between the backup device and the user device, ensuring that both parties can cryptographically verify each other before any sensitive data is exchanged.

[0043] The second secure element (in the backup device) proves its authenticity by signing a payload or presenting a digital certificate, which may be encrypted using the previously established session key derived from a cryptographic key agreement protocol such as Elliptic Curve Diffie-Hellman (ECDH).

[0044] This prevents impersonation or spoofing by rogue backup devices and enables bidirectional trust establishment, such that the user device can ensure that it is communicating with a genuine and authorized backup instance.

[0045] The encryption of authentication tokens or signed credentials using the session key provides confidentiality and forward secrecy during the authentication exchange, even in the presence of passive or active adversaries.

[0046] To support scalable and efficient trust anchoring, the individual key pair of the backup device may be cryptographically derived from a master key pair using a deterministic derivation method, enabling the user device to verify that the received public key belongs to a trusted key hierarchy. Alternatively, the individual key pair or a pre-established shared secret may be securely stored in the second secure element during the manufacturing or personalization phase. This avoids the need for runtime enrollment and allows authentication to be completed even in air-gapped environments.

[0047] Altogether, these mechanisms form the basis of a zero-trust exchange model, where no communication or payload acceptance occurs without explicit cryptographic validation of both parties, ensuring the authenticity, integrity, and authorization of all involved components.

[0048] According to one embodiment, only part of the first or second public key is transmitted, specifically (m - n) digits, and the user is prompted to input the remaining n digits for key completion.

[0049] This feature introduces user-in-the-loop validation, adding a manual layer of security on top of automated cryptographic exchange.Kratz / de Plasse / SHLD-X Sept. 2, 2025 KDP200025WO

[0050] The partial key disclosure method ensures that even if a session is intercepted, the communication remains incomplete and unusable without user-provided input.

[0051] The required user input can be entered via a touchscreen, external app, or NFCbased confirmation.

[0052] This is particularly useful in scenarios where high assurance is required, such as banking or ID-based verification.

[0053] It also mitigates hardware compromise risks, as full key exchange never occurs without user participation.

[0054] In a preferred embodiment, the second secure element is configured to verify the integrity of the received backup payload using a cryptographic integrity protection mechanism, such as a message authentication code (MAC) and / or a digital signature.

[0055] Such integrity verification ensures that the payload has not been altered, corrupted, or replaced during transmission or storage, independently of whether the payload has been encrypted for confidentiality.

[0056] The use of a MAC or digital signature enables the system to detect and reject any manipulation of the backup payload, for example as a result of man-in-the-middle attacks, faulty communication links, or tampering attempts on persistent memory.

[0057] In addition to tamper detection, this mechanism supports non-repudiation by cryptographically binding the payload to its legitimate source, allowing subsequent verification of its origin and authenticity in forensic or audit scenarios.

[0058] Integrity assurance is of particular importance in environments where cryptographic keys, authentication credentials, or executable applets are being stored or transferred, as even minor unauthorized modifications can result in unauthorized system access, functional instability, or critical security breaches.

[0059] In particular, this embodiment helps to ensure that only authentic and certified instances of applets or security-sensitive data structures, such as Secure Storage Domains (SSDs), are accepted and restored. As a result, the system is protected against injection of malicious code, substitution of downgraded applets, or unauthorized reconfiguration of eSIM profile components.Kratz / de Plasse / SHLD-X Sept. 2, 2025 KDP200025WO

[0060] It may as well be preferred a biometric sensor and / or user authentication interface is configured to authorize the execution of the backup or restore operation.

[0061] In one embodiment, the backup device comprises a mechanism for verifying local user presence, such as a biometric sensor or a user authentication interface for entering a PIN, password, or equivalent credential. This ensures that the execution of sensitive operations such as initiating a backup or performing a restore requires active and intentional user interaction.

[0062] The Password can be freely choosen by the user and the user is asked a questions that hints to the answer of as well so both, the question and the answer may be set by choice by the user.

[0063] By enforcing biometric or password-based authentication at the device level, the system ensures that only the rightful owner of the backup device is able to access or manipulate security-critical data. This remains true even in the event that the backup device is lost, misplaced, or stolen, thereby offering protection against unauthorized physical use.

[0064] When used in combination with cryptographic mechanisms as defined, for example, such as partial public key entry by the user, this embodiment enables a multi-factor authentication approach. It effectively combines three security dimensions: possession (the backup device itself), knowledge (a PIN or password), and inherence (biometric characteristics of the user).

[0065] Such a multi-layered authentication scheme provides strong device-level protection of applets and secure profile data, ensuring that only authorized users are able to interact with SSD (Secure Storage Domain) components, eSIM profile entries, or installed cryptographic applications. This significantly reduces the risk of app spoofing, unauthorized data access, or fraudulent manipulation of sensitive mobile identity information.

[0066] According to one embodiment it is preffered that the communication interface is configured to operate in an air-gapped environment without reliance on external network connectivity.

[0067] Such an air-gapped configuration effectively eliminates external attack vectors by preventing any remote access path to the backup process. It ensures that theKratz / de Plasse / SHLD-X Sept. 2, 2025 KDP200025WO entire communication and data exchange between the user device and the backup device remains physically contained and locally managed.

[0068] This is particularly advantageous in high-security environments where access to Secure Element-related data is restricted by regulatory, legal, or internal policy constraints. For example, in certified trust environments, remote provisioning or cloud-based key management may be explicitly prohibited.

[0069] In this embodiment, even updates, key exchanges, and trust establishment operations occur exclusively via direct physical interaction (e.g., NFC proximity), thereby reducing the risk of cloud-side or over-the-air (OTA) tampering or credential leakage.

[0070] The air-gapped design supports critical deployment scenarios such as government, defense, infrastructure control systems, or identity management in which strict data sovereignty, traceability, and compartmentalization are required.

[0071] This embodiment combines the backup functionality with an everyday peripheral device, such as a wireless charging pad or cradle, thereby serving a dual purpose and enhancing the practical usability of the solution.

[0072] From a usability and user experience perspective, the integration allows for frictionless and passive execution of the backup process — for example, during regular charging cycles — without requiring explicit user interaction beyond placing the device onto the charging surface.

[0073] Embedding security-critical backup logic into a familiar object lowers the barrier for regular use, reduces the risk of user negligence, and helps to prevent phenomena such as security fatigue or resistance to additional security steps.

[0074] This design further promotes habitual and frequent backup behavior, improving long-term data resilience and recoverability without requiring changes in user routines or additional user training.

[0075] This embodiment introduces temporal and quantitative control mechanisms that are designed to reduce the risk of brute-force attacks, repeated unauthorized access attempts, or automated abuse of the backup interface.

[0076] Responsibility for enforcing these constraints may be distributed between the backup device and the secure element. The secure element may apply policyKratz / de Plasse / SHLD-X Sept. 2, 2025 KDP200025WO enforcement internally, while the backup device may monitor usage conditions and restrict execution externally through firmware logic or application-level rules.

[0077] This approach aligns with the fundamental design principle of fraud-resistant backup control as described before, by ensuring that backup functionality is only available within strictly defined and user-authorized operational windows.

[0078] Such mechanisms also support the implementation of adaptive or context- sensitive security policies, including automatic lockouts, dynamic authentication windows, or differentiated thresholds based on risk scoring or recent activity history.

[0079] From a regulatory and certification perspective, these constraints facilitate secure audit logging, allowing the system to track and record precisely when and how often backup attempts were made, by whom, and under what conditions — thereby enhancing transparency, accountability, and trustworthiness of the backup process.

[0080] This embodiment introduces a form of split-key protection, in which a portion of the cryptographic material remains outside the scope of digital communication, thereby separating control between the system and the user.

[0081] By only transmitting an incomplete representation of the secret, the system ensures that no single party — neither the backup device nor the user device — can unilaterally reconstruct or activate the protected content without explicit cooperation from the user.

[0082] The withheld portion of the secret may be memorized by the user, printed for offline retention, or stored in a physically isolated medium such as a hardware token or secured paper wallet, enabling a human-readable form of two-part authentication.

[0083] This mechanism enhances the security of the backup architecture by enabling controlled, manual threshold-based recovery procedures. Such an approach is particularly relevant in high-assurance contexts, including confidential infrastructure access, hardware wallets, or scenarios involving state-level data compartmentalization.Kratz / de Plasse / SHLD-X Sept. 2, 2025 KDP200025WO

[0084] The intentional separation of key material renders intercepted or leaked backup payloads unusable without the user-retained segment, thereby providing strong protection against malware, key extraction attacks, and advanced persistent threats (APT) targeting both devices and transmission paths.

[0085] Moreover, this split-key scheme supports multi-party authorization concepts such as dual control or quorum-based access, in which restoration is only possible through the verified participation of both the system and an authenticated user, enhancing overall governance and accountability.

[0086] According to one embodiment, the backup device is further configured such that the second secure element rejects restoration attempts if the reconstructed private key or secret phrase is incomplete or fails validation.

[0087] This embodiment enforces a validation mechanism on the destination side of the backup system, thereby completing the split-key architecture and ensuring that restoration cannot proceed unless the user has correctly supplied the withheld key portion.

[0088] To accomplish this, the second secure element includes logic to verify whether the full reconstructed secret satisfies expected cryptographic properties — such as correct length, checksum match, valid key structure, or successful decryption of a test vector.

[0089] This verification prevents restoration based on incorrect or forged input, thereby mitigating risks arising from brute-force attacks, dictionary-based key guessing, or attempts to bypass user involvement.

[0090] In addition, the mechanism supports safe use of non-digital partials, such as printed or memorized segments of a secret. Re-entry errors caused by typographical mistakes or incomplete input can be detected and rejected before irreversible operations, such as decryption or credential import, are performed.

[0091] By requiring successful user-supplied reconstruction and verification prior to restoration, the system enforces a strong form of non-automatable user control. Even if the backup device is compromised, unauthorized access to backup contents is prevented without the user-retained key portion.Kratz / de Plasse / SHLD-X Sept. 2, 2025 KDP200025WO

[0092] According to one embodiment, the backup payload comprises a cryptographic checksum or redundancy code to ensure fault-tolerant reconstruction of the transmitted data.

[0093] This feature introduces a built-in resilience layer that protects the integrity and completeness of the backup payload against various real-world disturbances and error conditions.

[0094] By embedding a checksum or redundancy code — such as a cyclic redundancy check (CRC), HMAC digest, or a forward error correction code (e.g., Reed- Solomon) — the system is able to detect inconsistencies and reconstruct missing or corrupted parts of the payload, provided the redundancy threshold is not exceeded.

[0095] This significantly improves robustness in scenarios where signal degradation or hardware-level interruptions may occur, including wireless interference, interrupted power supply during a write operation, or data loss due to poor NFC signal quality.

[0096] The use of checksums or integrity codes also supports active tamper detection: any unauthorized modification, injection, or substitution of backup content will lead to verification failure, preventing harmful data from being accepted.

[0097] This embodiment is particularly useful in decentralized architectures or edge environments with limited redundancy, as it enables partial recovery without requiring retransmission or online coordination, thereby improving user confidence and overall system uptime.

[0098] According to one embodiment, the backup device is configured to notify the user of the success or failure of a backup attempt using a visual and / or haptic feedback mechanism.

[0099] This feature ensures that backup operations are transparently communicated to the user and not silently executed or failed without feedback.

[0100] Visual or haptic notification modalities may include integrated LED indicators, display messages on a touchscreen or companion device, vibration pulses, or audible tones confirming successful interaction.Kratz / de Plasse / SHLD-X Sept. 2, 2025 KDP200025WO

[0101] Such feedback allows users to react immediately to failures (e.g., due to misalignment, authentication errors, or out-of-window execution), thereby improving operational reliability and user involvement.

[0102] In addition, this feature supports auditability and verifiability of backup activity by providing an observable trace of whether a security-critical operation was performed, succeeded, or failed.

[0103] The embodiment aligns with general safety and assurance principles in the design of cryptographic systems, where explicit and unambiguous user awareness is essential to prevent misuse or unintentional misconfiguration, particularly in offline or air-gapped environments.

[0104] It may as well be preferred that the backup device further comprises a charger, in particular a wireless charger, for the user device.

[0105] This optimizes the handling for the users as the backup device has a dual function as a charger, in particular having a magnetic connection with the user device, and as a backup device.

[0106] According to one embodiment of the invention, a system is provided that comprises the backup device according to the invention, and a user device, wherein the user device comprises the first secure element configured to exchange data with the backup device and the second secure element of the user device.

[0107] Such a system enables device pairing, profile-based access enforcement, and policy-driven backup constraints across distributed devices. It may also allow binding backup functionality to the physical or cryptographic identity of the user device.

[0108] This is particularly useful in regulated or certifiable environments, where it must be provable that only specific device pairings can trigger sensitive operations such as applet backup or key replication.

[0109] An embodiment is further explained with the help of the following figures:Fig. 1 : a strucutural overview of an eUlCC;Fig. 2: a more detailed overview of a user device according to one example of the present invention;Kratz / de Plasse / SHLD-X Sept. 2, 2025 KDP200025WOFigr. 3: a flow diagram of a method according to the present inventionFig. 4a and 4b: perspective views of a user device, exemplarily shown as a smartphone, magnetically coupled to a backup device.

[0110] Figure 1 illustrates an eUlCC 1 that contains a set of general management functions 3, which handle tasks such as access rights and profile management. Two distinct eSIM profiles 5, 7 are stored within the eUlCC. The first profile 5 contains network credentials 11 required to establish a connection to a mobile network. The second eSIM profile 7, however, lacks telephone credentials and is referred to as a “non-telco” profile. This non-telco profile 7 provides a supplementary security domain (SSD) 13, within which applets 17 are stored. It is noteworthy that the first eSIM profile 5 may also offer a supplementary security domain (SSD) 15, although in the illustrated example, this functionality is not activated.

[0111] Figure 2 shows an example of a device 30 according to the invention having a processor module 32 configured to execute operating system software and application software, a memory module 34 coupled to the processor module, configured to store data and software applications, an embedded Universal Integrated Circuit Card (eUlCC) 36 configured to store a plurality of embedded Subscriber Identity Module (eSIM) profiles, a communication interface 40 coupled to the processor module, configured to support wireless and / or wired data transmission via multiple communication protocols; and a power supply mechanism 42 configured to provide electrical power to the device. The device itself may communicate with a mobile network 50.

[0112] Fig. 3 illustrates a method for securely backing up data from a first secure element, such as one embedded in a smartphone or tablet, to a second secure element located within a backup device. The method ensures the confidentiality, integrity, and authenticity of the transmitted data through a sequence of cryptographically protected steps.

[0113] As seen in step 100, the process begins by initiating a Near Field Communication (NFC) session between the user device and the backup device. The use of NFC provides a short-range, proximity-based communication channel, which minimizes the risk of remote interception and enables intentional, user-controlled interaction.Kratz / de Plasse / SHLD-X Sept. 2, 2025 KDP200025WO

[0114] In step 110, the devices perform a key exchange to establish a secure communication context. This may involve exchanging public keys or performing an Elliptic Curve Diffie-Hellman (ECDH) key agreement to derive a shared symmetric session key. The session key will be used to encrypt and authenticate the backup payload in subsequent steps.

[0115] Once the session is established, step 120 involves the backup device issuing a backup command to the secure element of the user device. This command may include relevant metadata, such as the scope of the backup, identification of the requesting application, or authorization parameters.

[0116] Following the command, the secure element proceeds in step 130 to encrypt the designated payload using the previously established session key. The payload may include internal state information, cryptographic keys, application logic, counters, or components of an eSIM profile. Encryption ensures that the data remains confidential and tamper-proof during transfer.

[0117] In step 140, the encrypted payload is transmitted from the user device to the backup device via the NFC channel. Due to its encrypted nature, the payload remains protected even if intercepted during transmission.

[0118] Finally, in step 150, the backup device verifies the received payload. This may involve validating message authentication codes (MACs), digital signatures, or user-supplied input in the case of split-key protection. Upon successful verification, the payload is securely stored in the second secure element of the backup device.

[0119] Fig. 4a and Fig. 4b illustrate a perspective views of a user device 50, exemplarily shown as a smartphone, magnetically coupled to a backup device 60 that comprises a wireless charging module 62 and a second secure element 64. The two devices are aligned and held in place by an integrated magnetic interface 66.

[0120] The user device 50 comprises a first secure element (not shown), such as an eUlCC, embedded in the hardware of the mobile phone. It may also include a display, user interface elements, and cryptographic software for secure communication with external devices.

[0121] The backup device 60 includes a circular charging surface or cradle on which the user device 50 is positioned at an angle. The surface is shaped to receive andKratz / de Plasse / SHLD-X Sept. 2, 2025 KDP200025WO hold the user device in a tilted orientation, thereby enabling both mechanical stability and ergonomic use during passive charging or backup operations.

[0122] A magnetic retention mechanism 64 ensures proper alignment and physical coupling between the two devices. This mechanism may comprise a magnet ring or an array of magnetic poles that interact with corresponding magnetic material or a ring structure in the user device.

[0123] The wireless charging module 62 of the backup device supplies energy inductively through the magnetic coupling, allowing the user device to recharge during the backup operation. The device also houses a second secure element (not shown) that is used to store encrypted backup payloads and perform cryptographic operations such as key validation and integrity checking.

[0124] The backup device may further include a communication interface (not shown) configured to initiate an NFC session with the user device 50. This interface enables transmission of APDU commands and encrypted payloads as described in connection with Fig. 4a.

[0125] The combined mechanical and electrical interface enables a seamless and user- friendly backup experience by integrating secure data transfer with regular device charging, minimizing user effort and maximizing operational security.

[0126] The features of the invention disclosed in the foregoing description, the claims, and the drawings may be essential for implementing the invention in its various embodiments, both individually and in any desired combination.

Claims

Kratz / de Plasse / SHLD-X Sept. 2, 2025 KDP200025WOClaims1 . A backup device for securely transferring state data from a first secure element to a second secure element, the device comprising:- a communication interface configured to establish a secure communication link with the first secure element of a user device, wherein the user device is a smartphone or tablet comprising an eUlCC;- a processing unit configured to issue a backup command to the first secure element and receive a backup payload in response- a second secure element configured to store said backup payload; wherein the processing unit is further configured to process the backup payload as a data structure representative of internal state information, secret keys, secret phrases, identity data, cryptographic counters, parts of an eSIM profile, and / or applets executed on or stored in the first secure element, and wherein the backup payload is encrypted by the first secure element using a symmetric key derived from a shared cryptographic session and / or the processing unit is configured to perform a key agreement protocol with the first secure element.

2. The backup device according to claim 1 , wherein the communication interface comprises a Near Field Communication (NFC) module.

3. The backup device according to claim 1 or claim 2, wherein the key agreement protocol comprises:(i) an Elliptic Curve Diffie-Hellman (ECDH) exchange over the communication interface to derive a shared symmetric key; or(ii) a mutual exchange of public keys, wherein the first secure element transmits a first public key of a first public-private keypair to the second secure element, and the second secure element transmits a second public key of a second publicprivate keypair to the first secure element, such that data is encrypted by each party using the respective public key of the recipient.Kratz / de Plasse / SHLD-X Sept. 2, 2025 KDP200025WO4. The backup device according to any of the proceeding claims, wherein the processing unit is further configured to verify a digital signature, a public key, and / or an authentication token received from the first secure element prior to accepting the backup payload.

5. The backup device according to any of the proceeding claims, wherein the processing unit is further configured to transmit a second digital signature, a second public key, and / or a second authentication token stored in the second secure element to the user device, wherein the token is encrypted using the key derived from the shared key agreement session.

6. The backup device according to claim 4 or 5, wherein only part of the first or second public key is transmitted, specifically (m - n) digits, and the user is prompted to input the remaining n digits for key completion.

7. The backup device according to any of the preceding claims, wherein the second secure element is configured to verify the integrity of the backup payload using a message authentication code (MAC) and / or a digital signature.

8. The backup device according to any of the preceding claims, further comprising a biometric sensor and / or user authentication interface configured to authorize the execution of the backup or restore operation.

9. The backup device according to any of the preceding claims, wherein the NFC communication module is configured to operate in an air-gapped environment without reliance on external network connectivity.

10. The backup device according to any of the preceding claims, wherein the backup device further comprises a charger, in particular a wireless charger, for the user device.Kratz / de Plasse / SHLD-X Sept. 2, 2025 KDP200025WO11. The backup device according to any of the preceding claims, wherein the processing unit is configured to allow the backup operation for a predetermined time period following a successful authentication, or alternatively, for a limited number of permitted attempts, and / or wherein the first secure element stores the time period or attempt counter and enforces the backup restriction accordingly.

12. The backup device according to any of the preceding claims, wherein only a partial segment of a private key and / or a secret is transmitted as part of the backup payload, specifically comprising the first x digits of a total of y digits, while the remaining (y - x) digits are withheld from transmission and are required to be retained separately by the user for completing restoration or activation.

13. The backup device according to any of the preceding claims, wherein the second secure element is further configured to reject restoration if the partial key or phrase is incomplete or incorrect.

14. The backup device according to any of the preceding claims, wherein the backup payload comprises a cryptographic checksum or redundancy code to ensure fault-tolerant reconstruction.

15. The backup device according to any of the preceding claims, wherein the device is configured to notify the user of a successful or failed backup attempt via a visual or haptic interface.

16. A system comprising a backup device according to any of the preceding claims and a user device, the user device comprising the first secure element.

17. A method for backing up data from a secure element of a user device to a second secure element of a backup device, comprising:- initiating an NFC session between the user device and the backup device;- exchanging public keys and / or performing an Elliptic Curve Diffie-HellmanKratz / de Plasse / SHLD-X Sept. 2, 2025 KDP200025WO(ECDH) key exchange to derive a symmetric encryption key;- issuing a backup command from the backup device to the first secure element;- encrypting, at the first secure element, a payload comprising internal state information, secret keys, or cryptographic counters;- transmitting the encrypted payload to the backup device;- verifying the authenticity of the payload using a MAC or digital signature; and- storing the payload in the second secure element.

18. The method of claim 17, further comprising: limiting the backup operation to a predefined time window after successful user authentication, or limiting the number of permitted backup attempts.

19. The method of claim 17 or 18, further comprising:- transmitting only a partial segment of a private key or secret as part of the backup payload;- prompting the user to supply a remaining segment locally during the restoration process.

20. The method of any of claims 17 to 19, wherein the second secure element rejects restoration unless the user-supplied segment matches the withheld portion.

21. The method of any of claims 17 to 20, wherein the user device and backup device are integrated into a system comprising a wireless charging interface.

22. A computer program product comprising instructions which, when executed on a processor of a backup device according to any of claims 1 to 15, cause the device to perform the method of issuing a backup request to a secure element, processing and storing the resulting payload, and enforcing authentication and security policies in accordance with any of claims 1 to 15.21Kratz / de Plasse / SHLD-X Sept. 2, 2025 KDP200025WO23. Use of a backup device according to any of claims 1 to 15 for securely replicating state data between secure elements.22

Images