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.

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 generating a device dependent cryptographic key in a rate-limited way. A system configured to practice the method first receives data associated with a user. The data associated with the user can be a password, a personal identification number (PIN), or a hash of the password. Then the system performs a first encryption operation on the user data based on a device-specific value to yield first intermediate data and performs a second encryption operation on the first intermediate data based on the device-specific value to yield second intermediate data. Then the system iteratively repeats the second encryption operation until a threshold is met, wherein each second encryption operation is performed on the second intermediate data from a previous second encryption operation. The iterations produce a final cryptographic key which the system can then output or use for a cryptographic operation.

Abstract: In one embodiment, a unique (or quasi unique) identifier can be received by an application store, or other on-line store, and the store can create a signed receipt that includes data desired from the unique identifier. This signed receipt is then transmitted to a device that is running the application obtained from the on-line store and the device can verify the receipt by deriving the unique (or quasi-unique) identifier from the signed receipt and comparing the derived identifier with the device identifier stored on the device, or the vendor identifier assigned to the application vendor.

Abstract: Disclosed herein are systems, methods, and non-transitory computer-readable storage media for encryption and key management. The method includes encrypting each file on a computing device with a unique file encryption key, encrypting each unique file encryption key with a corresponding class encryption key, and encrypting each class encryption key with an additional encryption key. Further disclosed are systems, methods, and non-transitory computer-readable storage media for encrypting a credential key chain. The method includes encrypting each credential on a computing device with a unique credential encryption key, encrypting each unique credential encryption key with a corresponding credential class encryption key, and encrypting each class encryption key with an additional encryption key.

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: 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 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: Disclosed herein are systems, methods, and non-transitory computer-readable storage media for generating a device dependent cryptographic key in a rate-limited way. A system configured to practice the method first receives data associated with a user. The data associated with the user can be a password, a personal identification number (PIN), or a hash of the password. Then the system performs a first encryption operation on the user data based on a device-specific value to yield first intermediate data and performs a second encryption operation on the first intermediate data based on the device-specific value to yield second intermediate data. Then the system iteratively repeats the second encryption operation until a threshold is met, wherein each second encryption operation is performed on the second intermediate data from a previous second encryption operation. The iterations produce a final cryptographic key which the system can then output or use for a cryptographic operation.

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 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: Disclosed herein are systems, methods, and non-transitory computer-readable storage media for encryption and key management. The method includes encrypting each file on a computing device with a unique file encryption key, encrypting each unique file encryption key with a corresponding class encryption key, and encrypting each class encryption key with an additional encryption key. Further disclosed are systems, methods, and non-transitory computer-readable storage media for encrypting a credential key chain. The method includes encrypting each credential on a computing device with a unique credential encryption key, encrypting each unique credential encryption key with a corresponding credential class encryption key, and encrypting each class encryption key with an additional encryption key.

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.

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.