Device and method for managing data

Abstract

Apparatus and methods for managing data stored within a container. The container may be associated with at least one registered user. Data within the container may be encrypted by a data encryption key (DEK). A computing device comprises: a security module including a cryptographic processor, a main processor, and a memory. The memory stores instructions that, when executed, configure the processor to: authenticate a user based on a user secret associated with the container, and generate a soft key based on the user secret. The instructions cause the cryptographic processor to generate a security generator output including a cryptographic key component, and generate an enhanced user key based on a key agreement protocol using the soft key and the cryptographic key component. The instructions cause the processor to construct an unencrypted DEK associated with the enhanced user key, and use the unencrypted DEK to decrypt a subset of the data.

Description

Technical Field

[0001] The present application relates generally to data management, and in particular to managing data stored within containers. Background Art

[0002] Computing devices can be configured to protect data stored on the computing device. The stored data may be confidential or proprietary information of a particular user, and access to the stored data may be dependent on verifying the identity of the user who wishes to access the stored data. For example, the computing device may require the user to authenticate before operating the computing device and before accessing or modifying stored data. Security operations may include comparing received user input to a list of passwords. In another example, security operations may include encrypting data using a cryptographic key associated with a particular user. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] Reference will now be made, by way of example, to the accompanying drawings which show example embodiments of the present application, and in which:

[0004] Figure 1 A computing device for managing data according to an example of the present application is shown in simplified block diagram form;

[0005] Figure 2 An example encryption key derivation operation according to the present application is shown;

[0006] Figure 3 A method for managing data stored in a container according to an example of the present application is shown in the form of a flowchart.

[0007] Figure 4 An enhanced user key generation operation according to an example of the present application is shown; and

[0008] Figure 5 An electronic device according to examples of the present application is shown in simplified block diagram form.

[0009] Similar reference numerals may be used in different drawings to identify similar components. DETAILED DESCRIPTION

[0010] In a first aspect, the present application describes a method for managing data within a container stored on a computing device. The container may be associated with at least one registered user. The data within the container may be encrypted by a data encryption key (DEK) and stored as encrypted data. The method includes: authenticating a user based on a user secret associated with the container; generating a soft key based on the user secret; generating, by a cryptographic processor other than a main processor of the computing device, a security generator output including a cryptographic key component associated with the authenticated user; generating, by the cryptographic processor, a hardened user key based on a key agreement protocol using the soft key and the cryptographic key component associated with the authenticated user; constructing an unencrypted DEK associated with the hardened user key for accessing a subset of the data stored within the container; and decrypting the subset of data using the unencrypted DEK.

[0011] In another aspect, the present application describes a computing device that manages data stored within a container. The container may be associated with at least one registered user. The data within the container may be encrypted by a data encryption key (DEK) and stored as encrypted data. The computing device includes: a security module including a cryptographic processor; a main processor coupled to the security module; and a memory coupled to the processor and the cryptographic processor. The memory may store instructions that, when executed, configure at least one of the main processor or the cryptographic processor to: authenticate a user based on a user secret associated with the container; generate a soft key based on the user secret; generate, by the cryptographic processor, a security generator output including a cryptographic key component associated with the authenticated user; generate, by the cryptographic processor, a hardened user key based on a key agreement protocol using the soft key and the cryptographic key component associated with the authenticated user; construct an unencrypted DEK associated with the hardened user key for accessing a subset of the data stored within the container; and decrypt the subset of the data using the unencrypted DEK.

[0012] In yet another aspect, the present application describes a non-transitory computer-readable storage medium storing processor-readable instructions that, when executed, configure a processor to perform one or more methods described herein. In this regard, the term "processor" is intended to include all types of processing circuits or chips capable of executing program instructions.

[0013] Those skilled in the art will be able to appreciate other aspects and features of the present application through a review of the following description of the examples in conjunction with the accompanying drawings.

[0014] In this application, the terms "about," "approximately," and "substantially" are intended to encompass possible variations in the upper and lower limits of a range of values, such as variations in properties, parameters, and dimensions. In a non-limiting example, the terms "about," "approximately," and "substantially" can mean plus or minus 10% or less.

[0015] In the present application, the term “and / or” is intended to cover all possible combinations and subcombinations of the listed elements, including only any one element, any subcombination, or all elements of the listed elements, without necessarily excluding additional elements.

[0016] In this application, the phrase "at least one of... or..." is intended to cover any one or more of the listed elements, including only any one element, any subcombination, or all of the listed elements, without necessarily excluding any additional elements, nor necessarily requiring all elements.

[0017] The present application relates to devices and methods for managing data stored in containers. A container can be a component of sandbox technology for limiting access to specified data or applications stored on a computing device. That is, a container can be an allocated portion of addressable memory on a computing device that is used to separate a specified set of data or applications from another set of data or applications stored in the memory. To illustrate, a data container can separate enterprise data from personal data stored in the memory of an electronic device, and vice versa. A computing device can require that access to the enterprise be authorized only in response to a successful authentication process, while access to personal data can be authorized without an authentication process. In another illustrative example, an application container can encapsulate files, dependencies, or libraries of a software application running in an operating system.

[0018] To further protect the data or applications stored within the container, the computing device can encrypt the data using a data encryption key (DEK). The security strength of the encrypted data can be linked to the security strength of the method used to manage the DEK. It may be desirable to reduce the storage of DEKs in their original or unprotected format. For example, the unprotected DEK can be an unencrypted DEK.

[0019] To increase data security, a computing device may encrypt the DEK using a user key derived from a user secret and received from the user. That is, the user secret may be a data input used to determine whether access to data or a data container may be provided to a user associated with the data input. In some examples, the user secret may be an alphanumeric password or biometric input from the user. The user secret may be used to authenticate the user associated with the container and may be used to protect the DEK. In some examples, the user key may be generated based on the received user secret and a password-based derivation function (e.g., Password-Based Key Derivation Function 2 (PBKDF2)). However, the above-described example method of generating the user key based on the received user secret and a password-based derivation function may be susceptible to "offline attacks." That is, an unscrupulous entity may attempt to extract data from the computing device or copy the data to another computing device (e.g., an offline device) to perform brute force operations. Such brute force operations may be used to discover the user key used to decrypt the DEK. It may be desirable to provide devices and methods for preventing such attempts to conduct offline attacks.

[0020] refer to Figure 1 , Figure 1 A computing device 100 for managing data according to an example of the present application is shown in simplified block diagram form. The computing device 100 includes a security module 110 and a main processor 102 coupled to the security module 110. In some examples, the computing device 100 may include a communication module for providing network communication capabilities with other computing devices. For example, the computing device 100 may receive commands or data (e.g., user secrets, etc.) as input via the communication module for use in the example operations described herein.

[0021] The security module 110 may be an integrated circuit configured to provide secure data including the identity and known internal state of the computing device 100. In some examples, the security module 110 may include a cryptographic processor 112 configured to perform operations related to encryption, signing, key generation, random number generation, etc. The security module 110 may include a secure repository 114, such as a non-volatile memory, for storing confidential or proprietary data associated with the computing device 100. In some example operations described herein, the main processor 102 and / or the cryptographic processor 112 may directly or indirectly retrieve data stored in the secure repository 114. As an illustrative example, the security module 110 may be a trusted platform module (TPM) device or other similar device.

[0022] The computing device 100 may include memory for storing applications or other data. For example, the computing device 100 may include memory for storing a container management application 120, a system log 122, and / or a data repository 130. The container management application 120 may include processor-readable instructions that, when executed, cause the main processor 102 and / or the cryptographic processor 112 to perform operations for managing data stored within the container 132, as well as other example operations described herein. The system log 122 may be a data file that includes encryption keys, registered user information, or other data used to manage stored data.

[0023] The computing device 100 includes a data repository 130 for storing data, applications, file systems, etc. The data repository 130 may include one or more containers 132, such as security boundaries associated with a given data, application, or file system. Figure 1 , a single container is shown, but it is contemplated that data repository 130 may include any number of containers. In some examples, container 132 may be similar to a component of a security boundary and sandbox technology used to restrict access to specified data or applications. Container 132 may be associated with at least one registered user. Furthermore, once the registered user has been authenticated, one or more processors may allow the at least one registered user to access the data or applications stored within the container.

[0024] In some examples, the data or applications stored in container 132 can be encrypted using a data encryption key (DEK) and stored as encrypted data. As an example, the data or applications stored in container 132 can be encrypted using the Advanced Encryption Standard Cipher Block Chaining (AES-CBC) mode using a 256-bit key (e.g., DEK). It should be understood that other examples of encryption protocols can be used. The DEK can also be encrypted using a user key, where the user key can be generated based on a user secret (e.g., a password, biometric input, etc.). The management server or management user can specify the key length associated with the user key. In some examples, once one or more processors can be configured to delete container 132, the data or applications stored in container 132 can be deleted accordingly. In some examples, one or more processors can register container 132 by associating the generated user key with container 132. One or more processors can perform operations to allow access to the data or applications in container 132 in response to receiving the associated user key.

[0025] In some examples, computing device 100 includes input module 140. Input module 140 can include a touch screen display for displaying a user interface and a touch screen interface for receiving motion or touch input from a user of computing device 100. Input module 140 can provide a user interface for user interaction with computing device 100. Other examples of input / output modules are contemplated for displaying content to a user or for receiving input signals representing commands or selectable options from a user of computing device 100.

[0026] refer to Figure 2 , Figure 2 An encryption key derivation operation 200 according to one example of the present application is shown. The host processor 102 may perform a random number generator operation 202 to generate a data encryption key 204 (e.g., a DEK). Furthermore, the host processor 102 may perform an encryption operation 208 to encrypt application data 206 using the data encryption key 204. The encryption operation 208 may include utilizing an AES-CBC protocol using a 256-bit key. In some examples, the length of the data encryption key 204 may be 256 bits. The resulting encrypted application data may be stored within the container 132.

[0027] In some examples, application data 206 may include two or more files, or may include two or more data portions. In addition, there may be two or more cryptographic initialization vectors, and each initialization vector may be associated with a data file or portion of data. Thus, host processor 102 may perform encryption operation 208 on a corresponding file or portion of data using a corresponding initialization vector, thereby encrypting a given file or portion of data separately from encrypting another file or portion of data. Other encryption protocols for performing encryption operation 208 are contemplated.

[0028] In some examples, the degree to which encrypted application data can be protected corresponds to the degree to which data encryption key 204 is protected. That is, it may be desirable to restrict the use of data encryption key 204 to one or more registered users associated with container 132. It may be desirable to reduce the storage of DEKs in plain text or unprotected format. That is, it may be desirable to reduce the storage of unencrypted DEKs.

[0029] The host processor 102 may perform additional encryption operations 210 to protect the data encryption key 204. The additional encryption operations 210 may use a user key 212 to encrypt the data encryption key 204. In some examples, the additional encryption operations 210 may include utilizing an AES-CBC protocol using a 256-bit key. That is, the length of the user key 212 may be 256 bits. Other encryption protocols are contemplated for performing the additional encryption operations 210.

[0030] The user key 212 may be based on the Figure 1 ) via the input module 140 ( Figure 1 ) provided by the host processor 102. For example, the user secret 214 can be an alphanumeric input or a biometric input. Other formats of the user secret 214 are contemplated. Upon receiving the user secret 214, the host processor 102 can perform a key derivation operation 216 to derive the user key 212. In some examples, the key derivation operation 216 can include a password-based key derivation function 2 (PBKDF2) operation. Other key derivation operations are contemplated. Based on the user secret 214, the key derivation operation 216 can derive the user key 212 having a specified length. For example, the host processor 102 can derive the user key 212 having a length of 256 bits, so that the host processor 102 can perform additional encryption operations 210 to encrypt the previously generated data encryption key 204 using the user key 212.

[0031] In response to encrypting the data encryption key 204 using the generated user key 212, the main processor 102 can store the data encryption key 204 in an encrypted format in the key store 218. In some examples, the key store 218 can be a repository of stored security credentials such as public key certificates, cryptographic keys, etc. In some examples, the key store 218 can be a data file, a cryptographic token, or other allocated portion of memory accessible to the operating system or applications. In some examples, Figure 1 The system log 122 may include a keystore 218. That is, the keystore 218 may not be stored within the secure enclave, but may be stored in a memory accessible to the host processor 102. In some other examples, the keystore 218 (or the contents of the keystore 218) may be encrypted or otherwise obfuscated based on a static key, where the static key may be stored at the computing device 100.

[0032] In some examples, the host processor 102 can generate a data encryption key 204 or a user key 212 of any length. For example, the length of the data encryption key 204 or the user key 212 can be 256 bits or greater. A longer key length can improve the robustness of any generated encryption key. However, in some examples, Figure 2The encryption key derivation operation 200 shown may be susceptible to an "offline attack." That is, an unscrupulous entity may attempt to extract data from the computing device 100 or copy the data to another computing device (e.g., an offline device) to perform a brute force operation to determine the user key 212. In some examples, the offline computing device may include a supercomputer, such as a computer with a high floating point operations per second compared to a general purpose computer. Other types of computers are contemplated for use as offline devices whose hardware / software is configured to perform operations to "crack" / reverse engineer passwords or whose floating point operations per second are high. Once the user key 212 is derived, the unscrupulous entity may decrypt the encrypted form of the data encryption key 204. To further increase the robustness of the operation to protect the data encryption key 204, a method is provided that includes a secure module 110 ( Figure 1 ) devices and methods for operating.

[0033] refer to Figure 3 , Figure 3 The flowchart shows the management of the example stored in the computing device 100 ( Figure 1 ) on the container 132 ( Figure 1 ). The method 300 includes operations that may be performed by one or more processors of the computing device 100. For example, the method 300 may include operations that may be performed by at least one of the main processor 102 or the cryptographic processor 112. The method 300 may be performed at least in part by communicating with the container management application 120 ( Figure 1 ) associated processor-executable instructions. In some examples, one or more operations may be implemented in other applications or in an operating system stored on and executed on the computing device 100 via the processor-executable instructions.

[0034] In some examples, container 132 ( Figure 1 ) can be associated with at least one registered user. That is, one or more processors can register container 132 by associating one or more users with the container 132, where each respective user can be associated with a user secret (e.g., a password). The user secret can be used to authenticate the user at computing device 100 and to provide access to data and / or applications stored within container 132. Data stored within container 132 can be encrypted using a data encryption key (DEK) and stored as encrypted data.

[0035] At operation 302, one or more processors may authenticate a user based on a user secret associated with the container 132. The user secret may be an alphanumeric input or a biometric input. That is, the computing device 100 may authenticate the user so that the user may be allowed to operate the input module 140 ( Figure 1 ) and may be allowed to access or modify data stored within container 132. Other types of input for receiving user confidentiality may be considered.

[0036] At operation 304, one or more processors may generate a soft key based on the user secret. The soft key may be a key derived based on a software derivation function and the user secret. In some examples, the software derivation function may include operations performed by a main processor or a general-purpose processor of the computing device. One or more processors may use a key derivation function such as a password-based key derivation function 2 (PBKDF2) to generate the soft key. For example, the key derivation function may apply a pseudorandom function to the user secret and a salt value to generate the user secret key. The user secret key may be used as a cryptographic key for subsequent operations. The salt value may be random data used as an additional input to the pseudorandom function. Other key derivation functions for generating the soft key may be considered. For example, the key derivation function may be a hash-based message authentication code (HMAC). In some examples, the key derivation function may provide a soft key with a specified length. For example, one or more processors may be configured to generate a soft key with a 256-bit length.

[0037] At operation 306, the cryptographic processor 112 ( Figure 1 ) can generate a secure generator output including a cryptographic key component associated with the authenticated user. The secure generator output can be based on a secure random number generator output, such as a pseudo-random number generator having properties that can be understood as suitable for cryptographic operations. The cryptographic processor 112 can be a processor other than the main processor 102 ( Figure 1 ). In some examples, the cryptographic processor 112 may be a distinct processor separate from the main processor 102 that is used to perform operations related to encryption, key or data signing, key generation, random number generation, etc. The cryptographic processor 112 may be a component of the security module 110 such that select data or keys generated by the cryptographic processor 112 may be restricted to the security module 110 and may not be allowed to be copied or released in plain text or unencrypted format outside of the security module 110.

[0038] In some examples, the security generator output includes a first elliptic curve cryptography (ECC) key pair and a second ECC key pair. Each of the respective ECC key pairs includes a private key and a public key. In this example, the cryptographic processor 112 can discard the public key of the first ECC key pair and the private key of the second ECC key pair, such that the cryptographic key component includes the private key of the first ECC key pair and the public key of the second ECC key pair.

[0039] At operation 308, the cryptographic processor 112 may generate a hardened user key based on a key agreement protocol using the soft key and a cryptographic key component associated with the authenticated user. The hardened user key may be a key derived based on one or more cryptographic keys generated by a secure hardware component of the computing device. In some examples, at least a portion of the cryptographic key generated by the secure hardware component may be restricted to the secure hardware component or accessible only when access to the secure hardware component is provided. In some examples, the key agreement protocol may be based on elliptic curve cryptography, such as the Elliptic Curve Diffie-Hellman (ECDH) protocol or operation. In this example, the hardened user key may be generated based on a previously generated soft key and a cryptographic key component. Because the hardened user key is based on the cryptographic key component, it may be challenging for an unscrupulous entity to extract or copy the memory contents of the computing device 100 to another computing device (e.g., an offline device) and then perform a brute force operation to determine the user key used to decrypt the data encryption key associated with the container 132. That is, because the private key of the first ECC key pair may be contained in the security module 110 and inaccessible to external computing devices or processes, an unscrupulous entity may not be able to generate the hardened user key. In the event that the hardened user key cannot be generated, an unscrupulous entity may be unable to decrypt the hardened DEK to decrypt the associated data stored within the container 132 .

[0040] In some examples, in a previous process, the one or more processors may have encrypted the data stored in the container 132 using the Advanced Encryption Standard (AES) protocol and the hardened user key. When a user requests access to the data stored in the container 132, the one or more processors may construct an unencrypted DEK associated with the hardened user key to access a subset of the data stored in the container 132 at operation 310.

[0041] At operation 312, the one or more processors may use the unencrypted DEK to decrypt the subset of data. Thus, when the one or more processors receive a user secret from a registered user, the example operations of the main processor 102 and the cryptographic processor 112 described herein may together generate a hardened user key that may be used to decrypt the previously encrypted DEK. The unencrypted DEK may be used to decrypt data that may be associated with the authenticated user and stored within the container 132.

[0042] In some examples, the one or more processors may also use the unencrypted DEK to protect additional data associated with the authenticated user. That is, the one or more processors may perform operations for receiving the additional data from another computing device or via input module 140 via the communication module. Furthermore, the one or more processors may use the unencrypted DEK (from operation 310) to encrypt the additional data and then store the encrypted additional data within container 132.

[0043] In some examples, constructing the unencrypted DEK includes decrypting the enhanced DEK using an Advanced Encryption Standard (AES) protocol and an enhanced user key. For example, the AES protocol can be an AES-CBC protocol operation.

[0044] A subset of the operations of method 300 may be performed by the host processor 102, while another subset of the operations of method 300 may be performed by the cryptographic processor 112. For example, operations 302, 304, 310, and 312 may be performed by the host processor 102, while operations 306 and 308 may be performed by the cryptographic processor 112. That is, the cryptographic processor 112 may perform operations associated with generating a cryptographic key component and generating a hardened user key using the key component that is intended to be non-decryptable outside of the security module 110. Thus, in addition to a soft key and a user secret received from a registered and authenticated user associated with the container 132, the example operations of method 300 may also generate a hardened user key based on the key component that relies on secure hardware aspects of the computing device 100.

[0045] To illustrate with a specific example Figure 3 Method 300, reference Figure 4 , Figure 4 FIG. 4 shows an example of an enhanced user key generation operation 400 according to the present application. Figure 4 In the example, a subset of operations can be performed with the security module 110 ( Figure 1 ), which operations are shown within the dashed box. A subset of the operations that may be associated with the security module 110 may be performed by the cryptographic processor 112. In this example, another subset of operations shown outside the hash box may be performed by the main processor 102.

[0046] As described in some examples herein, the DEK may be used to encrypt data, applications, file systems, etc., where the encrypted data, applications, or file systems may be stored on the computing device 100 ( Figure 1 ) container 132( Figure 1). The registered container may be associated with a user who may wish to protect and store data within the container 132. The data may be encrypted using the DEK, and then the encrypted data may be stored in the container 132. It should be understood that the DEK may be encrypted using the hardened user key. Thus, data that has been encrypted using the DEK may be associated with the user corresponding to the hardened user key. Figure 4 As described, the strengthening of user keys can be based on the security module 110 ( Figure 1 ) and operations that can be executed outside the security module 110.

[0047] Main processor 102 ( Figure 1 ) can be accessed via the input module 140 ( Figure 1 ) Receive a user secret 402. In some examples, the user secret may be an alphanumeric password, or may be a biometric input.

[0048] The host processor 102 may perform a key derivation operation 404, such as an operation of the PBKDF2 protocol, based on the user secret 402 to generate a soft user key 406. In this example, the PBKDF2 protocol may provide a 256-bit soft user key using a user salt value based on 64 bits of randomly generated data and the user secret 402. It should be understood that the user salt value may be based on other amounts of randomly generated data, and the soft user key 406 may be any other length.

[0049] The cryptographic processor 408 can generate two sets of randomly generated data (identified as 410a and 410b, respectively) through a secure random number generator (RNG) operation to provide encryption keys. In this example, the first set of randomly generated data 410a can provide a first ECC key pair, including a private key 412 of the first ECC key pair and a public key 414 of the first ECC key pair. Similarly, the second set of randomly generated data 410b can provide a second ECC key pair, including a private key 416 of the second ECC key pair and a public key 418 of the second ECC key pair.

[0050] In this example, the cryptographic processor 408 can delete 420 or ignore the public key 414 of the first ECC key pair and can delete or ignore the private key 416 of the second ECC key pair. The remaining private key 412 of the first ECC key pair and the public key 418 of the second ECC key pair can be used as input to a subsequent key agreement protocol operation to generate a hardened user key 424. In some examples, the hardened DEK can be stored in a non-migratable portion of the computing device. In this example, the ECC keys that are not deleted or ignored can be accessible to the cryptographic processor 408 in response to successful authentication of the user. For example, based on the received user secret, the ECC keys can be accessible in response to successful authentication of the user.

[0051] In some examples, the public key 418 of the second ECC key pair may be stored in a key store external to the security module 110, while the private key 412 of the first ECC key pair may be stored within the security module 110. For example, the private key 412 of the first ECC key pair may be stored in the secure repository 114 ( Figure 1 It should be understood that these aforementioned keys can be associated with the user of the user secret 402. When the computing device 100 requires a hardened key associated with an authorized user corresponding to the user secret 402, the cryptographic processor 408 can generate a hardened user key 424 based on the soft user key 406 as input to an additional cryptographic operation 422.

[0052] The host processor 102 may perform an additional cryptographic operation 422 based on the generated soft user key 406, the private key 412 of the first ECC key pair, and the public key 418 of the second ECC key pair. For example, the additional cryptographic operation 422 may utilize the soft user key 406 as input to an elliptic curve Diffie-Hellman (ECDH) protocol operation to generate a hardened user key 424 using: (a) the private key 412 of the first ECC key pair and (b) the public key 418 of the second ECC key pair. For example, the soft user key 406 may be provided to the elliptic curve Diffie-Hellman (ECDH) protocol operation as an ECC-CMS-SharedInfo entityUInfo parameter. That is, the ECC-CMS-SharedInfo entityUInfo field may represent a derived form of the data provided by the user (e.g., see https: / / tools.ietf.org / html / rfc8418).

[0053] In some examples, the hardened user key 424 can be used to encrypt a DEK that was previously used to encrypt data stored in the container 132 ( Figure 1) and is associated with the user corresponding to the user secret 402. It should be understood that the hardened user key 424 can be based on: (i) the user secret 402 that can be used to authenticate the user; and (ii) an encryption key that may be at least partially inaccessible to processes outside of the security module 110. Therefore, even if the unscrupulous entity successfully copies the data (including the data within the container) to an offline computing device, the unscrupulous entity's "offline attack" may be thwarted. Based on the devices and methods described herein, the unscrupulous entity may not be able to generate the hardened user key 424 necessary to: (a) decrypt the DEK associated with the data stored in the container 132; and (b) subsequently decrypt the data stored in the container. Without the unencrypted DEK, the unscrupulous entity may not be able to decrypt the data stored in the container.

[0054] In another implementation, one of the main processor or the cryptographic processor may receive a user secret. Based on the user secret, the main processor or the cryptographic processor may generate an ECC public key based on the user secret. For example, the main processor or the cryptographic processor may map the user secret or a representation of the user secret to a point on an elliptic curve associated with cryptographic operations of the computing device. Thus, the ECC public key may be identified at a specific point on the elliptic curve. The cryptographic processor may then perform an ECDH operation using the generated ECC public key to generate a hardened user key for decrypting the DEK.

[0055] refer to Figure 5 , Figure 5 An electronic device 500 according to an example of the present application is shown in the form of a simplified block diagram. The electronic device 500 may be Figure 1 An example computing device 100 is shown.

[0056] The electronic device 500 includes one or more main processors 502, a memory 504, and a communication module. The communication module can provide the computing device 100 with network capabilities for communicating with other computing devices. The memory 504 can include a data repository 506 for storing data, applications, file systems, etc. In addition, the data repository 506 can include Figure 1 One or more example containers 132. The memory 504 may store processor-executable software applications 508 that may include an operating system for providing basic device operations. The software applications 508 may also include instructions that implement the operations of the methods described herein.

[0057] The electronic device 500 may include a security module 510, which may be a hardware-based circuit for providing trusted information, including the identity and internal state data of the electronic device 500. The security module 510 may provide cryptographic functions, including encryption, signing, key generation, random number generation, etc. In one example, the security module 510 may correspond to Figure 1 security module 110.

[0058] The electronic device 500 may include an input module 512 for receiving signals representing user input. For example, the input module 512 may be a keyboard device, a touch input device, an acoustic input device, or any other device for receiving signals representing user input as described in the examples herein. The electronic device 500 may include a display interface and / or display 514. The display 514 may include examples such as a liquid crystal display (LCD), an electronic ink / electronic paper display, etc. In some examples, the display 514 may be a touch screen display.

[0059] In some examples, electronic device 500 can be a portable electronic device such as a smart phone, a personal computer, a personal digital assistant, a portable navigation device, a mobile phone, a wearable computing device (e.g., a smart watch, a wearable activity monitor, etc.), or any other type of computing device that can be configured to store data and software instructions and execute software instructions to perform the example operations described herein.

[0060] The example embodiments of the present application are not limited to any particular operating system, system architecture, mobile device architecture, server architecture, or computer programming language.

[0061] It will be understood that the applications, modules, routines, processes, threads or other software components that implement the described methods / processes can be implemented using standard computer programming techniques and languages. The present application is not limited to a particular processor, computer language, computer programming conventions, data structures or other such implementation details. Those skilled in the art will recognize that the described processes can be implemented as part of a computer executable code stored in a volatile or non-volatile memory, as part of an application specific integrated circuit (ASIC), etc.

[0062] Certain adaptations and modifications may be made to the described embodiments.Therefore, the embodiments discussed above are considered to be illustrative rather than restrictive.

Claims

1. A method of managing data stored within a container on a computing device, the container being associated with at least one registered user, the data within the container being encrypted by a data encryption key (DEK) and stored as encrypted data, the method comprising: authenticating a user based on a user secret associated with the container; generating a soft key based on the user secret; generating, by a cryptographic processor other than a main processor of the computing device, a security generator output, the security generator output including a cryptographic key component associated with the authenticated user; generating, by the cryptographic processor, a hardened user key based on a key agreement protocol using the soft key and the cryptographic key component associated with the authenticated user; constructing an unencrypted DEK associated with the hardened user key for accessing a subset of the data stored in the container; as well as The subset of the data is decrypted using the unencrypted DEK. 2 . The method of claim 1 , wherein the secure generator output comprises a first Elliptic Curve Cryptography (ECC) key pair and a second ECC key pair.

3. The method according to claim 2, further comprising: A public key of the first ECC key pair and a private key of the second ECC key pair are discarded by the cryptographic processor, and wherein the cryptographic key component includes the private key of the first ECC key pair and the public key of the second ECC key pair. The method of claim 1 , wherein the key agreement protocol is based on elliptic curve cryptography.

5. The method of claim 1, wherein the key agreement protocol comprises Elliptic Curve Diffie-Hellman (ECDH).

6. The method of claim 1, wherein the soft key comprises a specified length and is generated using a Password-Based Key Derivation Function 2 (PBKDF2).

7. The method of claim 6, wherein the PBKDF2 operation comprises a Hash-based Message Authentication Code (HMAC) operation.

8. The method of claim 1, wherein constructing the unencrypted DEK comprises decrypting a hardened DEK using an Advanced Encryption Standard (AES) protocol and the hardened user key, wherein the hardened DEK is stored in a non-migratable portion of the computing device.

9. The method of claim 1, further comprising using the unencrypted DEK to protect additional data associated with the authenticated user.

10. The method of claim 1, wherein the secure generator output is based on a secure random number generator output.

11. A computing device for managing data stored in a container, the container being associated with at least one registered user, the data in the container being encrypted by a data encryption key (DEK) and stored as encrypted data, the computing device comprising: security modules, including cryptographic processors; a main processor coupled to the security module; as well as a memory coupled to the processor and the cryptographic processor, the memory storing instructions that, when executed, configure at least one of the main processor or the cryptographic processor to: authenticating a user based on a user secret associated with the container; generating a soft key based on the user secret; generating, by the cryptographic processor, a security generator output comprising a cryptographic key component associated with the authenticated user; generating, by the cryptographic processor, a hardened user key based on a key agreement protocol using the soft key and the cryptographic key component associated with the authenticated user; constructing an unencrypted DEK associated with the hardened user key for accessing a subset of the data stored in the container; as well as The subset of the data is decrypted using the unencrypted DEK.

12. The computing device of claim 11, wherein the secure generator output comprises a first Elliptic Curve Cryptography (ECC) key pair and a second ECC key pair.

13. The computing device of claim 12 , wherein the instructions, when executed, further configure the cryptographic processor to discard the public key of the first ECC key pair and the private key of the second ECC key pair, and wherein the cryptographic key component includes the private key of the first ECC key pair and the public key of the second ECC key pair.

14. The computing device of claim 11, wherein the key agreement protocol is based on elliptic curve cryptography.

15. The computing device of claim 11, wherein the key agreement protocol comprises Elliptic Curve Diffie-Hellman (ECDH).

16. The computing device of claim 11, wherein the soft key comprises a specific length and is generated using a Password-Based Key Derivation Function 2 (PBKDF2).

17. The computing device of claim 11, wherein constructing the unencrypted DEK comprises decrypting a hardened DEK using an Advanced Encryption Standard (AES) protocol and the hardened user key, wherein the hardened DEK is stored in a non-migratable portion of the computing device.

18. The computing device of claim 11, wherein the instructions, when executed, further configure the main processor to use the unencrypted DEK to protect additional data associated with the authenticated user.

19. The computing device of claim 11, wherein the secure generator output is based on a secure random number generator output.

20. A non-transitory computer-readable storage medium storing instructions for managing data stored within a container, the container being associated with at least one registered user, the data within the container being encrypted by a data encryption key (DEK) and stored as encrypted data, the instructions, when executed by at least one of a main processor or a cryptographic processor of a computing device, causing the computing device to: authenticating a user based on a user secret associated with the container; generating a soft key based on the user secret; generating, by the cryptographic processor, a security generator output comprising a cryptographic key component associated with the authenticated user; generating, by the cryptographic processor, a hardened user key based on a key agreement protocol using the soft key and the cryptographic key component associated with the authenticated user; constructing an unencrypted DEK associated with the hardened user key for accessing a subset of the data stored in the container; as well as The subset of the data is decrypted using the unencrypted DEK.

Images