WO2022199796A1 - Method and computer-based system for key management - Google Patents

Abstract

A method and system for secure key handling and cryptographic processing of data on a computer using a Key Management System, KMS (2), where an application key, AK (6), is encrypted first by a key encryption key, KEK (16); the encrypted key, C (8), is put together with its ACP (9); and the resulting concatenation (10) is signed by a key signing key, KSK (17), to obtain a signature (11) to be included in a tuple (12). Such a KMS (2) design ensures that the ACP (9) for an AK (6) cannot be modified outside of the KMS (2) or replaced by that of another key without rendering the key unusable, and that ACP (9) queries and enforcement can be done without decrypting the AK (6).

Description

METHOD AND COMPUTER-BASED SYSTEM FOR KEY MANAGEMENT

TECHNICAL FIELD

The disclosure relates to data security, more particularly to methods and systems for secure key handling and cryptographic processing.

BACKGROUND

A Key Management System (KMS) is a functional component in a computing device that is mainly responsible for lifecycle management of cryptographic key material for applications, and for performing cryptographic operations using the key material upon requests from applications.

Lifecycle management tasks typically include generation of new keys, import of keys from another KMS or application, deletion of existing keys, answer queries about keys from applications, and the creation/modification of access control policies that define the conditions under which the keys can be used.

Cryptographic operations using the keys may include computing and verifying digital signatures, encryption and decryption, key agreement and derivation, and sometimes more complex protocols such as key attestation.

On devices where a more secure mode called Trusted Execution Environment (TEE) is available, it is common for the KMS on such a device to utilize the TEE to protect key material for applications to prevent the keys from being extracted even when the less secure side, called the Rich Execution Environment (REE) of the device, where most applications run, has been compromised. A KMS typically utilizes a TEE in a few ways. First, the most critical component of the software of a KMS, sometimes referred to as a Trusted Application, runs in the TEE only, so that this piece of software is more trustworthy and is protected by the TEE from malicious or accidental modifications. Secondly, the TEE can provide a root storage key that is only accessible by the Trusted Application of the KMS. This storage key can then be used to protect data managed by the KMS, i.e., the key material for applications. Thirdly, a TEE may provide hardware cryptographic accelerators or engines that allow the KMS to perform cryptographic operations in more secure and efficient ways. The protection of the key material typically involves two aspects. The first is the protection of the key material so that it is not directly accessible from the REE. This usually involves encryption of the key material by the storage key, or some keys derived from it, and often requires another mechanism, such as digital signatures or message authentication codes, to make sure that the encrypted keys are not modified in storage. The second is to control the access to the keys, such as which applications can use which keys at which times, the state that the device must be in for the keys to be usable, whether user authentication is required to use the keys, and so on. We refer to these rules for accessing the keys the Access Control Policies (ACPs). Part of the ACP for a key can be specified by the application who owns the key, and part may be specified by the operating system or the TEE. Part, if not all, of the ACP are enforced in TEE, to minimize the attack surfaces of the KMS.

An issue to be solved is that, as the National Institute of Standards and Technology (NIST) also recommends, keys and policies should be cryptographically bound. This is to make sure that an attacker, who is not able to decrypt the encrypted keys, cannot gain access to the keys by manipulating the ACP.

Another issue to be addressed is that the TEE of a device is typically much slower and computationally less capable compared to the REE, and switching between REE and TEE takes time. Furthermore, more code could mean more bugs and vulnerabilities for the system.

One way the prior art addresses these issues is by providing a KMS that puts the ACP for a key together with the key itself, and encrypts the result using a storage key. When this method is used, all key management operations on a specific key would affect both the key and its policy since they are encrypted together. For example, when a key is generated, the KMS has to also specify its ACP, so that they can be put together for the encryption. Any changes of the ACP would also require re-encryption of the key blob. A particular issue with this case is when an application sends a request to perform a cryptographic operation with a key, e.g. Key 1, the KMS would have to decrypt an Encrypted Blob 1 first, extract Policy 1 from the decrypted blob, and check if the request is allowed by Policy 1.

This method is often used when the encryption of the key blob is not done by the KMS itself, but rather provided by the underlying operation system as a secure storage service. By separating the data encryption step, it may slightly reduce the complexity of the KMS.

However, the disadvantages of this method are quite clear. Since the ACP is encrypted, it has to be decrypted before it can be queried or enforced. This introduces a few issues. First, queries on the key policies can be expensive since they are only available in TEE and policies need to be decrypted. Second, it increases the risk of key leakage since the key itself also gets decrypted unnecessarily when the ACP is being queried or enforced. Thirdly, it increases the risk of specific types of attacks such as Denial-of-Service (DoS) attacks or side-channel attacks, simply because a decryption operation is forced to be performed whenever the ACP is being queried or enforced.

It is also common to see a KMS with a centralized policy database, where all the access policies for all the keys managed by the KMS are stored in a central location, which could be a relational database, a file, a directory or even rules that are hardcoded into the software, which can all be defined as a Central Policy Database (CPD) to differentiate from the previously mentioned prior art method, where the ACP for a key is encrypted and stored together with the key.

In this method, separate protection mechanisms are applied to the keys and their policies. For example, the key material may be encrypted with one storage key, and the policy database is encrypted using another database key. Queries and modifications to the policies can be done independently from the encrypted keys. When an application requests to perform a cryptographic operation, the policy stored in the database can be queried and enforced without the need to decrypt the keys.

A major issue with this method is that the central policy database can become a target of attack, and hence requires additional efforts for protection. Compared with methods where the ACP for a key is encrypted and stored together with the key, extra care is required in this method to make sure that the ACP for a key cannot be modified by unauthorized parties, cannot be deleted either accidentally or intentionally, without deleting also the key, and cannot be swapped with the ACP for a different key. The CPD must also be roll-back protected to prevent attackers to exploit an old version of the database that may have outdated policies. These additional protections may introduce extra complexities and risks to the system.

In many implementations of KMS, traces of both previously described methods can be found. In other words, part of the ACP of a key may be stored and encrypted together with the key itself, and other parts may be found in a central policy database. For example, according to an implementation, algorithm specific information is put together with the key when it is encrypted, but information such as application identity is left outside of the key. Rules, such as rules defining that applications can only access the keys they generate by default, are often hardcoded into the software logic. In such implementations, in addition to the previously mentioned issues, the decryption of the key blob and the query, and enforcement of the policies are independent steps, which results in security risks. SUMMARY

It is an object to provide an improved method and system for secure key handling and cryptographic processing of data on a computer.

The foregoing objects are achieved by providing computer-implemented methods of designing a KMS that ensure that the ACP for a key cannot be modified outside of the KMS or replaced by that of another key without rendering the key unusable; and that ACP queries and enforcement can be done without decrypting the keys.

The main idea of the disclosed methods is to “encrypt-then-sign”, where the application key (AK) should be encrypted first by an encryption key, the encrypted key put together with its ACP, and the result signed by a signing Key.

The foregoing and other objects are achieved in particular by the features of the independent claims. Further implementation forms are apparent from the dependent claims, the description and the figures.

According to a first aspect, there is provided a method of secure key handling and cryptographic processing of data implemented on a computer, the method comprising receiving a request by a Key Management System, KMS, from an application to perform a cryptographic operation, the request comprising a reference to an application key, AK, and context information; retrieving a key blob from a storage medium by the KMS, the key blob comprising a ciphertext, C, corresponding to the AK and Access Control Policies, ACP, defining rules of accessing the AK; validating the ACP by the KMS based on the context information; decrypting the C by the KMS using the validated ACP as input to obtain the AK; and performing the requested cryptographic operation by the KMS using the obtained AK.

By implementing this method to encrypt and then decrypt data it becomes possible to ensure that the ACP for a key cannot be modified outside of the KMS. It is further ensured that the key cannot be replaced by that of another key without rendering the key unusable. A third advantage is that ACP queries and enforcement can be done using this method without decrypting the keys.

In other words, the method enables to protect AKs and their ACPs in a KMS that is more efficient and secure compared with prior art. With the method, the particular advantages over the prior art are described as follows. ACPs are integrity protected but not encrypted in storage. ACPs are checked and enforced before decrypting the key materials. The ACP for a key is used as a parameter when decrypting the key materials so that keys cannot be decrypted without presenting the unmodified ACP. ACPs for keys can be queried without decrypting the key materials. This allows, for example, applications to quickly find the right key to use under a certain scenario without a round trip to the TEE for decryption, hence achieving better performance.

Hence, the method enables to enforce strong binding between key materials in a KMS and their ACP, allowing better performance and security at the same time, without any extra cost for maintaining a central policy database.

Security benefits of the method include reduced risks of policy tampering or by-passing (policies are cryptographically bound to keys), and reduced risks of Denial-of-Service or side- channel attacks (less round-trips to TEE).

In a possible implementation form of the first aspect the C in the key blob is encrypted with a key encryption key, KEK, using an encryption algorithm, and the decrypting the C by the KMS using the validated ACP as input to obtain the AK comprises decrypting the C by the KMS with an encryption key using the encryption algorithm, the encryption key being the same symmetric key as the KEK or a corresponding asymmetric key pair to the KEK and configured to be accessible exclusively by the KMS within a Trusted Execution Environment, TEE, to obtain the AK. This method enables to enforce strong binding between key materials in a KMS and their ACP, while using the ACP for a key as a parameter when decrypting the key materials ensures that keys cannot be decrypted without presenting the unmodified ACP.

In a further possible implementation form of the first aspect the C in the key blob is concatenated with the ACP, and the resulting concatenation is signed with a key signing key, KSK, using a signing algorithm to obtain a signature, to be included in the key blob as a tuple; and the method further comprises: before decrypting the C, verifying the signature in the key blob by the KMS against the concatenation using the signing algorithm with a signing key, the signing key being the same symmetric key as the KSK or a corresponding asymmetric key pair to the KSK. This ensures that ACPs for keys can be queried without decrypting the key materials, which in turn allows applications to quickly find the right key to use under a certain scenario without a round trip to the TEE for decryption, hence achieving better performance.

EMBODIMENT 1

In a further possible implementation form of the first aspect the method further comprises providing on the computer at least one Storage Key, SK, configured to be accessible exclusively by the KMS; wherein the C in the key blob is encrypted using an Authenticated Encryption with Associated Data, AEAD, encryption algorithm with a KEK derived from the ACP and the SK, and with the ACP further used as the respective Authenticated Associated Data, AAD; wherein the key blob comprises an authentication tag generated by the AEAD encryption algorithm, wherein the authentication tag is used as a signature, in the key blob; and wherein decrypting the C by the KMS comprises authenticating the AAD using the authentication tag; deriving the KEK from the ACP and the SK using a key derivation function, KDF; and using the AEAD encryption algorithm with the ACP used as AAD and the KEK as input for to obtaining the AK.

This implementation achieves the effects on the KMS that ACPs are created when keys are generated or imported to the TEE, wherein the ACPs are integrity protected but not encrypted by the KMS. Furthermore, access control policy enforcements can be done without decrypting the key data. ACP for a key is used as a parameter when decrypting the application keys so that keys cannot be decrypted without presenting the unmodified access control policies. Finally, ACPs for application keys can be queried without decrypting the actual key material. This allows, for example, applications to quickly find the right key to use under a certain scenario without a round trip to the TEE for decryption, hence achieving better performance.

The method further ensures that ACP queries and enforcement can be made much faster compared to prior art, where key decryption needs to be performed before policies are available.

The method also brings improvements in security. First, it is more secure against attacks that attempt to gain access to the AKs by modifying ACPs or switching the policy for one key for another. Secondly, it is also more secure against attacks that attempt to degrade the performance of the KMS by sending many invalid requests that would force the KMS to perform decryptions in order to ACPs. In addition, by avoiding unnecessary decryptions, it is also more secure against side-channel attacks that attempt to learn information about the keys simply by observing the behavior of the KMS, such as timing and power consumption, while the keys are being decrypted.

In a further possible implementation form of the first aspect the method further comprises providing on the computer a Storage Encryption Key, SEK, and/or a Storage Signing Key, SSK, each of the SEK and SSK being configured to be accessible exclusively by the KMS; wherein the KEK is obtained from the SEK by the KMS, either by using the SEK as KEK, or by deriving the KEK from the SEK using the ACP as input parameter; and wherein the KSK is obtained from the SSK by the KMS, either by using the SSK as KSK, or by deriving the KSK from the SSK using the ACP as optional input parameter. This ensures additional security for both encryption and decryption and better performance over the prior art.

In a further possible implementation form of the first aspect the SEK is a distinct symmetric key; wherein the KEK is a symmetric key derived from the SEK by the KMS using a first key derivation function, KDF, with the ACP as input parameter; wherein the C in the key blob is encrypted with the KEK using a symmetric encryption algorithm; and wherein the decrypting the C by the KMS comprises deriving a KEK from the SEK using the first KDF and the ACP as input parameter; and decrypting the C with the KEK using the symmetric encryption algorithm to obtain the AK.

Overall, this method achieves strong binding between AKs and their ACPs in the KMS, in such a way that better performance and security are achieved at the same time. The method also brings improvements in security by being more secure against attacks that attempt to gain access to the AKs by modifying ACPs or switching the policy for one key for another.

In a further possible implementation form of the first aspect the SEK is a distinct symmetric key; wherein the KEK is an asymmetric key pair comprising a private key and a public key derived from the SEK by the KMS using a first key pair derivation function, KPDF, with the ACP as input parameter, the first KPDF being configured to obtain an asymmetric key pair from a symmetric key; wherein the C in the key blob is encrypted with a public key of the KEK, KEK_pub, using an asymmetric encryption algorithm; and wherein decrypting the C by the KMS comprises deriving a private key of the KEK, KEK_priv, from the SEK using the first KPDF and the ACP as input parameter; and decrypting the C with the KEK_priv using the asymmetric encryption algorithm to obtain the AK. This ensures additional security for both encryption and decryption and better performance over the prior art.

In a further possible implementation form of the first aspect the SEK is an asymmetric key pair comprising a private key and a public key which are used by the KMS as a public key of the KEK, KEK_pub, and a private key of the KEK, KEK_priv, respectively; wherein the C in the key blob is encrypted with the KEK_pub using an asymmetric encryption algorithm; and wherein decrypting the C by the KMS comprises decrypting the C with the KEK_priv using the asymmetric encryption algorithm to obtain the AK.

For such asymmetric encryption, the public key is used for encryption and the private key is used for decryption. The public keys often do not need to be kept secret. Furthermore, no key derivation steps are involved, which improves efficiency.

In a further possible implementation form of the first aspect the SSK is a distinct symmetric key; wherein the KSK is a symmetric key obtained from the SSK by the KMS, either by using the SSK as KSK, or by deriving the KSK from the SSK using a second key derivation function, KDF, with the ACP as input parameter; wherein the concatenation in the key blob is signed with the KSK using a symmetric signing algorithm to obtain a signature to be included in the key blob as a tuple; and wherein decrypting the C by the KMS comprises, before decrypting the C with the KEK obtaining a KSK from the SSK using the second KDF or using the SSK as KSK; and verifying the signature in the key blob against the concatenation with the KSK using the symmetric signing algorithm.

This method ensures that ACP queries and enforcement can be made much faster compared to prior art, where key decryption needs to be performed before policies are available. The method also brings improvements in security by being more secure against attacks that attempt to degrade the performance of the KMS by sending many invalid requests that would force the KMS to perform decryptions in order to ACPs. In addition, by avoiding unnecessary decryptions, it is also more secure against side-channel attacks that attempt to learn information about the keys simply by observing the behavior of the KMS, such as timing and power consumption, while the keys are being decrypted.

In a further possible implementation form of the first aspect the second KDF is identical to the first KDF, which simplifies the key derivation step.

In a further possible implementation form of the first aspect the SSK is a distinct symmetric key; wherein the KSK is an asymmetric key pair comprising a private key and a public key derived from the SSK by the KMS using a second key pair derivation function, KPDF, with the ACP as optional input parameter, the second KPDF being configured to obtain an asymmetric key pair from a symmetric key; wherein the concatenation in the key blob is signed with a private key of the KSK, KSK_priv, using an asymmetric signing algorithm; and wherein decrypting the C by the KMS comprises, before decrypting the C with the KEK, deriving a public key of the KSK, KSK_pub, from the SSK using the second KPDF and the ACP as input parameter; and verifying the signature in the key blob against the concatenation with the KSK_pub using the asymmetric signing algorithm.

In the alternative where ACP is involved as input parameter in deriving the KSK, the method provides the advantages of ensuring that ACP queries and enforcement can be made much faster compared to prior art, where key decryption needs to be performed before policies are available. The method also brings improvements in security. First, it is more secure against attacks that attempt to gain access to the AKs by modifying ACPs or switching the policy for one key for another. Secondly, it is also more secure against attacks that attempt to degrade the performance of the KMS by sending many invalid requests that would force the KMS to perform decryptions in order to ACPs. In addition, by avoiding unnecessary decryptions, it is also more secure against side-channel attacks that attempt to learn information about the keys simply by observing the behavior of the KMS, such as timing and power consumption, while the keys are being decrypted.

In the alternative where ACP is not involved and the public key of the KSK is made always available in REE, the method provides the advantages of making it possible to verify the integrity of the stored data (i.e., ACP and encrypted AK) using the public key of SSK (KSK), which does not have to be kept secret and can be made available in REE. In this way, any ACP modification can be checked when needed without a round-trip to the TEE.

In a further possible implementation form of the first aspect the second KPDF is identical to the first KPDF which simplifies the key pair derivation step.

In a further possible implementation form of the first aspect the SSK is an asymmetric key pair comprising a private key and a public key which are used by the KMS as a public key of the KSK, KSK_pub, and a private key of the KSK, KSK_priv, respectively; wherein the concatenation in the key blob is signed with the KSK_priv using an asymmetric signing algorithm; and wherein decrypting the C by the KMS comprises, before decrypting the C with the KEK, verifying the signature in the key blob against the concatenation with the KSK_pub using the asymmetric signing algorithm.

For asymmetric signatures, the private key is used for signing, and the public key is used for verification. The public keys often do not need to be kept secret. Furthermore, no key derivation steps are involved in this exemplary embodiment, as compared with the previous two exemplary embodiments.

In addition, since the stored data is signed using an asymmetric digital signature algorithm, it is possible to verify the integrity of the stored data (i.e., ACP and encrypted AK) using the public key of SSK, which does not have to be kept secret and can be made available in REE. In this way, it can checked if ACP has been modified when needed without a round-trip to the TEE. Furthermore, since integrity check can also be done in REE 5, the result of the policy queries and enforcements can be made more trustworthy, since it would be detected early in REE 5 if policies are tampered with.

EMBODIMENT 2

In a further possible implementation form of the first aspect the method further comprises providing on the computer at least one Storage Encryption Key, SEK, and at least one Storage Signing Key, SSK, each of the SEK and SSK being distinct symmetric keys configured to be accessible exclusively by the KMS; wherein the C in the key blob is encrypted with a key encryption key, KEK, using a symmetric encryption algorithm, the KEK being a symmetric key derived from the SEK using a first key derivation function, KDF, with the ACP as input parameter; wherein the C in the key blob is concatenated with the ACP, and the resulting concatenation is signed with a key signing key, KSK, using a symmetric signing algorithm to obtain a signature, T, to be included in the key blob as a tuple, the KSK being the same symmetric key as the SSK or a symmetric key derived from the SSK using a second key derivation function, KDF; and wherein decrypting the C by the KMS comprises obtaining a KSK from the SSK using the second KDF or using the SSK as KSK; verifying the signature in the key blob against the concatenation with the KSK using the symmetric signing algorithm; deriving a KEK from the SEK using the first KDF and the ACP as input parameter; and decrypting the C with the KEK using the symmetric encryption algorithm to obtain the AK.

This method ensures that ACP queries and enforcement can be made much faster compared to prior art, where key decryption needs to be performed before policies are available. The method also brings improvements in security by being more secure against attacks that attempt to gain access to the AKs by modifying ACPs or switching the policy for one key for another. Secondly, it is also more secure against attacks that attempt to degrade the performance of the KMS by sending many invalid requests that would force the KMS to perform decryptions in order to ACPs. In addition, by avoiding unnecessary decryptions, it is also more secure against side-channel attacks that attempt to learn information about the keys simply by observing the behavior of the KMS, such as timing and power consumption, while the keys are being decrypted.

EMBODIMENT S

In a further possible implementation form of the first aspect both the KEK and the KSK are distinct are asymmetric key pairs comprising a private key and a public key, each of the private keys configured to be accessible exclusively by the KMS within a Trusted Execution Environment, TEE, and each of the public keys configured to be accessible outside the TEE; wherein the C in the key blob is encrypted with a public key of the KEK, KEK_pub, using an asymmetric encryption algorithm; wherein the concatenation in the key blob is signed with a private key of the KSK, KSK_priv, using an asymmetric signing algorithm; and wherein decrypting the C by the KMS comprises verifying the signature in the key blob against the concatenation with a public key of the KSK, KSK_pub, using the asymmetric signing algorithm; and decrypting the C with a private key of the KEK, KEK_priv, using the asymmetric encryption algorithm to obtain the AK. Using this method, the stored data is signed using an asymmetric digital signature algorithm, which makes it possible to verify the integrity of the stored data (i.e., ACP and encrypted AK) using the public key of SSK, which does not have to be kept secret and can be made available in REE. In this way, any ACP checks for modifications can be done when needed without a round-trip to the TEE. In addition, since integrity check can also be done in REE, the result of the policy queries and enforcements can be made more trustworthy, since it would be detected early in REE if policies are tampered with.

EMBODIMENT 4

In a further possible implementation form of the first aspect the method further comprises providing on the computer at least one Storage Encryption Key, SEK, and at least one Storage Signing Key, SSK, each of the SEK and SSK being distinct symmetric keys configured to be accessible exclusively by the KMS; wherein both the public key of the KEK, KEK_pub, and the private key of the KEK, KEK_priv, is derived from the SEK using a first Key Pair Derivation Function, KPDF, with the ACP as input parameter, the first KPDF being configured to obtain an asymmetric key pair from a symmetric key; and wherein both the public key of the KSK, KSK_pub, and the private key of the KSK, KSK_priv, is derived from the SSK using a second Key Pair Derivation Function, KPDF, with the ACP as optional input parameter.

In the alternative where ACP is involved as input parameter in deriving the KSK, the method provides the advantages of ensuring that ACP queries and enforcement can be made much faster compared to prior art, where key decryption needs to be performed before policies are available. The method also brings improvements in security. First, it is more secure against attacks that attempt to gain access to the AKs by modifying ACPs or switching the policy for one key for another. Secondly, it is also more secure against attacks that attempt to degrade the performance of the KMS by sending many invalid requests that would force the KMS to perform decryptions in order to ACPs. In addition, by avoiding unnecessary decryptions, it is also more secure against side-channel attacks that attempt to learn information about the keys simply by observing the behavior of the KMS, such as timing and power consumption, while the keys are being decrypted.

In the alternative where ACP is not involved and the public key of the KSK is made always available in REE, the method provides the advantages of making it possible to verify the integrity of the stored data (i.e., ACP and encrypted AK) using the public key of SSK (KSK), which does not have to be kept secret and can be made available in REE. In this way, any ACP modification can be checked when needed without a round-trip to the TEE. In a further possible implementation form of the first aspect the private key of the KSK, KSK_priv, is configured to be accessible exclusively by the KMS within a Trusted Execution Environment, TEE; and the public key of the KSK, KSK_pub, is configured to be accessible outside the TEE, such as by applications running in a Rich Execution Environment, REE. As a result, the code that needs to be run in the TEE can be minimized, and the number of calls from the REE to the code in TEE can also be reduced.

In a further possible implementation form of the first aspect the private key of the KEK, KEK_priv, is configured to be accessible exclusively by the KMS within a Trusted Execution Environment, TEE; and the public key of the KEK, KEK_pub, is configured to be accessible outside the TEE, such as by applications running in a Rich Execution Environment, REE. As a result, the code that needs to be run in the TEE can be minimized, and the number of calls from the REE to the code in TEE can also be reduced.

In a further possible implementation form of the first aspect the request refers to cryptographically processing application data; the request comprises application data to be processed; performing the requested cryptographic operation by the KMS using the obtained AK comprises cryptographically processing the application data by the KMS using the AK; and the method further comprises transmitting the processed application data by the KMS to the application. The method makes it possible to cryptographically process application data, while providing advantages for data encryption and decryption.

In a further possible implementation form of the first aspect the request refers to modifying rules of accessing an AK; and the method further comprises the steps performed by the KMS: verifying, based on the ACP in the retrieved key blob, that rules of accessing the AK are allowed to be modified; and constructing a modified ACP based on the request; and the performing the requested cryptographic operation by the KMS using the obtained AK comprises encrypting the AK using the modified ACP as input parameter to generate a new ciphertext, C2; generating a modified key blob comprising the new ciphertext, C2, and the modified ACP; and replacing the retrieved key blob with the modified key blob in the storage medium. The method makes it possible to modify ACPs of an AK, while providing advantages for data encryption and decryption.

In a further possible implementation form of the first aspect the request refers to deleting an AK; and the method further comprises the steps performed by the KMS: verifying, based on the ACP in the retrieved key blob, that the requesting application is allowed to delete the AK; and performing the requested cryptographic operation by the KMS using the obtained AK comprises, in case the decryption of C using the ACP is successful, removing the retrieved key blob from the storage medium and clearing any decrypted content from any temporary storage medium. The method makes it possible to remove an AK from storage as well as any temporary storage, while providing advantages for data encryption and decryption.

According to a second aspect, there is provided a method of secure key handling and cryptographic processing of data implemented on a computer, the method comprising receiving a request by a Key Management System, KMS, from an application, the request comprising a query on at least one application key, AK, and any corresponding rules of access defined in a respective Access Control Policy, ACP, of each AK; and the method further comprising the steps performed by the KMS: retrieving a key blob from a storage medium by the KMS, the key blob comprising a ciphertext, C, corresponding to the at least one AK and a respective ACP; extracting the ACP from the retrieved key blob; and performing the requested query on the extracted ACP. This method enables to perform ACP queries, while providing advantages regarding data encryption and decryption, in particular that ACPs for keys can be queried without decrypting the key materials. This allows, for example, applications to quickly find the right key to use under a certain scenario without a round trip to the TEE for decryption, hence achieving better performance.

According to a third aspect, there is provided a computer-based system for secure key handling and cryptographic processing of data, the system comprising a Trusted Execution Environment, TEE; a Rich Execution Environment, REE; an application configured to be executed in the REE; a storage medium configured to store at least one key blob, each key blob comprising a ciphertext, C, and corresponding Access Control Policies, ACP; a Key Management System, KMS, configured to receive, from the application, a request to perform a cryptographic operation, the request comprising a reference to an application key, AK, and context information; and the KMS is configured to, in response to the request, retrieve a key blob from the storage medium corresponding to the AK; validate the ACP in the retrieved key blob based on the context information; decrypt the C using the validated ACP as input to obtain the AK; and perform the requested cryptographic operation using the generated AK according to the method of any one of the possible implementation forms of the first aspect or the second aspect.

By providing such a computer-based system configured to encrypt and then decrypt data it becomes possible to ensure that the ACP for a key cannot be modified outside of the KMS. It is further ensured that the key cannot be replaced by that of another key without rendering the key unusable. A third advantage is that ACP queries and enforcement can be done using this method without decrypting the keys.

In other words, the system enables to protect AKs and their ACPs in a KMS that is more efficient and secure compared with prior art. With the method, the particular advantages over the prior art are described as follows. ACPs are integrity protected but not encrypted in storage. ACPs are checked and enforced before decrypting the key materials. The ACP for a key is used as a parameter when decrypting the key materials so that keys cannot be decrypted without presenting the unmodified ACP. ACPs for keys can be queried using the system without decrypting the key materials. This allows, for example, applications to quickly find the right key to use under a certain scenario without a round trip to the TEE for decryption, hence achieving better performance.

Hence, the system enables to enforce strong binding between key materials in a KMS and their ACP, allowing better performance and security at the same time, without any extra cost for maintaining a central policy database.

Security benefits of the system include reduced risks of policy tampering or by-passing (policies are cryptographically bound to keys), and reduced risks of Denial-of-Service or side- channel attacks (less round-trips to TEE). As a further advantage, the code that needs to be run in the TEE can be minimized, and the number of calls from the REE to the code in TEE can also be reduced.

In a possible implementation form of the third aspect the KMS is configured to receive, from the application, a request referring to cryptographically processing application data; the request comprises application data to be processed; and the KMS is further configured to cryptographically process the application data by the KMS using the AK; and transmit the processed application data to the application. The system makes it possible to cryptographically process application data, while providing advantages for data encryption and decryption.

In a further possible implementation form of the third aspect the KMS is configured to receive, from the application, a request referring to modifying rules of accessing an AK; and the KMS is further configured to verify, based on the ACP in the retrieved key blob, that rules of accessing the AK are allowed to be modified; construct a modified ACP based on the request; encrypt the AK using the modified ACP as input parameter to generate a new ciphertext, C2; generate a modified key blob comprising the new ciphertext, C2, and the modified ACP; and replace the retrieved key blob with the modified key blob in the storage medium. The system makes it possible to modify ACPs of an AK, while providing advantages for data encryption and decryption.

In a further possible implementation form of the third aspect, the system further comprises a temporary storage medium; wherein the KMS is configured to receive, from the application, a request referring to deleting an AK; and wherein the KMS is further configured to verify, based on the ACP in the retrieved key blob, that the requesting application is allowed to delete the AK; and, in case the decryption of C using the ACP is successful, remove the retrieved key blob from the storage medium and clear any decrypted content from the temporary storage medium, such as a memory. This configuration makes it possible to remove an AK from storage as well as any temporary storage, while providing advantages for data encryption and decryption.

According to a fourth aspect, there is provided a computer-based system for secure key handling and cryptographic processing of data, the system comprising a Trusted Execution Environment, TEE; a Rich Execution Environment, REE; an application configured to be executed in the REE; a storage medium configured to be accessible by the KMS and to store at least one key blob, each key blob comprising a ciphertext, C, and corresponding Access Control Policies, ACP; and a Key Management System, KMS, configured to receive, from the application, a request comprising a query on at least one application key, AK, and any corresponding rules of access defined in a respective ACP of each AK; and in response to the request retrieve a key blob from the storage medium, the key blob comprising a C corresponding to the at least one AK and a respective ACP; extract the ACP from the retrieved key blob; and perform the requested query on the extracted ACP.

This system enables to perform ACP queries, while providing further advantages regarding data encryption and decryption, in particular that ACPs for keys can be queried without decrypting the key materials. This allows, for example, applications to quickly find the right key to use under a certain scenario without a round trip to the TEE for decryption, hence achieving better performance.

These and other aspects will be apparent from and the embodiment(s) described below.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following detailed portion of the present disclosure, the aspects, embodiments and implementations will be explained in more detail with reference to the example embodiments shown in the drawings, in which:

Fig. 1A shows a schematic illustration of a combined encryption method according to an example of the prior art;

Fig. 1 B shows a schematic illustration of an encryption method using a Central Policy Database according to another example of the prior art; Fig. 2 shows a flow diagram of a typical key access method according to another example of the prior art;

Fig. 3 shows a flow diagram of a method of secure key handling and cryptographic processing of data according to an example of the first aspect of the disclosure;

Fig. 4 shows a block diagram of a computer-based system for secure key handling and cryptographic processing of data according to an example of the third and fourth aspects of the disclosure;

Fig. 5 shows a flow diagram of encrypting an application key according to an example of the first aspect of the disclosure;

Fig. 6 shows a flow diagram of decrypting an application key according to an example of the first aspect of the disclosure;

Fig. 7 shows a flow diagram of encrypting an application key according to another example of the first aspect of the disclosure;

Fig. 8 shows a flow diagram of decrypting an application key according to another example of the first aspect of the disclosure;

Fig. 9 shows a flow diagram of deriving and using a key encryption key according to an example of the first aspect of the disclosure;

Fig. 10 shows a flow diagram of deriving and using a key signing key according to an example of the first aspect of the disclosure;

Figs. 11 A and 11 B show flow diagrams of deriving asymmetric key pairs of a key encryption key and a key signing key from symmetric keys, according to further examples of the first aspect of the disclosure;

Figs. 12A and 12B show flow diagrams of deriving asymmetric key pairs of a key encryption key and a key signing key from asymmetric key pairs according to a further example of the first aspect of the disclosure;

Fig. 13 shows a flow diagram summarizing possible flows of encryption and decryption of an application key, according to examples of the first aspect of the disclosure;

Fig. 14 shows a flow diagram of processing application data according to an example of the first aspect of the disclosure, on a computer-based system according to an example of the third aspect of the disclosure; Fig. 15 shows a flow diagram of deleting an application key according to an example of the first aspect of the disclosure, on a computer-based system according to an example of the third aspect of the disclosure;

Fig. 16 shows a flow diagram of modifying Access Control Policies of an application key according to an example of the first aspect of the disclosure, on a computer-based system according to an example of the third aspect of the disclosure;

Fig. 17 shows a flow diagram of handling queries on Access Control Policies according to a method of an example of the second aspect of the disclosure, on a computer-based system according to an example of the fourth aspect of the disclosure.

DETAILED DESCRIPTION

The object of the present disclosure is to provide a description of improved methods and systems to be used for application key (AK) and access control policy (ACP) protection within a Key Management System (KMS). Some implementation and other details are not disclosed explicitly, since the design and implementation of a full-fledged KMS is complicated and many details are out of the scope of this disclosure. For example, a KMS may utilize other security features provided by the local storage service such as roll-back prevention, volume/disk encryption, database encryption, and so on. These features should be used to compliment the method described here, and not as a replacement.

It is to be noted that a KMS can also be used to protect other user secrets such as credit card numbers and passwords. These use cases are essentially not different from the case of cryptographic keys. Although the disclosed examples only concern protection of cryptographic keys, it is understood that the methods and systems disclosed can be easily applied to other types of secrets.

Figures 1A, 1B and 2 illustrate encryption methods according to the prior art.

In particular, Fig. 1A shows a schematic illustration of a combined encryption method according to the prior art, wherein the KMS puts the ACP for a key together with the key itself, and encrypts the result using a storage key. When this method is used, all key management operations on a specific key would affect both the key and its policy since they are encrypted together. Therefore, this prior art method is often used when the encryption of the key blob is not done by the KMS itself, but rather provided by the underlying operation system as a secure storage service. By separating the data encryption step, it may slightly reduce the complexity of the KMS.

Fig. 1 B shows a schematic illustration of an encryption method using a Central Policy Database according to another example of the prior art, wherein all the access policies for all the keys managed by the KMS are stored in a central location, which could be a relational database, a file, a directory or even rules that are hardcoded into the software, which can all be defined as a Central Policy Database (CPD).

Fig. 2 shows a flow diagram of a typical key access method according to another example of the prior art, wherein traces of both previously described methods can be found, i.e. part of the ACP of a key may be stored and encrypted together with the key itself, and other parts may be found in a central policy database. Rules, such as that applications can only access the keys they generate by default, are often hardcoded into the software logic. Fig. 2 illustrates the steps to be taken to perform a cryptographic operation when a hybrid method is used. In particular, the decryption of the key blob and the query, and enforcement of the policies are independent steps, which results in security risks.

Fig. 3 illustrates the core steps of a method of secure key handling according to an example of the disclosure, implemented on a computer-based system, such as the system 100 illustrated in Fig. 4. In each of the embodiments of this invention, A computer may be a stationary computer (stationary device), e.g. a workstation or desktop computer, or a portable computer (mobile device), e.g. laptop, tablet, smartphone, mobile phone etc. The terms “portable” and “mobile” may be used as synonyms. The computer-based system may be a single computer, combination of computers, or combination of computer and other kind of device. A computer includes a processor and storage medium storing instructions that can be read and executed by the processor to control the computer-based system to perform the functions/steps described in the embodiments of the present invention.

It is to be noted that the disclosed methods hereinbelow consist of three main phases or functions, namely, encryption, decryption and query. The actual cryptographic algorithms for key derivation, signatures and encryptions may be chosen according to the capabilities of the used computing device and other considerations. Detailed exemplary embodiments will be given below, where the actual methods to determine KEK 16 and KSK 17 are also discussed.

Accordingly, Fig. 3 illustrates the decryption of an encrypted application key 6 by the KMS 2 according to the present disclosure. In a first step 101 , the KMS 2 receives a request 20 from an application 1 to perform a cryptographic operation. The request 20 may comprise, amongst others, a reference 21 to an AK 6, and context information 22.

In a second step 102, the KMS 2 retrieves a key blob 7 from a storage medium 3. The key blob 7 comprises a ciphertext (C) 8 corresponding to the AK 6 and ACP 9 defining rules of accessing the AK 6.

In a third step 103, the KMS 2 validates the ACP 9 based on the context information 22.

If the validation succeeds, in a fourth step 104, the KMS 2 decrypts the C 8 by the using the validated ACP 9 as input to obtain the AK 6.

In a final step 105, the requested cryptographic operation is performed using the obtained AK 6.

Fig. 4 shows a block diagram illustrating main components of a computer-based system 100 for secure key handling and cryptographic processing of data according to an example of the disclosure. The computer-based system 100 may be a computing device, for example, a smart phone, a tablet, a smart TV, or any devices that allow applications to run on.

The system further comprises a Trusted Execution Environment (TEE) 4; a Rich Execution Environment (REE) 5; an application 1 configured to be executed in the REE 5; a storage medium 3 configured to be accessible in the REE 5; and Key Management System (KMS) 2, configured to receive requests to perform cryptographic operations from the application 1 and, in response to the request, access the storage medium 3 to retrieve key blobs 7.

The application 1 is a software component hosted on the computing device and may be provided by the device vendor or by a third party.

The KMS 2 is a sub-system hosted on the computing device to provide key management services to applications 1. It may include a combination of various software and hardware sub components in the device.

The most critical component of the software of a KMS 2, sometimes referred to as a Trusted Application, runs in the TEE 4 only, so that this piece of software is more trustworthy and is protected by the TEE from malicious or accidental modifications. The TEE 4 also provides a Storage Key (SK) 13 that is only accessible by the Trusted Application of the KMS 2. In particular, Storage Keys 13 are cryptographic keys provided by the computing device to the KMS 2 exclusively. Only the KMS 2 on the same computing device can access these keys. These keys can be stored in a secure memory area so that the KMS 2 can access them directly, or may be provided by the underlying operating system via an API.

Thirdly, the TEE 4 may provide cryptographic accelerators 27 that allow the KMS 2 to perform cryptographic operations in more secure and efficient ways. The cryptographic accelerators 27 are hardware components that perform cryptographic operations in an efficient way. These accelerators 27 may be used by the KMS 2.

This system 100 ensures the protection of the key material so that it is not directly accessible from the REE 5, and that the access to the keys can be controlled through rules for accessing the keys defined in the ACP 9. Part of the ACP 9 for a key can be specified by the application 1 who owns the key, and part may be specified by the operating system or the TEE 4. Part, if not all, of the ACP 9 are enforced in TEE 4, to minimize the attack surfaces of the KMS 2.

The TEE 4 of a device is typically much slower and computationally less capable compared to the REE 5 and switching between REE 5 and TEE 4 takes time. Furthermore, more code could mean more bugs and vulnerabilities. As a result, the present disclosure aims is to minimize the code that needs to be run in the TEE 4, and to minimize the number of calls from the REE 5 to the code in TEE 4.

Fig. 5 illustrates the core “encrypt-then-sign” idea behind the disclosed methods of the present disclosure, wherein the AK 6 shall be encrypted first by a Key Encryption Key (KEK) 16 using an encryption algorithm to obtain a ciphertext (C) 8.

The KEK 16 can be derived from a Storage Encryption Key (SEK) 14 using the ACP 9 of the AK 6. The encrypted data, i.e. ciphertext (C) 8 is then concatenated with a binary representation of the ACP 9, and we denote the resulting concatenation 10 ACP || C, where the double vertical bars represent binary concatenation. 5. The resulting concatenation 10 is signed by a Key Signing Key (KSK) 17 using a signing algorithm to get a digital signature 11:

T = Sign(ACP || C, KSK)

The KSK 17 may be derived from a Storage Signing Key (SSK) 15 using the ACP 9 of the AK 6. The SEK 14 and SSK 15 may be the same when it is a symmetric key, or can be derived from a Storage Key (SK) 13. The output of the encryption phase is a tuple 12 (ACP, C, T). In practice, a KMS 2 should encode and store all the data in the tuple 12 at the same location, such as in the same file in a file system, or in the same record of a database table. Each of the SEK 14 and SSK 15 may be configured to be accessible exclusively by the KMS 2.

Fig. 6 shows a flow diagram of decrypting a C 8 according to an example of the disclosure. The inputs to the decryption phase comprise the following: an encrypted key (C) 8, an ACP 9, a digital signature 11, a storage encryption key SEK 14 and a storage signing key SSK 15. The SEK 14 and SSK 15 may be the same when it is a symmetric key, or can be derived from a Storage Key (SK) 13. The following steps are followed.

First, a KEK 16 is determined from SEK 14 using the ACP 9 of the AK 6. Then, the digital signature 11 is verified against the concatenation 10 ACP || C, using the key KSK 17 determined from SSK 15 and ACP 9. The encrypted key (C) 8 is decrypted using KEK 16 to obtain AK 6.

In practice, a KMS 2 should retrieve the tuple 12 (ACP, C, T) from the same storage location as used in the encryption phase and supply it to the decryption phase as inputs. The cryptographic algorithms used should match those in the encryption phase.

EMBODIMENT 1

Fig. 7 shows a flow diagram of encrypting an application key according to an example of the disclosure. In this exemplary embodiment, the SEK 14 and the SSK 15 are the same symmetric key, namely the Storage Key (SK) 13, configured to be accessible exclusively by the KMS 2.

For encrypting the C 8 in the key blob 7, in this example an Authenticated Encryption with Associated Data (AEAD) encryption algorithm is used such that the KEK 16 is derived from SK 13 and ACP 9, using a key derivation function (KDF) 18, such as HKDF. Commonly seen examples of AEAD encryption algorithms include AES-GCM, AES-CCM, Chacha20-Poly1305, and so on.

The AK 6 is encrypted by KEK 16 with the AEAD algorithm, where the ACP 9 is also used as the AAD (Authenticated Associated Data) for the AEAD encryption algorithm. The result is a tuple:

(C, Ta) = Enc_AEAD(AK, ACP, KEK), where C denotes the ciphertext 8 as the result of encryption, and Ta 11A as the authentication tag that is used to protect the integrity of the data.

The output of the encryption phase is a tuple 12 (ACP, C, T), where the ACP 9 is the AAD, and Ta 11A as the authentication tag is used as the signature T 11 in the key blob 7.

The AEAD encrypted blob generated as the result of the encryption phase should be stored by the KMS 2 at the same location as a single piece of data.

Although it is possible to have an asymmetric key pair as the SK 13 to compute both encryption and digital signature, it is generally regarded as an insecure practice in the field of cryptography and information security. Hence, we do not consider this option in this disclosure.

Fig. 8 illustrates the decryption phase of the previous exemplary embodiment, wherein first a KEK 16 is derived from SK 13 and ACP 9 using the same KDF 18 as in the encryption phase. The ciphertext C 8 decrypted with KEK 16 using the same AEAD algorithm used as in the encryption phase, where ACP 9 is used as the AAD. The result is either a key AK 6, wherein

AK = Dec_AEAD(C, T, ACP, KEK), or an error that indicates a failure.

The output of the decryption phase therefore is the application key AK 6.

EMBODIMENT 2

Figs. 9 and 10 illustrated different steps of key derivation for encryption and decryption of an AK 6 according to another example of the disclosure.

In this exemplary embodiment, the SEK 14 and the SSK 15 are distinct symmetric keys, where the SEK 14 supports a symmetric encryption algorithm such as AES, and the SSK 15 supports a symmetric signing algorithm such as HMAC.

For key encryption, as illustrated in Fig. 9, a key encryption key (KEK) 16 is derived from SEK 14 and ACP 9 using a first key derivation function (KDF) 181, such as HKDF. The AK 6 is encrypted by KEK 16 with a symmetric encryption algorithm, such as AES, to obtain ciphertext C 8.

As illustrated in Fig. 10, the concatenation 10 (ACP || C) is then signed using a symmetric signing algorithm, such as HMAC, with KSK 17 to obtain a signature T. The KSK 17 may be derived from SSK 15 and ACP 9 using a second key derivation function (KDF) 182, which may or may not be the same as the one first key derivation function (KDF) 181 used to derive KEK 16. If this step is omitted, SSK 15 may be used directly as KSK 17. The output of the encryption phase is a tuple (ACP, C, T).

Figs. 9-10 further illustrate the decryption phase according to the above example of the disclosure. As before, a KSK 17 is derived from SSK 15 and ACP 9 using the second KDF 182 (same as in the encryption phase). If KSK 17 derivation step was omitted during encryption, SSK 15 is directly used as KSK 17. Next, the signature T 11 of the tuple 12 is verified against the concatenation 10 (ACP || C) using the same symmetric signing algorithm used during the encryption phase. A KEK 16 is derived from SEK 14 and ACP 9 using the same first KDF 181 as in the encryption phase. The ciphertext C 8 is then decrypted with KEK 16 using the same symmetric encryption algorithm used as in the encryption phase to obtain AK 6, or an error that indicates a failure. The output of the decryption phase is the application key AK 6.

In the above exemplary embodiments, the SEK 14 and the SSK 15 are distinct symmetric keys, where the SEK 14 supports a symmetric encryption algorithm, and the SSK 15 supports a symmetric signing algorithm. As described, a symmetric key KEK 16 can be derived from SEK 14, and a symmetric key KSK 17 can be derived from SSK 15. However, in further exemplary embodiments, both the SEK, and SSK, as well as the KEK and KSK may be asymmetric key pairs.

EMBODIMENT 4

Figs. 11A and 11 B show flow diagrams of deriving asymmetric key pairs of a KEK 16 and a KSK 17 from distinct symmetric keys of a SEK 14 and SSK 15 respectively, according to further examples of the disclosure, using key pair derivation functions. In this exemplary embodiment, the KEK 16 and the KSK 17 are distinct asymmetric key pairs. For example, the KEK/KSK can be an RSA key pair, an Elliptic Curve (EC) key pair or Digital Signature Algorithm (DSA) key pair. The two keys do not have to be the same type. The storage keys SEK 14 and SSK 15 are symmetric keys where KEK 16 and KSK 17 are obtained by applying special key derivation algorithms that allows to derive an asymmetric key pair from a symmetric key (first a private key, then a public key computed from the private key). We refer to such key derivation algorithms Key Pair Derivation Functions (KPDF) to differentiate from those mentioned in the previous exemplary embodiments. The actual design of KPDF is out of the scope of this disclosure, and it depends on the type of the asymmetric encryption and digital signature algorithms to be used. For encryption, a key pair comprising a public key of KEK 16, KEK_pub 161, and a private key of the KEK 16, KEK_priv 162 is derived from SEK 14 and ACP 9 using a first KPDF 191 , as illustrated in Fig. 11A.

A key pair comprising a public key of the KSK 17, KSK_pub 171, and a private key of the KSK 17, KSK_priv 172 is derived from SSK 15, and optionally also using ACP 9 as input, using a second KPDF 192 as illustrated in Fig. 11 B. The second KPDF 192 may or may not be the same as the first KPDF 191 used in the previous step. If ACP 9 is not involved, the key pair of KSK 17 will remain the same for all the keys.

Fig. 13 (upper half, left to right) illustrates the encryption phase of this exemplary embodiment, wherein the AK 6 is encrypted by the public key of KEK 16, KEK_pub 161 with an asymmetric encryption algorithm supported by SEK 14 to obtain a ciphertext C 8. The concatenation 10 (ACP || C) is then signed using an asymmetric signing algorithm with the private key of KSK, KSK_priv 172, to obtain a signature T 11. The output of the encryption phase is a tuple 12 (ACP, C, T).

For decryption, as also illustrated in Fig. 13 (upper half, right to left), first a key pair comprising a public key of the KSK 17, KSK_pub 171 , and a private key of the KSK 17, KSK_priv 172 is derived from SSK 15, and optionally also using ACP 9 as input, using a second KPDF 192 as illustrated in Fig. 11 B. The second KPDF 192 may or may not be the same as the one used in previous step. If ACP 9 is not involved, the key pair of KSK 17 will remain the same for all the keys. The signature T 11 of the tuple 12 can then be verified against the concatenation 10 (ACP || C) with the public key of KSK 17, KSK_pub 171 , using the same asymmetric signing algorithm used during the encryption phase.

Next, a key pair comprising a public key of KEK 16, KEK_pub 161 , and a private key of the KEK 16, KEK_priv 162 is derived from SEK 14 and ACP 9 using a first KPDF 191 , as illustrated in Fig. 11A. The ciphertext C 8 is then decrypted with the private key of KEK 16, KEK_priv 162, using the same asymmetric encryption algorithm used as in the encryption phase, to obtain AK 6, or an error that indicates a failure. The output of the decryption phase is the application key AK 6.

EMBODIMENT S

Figs. 12A and 12B show flow diagrams of determining asymmetric key pairs of a KEK 16 and a KSK 17 from asymmetric key pairs of a SEK 14 and SSK 15 respectively, according to a further example of the disclosure. In this exemplary embodiment, the SEK 14 and the SSK 15 are distinct asymmetric key pairs. For example, the SEK/SSK can be an RSA key pair, an Elliptic Curve (EC) key pair or Digital Signature Algorithm (DSA) key pair. The two keys do not have to be the same type.

In this case, the key encryption key (KEK) 16 is the same as SEK 15, and the key signing key (KSK) 17 is the same as SSK 15. In particular, the SEK 14 is an asymmetric key pair comprising a private key and a public key which are used by the KMS 2 as a public key of the KEK 16, KEK_pub 161 , and a private key of the KEK 16, KEK_priv 162, respectively. Similarly, the SSK 15 is an asymmetric key pair comprising a private key and a public key which are used by the KMS 2 as a public key of the KSK 17, KSK_pub 171, and a private key of the KSK 17, KSK_priv 172, respectively.

Fig. 13 (upper half, left to right) illustrates the encryption and decryption phase of this exemplary embodiment. For encryption, the AK 6 is encrypted by the public key of KEK 16, KEK_pub 161, with an asymmetric encryption algorithm supported by SEK 14 to obtain a ciphertext C 8. The concatenation 10 (ACP || C) is then signed using an asymmetric signing algorithm with the private key of KSK 17, KSK_priv 172, to obtain a signature T 11. The output of the encryption phase is a tuple 12 (ACP, C, T).

For decryption, as also illustrated in Fig. 13 (upper half, right to left) the signature T 11 of the tuple 12 is verified against the concatenation 10 (ACP || C) with the public key of KSK 17, KSK_pub 171 , using the same asymmetric signing algorithm used during the encryption phase. Next, the ciphertext C 8 is decrypted with the private key of KEK 16, KEK_priv 162, using the same asymmetric encryption algorithm used as in the encryption phase, to obtain AK 6, or an error that indicates a failure. The output of the decryption phase is the application key AK 6.

In other words, each key pair consists of a public key and a private key. For asymmetric encryption, the public key is used for encryption and the private key is used for decryption. For asymmetric signatures, the private key is used for signing, and the public key is used for verification. The public keys often do not need to be kept secret. Furthermore, no key derivation steps are involved in this exemplary embodiment, as compared with the previous two exemplary embodiments.

In addition, since the stored data is signed using an asymmetric digital signature algorithm, it is possible to verify the integrity of the stored data (i.e., ACP 9 and encrypted AK 6) using the public key of SSK 15, which is the same as the public key of KSK 17, KSK_pub 171 , which does not have to be kept secret and can be made available in the REE 5. In this way, it can be checked if ACP 9 has been modified when needed without a round-trip to the TEE 4. This cannot be done in the previous exemplary embodiments. Since integrity check can also be done in REE 5, the result of the policy queries and enforcements can be made more trustworthy, since it would be detected early in REE 5 if policies are tampered with.

The choice of the key types and parameters may depend on various factors, such as the hardware support for certain algorithms, regulatory and compliance requirements, algorithm limitations (some types of keys can only be used to compute digital signatures, for example), performance considerations and so on.

EMBODIMENTS 2-8

Fig. 13 shows a flow diagram summarizing possible flows of encryption and decryption of an AK 6, encompassing to the above-described examples of the disclosure and further possible alternatives, using either distinct symmetric keys or asymmetric key pairs for either or both of the encryption or decryption phases.

Summarizing the exemplary embodiments presented so far, the variations focus on the type of SEK 14 and SSK 15, whether they are symmetric or asymmetric, and how KEK 16 and KSK 17 can be obtained from them. In particular, the following combinations have been discussed:

Example 1: SEK 14 and SSK 15 are the same, and symmetric. KEK 16 and KSK 17 are symmetric keys derived using a KDF 18 (Figs. 7-8).

Example 2: SEK 14 and SSK 15 are different symmetric keys. KEK 16 and KSK 17 are symmetric keys derived using a first KDF 181 and a second KDF 182 (Figs. 9-10).

Example 3: SEK 14 and SSK 15 are different asymmetric key pairs, and are the same as KEK 16 and KSK 17 (Figs. 12A-12B).

Example 4: SEK and SSK are different symmetric keys. KEK and KSK are asymmetric key pairs derived using a KPDF (Figs. 11 A-11 B).

Following from the above, it can easily be seen that there are more variants as follows, without the need for detailed encryption and decryption phases, since they will be identical to some of the exemplary embodiments already described.

Example 5: SEK 14 is a symmetric key and SSK 15 is an asymmetric key pair. KEK 16 is a symmetric key derived using a first KDF 181 from SEK 14. KSK 17 is the same as SSK 15. Example 6: SEK 14 is a symmetric key and SSK 15 is an asymmetric key pair. KEK 16 is an asymmetric key pair derived using a first KPDF 191 from SEK 14. KSK 17 is the same as SSK 15.

Example 7: SEK 14 is an asymmetric key pair and SSK 15 is a symmetric key. KEK 16 is the same as SEK 14. KSK 17 is the same as SSK 15, or a symmetric key derived from SSK 15 with a second KDF 182.

Example 8: SEK 14 is an asymmetric key pair and SSK 15 is a symmetric key. KEK 16 is the same as SEK 14. KSK 17 is an asymmetric key pair derived from SSK 15 with a second KPDF 192.

Alternatively, these variants can be viewed as different methods to derive from a root key (SEK 14 or SSK 15) to a sub key (KEK 16 or KSK 17), which is summarized below.

In a further exemplary embodiment, as illustrated in Fig. 13, the private key of the KSK 17, KSK_priv 172, is configured to be accessible exclusively by the KMS 2 within a Trusted Execution Environment, TEE 4; and the public key of the KSK 17, KSK_pub 171, is configured to be accessible outside the TEE 4, such as by applications 1 running in a Rich Execution Environment, REE 5.

In a further exemplary embodiment, as illustrated in Fig. 13, the private key of the KEK 16, KEK_priv 162, is configured to be accessible exclusively by the KMS 2 within a Trusted Execution Environment, TEE 4; and the public key of the KEK 16, KEK_pub 161, is configured to be accessible outside the TEE 4, such as by application 1s running in a Rich Execution Environment, REE 5.

It is worth to note that KDF or KPDF is always applied to the SEK 14 whenever possible, with the ACP 9 as a diversifying parameter. This is to make sure that decryption would fail without supplying the right ACP 9. However, this requirement can be relaxed for the SSK 15, which is the reason for the optional ACP 9 parameter in the derivation steps mentioned in the embodiments. Having the same signing key is actually more efficient when verifying the signatures in the REE 5, since only one public key needs to be made available to REE 5.

The disclosed methods are further involved when keys and policies are generated, updated, queried, used and deleted. The details of these processes and how the disclosed method is used during these processes are given hereinbelow.

Key Generation

When an application 1 generates an AK 6 in a KMS 2, the KMS 2 needs to determine (a) the type of the AK 6 and the parameters of the key generation algorithm, and (b) the rules to access the Ak 6 to be generated, i.e. , the ACP 9 for the Ak 6. For example, the application 1 may specify that an RSA key pair is to be generated (key type), and the length of the key should be 2048 bits (generation parameters), and that the key can only be used to compute digital signatures with some specific padding algorithm (ACP 9). The KMS 2 can further enhance the ACP 9 to include other conditions for key access. For example, the KMS 2 may require that a key generated by an application 1 can only be used by that application 1 (the owner), unless explicit authorizations are given by the owner to allow other applications to use the key. After the AK 6 is generated, the encryption steps are followed as described before.

Key Usage

When an application 1 requests the KMS 2 to perform a cryptographic operation with a specific AK 6, the KMS 2 retrieves the key blob 7 that contains the encrypted AK 6 from the storage 3, extracts the ACP 9, and checks if the operation is allowed by the ACP 9. If it is indeed allowed, the KMS 2 would decrypt the AK 6 with the ACP 9 as one of the inputs using the decryption steps as described before, and use the decrypted AK 6 to perform the requested cryptographic operation. The result of the operation is then returned to the application. Such a typical operation flow is illustrated in Fig. 3.

Fig. 14 shows a flow diagram of such key usage for processing application data 23 according to an example of the disclosure, wherein a request 20 from an application 1 comprises application data 23 to be processed. In this example, performing the requested cryptographic operation by the KMS 2 using the obtained AK 6 comprises, in a first additional step 201 , cryptographically processing the application data 23 by the KMS 2 using the AK 6; in next additional step 202, transmitting the processed application data 23 by the KMS 2 to the application 1. Key Deletion

When an application 1 requests to delete an AK 6, the KMS 2 retrieves the key blob 7 that contains the encrypted AK 6 from the storage 3, extracts the ACP 9, and checks if the application 1 is authorized to delete the key 6. If it is allowed, the KMS 2 further decrypts the AK 6 using the decryption steps described before, with the ACP 9 in the key blob 7 as one of the inputs. If the decryption is successful, the entire tuple 12 is removed from the storage 3 and the decrypted content is cleared from the memory 3A. The extra decryption step is to confirm that the ACP 9 was not tampered with.

Fig. 15 shows a flow diagram of a method of deleting an application key 6 according to an example of the disclosure, wherein the request 20 from the application 1 refers to deleting 25 an AK 6 and wherein the method further comprises the following additional steps performed by the KMS 2:

In a first step 401 , verifying, based on the ACP 9 in the retrieved key blob 7, that the requesting application 1 is allowed to delete the AK 6.

In a next step 402, in case the decryption of C 8 using the ACP 9 is successful, removing the retrieved key blob 7 from the storage medium 3 and clearing any decrypted content from any temporary storage medium 3A.

Policy Update

The KMS may allow the ACP 9 for an AK 6 to be updated when, for example, a first application may authorize another second application to use a key owned by the first application. In this case, the KMS 2 first checks the existing ACP 9 for the AK 6 to make sure that policy update is actually allowed for the AK 6. After that, the KMS constructs a new ACP 9A, performs the decryption steps as described before with the existing ACP 9, and performs the encryption steps again with the new ACP 9A. The resulting tuple 7 A is then used to replace the existing tuple 7 in the storage 3.

Fig. 16 shows a flow diagram of such a policy update according to an example of the disclosure, wherein the request 20 from the application 1 refers to modifying rules 24 of accessing an AK 6; and wherein the method further comprises the following additional steps performed by the KMS 2:

In a first step 301 , verifying, based on the ACP 9 in the retrieved key blob 7, that rules of accessing the AK 6 are allowed to be modified.

In a next step 302, constructing a modified ACPm 9A based on the request 20. In a next step 303, encrypting the AK 6 using the modified ACPm 9A as input parameter to generate a new ciphertext (C2) 8A.

In a next step 304, generating a modified key blob 7 A comprising the new ciphertext (C2) 8A, and the modified ACPm 9A.

In a final step 305, the retrieved key blob 7 is replaced with the modified key blob 7 A in the storage medium 3.

Policy Query

The KMS 2 may allow an application 1 to perform queries on the keys and/or their policies. For example, an application 1 may want a list of all the keys that are accessible by it and can be used to compute digital signatures using Elliptic Curve Digital Signature Algorithm (ECDSA) and the SHA256 digest algorithm. To perform such a query, the KMS 2 would simply extract the ACP 9 part of all the tuples 12 in the storage 3 and perform the search among all the ACPs 9.

The inputs to this query phase comprise a query criteria and multiple tuples, each representing the result of an encryption phase applied on some AK and its ACP. To perform a query on the ACP with a given criteria, we simply need to decode each tuple to locate the ACP in it, and then perform the query with the decoded ACP. No cryptographic operation is involved in this phase. We will omit this phase in the description of the embodiments due to its simplicity.

Fig. 17 shows a flow diagram of handling such queries on ACPs 9 according to a method of an example of the disclosure, including the following steps:

In a first step 501 , receiving a request 20 by a KMS 2, from an application 1 , the request 20 comprising a query 26 on at least one AK 6, and any corresponding rules of access defined in a respective ACP 9, of each AK 6.

In a next step 502, retrieving a key blob 7 from a storage medium 3 by the KMS 2, the key blob 7 comprising a ciphertext (C) 8, corresponding to the at least one AK 6 and a respective ACP 9;

In a next step 503, extracting the ACP 9 from the retrieved key blob 7.

In a final step 504, performing the requested query 26 on the extracted ACP 9.

The various aspects and implementations has been described in conjunction with various embodiments herein. However, other variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed subject-matter, from a study of the drawings, the disclosure, and the appended claims. In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. A single processor or other unit may fulfill the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measured cannot be used to advantage. A computer program may be stored/distributed on a suitable medium, such as an optical storage medium or a solid-state medium supplied together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems. The reference signs used in the claims shall not be construed as limiting the scope.

Claims

1. A method of secure key handling and cryptographic processing of data implemented on a computer, the method comprising: receiving (101) a request (20) by a Key Management System, KMS (2), from an application (1) to perform a cryptographic operation, the request (20) comprising a reference (21) to an application key, AK (6), and context information (22); retrieving (102) a key blob (7) from a storage medium (3) by the KMS (2), the key blob (7) comprising a ciphertext, C (8), corresponding to the AK (6) and Access Control Policies, ACP (9), defining rules of accessing the AK (6); validating (103) the ACP (9) by the KMS (2) based on the context information (22); decrypting (104) the C (8) by the KMS (2) using the validated ACP (9) as input to obtain the AK (6); and performing (105) the requested cryptographic operation by the KMS (2) using the obtained AK (6).

2. A method according to claim 1 , wherein the C (8) in the key blob (7) is encrypted with a key encryption key, KEK (16), using an encryption algorithm, and wherein the decrypting the C (8) by the KMS (2) using the validated ACP (9) as input to obtain the AK (6) comprises: decrypting the C (8) by the KMS (2) with an encryption key using the encryption algorithm, the encryption key being the same symmetric key as the KEK (16) or a corresponding asymmetric key pair to the KEK (16) and configured to be accessible exclusively by the KMS (2) within a Trusted Execution Environment, TEE (4), to obtain the AK (6).

3. A method according to claim 2, wherein the C (8) in the key blob (7) is concatenated with the ACP (9), and the resulting concatenation (10) is signed with a key signing key, KSK (17), using a signing algorithm to obtain a signature (11), to be included in the key blob (7) as a tuple (12); and wherein the method further comprises: before decrypting the C (8), verifying the signature (11) in the key blob (7) by the KMS (2) against the concatenation (10) using the signing algorithm with a signing key, the signing key being the same symmetric key as the KSK (17) or a corresponding asymmetric key pair to the KSK.

4. A method according to claim 2, wherein the method further comprises providing on the computer at least one Storage Key, SK (13), configured to be accessible exclusively by the KMS (2); wherein the C (8) in the key blob (7) is encrypted using an Authenticated Encryption with Associated Data, AEAD, encryption algorithm with a KEK (16) derived from the ACP (9) and the SK (13), and with the ACP (9) further used as the respective Authenticated Associated Data, AAD; wherein the key blob (7) comprises an authentication tag (11A) generated by the AEAD encryption algorithm, wherein the authentication tag (11A) is used as a signature (11), in the key blob (7); and wherein decrypting the C (8) by the KMS (2) comprises: authenticating the AAD using the authentication tag (11A); deriving the KEK (16) from the ACP (9) and the SK (13) using a key derivation function, KDF (18); and using the AEAD encryption algorithm with the ACP (9) used as AAD and the KEK (16) as input for to obtaining the AK (6).

5. A method according to claim 3, wherein the method further comprises providing on the computer a Storage Encryption Key, SEK (14), and/or a Storage Signing Key, SSK (15), each of the SEK (14) and SSK (15) being configured to be accessible exclusively by the KMS (2); wherein the KEK (16) is obtained from the SEK (14) by the KMS (2), either by using the SEK

(14) as KEK (16), or by deriving the KEK (16) from the SEK (14) using the ACP (9) as input parameter; and wherein the KSK (17) is obtained from the SSK (15) by the KMS (2), either by using the SSK

(15) as KSK (17), or by deriving the KSK (17) from the SSK (15) using the ACP (9) as optional input parameter.

6. A method according to claim 5, wherein the SEK (14) is a distinct symmetric key; wherein the KEK (16) is a symmetric key derived from the SEK (14) by the KMS (2) using a first key derivation function, KDF (181), with the ACP (9) as input parameter; wherein the C (8) in the key blob (7) is encrypted with the KEK (16) using a symmetric encryption algorithm; and wherein the decrypting the C (8) by the KMS (2) comprises: deriving a KEK (16) from the SEK (14) using the first KDF (181) and the ACP (9) as input parameter; and decrypting the C (8) with the KEK (16) using the symmetric encryption algorithm to obtain the AK (6).

7. A method according to claim 5, wherein the SEK (14) is a distinct symmetric key; wherein the KEK (16) is an asymmetric key pair comprising a private key and a public key derived from the SEK (14) by the KMS (2) using a first key pair derivation function, KPDF (191), with the ACP (9) as input parameter, the first KPDF (191) being configured to obtain an asymmetric key pair from a symmetric key; wherein the C (8) in the key blob (7) is encrypted with a public key of the KEK (16), KEK_pub (161), using an asymmetric encryption algorithm; and wherein decrypting the C (8) by the KMS (2) comprises: deriving a private key of the KEK (16), KEK_priv (162), from the SEK (14) using the first KPDF (191) and the ACP (9) as input parameter; and decrypting the C (8) with the KEK_priv (162) using the asymmetric encryption algorithm to obtain the AK (6).

8. A method according to claim 5, wherein the SEK (14) is an asymmetric key pair comprising a private key and a public key which are used by the KMS (2) as a public key of the KEK (16), KEK_pub (161), and a private key of the KEK (16), KEK_priv (162), respectively; wherein the C (8) in the key blob (7) is encrypted with the KEK_pub (161) using an asymmetric encryption algorithm; and wherein decrypting the C (8) by the KMS (2) comprises: decrypting the C (8) with the KEK_priv (162) using the asymmetric encryption algorithm to obtain the AK (6).

9. A method according to any one of claims 6 to 8, wherein the SSK (15) is a distinct symmetric key; wherein the KSK (17) is a symmetric key obtained from the SSK (15) by the KMS (2), either by using the SSK (15) as KSK (17), or by deriving the KSK (17) from the SSK (15) using a second key derivation function, KDF (182), with the ACP (9) as input parameter; wherein the concatenation (10) in the key blob (7) is signed with the KSK (17) using a symmetric signing algorithm to obtain a signature (11) to be included in the key blob (7) as a tuple (12); and wherein decrypting the C (8) by the KMS (2) comprises, before decrypting the C (8) with the KEK: obtaining a KSK (17) from the SSK (15) using the second KDF (182) or using the SSK (15) as KSK; and verifying the signature (11) in the key blob (7) against the concatenation (10) with the KSK (17) using the symmetric signing algorithm.

10. A method according to any one of claims 6 to 8, wherein the SSK (15) is a distinct symmetric key; wherein the KSK (17) is an asymmetric key pair comprising a private key and a public key derived from the SSK (15) by the KMS (2) using a second key pair derivation function, KPDF (192), with the ACP (9) as input parameter, the second KPDF (192) being configured to obtain an asymmetric key pair from a symmetric key; wherein the concatenation (10) in the key blob (7) is signed with a private key of the KSK (17), KSK_priv (172), using an asymmetric signing algorithm; and wherein decrypting the C (8) by the KMS (2) comprises, before decrypting the C (8) with the KEK: deriving a public key of the KSK (17), KSK_pub (171), from the SSK (15) using the second KPDF (192) and the ACP (9) as input parameter; and verifying the signature (11) in the key blob (7) against the concatenation (10) with the KSK_pub (171) using the asymmetric signing algorithm.

11. A method according to any one of claims 6 to 8, wherein the SSK (15) is an asymmetric key pair comprising a private key and a public key which are used by the KMS (2) as a public key of the KSK (17), KSK_pub (171), and a private key of the KSK (17), KSK_priv (172), respectively; wherein the concatenation (10) in the key blob (7) is signed with the KSK_priv (172) using an asymmetric signing algorithm; and wherein decrypting the C (8) by the KMS (2) comprises, before decrypting the C (8) with the KEK: verifying the signature (11) in the key blob (7) against the concatenation (10) with the KSK_pub (171) using the asymmetric signing algorithm.

12. A method according to any one of claims 10 or 11 , wherein the private key of the KSK (17), KSK_priv (172), is configured to be accessible exclusively by the KMS (2) within a Trusted Execution Environment, TEE (4); and wherein the public key of the KSK (17), KSK_pub (171), is configured to be accessible outside the TEE (4), such as by applications (1) running in a Rich Execution Environment, REE (5).

13. A method according to any one of claims 7 or 8, wherein the private key of the KEK (16), KEK_priv (162), is configured to be accessible exclusively by the KMS (2) within a Trusted Execution Environment, TEE (4); and wherein the public key of the KEK (16), KEK_pub (161), is configured to be accessible outside the TEE (4), such as by applications (1) running in a Rich Execution Environment, REE (5).

14. A method according to any one of claims 1 to 13, wherein the request (20) refers to cryptographically processing application data (23); wherein the request (20) comprises application data (23) to be processed; wherein the performing the requested cryptographic operation by the KMS (2) using the obtained AK (6) comprises cryptographically processing (201) the application data (23) by the KMS (2) using the AK (6); and wherein the method further comprises: transmitting (202) the processed application data (23) by the KMS (2) to the application (1).

15. A method according to any one of claims 1 to 13, wherein the request (20) refers to modifying rules (24) of accessing an AK (6); wherein the method further comprises the steps performed by the KMS (2): verifying (301), based on the ACP (9) in the retrieved key blob (7), that rules of accessing the AK (6) are allowed to be modified; and constructing (302) a modified ACP (9A) based on the request (20); and wherein the performing the requested cryptographic operation by the KMS (2) using the obtained AK (6) comprises: encrypting (303) the AK (6) using the modified ACP (9A) as input parameter to generate a new ciphertext, C2 (8A); generating (304) a modified key blob (7A) comprising the new ciphertext, C2, and the modified ACP (9A); and replacing (305) the retrieved key blob (7) with the modified key blob (7A) in the storage medium (3).

16. A method according to any one of claims 1 to 13, wherein the request (20) refers to deleting (25) an AK (6); wherein the method further comprises the steps performed by the KMS (2): verifying (401), based on the ACP (9) in the retrieved key blob (7), that the requesting application (1) is allowed to delete the AK (6); and wherein the performing the requested cryptographic operation by the KMS (2) using the obtained AK (6) comprises: in case the decryption of C (8) using the ACP (9) is successful, removing (402) the retrieved key blob (7) from the storage medium (3) and clearing any decrypted content from any temporary storage medium (3A).

17. A method of secure key handling and cryptographic processing of data implemented on a computer, the method comprising: receiving (501) a request (20) by a Key Management System, KMS (2), from an application (1), the request (20) comprising a query (26) on at least one application key, AK (6), and any corresponding rules of access defined in a respective Access Control Policy, ACP (9), of each AK (6); and wherein the method further comprises the steps performed by the KMS (2): retrieving (502) a key blob (7) from a storage medium (3) by the KMS (2), the key blob (7) comprising a ciphertext, C (8), corresponding to the at least one AK (6) and a respective ACP (9); extracting (503) the ACP (9) from the retrieved key blob (7); and performing (504) the requested query (26) on the extracted ACP (9).

18. A computer-based system for secure key handling and cryptographic processing of data, the system comprising: a Trusted Execution Environment, TEE (4); a Rich Execution Environment, REE (5); an application (1) configured to be executed in the REE (5); a storage medium (3) configured to store at least one key blob (7), each key blob (7) comprising a ciphertext, C (8), and corresponding Access Control Policies, ACP (9); a Key Management System, KMS (2), configured to receive, from the application (1), a request (20) to perform a cryptographic operation, the request (20) comprising a reference (21) to an application key, AK (6), and context information (22); and wherein the KMS (2) is configured to, in response to the request: retrieve a key blob (7) from the storage medium (3) corresponding to the AK (6); validate the ACP (9) in the retrieved key blob (7) based on the context information (22); decrypt the C (8) using the validated ACP (9) as input to obtain the AK (6); and perform the requested cryptographic operation using the generated AK (6) according to the method of any one of claims 1 to 13.

19. A computer-based system according to claim 18, wherein the KMS (2) is configured to receive, from the application (1), a request (20) referring to cryptographically processing application data (23); wherein the request (20) comprises application data (23) to be processed; and wherein the KMS (2) is further configured to: cryptographically process the application data (23) by the KMS (2) using the AK (6); and transmit the processed application data (23) to the application (1).

20. A computer-based system according to any one of claims 18 or 19, wherein the KMS (2) is configured to receive, from the application (1), a request (20) referring to modifying rules (24) of accessing an AK (6); and wherein the KMS (2) is further configured to: verify, based on the ACP (9) in the retrieved key blob (7), that rules of accessing the AK (6) are allowed to be modified; construct a modified ACP (9) based on the request (20); encrypt the AK (6) using the modified ACP (9) as input parameter to generate a new ciphertext, C2; generate a modified key blob (7) comprising the new ciphertext, C2, and the modified ACP (9); and replace the retrieved key blob (7) with the modified key blob (7) in the storage medium (3).

21. A computer-based system according to any one of claims 18 to 20, the system further comprising a temporary storage medium (3); wherein the KMS (2) is configured to receive, from the application (1), a request (20) referring to deleting (25) an AK (6); and wherein the KMS (2) is further configured to: verify, based on the ACP (9) in the retrieved key blob (7), that the requesting application (1) is allowed to delete the AK (6); and in case the decryption of C (8) using the ACP (9) is successful, remove the retrieved key blob (7) from the storage medium (3); and clear any decrypted content from the temporary storage medium (3), such as a memory.

22. A computer-based system for secure key handling and cryptographic processing of data, the system comprising: a Trusted Execution Environment, TEE (4); a Rich Execution Environment, REE (5); an application (1) configured to be executed in the REE (5); a storage medium (3) configured to be accessible by the KMS (2) and to store at least one key blob (7), each key blob (7) comprising a ciphertext, C (8), and corresponding Access Control Policies, ACP (9); and a Key Management System, KMS (2), configured to: receive, from the application (1), a request (20) comprising a query (26) on at least one application key, AK (6), and any corresponding rules of access defined in a respective ACP (9) of each AK (6); and in response to the request: retrieve a key blob (7) from the storage medium (3), the key blob (7) comprising a C (8) corresponding to the at least one AK (6) and a respective ACP (9); extract the ACP (9) from the retrieved key blob (7); and perform the requested query (26) on the extracted ACP (9).