Patent Description:
An edge device is a device located on a network that may either be a boundary between two networks, such as a gateway or a router, or an endpoint of a network, such as mobile telephone, an Internet of Things (IoT) gateway, sensor, controller, or actuator.

Often edge devices must store very sensitive information, for example, cryptographic keys that may be used for secure communication with other devices located on a network, account numbers, login credentials, and personal information pertaining to the owner of a particular edge device. Such information, which needs to be protected from unauthorized access both on the edge device itself, when in transit while being communicated over a network to other devices, or when stored on other devices, is referred to herein as private information.

One mechanism by which private information stored on an edge device may be protected is to store it in a secure element. A secure element (SE) is a tamper-resistant electronic component that is typically used for storing host applications and the confidential and cryptographic data associated with those host applications. Herein, the term secure element is defined as an embedded integrated circuit that employs tamper resistant features to protect applications and data stored thereon.

Secure Elements are described in <NPL>).

Therefore, the private information such as cryptography keys are both critical to their owners and must be held secret. Therefore, storing such information on secure elements protect the information from access from unauthorized parties.

Secure elements maybe found in many different applications, e.g., SIM cards for mobile telephones, access badges for both network and physical access, and also in Internet-of-Things (IoT) devices such as set-top boxes for television services, controllers for machines and vehicles.

All machines are susceptible to damage, destruction, misplacement, and theft. Thus, an unfortunate, but highly likely, end-of-life scenario for an edge device is its loss in some manner. An unfortunate consequence of such loss is the loss of the private information stored on the edge device, which can further result in the loss of access to data that is encrypted using keys stored in that private information. It is, therefore, desirable to have a mechanism for backing up private information, including cryptographic keys, stored on an edge device.

A first mechanism for backing up private information stored on edge devices linked to a particular individual or work group to whom a particular edge device belongs entails storing the private information on another device, e.g., on a personal computer or server belonging to that entity or work group. However, storing the information in that manner may entail storing it at a lower security level than the security level of the device from which it is backed up. For example, a data stored on a secure element of an edge device is very safe as compared to data stored, even in encrypted form, in a file on a hard disk or in a flash drive. Thus, such alternate storage of the private information defeats the objective of keeping it secure from unauthorized access. For example, if such a backup storage computer is hacked, the hacker may obtain access to the private information. Furthermore, such a mechanism is burdensome on the individuals or workgroups linked to such secure elements.

Another mechanism for providing backup of private information stored on edge devices is storing the private information on a centralized backup server, e.g., a company-wide server or an issuer-provided server. There are similar problems associated with that approach. Centralized backup servers may not have as high a level of security. If such a server is hacked, private information related to many edge devices may be divulged. Furthermore, the approach requires infrastructure investment and maintenance for the backup server.

Document <CIT> describes a method for a backup and restore of configuration data of an end-user device comprising the steps: encrypting the configuration data by using symmetric-key encryption with a symmetrical key, signing the encrypted configuration data with a device private key, and sending the encrypted and signed configuration data to a personal computer of a user of the end-user device, and/or to a storage location of a service provider network, for storage.

Document <CIT> describes a method for recovering data including collecting identity factors at a user device, wherein hashes of the identity factors are configured to be stored at a server.

From the foregoing it is apparent that there is a need for an improved method to backup private information, such as cryptographic keys and account numbers, stored on edge devices and to provide a mechanism for recovery of such information in the event an edge device is lost or damaged.

A method for backing up critical data stored on an originator edge device associated with a user such that the backed up critical data maybe recovered onto a target device. To backup critical data, requesting, by the vault-broker server, the originator edge device to create an export backup record of critical data stored on the originator edge device. Obtaining, by the originator edge device, a backup-retrieval code from the user of the originator edge device. Generating, by the originator edge device, the backup record in response to the request for the export backup record, the backup record being a function of the backup-retrieval code, a cryptographic key, and the critical data being backed up, and transmitting a backup-response message including the backup record, by the originator edge device to the vault-broker server. The backup-response message including the backup record is transmitted by the vault-broker server to the surrogate edge device, which stores the backup record. The vault-broker server stores an association between the originator edge device and the surrogate edge device on the vault-broker server.

In an aspect, an implied circle of trust is established among the originator edge device and a surrogate edge device based on a common cryptographic key issued by a trusted certificate authority and edge devices may be provisioned with certificates by the trusted certificate authority. The surrogate edge device uses the certificates to verify that the originator edge device, the target edge device, and surrogate edge device belong to the same implied circle of trust.

In an aspect, the backup record is generated by creating a wrapping key, which may be generated as a function of a backup-retrieval code, encrypting the critical data using the wrapping key, hashing the wrapping key or the backup-retrieval code, and creating the backup record from the encrypted critical data and the hashed value. The backup record message is generated by encrypting the backup record with a cryptographic key of the surrogate.

In a further aspect, the backed up private data is recovered to a target edge device, by generating, by the target edge device, a recovery-retrieval-code message and transmitting the recovery-retrieval-code message to the vault-broker server, determining, by the vault-broker server, a surrogate edge device on which the backup record of the originator edge device from which recovery is sought (the recovery surrogate edge device) has been saved, forwarding, by the vault-broker server, the recovery-retrieval-code message to the recovery surrogate edge device, validating, by the recovery surrogate edge device, the recovery-retrieval-code message, and upon successful validation of the recovery-retrieval-code message, transmitting a recovery-response message including the backup record of the originator device to the vault-broker server or upon failure of the validation of the recovery-retrieval-code message, and transmitting a recovery-response message including an error code. The vault-broker server forwards the recovery-response message to the target edge device. If the recovery-response message includes the backup record, recovering, by the target edge device, the backup record. On the other hand, if the recovery-response message includes an error code, the user is offered an additional attempt to provide the correct backup-retrieval code.

In an aspect, the recovery-retrieval-code message includes a hash of an attempted backup-retrieval code and an encryption key certificate of the target device.

The implied circle of trust may be established using a shared key or knowledge of a certificate of a trusted certificate authority.

The backup retrieval code may be a personal identification number, a biometric, a password, or a challenge-response dialog.

The implied circle of trust may include multiple surrogate edge devices wherein the method described herein is repeated for a plurality of such multiple surrogate edge devices.

In an aspect, a system including vault-broker server, an originator edge device, a surrogate edge device, and a target edge device performs the technology for backing up and recovering critical data as described herein.

In the following detailed description, reference is made to the accompanying drawings that show, by way of illustration, specific embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. It is to be understood that the various embodiments of the invention, although different, are not necessarily mutually exclusive. For example, a particular feature, structure, or characteristic described herein in connection with one embodiment may be implemented within other embodiments. In addition, it is to be understood that the location or arrangement of individual elements within each disclosed embodiment may be modified without departing from the spirit and scope of the invention. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is defined only by the appended claims, appropriately interpreted, along with the full range of equivalents to which the claims are entitled. In the drawings, like numerals refer to the same or similar functionality throughout the several views.

The following description includes references to various methods executed by a processor of an integrated circuit chip. As is common in the field, there may be phrases herein that indicate these methods or method steps are performed by software instructions or software modules. As a person skilled in the art knows, such descriptions should be taken to mean that a processor, in fact, executes the methods, software instructions, and software modules.

The herein described technology provides a mechanism by which private information stored on edge devices, including secure elements, can be backed up securely and efficiently and recovered from such backup copies without added burden and risk of locally backing up such information by individuals, work groups, organization, or issuers.

<FIG> is an illustration of a network <NUM> connecting multiple edge devices <NUM>. Some edge devices <NUM>' have secure elements <NUM>. The edge devices <NUM>/<NUM>' cooperate to backup private information of each other via brokerage services provided by a vault-broker server <NUM>. In <FIG>, edge device <NUM> are depicted as smartphones and boxes that maybe some type of device controllers. However, these are merely examples. The technology described herein is applicable to any network-connected edge device.

The secure element <NUM> may be an integrated part of an edge device <NUM>, as illustrated with edge device <NUM>" and secure element <NUM>'. Alternatively, the secure element <NUM> is located, on a removable device <NUM> such as, for example, a SIM card, a UICC, an SD card, or in a USB connectable device.

If a secure element <NUM>/<NUM>' can communicate with other nodes it may be considered an edge device <NUM>.

As described in greater detail hereinbelow, private information stored on an edge device <NUM> is backed up, in an encrypted form, on one or more other edge devices <NUM>. The former is referred to herein as an originator edge device and the latter, as a surrogate edge device. The concept of private information being stored on an edge device <NUM> includes the private information being stored on a secure element <NUM> contained in the edge device <NUM> or in another memory structure, e.g., a non-volatile memory, of the edge device <NUM>.

As described in greater detail below, implied circles of trust (ICT) may be established between various edge devices <NUM> wherein the edge devices <NUM> that belong to the same circle of trust share knowledge of a common trust key.

The vault-broker server <NUM> contains a database containing information linking edge devices <NUM> to implied circles of trust and a database containing information linking originator secure elements to one or more surrogate secure elements on which the private information stored on originator secure elements are backed up in encrypted form.

<FIG> is a high-level block diagram of a device architecture of an edge device <NUM> including a secure element <NUM>. In the example of <FIG>, an edge device <NUM> correspond to edge device <NUM> of <FIG>. The secure element <NUM>, conversely, corresponds to either secure element <NUM> or integrated secure element <NUM>'. Thus, the secure element <NUM> may be located on a removable device <NUM> (corresponding to removable device <NUM>) as shown in <FIG> or integrated into the edge device <NUM>.

The edge device <NUM> may include a processor <NUM> connected via a bus <NUM> to a random-access memory (RAM) <NUM>, a read-only memory (ROM) <NUM>, and a non-volatile memory (NVM) <NUM>.

Conversely, the secure element <NUM> may also include a processor <NUM>, a ROM <NUM>, a RAM <NUM>, and a non-volatile memory <NUM> connected via a bus <NUM>. The secure element <NUM> further includes an input/output interface <NUM> for connecting the processor <NUM>, again typically via the bus <NUM>, to a contact pad <NUM> by which the secure element <NUM> may be connected to contacts <NUM> located for example on a bus <NUM> of the edge device <NUM>.

As noted above, an edge device <NUM> does not necessarily contain a secure element <NUM> and, vice versa, a secure element <NUM> may be an edge device <NUM> as described herein.

The ROM <NUM> and/or NVM <NUM> may include a program memory <NUM> for storing programs executable by the processor <NUM>, as is illustrated in <FIG>.

<FIG> is a high-level block diagram illustrating programs located in the program memory <NUM> as well as private information located in a data memory <NUM> of the NVM <NUM>. While it is here depicted that the computer programs <NUM> are all co-located in the ROM <NUM> or the NVM <NUM>, in actual practice there is no such restriction as programs may be spread out over multiple memories and even temporarily installed in RAM <NUM>. Furthermore, the edge device <NUM> may include multiple ROMs or NVMs.

<FIG>, the data memory <NUM> is located in the memory (e.g., ROM <NUM> or NVM <NUM>) of the edge device <NUM>. In alternative embodiments, where the edge device <NUM> includes a secure element <NUM>, the data memory <NUM> is preferentially located on the secure element <NUM> thereby providing additional security to the private information.

The program memory <NUM> include card system programs <NUM>, which may include a virtual machine <NUM>, as well as, communications drivers <NUM> for communicating over the communications interface <NUM>. The card system <NUM> may also include a virtual machine or other interpreter <NUM> for executing programs stored on the edge device <NUM>.

The programs <NUM> also include a backup application <NUM> through which private data <NUM> may be backed up on other networked secure elements as described hereinbelow. The backup application <NUM> interacts with a vault-broker server application <NUM> executing on a vault-broker server <NUM> to backup the private data <NUM> on surrogate edge devices and to recover data from such surrogate edge devices.

As discussed in greater detail below, the backup application <NUM> generates encrypted backup records of the private data <NUM>, which may include cryptographic keys, transmits the encrypted backup records to the vault-broker server <NUM>, which, in turn, transmits the encrypted backup records to other edge devices <NUM>, herein called surrogate edge devices, for storage. When an edge device <NUM> is lost or damaged, a user of that edge device may recover the backup record from the surrogate edge device that stores the backup record via the vault-broker server <NUM>.

When the vault-broker server <NUM> receives a backup record from an originator edge device <NUM>, the vault-broker server <NUM> transmits that record to a surrogate edge device. The surrogate edge device receives the backup record from the vault-broker server <NUM>. The surrogate edge device <NUM> contains a surrogate application <NUM> which operates to receive such backup records from the vault-broker server <NUM> and stores the backup records <NUM> in a surrogate-backup-record memory <NUM>.

Each edge device <NUM> is provisioned by the manufacturer or the issuer of the edge device with various encryption keys and certificates <NUM>. These keys and certificates include:.

<FIG> is a high-level architecture diagram for the vault-broker server <NUM>. The vault-broker server <NUM> orchestrates the backup and recovery of private data from an edge device <NUM>. It establishes trust with the backup application <NUM> and surrogate application <NUM> on the originator edge device and the surrogate edge device and sends data and commands to these edge devices. Mechanisms for establishing trust between applications executing on devices and servers are well-known.

While the vault-broker server <NUM> connects various edge devices to one another, the private data of these edge devices <NUM> are end-to-end encrypted using the public key (EK-pub) of the edge device <NUM> while in transit (as well as when stored on surrogate edge devices). Therefore, it is not possible to discover the private data by having access to the vault-broker server <NUM> or the data stored thereon.

The primary service of the vault-broker server <NUM> is to manage the pairing between originator edge devices and surrogate edge devices in a manner that that does not breach security requirements for the critical private data.

The vault-broker server <NUM> contains a processor <NUM> and a non-volatile storage <NUM> as well as a communications interface <NUM>. The non-volatile storage <NUM> contains programs <NUM>, which include the vault-broker server application <NUM> for communicating with the corresponding backup application <NUM> of originator edge devices 201a as well as surrogate application <NUM> of surrogate edge device 201b (see, <FIG> and <FIG>).

The non-volatile storage <NUM> may also include data storage <NUM> and may be used for storing a vault-broker server database <NUM>, which links originator edge devices and the surrogate edge devices, which store backup data records <NUM> for respective originator edge devices. If a vault-broker server <NUM> manages backup of edge devices in multiple implied circles of trust, the vault-broker server <NUM> may also contain an implied circle of trust (ICT) database <NUM> which contains linkages between edge devices and ICTs. The vault-broker server <NUM>, when tasked with backing up data from an originator edge device may then determine possible surrogate edge devices within the same circle of trust as the originator edge device.

<FIG> is a data flow diagram illustrating the backup of data from an originator edge device 201a (ED-A) to a surrogate edge device 201b (ED-B) via the vault-broker server <NUM>.

The originator edge device 201a (ED-A) has the following keys associated with it:.

The surrogate edge device 201b (ED-B) has the following keys associated with it:.

While the illustrated embodiments utilize public key encryption, alternative embodiments utilize shared-secret encryption technologies.

The process of backing up critical data (CD1-A) from an originator edge device (ED-A) 201a to a surrogate edge device (ED-B) 201b via the vault-broker server <NUM> starts with the vault-broker server <NUM> selecting a surrogate device 201b from the same ICT as the originator device and requesting that surrogate edge device 201b to provide its encryption certificate (EK-cert-B), step <NUM>.

The surrogate edge device 201b verifies that the request is originating from a valid vault-broker server. This verification may be performed, for example, by using a shared secret between the vault-broker server <NUM> and the surrogate edge device 201b or by the vault-broker server <NUM> signing the request (e.g., using the Trust Key issued certificate (TK-cert-sv), which the surrogate edge device 201b can verify.

Messages below are similarly verified by the respective recipients. However, for clarity of explanation, the verification is not discussed further.

The surrogate edge device 201b replies with its encryption certificate, EK-cert-B, which contains the encryption key of the surrogate edge device 201b, EK-pub-B, step <NUM>.

The vault-broker server <NUM> requests that the originator edge device 201a exports its critical data (CD1-A), step <NUM>. The request includes the encryption certificate of the surrogate edge device (ED-B) 201b, i.e., EK-cert-B.

The originator edge device (ED-A) 201a verifies the validity of the received certificate and if it is determined to be valid, extracts the public key EK-pub-B, step <NUM>. The validation and extraction by the originator edge device 201a is possible because all edge devices <NUM> are provisioned with TK-cert and TK-pub.

A wrapping key (WK) is generated, step <NUM>. The wrapping key is used by the originator device to encrypt the critical data. The generation of the wrapping key may involve any combination of the user A <NUM>, the originator edge device 201a, and the vault-broker server <NUM>. For example, in the embodiment of <FIG> (discussed herein below), the wrapping key is based on a PIN entered by the user A <NUM>. In other embodiments, the wrapping key is generated and stored by the vault-broker server <NUM>.

One advantage of the embodiment where the wrapping key is generated and stored by the vault-broker server is to avoid the ramifications of the user <NUM> forgetting their PIN, e.g., the impossibility of recovering the backed-up data. Conversely, generating and saving the wrapping key on the vault-broker server <NUM> introduces some security risk that in some implementations may not meet security policies that only allow users to access their own data.

The originator edge device (ED-A) 201a generates a response, R, that is a response to the request to export the critical data (from step <NUM>), step <NUM>. The response R is generated using the following mechanism from the critical data (CD1-A) to be backed up:
<IMG>.

The originator edge device (ED-A) 201a transmits the response R to the vault-broker server <NUM>, step <NUM>.

The vault-broker server <NUM> forwards the response R to the surrogate edge device (ED-B) 201b as a "store data" command, step <NUM>.

The surrogate edge device (ED-B) 201b extracts the data that it is to store, step <NUM>, using the following mechanism:
<IMG>.

The surrogate edge device (ED-B) 201b stores two pieces of data as a backup record <NUM> in its surrogate-backup memory <NUM>, namely, H, the hash value, which may be computed from the wrapping key, and ED, the encryption of the critical data CD1-A, step <NUM>. However, from the information stored and available on the surrogate edge device (ED-B) 201b, it is not possible to derive the wrapping key (WK) or CD1-A using available interfaces. Furthermore, it is also not possible to know, from the perspective of the surrogate edge device (ED-B) 201b, which edge device the data belongs to. That association is only known to the vault-broker server <NUM>.

The surrogate edge device (ED-B) 201b sends a message confirming that the data extracted from R has been stored, step <NUM>.

The vault-broker server <NUM> records that the data from the originator edge device (ED-A) 201a has been successfully stored on the surrogate edge device (ED-B) 201b in the vault database <NUM>, step <NUM>. The vault database <NUM> maintains a record for each location that backup data from one edge device (originator) has been stored on another edge device (surrogate).

Data from any originator edge device (ED-A) 201a maybe stored on multiple surrogate edge devices (ED-B) 201b. Thus, the procedure of <FIG> may be repeated several times with different secure elements taking the role of the surrogate edge device (ED-B) 201b. Conversely, any surrogate edge device (ED-B) 201b may be a surrogate for multiple originator edge devices (ED-A) 201a. Thus, the procedure of <FIG> may be repeated for several edge devices each taking the role of the originator edge device (ED-A) 201a where the surrogate edge device (ED-B) 201b is one and the same surrogate edge device (ED-B) 201b. Thus, the vault database <NUM> may be a many-to-many mapping of originator edge devices (ED-A) 201a to surrogate edge devices (ED-B) 201b.

Turning now to the recovery of backed-up data from a surrogate edge device (ED-B) 201b, which is illustrated in the timing sequence diagram of <FIG> is a data-flow diagram illustrating a mechanism for recovery of data from one surrogate edge device (ED-B) 201b into another edge device <NUM>, here referred to as the target edge device (ED-A') 201a', in the same implied circle of trust. The target edge device (ED-A') 201a' does not need to be the same edge device <NUM> as the one from which the backed-up data originated. Rather, a typical application is the loss of the originator edge device (ED-A) 201a thereby necessitating the recovery of the data by the user of the originating edge device (ED-A) 201a into a new target edge device (ED-A') 201a'.

A preliminary step is that the User A' <NUM>' requests recovery of the data from the vault-broker server <NUM>, step <NUM>. This may be an out-of-band request, e.g., the user A' <NUM>' purchasing a new edge device <NUM>, the target edge device (ED-A') 201a', and requesting recovery of the data from the service operator or mobile network operator, who operates the vault-broker server <NUM>.

Typically the user A <NUM> of <FIG> is the same individual or entity as the user A' <NUM>' of <FIG>. However, one task of the surrogate ED-B 201b is to verify that. Furthermore, in embodiments in which the vault-broker server stores the wrapper key, the vault-broker server <NUM> may require authentication of the user A' <NUM>' before retrieving the wrapper key associated with the originator edge device ED-A 201a of user A <NUM>.

The vault-broker server <NUM> asks the target edge device (ED-A') 201a' for its encryption key certificate, EK-cert-A', step <NUM>.

As discussed hereinabove, the critical data is encrypted using a wrapping key (WK). To recover the data, the wrapping key must be recovered, step <NUM>. The wrapping key may, for example, have been stored by the vault-broker server. If the user demonstrates to the satisfaction of the vault-broker server that the user A' <NUM>' is the legitimate owner of the critical data stored from the originator edge device ED-A 201a, the vault-broker server retrieves the stored wrapper key (WK).

In the alternative embodiment of <FIG>, the wrapping key is generated using a one-way cryptographic function f(x) using a PIN entered by the user. The corresponding data-recovery embodiment is illustrated in <FIG>, which is discussed in greater detail hereinbelow.

The target edge device (ED-A') 201a' generates a response R' from the wrapping key WK' using the following mechanism, step <NUM>:
<IMG>.

The target edge device (ED-A') 201a' transmits the response R' to the vault-broker server <NUM>, step <NUM>.

Upon receipt of the response R', the vault-broker server <NUM> looks up which edge device <NUM> is a surrogate edge device that has stored a backup for the requested data, step <NUM>; here, the surrogate edge device (ED-B) 201b.

The vault-broker server <NUM> forwards the request R' to the surrogate edge device (ED-B) 201b, step <NUM>.

The surrogate edge device (ED-B) 201b verifies the request R', step <NUM>. The verification has several substeps:.

The rejection is reflected in the response message.

If the verification is satisfied, the edge device B 201b generates a response R2 as follows (step <NUM>):
<IMG>
<IMG>.

The surrogate edge device (ED-B) 201b sends the generated response R2, which contains either an error code or a message with a success code with the encrypted data, step <NUM>. The encrypted data (ED) is the same encrypted data as originally supplied by the originator edge device (ED-A) 201a as part of the response R generated in step <NUM> of <FIG> and transmitted as a storeData command to the surrogate edge device (ED-B) 201b in step <NUM> of <FIG>.

The vault-broker server <NUM> forward the response R2 in a recover data command, step <NUM>.

The target edge device (ED-A') 201a' extracts the data from the response R2 as follows, step <NUM>:
<IMG>.

In case the Error code was received, step <NUM>, the error count is incremented, step <NUM>. Otherwise, the CD1-A is recovered and saved in the target edge device (ED-A') 201a', step <NUM> and error count is reset to default.

Regardless of successful recovery or an error, the restore status is reported back to the vault-broker server <NUM>, step <NUM>. In the event of an error, the process may be repeated and the user A <NUM> may attempt additional wrapper-key recoveries until the threshold is exceeded. If the vault-server broker <NUM> stores the wrapper-key, there should not be any errors. However, the vault-server broker <NUM> may have some algorithmic approach to generate the wrapper key (WK'), e.g., based on a username and password, which may require repeated attempts by the user.

The process of backing up critical data (CD1-A) from an originator edge device (ED-A) 7201a to a surrogate edge device (ED-B) 7201b via the vault-broker server <NUM> starts with the vault-broker server <NUM> requesting the surrogate edge device 7201b to provide its encryption certificate (EK-cert-B), step <NUM> (Note: many steps of <FIG> and <FIG> are the same or serve an analogous purpose to corresponding steps in <FIG> and <FIG>, respectively. In <FIG> and <FIG> the reference numerals for such steps as well as the entities involved are prefixed with the numeral <NUM>. For the convenience of the reader, with that modification made, the describing text is replicated in the description of <FIG> and <FIG>).

The surrogate edge device 7201b verifies that the request is originating from a valid vault-broker server. This verification may be performed, for example, by using a shared secret between the vault-broker server <NUM> and the surrogate edge device 7201b or by the vault-broker server <NUM> signing the request (e.g., using the Trust Key issued certificate (TK-cert-sv), which the surrogate edge device 7201b can verify.

The surrogate edge device 7201b replies with its encryption certificate, EK-cert-B, which contains the encryption key of the surrogate edge device 7201b, EK-pub-B, step <NUM>.

The vault-broker server <NUM> requests that the originator edge device 7201a exports its critical data (CD1-A), step <NUM>. The request includes the encryption certificate of the surrogate edge device (ED-B) 7201b, i.e., EK-cert-B.

The originator edge device (ED-A) 7201a verifies the validity of the received certificate and if it is determined to be valid, extracts the public key EK-pub-B, step <NUM>. The validation and extraction by the originator edge device 7201a is possible because all edge devices <NUM> are provisioned with TK-cert and TK-pub.

A wrapping key (WK) is generated, step <NUM>. The wrapping key is used by the originator device to encrypt the critical data. The generation of the wrapping key may involve any combination of the user A <NUM>, the originator edge device 7201a, and the vault-broker server <NUM>. In the embodiment of <FIG>,the wrapping key is based on a PIN entered by the user A <NUM>.

To generate the wrapping key, step <NUM>', the user A <NUM> is requested to enter their PIN, step <NUM>, and the user A <NUM> enters their PIN, step <NUM>, which is sent back to the originator edge device (ED-A) 7201a in a response, step <NUM>. This PIN is used to generate a wrapping key, WK, using a cryptographic one-way function f(x), step <NUM>:
<IMG>.

The PIN is both used to generate a wrapping key to generate a response that includes the backup record of the data to be saved on the surrogate edge device 7201b and to recover the backed-up data in a data recovery operation. The PIN is used herein as a backup-retrieval code to verify that the user who seeks to recover data (as described hereinbelow) is the originating user or has authority to affect the recovery. In alternative embodiments the backup-retrieval code may be a password, a biometric, a challenge-response dialog, or any other mechanism by which the backup record may be protected.

The originator edge device (ED-A) 7201a generates a response, R, that is a response to the request to export the critical data (from step <NUM>), step <NUM>. The response R is generated using the following mechanism from the critical data (CD1-A) to be backed up:
<IMG>.

The originator edge device (ED-A) 7201a transmits the response R to the vault-broker server <NUM>, step <NUM>.

The vault-broker server <NUM> forwards the response R to the surrogate edge device (ED-B) 7201b as a "store data" command, step <NUM>.

The surrogate edge device (ED-B) 7201b extracts the data that it is to store, step <NUM>, using the following mechanism:
<IMG>.

The surrogate edge device (ED-B) 7201b stores two pieces of data as a backup record <NUM> in its surrogate-backup memory <NUM>, namely, H, the hash of the PIN of the user A <NUM>, and ED, the encryption of the critical data CD1-A, step <NUM>. However, from the information stored and available on the surrogate edge device (ED-B) 7201b, it is not possible to derive the wrapping key (WK), PIN, or CD1-A. Furthermore, it is also not possible to know, from the perspective of the surrogate edge device (ED-B) 7201b, which edge device the data belongs to. That association is only known to the vault-broker server <NUM>.

The surrogate edge device (ED-B) 7201b sends a message confirming that the data extracted from R has been stored, step <NUM>.

The vault-broker server <NUM> records that the data from the originator edge device (ED-A) 7201a has been successfully stored on ]the surrogate edge device (ED-B) 7201b in the vault database <NUM>, step <NUM>. The vault database <NUM> maintains a record for each location that backup data from one edge device (originator) has been stored on another edge device (surrogate).

Data from any originator edge device (ED-A) 7201a maybe stored on multiple surrogate edge devices (ED-B) 7201b. Thus, the procedure of <FIG> may be repeated several times with different secure elements taking the role of the surrogate edge device (ED-B) 7201b. Conversely, any surrogate edge device (ED-B) 7201b may be a surrogate for multiple originator edge devices (ED-A) 7201a. Thus, the procedure of <FIG> may be repeated for several edge devices each taking the role of the originator edge device (ED-A) 7201a where the surrogate edge device (ED-B) 7201b is one and the same surrogate edge device (ED-B) 7201b. Thus, the vault database <NUM> may be a many-to-many mapping of originator edge devices (ED-A) 7201a to surrogate edge devices (ED-B) 7201b.

Turning now to the recovery of backed-up data from a surrogate edge device (ED-B) 7201b in the embodiment in which a wrapping key is generated from a user-entered PIN, which is illustrated in the timing sequence diagram of <FIG> is a data-flow diagram illustrating a mechanism for recovery of data from one surrogate edge device (ED-B) 7201b into another edge device <NUM>, here referred to as the target edge device (ED-A') 7201a', in the same implied circle of trust. The target edge device (ED-A') 7201a' does not need to be the same edge device <NUM> as the one from which the backed-up data originated. Rather, a typical application is the loss of the originator edge device (ED-A) 7201a thereby necessitating the recovery of the data by the user of the originating edge device (ED-A) 7201a into a new target edge device (ED-A') 7201a'.

A preliminary step is that the User A' <NUM>' requests recovery of the data from the vault-broker server <NUM>, step <NUM>. This may be an out-of-band request, e.g., the user A' <NUM>' purchasing a new edge device <NUM>, the target edge device (ED-A') 7201a', and requesting recovery of the data from the service operator or mobile network operator, who operates the vault-broker server <NUM>.

Typically the user A <NUM> of <FIG> is the same individual or entity as the user A' <NUM>' of <FIG>. However, one task of the surrogate ED-B 7201b is to verify that.

The vault-broker server <NUM> asks the target edge device (ED-A') 7201a' for its encryption key certificate, EK-cert-A', step <NUM>.

As discussed hereinabove, the critical data is encrypted using a wrapping key (WK). To recover the data, the wrapping key must be recovered, step <NUM>.

In the embodiment of <FIG>, the wrapping key is generated using a one-way cryptographic function f(x) using a PIN entered by the user. The corresponding data-recovery embodiment is illustrated in <FIG>.

In the embodiment of <FIG>, the User A' <NUM>' must enter the correct PIN to recover the data. The flow of <FIG> is performed on each recovery attempt and could being viewed as inside a loop. To minimize attempts at illicit recovery of data, a PIN counter may be maintained and if a threshold has been exceeded by repeated recovery attempts, the recovery attempt is aborted. Thus, the PIN counter is checked, step <NUM>, and if it has been exceeded, the process is aborted, step <NUM>.

If the PIN counter has not been exceeded, step <NUM>, the User A' <NUM>' is asked to enter their PIN, step <NUM>. To be able to recover the data, the attempted PIN (PIN') must be the same as the PIN entered in step <NUM> to generate the backup record <NUM>. The User A <NUM>' enters the attempted PIN', step <NUM>, and it is transmitted to the target edge device (ED-A') 7201a', step <NUM>.

The wrapper key is then generated from the attempted PIN, step <NUM>:
<IMG>.

The target edge device (ED-A') 7201a' generates a response R' from the attempted PIN' using the following mechanism, step <NUM>:
<IMG>.

In the user-entered PIN alternative embodiment, the H' value may be computed from the attempted PIN rather than from the wrapper key, WK', i.e.:
<IMG>.

The target edge device (ED-A') 7201a' transmits the response R' to the vault-broker server <NUM>, step <NUM>.

Upon receipt of the response R', the vault-broker server <NUM> looks up which edge device <NUM> is a surrogate edge device that has stored a backup for the requested data, step <NUM>; here, the surrogate edge device (ED-B) 7201b.

The vault-broker server <NUM> forwards the request R' to the surrogate edge device (ED-B) 7201b, step <NUM>.

The surrogate edge device (ED-B) 7201b verifies the request R', step <NUM>. The verification has several substeps:.

If the verification is satisfied, the edge device B 7201b generates a response R2 as follows (step <NUM>):
<IMG>.

The surrogate edge device (ED-B) 7201b sends the generated response R2, which contains either an error code or a message with a success code with the encrypted data, step <NUM>. The encrypted data (ED) is the same encrypted data as originally supplied by the originator edge device (ED-A) 7201a as part of the response R generated in step <NUM> of <FIG> and transmitted as a storeData command to the surrogate edge device (ED-B) 7201b in step <NUM> of <FIG>.

The target edge device (ED-A') 7201a' extracts the data from the response R2 as follows, step <NUM>:
<IMG>.

In case the Error code was received, step <NUM>, the PINCounter is incremented. Otherwise, the CD1-A is recovered and saved in the target edge device (ED-A') 7201a', step <NUM>.

Regardless of successful recovery or an error, the restore status is reported back to the vault-broker server <NUM>, step <NUM>. In the event of an error, the process may be repeated and the user A <NUM> may attempt additional PIN entries until the threshold is exceeded.

From the foregoing it will be apparent that an efficient and secure mechanism for backing up and recovering private data stored on secure elements is provided.

Claim 1:
A method for backing up critical data (CD1-A) stored on an originator edge device (<NUM>, 201a, ED-A) associated with a user such that the backed up critical data maybe recovered onto a target device (<NUM>, 201a', ED-A'), the method comprising:
requesting, by the vault-broker server (<NUM>), the originator edge device to create an export backup record of critical data stored on the originator edge device;
generating a wrapping key (WK);
generating, by the originator edge device, the backup record (R) in response to the request for the export backup record, the backup record being a function of the wrapping key, a cryptographic key, and the critical data being backed up;
transmitting a backup-response message including the backup record, by the originator edge device to the vault-broker server;
transmitting the backup-response message including the backup record by the vault-broker server to a surrogate edge device;
storing the backup record on the surrogate edge device (<NUM>, 201b, ED-B);
wherein from the information stored and available on the surrogate edge device, it is not possible to derive the WK or the backed up critical data (CD1-A) using available interfaces; and
storing an association between the originator edge device and the surrogate edge device on the vault-broker server.