Authentication key-value data pair for protecting node-related data

Abstract

A computer-implemented method according to one embodiment includes encrypting a second symmetric key using a first symmetric key. Prior to encrypting the second symmetric key, the first symmetric key is securely loaded by the key management service into a hardware security module (HSM), and the cloud provider is only able to access encrypted bits of the first symmetric key. Key data of a key-value pair of the second symmetric key is used as additional authentication data (AAD) for encrypting the second symmetric key. The second symmetric key is used to encrypt value data of the key-value pair. The method also includes storing the encrypted second symmetric key, the AAD used in the encryption of the second symmetric key, and the tag bit created during the encryption of the second symmetric key for later use in verifying node-related data.

Description

Background Art

[0001] The present invention relates to data security, and more particularly, the present invention relates to authentication of data in storage systems and networks, including cloud-based storage systems and networks.

[0002] Cryptography is the science of writing secrets for the purpose of keeping data secret. Public and private keys are the basic concepts of public key cryptography, which is sometimes also called asymmetric cryptography. In public key cryptography, each public key is matched with only one private key. Together, they are used to encrypt and decrypt data. For example, a message encoded using a public key can only be decoded using the matching private key.

[0003] Data authenticity is primarily ensured by signing the document with a private key, so that any user of the data can verify the authenticity by using the corresponding public key. Summary of the invention

[0004] A computer-implemented method according to one embodiment includes encrypting a second symmetric key using a first symmetric key. Before encrypting the second symmetric key, the first symmetric key is securely loaded into a hardware security module (HSM) by a key management service, and the cloud provider can only access the encrypted bits of the first symmetric key. The key data of the key-value pair of the second symmetric key is used as additional authentication data (AAD) for encrypting the second symmetric key. The value data of the key-value pair is encrypted using the second symmetric key. The method also includes storing the encrypted second symmetric key, the AAD used in the encryption of the second symmetric key, and the tag bits created during the encryption of the second symmetric key for use thereafter in verifying node-related data.

[0005] According to another embodiment, a computer program product includes a computer-readable storage medium having program instructions embodied therewith. The program instructions can be read and / or executed by a computer to make the computer perform the aforementioned method.

[0006] According to another embodiment, a system includes a processor and logic integrated with the processor, executable by the processor, or integrated with the processor and executable by the processor. The logic is configured to execute the aforementioned method.

[0007] Other aspects and embodiments of the invention will become apparent from the following detailed description, which, when taken in conjunction with the accompanying drawings, illustrates, by way of example, the principles of the invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 is a diagram of a computing environment according to one embodiment of the present invention.

[0009] Figure 2 is a flow chart of a method according to one embodiment.

[0010] Figure 3 yes Figure 2 A flowchart of each sub-operation of the method operation.

[0011] Figures 4A-4H The progression of a client node registration process according to one embodiment is described.

[0012] Figures 5A-5F Described in accordance with one embodiment Figures 4A-4H Verification of nodes registered in the network. DETAILED DESCRIPTION

[0013] The following description is intended to illustrate the general principles of the invention and is not intended to limit the inventive concepts claimed herein.In addition, specific features described herein may be used in combination with other described features in each of the various possible combinations and permutations.

[0014] Unless expressly defined otherwise herein, all terms are to be given their broadest possible interpretations, including the meanings implied in the specification and as understood by those skilled in the art and / or defined in dictionaries, treatises, and the like.

[0015] It must also be noted that, as used in the specification and the appended claims, the singular forms "a", "an", and "the" include plural referents unless otherwise specified. It should also be understood that when used in this specification, the terms "comprises" and / or "comprising" specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or combinations thereof.

[0016] The following description discloses several preferred embodiments of authenticating and protecting key-value data pairs to protect node-related data that is subsequently verified using the key-value data pairs.

[0017] In a general embodiment, a computer-implemented method includes encrypting a second symmetric key using a first symmetric key. Before encrypting the second symmetric key, the first symmetric key is securely loaded into a hardware security module (HSM) by a key management service, and a cloud provider can only access the encrypted bits of the first symmetric key. Key data of a key-value pair of the second symmetric key is used as additional authentication data (AAD) for encrypting the second symmetric key. The value data of the key-value pair is encrypted using the second symmetric key. The method also includes storing the encrypted second symmetric key, the AAD used in the encryption of the second symmetric key, and the tag bits created during the encryption of the second symmetric key for subsequent use in verifying node-related data.

[0018] In another general embodiment, a computer program product includes a computer-readable storage medium having program instructions embodied therewith. The program instructions can be read and / or executed by a computer to enable the computer to perform the aforementioned method.

[0019] In another general embodiment, a system includes a processor and logic integrated with the processor, executable by the processor, or integrated with the processor and executable by the processor. The logic is configured to execute the aforementioned method.

[0020] Various aspects of the present disclosure are described by narrative text, flow charts, block diagrams of computer systems, and / or block diagrams of machine logic included in computer program product (CPP) embodiments. With respect to any flow chart, depending on the technology involved, the operations may be performed in an order different from the order shown in a given flow chart. For example, again depending on the technology involved, two operations shown in consecutive flow chart blocks may be performed in reverse order, as a single integrated step, simultaneously, or in a manner that at least partially overlaps in time.

[0021] Computer program product embodiments ("CPP embodiments" or "CPP") are terms used in this disclosure to describe any collection of one or more storage media (also referred to as "media") collectively included in a collection of one or more storage devices that collectively include machine-readable code corresponding to instructions and / or data for performing the computer operations specified in a given CPP claim. A "storage device" is any tangible device that can hold and store instructions for use by a computer processor. Without limitation, a computer-readable storage medium may be an electronic storage medium, a magnetic storage medium, an optical storage medium, an electromagnetic storage medium, a semiconductor storage medium, a mechanical storage medium, or any suitable combination of the foregoing. Some known types of storage devices that include these media include: magnetic disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), static random access memories (SRAM), compact disk read-only memories (CD-ROMs), digital versatile disks (DVDs), memory sticks, floppy disks, mechanical encoding devices (such as punch cards or pits / land formed in a major surface of a disk), or any suitable combination of the foregoing. Computer-readable storage media, as the term is used in this disclosure, should not be construed as storing in the form of transient signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides, light pulses transmitted through fiber optic cables, electrical signals transmitted through wires and / or other transmission media. As will be appreciated by those skilled in the art, data is typically moved at certain occasional points in time during normal operation of the storage device, such as during access, defragmentation, or garbage collection, but this does not make the storage device transient because the data is not transient while it is stored.

[0022] The computing environment 100 includes an example of an environment for executing at least some of the computer codes involved in performing the methods of the present invention, such as the code of the invention in block 200 for authenticating and protecting a key-value data pair to protect node-related data subsequently verified using the key-value data pair. In addition to block 200, the computing environment 100 includes, for example, a computer 101, a wide area network (WAN) 102, an end-user device (EUD) 103, a remote server 104, a public cloud 105, and a private cloud 106. In this embodiment, the computer 101 includes a processor set 110 (including a processing circuit 120 and a cache 121), a communication structure 111, a volatile memory 112, a permanent storage device 113 (including an operating system 122 and a block 107, as described above), a peripheral device set 114 (including a user interface (UI) device set 123, a storage device 124, and an Internet of Things (IoT) sensor set 125), and a network module 115. The remote server 104 includes a remote database 130. The public cloud 105 includes a gateway 140 , a cloud coordination module 141 , a host physical machine set 142 , a virtual machine set 143 , and a container set 144 .

[0023] Computer 101 may take the form of a desktop computer, laptop computer, tablet computer, smart phone, smart watch or other wearable computer, mainframe computer, quantum computer, or any other form of computer or mobile device now known or developed in the future that is capable of running programs, accessing a network, or querying a database such as remote database 130. As is well known in the art of computer technology, and depending on the technology, the performance of computer-implemented methods may be distributed among multiple computers and / or among multiple locations. On the other hand, in this presentation of computing environment 100, the detailed discussion focuses on a single computer, particularly computer 101, to keep the presentation as simple as possible. Computer 101 may be located in the cloud, even though it is not yet fully understood. Figure 1 1 is not shown in the cloud, on the other hand, computer 101 need not be in the cloud except to any extent that can be positively indicated.

[0024] Processor set 110 includes one or more computer processors of any type known now or to be developed in the future. Processing circuit 120 may be distributed over multiple packages, such as multiple cooperating integrated circuit chips. Processing circuit 120 may implement multiple processor threads and / or multiple processor cores. Cache 121 is a memory located in the processor chip package and is typically used for data or code that should be quickly accessed by threads or cores running on processor set 110. Cache memory is typically organized into multiple levels based on relative proximity to the processing circuit. Alternatively, some or all of the caches of the processor set may be located "off chip". In some computing environments, processor set 110 may be designed to work with qubits and perform quantum computing.

[0025] Computer readable program instructions are typically loaded onto the computer 101 to cause the processor set 110 of the computer 101 to perform a series of operating steps to implement a computer-implemented method, so that the instructions so executed will instantiate the method specified in the flowchart and / or narrative description of the computer-implemented method included in this document (collectively referred to as the "method of the present invention"). These computer readable program instructions are stored in various types of computer-readable storage media, such as cache 121 and other storage media discussed below. The program instructions and related data are accessed by the processor set 110 to control and direct the execution of the computer-implemented method. In the computing environment 100, at least some of the instructions for executing the computer-implemented method can be stored in the box 200 of the persistent storage 113.

[0026] The communication fabric 111 is the signal conduction paths that allow the various components of the computer 101 to communicate with each other. Typically, the fabric is made up of switches and conductive paths, such as those that make up a bus, a bridge, physical input / output ports, etc. Other types of signal communication paths may be used, such as fiber optic communication paths and / or wireless communication paths.

[0027] The volatile memory 112 is any type of volatile memory now known or developed in the future. Examples include dynamic random access memory (RAM) or static RAM. Typically, the volatile memory 112 is characterized by random access, but this is not required unless affirmatively indicated. In the computer 101, the volatile memory 112 is located in a single package and is internal to the computer 101, but, alternatively or additionally, the volatile memory can be distributed in multiple packages and / or located externally relative to the computer 101.

[0028] Permanent storage 113 is any form of non-volatile storage for computers known now or developed in the future. The non-volatility of the memory means that the stored data is maintained regardless of whether power is supplied to the computer 101 and / or directly to the permanent storage 113. Permanent storage 113 can be a read-only memory (ROM), but usually at least a portion of the permanent storage allows the writing of data, the deletion of data, and the rewriting of data. Some common forms of persistent storage include disks and solid-state storage devices. Operating system 122 can take several forms, such as various known proprietary operating systems or operating systems of the open source portable operating system interface type using a kernel. The code included in frame 200 is generally included in at least some of the computer codes involved in performing the method of the present invention.

[0029] The peripheral device set 114 includes a set of peripheral devices of the computer 101. The data communication connection between the peripheral devices and other components of the computer 101 can be implemented in various ways, such as a Bluetooth connection, a near field communication (NFC) connection, a connection made by a cable (such as a universal serial bus (USB) type cable), a plug-in type connection (e.g., a secure digital (SD) card), a connection made through a local area communication network, and even a connection made through a wide area network such as the Internet. In various embodiments, the UI device set 123 may include components such as display screens, speakers, microphones, wearable devices (such as goggles and smart watches), keyboards, mice, printers, touchpads, game controllers, and tactile devices. The storage device 124 is an external storage device, such as an external hard drive, or a pluggable storage device, such as an SD card. The storage device 124 can be permanent and / or volatile. In some embodiments, the storage device 124 can take the form of a quantum computing storage device for storing data in the form of quantum bits. In embodiments where the computer 101 needs to have a large amount of storage (e.g., where the computer 101 locally stores and manages a large database), the storage may be provided by a peripheral storage device designed to store very large amounts of data, such as a storage area network (SAN) shared by multiple geographically distributed computers. The IoT sensor set 125 consists of sensors that can be used in IoT applications. For example, one sensor may be a thermometer, while another sensor may be a motion detector.

[0030] The network module 115 is a collection of computer software, hardware, and firmware that allows the computer 101 to communicate with other computers via the WAN 102. The network module 115 may include hardware such as a modem or a Wi-Fi signal transceiver, software for packetizing and / or depacketizing data transmitted over a communication network, and / or web browser software for transmitting data over the Internet. In some embodiments, the network control function and the network forwarding function of the network module 115 are performed on the same physical hardware device. In other embodiments (e.g., embodiments utilizing software defined networks (SDN)), the control function and the forwarding function of the network module 115 are performed on physically separated devices, so that the control function manages several different network hardware devices. Computer-readable program instructions for executing a computer-implemented method can typically be downloaded to the computer 101 from an external computer or an external storage device via a network adapter card or a network interface included in the network module 115.

[0031] WAN 102 is any wide area network (e.g., the Internet) capable of transmitting computer data over non-local distances by any technology now known or developed in the future for transmitting computer data. In some embodiments, WAN 102 may be replaced and / or supplemented by a local area network (LAN) designed to transmit data between devices located in a local area (e.g., a Wi-Fi network). WANs and / or LANs typically include computer hardware such as copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and edge servers.

[0032] End-user device (EUD) 103 is any computer system used and controlled by an end-user (e.g., a customer of an enterprise operating computer 101), and may take any of the forms discussed above in connection with computer 101. EUD 103 typically receives useful and usable data from the operation of computer 101. For example, in the hypothetical case where computer 101 is designed to provide recommendations to an end-user, the recommendations would typically be transmitted from network module 115 of computer 101 to EUD 103 via WAN 102. In this manner, EUD 103 may display or otherwise present the recommendations to the end-user. In some embodiments, EUD 103 may be a client device, such as a thin client, a heavy client, a mainframe computer, a desktop computer, etc.

[0033] Remote server 104 is any computer system that provides at least some data and / or functionality to computer 101. Remote server 104 may be controlled and used by the same entity that operates computer 101. Remote server 104 represents a machine that collects and stores useful and usable data for use by other computers, such as computer 101. For example, in the hypothetical case where computer 101 is designed and programmed to provide recommendations based on historical data, the historical data may be provided to computer 101 from remote database 130 of remote server 104.

[0034] The public cloud 105 is any computer system available for use by multiple entities that provides on-demand availability of computer system resources and / or other computer capabilities, particularly data storage (cloud storage) and computing capabilities, without direct active management by users. Cloud computing typically utilizes the sharing of resources to achieve consistency and economy of scale. The direct and active management of the computing resources of the public cloud 105 is performed by computer hardware and / or software of the cloud coordination module 141. The computing resources provided by the public cloud 105 are typically implemented by virtual computing environments running on various computers that constitute the host physical machine set 142, which is the universe of physical computers in and / or available for the public cloud 105. Virtual computing environments (VCEs) typically take the form of virtual machines from a virtual machine set 143 and / or containers from a container set 144. It should be understood that these VCEs can be stored as images and can be transferred between various physical machine hosts as images or after instantiation of the VCEs. Cloud orchestration module 141 manages the transfer and storage of images, deploys new instantiations of VCEs, and manages active instantiations of VCE deployments. Gateway 140 is a collection of computer software, hardware, and firmware that allows public cloud 105 to communicate over WAN 102 .

[0035] Some further explanation of a virtualized computing environment (VCE) will now be provided. A VCE can be stored as an "image". A new active instance of the VCE can be instantiated from the image. Two common types of VCEs are virtual machines and containers. Containers are VCEs that use operating system-level virtualization. This refers to an operating system feature in which the kernel allows the existence of multiple isolated user space instances, called containers. From the perspective of the programs running in them, these isolated user space instances typically behave like actual computers. Computer programs running on a normal operating system can utilize all of the resources of the computer, such as connected devices, files and folders, network shares, CPU capabilities, and quantifiable hardware capabilities. However, programs running within a container can only use the contents of the container and the devices assigned to the container, a feature known as containerization.

[0036] The private cloud 106 is similar to the public cloud 105, except that the computing resources are only available to a single enterprise. Although the private cloud 106 is depicted as communicating with the WAN 102, in other embodiments, the private cloud can be completely disconnected from the Internet and can only be accessed through a local / private network. A hybrid cloud is a combination of multiple clouds of different types (e.g., private, community, or public cloud types), typically implemented by different vendors. Each of the multiple clouds remains an independent and discrete entity, but the larger hybrid cloud architecture is bound together by standardized or proprietary technologies that enable coordination, management, and / or data / application portability between the multiple constituent clouds. In this embodiment, the public cloud 105 and the private cloud 106 are both part of a larger hybrid cloud.

[0037] In some aspects, a system according to various embodiments may include a processor and logic integrated with the processor and / or executable by the processor, the logic being configured to perform one or more of the process steps described herein. The processor may be any configuration as described herein, such as a discrete processor or a processing circuit including many components such as processing hardware, memory, I / O interface, etc. By integrated with it, it is meant that the processor has logic embedded therewith as hardware logic, such as an application specific integrated circuit (ASIC), FPGA, etc. By executable by the processor, it is meant that the logic is hardware logic; software logic, such as a part of firmware, an operating system, a part of an application; etc., or some combination of hardware and software logic, which is accessible by the processor and configured to cause the processor to perform a certain function when executed by the processor. The software logic may be stored on local and / or remote memory of any memory type, as is known in the art. Any processor known in the art, such as a software processor module and / or a hardware processor, such as an ASIC, FPGA, a central processing unit (CPU), an integrated circuit (IC), a graphics processing unit (GPU), etc., may be used.

[0038] As mentioned above, cryptography is the science of writing in secret for the purpose of keeping data confidential. Public and private keys are the basic concepts of public key cryptography, which is sometimes also called asymmetric cryptography. In public key cryptography, each public key is matched with only one private key. Together, they are used to encrypt and decrypt data. For example, a message encoded using a public key can only be decoded using the matching private key.

[0039] Data authenticity is mainly ensured by signing documents with a private key, so that any user of the data can verify the authenticity by using the corresponding public key. However, the signature algorithm is based on asymmetric cryptography, which is slower compared to symmetric cryptography. In addition, it is difficult to use hardware security modules (HSMs) for signing. This is because the firmware of the HSM usually does not allow the private key to be extracted from the HSM, which severely limits the number of keys to be used due to the memory limitations of the HSM.

[0040] In stark contrast to the above deficiencies, the various embodiments and methods described herein verify the authenticity of data from both the client and the cloud provider, with the root of trust firmly anchored within the HSM. This is essentially a more flexible and relatively high-performance alternative to using asymmetric key-based signatures by utilizing symmetric keys and performing all security-related operations within the HSM while maintaining full cloud-scale scalability.

[0041] Reference now Figure 2 , a flow chart of a method 300 according to an embodiment is shown. In various embodiments, the method 300 may be performed according to the present invention. Figure 1-5F Of course, as will be appreciated by those skilled in the art upon reading this specification, method 300 may include more Figure 2 More or fewer operations may be performed as specifically described in .

[0042] Each step of method 300 may be performed by any suitable component of an operating environment. For example, in various embodiments, method 300 may be performed in part or in whole by a computer or some other device having one or more processors therein. A processor (e.g., a processing circuit, chip, and / or module implemented in hardware and / or software and preferably having at least one hardware component) may be utilized in any device to perform one or more steps of method 300. Illustrative processors include, but are not limited to, a central processing unit (CPU), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), etc., combinations thereof, or any other suitable computing device known in the art.

[0043] It can be stated in advance that the techniques of method 300 can be used to authenticate arbitrary data using a trust anchor within an HSM with a node measurement preparation phase. More specifically, various of these techniques can be used to authenticate and protect key-value data pairs to protect node-related data that is subsequently authenticated using the key-value data pairs. The keys of such authentication are not exposed, which is different from authentication using a public key, which is posted in a location with obvious contrast. In some methods, from a high-level perspective, the authentication of method 300 can first include starting an environment, or in the case where authentication is performed as a service, method 300 can first include starting a verifier. Next, a client, such as a client device, can be registered. For methods where multiple tenants / clients use this service, multiple clients are registered. Thereafter, a computing node can be registered for each client. Once the process is completed, the authenticity of the information registered in these described steps can be verified.

[0044] The techniques described in more detail in the various operations of method 300 include a description of how a client device can check the authenticity of a public key of a trusted platform module (TPM) (or any other data) in order to reduce the required trust level of the authenticator. Instead of requesting a key management service (KMS) (e.g., IBM's key protection (KP)) to generate a new (random) client root key (CRK) for the client, the authenticator can import the CRK directly into the HSM. The bits of the CRK can be defined by the client, however, these bits are preferably never seen in plain text by the authenticator. The client device can also have a KMS instance, and the client device can input the same CRK bits as the authenticator (as described above) of the KMS instance for the authenticator to the client device's own instance. As a result, both the authenticator and the client device have bits of the CRK available inside their respective HSMs. The client device can require the authenticator to provide a wrapped symmetric key (e.g., wDEK) for a specific node and the corresponding tag bits, initialization vector (IV), and additional authenticated data (AAD) (or a public key and IP address for recreating the AAD field). In this way, a command can be issued to unpack the symmetric key packaged by the client device to the KMS instance of the client device. If successful, the client device knows that the real public key of the specific node is being used. Various exemplary methods that describe these techniques in more detail are described below, for example, see operations 302 and 328 of method 300.

[0045] Operation 302 includes securely loading a first symmetric key within a hardware security module (HSM). In one approach, the first symmetric key is loaded from a key management service database of a known type into the HSM via a key management service of a known type. In some preferred methods, the secure loading of the first symmetric key occurs prior to the encryption of the second symmetric key and may be triggered by a predetermined verifier program code of the verifier that initiates a command to load the first symmetric key within the HSM. In some methods, the first symmetric key is a customer root key (CRK), such as, for example, an Advanced Encryption Standard (AES) key. Additionally, in some methods, the second symmetric key may be a data encryption key (DEK) of a known type that is configured to be encrypted, for example, a wrapped DEK (wDEK), and to be decrypted, for example, an unwrapped DEK (plaintext DEK).

[0046] In some methods, the first symmetric key resides in the KMS database in an encrypted state. In addition, in some methods, the cloud provider can access only the encrypted bits of the first symmetric key. Therefore, in some methods, the first symmetric key can be decrypted during the process of being securely loaded into the HSM. In some methods, the process of securely loading the first symmetric key in the HSM can include loading the encrypted instance key encryption key (IKEK) of the KMS database into the HSM to assist in the process of unpacking and / or decrypting the encrypted first symmetric key. Note that in other methods, the IKEK can optionally reside in the KMS database in a packed or decrypted state. For methods of loading the encrypted IKEK in the HSM, the master key encryption key (MKEK) of the HSM can be used to unpack and / or decrypt the IKEK encrypted in the HSM, for example, see operation 304. Note that decryption is essentially an unpacking command executed in some methods. The MKEK can be preloaded on the HSM and used as the HSM master key. The authenticator is "linked" to the HSM via the IKEK. In some approaches, the IKEK is a key that is automatically generated by the KMS for each instance and is securely stored by the KMS in the KMS database. In some approaches, the IKEK is wrapped with the MKEK, and the MKEK is securely preloaded to all HSMs of the KMS.

[0047] Once decrypted, the encrypted first symmetric key may be loaded from the database to the HSM using the unwrapped and / or decrypted IKEK, e.g., see operation 306. More specifically, in some methods, the encrypted first symmetric key is decrypted (e.g., unwrapped) using the unwrapped and / or decrypted IKEK, e.g., see operation 308, so that the IKEK may be loaded into the HSM for use in the decryption process. After reading the description herein, techniques that will be apparent to one of ordinary skill in the art may be used to encrypt and decrypt keys of a KMS database.

[0048] Operation 310 includes encrypting a second symmetric key using the decrypted first symmetric key. In a preferred method, the second symmetric key is encrypted using Advanced Encryption Standard with Galois / Counter Mode (AES-GCM) encryption. As will be described in detail elsewhere herein, the encryption of the second symmetric key is "authenticable" encryption because in some preferred methods the second symmetric key is ultimately used to ensure authentication of the client node registered with the TEE that communicates with the HSM. Thus, encrypting the second symmetric key using the decrypted first symmetric key enables authenticated encryption using relevant data that is compared before and after encryption, e.g., see Figure 3 . During the encryption of the second symmetric key by the first symmetric key, one or more types of key data may be used, for example, information of a node of a client registered with the authenticator, which is used to generate an unencrypted second symmetric key before encrypting the second symmetric key. In a preferred method, the key data of the key-value pair (or its hash) of the second symmetric key is used as additional authentication data (AAD) for encrypting the second symmetric key. In some methods, all encryption and decryption described in the various embodiments and / or methods described herein, for example, for encryption of the second symmetric key, may be an authenticated encryption with associated data (AEAD) cipher. In some methods, the key data may include a hash of node information, such as a SHA256 hash, such as a public key, an IP address, etc. In some methods, the key data may additionally and / or alternatively include a hash of a random number, such as a SHA256 hash. The information may additionally and / or alternatively include an IV appropriately selected using one or more predetermined known techniques, such as a random IV. The plaintext bits of the unencrypted second symmetric key are also available. Additionally, because the AAD is present in the authenticator, the flag bit can be created with the encrypted second symmetric key, for example, during AES_GCM encryption of the unencrypted second symmetric key. In some approaches, symmetric cryptography can be used for encryption and / or decryption, for example, a shared private key is used for encryption and decryption.

[0049] In some methods, secret information, such as node-related information, can be received from a node of a client device. Note that the node is preferably the same node on which the AAD is based. For example, such secret information may include, for example, client key sharing, predetermined trusted platform module (TPM) (authorization) secrets, node configuration, signing keys, etc. Once encrypted, the secret information can be stored as "value data" and can be injected into the TPM. In some methods, an unencrypted second symmetric key is used to encrypt value data of a verifiable key-value pair, for example, see operation 312. Once encrypted, the value data can be securely stored in a related customer file in a database of a known type. In addition, in some methods, after the value data is encrypted by the unencrypted second symmetric key, the second symmetric key can be encrypted by the first symmetric key.

[0050] Operation 314 includes storing an encrypted second symmetric key, an AAD used in the encryption of the second symmetric key, and a tag bit created during the encryption of the second symmetric key. In some methods, in operation 314, IV may be stored additionally and / or alternatively. For context, one or more of these types of information stored in operation 314 are stored as information related to a specific node (e.g., the node on which the AAD is based). As will be described in more detail below, the stored information is used to verify node-related data after storage, for example, see operations 316-328. In some methods, one or more types of information stored in operation 314 may be stored in a database managed by a validator. In some other methods, the information may be output to a client device and stored on the client device additionally and / or alternatively. In yet another method, the information may be stored additionally and / or alternatively at multiple storage devices at different locations.

[0051] It should be noted that although various operations are described above with respect to a single client device and node, in some methods, method 300 includes registering several clients, where each such client may have one or several computing nodes. For each of these client computing nodes, some secure encrypted information may be stored using the above techniques to register the node so as to enable the node to be authenticated thereafter, e.g., see operations 316-328.

[0052] Receive node-related data of the node, for example, see operation 316. In some methods, the node-related data can be received by the validator from the device of the client registered with the validator. According to some methods, the node-related information may include, for example, an IP address, public key information, a node ID, etc. The node-related data may additionally and / or alternatively include the tag bit of the node. In addition, the node-related data may additionally and / or alternatively include the AAD of the node, which is determined in some methods by hashing (e.g., SHA256 hashing) and other information of the node-related data, such as an IP address, public key information. In some methods, the node-related data can be received using a request for accessing the encrypted value data of the key-value pair. In another method, the node-related data can be additionally and / or alternatively received from a related node having a request for being authenticated.

[0053] In some methods, the first symmetric key is used to decrypt an encrypted third symmetric key associated with the node-related data, e.g., see operation 318. It should be noted that the encrypted third symmetric key may actually be the encrypted second symmetric key, however, from a terminology perspective, it is referred to herein as the "encrypted third symmetric key" because authenticity has not yet been satisfied, e.g., see operations 320-328.

[0054] The authenticity of the decrypted third symmetric key is determined, e.g., see decision 320. Figure 3 , according to one embodiment, illustrates exemplary sub-operations for determining the authenticity of a decrypted symmetric key, one or more of which may be used to perform Figure 2 However, it should be noted that according to one embodiment, Figure 3 sub-operations of , which is in no way intended to limit the present invention.

[0055] Continue to refer Figure 3, in some methods, the authenticity of the decrypted third symmetric key is determined by one or more comparisons. In one such method, the authenticity of the decrypted third symmetric key can be determined based on a first comparison of the tag bits of the node with the tag bits created during the encryption of the second symmetric key. For example, sub-operation 330 includes determining whether the tag bits of the node match the tag bits created during the encryption of the second symmetric key. In some methods, in response to determining that the tag bits of the node match the tag bits created during the encryption of the second symmetric key, for example, as shown by the "yes" logic path of sub-operation 330, a second comparison can be optionally performed to determine the authenticity of the decrypted third symmetric key. In some methods, the second comparison can be a comparison of the AAD of the node with the AAD used in the encryption of the second symmetric key. For example, sub-operation 332 includes determining whether the AAD of the node matches the AAD used in the encryption of the second symmetric key. In response to determining in the first comparison that the AAD of the node does not match the AAD used in encryption of the second symmetric key, e.g., as shown by the “No” logic path of sub-operation 332, and / or in response to determining in the second comparison that the tag bits of the node do not match the tag bits created during encryption of the second symmetric key, e.g., as shown by the “No” logic path of sub-operation 330, it can be determined that the decrypted third symmetric key is untrusted. More specifically, determining that the decrypted third symmetric key is untrusted includes determining that the decrypted third symmetric key is not the second symmetric key because the tag bits and / or AAD do not match. In response to determining that the decrypted third symmetric key is untrusted, the method optionally continues with the “No” logic path of decision 320, e.g., see. Figure 2 In some approaches, in response to determining that the decrypted third symmetric key is untrusted, the decrypted third symmetric key is not used to decrypt the encrypted value data of the key-value pair, e.g., see operation 322 of method 300. A warning regarding a failure to authenticate the received node-related data may additionally and / or optionally be output, e.g., see operation 324. In one approach, the warning is output to an administrator device of the authenticator and indicates that the node is improperly attempting to access the encrypted data of the key-value pair.

[0056] Reference again Figure 3 In response to determining in the first comparison that the AAD of the node matches the AAD used in encryption of the second symmetric key, and / or determining in the second comparison that the tag bits of the node match the tag bits created during encryption of the second symmetric key, e.g., as shown by the “no” logic paths of sub-operations 330 and 332, it can be determined that the decrypted third symmetric key is authentic, e.g., see the “yes” logic path of decision 320, continuing to operation 326. Now referring to Figure 2, operation 326 includes, in response to determining that the decrypted third symmetric key is authentic, decrypting the encrypted value data of the key-value pair using the decrypted third symmetric key (e.g., now authenticated as being actually the second symmetric key). In some methods, decryption of the encrypted value data of the key-value pair may include a process comprising: loading previously stored encrypted data into a verifier, and decrypting the encrypted data using the decrypted third symmetric key, e.g., plaintext DEK. By accessing the node-related data obtained as a result of the decryption of the encrypted data, one or more known types of verification operations may be performed on the received node-related data and / or the decrypted data, e.g., see operation 328.

[0057] It should be noted that in some methods, the value data of the key-value pair can be encrypted by a validator with a predefined validator program code. Therefore, in some methods in which the validator is configured to execute the validator program code, method 300 may optionally include executing the validator to verify the node-related data. In some methods, this can be performed in a cloud computing environment such as a trusted execution environment (TEE) (such as a provable isolated land). It should be noted that the validator can verify the code, but not the TEE. In contrast, the technique for checking the integrity of the TEE is to prove that the verifier is executed to verify the node-related data.

[0058] So far, authentication and protection of key-value data pairs have not been considered in traditional data authenticity technologies to protect node-related data that are subsequently verified using key-value data pairs. As described above, this is because traditional signature algorithms are based on asymmetric cryptography, which is relatively slow when compared to symmetric cryptography. In addition, it is difficult to use conventional HSMs to achieve the purpose of signing. This is because the firmware of traditional HSMs generally does not allow private keys to be extracted from HSMs, which severely limits the number of keys to be used due to the memory limitations of HSMs. Therefore, since various techniques described herein are used to protect node-related data, many benefits can be achieved. For example, since symmetric cryptography is used instead of asymmetric cryptography, the cryptography described herein is relatively fast. This leads to a relative improvement in the efficiency of computer systems that implement the various embodiments and methods described herein. It should be noted that these enabled relative efficiencies are not at the expense of reduced security in the techniques described herein. This is because key authenticity is ensured before encrypted node-related data is encrypted to perform verification work. Thus, the inventive findings disclosed herein regarding the use of authentication and protection key-value data pairs to protect node-related data, which is thereafter verified using the key-value data pairs, proceed contrary to conventional wisdom.

[0059] Figures 4A-4HA network 400 according to one embodiment is described. Alternatively, the present network 400 may be implemented in conjunction with features from any other embodiment listed herein (e.g., those described with reference to other figures). However, of course such a network 400 and other networks presented herein may be used in a variety of applications and / or permutations, which may or may not be specifically described in the illustrative embodiments listed herein. Furthermore, the network 400 presented herein may be used in any desired environment.

[0060] First reference Figure 4A , a network 400 including an authenticator may be started in a method using a known startup process. In one method, within the network 400, the authenticator is preferably run inside a verifiable trusted execution environment (TEE), such as a secure service container (SSC) on a mainframe. The authenticator may include a predetermined program code, for example, see the authenticator program code that can be used to access the KMS of the network 400. In one method, the KMS includes a KMS database, for example, see KMSDB. According to some more specific methods, the KMS may include a KMS service and / or another key management service (KMS), for example, such as IBM's key protection (KP), which is an implementation of IBM's KMS that handles one or more additional keys. In order to access the KMS of the network 400, the authenticator may include configuration data, for example, see configuration and / or secrets. In one method, the configuration data may include an instance ID of the KMS instance, for example, a KMS instance ID, which in a broader sense may be a pointer to a location where an instance key encryption key (IKEK) 402 is stored. In some approaches, the authenticator's secrets may include a token and / or a certificate, such as, for example, a KMS instance ID certificate, which enables access to the KMS.

[0061] In some approaches, the validator maintains a client list (e.g., View Client List (Empty)), which is an initially empty database. Although in some approaches, the client list is empty when the validator starts, the client list may eventually be populated with information 404, such as client IDs, client-related metadata 410 such as billing information, client-related metadata such as email addresses, other known types of client-related metadata, etc. The information 404 may additionally and / or alternatively include a pointer to a client file name that is maintained in a different database, such as a database other than the database storing the client list information 404.

[0062] At this point, it can be assumed that the authenticator is up and running and that no clients have been registered in the client list. It can also be assumed that the KMS (e.g., see KMS HSM) is running and includes a loaded master key encryption key (MKEK) 406. In one approach, MKEK 406 is a key initiated inside the KMS HSM and is not seen outside the KMS HSM. In another approach, MKEK 406 can be pre-loaded onto the KMS HSM in addition and / or alternatively and used as the HSM master key. In addition, because KMS itself is a multi-tenant configuration, IKEK 402 is owned by the authenticator, although IKEK 402 is encrypted by MKEK 406 in the KMS database.

[0063] Finally, the arrows to / from the nodes point to the IP addresses of the computational nodes, and the client intends to perform known types of measurements on the ordered validating nodes later. However, at this stage, the nodes are not yet connected, because the information to perform such measurements is not available when the validator starts.

[0064] In one approach, a prerequisite for the network may be that the authenticator is running in a TEE, e.g., where a client device can perform attestation of the TEE. The prerequisite may additionally and / or alternatively include the authenticator having a KMS instance. The prerequisite may additionally and / or alternatively include the authenticator having a key value store having a key, e.g., ClientID, a value CRK_keyID (populated later), which may be stored with a client list, e.g., Client_list.

[0065] Reference now Figure 4B , a request may be received from a client device to register with the authenticator, for example, to register with an authenticator service associated with the authenticator, for example, to see a client list. In some methods, the request includes information associated with a client of the requesting client device, for example, ClientID, client data, etc. The requesting client may be assigned a client file name 408, for example, ClientID_1, where all files are located at that particular client. Figure 4B As shown, in one method, the client file name 408 can be stored in the second database, such as a client file. In another method, the client file name 408 can be stored in the first database in addition and / or alternatively, such as, for example, a client list. According to various methods, the client file can include information, such as, ClientID, the number of nodes that the client wants to verify that the client has, a list of NodelIDs, etc.

[0066] The client may be assigned a client root key ID (CRK_keyID) of a client root key (CRK) 412 generated in the KMSDB, e.g., see Generating a CRK. More specifically, in one approach, generating a client root key may include the authenticator sending an instruction to the KMS to generate a CRK. In response to receiving the instruction to generate a CRK, the KMS generates the CRK 412 inside the KMS HSM. Generating the CRK 412 inside the KMS HSM in some approaches includes loading the IKEK 402 onto the KMS HSM, which in one approach may include unpacking the IKEK 402 using the MKEK 406. Thereafter, the CRK 412 may be encrypted using the IKEK 402.

[0067] exist Figure 4C In FIG. 4 , a process of registering a client node in network 400 is shown according to one method. Figure 4C , for purposes of example, operations are described for a first node having a client with client ID_1, but additional clients have been registered with the validator, e.g., see second client 414 which may be assigned client ID of Client_2, and Nth client 416 which may be assigned client ID of Client_N. It may also be noted that each of the client files may contain metadata and a node list 436, and each node list entry contains metadata and a secret / encrypted JSON 438. It may be assumed that the first node is characterized by information including the IP address of the first node (e.g., see IP_address[nodeID_n] and a public key (e.g., PubKey[nodeID_n]), which is ultimately used to verify any measurement data generated and signed internally in the node, e.g., see To / From Node. This information is fed into the validator, e.g., see operation 418, and the validator creates a hash, e.g., such as SHA256, which is ultimately used as additional authentication data (AAD) for symmetric encryption operations, which will be described in more detail elsewhere herein.

[0068] The process of registering a client node with a validator in the network 400 may additionally and / or alternatively include validating enabling the client to securely import the CRK, e.g., importing CRK_keyID and ClientID in the sense of bringing its own keys into the validator's KMS instance. The validator may add the ClientID and / or CRK_keyID to the Client_list, and the validator may create a key-value store, e.g., on disk, for the ClientID, e.g., see Node_list[ClientID].

[0069] Reference now Figure 4D, the verifier generates a random number, for example, see #1. In some methods, entropy is generated. For example, a plaintext data encryption key (DEK) 420 can be generated with the aid of a SHA256 hash. Thus, a plain DEK 420 can be a 256-bit symmetric data encryption key.

[0070] For some alternative methods utilizing Advanced Encryption Standard with Galois Counter Mode (AES-GCM) cryptography, a random initialization vector may be called, see for example, Random IV, which may be generated using a random number.

[0071] exist Figure 4E , the authenticator issues a command to the KMS to load CRK 412 to the KMS's HSM. Thus, in operation 422, CRK 412 is loaded to the KMS HSM. IKEK is also loaded, e.g., see operation 424, and decrypted and / or unwrapped by MKEK 406, e.g., see D / U. Decrypted IKEK 426 is used to decrypt and / or unwrapped CRK, e.g., see decrypted CRK 428.

[0072] Reference now Figure 4F , the loading of CRK 412 to the KMS HSM may be performed according to the wrapDEK command. More specifically, in a first step, IKEK 402 is loaded from the KMSDB to the KMS HSM via unwrapping (e.g., via decryption) IKEK 402 using MKEK 406. In a next step, CRK 412 is loaded to the KMS HSM and unwrapped and / or decrypted using unwrapped IKEK 426. Thereafter, the plaintext DEK 420 is encrypted using the decrypted CRK 428 by taking into account the AAD and the random IV, thereby establishing a wrapped DEK, e.g., see wDEK 430, which is essentially a plaintext DEK that has been AES encrypted (AES-GCM) using the decrypted CRK 428 using Galois / Counter Mode, taking into account the AAD and the random IV. The plaintext bits of the plaintext DEK are also available. Furthermore, because the AAD is present in the authenticator, the wDEK is also used to create tag_bits during AES-GCM encryption, which can be used for double-checking encryption operations as will be described in more detail elsewhere herein.

[0073] In some illustrative methods, the registration process of a node may include a client device registering a node using an associated ClientID. For example, the verifier may receive a public key, such as pub_key, node_id, from a node TPM, and the verifier obtains the IP address of the node, for example, see IP_address. In one of these methods, the verifier may perform SHA256 or another similar known type of hash function with PubKey and / or IP_address (e.g., authification_hash). In an optional method, the verifier knows one and only final hash. In this method, in the case where the final hash is unknown, the verifier can use a random number, such as hash_final, hash_final_nown_bool. In addition, the verifier can perform a wrapDEK operation in a KMS instance with plainDEK=hash_final, AAD=authenticity_hash, where CRK_keyID is used for wrapping, for example, wrappedDEK, tag_bits. Afterwards, the validator stores the key information in node_list[ClientID], for example, node_id,value:[pub_key,IP_address,wrappedDEK,tag_bits].

[0074] In some approaches, the client is linked to the authenticator and HSM via the CRK (the CRK is stored in a packaged form by the KMS), with "loading" being equivalent to unpacking the CRK into the HSM, possibly requiring the IKEK inside the HSM to allow for the unpacking, which links the CRK to the IKEK and links it to the authenticator.

[0075] exist Figure 4G In operation 432, the IV_bits, wDEK 430 and tag_bits obtained from the encryption are stored as information related to a specific node, for example, see nodes[nodeID]. In some methods, such information is preferably stored in a database managed by the authenticator. In some other methods, this information can be output to the client device and stored on the client device.

[0076] Reference now Figure 4HIn operation 434, secret data may be received from a client device in the network 400. For example, such secret data may include, for example, client key sharing, predetermined trusted platform module (TPM) (authorization) secrets, what the node configuration is, what the signing key is, etc. For example, such information may be node-related data that is loaded into the verifier, encrypted using the plain text DEK 420, and securely stored in the relevant client file (e.g., see client files). Such secret information may be used so that a client device can access a trusted platform module on a particular node. This is useful because when a client device attempts to access a node, it is ensured that the access information associated with the node is securely authenticated so that the client cannot be deceived into attempting to access a malicious node, for example, another node disguised as a node that is actually operating.

[0077] In some approaches, the node is authenticated by the HSM via a TPM public key (~= certificate) and IP address. This may be somewhat complex to understand immediately, although one of ordinary skill in the art will fully understand the process after reading the description herein. For example, and as will be described in more detail elsewhere below, where a SHA256 of a public key and / or IP address is used as the AAD for AES-GCM encryption, in some approaches successive decryption attempts are successful if and only if the same SHA256 value is used as the AAD used during encryption.

[0078] At this point, the authenticator service is up and running, several clients are registered, each of which may have one or several computing nodes, and for each of these client computing nodes, there is some securely encrypted information. According to one embodiment, various operations of network 400 may be performed at Figures 5A-5F Used to verify the node.

[0079] Figures 5A-5F Described according to one embodiment Figures 4A-4H network 400. Specifically, Figures 5A-5F In the , perform various operations to verify Figures 4A-4H Nodes registered with the network 400 in. Alternatively, the present network 400 may be implemented in conjunction with features from any other embodiment listed herein, such as those described with reference to other figures, however, of course such a network 400 and other networks presented herein may be used in a variety of applications and / or permutations, which may or may not be specifically described in the illustrative embodiments listed herein. In addition, the network 400 presented herein may be used in any desired environment.

[0080] Reference now Figure 5A, it can be assumed that the authenticator is up and running, and the client files and clients are registered in the network 400. The node data (e.g., node[nodeID_n] of node 502) may include any predetermined identification information of the node, such as the IP address of the node, the public key of the node, any one or more types of information used when registering the node with the authenticator, etc. In operation 504, the node information of the node is loaded into the authenticator. Because the node is actually a registered node and not a malicious node, the hashing of the information, such as see Hash, returns an AAD that matches the AAD of the client associated with the node. Therefore, the AAD is regenerated on the fly.

[0081] Reference now Figure 5B In operation 506, the validator is reloaded with Figures 4A-4H The encrypted DEK, IV bits, and tag bits generated in the enrollment operation described in .

[0082] exist Figure 5C In operation 508, the authenticator issues a command to the KMS to load the CRK 412 to the KMS HSM, e.g., see the loadCRK command. In operations 508 and 510, the encrypted IKEK 402 and the encrypted CRK 412 are decrypted and reloaded onto the KMS HSM. The techniques for loading and decrypting the encrypted IKEK 402 and the encrypted CRK 412 on the KMS HSM (e.g., see operations 424 and 422) can be used to reload the decrypted encrypted IKEK 402 and the encrypted CRK 412 on the KMS HSM, e.g., see operations 508 and 510.

[0083] Reference now Figure 5D , after reloading the decryption pair of encrypted IKE 402 and encrypted CRK 412 on the KMS HSM, a command for decrypting wDEK 430 is issued, for example, via an unwrapDEK command. The plain text DEK is generated by executing the unwrapDEK command on wDEK 430.

[0084] In a preferred method, if the tag bits of node 502 match the tag bits generated during node registration (e.g., by Figure 4F The operation is determined to be successful if the tag bits generated by the execution of the wrapDEK command in 430 match (e.g., are identical). Note that without possessing and / or knowing the information used to previously wrap the plaintext DEK during node registration, wDEK 430 will not be able to perform the operation based on Figure 5DThe unwrapDEK command in is unpacked. Therefore, if the tag bit of the node 502 matches the tag bit generated during the registration of the node, it can be determined that the operation is successful. On the contrary, if the tag bit of the node 502 does not match the tag bit generated during the registration of the node, it can be determined that the operation is unsuccessful.

[0085] Reference now Figure 5E , assuming a bit match is determined, it can be determined that access to the plaintext bits of the data encryption key (e.g., the bits of plaintext DEK 420) has been regained. This means that the bits of plaintext DEK 420 can be used to load and decrypt previously encrypted node-related data. For example, now referring to Figure 5E , in operation 512, the node-related data previously encrypted using the bits of the plaintext DEK (eg, see EncryptedData[nodeID_n]) is loaded onto the validator. Now referring to Fig. 5F , in operation 514, the bits of the plaintext DEK 420 are used to decrypt the node-related data, e.g., see the resulting DecryptedData[nodeID]. At this point, it can be determined that the PubKey of the node 502 with the specified IP address, e.g., see PubKey and IP_address, is credible and has all the secret information that is called to access the node. For example, such information may include the TPM (authorization) secret of the node 502. As previously described, it can be determined that the information is credible because the wDEK was successfully decrypted. Therefore, the actual verification work of the node can be performed. For example, in some methods, one or more known types of node verification operations can be performed.

[0086] In one illustrative method, a verifier may be used to perform verification of a node. For example, for all ClientIDs, the verifier may retrieve Node_list[ClientID], CRK_keyID[ClientID] from Client_list. For all entries in node_list[ClientID], a process may be performed including the verifier retrieving a signed hash (e.g., subject_hash, hash_signature) from the node TPM. The process may additionally and / or alternatively include the verifier retrieving [pub_key, IP_address, wraddedDEK, tag_bits] of the Node_id from the key value storage. The verifier may perform a SHA256 hash or another similar known type of hash using [PubKey||IP_address] for recreated_authenticity_hash. In addition, the verifier may perform a predetermined unwrapDEK operation on a KMS instance having wrappedDEK, tag_bits, AAD=recreated_authenticity_hash using the CRK_keyID used for packaging (e.g., plainDEK or failure) in the KMS instance. In response to determining that a failure has occurred, the information does not match, an alarm is issued because the AES-GCM tag bit verification failed. In response to determining that no failure has occurred, the pub key can be used to check hash_signature. In response to determining that hash_final_hovate_bool==true, the verifier is instructed to check proposed_hash==plainDEK. The result of this check includes success, such as OK, or failure. In response to determining that the result is a failure, an alarm is issued because the hash does not match. In response to determining that the result is not a failure, verification is completed. Note that the verifier does not need to always go to the HSM, instead, some results can be retained in the TEE memory for execution.

[0087] In another illustrative approach, the TPM hash or its SHA256 only makes it a valid AES256 key, the plaintext bits used as the DEK, even this TPM hash can be authenticated and verified by the HSM. In some approaches, AES-GCM encrypted SHA256 (TPM hash) can be used inside the KMS HSM, the CRK can be used as the key, and the SHA256 of the public key and / or IP address can be used as the AAD. During encryption, the HSM can generate tag bits. These tag bits "bind" everything together, for example, where everything includes the IP address, public key, client, authenticator [TPM hash], KMS HSS), etc. In the event that it is determined that even one bit in any of these types of information changes, the decryption attempt fails and reveals that something is wrong.

[0088] It is clear that the various features of the foregoing systems and / or methods may be combined in any manner, resulting in multiple combinations from the description presented above.

[0089] It should also be appreciated that embodiments of the present invention may be provided as a service deployed on behalf of a client to provide services on demand.

[0090] The description of various embodiments of the present invention has been given for the purpose of illustration, but it is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terms used herein are selected to best explain the principles of the embodiments, practical applications, or technical improvements existing in the market, or to enable other persons of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A computer-implemented method comprising: Using the first symmetric key to encrypt the second symmetric key, Wherein, before the encryption of the second symmetric key, the first symmetric key is securely loaded into the hardware security module HSM by the key management service, wherein the cloud provider has access only to the encrypted bits of the first symmetric key; wherein the key data of the key-value pair of the second symmetric key is used as additional authentication data AAD for encryption of the second symmetric key; encrypting the value data of the key-value pair using the second symmetric key; and The encrypted second symmetric key, the AAD used in the encryption of the second symmetric key, and the tag bits created during the encryption of the second symmetric key are stored for later use in verifying node-related data.

2. The computer-implemented method of claim 1 , comprising: Receiving the node-related data of a node, wherein the node-related data includes a tag bit of the node and an AAD of the node; decrypting an encrypted third symmetric key associated with the node-related data using the first symmetric key; and Determine the authenticity of the decrypted third symmetric key, wherein the authenticity of the decrypted third symmetric key is determined based on a first comparison of the node's tag bits with the tag bits created during encryption of the second symmetric key, and based on a second comparison of the node's AAD with the AAD used in encryption of the second symmetric key.

3. The computer-implemented method of claim 2, wherein: In response to determining in the first comparison that the AAD of the node matches the AAD used in encryption of the second symmetric key, and determining in the second comparison that the tag bits of the node match the tag bits created during encryption of the second symmetric key, the decrypted third symmetric key is determined to be authentic.

4. The computer-implemented method of claim 3, comprising: In response to determining that the decrypted third symmetric key is authentic, decrypting the encrypted value data of the key-value pair using the decrypted third symmetric key; and A validation operation is performed on the received node-related data.

5. The computer-implemented method of claim 3, wherein: The third symmetric key is the second symmetric key.

6. The computer-implemented method of claim 3, wherein: In response to determining in the first comparison that the AAD of the node does not match the AAD used in the encryption of the second symmetric key and / or determining in the second comparison that the tag bits of the node do not match the tag bits created during the encryption of the second symmetric key, the decrypted third symmetric key is determined to be untrustworthy, and the method includes: in response to determining that the decrypted third symmetric key is untrustworthy, not using the decrypted third symmetric key to decrypt the encrypted value data of the key-value pair; and outputting a warning that the received node-related data authentication failed.

7. The computer-implemented method of claim 1 , wherein: Securely loading the first symmetric key into the HSM by the key management service prior to encryption of the second symmetric key comprises: Loading the encrypted instance key encryption key IKEK of the database into the HSM, decrypting the encrypted IKEK in the HSM using the master key encryption key MKEK of the HSM, loading the first symmetric key from the database to the HSM, wherein the first symmetric key is encrypted in the database, and The encrypted first symmetric key is decrypted using the decrypted IKEK.

8. The computer-implemented method of claim 1 , wherein: Advanced Encryption Standard AES-GCM encryption with Galois / Counter Mode is used to encrypt the second symmetric key.

9. The computer-implemented method of claim 1 , comprising: A verifier of a provable trusted execution environment TEE is executed to verify the node-related data in a cloud computing environment within the TEE.

10. The computer-implemented method of claim 1, wherein: The encryption of the second symmetric key is authenticated encryption AEAD with associated data, wherein the key data of the key-value pair of the second symmetric key is used as the AAD for the AEAD encryption of the second symmetric key.

11. A computer program product, the computer program product comprising a computer-readable storage medium having program instructions embodied therein, the program instructions being readable and / or executable by a computer to cause the computer to: encrypting, by the computer, a second symmetric key using the first symmetric key, in, Prior to encryption of the second symmetric key, the first symmetric key is securely loaded into the hardware security module HSM by a key management service, wherein the cloud provider has access only to the encrypted bits of the first symmetric key; wherein the key data of the key-value pair of the second symmetric key is used as additional authentication data AAD for encryption of the second symmetric key; encrypting, by the computer, value data of the key-value pair using the second symmetric key; and The encrypted second symmetric key, the AAD used in encryption of the second symmetric key, and tag bits created during encryption of the second symmetric key are stored by the computer for later use in verifying node-related data.

12. The computer program product according to claim 11, wherein the program instructions can be read and / or executed by the computer to cause the computer to: The node-related data of a node is received by the computer, wherein: The node related data includes the label bit of the node and the AAD of the node; decrypting, by the computer, an encrypted third symmetric key associated with the node-related data using the first symmetric key; as well as The authenticity of the decrypted third symmetric key is determined by the computer, wherein the authenticity of the decrypted third symmetric key is determined based on a first comparison of the tag bits of the node with the tag bits created during encryption of the second symmetric key, and based on a second comparison of the AAD of the node with the AAD used in encryption of the second symmetric key.

13. The computer program product according to claim 12, wherein: In response to determining in the first comparison that the AAD of the node matches the AAD used in encryption of the second symmetric key, and determining in the second comparison that the tag bits of the node match the tag bits created during encryption of the second symmetric key, the decrypted third symmetric key is determined to be authentic.

14. The computer program product according to claim 13, wherein the program instructions can be read and / or executed by the computer to cause the computer to: In response to determining that the decrypted third symmetric key is authentic, decrypting the encrypted value data of the key-value pair using the decrypted third symmetric key; and A validation operation is performed on the received node-related data.

15. The computer program product of claim 13, wherein: The third symmetric key is the second symmetric key.

16. The computer program product of claim 13, wherein: In response to determining in the first comparison that the AAD of the node does not match the AAD used in encryption of the second symmetric key and / or determining in the second comparison that the tag bits of the node do not match the tag bits created during encryption of the second symmetric key, the decrypted third symmetric key is determined to be untrustworthy, and the program instructions are readable and / or executable by the computer to cause the computer to: in response to determining that the decrypted third symmetric key is untrustworthy, the computer does not use the decrypted third symmetric key to decrypt the encrypted value data of the key-value pair; and output a warning that the received node-related data authentication failed.

17. The computer program product of claim 11, wherein: Securely loading the first symmetric key into the HSM by the key management service prior to encryption of the second symmetric key comprises: Loading the encrypted instance key encryption key IKEK of the database into the HSM, decrypting the encrypted IKEK in the HSM using the master key encryption key MKEK of the HSM, loading the first symmetric key from the database to the HSM, wherein the first symmetric key is encrypted in the database, and The encrypted first symmetric key is decrypted using the decrypted IKEK.

18. The computer program product of claim 11, wherein: Advanced Encryption Standard AES-GCM encryption with Galois / Counter Mode is used to encrypt the second symmetric key.

19. The computer program product according to claim 11, wherein the program instructions can be read and / or executed by the computer to enable the computer to: execute a verifier of a provable trusted execution environment TEE by the computer to verify the node-related data in a cloud computing environment within the TEE.

20. A system comprising: processor; as well as Logic integrated with the processor, executable by the processor, or integrated with the processor and executable by the processor, the logic being configured to: Using the first symmetric key to encrypt the second symmetric key, Wherein, before the encryption of the second symmetric key, the first symmetric key is securely loaded into the hardware security module HSM by the key management service, wherein the cloud provider has access only to the encrypted bits of the first symmetric key; wherein the key data of the key-value pair of the second symmetric key is used as additional authentication data AAD for encryption of the second symmetric key; encrypting the value data of the key-value pair using the second symmetric key; and The encrypted second symmetric key, the AAD used in the encryption of the second symmetric key, and the tag bits created during the encryption of the second symmetric key are stored for later use in verifying node-related data.

Images