Patent Description:
Perfect forward secrecy refers to a feature that describes a means of preventing session keys from being compromised even if the private key of a server is compromised. To do so, protocols relating to perfect forward secrecy generate unique session keys for every session initiated by a user. If a session key is compromised, data exchanged outside of that particular session remains protected.

A virtual machine is an emulated computer system created using software. The virtual machines use physical system resources, such as the processor, random-access memory (RAM), and disk storage. While in operation, a virtual machine can be categorized as being within a type of operation state. These states include, but are not limited to, running, shutdown, suspended, and checkpoint/snapshot. Depending on the state of the virtual machine, session keys and other connection secrets can be either stored in memory, disk storage, or both.

United States Patent Application publication number <CIT>) discloses Sanitizing a virtual machine image of sensitive data. A label for a sensitivity level is attached to identified sensitive data contained within each software component in a plurality of software components of a software stack in a virtual machine image based on labeling policies. In response to receiving an input to perform a sanitization of the identified sensitive data having attached sensitivity level labels contained within software components of the software stack in the virtual machine image, the sanitization of the identified sensitive data having the attached sensitivity level labels contained within the software components of the software stack in the virtual machine image is performed based on sanitization policies.

<CIT>) discloses a checkpointing method for creating a file representing a restorable state of a virtual machine in a computing system, comprising identifying processes executing within the virtual machine that may store confidential data, and marking memory pages and files that potentially contain data stored by the identified processes; or providing an application programming interface for marking memory regions and files within the virtual machine that contain confidential data stored by processes; and creating a checkpoint file, by capturing memory pages and files representing a current state of the computing system, which excludes information from all of the marked memory pages and files.

United States Patent Application publication number <CIT>) discloses a system that monitors events that allocate and deallocate virtual memory regions in a device, wherein the events include system calls from user space. The system can generate a log of events, and based on the log of events, track regions of virtual memory allocated and deallocated via the events. The system can also record events with corresponding stack traces. Next, the system can group recorded events having matching stack traces to yield event groupings, and instrument functions in a compiled code associated with the process to determine retain counts of respective events associated with the functions. The system can then automatically pair at least one of a first portion of the events and a second portion of the respective events based on the event groupings and the retain counts of the respective events to yield paired events.

According to the present invention there are provided a system, method, and a computer program according to the independent claims.

Embodiments of the present disclosure include a perfect forward secrecy system for providing secure memory allocation functions in a virtual machine, including a data processing component and at least one memory component. The system also includes local data storage having stored thereon computer-executable program code, which, when executed by the data processing component, causes the data processing component to receive, from an application operating within a virtual machine, a secure memory allocation function for a connection secret. The secure memory allocation function includes a memory size parameter. The system also causes the data processing component to allocate memory for the connection secret according to the memory size parameter. The memory includes a memory location and a memory size. The system also causes the data processing component to transmit the memory location and the memory size to the virtual machine host to be stored as an entry in a secure database. The system also causes the data processing component to store the entry in the secure database and to monitor an operation state relating to the virtual machine. The system also causes the processing component to, in response to receipt of a notice indicating a change in the operation state of the virtual machine, determine the operation state of the virtual machine, retrieve the entry from the secure database relating to the virtual machine, and sanitize the memory based on a change to the operation state of the virtual machine.

Additional embodiments of the present disclosure include a computer-implemented method for providing perfect forward secrecy in virtual machines. The computer-implemented method includes receiving, from an application operating within a virtual machine, a secure memory allocation function for a connection secret. The secure memory allocation function includes a memory size parameter. The computer-implemented method further includes allocating memory for the connection secret according to the memory size parameter. The memory includes a memory location and a memory size. The computer-implemented method also includes transmitting the memory location and the memory size to a virtual machine host to be stored as an entry in a secure database and storing the entry in the secure database. The computer-implemented method further includes monitoring an operation state relating to the virtual machine. The computer-implemented method further includes, in response to receipt of a notice indicating a change in the operation state of the virtual machine, determining the operation state of the virtual machine, retrieving the entry from the secure database relating to the virtual machine, and sanitizing the memory based on a change to the operation state of the virtual machine.

Further embodiments of the present disclosure include a computer program product for providing perfect forward secrecy in virtual machines, which can include a computer-readable storage medium having program instruction embodied therewith, the program instruction executable by a processor to cause the processor to perform a method. The method includes receiving, from an application operating within a virtual machine, a secure memory allocation function for a connection secret. The secure memory allocation function includes a memory size parameter. The method further includes allocating memory for the connection secret according to the memory size parameter. The memory includes a memory location and a memory size. The method also includes transmitting the memory location and the memory size to a virtual machine host to be stored as an entry in a secure database and storing the entry in the secure database. The computer-implemented method further includes monitoring an operation state relating to the virtual machine. The method further includes, in response to receipt of a notice indicating a change in the operation state of the virtual machine, determining the operation state of the virtual machine, retrieving the entry from the secure database relating to the virtual machine, and sanitizing the memory based on a change to the operation state of the virtual machine.

These and other features, aspects, and advantages of the embodiments of the disclosure will become better understood with regard to the following description, appended claims, and accompanying drawings where:.

While the present disclosure is amenable to various modifications and alternative forms, specifics thereof have been shown by way of example in the drawings and will be described in detail. It should be understood, however, that the intention is not to limit the particular embodiments described. On the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the scope of the present disclosure.

The present disclosure relates to virtual machine security, and more specifically, to providing perfect forward secrecy capabilities to virtual machines. While the present disclosure is not necessarily limited to such applications, various aspects of the disclosure may be appreciated through a discussion of various examples using this context.

Perfect forward secrecy is built on a concept known as backtracking resistance. Backtracking resistance refers to a means that assures previously generated bits are impossible to recover. These generated bits can refer to secrets used to establish a secure connection between a server and a client.

Various protocols implement perfect forward secrecy as a way to secure secrets. For instance, the Transport Layer Security (TLS) protocol implements perfect forward security that protects against both data leak and breach style attacks. A data leak refers to an attack where an attacker recovers temporary secrets such as the session keys or Diffie-Hellman private keys. Using these secrets, the attacker can decrypt communication from a present session, but not from any previous or future sessions, because the values used to generate those secrets are different. A breach refers to a model where an attacker recovers long-term secrets. A long-term secret can be a private key corresponding to a public key in a certificate. The long-term secret, however, is not useful in decrypting a previous session as the private key is simply used to authenticate a server.

However, an attacker may be able to compromise a client's machine and gain access to the machine's memory and disk storage. By doing so, the attacker can recover the client's TLS session keys and other secrets stored in memory. Furthermore, if previous keys are still in memory or disk storage, the attacker can locate those secrets and use them to decrypt previous sessions. These types of attacks are protected by perfect forward secrecy. To ensure perfect forward secrecy is maintained, keys should be erased from memory after use and are not to be stored in disk storage.

A virtual machine refers to a virtual representation, or emulation, of a physical computer. To establish a virtual machine, a hypervisor can be used to allocate physical computing resources to the virtual machine. These computing resources include processors, memory, and storage. Once established, a virtual machine can operate as a standalone system with its own operating system and applications.

A virtual machine can also be in various states of operation. These include, but are not limited to, running, shutdown, suspended, and checkpoint/snapshot. When a virtual machine is in a running state of operation, instruction execution can be in progress, and an application can reliably delete any keys from memory. When a virtual machine is in a shutdown state, it is forced to shut down. An application may not have an opportunity to delete keys from memory prior to the shutdown. After a virtual machine is shut down, its memory is still being powered on by the virtual machine host. Thus, the memory retains the key information if the virtual machine did not delete it. When a virtual machine is in a suspended state, the hypervisor suspends operation of the virtual machine, and its memory, along with the keys, is written to disk storage. When a virtual machine is in a snapshot state, a snapshot of the virtual machine is taken, similar to a backup, where the memory, along with the keys, is written to storage to support the possibility of revert operations by an administrator.

Limitations on virtual machine security remain, however, as perfect forward secrecy cannot be reliably maintained by a virtual machine due to the various vulnerabilities presented by the states of operation. Applications running within a virtual machine may not be able to securely delete keys from memory or from disk storage. An attacker can compromise the virtual machine and access the memory and disk storage to retrieve the keys as well as other secrets.

Embodiments of the present disclosure may overcome the above and other problems, by using a perfect forward secrecy system. The perfect forward secrecy system includes a secure memory allocation function configured to allocate a connection secret into memory and store information regarding the connection secret in an encrypted database. The perfect forward secrecy system further includes a secure memory deallocation function configured to deallocate the connection secret from memory and perform a sanitization operation on the memory location where the connection secret was stored. The perfect forward secrecy system also includes a secure memory reallocation function configured to reallocate the memory into a different memory location and to update the encrypted database with that corresponding information. Additionally, the perfect forward system includes a virtual machine monitor configured to monitor the virtual machines which have utilized the secure memory allocation functions. Upon receiving a change in the operational status of a monitored virtual machine, the perfect forward system can sanitize memory locations as necessary.

More specifically, the perfect forward secrecy system described herein provides applications operating within a virtual machine, or a physical machine, with secure memory allocation functions for connection secrets. The connection secrets include, but are not limited to, public keys, private keys, and session keys. The perfect forward secrecy system can monitor the status of the virtual machines to determine whether or not the sanitization of a memory location is required.

Memory allocation functions are functions used by applications to perform dynamic memory allocation. Dynamic memory allocation refers to the process of allocating memory during program execution. The types of memory allocation functions include, but are not limited to, malloc, calloc, realloc, and free. The malloc function allocates memory of the requested size and returns a pointer to the first byte of allocated space. The calloc function, similar to the malloc function, also allocates the space for elements of an array. It also initializes the elements to zero and returns a pointer to the first byte of allocated space. The realloc function is used to modify the size of a previously allocated memory space. The free function empties a previously allocated memory space.

The perfect forward secrecy system provides secure memory allocation functions that can be used by applications to perform dynamic memory allocation for connection secrets. The secure memory allocation functions include smalloc, scalloc, srealloc, and sfree.

In some embodiments, the smalloc function is a secure memory allocation used to allocate a block of memory dynamically. An application operating on a virtual machine can use the smalloc function to allocate a secure memory of a size requested by the function. The virtual machine can allocate the memory the same as it would with the malloc function. Once allocated, the virtual machine can notify the virtual machine host, via a hypervisor, of the memory location by providing the pointer generated during allocation as well as the size of the secure memory. The virtual machine host can store the pointer information and the size of the secure memory in a secure database.

In some embodiments, the scalloc function is secure memory allocation function used to allocate multiple blocks of memory dynamically. An application operating on a virtual machine can use the scalloc function to allocate based on n number of memory blocks of the same size. The virtual machine can allocate the memory the same as it would with the calloc function. After the memory space is allocated, the bytes can be initialized to zero. Once allocated, the virtual machine can notify the virtual machine host, via a hypervisor, of the memory location by providing the pointer generated during allocation as well as the size of the secure memory. The virtual machine host can store the pointer information and the size of the secure memory in a secure database. Typically, a scalloc function can be used to allocate memory for complex data structures such as arrays and structures.

In some embodiments, the srealloc function is a secure memory allocation function used to resize the memory size of already allocated memory. It can expand the current memory block size while leaving the original content as it is. An application operating on a virtual machine can use the srealloc function to reallocate secure memory and specify the new memory size. The virtual machine can allocate the memory the same as it would with the realloc function. The virtual machine can notify the virtual machine host, via the hypervisor, of the location and size of the secure memory. Using that information, the virtual machine host can update the entry in the secure database to reflect the new information.

In some embodiments, the sfree function is used to release/deallocate secure memory. An application operating on a virtual machine can use the sfree function to delete secure memory. The virtual machine can notify the virtual machine host, via the hypervisor, about the location and size of the secure memory being freed. The virtual machine can delete the memory and sanitize the location. The entry in the secure database can also be deleted.

Referring now to <FIG>, shown is a block diagram illustrating an exemplary virtual machine environment <NUM>, in accordance with embodiments of the present disclosure. The virtual machine environment <NUM> includes a virtual machine host <NUM>, a hypervisor <NUM>, virtual machine <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-N (collectively "virtual machines <NUM>"), where N is a variable integer representing any number of possible virtual machines <NUM>, a switching fabric <NUM>, and a storage environment <NUM>.

The virtual machine <NUM>-<NUM> includes applications <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-N (collectively "applications <NUM>"), and a guest operating system <NUM>. The virtual machine <NUM>-<NUM> includes applications <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-N (collectively "applications <NUM>"), and a guest operating system <NUM>. The virtual machine <NUM>-<NUM> includes applications <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-N (collectively "applications <NUM>"), and a guest operating system <NUM>. The virtual machine host <NUM> includes a host input/output (I/O) controller <NUM>, storage <NUM>, including a secure database <NUM>, and memory <NUM>.

The virtual machine host <NUM> is a component of the virtual machine environment <NUM> configured to provide and support virtualization, in accordance with embodiments of the present disclosure. The virtual machine host <NUM> is further configured to operate the hypervisor <NUM>. Virtualization refers to the process of running a virtual instance of a computer system in a layer abstracted from the actual hardware. The virtual machine host <NUM> can be a physical computer, server, physical machine, and the like, with physical computing components. The physical computing components include, but are not limited to, at least one processor, storage <NUM>, and memory <NUM>. The virtual machine host <NUM> can also operate the hypervisor <NUM> to provide the virtualization needed to generate the virtual machines <NUM>.

The hypervisor <NUM>, or virtual machine monitor (VMM), is a component of the virtual machine environment <NUM> configured to create and deploy the virtual machines <NUM>, in accordance with embodiments of the present disclosure. The hypervisor <NUM> can be computer software, firmware, or hardware that provides the environment in which the virtual machines <NUM> operate within. The hypervisor <NUM> can also manage the execution of the virtual machines' <NUM> operating systems. The hypervisor <NUM> acts as an interface between the hardware devices (e.g., storage <NUM>, memory <NUM>) on the virtual machine host <NUM> and the virtual devices on the virtual machines <NUM>. The hypervisor <NUM> presents some subset of the physical resources to each individual virtual machine <NUM> and handles the actual I/O from the virtual machine <NUM> to a physical device and back again. For example, application <NUM>-<NUM> requests an allocation of a variable onto the memory of virtual machine <NUM>-<NUM>. The virtual machine <NUM>-<NUM> allocates the variable into its virtual memory space provided by the hypervisor <NUM>, and the hypervisor <NUM> can allocate the variable into physical memory <NUM>.

The virtual machines <NUM> are components of the virtual machine environment <NUM> configured to operate as containers for operating systems and applications that run on top of the hypervisor <NUM> on the virtual machine host <NUM>. The virtual machines <NUM> can include a set of resources to which the applications <NUM>, <NUM>, <NUM> running on the virtual machines <NUM> can request access. An application can request usage of the resources available to a virtual machine <NUM> through programming language functions (e.g., malloc, calloc, free, realloc), which get passed through to the operating system <NUM>, which passes the request to a virtual I/O controller. The virtual I/O controller can process the request by accessing the virtual resources assigned to the virtual machine <NUM>. Upon accessing the virtual resources, the hypervisor <NUM> can access the host I/O controller <NUM> to perform the functions on the physical resources located on the virtual machine host <NUM>.

The switching fabric <NUM> is a component of the virtual machine environment <NUM> configured to interconnect the virtual machine host <NUM> and the storage system <NUM> via one or more network switches, in accordance with embodiments of the present disclosure. The switching fabric <NUM> can be made up of a variety of high-speed networks. These networks include but are not limited to, fiber channel, InifiniBand, and RapidlO. The switching fabric <NUM> can be a combination of hardware and software that controls traffic to and from a network node with the use of multiple switches. Typically, the switching fabric <NUM> makes use of shared memory and data buffers. In some embodiments, the switching fabric <NUM> is a fiber channel switched fabric (FC-SW) topology where devices in the network (e.g., the virtual machine host <NUM>) can be connected to each other via one or more fiber channel switches.

The storage environment <NUM> is a component of the virtual machine environment configured to consolidate, manage, and operate data storage, in accordance with embodiments of the present disclosure. In some embodiments, the storage environment <NUM> is a server or an aggregation of servers. Examples of the storage environment <NUM> include storage servers (e.g., block-based storage), direct-attached storage, file servers, server-attached storage, network-attached storage, or any other storage solution. In some embodiments, the components of the storage environment <NUM> are implemented within a single device. In some other embodiments, the components of the storage environment <NUM> comprise a distributed architecture. For example, the storage environment <NUM> can comprise multiple storage systems physically located at different locations but are able to communicate over a communication network to achieve the desired result.

In some embodiments, the storage environment <NUM> is a storage area network (SAN). SANs can include a multitude of storage systems of varying capabilities. These storage systems can have capabilities such as data reduction (e.g., deduplication, compression), storage tiering, redundant array of independent disks (RAID), and the like. Other storage systems may simply store fully allocated volumes.

It is noted that <FIG> is intended to depict the major representative components of an exemplary virtual machine environment <NUM>. In some embodiments, however, individual components may have greater or less complexity than as represented in <FIG>, components other than or in addition to those shown in <FIG> may be present, and the number, type, and configuration of such components may vary.

<FIG> is a block diagram illustrating a perfect forward secrecy system <NUM> operating within a hypervisor <NUM>, in accordance with embodiments of the present disclosure. The perfect forward secrecy system <NUM> includes a secure memory allocation function <NUM>, a secure contiguous allocation function <NUM>, a secure reallocation function <NUM>, a secure deallocation function <NUM>, and a virtual machine monitor <NUM>.

The secure memory allocation function <NUM> is a component of the perfect forward secrecy system <NUM> configured to allocate secure memory. The secure memory allocation function <NUM> (smalloc <NUM>) can be used to allocate a block of memory on a heap. A user can specify the number of bytes to be allocated when the function is used. Once allocated, an application can access the block of memory via a pointer that is returned by the secure memory allocation function <NUM>. The pointer returned by smalloc <NUM> can be a void type and castable by the application <NUM> into a data type (e.g., connection secret).

The secure memory allocation function <NUM> is further configured to transmit attributes of the memory allocated using this function. These attributes include, but are not limited to, the pointer that references the location of the memory as well as the memory size allocated. The attributes can be transmitted, via the hypervisor <NUM>, to a virtual machine host <NUM> where entry of the attributes can be made into a secure database <NUM>.

In some embodiments, the smalloc <NUM> is used by an application operating on a physical machine. The smalloc <NUM> can allocate the memory in the same manner as a virtual machine. The attributes of the allocation and memory size can be performed by the physical machine that can be kept separate and inaccessible by the application.

In some embodiments, the virtual machine host <NUM> can operate the secure database <NUM> within a storage environment <NUM>. For example, the virtual machine host <NUM> may access a SAN storage drive that is storing the secure database <NUM>.

The secure contiguous allocation function <NUM> is a component of the perfect forward secrecy system <NUM> configured to allocate multiple blocks of memory. The secure contiguous allocation function <NUM> (scalloc <NUM>) can be used to allocate memory for complex data structures such as an array or linked list. The multiple blocks of memory are of the same size as specified when the function is used. Once allocated, an application can access the block of memory via a pointer that is returned by the secure contiguous allocation function <NUM>. The pointer returned by scalloc <NUM> can be a void type and castable by the application into a data type (e.g., connection secret).

The secure contiguous allocation function <NUM> is further configured to transmit attributes of the memory allocated using this function. These attributes include, but are not limited to, the pointer that references the location of the memory as well as the memory size allocated. The attributes can be transmitted, via the hypervisor <NUM>, to a virtual machine host <NUM> where entry of the attributes can be made into a secure database <NUM>.

In some embodiments, the scalloc <NUM> is used by an application operating on a physical machine. The scalloc <NUM> can allocate the memory in the same manner as a virtual machine. The attributes of the allocation and memory size can be performed by the physical machine that can be kept separate and inaccessible by the application.

The secure reallocation function <NUM> is a component of the perfect forward secrecy system <NUM> configured to alter the memory size of an already allocated memory secured by either the smalloc <NUM> or the scalloc <NUM>. The secure reallocation function <NUM> (srealloc <NUM>) can expand the current block or blocks of memory while not affecting the stored content. The srealloc <NUM> can also reduce the memory size of the previously allocated memory size. For example, an application can initially call smalloc <NUM> to allocate four hundred bytes of memory. The srealloc <NUM> can be called to reduce the memory size to a different size, such as two hundred bytes. In this same example, the original four hundred bytes can be sanitized using known sanitization techniques.

The secure reallocation function <NUM> is further configured to transmit updated attributes of the memory reallocated using this function. The attributes include the pointer that references the location of the memory as well as the resized memory size. The attributes can be transmitted, via the hypervisor <NUM>, to a virtual machine host <NUM> where the entry previously inputted by the smalloc <NUM> or the scalloc <NUM> can be updated with the updated attributes.

The secure deallocation function <NUM> is a component of the perfect forward secrecy system <NUM> configured to deallocate the memory blocks allocated by the smalloc <NUM> or the scalloc <NUM> functions. The secure deallocation function <NUM> (sfree <NUM>) can release the memory allocated by either the smalloc <NUM> or the scalloc <NUM> and sanitize the memory blocks by overwriting the blocks with random values. In some embodiments, the sfree <NUM> overwrites the memory blocks using known sanitization techniques.

The sfree <NUM> is further configured to transmit a function notifying a virtual machine host <NUM> that the memory blocks have been released and to delete any entry of that allocation from the secure database <NUM>. Additionally, the function can instruct the virtual machine host <NUM> to sanitize the physical memory location that stored the allocated memory blocks.

The virtual machine monitor <NUM> is a component of the perfect forward secrecy system <NUM> configured to monitor operation states of virtual machines <NUM> that have used the secure memory allocation functions (e.g., smalloc <NUM>, scalloc <NUM>, srealloc <NUM>, sfree <NUM>). Upon detecting a change in the operation state of a virtual machine <NUM>, the virtual machine monitor <NUM> can initiate actions to ensure perfect forward secrecy is maintained. These operation states include, but are not limited to, running, shutdown, suspended, and checkpoint/snapshot.

A virtual machine <NUM> can be in a running operation state by sending a notification to the hypervisor <NUM> notifying the virtual machine host <NUM> that operation has started. At this point, the virtual machine <NUM> can execute instruction from its guest operating system <NUM> and any applications <NUM> operating on the virtual machine <NUM>. During this operation state, the virtual machine monitor <NUM> can monitor for any change from this operation state. The virtual machine <NUM> in a running operation state can reliably delete and sanitize ephemeral and session keys stored using the secure memory allocation functions. For example, an application can call smalloc <NUM> to allocate memory blocks for a session key. Once the session key is no longer needed, the application can call the sfree <NUM> function to delete and sanitize the memory blocks storing the key. The virtual machine monitor <NUM> need not perform any additional actions as long as the virtual machine <NUM> stays in the running operation state when those two functions are called.

A virtual machine <NUM> can be in a shutdown operation state when it has stopped operation. This can occur in several ways. For instance, the virtual machine <NUM> can initiate a shutdown itself and notify the hypervisor <NUM> that a shutdown is occurring. Also, a virtual machine <NUM> can be shutdown due to a stop or kill action initiated by the hypervisor <NUM>. The virtual machine monitor <NUM> can also detect that a virtual machine <NUM> is no longer running and determine that the virtual machine <NUM> is in a shutdown operation state.

The virtual machine monitor <NUM> is further configured to sanitize secure memory blocks allocated by a virtual machine <NUM> that is in a shutdown operation state. Upon detecting that a virtual machine <NUM> is in a shutdown operation state, the virtual machine monitor <NUM> can send a function to the virtual machine host <NUM> to retrieve all entries in the secure database <NUM> that were made by the virtual machine <NUM>. The memory blocks referenced in the entries can be sanitized. Once sanitized, the entries can be removed from the secure database <NUM>. In some embodiments, the virtual machine monitor <NUM> sends a function to the virtual machine host <NUM> to sanitize all memory blocks held by the virtual machine <NUM> if the virtual machine <NUM> had an entry in the secure database <NUM>.

A virtual machine <NUM> can be in a suspended operation state when a suspend function is issued to a virtual machine <NUM>. A suspend function can be issued by a hypervisor <NUM> as well as from a file executed by the virtual machine <NUM>. Once initiated, all transactions being performed by the virtual machine <NUM> are frozen until a resume function is issued. When a virtual machine <NUM> is suspended, its memory can be written onto storage so as to preserve the virtual machine <NUM> until a resume function is issued. However, if the virtual machine <NUM> has connection secrets allocated onto memory, those connection secrets are written to storage.

The virtual machine monitor <NUM> is further configured to sanitize the storage location of the secure memory blocks allocated by a virtual machine <NUM> that is in a suspended operation state. Upon detecting a virtual machine <NUM> in a suspended operation state, the virtual machine monitor <NUM> can send a function to the virtual machine host <NUM> to sanitize the stored memory locations that have been written onto storage. For example, a virtual machine <NUM> can use a secure memory allocation function (e.g., smalloc <NUM>, scalloc <NUM>) to store a connection secret in memory. While the connection secret is still stored in memory, the virtual machine <NUM> can go into a suspended operation state that triggers the virtual machine host <NUM> to store the memory of the virtual machine <NUM> on storage <NUM>. The virtual machine monitor <NUM> can send a function to the virtual machine host <NUM> to delete and sanitize the connection secret from storage.

In some embodiments, the virtual machine monitor <NUM> sends a function to the virtual machine host <NUM> to retrieve all entries in the secure database <NUM> that were made by the virtual machine <NUM> and to sanitize the memory blocks referenced in those entries. Once sanitized, the entries can be removed from the secure database <NUM>. This can be performed prior to the virtual machine host <NUM> writing the memory onto storage. Thus, any secure memory blocks allocated by the virtual machine <NUM> are deleted prior to the memory being written to storage.

A virtual machine <NUM> can be in a checkpoint/snapshot operation state where an image of the virtual machine <NUM> is taken and written onto storage <NUM>. This typically occurs for back up purposes and to support possible revert operation functions. Similar to the suspend operation state, the virtual machine's <NUM> memory can be written onto storage so as to preserve the virtual machine <NUM>. However, if the virtual machine <NUM> has connection secrets allocated onto memory, those connection secrets are written to storage.

The virtual machine monitor <NUM> is further configured to send a function to the virtual machine host <NUM> to retrieve entries made into the secure database <NUM> by a virtual machine <NUM> going into a checkpoint/snapshot operation state. Using the information stored in the secure database <NUM>, the virtual machine host <NUM> can sanitize the memory blocks prior to storing an image of the virtual machine <NUM>.

In some embodiments, the perfect forward secrecy system <NUM> operates with any memory allocation function provided by a virtual machine <NUM>. For example, the operating system calls corresponding to a new function or delete function that operates similar to an allocation and deallocation function can be used by the perfect forward secrecy system <NUM>.

In some embodiments, the perfect forward secrecy system <NUM> operates using a third-party shared library system calls offered by a virtual machine provider. For example, in place of operating system calls allocating the memory. Virtual machines <NUM> operating within a particular platform can utilize the shared library that offers functionality similar to that of smalloc <NUM>, scalloc <NUM>, srealloc <NUM>, and sfree <NUM>.

<FIG> is a data flow diagram <NUM> illustrating secure memory allocation functions according to the perfect forward secrecy system <NUM>, in accordance with embodiments of the present disclosure. To illustrate data flow diagram <NUM>, but not to limit embodiments, <FIG> is described within the context of the virtual machine environment <NUM> of <FIG> and the perfect forward secrecy system <NUM> of <FIG>.

At operation <NUM>, the application <NUM> can transmit a smalloc <NUM> function to a guest operating system <NUM>. The smalloc <NUM> function includes a memory size to be allocated securely. At operation <NUM>, the guest operating system <NUM> can allocate the memory in the same manner as a malloc function. The memory is allocated in the virtual machine's <NUM> virtual memory space corresponding to physical memory space operated by the virtual machine host <NUM>.

At operation <NUM>, the perfect forward secrecy system <NUM> can send a function to the virtual machine host <NUM> to add an entry into a secure database <NUM>. The function can include the pointer generated by the malloc function and the memory size requested. At operation <NUM>, the virtual machine host <NUM> can create an entry into the secure database <NUM> that includes the location and the memory size of the allocated memory.

At operation <NUM>, the application <NUM> can transmit a scalloc <NUM> function to a guest operating system <NUM>. The scalloc <NUM> function includes a number of blocks to be allocated and a memory size for each block. At operation <NUM>, the guest operating system <NUM> can allocate the memory in the same manner as a calloc function. The memory is allocated in the virtual machine's <NUM> virtual memory space corresponding to physical memory space operated by the virtual machine host <NUM>.

At operation <NUM>, the perfect forward secrecy system <NUM> can send a function to the virtual machine host <NUM> to add an entry into a secure database <NUM>. The function can include the pointer generated by the calloc function and the memory size requested. At operation <NUM>, the virtual machine host <NUM> can create an entry into the secure database <NUM> that includes the location and the memory size of the allocated memory.

At operation <NUM>, the application <NUM> can transmit a srealloc <NUM> function to a guest operating system <NUM>. The srealloc <NUM> function includes a pointer indicating a location of allocated memory and a new memory size. At operation <NUM>, the guest operating system <NUM> can reallocate the memory in the same manner as a realloc function. The memory is reallocated in the virtual machine's <NUM> virtual memory space corresponding to physical memory space operated by the virtual machine host <NUM>.

At operation <NUM>, the perfect forward secrecy system <NUM> can send a function to the virtual machine host <NUM> to modify an entry in a secure database <NUM>. The function can include the pointer generated by the realloc function, the old memory pointer, and the updated memory size. At operation <NUM>, the virtual machine host <NUM> can update the entry into the secure database <NUM> that includes the location and the updated memory size of the reallocated memory and additionally can sanitize the physical memory location that corresponded to the old memory.

At operation <NUM>, the application <NUM> can transmit a sfree <NUM> function to a guest operating system <NUM>. The sfree <NUM> function includes a location and memory size to be deallocated securely. At operation <NUM>, the guest operating system <NUM> can deallocate the memory in the same manner as a free function. The memory is deallocated in the virtual machine's <NUM> virtual memory space corresponding to physical memory space operated by the virtual machine host <NUM>. Additionally, the guest operating system <NUM> can populate the memory space with zero's to overwrite any information that was stored in that space.

At operation <NUM>, the perfect forward secrecy system <NUM> can send a function to the virtual machine host <NUM> to delete an entry in a secure database <NUM>. The function can include a point providing a location of the memory and the memory size deallocated. At operation <NUM>, the virtual machine host <NUM> can delete an entry from the secure database <NUM> that includes the location and the memory size of the allocated memory. Additionally, the virtual machine host <NUM> can sanitize the physical memory location that corresponded to the location in the sfree <NUM> function.

<FIG> is a data flow diagram <NUM> illustrating virtual machine operation states according to the perfect forward secrecy system <NUM>, in accordance with embodiments of the present disclosure. To illustrate data flow diagram <NUM>, but not to limit embodiments, <FIG> is described within the context of the virtual machine environment <NUM> of <FIG> and the perfect forward secrecy system <NUM> of <FIG>.

At operation <NUM>, the virtual machine host <NUM> issues a power-off function to the virtual machine <NUM>. This places the virtual machine <NUM> in a shutdown operation state <NUM>. The virtual machine monitor <NUM> can notice that the virtual machine <NUM> is now in a shutdown state and can send a function to the virtual machine host <NUM> to retrieve all entries made by the virtual machine <NUM> that is being stored in the secure database <NUM>.

At operation <NUM>, the virtual machine host <NUM> retrieves the entries stored in the secure database <NUM> that were made by the virtual machine <NUM>. At operation <NUM>, the secure database <NUM> responds to the query request and transmits the information for any and all entries made by the virtual machine <NUM>.

At operation <NUM>, the virtual machine host <NUM> can overwrite the memory locations found in each of the entries provided by the secure database <NUM>. Additionally, the virtual machine host <NUM> can sanitize the memory locations using known sanitization techniques to permanently delete any connection secrets stored in those memory locations.

At operation <NUM>, the virtual machine host <NUM> issues a suspend function to the virtual machine <NUM> to pause all operations being performed. This places the virtual machine <NUM> in a suspended operation state <NUM>. The virtual machine monitor <NUM> can notice that the virtual machine <NUM> is now in a suspended state and can send a function to the virtual machine host <NUM> to retrieve all entries made by the virtual machine <NUM> that is being stored in the secure database <NUM>.

At operation <NUM>, the virtual machine host <NUM> can complete the suspension of the virtual machine <NUM> to halt all operations. Additionally, the virtual machine <NUM> can store the memory of the virtual machine <NUM> in storage <NUM>.

At operation <NUM>, the virtual machine host <NUM> issues a checkpoint/snapshot function to the virtual machine <NUM> to create an image of the virtual machine <NUM>. This places the virtual machine <NUM> in a checkpoint/snapshot operation state <NUM>. The virtual machine monitor <NUM> can notice that the virtual machine <NUM> is now in a checkpoint/snapshot state and can send a function to the virtual machine host <NUM> to retrieve all entries made by the virtual machine <NUM> that is being stored in the secure database <NUM>.

At operation <NUM>, the virtual machine host <NUM> can complete the checkpoint/snapshot of the virtual machine <NUM> by taking an image of the virtual machine <NUM>. The image of the virtual machine <NUM> can be stored in storage <NUM> as a backup of the virtual machine <NUM>.

<FIG> is a flow diagram illustrating a process <NUM> for providing perfect forward secrecy for a virtual machine, in accordance with embodiments of the present disclosure. The process <NUM> may be performed by hardware, firmware, software executing on at least one processor, or any combination thereof. For example, any or all of the steps of the process <NUM> may be performed by one or more computing devices (e.g., computer system <NUM> of <FIG>). To illustrate process <NUM>, but not to limit embodiments, <FIG> is described within the context of the virtual machine environment <NUM> of <FIG> and the perfect forward secrecy system <NUM> of <FIG>.

The process <NUM> begins by receiving a secure memory allocation function from a virtual machine <NUM> to store a connection secret. This is illustrated at step <NUM>. The secure memory allocation functions can be a smalloc <NUM>, a scalloc <NUM>, and a srealloc <NUM>. Depending on the secure memory allocation function, various parameters may be included. For example, a smalloc function includes a memory size parameter indicating the memory size that is to be allocated. A scalloc function includes a memory size and a number of blocks to be allocated. The memory size indicates the memory size of each block being allocated. A srealloc function includes a pointer to a memory location being resized and a memory size of the new memory size.

The virtual machine <NUM> allocates the memory requested by the secure memory allocation function. This is illustrated at step <NUM>. A virtual machine <NUM> can allocate the memory as a standard memory allocation function. For example, a smalloc <NUM> function can be allocated in a similar way as a malloc function. A scalloc <NUM> function can be allocated in a similar way as a calloc function, and a srealloc <NUM> function can be allocated in a similar way as a realloc function.

Once allocated, the perfect forward secrecy system <NUM> transmits memory attributes relating to secure memory allocation function to the virtual machine host <NUM>. This is illustrated at step <NUM>. The memory attributes include the memory location of the allocated memory and the memory size allocated. Based on the secure memory allocation function received, the memory attributes transmitted to the virtual machine host <NUM> may vary. For instance, a smalloc <NUM> function can have the memory location and a memory size transmitted. A srealloc <NUM> function can have a memory location of a currently stored memory location and an updated memory size. In some embodiments, a pointer, providing the memory location, is transmitted as a memory attribute.

The virtual machine host <NUM> stores an entry into a secure database <NUM> that includes the memory attributes and the virtual machine <NUM>. This is illustrated at step <NUM>. The entry can include the memory location, the memory size of the allocated memory, and information regarding the virtual machine <NUM> that made the allocation. The entry can be used in deleting and sanitizing connection secrets in the event that the virtual machine <NUM> changes to an operation state that could compromise the connection secrets. In some embodiments, the virtual machine host <NUM> stores the entry into the secure database <NUM> that is stored in a storage environment <NUM>. For example, the secure database <NUM> can be stored in a SAN accessible to the virtual machine host <NUM>.

The virtual machine monitor <NUM> monitors the virtual machine <NUM> for a change in its operation state. This is illustrated at step <NUM>. The virtual machine monitor <NUM> can identify which virtual machines <NUM> have allocated memory using secure memory functions and monitor to see if their operation state has changed. In some embodiments, the virtual machine monitor <NUM> can query the virtual machine <NUM> at an interval to determine the operation state. For example, the virtual machine monitor <NUM> can ping the virtual machine <NUM> to see if a response is given. A query can also be sent to the virtual machine host <NUM> to provide a status on the virtual machine <NUM>. In some embodiments, the virtual machine monitor <NUM> receives a notification from the virtual machine host <NUM> that a virtual machine <NUM> is changing operation state. For example, a virtual machine host <NUM> can transmit a stop function, or a suspend function, to a virtual machine <NUM>. When doing so, the virtual machine host <NUM> can also transmit a message to the virtual machine monitor <NUM>, notifying it of the upcoming change.

The virtual machine monitor <NUM> determines whether there is an operation change to the virtual machine <NUM>. This is illustrated at step <NUM>. If no change has occurred, the virtual machine monitor <NUM> continues to monitor the virtual machine <NUM> until the virtual machine <NUM> securely deallocates the memory. However, if the virtual machine monitor <NUM> notices that an operation change has occurred to the virtual machine <NUM>, then the virtual machine monitor <NUM> determines the operation state the virtual machine <NUM> changed to. This is illustrated at step <NUM>. For example, the virtual machine <NUM> can change from a running state to a shutdown state, or to a suspended state, or to a checkpoint/snapshot state. Based on the state the virtual machine <NUM> changed to, the virtual machine monitor <NUM> can provide functions to the virtual machine host <NUM> to prevent connection secrets from being compromised.

The virtual machine host <NUM> sanitizes the memory location allocated by the virtual machine. This is illustrated at step <NUM>. The virtual machine host <NUM> can query the secure database <NUM> for all entries made by the virtual machine <NUM>. Upon retrieving the query results, the virtual machine host <NUM> can read each entry to determine the secure memory location allocated by the virtual machine <NUM>. At each memory location, the virtual machine host <NUM> can overwrite the data with zeros. In some embodiments, the virtual machine host <NUM> permanently erases data from the physical memory locations using known sanitization techniques.

In some embodiments, the virtual machine host <NUM> permanently erases data stored on the storage <NUM>. The virtual machine host <NUM> can determine if the memory stored by the virtual machine <NUM> has been saved onto storage prior to permanently deleting the secure memory locations. For example, a suspend operation or a snapshot/checkpoint operation copy the memory of a virtual machine <NUM> and place the copy onto storage. If the memory has been stored onto storage, then the virtual machine host <NUM> can go into storage <NUM> and locate the stored memory and permanently erase the data.

Referring now to <FIG>, shown is a high-level block diagram of an example computer system <NUM> (e.g., the perfect forward secrecy system <NUM>) that may be used in implementing one or more of the methods, tools, and modules, and any related functions, described herein (e.g., using one or more processor circuits or computer processors of the computer), in accordance with embodiments of the present disclosure. In some embodiments, the major components of the computer system <NUM> may comprise one or more processors <NUM>, a memory <NUM>, a terminal interface <NUM>, a I/O (Input/Output) device interface <NUM>, a storage interface <NUM>, and a network interface <NUM>, all of which may be communicatively coupled, directly or indirectly, for inter-component communication via a memory bus <NUM>, a I/O bus <NUM>, and an I/O bus interface <NUM>.

The computer system <NUM> may contain one or more general-purpose programmable central processing units (CPUs) <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-N, herein generically referred to as the processor <NUM>. In some embodiments, the computer system <NUM> may contain multiple processors typical of a relatively large system; however, in other embodiments, the computer system <NUM> may alternatively be a single CPU system. Each processor <NUM> may execute instructions stored in the memory <NUM> and may include one or more levels of on-board cache.

The memory <NUM> may include computer system readable media in the form of volatile memory, such as random-access memory (RAM) <NUM> or cache memory <NUM>. Computer system <NUM> may further include other removable/non-removable, volatile/non-volatile computer system storage media. By way of example only, storage system <NUM> can be provided for reading from and writing to a non-removable, non-volatile magnetic media, such as a "hard drive. " Although not shown, a magnetic disk drive for reading from and writing to a removable, non-volatile magnetic disk (e.g., a "floppy disk"), or an optical disk drive for reading from or writing to a removable, non-volatile optical disc such as a CD-ROM, DVD-ROM or other optical media can be provided. In addition, the memory <NUM> can include flash memory, e.g., a flash memory stick drive or a flash drive. Memory devices can be connected to memory bus <NUM> by one or more data media interfaces. The memory <NUM> may include at least one program product having a set (e.g., at least one) of program modules that are configured to carry out the functions of various embodiments.

Although the memory bus <NUM> is shown in <FIG> as a single bus structure providing a direct communication path among the processors <NUM>, the memory <NUM>, and the I/O bus interface <NUM>, the memory bus <NUM> may, in some embodiments, include multiple different buses or communication paths, which may be arranged in any of various forms, such as point-to-point links in hierarchical, star or web configurations, multiple hierarchical buses, parallel and redundant paths, or any other appropriate type of configuration. Furthermore, while the I/O bus interface <NUM> and the I/O bus <NUM> are shown as single respective units, the computer system <NUM> may, in some embodiments, contain multiple I/O bus interface units, multiple I/O buses, or both. Further, while multiple I/O interface units are shown, which separate the I/O bus <NUM> from various communications paths running to the various I/O devices, in other embodiments some or all of the I/O devices may be connected directly to one or more system I/O buses.

In some embodiments, the computer system <NUM> may be a multi-user mainframe computer system, a single-user system, or a server computer or similar device that has little or no direct user interface but receives requests from other computer systems (clients). Further, in some embodiments, the computer system <NUM> may be implemented as a desktop computer, portable computer, laptop or notebook computer, tablet computer, pocket computer, telephone, smartphone, network switches or routers, or any other appropriate type of electronic device.

It is noted that <FIG> is intended to depict the major representative components of an exemplary computer system <NUM>. In some embodiments, however, individual components may have greater or lesser complexity than as represented in <FIG>, components other than or in addition to those shown in <FIG> may be present, and the number, type, and configuration of such components may vary.

One or more programs/utilities <NUM>, each having at least one set of program modules <NUM> may be stored in memory <NUM>. The programs/utilities <NUM> may include a hypervisor (also referred to as a virtual machine monitor), one or more operating systems, one or more application programs, other program modules, and program data. Each of the operating systems, one or more application programs, other program modules, and program data or some combination thereof, may include an implementation of a networking environment. Programs <NUM> and/or program modules <NUM> generally perform the functions or methodologies of various embodiments.

It is to be understood that although this disclosure includes a detailed description on cloud computing, implementation of the teachings recited herein is not limited to a cloud computing environment.

A cloud computing environment is service-oriented with a focus on statelessness, low coupling, modularity, and semantic interoperability.

As shown, cloud computing environment <NUM> includes one or more cloud computing nodes <NUM> with which local computing devices used by cloud consumers, such as, for example, personal digital assistant (PDA) or cellular telephone <NUM>-<NUM>, desktop computer <NUM>-<NUM>, laptop computer <NUM>-<NUM>, and/or automobile computer system <NUM>-<NUM> may communicate. It is understood that the types of computing devices <NUM>-<NUM> to <NUM>-<NUM> shown in <FIG> are intended to be illustrative only and that computing nodes <NUM> and cloud computing environment <NUM> can communicate with any type of computerized device over any type of network and/or network addressable connection (e.g., using a web browser).

Referring now to <FIG>, a set of functional abstraction layers <NUM> provided by cloud computing environment <NUM> (<FIG>) is shown.

Examples of hardware components include mainframes <NUM>; RISC (Reduced Instruction Set Computer) architecture-based servers <NUM>; servers <NUM>; blade servers <NUM>; storage devices <NUM>; and networks and networking components <NUM>.

Workloads layer <NUM> provides examples of functionality for which the cloud computing environment may be utilized. Examples of workloads and functions which may be provided from this layer include mapping and navigation <NUM>; software development and lifecycle management <NUM> (e.g., the perfect forward secrecy system <NUM>); virtual classroom education delivery <NUM>; data analytics processing <NUM>; transaction processing <NUM>; and precision cohort analytics <NUM>.

The computer program product may include a computer-readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.

The computer-readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer-readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

Computer-readable program instructions described herein can be downloaded to respective computing/processing devices from a computer-readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network.

Claim 1:
A computer system for providing perfect forward secrecy in a virtual machine, the system comprising:
a data processing component;
a physical memory (<NUM>) ; and
local data storage having stored thereon computer executable program code, which when executed by the data processing component causes the data processing component to:
receive (<NUM>), from an application (<NUM>, <NUM>, <NUM>) operating within a virtual machine (<NUM>), a secure memory allocation function (<NUM>) for a connection secret, wherein the secure memory allocation function includes a memory size parameter; and
allocate (<NUM>) memory for the connection secret according to the memory size parameter, wherein the memory includes a memory location and a memory size;
characterized in that the computer executable code, when executed by the data processing component, causes the data processing component to:
transmit (<NUM>) the memory location and the memory size to a virtual machine host to be stored as an entry in a secure database;
store (<NUM>) the entry in the secure database;
monitor (<NUM>) an operation state relating to the virtual machine;
receive a notice indicating a change to the operation state of the virtual machine;
determine the operation state of the virtual machine;
retrieve the entry from the secure database relating to the virtual machine; and
sanitize (<NUM>), based on the operation state of the virtual machine, the memory location indicated by the entry.