Patent Application
20220271933
This disclosure relates generally to data backup and recovery. More specifically, this disclosure relates to a system and method for device to device secret backup and recovery.
End users usually have various types of confidential data, can be referred to as “secrets,” including but not limited to the following: (i) login credentials (for example, username and password and/or portable authentication tokens), such as for a SAMSUNG account or WiFi hotspot or bank account; (ii) text phrases, cryptocurrency wallet recovery phrases; and (iii) encryption keys (for example, cryptocurrency keys or private keys). These secrets are so important that losing them will be very costly to the owner of the secrets. Ideally, a user would be able to backup and recover such information in a way to minimize the risk of losing the secret or its concealment.
This disclosure provides a system and method for device to device secret backup and recovery.
In a first embodiment, a method executed by a first electronic device is provided. The method includes splitting a selected secret for backup into N secret shares in a trusted execution environment (TEE) of the first electronic device. The method includes transferring, via the transceiver over a short-range transmission, the N secret shares to N trustee devices, by transferring each secret share from among the N shares to a different trustee device from among N trustee devices. Each secret share is configured to, when received by a trustee device, cause the trustee device to store the secret share in a TEE of the trustee device. The method includes receiving, from the trustee electronic device, one of an acknowledgement confirming the transferred secret share is stored in the TEE of the trustee electronic device or an error warning the transferred secret share is not stored in the TEE of the trustee electronic device.
In a second embodiment, an electronic device is provided. The electronic device functions as a source electronic device, and is referred to as a “source/recovery electronic device” when additionally functioning as a recovery electronic device. The electronic device includes a transceiver, a processor, and a memory. The processor is coupled to the transceiver and to the memory. The memory stores instructions that, when executed by the processor, cause the processor to perform device to device secret backup and recovery processes. Particularly, the instructions cause the processor to split a selected secret for backup into N secret shares in a trusted execution environment (TEE) of the electronic device. The instructions also cause the processor to transfer, via the transceiver over a short-range transmission, the N secret shares to N trustee devices, by transferring each secret share from among the N secret shares to a different trustee device from among the N trustee devices. Each secret share is configured to, when received by a trustee device, cause the trustee device to store the secret share in a TEE of the trustee device. The instructions further cause the processor to receive, from the trustee electronic device, one of an acknowledgement confirming the transferred secret share is stored in the TEE of the trustee electronic device or an error warning the transferred secret share is not stored in the TEE of the trustee electronic device.
In a third embodiment, a trustee electronic device is provided. The trustee electronic device includes a transceiver, a processor, and a memory. The transceiver is configured to perform short-range communications. The processor is coupled to the transceiver and to the memory. The memory stores instructions that, when executed by the processor, cause the processor to perform device to device secret backup and recovery processes. Particularly, the instructions cause the processor to establish a short-range communications connection to a source electronic device. The instructions also cause the processor to receive a secret share from a trusted execution environment (TEE) of the source electronic device over the short-range communication connection, the secret share being one from among N secret shares generated by the source electronic device. The instructions also cause the processor to check whether the received secret share is secure. The instructions also cause the processor to, in response to determining the received secret share is secure, store the secret share in a TEE of the trustee electronic device and transmit an acknowledgement to the source electronic device confirming the received secret share is stored in the TEE of the trustee electronic device. The instructions further cause the processor to, in response to determining the received secret share is not secure, transmit an error signal to the source electronic device warning the received secret share is not stored in the TEE of the trustee electronic device.
Other technical features may be readily apparent to one skilled in the art from the following figures, descriptions, and claims.
Before undertaking the DETAILED DESCRIPTION below, it may be advantageous to set forth definitions of certain words and phrases used throughout this patent document. The term “couple” and its derivatives refer to any direct or indirect communication between two or more elements, whether or not those elements are in physical contact with one another. The terms “transmit,” “receive,” and “communicate,” as well as derivatives thereof, encompass both direct and indirect communication. The terms “include” and “comprise,” as well as derivatives thereof, mean inclusion without limitation. The term “or” is inclusive, meaning and/or. The phrase “associated with,” as well as derivatives thereof, means to include, be included within, interconnect with, contain, be contained within, connect to or with, couple to or with, be communicable with, cooperate with, interleave, juxtapose, be proximate to, be bound to or with, have, have a property of, have a relationship to or with, or the like. The term “controller” means any device, system or part thereof that controls at least one operation. Such a controller may be implemented in hardware or a combination of hardware and software and/or firmware. The functionality associated with any particular controller may be centralized or distributed, whether locally or remotely. The phrase “at least one of,” when used with a list of items, means that different combinations of one or more of the listed items may be used, and only one item in the list may be needed. For example, “at least one of: A, B, and C” includes any of the following combinations: A, B, C, A and B, A and C, B and C, and A and B and C.
Moreover, various functions described below can be implemented or supported by one or more computer programs, each of which is formed from computer readable program code and embodied in a computer readable medium. The terms “application” and “program” refer to one or more computer programs, software components, sets of instructions, procedures, functions, objects, classes, instances, related data, or a portion thereof adapted for implementation in a suitable computer readable program code. The phrase “computer readable program code” includes any type of computer code, including source code, object code, and executable code. The phrase “computer readable medium” includes any type of medium capable of being accessed by a computer, such as read only memory (ROM), random access memory (RAM), a hard disk drive, a compact disc (CD), a digital video disc (DVD), or any other type of memory. A “non-transitory” computer readable medium excludes wired, wireless, optical, or other communication links that transport transitory electrical or other signals. A non-transitory computer readable medium includes media where data can be permanently stored and media where data can be stored and later overwritten, such as a rewritable optical disc or an erasable memory device.
Definitions for other certain words and phrases are provided throughout this patent document. Those of ordinary skill in the art should understand that in many if not most instances, such definitions apply to prior as well as future uses of such defined words and phrases.
For a more complete understanding of the present disclosure and its advantages, reference is now made to the following description taken in conjunction with the accompanying drawings, in which like reference numerals represent like parts:
General data backup solution usually makes one or more duplicated copies of the original data and stores the duplicated copies in a separate place (e.g., in remote media such as email or a storage in cloud storage device or in local media. Examples of local media include paper, a board (e.g., chalkboard, white-board for markers, cork board), computer storage on a mobile device, personal computer, external hard drive and etc. Applying this technique of storing the duplicated copies in a place separate from the original data as a technique of backing-up a secret is problematic.
As a first problem for backing up, making duplicated copies will always increase the risk of data being hacked/exposed to unauthorized parties. However, the more copies, the better redundancy. Therefore, techniques of backing-up a secret involve a conflict between security and redundancy, which conflict is a common problem for both remote backup and local backup.
As a second problem for backing up, remote backup and recovery often requires the owner of the original data (which may include customer's confidential data that belongs to a customer of a cloud computing service) to trust the remote server. As in most cases, the remote server has the access to the backup, and in some cases, the owner of the remote server has access to data stored on the remote server. Such access enables a malicious insider (e.g., an employee for the owner of the remote server) to view and expose the customer's confidential data. A remote server is often a popular target of hackers as it stores a lot of data. Any hack or data breach on the server could result in the leakage of backed-up customer's confidential data, and it is practically impossible to track where the leaked secret flows. In some scenarios, remote backup and recovery services are provided by a remote server owned by a corporation that ceases to offer (e.g., terminates) the remote backup and recovery services or that experiences a life cycle end (e.g., goes out of business). Such termination of remote backup and recovery services causes an owner of a secret to no longer have control to protect the backed-up secret from an undesirable successor of the corporation.
As a third problem for backing up, remote backup and recovery often requires availability of network (e.g., Internet access). However, transferring customer's confidential data could be eavesdropped or intercepted, or tampered by man-in-the-middle attacks. Additionally, the network might not always be available.
As a fourth problem for backing up, backup to and recovery from remote storage usually requires a credential, such as a cloud account ID and password, to control or limit access to the referred storage. This credential usually requires the user (e.g., customer of cloud computing service) to memorize, which adds additional burdens to the user.
Embodiments of the present disclosure split a user-selected secret for backup into a plurality of shares within a trusted execution environment (TEE); and transfer, via a transceiver on the device over short-range transmission, the plurality of shares to a plurality of trustee devices. Each share of the secret is transferred to a different trustee device to be stored in the trustee device's trusted execution environment (TEE). In certain embodiments of this disclosure, an electronic device that is owned by a trustee is interchangeably referred to as a trustee device, a trustee's device, or a trustee electronic device.
Regarding the conflict between security and redundancy, certain embodiments of this disclosure provide a custom level of security. The backup and recovery of the data is well protected such that it cannot be accessed by (or exposed to) unauthorized entities. Embodiments of this disclosure also provide a custom level of redundancy. The backup of data has enough redundancy such that the recovery is always available even when some data backup is inevitably damaged and/or lost.
In certain embodiments of this disclosure, a device-to-device (D2D) system performs backup and recovery of a secret without using a remote server. According to embodiments of this disclosure, the system includes a secret owner's device (called as “source device” in backup and “recovery device” in recovery) and a set of trustee devices located within a physical proximity to the secret owner's device. The recovery device could be the same device as the source device, or a different device than the source device. For example, when user loses the source device, the user might need to recover the secret to a new device as recovery device. Each device (source, recovery, and trustee) has a processor supporting a trusted execution environment (TEE), a biometric authenticator, a data I/O interface and a short-range communication component. The devices can be easily and physically accessed by the secret owner according to the device owners' permission and awareness.
In certain embodiments, device-to-device secret backup and recovery processes include performing actions to securely pair the source/recovery device with trustee device using a key negotiated between TEE of source/recovery device and TEE of trustee device via short-range communication. In order to backup a secret, the source device receives (e.g., from user input) a secret into its TEE, splits the secret into a predefined number of pieces called as secret shares within source device's TEE, and transfers the secret shares to multiple trustee devices for storage within the trustee device's TEE. In order to recover the secret, a recovery device requests secret shares from multiple trustee devices; identifies and removes the incorrect secret shares until a predefined number of correct secret shares are received; and reconstructs the secret from the predefined number of correct secret shares.
In certain embodiments, in order to securely pair the source/recovery device with trustee device, the user of the source/recovery device designates a set of devices as trust devices; and the source/recovery device and each of the trustee devices establish a trustor-trustee relationship via short-range device-to-device communication. User authentication is required at the beginning of device pairing. The source/recovery device maintains a list of trustee devices. Each trustee device maintains a list of corresponding source/recovery devices that are designated as a trustor. Accordingly, embodiments of this disclosure prevent the owners of the source/recovery device and trustee device from being burdened with memorizing who are the trustees and trustor of each secret. In certain embodiments of this disclosure, a biometric authenticator performs the user authentication, which reduces the memorization burden of the owners of the source/recovery device and trustee device, who are no longer required to remember a username, password, or personal identification number (PIN) to interact with backup and recovery processes.
In certain embodiments, a secret backup from one source device to multiple trustee device (1-to-multiple backup scenario) is enabled. A secure device pairing can be completed before a secret backup is initiated. The secret is split into several pieces of secret shares such that a minimum number of secret shares are required to combine in order to recover the original secret. Each secret share is encrypted by the key only known by the user of the source device. The checksums of all shares and a signature is appended to each share. The user of the source device designates a trustee device for each secret share. The information of all these designations is appended to each share. The shares are then transferred to their designated trustee devices. Each trustee device encrypts the received secret share using a key known only by trustee device's owner. The transfer of the share occurs via short-range device-to-device communication.
In certain embodiments, a secret recovery from multiple trustee device to a recovery device (1-to-multiple recovery scenario) is enabled. A secure device pairing can be completed before secret recovery. The recovery device requests a secret share from a trustee device selected by a user of the recovery device. The trustee device decrypts the secret share and transfers it to the recovery device via short-range device-to-device communication. The recovery device reads the list of designations among secret shares and trustee devices from the appended info, and such designation info will be provided to user. When receiving a secret share from a trustee device, the recovery device checks if it has received the required minimum number of secret shares for recovering the original secret. If the minimum number has not been received, the recovery device continues to request a secret share from another trustee device. If the minimum number has been received, the source device performs a majority vote to determine the correct hash information of secret shares. If all received secret shares have the correct hashes, the recovery device reconstructs (e.g., tries to recover) the original secret. If some secret shares have incorrect hashes, the recovery device removes those incorrectly-hashed secret shares, and continues to request a secret share from another trustee device. The recovery device repeats this process until either the secret is recovered or no more trustee devices remain, in which case the recovery fails.
Embodiments of this disclosure provide on-device key management, which includes deriving (e.g., creating or generating) a key pair from user authentication in the TEE of the device. By utilizing the derived key pair, the source device and one trustee device negotiate a communication encryption key (KC) to establish a short-range communication channel between each other. The on-device key management of this disclosure does not require a key management server.
Embodiments of this disclosure provide confidentiality. Data stored in on-device storage is always encrypted by the key derived from user authentication. Data being communicated between a source/recovery device and a trustee device is always encrypted by the communication encryption key KC. Only the original secret owner can decrypt the secret share and secret.
As introduced above, embodiments of this disclosure provide customized security. An original secret is split into a number (N) of non-identical secret shares and shares are distributed into multiple devices. A number (K) of trustee devices are required to recovery secret. If the value of K is two (2), then a 1-to-2 scenario occurs, but if the value of K is one (1), then a 1-to-1 scenario occurs. Thus, the original secret is only exposed if at least K secret shares are exposed from K trustee devices. By requiring user authentication on both the source device and trustee devices, the risk of exposing secret shares is reduced. Short-range communication is adopted to avoid man-in-the-middle attacks and thereby avoid the need of a CA.
As introduced above, embodiments of this disclosure provide customized redundancy. The secret share has redundancy such that the damage to a user-configurable number of secret shares for any reason can be tolerated. Embodiments of this disclosure provide a UI to guide user through the setup process, to configure various settings, and to show the meta information about the backup and recovery, such as time, trust device list, etc.
An electronic device, according to embodiments of the present disclosure, can implement a trusted execution environment (TEE), such as in a secure area of a main processor and a secure area under control of an operating system. A TEE can act as an isolated execution environment to provide security features such as isolated execution, integrity of applications executing with the TEE, along with confidentiality of application assets. The TEE may be a secure operating environment and may include a hardware component and a software component (e.g., an ARM TRUSTZONE operating environment). In general, the TEE may execute secure applications, with limited access to other elements and components of the electronic device. Similarly, non-secure applications executing outside the trusted execution environment have limited or no access to secure applications executing inside the trusted execution environment.
In various disclosed embodiments, the TEE can include one or more trusted applications (“trusted apps”). The trusted apps in the TEE can include device authenticator trusted apps that collect user authentication data. The trusted apps in the TEE can include an authentication trusted app that performs such functions as collecting and integrating user authentication data and verifying its validity. The trusted apps in the TEE can include payment trusted apps that, when properly authorized, perform payment processing according to requirements of a financial service provider (for example, a bank, credit card payment processors, or other financial service providers). The trusted apps in the TEE can include trusted device-to-device (D2D) secret backup and recovery apps that, when properly authorized, (i) backups a secret with sufficient security such that the secret cannot be accessed by or exposed to unauthorized entities (for example, unauthorized persons) and with sufficient redundancy such that recovery is available when some data backup is inevitably damaged and/or lost and; and (ii) recovers the backed-up secret from an external device. The trusted apps in the TEE can include other trusted apps, such as key storage trusted apps, and others.
According to embodiments of this disclosure, an electronic device 101 is included in the communication system 100. The electronic device 101 can include at least one of a bus 110, a processor 120, a memory 130, an input/output (I/O) interface 150, a display 160, a communication interface 170, and one or more sensors 180. In some embodiments, the electronic device 101 may exclude at least one of these components or may add at least one other component. The bus 110 includes a circuit for connecting the components 120-180 with one another and for transferring communications (such as control messages and/or data) between the components.
The processor 120 includes one or more of a central processing unit (CPU), a graphics processor unit (GPU), an application processor (AP), or a communication processor (CP). The processor 120 is able to perform control on at least one of the other components of the electronic device 101 and/or perform an operation or data processing relating to communication. In certain embodiments, the processor 120 performs device-to-device secret backup and recovery processes as described herein.
The memory 130 can include a volatile and/or non-volatile memory. For example, the memory 130 can store commands or data related to at least one other component of the electronic device 101. According to embodiments of this disclosure, the memory 130 can store software and/or a program 140. The program 140 includes, for example, a kernel 141, middleware 143, an application programming interface (API) 145, and/or an application program (or “application”) 147. At least a portion of the kernel 141, middleware 143, or API 145 may be denoted as an operating system (OS). Different portions of memory 130 and/or a memory in processor 120 can be designated for use as a trusted execution environment (TEE).
The kernel 141 can control or manage system resources (such as the bus 110, processor 120, or memory 130) used to perform operations or functions implemented in other programs (such as the middleware 143, API 145, or application 147). The kernel 141 provides an interface that allows the middleware 143, the API 145, or the application 147 to access the individual components of the electronic device 101 to control or manage the system resources. The application 147 includes one or more applications for trusted device-to-device (D2D) secret backup and recovery functions as discussed below. These functions can be performed by a single application or by multiple applications that each carries out one or more of these functions. The middleware 143 can function as a relay to allow the API 145 or the application 147 to communicate data with the kernel 141, for instance. A plurality of applications 147 can be provided. The middleware 143 is able to control work requests received from the applications 147, such as by allocating the priority of using the system resources of the electronic device 101 (like the bus 110, the processor 120, or the memory 130) to at least one of the plurality of applications 147. The API 145 is an interface allowing the application 147 to control functions provided from the kernel 141 or the middleware 143. For example, the API 145 includes at least one interface or function (such as a command) for filing control, window control, image processing, or text control.
The I/O interface 150 serves as an interface that can, for example, transfer commands or data input from a user or other external devices to other component(s) of the electronic device 101. The I/O interface 150 can also output commands or data received from other component(s) of the electronic device 101 to the user or the other external device.
In some embodiments, the electronic device 101 further includes one or more speakers that convert electrical signals into sound. The speakers can be housed within a housing of the electronic device 101. The speakers can be connected to the bus 110 directly or indirectly through an intermediate connection to the I/O interface 150.
The display 160 includes, for example, a liquid crystal display (LCD), a light emitting diode (LED) display, an organic light emitting diode (OLED) display, a quantum-dot light emitting diode (QLED) display, a microelectromechanical systems (MEMS) display, or an electronic paper display. The display 160 can also be a depth-aware display, such as a multi-focal display. The display 160 is able to display, for example, various contents (such as text, images, videos, icons, or symbols) to the user. The display 160 can include a touchscreen and may receive, for example, a touch, gesture, proximity, or hovering input using an electronic pen or a body portion of the user.
The communication interface 170, for example, is able to set up communication between the electronic device 101 and an external electronic device (such as an electronic device 102, a third electronic device 104, or a server 106). For example, the communication interface 170 can be connected with a network 162 or 164 through wireless or wired communication to communicate with the external electronic device. The communication interface 170 can be a wired or wireless transceiver or any other component for transmitting and receiving signals, such as images.
The wireless communication is able to use at least one of, for example, long term evolution (LTE), long term evolution-advanced (LTE-A), 5th generation wireless system (5G), millimeter-wave or 60 GHz wireless communication, Wireless universal serial bus (USB), code division multiple access (CDMA), wideband code division multiple access (WCDMA), universal mobile telecommunication system (UMTS), wireless broadband (WiBro), or global system for mobile communication (GSM), as a cellular communication protocol. The wired connection can include, for example, at least one of a USB, high-definition multimedia interface (HDMI), recommended standard 132 (RS-232), or plain old telephone service (POTS). The network 162 or 164 includes at least one communication network, such as a computer network (like a local area network (LAN) or wide area network (WAN)), Internet, or a telephone network.
The communication interface 170 is able to set up device-to-device (D2D) communication between the electronic device 101 and an external electronic devices 102 and 104. The D2D communication can be Bluetooth Low Energy (BLE) communication, near-field communication, or other short-range communication.
The electronic device 101 further includes one or more sensors 180 that can meter a physical quantity or detect an activation state of the electronic device 101 and convert metered or detected information into an electrical signal. For example, one or more sensors 180 can include one or more cameras or other imaging sensors for capturing images of scenes. The sensor(s) 180 can also include one or more buttons for touch input, a gesture sensor, a gyroscope or gyro sensor, an air pressure sensor, a magnetic sensor or magnetometer, an acceleration sensor or accelerometer, a grip sensor, a proximity sensor, a color sensor (such as a red green blue (RGB) sensor), a bio-physical sensor, a temperature sensor, a humidity sensor, an illumination sensor, an ultraviolet (UV) sensor, an electromyography (EMG) sensor, an electroencephalogram (EEG) sensor, an electrocardiogram (ECG) sensor, an infrared (IR) sensor, an ultrasound sensor, an iris sensor, or a fingerprint sensor. The sensor(s) 180 can further include an inertial measurement unit, which can include one or more accelerometers, gyroscopes, and other components. The sensor(s) 180 can include an audio sensor, such as a microphone, that convert sound into electrical signals. Example microphones include a dynamic microphone, a condenser microphone, a piezoelectric microphone, or the like. In addition, the sensor(s) 180 can include a control circuit for controlling at least one of the sensors included here. Any of these sensor(s) 180 can be located within the electronic device 101.
The sensor(s) 180 can be used as input devices for user authentication, such as implementing a touchscreen or buttons for receiving passcodes, PINs, or patterns, a fingerprint sensor for scanning a user's fingerprint, a camera for iris or facial recognition, and the like.
The external electronic devices 102 and 104 can include the same or similar components 110-180 as the electronic device 101 (or a suitable subset thereof). The electronic device 101 can be directly connected with the second electronic device 102 to communicate with the second electronic device 102 without involving with a separate network.
The external electronic devices 102 and 104 and the server 106 each can be a device of the same or a different type from the electronic device 101. According to certain embodiments of this disclosure, the server 106 includes a group of one or more servers. Also, according to certain embodiments of this disclosure, all or some of the operations executed on the electronic device 101 can be executed on another or multiple other electronic devices (such as the external electronic devices 102 and 104 or server 106). Further, according to certain embodiments of this disclosure, when the electronic device 101 should perform some function or service automatically or at a request, the electronic device 101, instead of executing the function or service on its own or additionally, can request another device (such as external electronic devices 102 and 104 or server 106) to perform at least some functions associated therewith. The other electronic device (such as external electronic devices 102 and 104 or server 106) is able to execute the requested functions or additional functions and transfer a result of the execution to the electronic device 101. The electronic device 101 can provide a requested function or service by processing the received result as it is or additionally. To that end, a cloud computing, distributed computing, or client-server computing technique may be used, for example. While
The server 106 can include the same or similar components 110-180 as the electronic device 101 (or a suitable subset thereof). The server 106 can support to drive the electronic device 101 by performing at least one of operations (or functions) implemented on the electronic device 101. For example, the server 106 can include a processing module or processor that may support the processor 120 implemented in the electronic device 101. In certain embodiments, the server 106 performs the natural language processing. In certain embodiments, the server 106 performs various services, including secure data transfer with a cloud storage provider or single sign-on (SSO) services.
Although
As shown in
The RF transceiver 210 receives, from the antenna 205, an incoming RF signal transmitted by an eNB of the communication system 100. The RF transceiver 210 down-converts the incoming RF signal to generate an intermediate frequency (IF) or baseband signal. The IF or baseband signal is sent to the RX processing circuitry 225, which generates a processed baseband signal by filtering, decoding, and/or digitizing the baseband or IF signal. The RX processing circuitry 225 transmits the processed baseband signal to the speaker 230 (such as for voice data) or to the main processor 240 for further processing (such as for web browsing data).
The TX processing circuitry 215 receives analog or digital voice data from the microphone 220 or other outgoing baseband data (such as web data, e-mail, or interactive video game data) from the main processor 240. The TX processing circuitry 215 encodes, multiplexes, and/or digitizes the outgoing baseband data to generate a processed baseband or IF signal. The RF transceiver 210 receives the outgoing processed baseband or IF signal from the TX processing circuitry 215 and up-converts the baseband or IF signal to an RF signal that is transmitted via the antenna 205.
The main processor 240 can include one or more processors or other processing devices and execute the basic OS program 261 stored in the memory 260 in order to control the overall operation of the electronic device 200. For example, the main processor 240 could control the reception of forward channel signals and the transmission of reverse channel signals by the RF transceiver 210, the RX processing circuitry 225, and the TX processing circuitry 215 in accordance with well-known principles. In some embodiments, the main processor 240 includes at least one microprocessor or microcontroller.
The main processor 240 is also capable of executing other processes and programs resident in the memory 260. The main processor 240 can move data into or out of the memory 260 as required by an executing process. In some embodiments, the main processor 240 is configured to execute the applications 262 based on the OS program 261 or in response to signals received from eNBs or an operator. The main processor 240 is also coupled to the I/O interface 245, which provides the electronic device 200 with the ability to connect to other devices such as laptop computers and handheld computers. The I/O interface 245 is the communication path between these accessories and the main processor 240.
The main processor 240 is also coupled to one or more input devices 250 (e.g., keypad) and to one or more output devices 255 (e.g., electronic display illustrated as “DISPLAY”). The operator of the electronic device 200 can use a keypad input device 250 to enter data into the electronic device 200. The output device 255, as a display, may be a liquid crystal display or other display capable of rendering text and/or at least limited graphics, such as from web sites.
The memory 260 is coupled to the main processor 240. Part of the memory 260 could include a random access memory (RAM), and another part of the memory 260 could include a Flash memory or other read-only memory (ROM).
As described in more detail below, the main processor 240 accesses instructions (e.g., computer program code) stored in the memory 260, and by executing the instructions, performs device-to-device secret backup and recovery processes according to this disclosure.
Although
The electronic device 301 includes a trusted execution environment (TEE) 302 and a non-secure execution environment 304. As examples, the TEE 302 can be implemented using ARM TRUSTZONE technology or INTEL software guard extensions (SGX).
The components of the electronic device 301 that are outside of the TEE 302 are included in the non-secure execution environment 304. The non-secure execution environment 304 includes a user interface 306 and a communicator 308. The user interface 306 is executed (for example, runs) outside the trusted environment. The user interface 306 represents the output device 255 of
The communicator 308 includes a local connection driver 382, which provides secure communication with devices in proximity to the electronic device 301. The local connection driver 382 can perform short-range communication using near field communication (NFC) 382a, WiFi 382b, USB connection 382c, BLUETOOTH paired connection 382d, or QR code 382e. The communicator 308 includes a remote connection driver 384, which provides secure communication with a remote machine (for example, server 106) or cloud services. The remote connection driver 384 enables remote access 384a, allowing the electronic device 301 to perform secure data transfer with a remote device. In a non-limiting example, the owner of electronic device 301 is also the owner of a work personal computer (PC), and remote connection driver 384 enables electronic device 301 to perform secure data transfer with the work PC via Secure Shell Protocol (SSH), or with a friend's device (for example, third electronic device 104) in a different city. The remote connection driver 384 enables cloud integration 384b, allowing the electronic device 301 to perform secure data transfer with a cloud storage provider, such as DROPBOX.
The TEE 302 includes a trusted user interface 310, an authenticator 320, a data manager 330, a processor 340, a security enforcer 350, and a data transferer 360. More particularly, within TEE 302 are trusted apps, which can be the same as or similar to the secret vault app 263 of (
The trusted user interface 310 is a user interface running in the trusted environment. For simplicity, the trusted user interface 310 shown in
The trusted user interface 310 provides various trusted user interfaces that prompt and enable a user to provide input to the trusted input 312. More particularly, the trusted display 314 outputs trusted user interfaces through the user interface 306, for example, by calling (as illustrated by the bidirectional call arrow 370) the user interface 306 for rendering. The trusted display 314 allows the recovered secret to be shown to the user or to be exported to an app.
When the user initiates a secret backup through UI 306, UI 306 calls trusted input 312 to obtain input from the user and forwards the input to other components in the TEE 302. When the user initiates a secret recovery through UI 306, UI 306 calls the trusted input 312 to obtain the user request (for example, a user-selection of which secret to be recovered). After the secret is recovered in TEE 302, the trusted display 315 shows the recovered secret to the user or exports the recovered secret to an app.
The authenticator 320 can include device authenticator trusted apps that collect user authentication data. The user authentication data can include biometric data such as fingerprints, iris images, facial images, or a combination thereof. The user authentication data can include gatekeeper data such as previously-registered/reference PINs, passcodes, patterns, and others. The authenticator 320 authenticates the user's identity to ensure that authorization from the user has been received.
The data manager 330 manages trustees' information, user configurations, information about secrets, information about shares, and other metadata. The processor 340 can be a secure area of a main processor (for example, processor 120 of
Now refer to
The data manager 330 includes trustee manager 331, configuration manager 332, secret manager 333, share manager 334, metadata manager 335, and storage 336. The trustee manager 331 manages information about the user's trustees and the trustees' devices. For example, trustee manager 331 of a source/recovery device maintains a list of trustee devices. Also, the trustee manager 331 of each trustee device maintains a list of corresponding source/recovery devices.
The configuration manager 332 manages user-adjustable configuration settings for each secret. The configuration settings can be applied to a group of secrets such that each secret has the same configuration settings. Alternatively, configuration settings can be applied to each secret, individually, such that configuration settings applicable to one secret may differ from the configuration applicable to another secret. For each secret, the configuration settings include the number of shares to distribute (herein defined as “n”), the number of shares needed for recovery (herein defined as “k”), and a trustee grouping. As a non-limiting example, a trustee grouping may include two external devices (102 and 104), such as, one family's device and one friend's device. That is, the family's device (102) can be owned by the family of the owner of the electronic device 301, which family member may cohabitate with the owner of the electronic device 301. The friend's device (104) can be owned by a friend of the owner of the electronic device 301, which friend may live in a different city or in the same neighborhood as the owner of the electronic device 301. As another non-limiting example, a trustee grouping may include one external device (102), such as, an old smartphone or old personal laptop or work PC that is owned by the same owner of the electronic device 301.
The secret manager 333 manages information about each secret that is backed up, including but not limited to: (i) create time; (ii) usage; (iii) owner of secret; and (iv) trustees (namely, who and what devices store the shares of this secret). The creation time is a date and timestamp of when a secret was backed up. The usage identifies the purpose of the secret, for example, usage for bank account logins or usage for crypto wallet key mnemonic paraphrase. The owner of electronic device 301 might be helping someone else to back-up their secret. Accordingly, for each secret, the owner of the secret identifies an owner, which distinguishes the owner of the electronic device 301 from other owners of secrets (e.g., friends, family, co-workers, neighbors, confidants of the electronic device 301).
The share manager 334 manages information about each share of each secret, including but not limited to: (i) receive time that indicates when the share was received to this electronic device 301; (ii) owner of the share; and (iii) sender of the share. The share may be sent from the owner or may be forwarded by another trustee. The owner of the share is the owner of the secret from which the share was generated.
The metadata manager 335 manages all other metadata including but not limited to: (i) trustees; (ii) data transfer log; (iii) activity log; and (iv) statistics. The trustees include a list of paired trustees and the trustee's device information. The data transfer log includes timestamps and connection types of each interaction with other devices. The activity log includes a logbook or register of which app accessed the secret and a date/timestamp of when the secret was access by the app. The statistics include a number of trustees, a number of secrets, a number of shares on each trustee's device, and the like.
The storage 336 provides secure data storage for shares, configuration settings, and the like. In certain embodiments, the storage 336 is a database.
The processor 340 includes an algorithm selector 342, a share generator 344, and a secret recoverer (“secret recovery module”) 346. The algorithm selector 342 selects which algorithms to use for secret backup and recovery according to a security policy. Example security policies include a Shamir secret sharing, multi-signature, and the like. Any algorithm can be selected if the algorithm supports all four of the following: (1) backup a secret to N trustees; (2) no trustee can see (i.e., access or be exposed to a raw/non-encrypted version of) the secret; (3) any subset of K trustee devices (wherein K≤N) that store a share of the secret can work together to recover or reconstruct the secret from K secret shares; and (4) any j trustees (where j is fewer than K trustee devices (j<K)) that store a share of the secret cannot recover the secret by working together or alone.
The share generator 344 generates shares for a given secret by following the user-adjustable configuration settings and by executing the selected algorithm, which is selected by the algorithm selector 342. Analogously, the secret recovery module 346 reconstructs a secret from shares by following the user-adjustable configuration settings and by executing the selected algorithm, which is selected by the algorithm selector 342.
In a non-limiting example, the share generator 344 generates five (5) shares according to user-adjustable configuration settings that specify n=5 and k=3, as shown in
The security enforcer 350 includes encryption/decryption module 352 (illustrated as encrypter & decrypter), error detector and corrector 354, context monitor 356, and policy manager 358. The encryption/decryption module 352 ensures only the TEE 302 can see or access the data (i.e., secrets, shares, configuration settings, and the like) used for device-to-device secret backup and recovery processes. That is, the encryption/decryption module 352 ensures such that the non-secure execution environment 304 and no other unauthorized entity outside the TEE 302 can see the data used for device-to-device secret backup and recovery processes. The encryption/decryption module 352 provides confidentiality to TEE 302, such that when data is provided by the user via trusted UI 310, the user-inputted data will be encrypted and stay encrypted inside the TEE 302. When data is exported out of the TEE 302, the data is decrypted by the encryption/decryption module 352. The encryption/decryption module 352 provides confidentiality to data transfers to/from the TEE 302, such that before data is transferred from electronic device 301 to another device (e.g., 102, 104, 106), the communicator 308 creates an encrypted channel between the two devices' TEEs, so that data transfer is confidential. That is, the encryption/decryption module 352 cooperates with data transferer 360 and communicator 308 to create an encrypted channel between the TEE 302 of electronic device 101 and another TEE (like TEE 302) of an external electronic device 102, 14, 106. Confidential data, including but not limited to the secrets and shares (e.g., 402 and 404 of
The error detector and corrector 354 protects data integrity when data is transferred between owner and trustees, and prevents trustees from modifying the data. In certain embodiments, the error detector and corrector 354 includes a checksum generator/verifier.
The context monitor 356 monitors the security of both execution environments 302 and 304 of the electronic device 301. For example, the context monitor 356 monitors network security, and performs attestation to ensure the TEE 302 is indeed secure. The error detector and corrector 354 provides transfer error detection and correction for the TEE 302. For example, when electronic device 301 sends data d and its checksum c=chksm(d) to a second electronic device 102, then the second electronic device 102 receives (d′, c′). The second electronic device 102 verifies chksm(d′)==c′. If so, second electronic device 102 sends an acknowledgement message (“ACK”) to the first electronic device 301; otherwise, second electronic device 102 sends an error message (“ERR”) to the first electronic device 301 and the two devices 301 and 102 try again. The second electronic device 102 may be able to correct several bit errors if error correction coding algorithms are used, e.g., Reed-Solomon codes. The checksums can be referred to as integrity information. Data d (for example, shares) is attached with checksum and a signature to ensure the data is not damaged or tampered by dishonest shareholders or hackers.
Additionally, the error detector and corrector 354 provides trustee tamper detection for the TEE 302. For example, for a secret, the share generator 344 of the electronic device 301 generates n shares{sj}1≤j≤n and n checksums {cj=chksm(sj)}1≤j≤n, appends the n checksums to every share, and sends (si, {cj}1≤j≤n) to trustee i. A checksum function is a specific type of hash function. In certain embodiments, the share generator 344 generates n shares{sj}1≤j≤n by splitting the secret into the N parts {pj}1≤j≤n, computing N individual hashes {hj=hash(pj)}1≤j≤n of respective ones of the N parts, and encrypting each of the N parts by appending a corresponding individual hash hi to the respective individual part pi. That is, the share generator 344 generates a share si=(pi, hi) by appending an individual hash hi of a part to the part pi itself. The hash of all shares {cj}1≤j≤n is different from the all of the individual hashes of the N parts {hj}1≤j≤n. If a small fraction of the n trustees is dishonest or hacked and send tampered si, ci to the electronic device 301 (via the share generator 344) for recovery, then the electronic device 301 can leverage the n trustees' consensus of checksums to detect tampering and determine an identity of the dishonest trustee(s). The error detector and corrector 354 detects a hacked trustee device based on comparing a consensus of integrity information of the N shares to integrity information appended to a share retrieved from the hacked trustee device. For example, during a process for device-to-device secret recovery, the error detector and corrector 354 performs a “majority vote” for detection of “compromised” secret shares. That is, the error detector and corrector 354 compares to determine whether number of “trusted” trustee devices is greater than the number of “untrusted” devices. In response to determining a consensus (i.e., the number of “trusted” trustee devices is greater than the number of “untrusted” devices), error detector and corrector 354 determines that a process for device-to-device secret recovery will generate the correct hash through majority vote and then can correctly verify the integrity of the secret share, even if error detector and corrector 354 has not yet determined which trustee device has turned into an “untrusted” device and whether the hash is still correct.
The policy manager 358 manages different security policies, and enforces a selected security policy. The selected security policy can be user-selected and/or user-configured. As a non-limiting example, one security policy may restrict who can be a trustee, such as a rule that the trustees must be 2 friends and 2 family members. For example, the security policy may generically require that trustees have a “friend” or “family” relationship (e.g., as registered in an address book) to the owner of the electronic device 301. The policy manager 358 enables the user to define the level of trust for the trustees, for example, the having the “family” relationship to the user/owner may have a higher level of trust than a “friend,” and the user may define a security policy that requires such requires at least one trustee device to be from among family member devices for backup and recovery processes. Alternatively, the security policy may require that trustees be a specific person or specified people (e.g., Nancy and Jamie). Another security policy may allow different secrets (including corresponding shares generated therefrom) to have different policies. Another security policy may forbid or require that different secrets (including corresponding shares generated therefrom) have the same security policies.
The data transferer 360 includes a share distributor 362 and a share collector 364. The share distributor 362 distributes shares (for example, shares 404a-404e of
The share collector 364 collects shares from trustees' devices for secret recovery. The share collector 364 ensures the received share is a specified share that was requested, not someone else's share and not another secret's share. The share collector 364 keeps track of how many shares have been received. The share collector 364 triggers a warning alert if not enough shares are collected before a timeout, such as a recovery time limit.
User-adjustable configuration settings specify that n=5 and k=3, which enables a source device, such as electronic device 301 to backup any secret 402 to five (5) trustee devices 406a-406e (generally, 406) and requires retrieval of shares from three (3) trustee devices 406 to recover the secret 402. The source device (301) initiates the TEE 302 to receive and setup a secret 402 for D2D secret backup. The trustee devices 406a-406e can be the same as or similar to the external electronic devices 102 and 104 of
As introduced above, the share generator 344, in response to receiving the secret 402, generates five (5) shares 404 by applying an algorithm selected by the algorithm selector 342. By applying the selected algorithm, the share generator 344 splits the secret 402 into 5 parts, which may or may not be mutually exclusive parts, and encrypts each of the 5 parts. The 5 encrypted parts of the secret are together referred to as shares 404, and individually referred to as shares 404a-404e.
The source device (301) can access any two trustee devices 406; but cannot recover the secret 402 from fewer than three (<k where k=3) of the trustee devices 406. That is, if at most 2 trustee devices 406 are not available for any reason, then the source device (301) can still recover the secret 402.
The source device (301) relies on short-range D2D communication provided by the local connection driver 382, so TEE 302 is able to perform device-to-device secret backup and recovery processes according to this disclosure without need for a network (such as network 162).
As introduced above, at the time of recovery, a recovery device, such as electronic device 301, requires at least 3 trustee devices (k=3) to recover the secret 402. The recovery device (301) initiates the TEE 302 to recover a secret 402 using D2D secret recovery processes. The first trustee device 406a, third trustee device 406c, and fifth trustee device 406e transfer respective shares 404a, 404c, and 404e to the recovery device (301) via short-range D2D communication provided by the local connection driver 382.
As introduced above, the secret recovery module 346, in response to retrieving at least three shares 404a, 404c, and 404e (together referred to as retrieved shares 504), reconstructs the secret 402 by applying the algorithm selected by the algorithm selector 342. By applying the selected algorithm, the secret recovery module 346 decrypts the 3 shares 504 into raw/non-encrypted parts of the secret 402, and combines the 3 raw/non-encrypted parts into a reconstructed secret 402.
The process 600 begins at block 601, at which the processor 240 initiates a D2D secret backup process. For example, user may select to open a trusted app 263 by touching an associated icon or associated button provided by a trusted UI. In certain embodiments, initiation of the D2D secret backup process is in response to receiving user input that opens the secret vault app 263, which user input can be received through the user interface 306 of the non-secure execution environment 304 or can be received through the trusted UI 310. As a particular example, the user may select a secret vault button (908 of
In response to detecting that the D2D secret backup has been initiated, the user interface (UI 306 or trusted UI 310) triggers the TEE 302 to authenticate (at block 603) the identity of the user using authenticator 320.
At block 605, the TEE 302 retrieves confidential data using the trusted UI 310. More particularly, the confidential data includes user secret, user-adjustable configuration settings, remarks, etc. Examples of the retrieved confidential data includes the settings 802, 804a-804b shown in
At block 607, in response to receiving a user secret, the TEE 302 generates N shares using share generator 344. At block 609, the TEE 302 enforces a security policy using policy manager 358. At block 611, the TEE 302 stores the N generated shares in the (database) storage 336.
At block 613, the TEE 302 distributes the n generated shares to n trustee devices using share distributor 362. In some embodiments, the TEE 302 iteratively distributes each of the n generated shares to a different trustee device from among n trustee devices. In at least one embodiment, distributing the N shares includes receiving a generated share from the storage 336, establishing an encrypted channel 615 between the two devices' TEEs 302 and 602, and transferring the share from the TEE 302 of the main electronic device 301 to the TEE 602 of the trustee electronic device 102 using short-range communication. At block 617, the TEE 302 outputs one or more user interfaces that support the process 600 using the UI 306 of the non-secure environment 304.
As described above, blocks 601-617 of the process 600 are implemented within the TEE 302. Additionally, the device-to-device secret backup process 600 begins in the trustee electronic device 102 at block 617, at which a request is received from the main electronic device 301, requesting to backup a secret. In response to detecting that the request to backup a secret has been received, the TEE 602 performs a user authentication process (at block 619) using its authenticator (320). At block 621, the TEE 602 receives a share from the TEE 302 of the main electronic device 301 using short-range communication of the encrypted channel 615 between the two devices' TEEs 302 and 602. At block 623, the TEE 602 checks the security of the received share using security enforcer 350. In at least one embodiment, checking the security of the received share includes further encrypting the share using the encryption/decryption module (352) of the TEE 602. At block 625, the TEE 602 stores the received share in a database storage 636 of the TEE 602.
The process 700 begins at block 701, at which the processor 240 initiates a D2D secret recovery. For example, user may select to open a trusted app 263 by touching an associated icon or associated button provided by a user interface.
In response to detecting that the D2D secret recovery has been initiated, the TEE 302 collects (at block 703) k shares trustee electronic devices using secret recovery module 346. In at least one embodiment, collecting the k shares includes establishing an encrypted channel 715 between the two devices' TEEs 302 and 602, iteratively retrieving a share from the TEE 602 of k trustees' electronic devices (including 102) using short-range communication, and storing the retrieved share in storage 336 of the main electronic device 102.
At block 705, the TEE 302 checks the security of the received share using security enforcer 350. At block 707, the TEE 302 reconstructs the secret by decrypting the k received shares using the encryption/decryption module 352, and combining the decrypted parts of the secret using the secret recovery module 346. At block 709, the TEE 302 outputs the reconstructed secret (for example, by displaying the secret) using trusted UI 310. At block 711, the TEE 302 outputs one or more user interfaces that support the process 700 using the UI 306 of the non-secure environment 304.
As described above, blocks 701-711 of the process 700 are implemented within the TEE 302. Additionally, the device-to-device secret recovery process 700 begins in the trustee electronic device 102 at block 717, at which a request is received from the main electronic device 301, requesting to recover a secret. In response to detecting that the request to recover a secret has been received, the TEE 602 performs a user authentication process (at block 719) using its authenticator (320). In certain embodiments, the user authentication process (at block 719) includes both the owner of main electronic device 301 and the trustee (e.g., owner of the trustee electronic device 102) performing biometric authentication at the same time on each of the trustee devices to prevent the case of betrayed trustee.
At block 721, the TEE 602 retrieves a share from the storage 636 of the trustee electronic device 101. At block 723, the TEE 602 sends the retrieved share to the TEE 302 of the main electronic device 301 using short-range communication of the encrypted channel 715 between the two devices' TEEs 302 and 602.
As shown in
According to the scenarios provided in this disclosure, the first, second, and third electronic devices 101, 102, and 104 are owned by users named George, Nancy, and Jamie, respectively. In an example 1-to-2 scenario in which a secret backup to a trustee grouping of multiple (i.e., 2) trustee electronic devices occurs, the configuration settings for a first share may specify Nancy's smartphone as the user-selected trustee device 816a. The configuration settings for a second share may specify Jamie's smartphone as the user-selected trustee device 816b. Additional details of this 1-to-2 scenario, are described more particularly below with reference to
In another example 1-to-1 scenario in which a secret backup to a trustee grouping of one external electronic device that is owned by the same owner of the electronic device 301 occurs, the configuration settings for the sole, first share may specify an old smartphone as the user-selected trustee device 816a. Additional details of this 1-to-1 scenario, are described more particularly below with reference to
In
In
In
When the electronic device 101 and the second electronic device 102 (Nancy's phone) are moved into locations in close proximity to each other, the TEE 302 detects the presence of the second electronic device 102 by using the local connection driver 382, and in response to detection, transfers a share 404 to the trusted database storage 636 of the second electronic device 102. When the electronic device 101 and the third electronic device 104 (Jamie's phone) are moved into locations in close proximity to each other, the TEE 302 repeats this process in analogous manner. As a particular example, the TEE 302 uses the data transferer 360 to transfer the first share 404a to the second electronic device 102 and to transfer the second share 404b to the third electronic device 104. In response to completing transmission of N shares to K trustee devices, the TEE 302 changes the screen, for example, to display the user interface 904 of
The user interface 903 displays the names 934a-934b of the devices belonging to the trustee grouping 924. Next to each of the names, the user interface 903 displays a status indicator 936 or 938 indicating a confirmation (936) that a share 404 has been transferred to the named trustee device or indicating an in-progress status (938) that the electronic device 101 in has initiated but not completed a process of transferring a share 404 to the named trustee device.
In
More particularly,
In
When the electronic device 101 is moved into a location in close proximity to either one of the trustee devices belonging to the trustee grouping 924 (specifically, the second electronic device 102 (Nancy's phone) or the third electronic device 104 (Jamie's phone)), the TEE 302 detects the presence of the trustee device 102 or 104 by using the local connection driver 382. In response to the detection, the TEE 302 identifies the trustee device and retrieves the share 404 corresponding to the username 910 from the trusted database storage 636 of the second electronic device 102. For example, the TEE 302, in response to identifying the second electronic device 102 (Nancy's phone) in close proximity, retrieves the share 404a. Alternatively, in response to identifying the second electronic device 104 (Jamie's phone) in close proximity, the TEE 302 retrieves the share 404b. Upon completing retrieval of one share 404 from a trustee device, the TEE 302 changes the screen to display the user interface 1003 of
In
As another example of information related to the secret 912, the user interface 1004 displays the name of the bank account 1020a to which the secret 912 provides access. The bank account 1020a is one among a list of other accounts for which the owner/user has used the secret vault app to backup other secrets 1022 and 1024. For example, the list of other accounts includes a SAMSUNG account 1020b and a SAMSUNG wallet Bitcoin account 1020c.
In the example screenshot of the user interface 1004 that is shown in
The user interface 1004 displays a finish button 1028, which when touched by the user, triggers the TEE 302 to exit the secret vault app 263 and change the screen, for example, to display the user interface 900 of
As shown in
As shown in
The user interface 1203 shown in
For ease of explanation,
It is understood that the processor 340 of the TEE 302 of the source electronic device 101 performs the trusted D2D secret backup process 1300 in collaboration with the TEE 602 of a trustee electronic device 102. For ease of visual aid, the trusted processor 340 of the source electronic device 101 is shown as the “Source Device Vault Service (SCV),” and the trusted authenticator 320 of the source electronic device 101 is shown as the “Vault TA.” Also for ease of visual aid, “Trustee Device Vault SVC” and “Trustee Vault TA” respectively refer to the TEE 602 and authenticator 320T (with a subscript T indicating a relationship to the trustee device) of the trustee device 102. The processes performed at block 1302 and at block 601 of
At block 1303, the processor 340 prepares a secret 1304, which preparation includes performing the process 1400 (
In certain embodiments, preparation (at block 1303) of a secret includes receiving confidential data, as described above with reference to block 605 of
At block 1306, the processor 340 performs device attestation of the source electronic device 101. In certain embodiments, in performance of device attestation, the user interface (UI 306 or trusted UI 310) sends a user authentication request 1308, which includes user credentials 1310, to the authenticator 320. Alternatively, in certain embodiments, the user interface transmits the user authentication request 1308 to an authentication service provided by the server 106. For simplicity,
At block 1316, the authenticator 320 determines whether the received user credentials 1310 were received from the owner of the source electronic device 101 by comparing the user credentials 1310 to a credential C previously registered into the TEE 302 by the owner. Examples of the credential C include a biometric template or a secret question/answer pair. In certain embodiments, the user authentication processes included generating (e.g., deriving) private source encrypt key KS from the credential C, for example, using the encrypter/decrypter 352. That is, in certain embodiments, the private source encrypt key KS is derived from the biometric information. The authenticator 320 stores the source encrypt key KS in secure storage 336 of the source electronic device 101. The processes performed at block 1316 and at block 603 of
At operation 1320, in response to receiving the acknowledgement 1318, the processor 340 wraps the source encrypt key KS, sends the wrapped source encrypt key KS and the confidential data (including the secret 1304 and the configuration settings 1305) to the authenticator 320. In certain embodiments, the communication at operation 1320 is defined as “secret, wrappedPrivKey_A.”
At block 1322, the authenticator 320 unwraps the wrapped private key KS using a device root key, which can be defined as “DRKPrivKey_A=unwrap(wrappedPrivKey_A)”.
At block 1324, the authenticator 320 splits the secret 1304 into N shares according to the configuration setting 1305. The processes performed at block 1324 and at block 607 of
Now refer to
At operation 1330, the processor 340 sends (to the authenticator 320) the wrapped Share1 1332 assigned to the trustee device 102, the user selection 1328 regarding visibility of the Share1, and a trustee certificate 1334 corresponding to the trustee device 102. As an example, a trustee certificate 1334 can be defined as “DRKCert_B” and based on the encrypt key KT 1334.
At block 1336, the authenticator 320 generates a request 1338 (“Req.”), which can be defined as “req=jws(ID_A, jwe(share∥visibility, DRKPubKey_B), DRKPrivKey_A).” The request 1338 includes the Share1 and the user selection 1328 regarding visibility of Share1, both of which are encrypted using a trustee public key (DRKPubKey_B) that is derived from the private trustee encrypt key KT, and both of which are again (e.g., doubly) encrypted using the source encrypt key KS. That is, the double encryption (also referred to as “dual encryption”) of this disclosure is distinct from a single encryption based on two encryption keys, as the dual encryption of this disclosure includes two authentications (e.g., biometric authentications), which includes an authentication by the owner and an authentication by the trustee. This disclosure is not limited to a single order of double encryption, and it is understood that double encryption of the Share1 can include an initial encryption using the source encrypt key KS followed by an encryption using the trustee public key (DRKPubKey_B). The request 1338 includes an identifier (illustrated as “ID_A”) of the source electronic device 101, which identifier is encrypted using the source encrypt key KS. The request 1338 includes a signature that could be generated using a JSON web signature function (jws( )) based on the Share, visibility settings, and the private source encrypt key KS. In sum, the request 1338 includes: the secret share which is doubly encrypted using source encrypt key KS and a communication encryption key KC.
The authenticator 320 sends the request 1338 to the processor 340, which transmits the request 1338 to the TEE 602 of the trustee device via a short-range communication 1340 (for example, a tap). The request 1338 is configured to cause the trustee device 102 to store the share (Share) in the storage 636 of the TEE 602 of the trustee device, but trustee TEE 602 performs various operations 1342-1346 before storing the received share in the storage 636.
At block 1342, in response to receiving the request 1338, the trustee TEE 602 checks whether the received Share1 is secure. In certain embodiments, checking whether the received share is secure includes determining whether the identifier of the source device 101 was previously set at the trustor, and if not (e.g., “A.isTrustor=false”), rejecting the received share and determining the received share is not secure. In certain embodiments, checking whether the received share is secure includes determining whether the source device transmitted too much data via the communication 1340, and if so, rejecting the received share and determining the received share is not secure. Similarly, trustee TEE 602 accepts the received share based on a determination that the identifier of the source device 101 was previously set as the trustor (e.g., “A.isTrustor=true”) and that the source device 101 did not transmit too much data.
In response to identifying (at block 1344) that a source certification (“DRKCert_A”) 1427 was previously stored in the trustee storage 636, the trustee TEE 602 checks (at block 1346) the (“jws”) signature. For example, at block 1346, checking the signature could include decrypting and verifying the doubly encrypted signature (e.g., jws signature which was received via the communication 1340).
At operation 1348, the trustee TEE 602 sends the request 1338 and the wrapped encrypt key KT 1350 to the trustee authenticator 320T. In certain embodiments, the communication a operation 1348 could be defined as “req, wrappedPrivKey_B.”
Now refer to
At block 1354, the trustee authenticator 320T decrypts the share Sharei using the unwrapped trustee encrypt key KT, which in certain embodiments is defined as “DRKprivKey_B.”
At block 1356, the trustee authenticator 320T wraps the share (i.e., Share). As an example, the wrapped Share, 1364 can be defined as “wrappedShare=wrap(share).”
At block 1358, the trustee authenticator 320T generates an acknowledgement 1360, which can be defined as “ack=jws(OK, DRKPrivKey_B).” That is, the acknowledgement 1360 is generated based on the unwrapped trustee encrypt key KT.
At operation 1362, the trustee authenticator 320T sends the acknowledgement 1360 and the wrapped Sharei 1364 to the trustee TEE 602.
At block 1366, the trustee TEE 602 stores (e.g., saves), in the storage 363 of the trustee TEE 602, the following: the wrapped Share, 1364, the user selection 1328 regarding visibility corresponds to the wrapped Share1 1364, and the identifier (e.g., “ID_A”) of the source electronic device 101.
At operation 1368, the trustee TEE 602 transmits the acknowledgement 136 and the identifier (“ID_B”) of trustee electronic device 102 to the processor 340 of TEE 302 of the source electronic device 101 via a short-range communication. For example, the transmission performed at operation 1368 can be defined as “ACK∥ID_B.”
In response to identifying (at block 1370) that trustee certificate (“DRKCert_B”) 1334 was previously stored in the source storage 336, the processor 340 of the source device verifies (at block 1372) the (“jws”) signature. For example, at block 1372, checking the signature could include decrypting and verifying the signature defined by the acknowledgement 1360 (e.g., defined as “ack=jws(OK,DRKrivKey_B)”).
At block 1374, the processor 340 of the source device determines whether to send another share or to complete the D2D secret backup process 1300. More particularly, the processor 340 determines whether all N shares have been transmitted to a plurality of N trustee devices, and if not, the processor 340 transmits another share (e.g., Share2) to another trustee device (such as the third electronic device 104), but if so, the process 1300 ends.
The process 1400 begins when the source electronic device 101 obtains an add trustee message 1402 (illustrated as “msg=add trustee∥add trustor”) indicating that the user of the source electronic device 101 has selected to add a trustee electronic device 102. Obtaining the add trustee message 1402 can be performed by using the processor 340 to generate the message 1402, or by receiving the message 1402 from a user interface (UI 306 or trusted UI 310).
In the process 1400, user authentication is required at the beginning of device paring, as such, the processor 340 sends a user authentication request 1406 which includes user credentials 1408, to the authenticator 320. The processes performed at block 1410 and at block 1316 of
As operation 1416, the processor 320, in response to receiving the acknowledgement 1414, generates a source encrypt key KS from the credentials C, wraps the source encrypt key KS, and forwards the add trustee message 1402 and the wrapped KS to the authenticator 320. The forwarding communication from the processor 320 to the authenticator 320 is illustrated is as “msg, wrappedPrivKey_A.”
At operation 1418, the authenticator 320 accesses the source encrypt key KS by unwrapping the wrapped source encrypt key KS, for example, illustrated as “DRKPrivKey_A=unwrap(wrap(wrappedPrivKey_A)”.
The authenticator 320 generates a signature 1420 using the source encrypt key KS. For example, the signature 1420, which is illustrated as req=jws(msg, DRKPrivKey_A), could be generated using a JSON web signature function (jws( )) based on the add trustee message 1402 (“msg”) and the wrapped source encrypt key KS.
At operation 1422, the processor 340 receives the signature 1420 (“req”) from the authenticator 320.
At operation 1424, the processor 340 detects that the source electronic device 101 has moved into a location in close proximity to the trustee device 102 (illustrated as a 1st tap). For example, the back surface of each of the two devices 101 and 102 may face each other, and may contact (e.g., tap) each other. While the source and trustee electronic devices 101 and 102 are located in close proximity to each other (e.g., during the first tap), the processor 340 of the source electronic device 101 negotiates a communication encrypt key KC and transmits a signal (illustrated as “req∥DRKCert_A”) to the TEE 602 of the trustee device 102. That is, the processor 340 transmits the signature 1420, which includes a source certification (“DRKCert_A”).
At operations 1426-1450, the source and trustee devices 101 and 102 may be moved and separated away from close proximity to each other. At operation 1426, the TEE 602 verifies the source certificate 1427 (illustrated as “DRKCert_A”). Additionally at operation 1426, the TEE 602 ascertains an identifier 1429 (“ID_A”) of the source/recovery device 101 (for example, by performing a “get ID_A” function).
At operation 1428, the TEE 602 checks the jws signature, namely, the signature 1420.
At operation 1430, the TEE 602 confirms whether the trustee device 102 is a trustee or a trustor in a relationship with the source electronic device 101.
At operation 1432, the TEE 602 sends a user authentication request, which includes user consent 1436, to the trustee authenticator 320T or 1412. For example, the user (e.g., Nancy) of the trustee device 102 may input a selection indicating consent 1436 for the user's electronic device 102 to be added as trustee in a relationship with source device 101 as trustor.
At operation 1434, the trustee authenticator 1412 performs user authentication processes. For example, the trustee authenticator 1412 determines whether the received user consent 1436 were received from the owner of the trustee electronic device 102 by comparing the user credentials 1310 to a credential CT previously registered into the TEE 602 by the owner/user of the trustee electronic device 102. Based on the results of the user authentication, the trustee authenticator 1412 sends an acknowledgement 1438 or an error signal to the TEE 602. In certain embodiments, during the pairing process, the TEE 602 of the trustee device computes and stores a hash of the biometric data of the owner of the secret in the secure storage 636 of trustee device 102.
At operation 1440 (illustrated as “Add ID_A∥DRKCert_A, set A.isTrustor=true, A.isTrustee=true”), the trustee TEE 602, in response to receiving the acknowledgement 1438, sets the identifier (illustrated as “ID_A) of source device 101 as the trustor (illustrated as “set A.isTrustor=true”).
At operation 1442, the trustee TEE 602 generates, wraps, and stores a trustee encrypt key KT in trusted database storage 636. The trustee TEE 602 sends an acknowledgement (illustrated as genAck(“yes”, wrappedPrivKey_B)”) to the trustee authenticator 320T. The acknowledgement includes the wrapped trustee encrypt key KT.
At operation 1444, the trustee authenticator 320T accesses the trustee encrypt key KT by unwrapping the wrapped trustee encrypt key KT, for example, illustrated as “DRKPrivKey_B=unwrap(wrappedPrivKey_B).”
At operation 1446, the trustee authenticator 320T generates a signature 1448 using the trustee encrypt key KT. For example, the signature 1448, which is illustrated as ack=jws(“yes”, DRKPrivKey_B), could be generated using a JSON web signature function (jws( )) based on the message (“yes”) and the wrapped trustee encrypt key KT. The trustee authenticator 320T sends an acknowledgement 1450, including the signature 1448, to the trustee TEE 602.
At operation 1452, the trustee TEE 602 detects that the source electronic device 101 has moved into a location in close proximity to the trustee device 102 (illustrated as a 2nd tap). During the second tap, the trustee TEE 602 a transmits the signature 1448 via a signal (illustrated as “ack∥DRKCert_B”) to the TEE 304 of the source device 101, and the signal includes the trustee encrypt key KT.
At operation 1454, the processor 340 verifies the trustee encrypt key KT. At operation 1456, the processor 340 verifies the signature 1448. At operation 1458 (illustrated as “add ID_B∥DRKCert_B, set B.isTrustee=true, B.isTrustor=true”), the processor 340 sets the identifier (illustrated as “ID_B”) of trustee device 102 as the trustor (illustrated as “set B.isTrustee=true”). The process 1400 ends upon completion of operation 1458. Although
At operation 1502, the user of the recovery device 101 selects which secret to recover by selecting an identifier (illustrated as “secretID”) of the selected secret. More particularly, the processor 340 of the recovery device 101 receives input indicating the identifier (“secretID”) of the selected secret.
At operation 1504, the processor 340 of the recovery device 101 sends, to the trusted authenticator 320 of the recovery device 101, the following: the identifier (“secretID”) of the selected secret and the wrapped source encrypt key KS (illustrated as “wrappedPrivKey_A”).
At operation 1506, the trusted authenticator 320 unwraps the wrapped source encrypt key KS. The function performed at operation 1506 can be defined as “DRKPrivKey_A=unwrap(wrappedPrivKey_A).”
At operation 1508, the trusted authenticator 320 generates a request (“req”) 1510, which can be defined as “req=jws(ID AH secretID, DRKPrivKey_A).”
At operation 1512, the trusted authenticator 320 sends the request 1510 to the processor 340 of the TEE 302.
At operation 1514, the processor 340 detects that the recovery electronic device 101 has moved into a location in close proximity to the trustee device 102 (illustrated as a 1st tap). During the first tap, the processor 340 forwards the request 1510 to the TEE 602 of the trustee device 102 via a short-range communication.
The processes performed at operations 1516 and 1518 are similar the processes performed at blocks 1344 and 1346 of
At operation 1520, the TEE 302 searches for the identifier (“secretID”) of the selected secret in the database 636, and checks whether the database 636 contains any share that is related to the identifier of the selected secret.
The processes performed at operations 1522, 1524, and 1526 are similar the processes performed at operations 1432, 1434, and 1438 of
At operation 1530, the trustee TEE 602 retrieves, from the database 636, a share that is related to both the identifier (“secretID”) of the selected secret and the identifier (“ID_A) of source device 101. The retrieved share is wrapped (illustrated as “wrappedShare”). In the embodiment shown in
At operation 1532, the trustee TEE 602 sends the wrappedShare and the wrapped trustee encrypt key KT to the trustee authenticator 320T. The wrapped trustee encrypt key KT is illustrated as “wrappedPrivKey_B.”
The process performed at operation 1534 is similar the process performed at blocks 1444 of
At operation 1536, the authenticator 320 generates a message 1538 (“msg”), which can be defined as “msg=jws(ID_B jwe(share, DRKPubKey_A), DRKPrivKey_B).” The message 1538 includes a signature that could be generated using a JSON web signature function (jws( )) based on the Share, and the identifier (“ID_B”) of the trustee device, and a trustee private key (“DRKPrivKey_B”). The message 1538 includes the Share1, which is encrypted using a source public key (DRKPubKey_A).
At operation 1540, the trustee authenticator 320T sends the message 1538 to the trustee TEE 602, which forwards (at operation 1542) the message 1538 to the TEE 302 of the recovery device 101. That is, at operation 1542, the trustee TEE 602 detects that the recovery electronic device 101 has moved into a location in close proximity to the trustee device 102 (illustrated as a 2nd tap). During the second tap, the trustee TEE 602 a transmits the message 1538 to the TEE 302 via short-range communications.
The processes performed at operations 1544 and 1546 are similar the processes performed at blocks 1370 and 1372 of
At operation 1548, the trustee TEE 602 sends the message 1538 to the authenticator 320 of the recovery device 101. At operation 1550, the authenticator 320 of the recovery device 101 decrypts the retrieved share using the private key DRKPrivKey_A, which was received within the message 1538. At operation 1552, after the share has been decrypted, the authenticator 320 sends the decrypted share 1544 to the processor 340 the TEE 340 of the recovery device 101.
At operation 1556, the processor 340 saves the retrieved share 1554 in the storage 336 of the recovery device 101. Additionally at operation 1556, the processor 340 determines whether K shares have been retrieved from to a subset of K trustee devices, and if not, the processor 340 retrieves another share (e.g., Share2) from another trustee device (such as the third electronic device 104). If the processor 340 determines K shares have been retrieved, then the processor 340 reconstructs the secret from K retrieved shares using a selected algorithm, and process 1400 ends.
Now refer to
At block 1612, the processor 120 splits a selected secret for backup into N secret shares in a trusted execution environment (TEE) 302 of the first electronic device 101. At block 1614, the processor 120 computes integrity information for each of the N secret shares. At block 1616, the processor 120 appends, to each of the N secret shares, the computed integrity information of the N secret shares.
At block 1618, the processor 120 identifies a security policy including one or more rules applicable to the at least one assignment. At block 1620, the processor 120 determines whether the at least one assignment complies with the one or more rules. At block 1622, in response to determining a particular assignment does not comply with the security policy, the processor 120 disallows the specific one of the secret shares from being transferred to the assigned trustee device, and the method 1600 ends. At block 1624, in response to determining the particular assignment complies with the security policy, the processor 120 allows transfer of the specific one of the secret shares to the assigned trustee. At block 1626, the processor 120 transfers the N secret shares to N trustee devices via a transceiver (e.g., 170) over a short-range transmission (e.g., 615 of
Now refer to
At block 1656, the processor 120 reconstructs the secret from the subset of K retrieved secret shares. In certain embodiments, reconstructing (as shown by blocks 1656-1666) the secret from K retrieved secret shares includes determining (at block 1658), in response to completing retrieval of the subset of K secret shares from the subset of K trustee devices, whether some of the retrieved secret shares have incorrect hashes. At block 1660, the processor 120 removes each of the retrieved secret shares that has an incorrect hash. At block 1662, the processor 120 replace each removed secret share by retrieving a secret share from another trustee device. In certain embodiments, reconstructing (as shown by blocks 1664-1666) the secret from K retrieved secret shares includes identifying (at block 1664) a selected algorithm for generating the N secret shares and reconstructing the secret. The selected algorithm has been applied to the selected secret during the splitting. At block 1666, the processor 120 generates a reconstructed secret by applying the identified selected algorithm to the subset of K secret shares.
The first electronic device 101 is not limited to recovering only one secret share. In blocks 1668-1670, first electronic device 101 recovers a second secret. At block 1668, the processor 120 retrieves, via a transceiver of the first electronic device performing short-range communications with a second plurality of trustee devices, K2 secret shares that were generated (at block 1608 of
The electronic device 101 is not limited to performing the functions of a trustor device that splits and reconstructs secrets, rather it is understood that electronic device 101 can also perform the functions of a trustee device.
The above flowcharts illustrate example methods that can be implemented in accordance with the principles of the present disclosure and various changes could be made to the methods illustrated in the flowcharts herein. For example, while shown as a series of steps, various steps in each figure could overlap, occur in parallel, occur in a different order, or occur multiple times. In another example, steps may be omitted or replaced by other steps.
Although the figures illustrate different examples of electronic devices, various changes may be made to the figures. For example, the electronic devices can include any number of each component in any suitable arrangement. In general, the figures do not limit the scope of this disclosure to any particular configuration(s). Moreover, while figures illustrate operational environments in which various user equipment features disclosed in this patent document can be used, these features can be used in any other suitable system.
None of the description in this application should be read as implying that any particular element, step, or function is an essential element that must be included in the claim scope. The scope of patented subject matter is defined only by the claims. Moreover, none of the claims is intended to invoke 35 U.S.C. § 112(f) unless the exact words “means for” are followed by a participle. Use of any other term, including without limitation “mechanism,” “module,” “device,” “unit,” “component,” “element,” “member,” “apparatus,” “machine,” “system,” “processor,” or “controller,” within a claim is understood by the applicants to refer to structures known to those skilled in the relevant art and is not intended to invoke 35 U.S.C. § 112(f).
Although the present disclosure has been described with exemplary embodiments, various changes and modifications may be suggested to one skilled in the art. It is intended that the present disclosure encompass such changes and modifications as fall within the scope of the appended claims. None of the description in this application should be read as implying that any particular element, step, or function is an essential element that must be included in the claims scope. The scope of patented subject matter is defined by the claims.
The present application claims priority to U.S. Provisional Patent Application No. 63/151,184, filed on Feb. 19, 2021. The content of the above-identified patent document is incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 63151184 | Feb 2021 | US |
