Data validation method and system for protecting node-related data

Abstract

A data validation method and system for protecting node-related data includes first encrypting a second symmetric key using a first symmetric key, which is securely loaded into a hardware security module (HSM) by a key management service prior to the encryption of the second symmetric key, and a cloud provider has access to only 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 the encryption of the second symmetric key. Value data of the key-value pair is then encrypted using the second symmetric key. The encrypted second symmetric key, the AAD used for the encryption of the second symmetric key, and tag bits created during the encryption of the second symmetric key are then stored for later use in validating node-related data.

Description

[Background technology]

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

[0002] Cryptography is the science of encoding with the goal of keeping data secret. Public and private keys are the fundamental concepts of public key cryptography, which is also sometimes called asymmetric cryptography. In public key cryptography, every public key matches 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 documents 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] According to one embodiment, a computer-implemented method includes encrypting a second symmetric key using a first symmetric key, the first symmetric key being securely loaded into a hardware security module (HSM) by a key management service prior to the encryption of the second symmetric key, and a cloud provider having access to only the encrypted bits of the first symmetric key. Key data of a key-value pair of the second symmetric key is used as additional authenticated data (AAD) for the encryption of the second symmetric key. Encrypting value data of the key-value pair using the second symmetric key. The method further includes storing the encrypted second symmetric key, the AAD used for the encryption of the second symmetric key, and tag bits created during the encryption of the second symmetric key for subsequent use in verifying node-related data.

[0005] A computer program product according to another embodiment includes 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 perform the method described above.

[0006] According to another embodiment, a system includes a processor and logic integrated with, executable by, or integrated with and executable by the processor, the logic configured to perform the method described above.

[0007] Other aspects and embodiments of the present invention will become apparent from the following detailed description, taken in conjunction with the drawings, illustrating by way of example the principles of the invention. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 illustrates a cloud computing environment according to one embodiment of the present invention.

[0009] [Figure 2] 1 is a flowchart of a method according to one embodiment.

[0010] [Figure 3] 3 is a flowchart of various sub-operations of the method of FIG. 2;

[0011] [Figure 4A] 1 illustrates the progression of a client node registration process according to one embodiment. [Figure 4B] 1 illustrates the progression of a client node registration process according to one embodiment. [Figure 4C] 1 illustrates the progression of a client node registration process according to one embodiment. [Figure 4D] 1 illustrates the progression of a client node registration process according to one embodiment. [Figure 4E] 1 illustrates the progression of a client node registration process according to one embodiment. [Figure 4F] 1 illustrates the progression of a client node registration process according to one embodiment. [Figure 4G] 1 illustrates the progression of a client node registration process according to one embodiment. [Figure 4H] 1 illustrates the progression of a client node registration process according to one embodiment.

[0012] [Figure 5A] 4A-4H illustrate validation of registered nodes in the network of FIGS. 4A-4H according to one embodiment. [Figure 5B] 4A-4H illustrate validation of registered nodes in the network of FIGS. 4A-4H according to one embodiment. [Figure 5C] 4A-4H illustrate validation of registered nodes in the network of FIGS. 4A-4H according to one embodiment. [Figure 5D] 4A-4H illustrate validation of registered nodes in the network of FIGS. 4A-4H according to one embodiment. [Figure 5E]4A-4H illustrate validation of registered nodes in the network of FIGS. 4A-4H according to one embodiment. [Figure 5F] 4A-4H illustrate validation of registered nodes in the network of FIGS. 4A-4H according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0013] The following description is made for the purpose of illustrating the general principles of this invention and is not meant to limit the inventive concepts claimed herein. Moreover, particular features described herein can be used in combination with other described features, in each of the various possible combinations and permutations.

[0014] Unless otherwise specifically defined herein, all terms are to be given their broadest possible interpretation, including the meaning implied by this specification and the meaning understood by a person skilled in the art and / or defined in dictionaries, treatises, etc.

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

[0016] The following description discloses several preferred embodiments that authenticate and secure key-value data pairs for protecting node-related data that is then verified using the key-value data pairs.

[0017] In one general embodiment, a computer-implemented method includes encrypting a second symmetric key using a first symmetric key. The first symmetric key has been securely loaded into a hardware security module (HSM) by a key management service prior to the encryption of the second symmetric key, and a cloud provider has access to only 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 the encryption of the second symmetric key. Encrypting value data of the key-value pair using the second symmetric key. The method further includes storing the encrypted second symmetric key, the AAD used for the encryption of the second symmetric key, and 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 therein, the program instructions being readable and / or executable by a computer to cause the computer to perform the method described above.

[0019] In another general embodiment, a system includes a processor and logic integrated with, executable by, or integrated with and executable by the processor, the logic configured to perform the method described above.

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

[0021] A computer program product embodiment ("CPP embodiment" or "CPP") is a term used in this disclosure to describe any set of one or more storage media (also referred to as "media"), collectively contained in one or more storage devices, that collectively contain 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. The computer-readable storage medium may be, but is not limited to, 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 diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanically encoded device (such as a punch card or pits / lands formed on 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, is not to be construed as storage in the form of a transient signal per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide, light pulses passing through fiber optic cables, electrical signals transmitted through wires, and / or other transmission media. As one skilled in the art will appreciate, data is typically moved at some infrequent time during the normal operation of the storage device, such as during access, defragmentation, or garbage collection, but the above does not qualify a storage device as transient because the data is not transient while it is stored.

[0022] Computing environment 100 includes an example environment for the execution of at least some of the computer code involved in performing the method of the present invention, such as the code of the present invention in block 200 for authenticating and securing key-value data pairs for protecting node-related data that is subsequently verified using the key-value data pairs. In addition to block 200, computing environment 100 includes, for example, computer 101, wide area network (WAN) 102, end user device (EUD) 103, remote server 104, public cloud 105, and private cloud 106. In this embodiment, computer 101 includes processor set 110 (including processing circuitry 120 and cache 121), communications fabric 111, volatile memory 112, persistent storage 113 (including operating system 122 and block 200 shown above), peripheral device set 114 (including user interface (UI) device set 123, storage 124, and Internet of Things (IoT) sensor set 125), and network module 115. Remote server 104 includes remote database 130. The public cloud 105 includes a gateway 140, a cloud orchestration module 141, a set of host physical machines 142, a set of virtual machines 143, and a set of containers 144.

[0023] Computer 101 may take the form of a desktop computer, a laptop computer, a tablet computer, a smartphone, a smartwatch or other wearable computer, a mainframe computer, a quantum computer, or any other form of computer or mobile device now known or later developed that is capable of executing programs, accessing a network, or querying a database, such as remote database 130. As is well understood in the field of computer technology, and depending on the technology, the performance of a computer-implemented method may be distributed among multiple computers and / or multiple locations. However, in this description of computing environment 100, for purposes of brevity, the detailed discussion focuses on a single computer, specifically computer 101. Although computer 101 is not depicted in FIG. 1 within a cloud, it may be located within a cloud. However, computer 101 is not required to reside within a cloud except to any extent expressly indicated.

[0024] Processor set 110 includes one or more computer processors of any type now known or later developed. Processing circuitry 120 may be distributed across multiple packages, e.g., multiple linked integrated circuit chips. Processing circuitry 120 may implement multiple processor threads and / or multiple processor cores. Cache 121 is memory located within the processor chip package and is typically used for data or code that should be available for fast access by threads or cores executing on processor set 110. Cache memory is typically organized into multiple levels depending on relative proximity to the processing circuitry. Alternatively, some or all caches for a processor set may be located “off-chip.” In some computing environments, processor set 110 may be designed to operate with qubits and perform quantum computing.

[0025] Computer-readable program instructions are typically loaded onto computer 101 to cause processor set 110 of computer 101 to perform a series of operational steps, thereby implementing a computer-implemented method, such that the instructions so executed instantiate the method specified in the flowcharts and / or descriptions of the computer-implemented method contained herein (collectively referred to as the "methods 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 associated data are accessed by processor set 110 to control and direct the execution of the methods of the present invention. In computing environment 100, at least some of the instructions for implementing the methods of the present invention may be stored in block 200 within persistent storage 113.

[0026] Communications fabric 111 is the signal-conducting pathway that allows various components of computer 101 to communicate with one another. Typically, this fabric is made up of switches and conductive pathways, such as switches and conductive pathways that make up buses, bridges, physical input / output ports, etc. Other types of signal communication pathways may be used, such as fiber optic and / or wireless communication pathways.

[0027] Volatile memory 112 may be any type of volatile memory now known or later developed. Examples include dynamic random access memory (RAM) or static RAM. Typically, volatile memory 112 is characterized by random access, although this is not required unless expressly stated. In computer 101, volatile memory 112 is located in a single package and is internal to computer 101; however, alternatively or additionally, volatile memory may be distributed across multiple packages and / or located external to computer 101.

[0028] Persistent storage 113 is any form of non-volatile storage for a computer, now known or later developed. The non-volatility of this storage means that stored data remains regardless of whether power is supplied to computer 101 and / or directly to persistent storage 113. While persistent storage 113 may be read-only memory (ROM), typically at least a portion of persistent storage allows data to be written, data to be deleted, and data to be rewritten. Some well-known forms of persistent storage include magnetic disks and solid-state storage devices. Operating system 122 may take several forms, such as various known proprietary operating systems employing a kernel or open-source Portable Operating System Interface-type operating systems. The code contained in block 200 typically includes at least some of the computer code involved in performing the methods of the present invention.

[0029] Peripheral device set 114 includes the set of peripheral devices of computer 101. Data communication connections between peripheral devices and other components of computer 101 may be implemented in various forms, such as Bluetooth connections, near field communication (NFC) connections, connections made by cables (such as universal serial bus (USB)-type cables), insertion-type connections (e.g., Secure Digital (SD) cards), connections made through local area communication networks, and even connections made through wide area networks such as the Internet. In various embodiments, UI device set 123 may include components such as display screens, speakers, microphones, wearable devices (such as goggles and smartwatches), keyboards, mice, printers, touchpads, game controllers, and haptic devices. Storage 124 may be external storage, such as an external hard drive, or insertable storage, such as an SD card. Storage 124 may be persistent and / or volatile. In some embodiments, storage 124 may take the form of a quantum computing storage device for storing data in the form of qubits. In embodiments where computer 101 is required to have a large amount of storage (e.g., where computer 101 stores and manages large databases locally), this 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. IoT sensor set 125 consists of sensors used in Internet of Things applications. For example, one sensor may be a thermometer and another sensor may be a motion detector.

[0030] Network module 115 is a collection of computer software, hardware, and firmware that enables computer 101 to communicate with other computers over WAN 102. Network module 115 may include hardware such as a modem or Wi-Fi signal transceiver, software for packetizing and / or depacketizing data for communication network transmission, and / or web browser software for communicating data over the Internet. In some embodiments, the network control and network forwarding functions of network module 115 are performed on the same physical hardware device. In other embodiments (e.g., embodiments utilizing Software-Defined Networking (SDN)), the control and forwarding functions of network module 115 are performed on physically separate devices, such that the control function manages several different network hardware devices. Computer-readable program instructions for performing the methods of the present invention may be downloaded to computer 101 from an external computer or external storage device, typically through a network adapter card or network interface included in network module 115.

[0031] WAN 102 is any wide area network (e.g., the Internet) capable of communicating computer data over non-local distances using any technology for communicating computer data now known or later developed. In some embodiments, WAN 102 may be replaced and / or supplemented by a local area network (LAN) designed to communicate data between devices located in a local area, such as a Wi-Fi network. WANs and / or LANs typically include copper transmission cables, optical fiber transmissions, wireless transmissions, and computer hardware such as 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 the enterprise operating computer 101) and may take any of the forms described above in connection with computer 101. EUD 103 typically receives useful and useful data from the operation of computer 101. For example, in the hypothetical case where computer 101 is designed to provide recommendations to end users, the recommendations would typically be communicated from computer 101's network module 115 over WAN 102 to EUD 103. In this manner, EUD 103 can 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, and the like.

[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 useful 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, then this historical data may be provided to computer 101 from remote database 130 of remote server 104.

[0034] A 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 functionality, particularly data storage (cloud storage) and computing capacity, without direct active management by users. Cloud computing typically leverages resource sharing to achieve consistency and economies of scale. Direct active management of the computing resources of the public cloud 105 is performed by the computer hardware and / or software of a cloud orchestration module 141. The computing resources provided by the public cloud 105 are typically implemented by virtual computing environments running on various computers comprising a host physical machine set 142, which is the universe of physical computers within and / or available to the public cloud 105. The 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 is understood that these VCEs may be stored as images and transferred among and between various physical machine hosts, either as images or after instantiation of the VCEs. Cloud orchestration module 141 manages the transfer and storage of images, deploys new instantiations of VCE, and manages active instantiations of VCE deployments. Gateway 140 is a collection of computer software, hardware, and firmware that enables public cloud 105 to communicate over WAN 102.

[0035] Some further description of virtualized computing environments (VCEs) is now provided. A VCE can be stored as an "image." A new, active instance of a VCE can be instantiated from an image. Two well-known types of VCEs are virtual machines and containers. A container is a VCE that uses operating system-level virtualization. This refers to a feature of an operating system in which the kernel allows the existence of multiple isolated user space instances, called containers. These isolated user space instances typically behave as actual computers from the perspective of programs running within them. A computer program running on a typical operating system can utilize all of the computer's resources, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, a program running inside a container can only use the contents of the container and the devices assigned to that container; this feature is known as containerization.

[0036] A private cloud 106 is similar to a public cloud 105, except that its computing resources are available only for use by a single enterprise. While the private cloud 106 is shown in communication with the WAN 102, in other embodiments, the private cloud may be completely disconnected from the Internet and accessible only through a local / private network. A hybrid cloud is a composite of multiple clouds of different types (e.g., private, community, or public cloud types), often implemented by different vendors. While each of the multiple clouds remains a separate, discrete entity, the larger hybrid cloud architecture is bound together by standardized or proprietary technologies that enable orchestration, management, and / or data / application portability between the constituent clouds. In this embodiment, both the public cloud 105 and the private cloud 106 are part of a larger hybrid cloud.

[0037] In some aspects, systems according to various embodiments may include a processor and logic integrated with and / or executable by the processor, the logic configured to perform one or more of the process steps described herein. The processor may be of any configuration described herein, such as a discrete processor or processing circuitry including numerous components, such as processing hardware, memory, I / O interfaces, etc. "Integrated with" means that the processor has logic embedded therein as hardware logic, e.g., an application-specific integrated circuit (ASIC), FPGA, etc. "Executable by a processor" means that the logic is hardware logic, software logic, e.g., firmware, part of an operating system, part of an application program, etc., or some combination of hardware and software logic accessible by the processor and configured to cause the processor to perform some function when executed by the processor. As known in the art, software logic may be stored in any memory type, local and / or remote memory. Any processor known in the art may also be used, such as a software processor module and / or a hardware processor, e.g., an ASIC, FPGA, central processing unit (CPU), integrated circuit (IC), graphics processing unit (GPU), etc.

[0038] As mentioned elsewhere above, cryptography is the science of secret writing with the goal of keeping data secret. Public and private keys are the basic concepts of public key cryptography, which is also sometimes called asymmetric cryptography. In public key cryptography, every public key matches 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 mostly 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, signature algorithms are based on asymmetric cryptography, which is slow compared to symmetric cryptography. Also, using hardware security modules (HSMs) for signing purposes is difficult because HSM firmware usually does not allow the private key to be extracted from the HSM, which severely limits the number of keys that can be used due to memory limitations of the HSM.

[0040] In stark contrast to the above drawbacks, the various embodiments and techniques described herein verify the authenticity of data by both the client and the cloud provider with a root of trust firmly established within the HSM, which is an inherently more flexible and relatively more performant alternative to using asymmetric key-based signatures by leveraging symmetric keys and performing all security-related operations within the HSM while maintaining full cloud-scale scalability.

[0041] Referring now to Figure 2, a flowchart of a method 300 according to one embodiment is shown. Method 300 may be performed by the present invention in various embodiments, particularly in any of the environments shown in Figures 1-5F. Of course, more or fewer operations than those specifically illustrated in Figure 2 may be included in method 300, as will be understood by those skilled in the art upon reading this specification.

[0042] Each of the steps 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, preferably having at least one hardware component, may be utilized in any device to perform one or more steps of method 300. Exemplary processors include, but are not limited to, a central processing unit (CPU), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or the like, combinations thereof, or any other suitable computing device known in the art.

[0043] The techniques of method 300 may be prefaced with a preparation phase for node measurement, and may be used to authenticate any data that has a trust anchor within the HSM. More specifically, various of these techniques may be used to authenticate and secure key-value data pairs for protecting node-related data, which is then verified using the key-value data pairs. The key in such authentication is not revealed, which is in stark contrast to public-key authentication, which posts a public key to a location. In some approaches, from a high-level perspective, authentication in method 300 may first include initiating an environment, or if authentication is performed as a service, method 300 may first include initiating a verification device. Next, a client, e.g., a client device, may be registered. In approaches where multiple tenants / clients use such a service, multiple clients are registered. A compute node may then be registered for each client. Once this process is complete, the authenticity of the information registered in these described steps may be verified.

[0044] Techniques described in further detail in various operations of method 300 include a description of how a client device can check the authenticity of a Trusted Platform Module (TPM) (or any other data) public key to reduce the level of trust required in the verification device. Instead of the verification device requesting a key management service (KMS), such as IBM's key protect (KP), the CRK can be imported directly into the HSM to generate a fresh (random) client root key (CRK) for the client. Although the bits of the CRK are defined by the client, these bits are preferably not seen in the plain by the verification device. The client device may also have a KMS instance, and the client device may import the same CRK bits into its own instance that was provided to the verification device (as described above) for the verification device's KMS instance. Both the verification device and the client device then have access to the CRK bits inside their respective HSMs. The client device may request the verifier to provide the wrapped symmetric key, e.g., the wDEK, and the corresponding tag bits, initialization vector (IV), and additional authentication data (AAD) for the particular node (or the public key and IP address to recreate the AAD field). In this manner, a command may be issued to the client device's KMS instance to unwrap the wrapped symmetric key by the client device. If successful, the client device knows that an authentic public key for the particular node is being used. Various exemplary approaches that explain these techniques in further detail are described below; see, for example, acts 302-328 of method 300.

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

[0046] In some approaches, the first symmetric key resides in an encrypted state in the KMS database. Also, in some approaches, the cloud provider may only have access to the encrypted bits of the first symmetric key. Accordingly, in some approaches, the first symmetric key may be decrypted in the process of being securely loaded into the HSM. In some approaches, the process of securely loading the first symmetric key into the HSM may include loading an encrypted instance key encryption key (IKEK) from the KMS database into the HSM to assist in the process of unwrapping and / or decrypting the encrypted first symmetric key. Note that in other approaches, the IKEK may optionally reside in a wrapped or decrypted state in the KMS database. In approaches where an encrypted IKEK is loaded into the HSM, the HSM's master key encryption key (MKEK) may be used to unwrap and / or decrypt the encrypted IKEK in the HSM (e.g., see operation 304). Note that in some approaches, decryption essentially amounts to an unwrap command being executed. The MKEK may be pre-loaded onto the HSM and serves as the HSM master key. Verification devices are "linked" to the HSM via the IKEK. In some approaches, the IKEK is a key that the KMS automatically generates for each instance and securely stores in the KMS database. In some approaches, the IKEK is wrapped by the MKEK, and the MKEK is securely pre-loaded into all HSMs in the KMS.

[0047] Once decrypted, the unwrapped and / or decrypted IKEK may be used to load the encrypted first symmetric key from the database into an HSM (see, e.g., operation 306). More specifically, in some approaches, the unwrapped and / or decrypted IKEK is used to decrypt, e.g., unwrap, the encrypted first symmetric key (see, e.g., operation 308), and the IKEK may then be loaded into an HSM for use in the decryption process. Techniques that will be apparent to those skilled in the art upon reading the description herein may be utilized to encrypt and decrypt keys in a KMS database.

[0048] Operation 310 includes encrypting a second symmetric key using the decrypted first symmetric key. In one preferred approach, Advanced Encryption Standard with Galois / Counter Mode (AES-GCM) encryption is used to encrypt the second symmetric key. As described in more detail elsewhere herein, the encryption of the second symmetric key is “authenticable” encryption because, in some preferred approaches, the second symmetric key is ultimately used to ensure the authenticity of a client node registering with a TEE in communication with the HSM. Thus, encrypting the second symmetric key using the decrypted first symmetric key enables authenticated encryption with associated data compared before and after encryption (see, e.g., FIG. 3 ). One or more types of key data used to generate the unencrypted second symmetric key prior to encryption of the second symmetric key, e.g., information about the client node registering with the verification device, may be used by the first symmetric key during encryption of the second symmetric key. In one preferred approach, the key data (or a hash thereof) of the key-value pair of the second symmetric key is used as additional authentication data (AAD) for the encryption of the second symmetric key. In some approaches, all encryption and decryption described in various embodiments and / or approaches described herein, such as the encryption used for the second symmetric key, may be authenticated encryption with associated data (AEAD) cryptography. In some approaches, the key data may include a hash, e.g., a SHA256 hash, of node information, e.g., a public key, IP address, etc. In some approaches, the key data may additionally and / or alternatively include a hash, e.g., a SHA256 hash, of a random number. The information may additionally and / or alternatively include an appropriately selected IV, e.g., a random IV, using one or more predetermined known techniques. Plain bits of the unencrypted second symmetric key may also be available.Additionally, because the AAD resides in the verification device, the tag bits may be created using an encrypted second symmetric key, e.g., created during AES-GCM encryption of an unencrypted second symmetric key. In some approaches, symmetric cryptography may be used for encryption and / or decryption, e.g., one shared secret key is used for encryption and decryption.

[0049] In some approaches, secret information, e.g., node-related information, may be received from the client device's node. Note that this node is preferably the same node on which the AAD is based. For example, such secret information may include, e.g., a client key share, a predetermined Trusted Platform Module (TPM) (authorization) secret, the node's configuration, a signing key, etc. Once encrypted, this secret information may be stored as "value data" and injected into the TPM. In some approaches, an unencrypted second symmetric key is used to authentically encrypt the value data of the key-value pair (e.g., see operation 312). Once encrypted, the value data may be securely stored within the associated client file in a database of known type. Additionally, in some approaches, the value data may be encrypted with the unencrypted second symmetric key, followed by encryption of the second symmetric key with the first symmetric key.

[0050] Operation 314 includes storing the encrypted second symmetric key, the AAD used to encrypt the second symmetric key, and tag bits created during the encryption of the second symmetric key. In some approaches, an IV may additionally and / or alternatively be stored in operation 314. For context, one or more of these types of information stored in operation 314 are stored as information about a particular node, e.g., the node on which the AAD is based. As described in further detail below, this stored information is used to verify node-related data after being stored (e.g., see operations 316-328). In some approaches, one or more types of information stored in operation 314 may be stored in a database managed by the verification device. In some other approaches, the information may additionally and / or alternatively be output to and stored on a client device. In yet another approach, the information may additionally and / or alternatively be stored in 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 approaches, method 300 includes registering several clients, and each such client may have one or several computing nodes. For each of these client computing nodes, some securely encrypted information may be stored using the techniques described above to register the node and enable the node to be subsequently verified (see, e.g., operations 316-328).

[0052] Node-related data for the node is received (e.g., see operation 316). The node-related data may, in some approaches, be received by the verifier from a client device registered with the verifier. According to some approaches, 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 node's tag bits. Further, the node-related data may additionally and / or alternatively include the node's AAD, which, in some approaches, is determined by a hash, e.g., a SHA256 hash, other information in the node-related data, e.g., an IP address, public key information, etc. In some approaches, the node-related data may be received along with a request to access encrypted value data of a key-value pair. In other approaches, the node-related data may additionally and / or alternatively be received from an associated node along with a request to be authenticated.

[0053] The first symmetric key is used, in some approaches, to decrypt an encrypted third symmetric key associated with the node-related data (see, e.g., operation 318). Note that the encrypted third symmetric key may actually be the encrypted second symmetric key, but is referred to herein as the "encrypted third symmetric key" for terminology purposes because authenticity has not yet been satisfied (see, e.g., operations 320-328).

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

[0055] With continued reference to FIG. 3 , in some approaches, the authenticity of the decrypted third symmetric key is determined by one or more comparisons. In one such approach, the authenticity of the decrypted third symmetric key may be determined based on a first comparison of the node's tag bits with the tag bits created during the encryption of the second symmetric key. For example, sub-operation 330 includes determining whether the node's tag bits match the tag bits created during the encryption of the second symmetric key. In some approaches, in response to a determination that the node's tag bits match the tag bits created during the encryption of the second symmetric key, e.g., as indicated by a “yes” logical path of sub-operation 330, a second comparison may optionally be performed to determine the authenticity of the decrypted third symmetric key. The second comparison may, in some approaches, be a comparison of the node's AAD with the AAD used to encrypt the second symmetric key. For example, sub-operation 332 includes determining whether the node's AAD matches the AAD used to encrypt the second symmetric key. In response to a determination in the first comparison that the node's AAD does not match the AAD used to encrypt the second symmetric key, e.g., as indicated by the “NO” logical path of sub-operation 332, and / or a determination in the second comparison that the node's tag bits do not match the tag bits created during the encryption of the second symmetric key, e.g., as indicated by the “NO” logical path of sub-operation 330, a determination may be made that the decrypted third symmetric key is not authentic. More specifically, a determination that the decrypted third symmetric key is not authentic may include a determination that the tag bits and / or AAD do not match, and therefore the decrypted third symmetric key is not the second symmetric key. In response to a determination that the decrypted third symmetric key is not authentic, the method optionally continues down the “NO” logical path of decision 320 (see, e.g., FIG. 2 ). In some approaches, in response to determining that the decrypted third symmetric key is not authentic, 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).Additionally and / or alternatively, a warning may be output that the received node-related data failed authentication (see, e.g., operation 324). In one approach, a warning is output to the verifier's administrator device indicating that the node is attempting to improperly access key-value pair encrypted data.

[0056] Referring again to FIG. 3 , in response to a determination in the first comparison that the node's AAD matches the AAD used to encrypt the second symmetric key and / or a determination in the second comparison that the node's tag bits match the tag bits created during the encryption of the second symmetric key, the decrypted third symmetric key may be determined to be authentic (e.g., see the “yes” logic path of decision 320), e.g., as indicated by the “yes” logic path of sub-operations 330 and 332 following to operation 326. Referring now to FIG. 2 , operation 326, in response to a determination that the decrypted third symmetric key is authentic, includes decrypting the encrypted value data of the key-value pair using the decrypted third symmetric key, e.g., authenticated here to be in fact the second symmetric key. Decrypting the encrypted value data of the key-value pair may, in some approaches, include a process including loading pre-stored encrypted data into a verification device and decrypting the encrypted data using the decrypted third symmetric key, e.g., the plain DEK. With access to the node-associated data obtained as a result of decrypting the encrypted data, one or more known types of verification operations may be performed on the received node-associated data and / or the decrypted data (e.g., see operation 328).

[0057] Note that in some approaches, the value data of the key-value pair is encrypted by a verifier having predefined verifier program code. Accordingly, in some approaches where the verifier is configured to execute the verifier program code, method 300 may optionally include running the verifier to verify the node-related data. In some approaches, this may be accomplished in a cloud computing environment, for example, within a trusted execution environment (TEE), such as a provable enclave. Note that the verifier may verify the code but may not verify the TEE. Instead, attestation is a technique for checking the integrity of the TEE, while the verifier is executed to verify the node-related data.

[0058] Authenticating and securing key-value data pairs to protect node-related data that is subsequently verified using the key-value data pairs has not previously been considered in conventional data authenticity techniques. As noted elsewhere above, this is because conventional signature algorithms are instead based on asymmetric cryptography, which is relatively slow when compared to symmetric cryptography. Furthermore, using conventional HSMs for signing purposes is difficult because the firmware in conventional HSMs typically does not allow private keys to be extracted from the HSM, which severely limits the number of keys used due to HSM memory limitations. Accordingly, numerous advantages are possible as a result of using various of the techniques described herein to protect node-related data. For example, the cryptography described herein is relatively faster because symmetric cryptography is used instead of asymmetric cryptography. This results in relative improvements to the efficiency of computer systems implementing the techniques of the various embodiments and approaches described herein. Note that these possible relative efficiencies do not come at the expense of reduced security in the techniques described herein. This is because the authenticity of the key is assured before the encrypted node-related data is encrypted to perform the verification task. Accordingly, the inventive findings disclosed herein regarding the use of authenticated and secure key-value data pairs to protect node-related data that is subsequently verified using the key-value data pairs proceed in contrast to conventional wisdom.

[0059] 4A-4H illustrate a network 400 according to one embodiment. Optionally, the network 400 may be implemented in conjunction with features from any other embodiment enumerated herein, such as those described with reference to other figures. However, it should be understood that such a network 400, and others presented herein, may be used in various applications and / or permutations that may or may not be specifically described in the exemplary embodiments enumerated herein. Furthermore, the network 400 presented herein may be used in any desired environment.

[0060] Referring first to FIG. 4A , in one approach, a network 400 including a verification device can be started using a known startup process. Within the network 400, in one approach, the verification device is preferably run within a provable trusted execution environment (TEE), such as a secure service container (SSC) on a mainframe. The verification device may include predetermined program code (e.g., see verification device program code used to access the KMS of the network 400). In one approach, the KMS includes a KMS database (e.g., see KMS DB). According to some more specific approaches, the KMS may include a KMS service and / or another key management service (KMS) that handles one or more redundant keys, such as IBM's Key Protection (KP), which is one implementation of IBM's KMS. To access the KMS of the network 400, the verification device may include configuration data (e.g., see config and / or secret). In one approach, the configuration data may include the instance ID of the KMS instance, e.g., the KMS instance ID, which may more broadly be a pointer to where the instance key encryption key (IKEK) 402 is stored. In some approaches, the verifier's secret may include a token and / or credentials, such as KMS instance ID credentials, that enable access to the KMS.

[0061] In some approaches, the verification device maintains a client list, which is a database that is initially empty (see, e.g., Client List (Empty)). In some approaches, at verification device startup, the client list is empty, but the client list may eventually be populated with information 404, such as client IDs, client-associated metadata 410 such as billing information, client-associated metadata such as email addresses, other known types of client-associated metadata, etc. Information 404 may additionally and / or alternatively include pointers to client file names of files maintained in a different database, e.g., some database other than the database that stores client list information 404.

[0062] At this point, it can be assumed that the verification device is up and running and that there are no clients yet in its client list. It can also be assumed that the KMS (see, e.g., KMS HSM) is running and contains a loaded master key encryption key (MKEK) 406. In one approach, the MKEK 406 is a key that originates internally to the KMS HSM and is not otherwise seen outside the KMS HSM. In another approach, the MKEK 406 is additionally and / or alternatively pre-loaded onto the KMS HSM and serves as the HSM master key. Additionally, because the KMS is itself multi-tenant, the IKEK 402 is owned by the verification device, but the IKEK 402 is encrypted in the KMS database by the MKEK 406.

[0063] Finally, arrows to / from the nodes point to the IP addresses of computational nodes on which the client aims to later perform measurements of known types in order to verify the node, however, the node is not yet connected at this stage because the information used to perform such measurements is not available at the start-up of the verifier.

[0064] In one approach, a network requirement may be, for example, that a verifier be running in the TEE if the client device is capable of performing TEE attestation. The requirement may additionally and / or alternatively include the verifier owning a KMS instance. The requirement may additionally and / or alternatively include the verifier having a key-value store containing a key, e.g., clientID, with a value CRK_keyID (entered later), stored with a client list, e.g., client_list.

[0065] 4B, a request to register with a verification device may be received from a client device (e.g., see client list), e.g., to register with a verification device service associated with the verification device. In some approaches, the request includes information associated with the requesting client device, e.g., ClientID, client data, etc. The requesting client is assigned a client file name 408, e.g., ClientID_1, where all files for that particular client are located. As shown in FIG. 4B, in one approach, the client file name 408 may be stored in a second database, e.g., a client file. In another approach, the client file name 408 may additionally and / or alternatively be stored in a first database (e.g., see client list). According to various approaches, the client file may include information, e.g., the clientID, the number of nodes the client has and wishes to verify, a list of NodeIDs, etc.

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

[0067] 4C , the process by which a client node is registered with the network 400 is shown according to one approach. While operation is described in FIG. 4C for illustrative purposes with respect to a client's first node having ClientID_1, it should be noted that additional clients (e.g., see a second client 414 assigned client ID Client_2 and an Nth client 416 assigned client ID Client_N) may be registered with the verification device. It should also be noted that each client file may include metadata and a node list 436, with each node list entry including metadata and a secret / encrypted JSON 438. It is envisioned that the first node will feature information including the first node's IP address (e.g., see IP_address[nodeID_n]) and public key (e.g., PubKey[nodeID_n]), which will ultimately be used to verify any measurement data generated and signed within the node (e.g., see From / To Node). Such information is provided to a verification device (see, e.g., operation 418), which creates a hash, such as a SHA256, that is ultimately used as additional authentication data (AAD) for symmetric encryption operations described in more detail elsewhere herein.

[0068] The process by which a client node registers with a verifier in network 400 may additionally and / or alternatively include the verifier enabling the client to securely import a CRK into the verifier's KMS instance, e.g., in the sense of bringing their own key (e.g., CRK_keyID and clientID). The verifier may add the clientID and / or CRK_keyID to a client_list, and the verifier may create a key-value store for the clientID, e.g., on DISCO (see, e.g., node_list[clientID]).

[0069] 4D, the verification device generates a random number (see, e.g., #1). Entropy is generated in several ways. For example, a plain data encryption key (DEK) 420 may be generated by a SHA256 hash. Accordingly, the plain DEK 420 may be a 256-bit symmetric data encryption key.

[0070] For some optional techniques that utilize the Advanced Encryption Standard with Galois Counter Mode (AES-GCM) cryptography, a random initialization vector may be required (see, e.g., Random IV generated using random numbers).

[0071] 4E, the verification device issues a command for the KMS to load CRK 412 into the KMS HSM. In response, CRK 412 is loaded into the KMS HSM in operation 422. The IKEK is also loaded (e.g., see operation 424) and is decrypted and / or unwrapped (e.g., see D / U) by MKEK 406. The decrypted IKEK 426 is used to decrypt and / or unwrap the CRK (e.g., see decrypted CRK 428).

[0072] 4F, loading of CRK 412 into a KMS HSM may be accomplished according to the wrapDEK command. More specifically, in a first step, IKEK 402 is loaded from the KMS DB into the KMS HSM via unwrapping, e.g., decrypting, IKEK 402 using MKEK 406. In a next step, CRK 412 is loaded into the KMS HSM and unwrapped and / or decrypted using the unwrapped IKEK 426. The decrypted CRK 428 is then used to encrypt plain DEK 420 by considering the AAD and random IV, thereby establishing a wrapped DEK (see, e.g., wDEK 430), which is essentially a plain DEK encrypted with AES with Galois / Counter Mode (AES-GCM) using decrypted CRK 428, considering the AAD and random IV in doing so. The plain bits of the plain DEK are also available. Additionally, because the AAD is present on the verification device, tag_bits are also created by the wDEK during AES-GCM encryption, which can be used to double-check the encryption operation, as described in more detail elsewhere in this specification.

[0073] In some example approaches, the process of node registration may include a client device registering the node using an associated clientID. For example, the verifier may receive a public key, e.g., pub_key, node_id, from the node TPM, and the verifier obtains the node's IP address (e.g., see IP_address). In one such approach, the verifier may perform SHA256 or another similar known type of hash function using the PubKey and / or IP_address, e.g., authenticity_hash. In one optional approach, the verifier knows a unique final hash. In such an approach, if the final hash is not known, the verifier may use random numbers, e.g., hash_final, hash_final_known_bool. The verifier may also perform a wrapDEK operation at the KMS instance with plainDEK=hash_final, AAD=authenticity_hash, using the CRK_keyID for wrapping, e.g., wrappedDEK, tag_bits. The verifier then stores the key information, for example, node_id, value:[pub_key, IP_address, wrappedDEK, tag_bits] in node_list[clientID].

[0074] In some approaches, the client is linked to both the verification device and the HSM via the CRK (the CRK is stored by the KMS in wrapped form, and "loading" is equivalent to unwrapping the CRK into the HSM). To enable unwrapping, an IKEK is needed inside the HSM, which links the CRK to the IKEK and it to the verification device.

[0075] At operation 432 of Figure 4G, the IV_bits, wDEK 430, and tag_bits resulting from the encryption are stored as information associated with a particular node (see, e.g., node[nodeID]). In some approaches, such information is preferably stored in a database managed by the verifier. In some other approaches, the information may be output to and stored on the client device.

[0076] 4H, in operation 434, secret data may be received from a client device over network 400. For example, such secret data may include, for example, a client key share, a predetermined Trusted Platform Module (TPM) (authorization) secret, what the node configuration is, what the signing key is, etc. For example, such information may be node-related data that was loaded onto a verification device, encrypted using plain DEK 420, and securely stored inside an associated client file (e.g., see client file). Such secret information may be used by a client device to access a trusted platform module on a particular node. This is useful because it ensures that when a client device attempts to access a particular node, the access information associated with that node is securely authenticated, so that the client is not tricked into attempting to access a rogue node, e.g., another node masquerading as the actual operating node.

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

[0078] At this point, the verification device 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, some securely encrypted information exists. Various operations of network 400 may be used in Figures 5A-5F to verify nodes according to one embodiment.

[0079] 5A-5F illustrate the network 400 of FIGS. 4A-4H according to one embodiment. Specifically, in FIGS. 5A-5F, various operations are performed to verify nodes registered in the network 400 of FIGS. 4A-4H. Optionally, the network 400 may be implemented in conjunction with features from any other embodiment enumerated herein, such as those described with reference to other figures. However, it should be understood that such a network 400, and others presented herein, may be used in various applications and / or permutations that may or may not be specifically described in the exemplary embodiments enumerated herein. Furthermore, the network 400 presented herein may be used in any desired environment.

[0080] 5A, it may be assumed that the verifier is up and running, with a client file and client registered on network 400. Node 502's node data, e.g., nodes[nodeID_n], may include any predetermined identification information for the node, such as the node's IP address, the node's public key, any one or more types of information used to register the node with the verifier, etc. In operation 504, the node's node information is loaded into the verifier. Because the node is a registered node and not a rogue node, a hash of the information (e.g., see Hash) returns an AAD that matches the AAD of the client associated with the node. The AAD is regenerated on the fly accordingly.

[0081] Referring now to FIG. 5B, in operation 506, the encrypted DEK, IV bits, and tag bits generated in the enrollment operation described in FIGS. 4A-4H are reloaded onto the verification device.

[0082] 5C, a command is issued by the verification device to the KMS to load CRK 412 onto the KMS HSM (see, e.g., the loadCRK command). In operations 508 and 510, the encrypted IKEK 402 and encrypted CRK 412 are decrypted and reloaded onto the KMS HSM. The techniques used to load and decrypt the encrypted IKEK 402 and encrypted CRK 412 onto the KMS HSM (see, e.g., operations 424 and 422) may be utilized to reload and decrypt the encrypted IKEK 402 and encrypted CRK 412 onto the KMS HSM (see, e.g., operations 508 and 510).

[0083] 5D, following reloading and decrypting encrypted IKEK 402 and encrypted CRK 412 on the KMS HSM, a command is issued to decrypt wDEK 430, for example, via the unwrapDEK command. The plain DEK is produced by performing the unwrapDEK command on wDEK 430.

[0084] In a preferred approach, a determination that the operation is successful is made if the tag bits of node 502 match, e.g., are substantially the same as, the tag bits generated during node registration, e.g., the tag bits resulting from execution of the wrapDEK command in FIG. 4F. Note that without possession and / or knowledge of the information used to previously wrap the plain DEK during node registration, wDEK 430 cannot be unwrapped pursuant to the unwrapDEK command in FIG. 5D. Accordingly, if the tag bits of node 502 match the tag bits generated during node registration, the operation may be determined to be successful. In contrast, if the tag bits of node 502 do not match the tag bits generated during node registration, the operation may be determined to be unsuccessful.

[0085] 5E, assuming that the bits are determined to match, it may be determined that access to the plain bits of the data encryption key, e.g., the bits of plain DEK 420, has again been obtained. This means that the previously encrypted node-related data is loaded and decrypted using the bits of plain DEK 420. For example, referring now to FIG. 5E, node-related data previously encrypted using the bits of the plain DEK (e.g., see EncryptedData[nodeID_n]) is loaded onto the verification device in operation 512. Referring now to FIG. 5F, the node-related data is decrypted using the bits of plain DEK 420 (e.g., see the obtained DecryptedData[nodeID]) in operation 514. At this point, it may be determined that the PubKey (e.g., see PubKey and IP_address) of node 502 with the specified IP address is authentic and has all the secret information needed to access the node. For example, such information may include the TPM (authorization) secret of node 502. As previously mentioned, because the wDEK was successfully decrypted, this information may be determined to be authentic. In response, the actual verification of the node may be performed. For example, in some approaches, one or more known types of node verification operations may be performed.

[0086] In one exemplary approach, a verifier may be used to perform node verification. For example, for every client ID, the verifier may retrieve node_list[clientID], CRK_keyID[clientID] from client_list. For every entry in node_list[clientID], a process may be performed that includes the verifier retrieving a signed hash, e.g., proposed_hash, hash_signature, from the node TPM. The process may additionally and / or alternatively include the verifier retrieving the [pub_key, IP_address, wrappedDEK, tag_bits] of the node_id from the key-value store. For the recreated_authenticity_hash, the verifier may perform a SHA256 hash using [PubKey||IP_address], or another similar known type of hash. Additionally, the verifier may perform a predefined unwrapDEK operation on the wrappedDEK, tag_bits, AAD=recreated_authenticity_hash at the KMS instance using the CRK_keyID for wrapping, e.g., plainDEK or failure. In response to a determination that a failure occurred, an alarm may be raised because the information does not match and the AES-GCM tag bit verification failed. In response to a determination that no failure occurred, the pub key may be used to check the hash_signature. In response to a determination that hash_final_known_bool==true, the verifier is instructed to check proposed_hash==plainDEK. The results of this check include success, e.g., OK, or failure. In response to a determination that the result is failure, an alarm is raised because the hashes do not match. In response to a determination that the result is not failure, the verification is complete. Note that the verifier does not always need to go to the HSM; instead, it may keep some results in TEE memory for execution.

[0087] In another exemplary approach, if the TPM hash, or even its SHA256 just to make it a valid AES256 key, is used as the plain bits of the DEK, then even this TPM hash can be authenticated and verified by the HSM. In some approaches, the AES-GCM encryption 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 IP address, public key, client, verification device [TPM hash], KMS HSM, etc. If it is determined that even a single bit has changed in any of these types of information, the decryption attempt will fail, making it clear that something is wrong.

[0088] It will be apparent that the various features of the above-described systems and / or methods may be combined in any manner, creating multiple combinations in accordance with the description presented above.

[0089] It will be further appreciated that embodiments of the present invention may also be provided in the form of a service that is deployed on behalf of a customer to provide the service on demand.

[0090] The description of various embodiments of the present invention has been presented for illustrative purposes and is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein has been selected to best explain the principles, practical applications, or technical improvements of the embodiments over art found in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. encrypting a second symmetric key using the first symmetric key; wherein the first symmetric key is securely loaded within a Hardware Security Module (HSM) by a key management service prior to the encryption of the second symmetric key; the cloud provider has access to only 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 the encryption of the second symmetric key; encrypting value data of the key-value pair using the second symmetric key; and storing the encrypted second symmetric key, the AAD used to encrypt the second symmetric key, and tag bits created during the encryption of the second symmetric key for subsequent use in verifying node-associated data; A computer-implemented method comprising:

2. receiving the node-associated data of a node, wherein the node-associated data includes tag bits of the node and an AAD of the node; decrypting, using the first symmetric key, an encrypted third symmetric key associated with the node-associated data; and determining 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 tag bits of the node with the tag bits created during the encryption of the second symmetric key, and based on a second comparison of the AAD of the node with the AAD used to encrypt the second symmetric key. The computer-implemented method of claim 1 , comprising:

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

4. 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 performing a verification operation on the received node-related data; The computer-implemented method of claim 3 , comprising:

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

6. 4. The computer-implemented method of claim 3, wherein in response to a determination in the first comparison that the AAD of the node does not match the AAD used to encrypt the second symmetric key and / or a determination 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, it is determined that the decrypted third symmetric key is not authentic, the computer-implemented method comprising, in response to a determination that the decrypted third symmetric key is not authentic, 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 failed authentication.

7. Securely loading the first symmetric key into the HSM by the key management service prior to the encryption of the second symmetric key, comprising: loading a database encrypted instance key encryption key (IKEK) into the HSM; decrypting the encrypted IKEK at the HSM using a Master Key Encryption Key (MKEK) of the HSM; loading the first symmetric key from the database into the HSM, wherein the first symmetric key is encrypted in the database; and decrypting the encrypted first symmetric key using the decrypted IKEK. The computer-implemented method of claim 1 , comprising:

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

9. 2. The computer-implemented method of claim 1, comprising executing a verifier of a provably trusted execution environment (TEE) to verify the node-related data in a cloud computing environment within the TEE.

10. 2. The computer-implemented method of claim 1, wherein the encryption of the second symmetric key is authenticated encryption with associated data (AEAD), and 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-readable storage medium having program instructions embodied thereon, the program instructions causing a computer to: encrypting, by the computer, a second symmetric key using the first symmetric key; wherein the first symmetric key is securely loaded within a Hardware Security Module (HSM) by a key management service prior to the encryption of the second symmetric key; the cloud provider has access to only 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 the encryption of the second symmetric key; encrypting, by the computer, value data of the key-value pair using the second symmetric key; and storing, by the computer, the encrypted second symmetric key, the AAD used to encrypt the second symmetric key, and tag bits created during the encryption of the second symmetric key, for subsequent use in verifying node-associated data. a computer program product readable and / or executable by said computer to cause said computer to perform

12. The program instructions cause the computer to: receiving, by the computer, the node-associated data for a node, wherein the node-associated data includes tag bits for the node and an AAD for the node; decrypting, by the computer, an encrypted third symmetric key associated with the node-associated data using the first symmetric key; and determining, by the computer, 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 tag bits of the node with the tag bits created during the encryption of the second symmetric key, and based on a second comparison of the AAD of the node with the AAD used to encrypt the second symmetric key.

12. The computer program product of claim 11, readable and / or executable by the computer to cause the computer to:

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

14. The program instructions cause the computer to: in response to determining that the decrypted third symmetric key is authentic, decrypting, by the computer, the encrypted value data of the key-value pair using the decrypted third symmetric key; and performing, by the computer, a verification operation on the received node-related data.

14. A computer program product according to claim 13, readable and / or executable by the computer to cause the computer to:

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

16. 14. The computer program product of claim 13, wherein in response to a determination in the first comparison that the AAD of the node does not match the AAD used to encrypt the second symmetric key and / or a determination 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, a determination is made that the decrypted third symmetric key is not authentic, the program instructions being readable and / or executable by the computer to cause the computer to: in response to a determination that the decrypted third symmetric key is not authentic, by the computer not using the decrypted third symmetric key to decrypt the encrypted value data of the key-value pair; and by the computer outputting a warning that the received node-related data failed authentication.

17. Securely loading the first symmetric key into the HSM by the key management service prior to the encryption of the second symmetric key, comprising: loading a database encrypted instance key encryption key (IKEK) into the HSM; decrypting the encrypted IKEK at the HSM using a Master Key Encryption Key (MKEK) of the HSM; loading the first symmetric key from the database into the HSM, wherein the first symmetric key is encrypted in the database; and decrypting the encrypted first symmetric key using the decrypted IKEK.

12. The computer program product of claim 11, comprising:

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

19. 12. The computer program product of claim 11, wherein the program instructions are readable and / or executable by the computer to cause the computer to execute a provably trusted execution environment (TEE) verifier to verify the node-related data in a cloud computing environment within the TEE.

20. a processor; and and logic integrated with, executable by, or integrated and executable by the processor, the logic comprising: encrypting a second symmetric key using the first symmetric key; wherein the first symmetric key is securely loaded within a Hardware Security Module (HSM) by a key management service prior to the encryption of the second symmetric key; the cloud provider has access to only 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 the encryption of the second symmetric key; encrypting the value data of the key-value pair using the second symmetric key; and storing the encrypted second symmetric key, the AAD used to encrypt the second symmetric key, and tag bits created during the encryption of the second symmetric key for subsequent use to verify node-associated data; The system is configured as follows:

Images