System and methods for decrypting network traffic in a virtualized environment

ES 2 827 007 T3

DESCRIPTION

System and procedures for decrypting network traffic in a virtualized environment

Related requests

This application claims the benefit of the filing date of US Provisional Patent Application No. 62 / 317,804, filed April 4, 2016, entitled Systems and Methods for Decrypting NetWork Traffic in a Virtualized Environment.

Background

The invention relates to computer security systems and procedures and, in particular, to encrypted electronic communication.

In the modern digital world, a wide variety of products and services depend on data encryption. Encrypted communications enable, among others, online commerce, online banking and telephony over data networks such as the Internet. Encryption is also widely used to protect users' privacy and personal data. In an era of proliferation of interconnected electronic devices (Internet of Things), reliance on encryption is a strength, but also a vulnerability.

In recent years, encryption has been increasingly used for malicious purposes, for example to conceal malicious software activities or to demand a ransom for a user's valuable data. A typical example of malicious software activities involves setting up a network of hijacked computer systems, commonly known as a botnet (robot network), and using the respective network to launch a distributed denial of service attack against a targeted web server. As part of the botnet setup, each botnet member is infiltrated by a software agent, using various procedures (eg outright hacking, phishing, etc.). The agent can then use encryption to discreetly communicate with a remote server, for example to receive the target's network address and / or to coordinate the attack with other members of the botnet. Various procedures have been described to prevent or counteract such malicious activities. An example is US Pre-Grant Publication No. 2014 / 0115702A1 by Li et al., Entitled Encrypted Data Inspection in a Network Environment, which describes the decryption of a network flow between a first node and a second node, and the scanning of the decryption of target data that may indicate maliciousness.

Anti-malware operations are further complicated by the advent of hardware virtualization technology, which enables the creation of simulated computing environments commonly known as virtual machines. Multiple virtual machines can run simultaneously on the same physical machine, sharing hardware resources between them, thus reducing investment and operating costs. Each virtual machine can run its own operating system and / or software applications, separately from other virtual machines. Hardware virtualization is deployed for a variety of reasons, for example to ensure software portability or to strengthen security. Other popular hardware virtualization applications, known by the generic name of cloud computing, include web server farms and virtual desktop infrastructure (VDI). In a typical VDI configuration, a software application runs on a first computer system, while the user interacts with the respective application using a second computer system (terminal). An on-demand instance of a virtual machine is created that runs the respective application on the first computer system, which may end up running hundreds of such virtual machines for multiple remote users. Due to the constant proliferation of malware, each virtual machine potentially requires protection against malware.

Escalating security threats and a growing demand for virtualization generate great interest in developing efficient antimalware systems and procedures designed to address the challenges of hardware virtualization.

Compendium

According to one aspect, a client system comprises a hardware processor and memory, the hardware processor configured to run a virtual machine, and an introspection engine. The virtual machine is configured to carry out a communication session with a remote party, the communication session comprising a handshake message followed by an encrypted payload, where the handshake message contains an encryption parameter used by the client system to derive an encryption key, and where the encrypted payload is encrypted with the encryption key. The introspection engine runs outside of the virtual machine and is configured to identify within memory a target memory page based on whether a content of the target memory page has changed between an occurrence of a first session event of the communication session and an occurrence of a second session event of the communication session. The introspection engine is further configured to transmit the content of the target memory page to a decryption engine configured to decrypt the encrypted payload based on the content.

According to another aspect, a server computer system comprises a hardware processor configured to execute a decryption engine configured to perform decryption procedures for a plurality of client systems.

ES 2 827 007 T3

A decryption method comprises receiving a content of a target memory page from a client system of the plurality of client systems, receiving an encrypted payload of a communication session carried out between a virtual machine running on the client system, and a remote party and, in response, decrypt the encrypted payload based on the content of the target memory page. The communication session comprises a handshake message followed by the encrypted payload, where the handshake message contains an encryption parameter used by the client system to derive an encryption key, and where the encrypted payload is encrypted. with the encryption key. The client system is configured to run an introspection engine outside of the virtual machine, the introspection engine configured to identify the target memory page within a client system memory based on whether the content of the target memory page has changed between an occurrence of a first session event of the communication session and an occurrence of a second session event of the communication session.

According to another aspect, a non-transient computer-readable medium stores instructions that, when executed by a hardware processor of a client system that further comprises memory, cause the hardware processor to form an introspection engine that runs outside of a virtual machine running on the client system. The virtual machine is configured to carry out a communication session with a remote party, the communication session comprising a handshake message followed by an encrypted payload, where the handshake message contains an encryption parameter used by the client system to derive an encryption key, and where the encrypted payload is encrypted with the encryption key. The introspection engine is configured to identify within memory a target memory page based on whether a content of the target memory page has changed between an occurrence of a first session event of the communication session and an occurrence of a second session event of the communication session. The introspection engine is further configured to transmit the content of the target memory page to a decryption engine configured to decrypt the encrypted payload based on the content.

According to another aspect, a decryption method for encrypted communications between a client system and a remote party. The client system is configured to run a virtual machine. The virtual machine is configured to carry out a communication session with a remote party, the communication session comprising a handshake message followed by an encrypted payload, where the handshake message contains an encryption parameter used by the client system to derive an encryption key, and where the encrypted payload is encrypted with the encryption key. The method comprises employing at least one hardware processor to identify within a memory of the client system a target memory page based on whether a content of the target memory page has changed between an occurrence of a first session event of the session. of communication and an occurrence of a second session event of the communication session. The method further comprises employing at least one hardware processor to collect the encrypted payload, and employing at least one hardware processor to decrypt the encrypted payload based on the content of the target memory page.

Brief description of the drawings

The above aspects and advantages of the present invention will be better understood by reading the following detailed description and by referring to the drawings where:

Figure 1 illustrates an exemplary configuration where client systems collaborate with a firewall to decrypt potentially malicious network traffic in accordance with some embodiments of the present invention.

Figure 2 illustrates an exemplary hardware configuration of a client system in accordance with some embodiments of the present invention.

Figure 2-B illustrates an exemplary hardware configuration of a firewall in accordance with some embodiments of the present invention.

Figure 3 shows a guest virtual machine (VM) exposed by a hypervisor running on a client system, and an introspection engine running outside of the guest VM (s) based on some embodiments of the present invention.

Figure 4 shows an exemplary memory address translation in a hardware virtualization configuration as illustrated in Figure 3.

Figure 5 shows an exemplary sequence of steps performed by the introspection engine to intercept encrypted traffic entering or leaving a guest VM, in accordance with some embodiments of the present invention.

Figure 6 shows an exemplary sequence of steps performed by the introspection engine to obtain an optimized memory snapshot of a guest VM, according to some embodiments of the present invention.

Figure 7 illustrates an exemplary sequence of steps performed by the introspection engine to obtain optimized memory snapshots for multiple simultaneous encrypted communication sessions, in accordance with some embodiments of the present invention.

ES 2 827 007 T3

Figure 8 illustrates an exemplary decryption engine running on the firewall in accordance with some embodiments of the present invention.

Figure 9 shows an exemplary sequence of steps performed by the decryption engine in accordance with some embodiments of the present invention.

Detailed description of preferred embodiments of the invention

In the following description, it is understood that all of the listed connections between structures can be direct operational connections or indirect operational connections through intermediate structures. An item set includes one or more items. Any enumeration of an element is understood to refer to at least one element. A plurality of elements includes at least two elements. Unless otherwise specified, any use of OR refers to an exclusive or not. Unless otherwise required, any step of the described procedure need not necessarily be performed in a particular illustrated order. A first element (for example, data) derived from a second element encompasses a first element equal to the second element, as well as a first element generated by processing the second element and optionally other data. Making a determination or decision based on a parameter includes making the determination or decision based on the parameter and optionally based on other data. Unless otherwise specified, an indicator of some quantity / data can be the quantity / data itself, or a different indicator of the quantity / data itself. Computer security encompasses the protection of users and equipment against unintended or unauthorized access to data and / or hardware, the unintentional or unauthorized modification of data and / or hardware, and the destruction of data and / or hardware. A computer program is a sequence of processor instructions that carries out a task. The computer programs described in some embodiments of the present invention may be separate software entities or sub-entities (eg, subroutines, libraries) from other computer programs. Unless otherwise specified, the guest software runs inside a virtual machine. A program is said to run inside a virtual machine when it runs on a virtual processor of the respective virtual machine. A process is an instance of a computer program, such as an application or a part of an operating system, and is characterized by having at least one thread of execution and a virtual memory space assigned to it, where a content of the virtual memory space respective includes executable code. Unless otherwise specified, a page represents the smallest unit of virtual memory that can be individually allocated to physical memory on a host system. Unless otherwise specified, a memory snapshot of a client system / virtual machine comprises a copy of a content of a section of memory used by the respective client system / virtual machine. Computer-readable media encompasses non-transient media such as magnetic, optical, and semiconductor storage media (eg, hard drives, optical drives, flash memory, DRAM), as well as communication links such as lead cables and fiber optic links. According to some embodiments, the present invention provides, among other things, computer systems comprising hardware (eg, one or more microprocessors) programmed to perform the procedures described in this invention, as well as computer-readable media encoding instructions to perform the procedures described in this invention.

The following description illustrates embodiments of the invention by way of example and not necessarily by way of limitation.

Figure 1 shows an exemplary configuration according to some embodiments of the present invention, where a set of client systems 12a-d collaborate with a firewall 15 to intercept and decrypt the encrypted network traffic that occurs between the respective client systems 12a- d and a remote party illustrated as a content server 13. Each of the servers 13 and 15 generally represents a set of interconnected computer systems, which may or may not be in physical proximity to each other.

Exemplary 12a-d client systems include corporate computer systems, but also personal computer systems, mobile computing platforms (laptops, tablets, mobile phones), portable electronic devices (smart watches), household appliances (smart TVs, thermostats, security systems / home surveillance), or any other electronic device that has a processor and memory and that supports hardware virtualization. An exemplary client system of particular interest to computer security is a decoy computer. Decoy is a generic term used in the art to describe a set of systems and procedures to entice malicious entities to collect data and study malicious software. An exemplary decoy comprises a seemingly unprotected computer system that can allow a hacker or malware agent to enter, install software, and / or communicate with other computers over a network.

The illustrated client systems are interconnected via a local communication network 10, such as a corporate network or a home network. The parts of the local network 10 may include a local area network (LAN). A gateway device 14 may allow the client's client systems 12a-d access to an extended network 11 (eg, the Internet), so that all or part of the network traffic between the client systems 12a-d and a remote party traverses the gateway device 14. An exemplary gateway device 14 comprises physical apparatus such as a router and / or a switch.

ES 2 827 007 T3

Figure 2-A illustrates an exemplary hardware configuration of a client system 12 in accordance with some embodiments of the present invention. The client system 12 may represent any of the systems 12a-d of Figure 1. For simplicity, the illustrated client system is a personal computer; the hardware configuration of other client systems such as mobile phones , tablet computers, etc., may differ somewhat from the illustrated configuration of Figure 2-A. Client system 12 comprises a set of physical devices, including a hardware processor 16 and a memory unit 18. Processor 16 comprises a physical device (eg, a microprocessor, a multi-core integrated circuit formed on a semiconductor substrate, etc. .) configured to execute computational and / or logical operations with a set of signals and / or data. In some embodiments, such operations are delivered to processor 16 in the form of a sequence of processor instructions (eg, machine code or other type of encoding). Memory unit 18 may comprise volatile computer-readable media (eg, DRAM, SRAM) that store instructions and / or data accessed or generated by processor 16.

Input devices 20 may include keyboards and computer mice, among others, that allow the user to enter data and / or instructions into system 12. Output devices 22 may include display devices such as monitors. In some embodiments, the input devices 20 and the output devices 22 may share a common hardware component, as in the case of touch screen devices. Storage devices 24 include computer-readable media that allow non-volatile storage, reading, and writing of software instructions and / or data. Exemplary storage devices 24 include magnetic and optical discs and flash memory devices, as well as removable media such as CD and / or DVD drives and discs. Network adapters 26 allow system 12 to connect to a network 10 and / or other computer machines / systems. Controller hub 28 generically represents the plurality of system, peripheral, and chipset buses, and / or all other circuits that allow intercommunication of devices 16-26 of system 12. For example, controller hub 28 may include a controller memory, an input / output (I / O) controller, and an interrupt controller, among others. In another example, hub 28 may comprise the north bridge bus that connects processor 16 to memory 18, and / or the south bridge bus that connects processor 16 to devices 20, 22, 24, and 26, among others. .

Figure 2-B shows an exemplary hardware configuration of firewall 15 in some embodiments of the present invention. In the illustrated configuration, the server 15 comprises a server processor 16, a server memory 18, a set of server storage devices 124, and a set of network adapters 126. Processor 116 may comprise a microprocessor or other physical device configured to perform mathematical and / or logical operations on a set of data. Memory 18 may comprise volatile computer-readable media that stores instructions and / or data for execution and / or processing by processor 116. Server storage devices 124 comprise non-volatile computer-readable media such as hard drives, CDs and DVD ROMs, and flash memory, among others. Server network adapters 126 allow firewall 15 to connect and exchange data with other electronic devices over extended network 11.

Figure 3 shows a typical software configuration according to some embodiments of the present invention. The client system 12 is configured to expose a set of virtual machines (VMs). Although Figure 3 shows only one guest VM 32, some implementations can host multiple VMs (for example, hundreds) operating simultaneously. Each virtual machine comprises an emulation of a real physical machine / computer system and can run an operating system and a variety of software applications. Embodiments like the one illustrated in Figure 3 can be used to protect cloud computing clients from malicious software, such as software that attempts to steal proprietary, private and / or confidential data, or software that attempts to hijack and transform the system. client 12 on a botnet member. In such embodiments, client system 12 may represent a server computing system of a cloud service provider. In other exemplary embodiments, client system 12 represents a user's private device, such as a personal computer or mobile phone. Such devices often employ hardware virtualization, for example, to increase software portability or to strengthen security. In yet another exemplary embodiment, client system 12 may be configured as a decoy. In such embodiments, the client system 12 may expose multiple virtual machines, for example, one posing as a web server, another posing as a personal computer connected to a corporate network, and so on.

In some embodiments, a hypervisor 30 runs on client system 12, the hypervisor 30 comprising software configured to create or enable a plurality of virtualized devices, such as a virtual processor and virtual memory management unit, and to present such virtualized devices. to the software rather than the actual physical devices of the client system 12. Such operations are commonly known in the art as exposing a virtual machine. The hypervisor 30 may further allow multiple virtual machines to share the hardware resources of the host system 12, so that each VM operates independently and is not aware of other VMs running concurrently running on the client system 12. Hypervisor Examples Popular include VMware vSphere ™ from VMware Inc. and the open source Xen hypervisor, among others.

In the exemplary configuration illustrated in Figure 3, guest VM 32 runs a guest operating system (OS) 34, and a suite of applications 36a-b. Guest OS 34 can comprise any widely available operating system, such as Microsoft Windows®, MacOS®, Linux®, iOS® or Android ™, among others, providing an interface

ES 2 827 007 T3 between the applications running inside the VM 32 and the virtualized hardware devices of the guest VM 32. The applications 36a-b generically represent any user application, such as a word processor, a sheet application calculator, a graphics application, a browser, a social media application, and an electronic communication application, among others. In this invention, the guest OS 34 and applications 36a-b are said to run inside the guest VM 32, that is, they run on a virtual processor of the VM 32. Instead, the hypervisor 30 is said to be running. run outside of guest VM 32

In some embodiments, exposing the guest VM 32 comprises configuring a data structure used by the hypervisor 30 to manage the operation of the guest VM 32. Such a structure will be referred to in this invention as Virtual Machine State Object (VMSO). Exemplary VMSOs include the Virtual Machine Control Framework (VMCS) on Intel® platforms and the Virtual Machine Control Block (VMCB) on AMD® platforms. In some embodiments, processor 16 associates a region in memory with each VMSO, so that the software can reference a specific VMSO using a memory address or pointer (eg, a VMCS pointer on Intel® platforms).

Each VMSO may comprise data representing a current state of a respective virtualized processor displayed on client system 12. In multi-threaded configurations, hardware processor 16 may operate a plurality of cores, each core further comprising multiple logical processors, where each logical processor it can process a thread of execution independently of, and simultaneously with, other logical processors. Multiple logical processors can share some hardware resources, for example, a common MMU. In a multi-threaded environment, a different VMSO can be configured for each different logical processor. Each VMSO may comprise a guest status area and a host status area, the guest status area containing the status of the respective VM's CPU (i.e., of the respective virtualized processor) and storing the status area of host the current state of the hypervisor 30. In some embodiments, the VMSO guest status area includes the content of control registers (eg CR0, CR3, etc.), instruction pointer (eg RIP), general purpose registers (eg , EAX, ECX, etc.), and status registers (for example, EFLAGS) of the virtual processor of the respective VM, among others. The VMSO host status area can include a pointer (for example, an EPT pointer on Intel® platforms) to a page table configured for address translations for the respective VM.

In some embodiments, processor 16 may store a portion of a VMSO within dedicated internal registers / caches, while other portions of the respective VMSO may reside in memory 18. At any given time, at most one VMSO (referred to in this invention Current VMSO) can be loaded into a logical processor, identifying the virtual machine that currently has control of the respective logical processor. When processor 16 switches from running software within the VM (eg, application 36a in Figure 3) to running software outside of the respective VM (eg, hypervisor 30), processor 16 can save the current state of the device. processor in the guest status area of ​​the current VMSO. and load the VMSO host state into the processor. Conversely, when processor 16 switches from running software outside the VM to running software inside the respective VM, processor 16 can save the current state of the processor in the host state area of ​​the VMSO and load the guest state. current VMSO on processor 16.

In some embodiments, an introspection engine 40 runs outside of all exposed guest VMs on the respective client system. Introspection is an established term in the hardware virtualization art, which generically denotes gathering information about various aspects of the operation of a virtual machine from a position outside of the respective VM. In some embodiments of the present invention, introspection comprises operations such as monitoring processes running within guest VM 32, intercepting an attempt to execute a certain OS function or processor instruction within guest VM 32, intercepting a attempt to access a page of memory used by guest VM 32, and determine a location in memory 18 where the specific data used by guest VM is stored, among others. Engine 40 can be built into hypervisor 30, or it can be delivered as a separate and independent software component from hypervisor 30, but running at a processor privilege level substantially similar to that of hypervisor 30. A single engine 40 can be configured to introspect multiple VMs running on client system 12. Engine 40 may collaborate with hypervisor 30 to decrypt communications entering and / or leaving client systems 12. More specifically, engine 40 may be configured to approximately locate within memory 18 an encryption key used to encrypt an encryption key. message sent or received by guest VM 32, as detailed below.

The software running on the client system 12 may further comprise a network filter 42 configured to intercept communications entering or leaving the guest VM 32 and to exchange information with the introspection engine 40. The filter 42 may listen for ports of Specific network, for example, connections on port 443 that respect the TLS protocol. Filter 42 can run inside or outside of VM 32. When running outside of VM 32, a single network filter can monitor communications entering or leaving multiple VMs running on client system 12. To accomplish such monitoring, hypervisor 30 can route all communications within and / or or out of client system 12 through network filter 42. Filter 42 may have exclusive control of network adapter (s) 26, a configuration that can be implemented, for example, using Intel® VT-d® technology. When monitoring multiple VMs, filter 42 can maintain a VM-specific packet queue, that is, associate each intercepted network packet with a source and / or destination VM.

ES 2 827 007 T3

In some embodiments, the introspection engine 40 operates by detecting various events that occur during the execution of the software within the guest VM 32. Exemplary events detected by the introspection engine 40 include, for example, a processor exception and / or interrupt, an attempt to execute a particular guest OS function 34, a processor privilege change (for example, a system call) , an attempt to access (read from, write to and / or execute from) a particular memory location, etc. The introspection engine 40 may further be configured to determine the memory addresses of various software components running within the guest VM 32, as described below.

Some embodiments further comprise a utility agent 44 that runs within guest VM 32, agent 44 collaborating with introspection engine 40 to detect and analyze events that occur within guest VM 32. Agent 44 may comprise, for example, a handler that runs at the privilege level of guest OS 34 processor (eg, ring 0, kernel mode), and may be registered as a handler for various processor events such as faults page and hardware interrupts. An advantage of such configurations is that certain information is much easier to obtain from within a VM than from outside the respective VM, since an internal agent has access to all the functionality of the guest OS 34. A disadvantage is that agents running inside the guest VM 32 are potentially vulnerable to malicious software running inside the respective VM. To mitigate this risk, some implementations may inject agent 44 only temporarily into guest VM 32, and may delete agent 44 after agent 44 completes execution.

To detect events that occur within the guest VM 32, the introspection engine 40 may employ any method known in the virtualization art. An important category of procedures uses an attempt to access a particular memory location as an indicator of the occurrence of a particular event. To detect such a memory access attempt, some embodiments configure memory access permissions such that the attempt will violate the respective permissions. The violation is then intercepted by the introspection engine and / or utility agent 44. Virtual machines typically operate with virtualized physical memory, also known in the art as guest physical memory. Virtualized physical memory comprises an abstract representation of real physical memory 18, for example, as a contiguous address space specific to each VM, with portions of that space assigned to addresses within physical memory 18 and / or physical storage devices 24. In modern hardware virtualization platforms, such allocation is typically accomplished through dedicated data structures and mechanisms controlled by processor 16, known as second-level address translation (SLAT). Popular implementations of SLAT include Extended Page Tables (EPT) on Intel® platforms and Rapid Virtualization Indexing (RVI) / Nested Page Tables (NPT) on AMD® platforms. In such systems, virtualized physical memory is partitioned into units known in the art as pages, with a page representing the smallest unit of virtualized physical memory individually allocated to physical memory via SLAT, that is, the allocation between physical memory and virtualized is done with page granularity. All pages are typically a default size, for example 4 kilobytes, 2 megabytes, and so on. Partitioning of virtualized physical memory into pages is typically configured by the hypervisor 30. In some embodiments, the hypervisor 30 also configures the SLAT structures and thus the allocation between physical memory and virtualized physical memory. In some embodiments, a pointer to a SLAT data structure (eg, to a page table) is stored within the VMSO of the respective virtual machine. The actual mapping (translation) of a virtualized physical memory address to a physical memory address may comprise looking up the physical memory address in a translation-ahead buffer (TLB) of the client system 12. In some embodiments, the address translation comprises performing a page scan, which includes a set of successive address lookups in a set of page tables and / or page directories, and performing calculations such as adding a page offset to an address relative to the respective page.

Figure 4 illustrates such memory address allocation in one embodiment as shown in Figure 3. Upon exposure by hypervisor 30, guest VM 32 views a virtualized physical memory space 218 as its own physical memory space. A software object (eg, application 36a) running inside guest VM 32 is allocated virtual memory space 318 by guest OS 34. When the software object tries to access a content of an exemplary memory page 50a of space 318a, an address of page 50a is translated by the virtualized processor of guest VM 32 into an address of a page 50b of physical memory space virtualized 218, based on the page tables configured and controlled by the guest OS 34. The page address 50b is further assigned by the physical processor 16 to an address of a page 50c within the physical memory 18 using SLAT configured by the hypervisor 30.

Virtual address space 218 is commonly known in the art as guest physical memory, and an address within one such memory space is called a guest physical address (GPA). Address space 318 is typically called guest virtual memory and contains guest virtual addresses (GVAs). The addresses within physical memory 18 are commonly referred to as Host Physical Addresses (HPA). Therefore, a translation / address assignment such as 52 in Figure 4 is called a translation from GVA to GPA. Instead, address translations such as 54 are commonly referred to as GPA to HPA translations.

In some embodiments, hypervisor 30 configures its own virtual memory space 418 comprising a

ES 2 827 007 T3 representation of physical memory 18, and employs a translation mechanism (eg, page tables) to map addresses in space 418 to addresses in physical memory 18. In Figure 4, such exemplary mapping translates the address of a page 50f within virtual space 418 to the physical address of page 50c, and the address of a page 50d to the physical address of page 50e. Such allocations potentially allow any software object running at the processor privilege level of the hypervisor 30 to manage memory pages belonging to software objects running within various VMs running on the client system 12. In particular, the memory introspection engine 40 can thus enumerate, read, write and control access to the physical memory pages used by any process running within the guest VM 32.

In some embodiments, detecting an event that occurs within guest VM 32 involves introspection engine 40 collaborating with hypervisor 30 to establish memory access permissions within a SLAT data structure. These features can be platform specific, but access permissions are typically set with page granularity. For example, on Intel® platforms that support virtualization, the EPT entry for each memory page includes a set of access permission bits that indicate whether the respective page can be read, written, and executed, respectively. When an attempt to access a particular memory page violates an access permission set for the respective memory page, the respective attempt may trigger a processor event, such as an exception or a virtual machine exit event (VMExit on Intel platforms ®). In response to the processor event, the processor 16 may switch to execute an event handler routine outside of the respective VM, allowing the introspection engine 40 to detect the occurrence of the respective access violation. In an alternative embodiment, a memory access violation can trigger a processor exception (for example, a virtualization exception or #VE on Intel® platforms). In response to such processor events, processor 16 may switch to executing an event handler routine within the respective VM, that is, without exiting the respective VM. In embodiments having a utility agent 44 as shown in Figure 4, agent 44 may register as a virtualization exception handler, thus detecting memory access violations.

In some embodiments, a SLAT entry of a memory page further comprises fields (eg, bits) that indicate whether the respective page has been accessed and / or written to the respective page. Such bits are typically called dirty and accessed bits. Some embodiments use accessed and / or dirty bits to identify memory pages that are likely to contain encryption keys, as further shown below.

In some embodiments of the present invention, the introspection engine 40 is configured to monitor encrypted communications entering or leaving the guest VM. A communication session typically comprises a preliminary negotiation between the parties, followed by the actual exchange of encrypted messages. In the art, the former is commonly referred to as handshake, while the content of the message is commonly known as payload. The handshake comprises a set of exchanges that specify, among others, a cipher (i.e., an encryption algorithm) and an ingredient to derive an encryption key. Exemplary figures include block figures derived from the Advanced Encryption Standard (AES) and flow figures such as ChaCha-20. In some embodiments, the handshake may comprise an actual key exchange performed based on a specific protocol and / or additional steps to verify the identity of one or both parties. Depending on the cipher, the ingredients to derive the encryption key may comprise a set of random numbers, a public key of the communicating parties, etc.

A concrete example of a secure communication protocol is the Transport Layer Security (TLS) protocol described, for example, in Request for Comments (RFC) 5246 of the Internet Engineering Task Force Network Working Group ( IETF). The TLS protocol is currently used by most browsers, e-commerce, and secure electronic banking applications. A TLS session includes, but is not limited to, a unique session identifier, a cipher specification, and a master secret shared between the communicating parties. The master secret is normally calculated by each party separately, using ingredients exchanged during the first contact. The TLS handshake protocol comprises the following stages / phases:

a) Exchange greeting messages to agree cryptographic parameters for communication. A Client Hello message sent from a client to a server can indicate a list of supported digits and include a random number provided by the client, among others. A Server Hello message sent from the server to the client can indicate a choice of cipher from among those proposed by the client and include a random number provided by the server.

b) Perform authentication of the parties. The server can send a certificate confirming your identity and can request a certificate from the client. This stage can comprise a ClientCertificate message from the client and a ServerCertificate message from the server.

c) Exchanging the necessary cryptographic parameters to allow the client and the server to agree or calculate a shared secret (for example, a premaster secret). The cryptographic parameters can comprise a set of keys or other information depending on the chosen number. For example, the keys exchanged during this phase can be public cryptographic keys (Rivest-Shamir-Adleman, Diffie-Hellman, etc.) of the client and the server. This stage may comprise a ClientKeyExchange message transmitted by the client and / or a ServerKeyExchange message transmitted by the server. When Rivest-Shamir-Adleman (RSA) is used for authentication

ES 2 827 007 T3 server and key exchange, the client generates a pre-master secret, encrypted with the server's public key and sent to the server as part of the ClientKeyExchange message. The server then uses your private key to decrypt the premaster secret. When using Diffie-Hellman, each side calculates its own premaster secret based on a negotiated key.

d) Exchanging ChangeCipherSpec messages to indicate that each sending party will henceforth encrypt the outgoing messages from the session using the agreed cryptographic parameters.

e) Exchanging Finished messages (ClientFinished and ServerFinished) to formally end the session contact. To allow the client and server to verify that their peer has received and / or calculated the correct security parameters (for example, a shared secret) and that the handshake occurred without forgery by an attacker, ClientFinished messages and ServerFinish are encrypted. Each receiving party must attempt to decrypt the received Finished message; successful decryption indicates a successful handshake.

In the TLS protocol, each party calculates a master secret based on the cryptographic parameters exchanged during the handshake, for example based on the premaster secret and random numbers provided by the client and server. From the master secret, each side can then determine a set of session keys. The term session keys will be used in this invention to generically denote cryptographic parameter values ​​used to encrypt and / or decrypt communications during the current session. Exemplary session keys include a premaster secret, a master secret, server and client-side write keys, initialization security vectors / values, and message authentication codes (MAC), among others. In an embodiment using symmetric cryptography, the encryption and decryption keys are identical, so knowledge of an encryption key is sufficient for decryption. In asymmetric cryptography, the encryption and decryption keys differ. How the session keys are used therefore depends on the negotiated figure.

Some embodiments of the present invention are based on the observation that the session keys used for encryption during the current session must be calculated by each side before sending the Finished message of the handshake (otherwise, the respective message cannot be encrypted). In addition, the ingredients to derive the session keys are received by each side as part of the handshake, for example, as part of the Server-Hello, ClientKeyExchange and ServerKeyExchange messages. Therefore, the session keys are likely to appear in the client system memory at some point during the handshake. Some embodiments of the present invention use handshake timing to determine an approximate memory location of session keys.

Figure 5 shows an exemplary sequence of steps performed by the insight engine 40 in accordance with some embodiments of the present invention. In a sequence of steps 502-504, the engine 40 may collaborate with the network filter 42 to detect a handshake message transmitted between the client system 12 to a remote party (for example, the content server 13 in Figure 1). In one example, a connection request can come from an application running inside guest VM 32, for example a browser, and can indicate the intention to start an encrypted communication session, such as a TLS session, an SSH session , a VPN session, etc. As such, the connection request may comprise a handshake message (eg ClientHello) to server 13. In another example, the detected handshake message comprises a message from the server 13 (eg, a ServerHello), transmitted in response to a ClientHello received from the client system 12.

When a handshake message is detected, in a step 506 the introspection engine 40 can extract a set of handshake parameters, such as a session ID and an indicator of the number to be used for the session. In an embodiment that monitors TLS connections, step 506 may further extract cryptographic parameters such as random numbers provided by the server and / or the client. Introspection engine 40 may then instruct network filter 42 to forward the handshake message to its intended recipient VM (eg, guest VM 32 in Figure 3).

In a step 508, the introspection engine 40 may obtain an optimized memory snapshot of the guest VM 32. A memory snapshot comprises a copy of the contents of a set of memory pages used by the respective VM. In some embodiments, the optimized snapshot comprises the contents of a set of memory pages most likely to contain the session keys, or at least cryptographic parameter values ​​used to derive the session keys for the current communication session. Exemplary procedures for obtaining the optimized snapshot are described below.

A step 510 may collect the encrypted payload of the current session, obtaining a copy of the respective payload from network filter 42. In some embodiments, network filter 42 is configured to hold multiple data queues, eg indexed. by session ID and / or virtual machine. The network filter 42 can therefore unequivocally and consistently retrieve the encrypted payload of a session even when the respective payload is divided into multiple packets interleaved between other communications. Then, in a step 512, the introspection engine 40 can transmit the collected optimized memory snapshot, the handshake parameters, and the encrypted payload to the firewall 15 for analysis.

Figure 6 shows an exemplary sequence of steps performed by the introspection engine 40 to obtain a

ES 2 827 007 T3 optimized memory snapshot of guest VM 32. To derive the approximate memory location of session keys, some embodiments of the present invention identify a set of memory pages whose content has changed during a time interval which roughly matches the time the respective session keys were generated.

Memory pages whose content has recently changed, that is, pages that were recently written to, can be identified using any method known in the art. In one example, the introspection engine 40 may mark a set of memory pages used by guest VM 32 as not writable in a SLAT data structure associated with guest VM 32. Any subsequent attempt to modify the content of such a page will then constitute a memory access violation and thus trigger a processor event (for example, VM Exit or virtualization exception), which will then be intercepted by the introspection engine 40 and / or utility agent 44. In response to the interception of the event, the engine 40 may mark the respective page as writable and re-launch the respective VM, to allow the respective write to proceed. In such a way, the engine 40 may end up with a list of dirty memory pages, the content of which constitutes the desired optimized memory snapshot.

The above scenario is quite inefficient and computationally expensive. Various optimizations are possible on select hardware platforms. For example, on platforms that support accessed and / or dirty bits, some implementations may reset the dirty bit of a page table entry (EPT entry on Intel® platforms) of a memory page used by the VM. guest 32, and check the value of the dirty bit at some later time to determine if it has been written to the respective page. This mechanism can be further optimized. For example, certain generations of Intel® processors have a feature called Page Modification Log (PML), which automatically exports a list of pages whose content has changed to a memory location accessible to the memory introspection engine 40.

Another possible optimization strategy uses a real-time migration feature that some hypervisors (eg Xen®) use to efficiently migrate and / or clone virtual machines. The respective feature is built around a set of dirty log primitives that automatically crawl the pages that have been written to and export a list of such pages on a schedule basis.

The sequence of steps illustrated in Figure 6 identifies pages that have been modified during a time interval between a session event of a first type and a session event of a second type. Session events in this invention denote various phases of a communication protocol, for example, as described above in connection with the TLS protocol. Exemplary session events comprise, for example, sending and / or receiving messages that are part of a particular communication session (for example, a handshake message transmitted between client system 12 and server 13, a message containing a part of an encrypted payload of the respective session, etc.). A detection of 1^er event type (steps 522-524) triggers page change monitoring (step 526). In some embodiments, step 526 comprises suspending guest VM 32, resetting the dirty bit of the SLAT entries that correspond to the memory pages used by guest VM 32, and re-launching guest VM 32. In some embodiments, the set of memory pages whose writing will be monitored can be reduced, for example, to a set of pages used by the process (e.g., browser) conducting the current communication session, or by a process that handles encryption / decryption (eg LSASS.EXE on Windows®). The memory introspection engine 40 can identify pages used by the respective process / application by traversal data structures used by the guest OS 34 to manage threads and processes. The task of identifying such memory pages can be facilitated by collaborating with utility agent 44 running within guest VM 32 - agent 44 typically has access to much more information than engine 40.

The write monitoring is deactivated (step 534) after detecting the occurrence of a session event of a second type (steps 528-530), for example, the receipt of another handshake message of the respective session. A step 532 may suspend the execution of the guest VM 32, to prevent modifications to the memory while taking the memory snapshot. In a further sequence of steps 536-538, the engine 40 identifies the pages written to between the first and second session events, and copies the content of those pages as an optimized memory snapshot. In a further step 540, the introspection engine 40 can re-launch the guest VM 32.

In an alternate embodiment, the execution of the guest VM 32 is not suspended for the duration of the optimized memory snapshot collection. Such suspensions are likely to slow down the system and affect the user experience. Also, suspending guest VM 32 may not be desirable for security reasons, as it may reveal the fact that the respective VM is being monitored. As session keys are typically written once and not moved into memory, consistency of all pages used by guest VM 32 is not required. One simply has to ensure that the current session does not end (and therefore Therefore, the keys do not disappear) before the dirty pages are copied. Instead of stopping guest VM 32, some implementations use network filter 42 to manipulate the flow of communication into or out of guest VM 32. For example, filter 42 may delay the delivery of data packets from server 13 to guest VM 32 for the duration of memory snapshot collection. The lag may appear to software running inside guest VM 32 to be fairly normal network latency. To achieve delay functionality, some embodiments use a

ES 2 827 007 T3 inter-process notification mechanism for communicating between engine 40 and network filter 42. For example, engine 40 may notify filter 42 in response to a successful collection of the optimized memory snapshot. In turn, filter 42 may notify engine 40 in response to the interception of certain network packets (eg, Server-Hello or ServerFinished messages).

Upon observing that session keys are typically derived during the handshake portion of a session, various embodiments of the present invention use various handshake events as session 1 events.^er and the 2nd type. For example, in some embodiments, the events of 1^er types - which activate page monitoring - include interception by network filter 42 of a network packet comprising an ingredient to derive a session key for the respective session. Exemplary ingredients include a random number, key, and shared secret, among others. One such exemplary session event from 1^er type is a ServerHello message received from server 13. Other implementations may use. Other possible choices for a 1 event^er types include a ClientHello message from guest VM 32, a ClientKeyExchange, and a ServerKeyExchange message. Regarding the session events of the 2nd type - that deactivate the monitoring of pages, some implementations use the interception by the network filter 42 of an encrypted message transmitted to or from the guest VM 32. An example of an event of the 2nd type is the interception of a ClientFinished or ServerFinished message. Another possible choice event of the 2nd type is the interception of a packet comprising a part of an encrypted payload using a session key of the current session.

The exemplary procedures described above in connection with Figs. 5-6 apply to a single communication session. In practice, multiple sessions can be run simultaneously within a single VM, for example, through multiple instances of a browser (such as tabbed browsing), or through different applications running at the same time. Some implementations are configured to track dirty pages for each session separately. For clarity, the description below will focus on the particular task of collecting memory snapshots of TLS sessions, each snapshot comprising modified memory pages between a ServerHello message from each session and a ClientFinished message from the respective session.

Getting session-specific optimized snapshots poses an additional challenge to clarify an arbitrary sequence of session events. Some embodiments configure the page monitoring mechanism to identify all written pages between two consecutive events. However, such events can belong to different sessions and can be of the first type or of the second type (to borrow the nomenclature used previously in relation to Figure 6). To account for this ambiguity, some embodiments of the introspection engine 40 maintain a global list of currently active sessions, each entry in the list comprising information such as a session ID, a source Internet protocol (IP) address, number Source port number, destination IP address, destination port number and a timestamp of a ServerHello message for the respective session. Engine 40 may further maintain a global array of timestamps, storing at least one timestamp for each page of monitored memory. Each timestamp in the matrix may be indicative of a moment in time when it was written on the respective page. For this reason, the timestamp matrix will be considered in this invention as the page modification timestamp matrix.

Figure 7 shows an exemplary sequence of steps performed by the memory introspection engine in an embodiment configured to track multiple simultaneous TLS sessions. A step 552 initializes the matrix of page modification timestamps. Step 552 may further comprise setting the page modification detection mechanism (eg, PML, reset dirty bits, etc.). A sequence of steps 554-556 listens for events of type Hello or Finished. When an event is detected, in a step 558, the introspection engine 40 may invoke the page modification detection mechanism to identify currently dirty pages, that is, pages of memory whose content has changed since the previous detected event, regardless of if it was a Hello or Finished message. A step 560 may then update the matrix of page modification timestamps so that timestamps corresponding to dirty pages are updated to the current timestamp, or to a timestamp indicative of the occurrence of the detected event. at the moment. When the respective event is 1^er type (eg, ServerHello), in a step 564 the engine 40 can initialize a new session data structure, filling in a session ID, a source and destination IP address and ports, among others. A further step 566 records a timestamp indicative of the current ServerHello event, which in this invention will be considered as the Hello timestamp of the respective session.

When the currently detected event is of the 2nd type (eg ClientFinished), at a step 570, the introspection engine 40 may step through the array of page modification timestamps. For each page, some embodiments may compare the page modification timestamp of the respective page with the Hello timestamp of the respective session (ie, of the session to which the currently detected event belongs). When the modification timestamp indicates that the respective page has been written after the Hello event of the respective session, the engine 40 may include the respective page in the optimized memory snapshot of the respective session.

Figure 8 shows exemplary software running on firewall 15, including decryption engine 60 in accordance with some embodiments of the present invention. For each monitored communication session,

ES 2 827 007 T3 engine 60 can receive session data from the respective client system (for example, client systems 12a-d in Figure 1), such as a handshake parameter set 72, an optimized memory snapshot 70 and / or an encrypted payload 74. Such data may further comprise pointers that uniquely associate each item with a particular client system, VM, and / or communication session. Handshake parameters 72 may comprise an indicator of a cipher used to encrypt payload 74. Optimized memory snapshot 70 comprises a copy of a memory page content from a client system, as described above. Payload 74 comprises a portion of an encrypted communication (eg, a network packet).

Figure 9 shows an exemplary sequence of steps performed by decryption engine 60 in accordance with some embodiments of the present invention. In response to the receipt of session data from the client system 12 (step 582), in a step 584 the engine 60 may extract from the session data an indicator of the figure used in the respective session. Decryption engine 60 may then select a decryption procedure / algorithm based on the cipher. A sequence of steps 586-588-590 is then repeated in a loop until a termination condition is satisfied, for example, until a successful decryption of the payload is achieved, or until an allotted time period expires. for decryption.

Attempts to decrypt the payload can proceed according to any method known in the art of cryptography. The procedure for collecting the optimized memory snapshot was designed so that the session keys, or at least the values ​​of the cryptographic parameters used to derive the encryption and decryption keys for the respective session, are likely to reside within the snapshot of respective memory. The byte size of the session keys may be known a priori, or it may be derived from the encryption parameters received from the client system 12. However, the precise location of the session keys within the snapshot may not be known. Therefore, some implementations may search for the key material through trial and error. In one such example illustrated in Figure 9, a step 586 may derive a candidate decryption key from the optimized memory snapshot. In an embodiment using symmetric cryptography (eg TLS protocol), the encryption and decryption keys are identical, therefore a candidate decryption key may comprise, for example, a byte sequence of the snapshot, the sequence having the required byte size. In a step 588, the engine 60 may attempt to decrypt at least a portion of the payload of the respective session using the candidate keys. Success can be evaluated using various procedures known in the art. For example, some embodiments calculate an information entropy from the decrypted message. Low entropy typically indicates successful decryption, although such procedures are known to produce false positives or false negatives.

An alternative approach to decryption uses what is known in the art as a known plaintext attack. One such embodiment exploits the fact that the decryption engine 60 has access to an encrypted version of a known message, eg, the content of a ClientFinished and / or ServerFinished (encrypted) message exchanged during the respective session. The format and clear text of such messages is known a priori, being documented in the TLS protocol.

Some embodiments of the present invention allow decryption of some or all communications between a client system and a remote party. Examples of such communications include any encrypted communication using symmetric or asymmetric key algorithms, including Secure Socket Layer (SSL) / Transport Layer Security (TLS), secure command line (TLS) connections ( Secure Shell, SSH), Virtual Private Network (VPN) connections, and onion routing / anonymity network connections (eg TOR software). Exemplary applications of the procedures outlined include malware detection and analysis, intrusion detection and surveillance, among others.

In an exemplary application, a computer system that houses at least a part of the decryption system is part of a decoy system. Decoys are typically configured to allow the installation of malicious software and / or to allow an intruder to take control of some aspects of the respective computer system. Malicious software and intruders can then use an encrypted channel to communicate with external entities, such as command and control (C&C) servers. By allowing the decryption of such communications, some implementations can facilitate the investigation into malware, intrusion and / or hacking procedures.

Another exemplary antimalware use of some embodiments involves detecting malicious content before it infiltrates a client system. In some advanced malware attack scenarios, a malicious software agent reaches the client through encrypted communication with an otherwise benign server, for example via email (phishing) or online advertising. Due to encryption, the agent typically cannot be detected until it has been unzipped and installed on the host, or even later, when it performs some action indicative of malware. Some embodiments of the present invention may allow early detection and incapacitation of such agents.

In another exemplary application, cloud service providers can use some implementations to inspect encrypted traffic in near real time and quickly detect malicious data flowing to or from their servers. Such detection can prevent the respective servers from acting as a launch pad

ES 2 827 007 T3 for a malicious attack, for example a distributed denial of service (DDOS) attack.

Decryption of encrypted communication is an extremely difficult undertaking. Some conventional approaches to breaking encryption attempt to avoid decryption entirely. Such procedures include, for example, modifying encryption libraries to provide additional information or introducing back doors that allow a user to discretely gain access to the plaintext of the respective communication, to an actual encryption key, or to some other information that lead to a key. Such approaches are considered dangerous as they can weaken Internet security in the long run. They are also inconvenient for being typically non-portable, that is, effective only on certain hardware platforms and / or operating systems. Another drawback is that a modification of a cryptographic library is visible to the software running on the respective client and can therefore be detected and neutralized.

Modern figures can only be cracked using some version of a brute force attack, which typically carries a substantial computational cost. One such attack involves testing several candidate keys, until one finally works. Some conventional decryption systems / procedures search the memory of the client system for key material. However, not knowing the actual location of the key material can make such procedures impractical due to the immense computational expense required for the search. Furthermore, stopping the respective machine for the time required to acquire large memory dumps is likely to negatively affect the user experience. Some conventional approaches attempt to optimize the search for key material by setting branch points in order to obtain memory dumps at certain times of execution. However, bypass points are predefined and therefore can be broken if the underlying system and / or communication software is updated.

Some embodiments of the present invention are based on two key observations. First, a large number of client systems that potentially benefit from decryption run in hardware virtualization configurations (virtual machines). Examples include server farms and virtual desktop infrastructure cloud providers. To take advantage of such configurations, some embodiments of the present invention place an introspection engine outside of a virtual machine that performs encrypted communication, at a processor privilege level of a hypervisor that exposes the respective VM. The introspection engine can use virtualization techniques to access and inspect the contents of the memory used by the respective VM, potentially without knowledge or interference from the software running within the respective VM. Thus, a single introspection engine can discretely monitor the communications carried out by multiple VMs running simultaneously on the respective client system.

The second observation is that the encryption keys, or at least the cryptographic parameters used to derive the respective keys, are exchanged by the communication partners during a specific phase of a session, for example during a handshake. Some embodiments use this observation to derive an approximate location of the session keys, thus allowing a reduction of the memory search area from hundreds of megabytes in conventional procedures to a few pages of memory (for example, tens of kilobytes to a few megabytes ). This substantially reduces the computational decryption effort, making a brute force attack feasible.

Some implementations use modern processor hardware optimizations, such as the ability to set accesses and / or dirty flags within a page table entry, or the page modification record (PML) feature of some Intel® processors, to identify a set of memory pages whose content changes during a time interval that includes the exchange and / or generation of session keys. Some embodiments then search for the key material within the content of the respective memory pages.

By locating session keys based on the characteristics of the communication protocol, rather than relying on specific hardware or software characteristics of the client system / virtual machine, some implementations allow decryption of communications on various devices (personal computers, mobile phones, household appliances, etc.), as well as on client systems running multiple heterogeneous virtual machines, regardless of the operating system and communication application (eg browser, messaging application, VPN software, etc.).

To avoid detection by software running inside the monitored VM, some implementations disguise the occasional delays caused by collecting an optimized memory snapshot from the respective VM as network latency. In one example, the introspection engine collaborates with the network filter to delay the delivery of certain network packets to the monitored VM for the duration of the memory snapshot acquisition. For software running inside the VM, these delays may appear to be caused by transmission problems on the network. Furthermore, to avoid affecting the user experience, some implementations offload the computational burden of decryption onto a separate machine (firewall). Therefore, the actual decryption can be carried out offline.

It will be apparent to one skilled in the art that the above embodiments can be altered in many ways without departing from the scope of the invention. Accordingly, the scope of the invention should be determined by the following claims and their legal equivalents.