Abstract: Disclosed herein are systems, methods, and non-transitory computer-readable storage media for wireless data protection utilizing cryptographic key management on a primary device and a backup device. A system encrypts a file with a file key and encrypts the file key twice, resulting in two encrypted file keys. The system encrypts each file key differently and stores a first file key on the primary device and transmits one of the encrypted file keys in addition to the encrypted file to a backup device for storage. On the backup device, the system associates the encrypted file key with a set of backup keys protected by a user password. In one embodiment, the system generates an initialization vector for use in cryptographic operations based on a file key. In another embodiment, the system manages cryptographic keys on a backup device during a user password change.

Abstract: A method of establishing communications with a first device is disclosed. The method includes: the first device presenting connection information to a second device; receiving a response from a second device; establishing an association with the second device; transmitting, in response to a determination that the first device and the second device are connected for data, first data to the second device, the first data comprising addressing information for a server; receiving second data from the second device, the second data comprising second information for establishing communications with the first device; and configuring the first device to receive third data from a location remote to the first device using the second information from the second data.

Abstract: Techniques are disclosed relating to the secure communication of devices. In one embodiment, a first device is configured to perform a pairing operation with a second device to establish a secure communication link between the first device and the second device. The pairing operation includes receiving firmware from the second device to be executed by the first device during communication over the secure communication link, and in response to a successful verification of the firmware, establishing a shared encryption key to be used by the first and second devices during the communication. In some embodiments, the pairing operation includes receiving a digital signature created from a hash value of the firmware and a public key of the second device, and verifying the firmware by extracting the hash value from the digital signature and comparing the extracted hash value with a hash value of the received firmware.

Abstract: In one embodiment of the invention, service providers generate bloom filters with the user ID codes of registered users and exchange the bloom filters with one another. In response to a request to locate a first user, a first service provider will query its own registration database to determine if the first user is registered with the first service provider. If the first user is not registered with the first service provider, then the first service provider will query its bloom filters to identify other service providers with which the first user may be registered. A positive response from a bloom filter indicates that the first user may or may not be registered with the service provider associated with that bloom filter, and a negative response indicates with certainty that the first user is not registered with the service provider associated with that bloom filter.

Abstract: A method of activating a first device is disclosed. The method includes: the first device pairing with a second device; receiving a connection request from a second device; connecting to the second device; opening a communication channel to the second device; transmitting an activation package to the second device; receiving an activation payload from the second device; and performing an activation using information from the activation payload.

Abstract: In some implementations, encrypted data (e.g., application data, keychain data, stored passwords, etc.) stored on a mobile device can be accessed (e.g., decrypted, made available) based on the context of the mobile device. The context can include the current device state (e.g., locked, unlocked, after first unlock, etc.). The context can include the current device settings (e.g., passcode enabled/disabled). The context can include data that has been received by the mobile device (e.g., fingerprint scan, passcode entered, location information, encryption key received, time information).

Abstract: A method of unlocking a second device using a first device is disclosed. The method can include: the first device pairing with the second device; establishing a trusted relationship with the second device; authenticating the first device using a device key; receiving a secret key from the second device; receiving a user input from an input/output device; and transmitting the received secret key to the second device to unlock the second device in response to receiving the user input, wherein establishing a trusted relationship with the second device comprises using a key generated from a hardware key associated with the first device to authenticate the device key.

Abstract: In an embodiment, a system is provided in which the private key is managed in hardware and is not visible to software. The system may provide hardware support for public key generation, digital signature generation, encryption/decryption, and large random prime number generation without revealing the private key to software. The private key may thus be more secure than software-based versions. In an embodiment, the private key and the hardware that has access to the private key may be integrated onto the same semiconductor substrate as an integrated circuit (e.g. a system on a chip (SOC)). The private key may not be available outside of the integrated circuit, and thus a nefarious third party faces high hurdles in attempting to obtain the private key.

Abstract: An SOC implements a security enclave processor (SEP). The SEP may include a processor and one or more security peripherals. The SEP may be isolated from the rest of the SOC (e.g. one or more central processing units (CPUs) in the SOC, or application processors (APs) in the SOC). Access to the SEP may be strictly controlled by hardware. For example, a mechanism in which the CPUs/APs can only access a mailbox location in the SEP is described. The CPU/AP may write a message to the mailbox, which the SEP may read and respond to. The SEP may include one or more of the following in some embodiments: secure key management using wrapping keys, SEP control of boot and/or power management, and separate trust zones in memory.

Abstract: Disclosed herein are systems, methods, and non-transitory computer-readable storage media for wireless data protection utilizing cryptographic key management on a primary device and a backup device. A system encrypts a file with a file key and encrypts the file key twice, resulting in two encrypted file keys. The system encrypts each file key differently and stores a first file key on the primary device and transmits one of the encrypted file keys in addition to the encrypted file to a backup device for storage. On the backup device, the system associates the encrypted file key with a set of backup keys protected by a user password. In one embodiment, the system generates an initialization vector for use in cryptographic operations based on a file key. In another embodiment, the system manages cryptographic keys on a backup device during a user password change.

Abstract: A method of activating a first device is disclosed. The method includes: the first device pairing with a second device; receiving a connection request from a second device; connecting to the second device; opening a communication channel to the second device; transmitting an activation package to the second device; receiving an activation payload from the second device; and performing an activation using information from the activation payload.

Abstract: A method of unlocking a second device using a first device is disclosed. The method can include: the first device pairing with the second device; establishing a trusted relationship with the second device; authenticating the first device using a device key; receiving a secret key from the second device; receiving a user input from an input/output device; and transmitting the received secret key to the second device to unlock the second device in response to receiving the user input, wherein establishing a trusted relationship with the second device comprises using a key generated from a hardware key associated with the first device to authenticate the device key.

Abstract: Disclosed herein are systems, methods, and non-transitory computer-readable storage media for wireless data protection utilizing cryptographic key management on a primary device and a backup device. A system encrypts a file with a file key and encrypts the file key twice, resulting in two encrypted file keys. The system encrypts each file key differently and stores a first file key on the primary device and transmits one of the encrypted file keys in addition to the encrypted file to a backup device for storage. On the backup device, the system associates the encrypted file key with a set of backup keys protected by a user password. In one embodiment, the system generates an initialization vector for use in cryptographic operations based on a file key. In another embodiment, the system manages cryptographic keys on a backup device during a user password change.

Abstract: In some implementations, encrypted data (e.g., application data, keychain data, stored passwords, etc.) stored on a mobile device can be accessed (e.g., decrypted, made available) based on the context of the mobile device. The context can include the current device state (e.g., locked, unlocked, after first unlock, etc.). The context can include the current device settings (e.g., passcode enabled/disabled). The context can include data that has been received by the mobile device (e.g., fingerprint scan, passcode entered, location information, encryption key received, time information).

Abstract: A method and apparatus of a device that enables a user to participate in a secure instant messaging session by starting with a low security connection before switching to a high security connection is described. The device concurrently establishes a low security connection and a high security connection with a remote participant of the secure instant messaging session. The device sends a first message to the remote participant through the low security connection while the high security connection is being established. The device further determines whether the high security connection is established. If the high security connection is established, the device can send a second message to the remote participant through the high security connection. If the high security connection is not yet established, the device can send the second message to the remote participant through the low security connection.

Abstract: A method for configuring a device includes receiving a first configuration profile comprising a first configuration and a first certificate and a second certificate, verifying the first configuration profile with the first certificate, receiving a user input indicating to accept the first configuration profile, configuring the device according to the first configuration, receiving a second configuration profile comprising a second configuration, verifying the second configuration profile with the second certificate and updating the device according to the second configuration, wherein the user is unaware of the updating.

Abstract: An SOC implements a security enclave processor (SEP). The SEP may include a processor and one or more security peripherals. The SEP may be isolated from the rest of the SOC (e.g. one or more central processing units (CPUs) in the SOC, or application processors (APs) in the SOC). Access to the SEP may be strictly controlled by hardware. For example, a mechanism in which the CPUs/APs can only access a mailbox location in the SEP is described. The CPU/AP may write a message to the mailbox, which the SEP may read and respond to. The SEP may include one or more of the following in some embodiments: secure key management using wrapping keys, SEP control of boot and/or power management, and separate trust zones in memory.

Abstract: Systems and methods are disclosed for secure relocation of encrypted files for a system having non-volatile memory (“NVM”). A system can include an encryption module that is configured to use a temporary encryption seed (e.g., a randomly generated key and a corresponding initialization vector) to decrypt and encrypt data files in an NVM. These data files may have originally been encrypted with different encryption seeds. Using such an approach, data files can be securely relocated even if the system does not have access to the original encryption seeds. In addition, the temporary encryption seed allows the system to bypass a default key scheme.

Abstract: An SOC implements a security enclave processor (SEP). The SEP may include a processor and one or more security peripherals. The SEP may be isolated from the rest of the SOC (e.g. one or more central processing units (CPUs) in the SOC, or application processors (APs) in the SOC). Access to the SEP may be strictly controlled by hardware. For example, a mechanism in which the CPUs/APs can only access a mailbox location in the SEP is described. The CPU/AP may write a message to the mailbox, which the SEP may read and respond to. The SEP may include one or more of the following in some embodiments: secure key management using wrapping keys, SEP control of boot and/or power management, and separate trust zones in memory.

Abstract: A machine implemented method includes storing a first data representing a prior exception to a first trust failure (e.g., expired certificate). The prior exception may be stored as part of establishing a first communication with a data processing system (e.g., a handheld device). The first communication may not be trustworthy. The method may determine, as part of establishing a second communication with the data processing system, that a second trust failure has occurred. The second trust failure (e.g., revoked certificate) indicates that the second communication may not be trustworthy. The method may determine whether the prior exception applies to the second trust failure. If the prior exception does not apply, the data processing system determines, automatically, whether to create a new exception for the second trust failure.