Physical side-channel monitoring of software program

Abstract

Systems and methods are disclosed for physical side-channel monitoring of a software program. In one embodiment, a method performed by a server for enabling program- specific side channel analysis (SCA) comprises receiving, from an orchestrator, an instruction to execute a first software program, executing the first software program on at least one processor core of at least one processor at the server, and sending measurement data for the first software program to a SCA monitor. The measurement data for the first software program comprises, for each processor core for each processor on which the first software program is executed at the server, for each time period during which the first software program was executed on the processor core, one or more physical side-channel measurements related to the processor core made during the time period during which the first software program was executed by the processor core.

Description

[0001] PHYSICAL SIDE-CHANNEL MONITORING OF SOFTWARE PROGRAM

[0002] Technical Field

[0003] The present disclosure relates to physical side-channel monitoring of execution of a software program for anomaly detection.

[0004] Side-channel leakage, which is also referred to as side-channel emission, is defined as a non-intended information channel from a device. The side-channel can consist of e.g., power consumption, electromagnetic (EM) emissions, thermal signatures, sound, and / or optical emissions. An attacker can utilize these leakages to extract sensitive information from a device, e.g., to extract a cryptographic key utilized to encrypt information.

[0005] Examples of attacks leveraging side-channel emissions include methods to extract cryptographical keys from cryptographic algorithms implemented in software executing on Subscriber Identity Modules (SIMs) of mobile devices (e.g., mobile smartphones) and Central Processing Units (CPUs). Further examples include attacks on hardware implementations of cryptographic algorithms such as, for example, the cryptographic standard algorithm, Advanced Encryption Standards (AES), and the Post-Quantum Cryptography (PQC) standardized KYBER.

[0006] Side-channel emissions can also be used to reverse engineer software running on a CPU or microcontroller.

[0007] The side-channel emissions are typically unintendedly emitted by the device, and although sometimes maliciously exploited by attackers to extract secrets, it can also be used to monitor the state of the device as a means of detecting malicious software alterations. In these cases, a monitor, which is often external, registers the side-channel leakage from the device and concludes whether the device is behaving normally according to pre-defined criteria.

[0008] Several methods for side-channel monitoring exist. In some solutions, the monitoring device is oblivious to the internal state of the device (i.e., the monitored device) and only determines “normal” or “abnormal” side-channel leakage. In other solutions, the monitoring device can connect certain states or operations within the monitored device to certain side-channel patterns. The latter may also detect “illegal” state transitions within an execution, i.e., where the execution flow of the monitored device is abnormal.

[0009] The most prominent advantage of side-channel monitoring is that it is very difficult to avoid or intentionally shape the side-channel emissions, and the monitoring device may be physically or logically separated from (processing part ol) the monitored device. This makes it very difficult for an attacker to remain undetected as an attack on a monitored device will unavoidably cause abnormal changes in the side-channel emissions. This is beneficial in both high-security environments and as a complement to “classic” monitoring solutions. Low-cost generic hardware for side-channel measurements is nowadays available. One example is the ChipWhisperer® series of devices provided by NewAE Technology, Inc.

[0010] Side-channel monitoring of software containers is a relatively new field and is usually performed using performance indicators, e.g., CPU utilization and memory utilization.

[0011] Summary

[0012] Systems and methods are disclosed for physical side-channel monitoring of a software program. In one embodiment, a method performed by a server for enabling program-specific side channel analysis (SCA) for anomaly detection comprises receiving, from an orchestrator, an instruction to execute a first software program and executing the first software program on at least one processor core of at least one processor at the server. The method further comprises sending measurement data for the first software program to an SCA monitor for anomaly detection. The measurement data for the first software program comprises, for each processor core of the at least one processor core for each of the at least one processor on which the first software program is executed at the server, for each time period of one or more time periods during which the first software program was executed on the processor core, one or more physical side-channel measurements related to the processor core made during the time period during which the first software program was executed by the processor core. In this manner, powerful black box monitoring of a remotely executing software program is enabled.

[0013] In one embodiment, the measurement data for the first software program further comprises, for each processor core of the at least one processor core for each of the at least one processor on which the first software program is executed at the server, information indicative of the one or more time periods during which the first software program was executed on the processor core.

[0014] In one embodiment, the one or more physical side-channel measurements related to the processor core comprise one or more physical side-channel measurements indicative of power consumption of the processor core.

[0015] In one embodiment, the method further comprises, prior to sending the measurement data for the first software program to the SCA monitor, receiving, from the SCA monitor, a request for the measurement data for the first software program and obtaining the measurement data for the first software program by mapping the time periods during which the first software program was executed on the at least one processor core of the at least one processor to corresponding physical side-channel measurements stored for the at least one processor core of the at least one processor for the respective time periods. In one embodiment, the request for the measurement data for the first software program is protected. In one embodiment, the request for the measurement data for the first software program is protected via any one or more of the following protection mechanisms: a timestamp, a cryptographic signature, a message authentication code (MAC), using a secure channel between the server and the SCA monitor. In one embodiment, a function at the server that receives the request from the SCA monitor is trusted by the SCA monitor. In one embodiment, the method further comprises validating the request prior to obtaining the measurement data for the first software program.

[0016] In one embodiment, sending the measurement data for the first software program to the SCA monitor comprises sending the measurement data for the first software program to the SCA monitor via a secure channel between the server and the SCA monitor and / or in an encrypted manner.

[0017] In one embodiment, the measurement data further comprises, for each processor core of the at least one processor core for each of the at least one processor on which the first software program is executed, information indicative of the processor core.

[0018] In one embodiment, each of the one or more physical side-channel measurements related to the processor core made during the time period during which the first software program was executed by the processor core is a physical side-channel measurement made at a specific time during the time period.

[0019] In one embodiment, the method further comprises performing and storing physical-side channel measurements and corresponding timestamps related to one or more processing cores in one or more processors at the server, wherein the one or more physical side-channel measurement related to the processor core made during the time period during which the first software program was executed by the processor core are a subset of the stored physical-side channel measurements that were made on the processor core and have corresponding timestamps within the time period. In one embodiment, performing and storing the physical-side channel measurements comprises continuously performing and storing the physical-side channel measurements and corresponding timestamps for each of one or more processing cores in each of one or more processors at the server. In one embodiment, performing and storing the physical-side channel measurements comprises performing and storing the physical-side channel measurements and corresponding timestamps for at least one of one or more processing cores in at least one of one or more processors at the server responsive to an activation trigger. In one embodiment, the activation trigger is reception of an associated request to activate physical side-channel measurements. In one embodiment, the activation trigger is reception of an associated request to activate physical sidechannel measurements for the first software program.

[0020] In one embodiment, the method further comprises obtaining and storing execution data comprising, for each processor core of the at least one processor core for each processor of the at least one processor on which the first software program is scheduled to execute: information indicative of the processor core and information indicative of one or more time periods during which the first software program is executed on the processor core in accordance with the scheduling, wherein the one or more time periods during which the first software program was executed on the processor core are identified based on the stored execution data.

[0021] In one embodiment, the first software program is executed in a trusted execution environment on the server.

[0022] In one embodiment, each of the one or more physical side-channel measurements related to the processor core made during the time period during which the first software program was executed by the processor core is a physical side-channel measurement made at a specific time during the time period for at least one execution unit of the processor core.

[0023] In one embodiment, each of the one or more physical side-channel measurements related to the processor core made during the time period during which the first software program was executed by the processor core is a physical side-channel measurement made at a specific time during the time period for the processor core.

[0024] In one embodiment, the instruction from the orchestrator to execute the first software program comprises an instruction to allow the first software program to be executed at least a certain number of times before sending the measurement data to the SCA monitor.

[0025] Corresponding embodiments of a server are also disclosed. In one embodiment, a server for enabling program-specific SCA for anomaly detection is adapted to receive, from an orchestrator, an instruction to execute a first software program, execute the first software program on at least one processor core of at least one processor at the server, and send measurement data for the first software program to a SCA monitor for anomaly detection. The measurement data for the first software program comprising, for each processor core of the at least one processor core for each of the at least one processor on which the first software program is executed at the server, for each time period of one or more time periods during which the first software program was executed on the processor core, one or more physical side-channel measurements related to the processor core made during the time period during which the first software program was executed by the processor core. In one embodiment, a server for enabling program-specific SCA for anomaly detection comprises one or more processors each comprising one or more processor cores and at least one scheduler. The at least one scheduler is configured to receive, from an orchestrator, an instruction to execute a first software program, execute the first software program on at least one processor core of at least one processor at the server, and send measurement data for the first software program to a SCA monitor for anomaly detection. The measurement data for the first software program comprising, for each processor core of the at least one processor core for each of the at least one processor on which the first software program is executed at the server, for each time period of one or more time periods during which the first software program was executed on the processor core, one or more physical side-channel measurements related to the processor core made during the time period during which the first software program was executed by the processor core.

[0026] Embodiments of a method performed by a SCA monitor for program-specific anomaly detection are also disclosed. In one embodiment, a method performed by a SCA monitor for program-specific anomaly detection comprises receiving, from a server, measurement data for a first software program. The measurement data comprises, for each processor core of at least one processor core for each of at least one processor on which the first software program was executed at the server, for each time period of one or more time periods during which the first software program was executed on the processor core, one or more physical side-channel measurements related to the processor core made during the time period during which the first software program was executed by the processor core. The method further comprises processing the measurement data to form a measurement profile of the first software program and performing anomaly detection for the first software program based on the measurement profile of the first software program and an anomaly detection model for the first software program.

[0027] In one embodiment, the measurement data for the first software program further comprises, for each processor core of the at least one processor core for each of the at least one processor on which the first software program is executed at the server, information indicative of the one or more time periods during which the first software program was executed on the processor core.

[0028] In one embodiment, the method further comprises sending, to the server, one or more requests for the measurement data for the first software program, wherein receiving the measurement data for the first software program from the server comprises receiving the measurement data for the first software program from the server responsive to the one or more requests. In one embodiment, the one or more physical side-channel measurements related to the processor core comprise one or more physical side-channel measurements indicative of power consumption of the processor core. In one embodiment, each of the one or more requests for the measurement data for the first software program is protected. In one embodiment, each of the one or more requests for the measurement data for the first software program is protected via any one or more of the following protection mechanisms: a timestamp, a cryptographic signature, and using a secure channel between the server and the SCA monitor.

[0029] In one embodiment, a function at the server that receives the one or more requests from the SCA monitor at the server is trusted by the SCA monitor.

[0030] In one embodiment, the one or more requests for the measurement data for the first software program consist of a single request for the measurement data for the first software program.

[0031] In one embodiment, sending the one or more requests for the measurement data for the first software program and receiving the measurement data responsive to the one or more requests comprises sending, to the server, a first request for measurement data for the first software program, receiving, from the server, first measurement data for the first software program, responsive to the first request, sending, to the server, one or more additional requests for measurement data for the first software program, and receiving, from the server, one or more additional measurement data for the first software program, responsive to the one or more additional requests, respectively, wherein the measurement data for the first process comprises the first measurement data for the first process and the one or more additional measurement data for the first process.

[0032] In one embodiment, receiving the measurement data for the first software program from the server comprises receiving the measurement data for the first software program from the server via a secure channel between the server and the SCA monitor and / or in an encrypted manner.

[0033] In one embodiment, the measurement data further comprises, for each processor core of the at least one processor core for each of the at least one processor on which the first software program is executed at the server, information indicative of the processor core.

[0034] In one embodiment, each of the one or more physical side-channel measurements related to the processor core made during the time period during which the first software program was executed by the processor core is a physical side-channel measurement made at a specific time during the time period.

[0035] In one embodiment, during processing of the measurement data to form the measurement profile of the first software program, one or more of the physical side-channel measurements are discarded. In one embodiment, the one or more discarded physical side-channel measurements comprise either or both of: one or more of the physical side-channel measurements that were made within a predefined amount of time prior to an end of their respective time periods and one or more of the physical side-channel measurements that were made within a predefined amount of time after a start of their respective time periods.

[0036] In one embodiment, the first software program is executed on the server and one or more additional servers, and processing the measurement data to form the measurement profile of the first software program comprises processing the measurement data for the first software program received from the server together with measurement data for the first software program received from the one or more additional servers to form the measurement profile of the first software program. In one embodiment, the measurement data is pre-processed to normalize the measurement data across the server and the one or more additional servers prior to processing to form the measurement profile of the first software program.

[0037] Corresponding embodiments of a SCA monitor are also disclosed. In one embodiment, a SCA monitor for program-specific anomaly detection is adapted to receive, from a server, measurement data for a first software program, the measurement data comprising, for each processor core of at least one processor core for each of at least one processor on which the first software program was executed at the server, for each time period of one or more time periods during which the first software program was executed on the processor core, one or more physical side-channel measurements related to the processor core made during the time period during which the first software program was executed by the processor core. The SCA monitor is further adapted to process the measurement data to form a measurement profile of the first software program and perform anomaly detection for the first software program based on the measurement profile of the first software program and an anomaly detection model for the first software program.

[0038] In one embodiment, a computing system for implementing a SCA monitor for programspecific anomaly detection comprises a network interface and one or more processors associated with the network interface. The one or more processors are configured to cause the computing system to receive, from a server, measurement data for a first software program, the measurement data comprising, for each processor core of at least one processor core for each of at least one processor on which the first software program was executed at the server, for each time period of one or more time periods during which the first software program was executed on the processor core, one or more physical side-channel measurements related to the processor core made during the time period during which the first software program was executed by the processor core. The one or more processors are further configured to cause the computing system to process the measurement data to form a measurement profile of the first software program and perform anomaly detection for the first software program based on the measurement profile of the first software program and an anomaly detection model for the first software program.

[0039] The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure.

[0040] Figure 1 illustrates a system in accordance with embodiments of the present disclosure;

[0041] Figures 2A and 2B illustrate the operation of the system of Figure 1, in accordance with some embodiments of the present disclosure;

[0042] Figure 3 is a signaling diagram that illustrates the operation of the system of Figure 1, in accordance with an embodiment of the present disclosure;

[0043] Figure 4 is a signaling diagram that illustrates the operation of the system 100 of Figure 1, in accordance with another embodiment of the present disclosure; and

[0044] Figure 5 is a schematic block diagram of an example of a server according to some embodiments of the present disclosure.

[0045] Figure 6 is a schematic block diagram of an example of a Side-Channel Analysis (SCA) monitor according to some embodiments of the present disclosure.

[0046] Figure 7 is a schematic block diagram of an example of a computing system that implements the Side-Channel Analysis (SCA) monitor according to some embodiments of the present disclosure.

[0047] Detailed

[0048] The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure.

[0049] A Power Management Unit (PMU), sometimes called a power controller or power configuration unit, is responsible for controlling and measuring the voltage supplied to the different components in a system. The PMU can receive instructions to temporarily increase or decrease the span of allowed power (i.e., current) to a component, e.g., corresponding to defined power budgets given to a certain component running a certain process.

[0050] Modem processors, e.g., Intel® processors after the Haswell series (2016), support percore power control and measurements within the Central Processing Unit (CPU), i.e., that each CPU core can be measured and controlled individually. The PMU often provides an interface to the Operating System (OS) for measurements and control of frequency, voltage, and power state of different hardware components. In the x86 ecosystem (and some ARM based devices), the Advanced Configuration and Power Interface (ACPI) provides functionality through which the OS can request changes to power and performance settings. The framework for dynamically scaling frequency and voltage settings to save power for different hardware is commonly referred to as Dynamic Voltage and Frequency Scaling (DVFS).

[0051] The power can either be measured directly or as a function of either frequency (which is roughly linearly proportional to power consumption), voltage (roughly quadratically proportional to power consumption), or a combination of frequency and voltage. Apart from direct measurements of current, the combination of voltage and frequency is most exact as there exists a covariance between frequency and voltage in terms of power consumption.

[0052] The PMU can respond to queries for current power consumption of a component. This is a feature that can be very useful for managing power budgets of components and / or processes. However, these queries have been abused in side-channel attacks, such as PLATYPUS (see M. Lipp et al., "PLATYPUS: Software-based Power Side-Channel Attacks on x86," 2021 IEEE Symposium on Security and Privacy (SP), San Francisco, CA, USA, 2021, pp. 355-371, doi: 10.1109 / SP40001.2021.00063.), where continuous querying allows an attacker to extract information about the state of the process / component. In the PLATYPUS attack, the attackers extract a cryptographic key from a process running on a CPU. As a mitigation, several PMUs are now requiring the requesting process to be privileged, throttling their responses, and / or lowering their granularity in their response.

[0053] It can be determined, from these attacks, that the PMU is capable of providing accurate- enough measurements to monitor processes running on the device.

[0054] In many hardware realizations, the PMU runs at a significantly lower clock frequency than the main CPU cores, meaning that the measurements will have a lower sample rate than the clock speed. In some scenarios, this is not a problem, in others, it can be compensated by repeated measurements of the same process, e.g., during an enrollment phase, to ensure that the measurements obtained during a validation phase can be mapped at least one subset of enrollment measurements.

[0055] Modem cloud computing devices contain CPUs having a large number of processing cores, a large amount of memory, and network capabilities. These resources can be virtualized and shared in various ways by cloud software. One important technique used by most schedulers is to share the physical resource in the temporal domain. More than one task or program or job can be present inside the memory at one point of time. When the second program is to be executed, a context switch occurs, storing the current state of the first program and loading the state of the second program. Note that as used herein a “software program” one of: uncompiled source code, compiled source code, or a software process being executed on the server, depending on context. For example, when being sent (e.g., communicated or downloaded) from one network node to another, the software program may be uncompiled or compiled source code. When executed by a processor(s), the software program is executed in a software process.

[0056] The time a program is allowed to execute before context switch is sometimes called a “time quantum”. For example, in Ubuntu, the default value of the time quantum is 100 milliseconds (ms) (i.e., ~ 108clock cycles for a Gigahertz (GHz) processor). An OS scheduler that has multiple CPU cores will additionally schedule tasks on the different available processing cores, meaning that a process or thread may execute on different processing cores for different time quantums.

[0057] A one-shot modeling for side-channel monitoring procedure has been disclosed for learning and using an architecture for a neural network with three distinct phases. These three phases are as follows:

[0058] 1. Using a large amount of un-labeled side-channel traces from many different processes to learn an embedded representation using methods similar to those recently used for learning pre-trained representations for audio, images, or language models.

[0059] 2. Using a large number of side-channel traces from different processes, as well as modified versions of these processes (that should not be considered to be the same) with more than one trace from each process and use this to leam a similarity function that takes two traces and outputs if they are two measurements of the same or different processes.

[0060] 3. Using the learned similarity function in a one-shot anomaly detection setting by comparing a first obtained trace (representing current version of a process) to a second trace from the same process and outputting whether the traces are measurements of the same or different processes.

[0061] Black box monitoring can be described as a situation where the monitor does not have control and does not know what’s happening inside the monitored process. The monitor is only able to observe externally visible traits, such as traffic, CPU utilization, etc. This is suitable where the monitor is not the same as the software owner, as the confidentiality of the software can be preserved.

[0062] The existing technology related to remote monitoring of side-channels includes the following: • United States (U.S.) Patent Number 1O,872,149B1 entitled “Anomaly detection based on side-channel emanations” describes a system where states of code running in a device are correlated with side-channel emissions, creating a non-deterministic finite automation graph which can be traversed to determine if respective state produces the correct sidechannel emission. If not, the monitor can take corrective action for the device running the code.

[0063] • A. S. M. Asadujjaman et al., "5GFIVer: Functional Integrity Verification for 5G Cloud- Native Network Functions," 2022 IEEE International Conference on Cloud Computing Technology and Science (CloudCom), Bangkok, Thailand, 2022, pp. 162-169, doi: 10.1109 / CloudCom55334.2022.00032. (hereinafter referred to as the “5GFIVer Paper”) describes a black box monitoring approach where logical side-channels such as CPU utilization and memory consumption is used.

[0064] There are certain problems associated with existing side-channel monitoring solutions. Side-channel monitoring is a well-known solution for obtaining hard-to-falsify measurements of current processes within a device. Physical side-channels (e.g., power and electromagnetic emissions) are more difficult to falsify than logical side-channels, but monitoring of physical sidechannels requires specific components, e.g., a PMU or an external monitor to obtain the measurements. However, there is no existing side-channel monitoring solution for how to efficiently use physical side-channels to monitor cloud-based containers and other as-a-service offerings with conventional side-channel monitoring, requiring external hardware.

[0065] In particular, none of the existing technology described herein provide a side-channel monitoring solution that can take into account when a software program (e.g., a cloud-based container) has been active on a specific processor or a specific processing core of a specific processor, which may be non-continuous. Instead, the existing side-channel monitoring solutions measure the whole or parts of a system without correlating it to a specific software program or a specific processor / processing core.

[0066] United States (U.S.) Patent Number 10 / 872, 149B1 entitled “Anomaly detection based on side-channel emanations” mentions correlating operation status with side-channel measurements; however, the solution described therein requires (a) external probes for analog measurements and (b) the monitored device to explicitly communicate “app events” externally, making it very difficult to synchronize if the software programs are not continuously executing.

[0067] Hence, none of existing side-channel monitoring solutions provide a suitable approach for a cloud-based scenario where the software programs can execute non-continuously on several different processing cores and / or processors, possibly located in several different servers. Also, the 5GFIVer Paper describes a black box approach to monitor virtualized network functions in a 5thGeneration (5G) system using logical side-channels such as Central Processing Unit (CPU) utilization and memory consumption. However, the black box approach described in the 5GFIVer Paper does not use physical side-channels, but rather uses logical side-channels to provide a logical side-channel monitoring solution that can be used to complement a physical sidechannel monitoring solution as a part of a defense-in-depth approach. Furthermore, the 5GFIVer Paper does not take into consideration that the software programs can execute non-continuously.

[0068] Embodiments of solutions for addressing the aforementioned and / or other challenges are disclosed herein. In particular, systems and methods are disclosed for performing remote black box monitoring of software programs by using physical side-channels. In general, embodiments of the present disclosure involve an orchestrator, e.g. Kubemetes, which allocates nodes and quotas for resource usage on those nodes. A node is a virtual device or a physical device (e.g., a physical server) on which workloads can be run. In a cloud environment, there are multiple layers of schedulers (e.g., Kubemetes scheduler, hypervisor scheduler, Operating System (OS) scheduler) responsible for scheduling software programs (e.g., from one or multiple tenant(s)) onto nodes and eventually on physical processing (e.g., Central Processing Unit (CPU)) cores. Servers, on which nodes run, also include respective Management Units (MUs) (e.g., PMUs).

[0069] Embodiments of the present disclosure relate to how the orchestrator, scheduler(s), and MU(s) cooperatively operate to enable physical side-channel monitoring for a software program that is executed on one or more processor cores of one or more processors of at least one server. In general, the orchestrator, scheduler(s), and MU(s) obtain physical side-channel measurements (e.g., power consumption related measurements, electromagnetic radiation measurements, temperature measurements) for physical resources (e.g., at least one processor core of at least one processor) during execution of the software program for which side-channel monitoring is desired and track the physical resources (e.g., processing cores) and time periods for which the associated physical side-channel measurements should be considered for side-channel monitoring for the software programs.

[0070] In some embodiments, for a particular software program, the server(s) executes the software program on one or more processing cores of one or more processors at the server(s) in accordance with a schedule. For each time period during which the software program is executed, the server(s) stores information indicative of the time period (e.g., execution start time and execution stop time) during which the software program is executed and information indicative of the processing core (and optionally processor if there are more than one processor) on which the software program is executed during that time period. During or after execution of the software program, a Side Channel Analysis (SCA) monitor requests measurement data for the software program from the server(s). The server(s) responds by sending the requested measurement data for the software program to the SCA monitor. The measurement data includes for each processor core of each of at least one processor on which the software was executed:

[0071] • information indicative of one or more time periods during which the software program was executed by the processor core,

[0072] • for each of the time periods during which the software program was executed by the processor core: o one or more physical side-channel measurements related to the processing core (e.g., measurements related to or indicative of power consumption of the processor core, measurements indicative of electromagnetic radiation from the processor core, measurements indicative of a temperature of the processor core, or the like) made during the time period during which the software program was executed by the processor core; and o optionally, information that identifies the processing core (e.g., processor ID + processing core ID) that executed the software program during this time period.

[0073] The SCA monitor processes the measurement data (e.g., merges the physical side-channel measurements into a time-series of physical side-channel measurements) to provide a set of measurements that form a measurement profile for the software program. In other words, the SCA monitor performs stitching of the physical side-channel measurements included in the measurement data to form the measurement profile for the software program. The measurement profile is evaluated (e.g., by the SCA monitor or by a tenant of the software program) to determine one or more appropriate actions to be taken, if any, for the software program. For example, if an anomaly is detected, the server(s) may be instructed (e.g., by the SCA monitor or by the orchestrator) to take one or more defensive actions (e.g., raise an alarm to an operator of the server(s) or terminate the software program).

[0074] In some embodiments, the orchestrator is informed of the result of the evaluation of the measurement profile of the software program and, for example, either continues the execution of the software program or takes correcting actions for the server(s), e.g., terminating the process.

[0075] Embodiments of systems and methods are disclosed for performing remote black box monitoring of software programs by using physical side-channels. Embodiments of the present disclosure involve an orchestrator, an SCA monitor, and at least one server being communicatively coupled. The orchestrator is configured to schedule software programs on at least one server, the at least one server having a set of processors where each processor has at least one processing core. The SCA monitor collects and in some embodiments analyzes measurement data including physical side-channel measurements for the software programs from the server(s). Each server further includes a MU for recording physical side-channel measurements for at least one processor core (but preferably all processor cores) of at least one processor (but preferably all of the processors) in the set of processors. In one embodiment, the method includes the following. The orchestrator schedules a first software program to be executed by a server. The server selects at least one processor core of at least one processor at the server to execute the first software program. The MU of the server makes physical side-channel measurements for the selected at least one processor core of the selected at least one processor during time periods for which the first software program is scheduled to be executed thereon. The server stores information (e.g., execution start times and execution stop times) indicative of the time periods during the first software program is executed and information that identifies the respective processor core(s) and processor(s) on which the first software program is executed during each of those time periods. The server maps the time periods during which the first software program is executed to the physical side-channel measurements made for the processor cores that executed the first software program during those time periods and the corresponding processor core (and processor) identifier. The server provides the resulting measurement data to the SCA monitor (e.g., upon request). The SCA monitor processes this measurement data to provide a measurement profile for the first software program. The measurement profile is evaluated (e.g., by the SCA monitor or by the tenant of the first software program), e.g., for anomaly detection. Based on the results of this evaluation, one or more appropriate actions may be taken.

[0076] Embodiments of the solutions described herein may provide a number of advantages over the existing side-channel monitoring solutions. For example, embodiments of the present disclosure may enable powerful, black box monitoring of remotely executing software programs. This is advantageous for at least the two following use cases: for a tenant which wants to ensure that a software program (e.g., a container / function) is executing properly and for a service provider which wants to ensure that only certain functionality is allowed (or that certain functionality is not allowed) to execute on their hardware.

[0077] Embodiments of the remote, physical side-channel monitoring solutions described herein can be used as a standalone solution or complement other metrics used for remote side-channel monitoring, such as CPU usage and memory utilization.

[0078] Furthermore, embodiments of the remote, physical side-channel monitoring solutions described herein can be used as a complement to, or replacement of, classic static analysis performed by the service provider on the third-party software. In some cases, where code inspection is not possible, embodiments of the present disclosure can provide a method of ensuring non-compliant software is not executed on the service provider’s infrastructure.

[0079] Figure 1 illustrates a system 100 in accordance with embodiments of the present disclosure. In some embodiments, the system 100 forms a cloud-based as-a-service environment, e.g., container-as-a-service, platform-as-a-service, or function-as-a-service. The system 100 includes a tenant 102 of the cloud-based as-a-service environment, owning a first software program 104, an orchestrator 106, an SCA monitor 108, and one or more servers 110. The first software program 104 is, in the example embodiments described herein, a software program to be executed in one of the servers 110, as scheduled by the orchestrator 106. Note that a software program may be executed by different servers 110, e.g., during different time periods or may in some cases have different parts that are executed on the same server 110 or potentially different servers 110. The first software program 104 may be, e.g., in the form of a container, function, microservice, or virtual machine. In most embodiments, the first software program 104 is supplied to the orchestrator 106 (and optionally the server(s) 110) by the tenant 102. The first software program 104 may be encrypted before reaching the server(s) 110.

[0080] Note that as used herein a “software program” one of: uncompiled source code, compiled source code, or a software process being executed on the server, depending on context. For example, in step 206 and prior in the procedure of Figure 2 (and likewise in step 304 and prior in the procedure of Figure 3), the software program may be uncompiled or compiled source code. After step 206 (and likewise after step 304), the software program is executed in a software process. The software program may be compiled by the tenant 102, by the orchestrator 106, or by the server 110.

[0081] The orchestrator 106 is communicatively coupled to the one or more servers 110 and is responsible for sending and scheduling software programs to the servers 110. The orchestrator 106 may be a standalone entity or may be implemented as part of the server 110 (e.g., when all processors are located on a single server 110). The orchestrator 106 may be, for example, a Kubemetes instance. The orchestrator 106 includes a software program scheduler 112 that schedules software programs (e.g., the first software program 104) for execution on the server(s) 110.

[0082] The SCA monitor 108 is communicatively coupled to the one or more servers 110. The SCA monitor 108 may be a standalone entity, a distributed virtual component, or part of the orchestrator 106. The SCA monitor 108 includes, in this example, a side-channel analyzer 114, a stitching function 116, a stitching cache 118, a monitor Application Programming Interface (API) 120, and a database 122. Note that the components of the SCA monitor 108 illustrated in the example of Figure 1 are only an example. The functionality of the SCA monitor 108 described herein may be implemented in any desired manner. The side-channel analyzer 114, the stitching function 116, and the monitor API 120 are preferably implemented in software (e.g., as subfunctions of a software package that implements the SCA monitor 108). Thus, the SCA monitor 108 may be implemented in software that is stored in memory of a computing system (e.g., a physical server) and executed by one or more processors (e.g., one or more CPUs) of the computing system.

[0083] The side-channel analyzer 114 analyzes measurements, e.g., by an anomaly detection model, and determines if the measurements are aligned with expected results and decides what the appropriate action(s) is for the software based on the result. An anomaly detection model may be a statistical model describing the observable characteristics correlated to expected execution of the software. It is used to compare obtained characteristics (e.g., physical side-channel measurements) to expected characteristics, producing an indication on whether the obtained characteristics indicate that the execution of the software was as expected. The database 122 stores software program anomaly detection models (e.g., one model per software program), so that the appropriate model can be used by the side-channel analyzer 114 to perform the comparison of a new measurement from a given process. Note that, in some embodiments, the side-channel analyzer 114 (and optionally the model used for the analysis) may be provided by the tenant 102. The stitching function 116, using the stitching cache 118, stores and merges several discrete measurements from execution instances of the software program.

[0084] The server 110 includes a MU 124, one or more processors 126 each including one or more processor cores 128, and memory 130 that stores, in this example, the first software program 104 (provided by the tenant 102 via the orchestrator 106) and optionally one or more second software programs 132 (e.g., obtained from the same and / or different tenant(s)). The one or more second software programs 132 may or may not be evaluated by the SCA monitor 108. The server 110 includes a measurement cache 134 that stores physical side-channel measurements made by the MU 124, an execution database 136, and an OS scheduler 138. Optionally, the server 110 may include a hypervisor scheduler 140 and / or a Trusted Execution Environment 142, in some embodiments. The server 110 also includes a system time provider 144 (e.g., a system clock).

[0085] The MU 124 performs physical side-channel measurements for the processor cores 128 of the processor(s) 126 in the server 110. The physical side-channel measurements are, in some embodiments, measurements of the power consumption of the processor cores 128 of the processors 126 in the server 110. However, the physical side-channel measurements are not limited thereto. Other examples of the physical side-channel measurements include measurements of the electromagnetic radiation from the processor cores 128 of the processors 126, measurements of the temperature of the processor cores 128 of the processors 126, and the like. The measurement cache 134 is used to store physical side-channel measurements for different processors 126 and processor cores 128 over a known sliding time window. The one or more processors 126 include, for example, one or more Central Processing Units (CPUs), one or more Graphics Processing Units (GPUs), one or more microprocessors, or the like. Each processor 126 includes at least one processor core 128, where one or several software programs may execute on each processor core 128 simultaneously. The OS scheduler 138 and / or the hypervisor scheduler 140 schedules software programs for execution on the processors 126 and (e.g., if requested) stores the execution times (e.g., start and stop times), core IDs, and process ID in the execution database 136. Note that a core ID may indicate both the processor 126 and the processor core 128. The execution database 136 stores execution times and core IDs for different processes. In some embodiments, the execution database 136 may instead be a part of the orchestrator 106. The system time provider 144 is responsible for delivering accurate time stamps for the OS scheduler 138 and / or the hypervisor scheduler 40 as well as for the MU 124.

[0086] Note that preferred embodiments are set in a cloud-based as-a-service environment, e.g., container-as-a-service, platform-as-a-service, or function-as-a-service. In this case, the orchestrator 106 receives the first software program, e.g., from the tenant 102, where this first process is to be executed on a server (e.g., the server 110). The common denominator in the exemplified environments is that the OS is provided by the service provider, which allows the orchestrator 106 to collect measurements in a secure manner. It is possible to use this in an infrastructure-as-a-service environment as well, but this puts requirements on the client, as described in the subsection below entitled “Tenant-Controlled OS.”

[0087] As an alternative to receiving the software directly, the orchestrator 106 may receive a request to set up an execution environment on the server 110 which can be utilized to execute the first software program. The differences between the preferred embodiments and such an alternative embodiment are described in the subsection below entitled “Trusted Execution Environment (TEE) on the Server”.

[0088] In real world examples, the servers 110 may be divided into nodes, where each node may consist of several servers. However, as this abstraction layer is irrelevant for embodiments of the present disclosure, such nodes are not described herein; rather, the description is such that the server 110 is selected directly by the orchestrator 106. Furthermore, the software programs (e.g., the first software program 104 and the second software program 132) described may be embodied in several different manners, e.g., as a container, a function, a microservice or a virtual machine.

[0089] Figures 2A and 2B illustrate the operation of the system 100 of Figure 1, in accordance with some embodiments of the present disclosure. Note that optional steps are represented by dashed lines / boxes. As illustrated, in this example of Figure 2A, the MU 124 performs physical side-channel measurements for the processor cores 128 of the processors 126 and stores the physical side-channel measurements together with corresponding timestamps (e.g., obtained from the system time provider 144) in the measurement cache 134 (step 200). The physical side-channel measurements may be performed continuously (e.g., at a predefined periodicity) for all of the processor cores 128 of all of the processors 126. However, in an alternative embodiment, the physical side-channel measurements are only performed for the processor cores 128 of the processor(s) 126 on which a particular process for which side-channel monitoring has been requested. The physical side-channel measurements may be any type of physical-side channel measurements such as, for example, power consumption related measurements for the processor cores 128, electromagnetic radiation measurements for the processor cores 128, temperature measurements for the processor cores 128. In one example embodiment, the physical side-channel measurements are measurements that directly or indirectly indicate the power consumption of the processor cores 128 (e.g., voltage measurements, clock frequency measurements, or a combination thereol).

[0090] The tenant 102 sends, to the orchestrator 106, a request to run the first software program 104 (step 202). This request includes the first software program 104 in this example. This request may also include an indication that side-channel monitoring is desired for the first software program 104. The orchestrator 106 selects the server 110 to execute the first software program 104 (e.g., the software program scheduler 112 schedules the first software program 104 to run on the server 110) and sends an instruction to the server 110 to start execution of the first software program 104 (step 204). This instruction may include the first software program 104 if the first software program 104 is not already stored at (or otherwise available to) the server 110. This instruction may also explicitly or implicitly indicate a request to start physical side-link measurements for the first software program 104.

[0091] At the server 110, the OS scheduler 138 schedules the first software program 104 for execution by at least one processor core 128 of at least one processor 126 at the server 110 (step 206). The first software program 104 is executed by the at least one processor core 128 of the at least one processor 126, as scheduled, and reports, to the OS scheduler 138, information indicative of the time periods during which the first software program 104 is executed (e.g., start and stop times in the illustrated example) and, for each time period, information that identifies the processor core 128 (and optionally processor 126) on which the first software program 104 is executed during that time period (e.g., processor and core ID in the illustrated example) (step 207). These time periods are also referred to herein as execution times or execution time periods. The OS scheduler 138 records (i.e., stores in the execution database 136) the information indicative of the time periods during which the first software program 104 is executed and, for each time period, information that identifies the processor core 128 (and optionally processor 126) on which the first software program 104 is executed during that time period (step 208). For example, in one embodiment, while the first software program 104 is being executed in accordance with the scheduling of step 206, the OS scheduler 138 is notified when execution of the first software program starts and stops (i.e., execution start and stop times) and the corresponding processor core identifier (ID) and processor ID (or alternatively a single ID that identifies both the processor 126 and the processor core 128).

[0092] Turning to Figure 2B, at some point in time either during or after execution of the first software program 104 at the server 110, the SCA monitor 108 sends a request to the server 110 (e.g., to the MU 124 in this example) for measurement data for the first software program 104 (step 210). The server 110 (e.g., the MU 124 in this example) obtains the requested measurement data for the first software program 104 by mapping the appropriate physical side-channel measurements to the time periods during which the first software program 104 was executed using the core IDs (step 212). The resulting measurement data includes, for each processor core 128 on which the first software program 104 was executed:

[0093] • information indicative of time periods during which the first software program 104 was executed on the processor core 128;

[0094] • for each of the time periods during which the first software program 104 was executed by the processor core 128: o one or more physical side-channel measurements for the processor core 128 during that time period; and o optionally, information that identifies the processing core (e.g., core ID) that executed the first software program 104 during that time period.

[0095] The server 110 (e.g., the MU 124 in this example) sends the measurement data for the first software program to the SCA monitor 108 (step 214). The SCA monitor 108 may initiate one or more additional iterations of steps 210 to 214 to obtain additional measurement data for the first software program (step 215). In this manner, the SCA monitor 108 obtains per-software-process physical side-channel measurements. For a particular software program to be analyzed, the monitor API 120 obtains the measurement data for the software program from the server(s) 110 on which the software program is executed (via the request and response of steps 210 and 214) and stores the measurement data for the software program in the database 122.

[0096] Then, the SCA monitor 108 (e.g., the stitching function 116 of the SCA monitor 108) processes the measurement data (and optionally the additional measurement data from step 215) for the first software program to form a measurement profile for the first software program (step 216). This processing is also referred to here as “stitching”. The stitching function 116 processes the measurement data for the first software program, using the stitching cache 118 if needed, to generate the measurement profile for the software program. The measurement profile includes, for example, the physical side-channel measurements from the measurement data arranged in sequence according to the times at which those measurements were made. The SCA monitor 108 (e.g., the side-channel analyzer 114 of the SCA monitor 108) performs anomaly detection based on the measurement profile of the first software program (step 218). More specifically, the sidechannel analyzer 114 then analyzes the measurement profile for the first software program, e.g., evaluates the measurement profile for the first software program against a known (e.g., pre-trained or predefined) model (e.g., a Machine Learning (ML) model for anomaly detection) of the measured characteristic (e.g., power consumption, electromagnetic radiation, processor core temperature, or the like) of the first software program 104 to determine whether the first software program 104 is behaving normally or whether an anomaly is detected. If an anomaly is detected, the SCA monitor 108 may either instruct the server 110 to take one or more defensive actions (e.g., raise an alarm to an operator or termination execution of the first software program 104) or notify the orchestrator 106. If the orchestrator 106 is notified, the orchestrator 106 takes an appropriate action such as, for example, refraining from scheduling the first software program 104 for execution.

[0097] Figure 3 is a signaling diagram that illustrates the operation of the system 100 of Figure 1, in accordance with an embodiment of the present disclosure. The steps of the procedure of Figure 3 are as follows:

[0098] Step 300: The orchestrator 106 receives the first software program 104 from the tenant 102. Step 301 : The MU(s) 124 in the server(s) 110 continuously (or for only specific resources upon request by the scheduler 112) stores physical side-channel measurements for respective processor(s) 126 and processor cores 128 in the measurement cache 134. This may be implemented in a rotation manner where old values are overwritten after a predetermined period of time. Note that, in some embodiments, the MU(s) 124 continuously obtain and store physical side-channel measurements and store them in the measurement cache 134. However, in other embodiments, the MU(s) 124 may not start obtaining and storing the physical-side channel measurements until some trigger has occurred such as, for example, receiving the instruction to schedule and execute the first software program 104 in step 302.

[0099] During an enrollment phase, one or several physical side-channel measurements of legitimate and optionally malicious software programs are taken. If several measurements are taken, each value is either saved as alternatives for the respective part of the execution or combined and saved as an average for the respective part of the execution. These measurements are used to train an anomaly detection model (where an anomaly represents an invalid execution) per enrolled software program and can be used to validate later executions of the same software programs. The enrollment may be performed by the tenant 102 or the SCA monitor 108 depending on the use case. If a pre-trained one-shot comparison model is used, the enrollment phase of a software program may be reduced to storing the corresponding measurement (or a preprocessed version of it) in a database (instead of a complete anomaly detection model).

[0100] Step 302: The orchestrator 106 sends an instruction to a particular server 110 to start the first software program 104, e.g., in the form of a container, on the particular server 110. In some embodiments, the server 110 is responsible for selecting a particular processor 126 and particular processor core(s) 128 on which the first software program 104 will execute. In other embodiments, the orchestrator 106 explicitly selects the processor 126. The orchestrator 106 supplies the first software program 104 to the server 110 on which the first software program 104 is to be executed.

[0101] Step 304: The OS scheduler 138 on selected server 110 receives the first software program 104. The OS scheduler 138 schedules the first software program to execute on at least one processor core 128 on at least one processor 126, e.g., a CPU.

[0102] Step 306: The OS scheduler 138 receives indication from the at least one processor 126 that the first software program 104 has started (step 306). If the first software program 104 is running on several processor cores 128, the start on each processor core 128 may be reported individually.

[0103] Step 308: The OS scheduler 138 receives indication that the first software program 104 is no longer executing and notes the system time, which may be obtained from the system time provider 144 (not included in Figure 3,). The OS scheduler 138 writes system time, core ID and process ID to the execution database 136. The first software program 104 may no longer be executing due to, for example, optional intermittent scheduling of a second software program 132 for execution. The process steps 306-308 can be repeated several times. Step 310: The SC A monitor 108 requests side-channel information about the first software program 104 from the server 110. The MU 124 is, in this example, able to trust that the request is received from an authorized party. Example ways of achieving this trust are described below in the subsection entitled “Securing PMU Measurements.”

[0104] Step 312: The MU 124 fetches the execution time(s) (e.g., start and stop times) and respective core ID on which the first software program 104 was executed during those execution time(s) from the execution database 136. The MU 124 obtains the physical side-channel measurement(s) from the measurement cache 134 which corresponds to the execution time(s) and core ID(s). In some embodiments, if a measurement value is close to (e.g., within a predefined amount of time from) the start and / or end of an execution time, that measurement value may be discarded to avoid measuring accidentally the context switch between software programs.

[0105] Step 314: The SCA monitor 108 receives the physical side-channel measurements together with core ID and execution time(s) from the MU 124 of the server 110. If the total length (in time) of the received physical side-channel measurements is below a threshold, the SCA monitor 108 may await further execution of the software program and return to step 314. If the total length (in time) of the received measurements is above a threshold, the SCA monitor 108 continues to step 318 where an analysis of the measurement profile is performed (see step 318 below). At this point, the SCA monitor 108 may, in an optional step (not included in Figure 3), further instruct the server 110 to pause the first software program until the analysis has been completed.

[0106] Step 316: The SCA monitor 108, and in particular the stitching function 116, processes the physical side-channel measurements and the associated execution times to form a measurement profile for the first software program 104 from the received set of physical side-channel measurements. If the first software program 104 has executed on a single processor 126 or single processor core 128 or sequentially on more than one processor 126 or more than one processor core 128, the set(s) of measurements are merged in time based on the respective execution times in the order of execution into a single set of measurements forming the measurement profile for the first software program 104. More advanced variants are described below in the subsection entitled “Aspects of Stitching”.

[0107] Step 318: The side-channel analyzer 114 performs analysis of the measurement profile of the first software program 104 output by the stitching function 116 by validating the measurement profile with a software program specific anomaly detection model. In one embodiment, a pretrained measurement comparison model is used to create a match probability between the measurement profile created based on the received physical side-channel measurements and an expected measurement profile of the first software program, e.g., by using one-shot anomaly detection. A one-shot pair-difference model has been trained to differentiate measurements pairs of the same process from measurement pairs of different processes and will return a probability value as to whether two measurements are from the same process or not. If the output of the anomaly detection model is that the new measurement profile of the first software program created based on the received measurements corresponds to an anomaly with a confidence above a certain match threshold (determined, e.g., on a validation set of measurements after the model has been trained), the SCA monitor 108 instructs the server 110 that is executing the first software program 104 to take a defensive action(s), e.g., terminate the first software program 104, indicate to the tenant 102 that the first software program 104 did not pass the validation, or restart the first software program 104. If the confidence score from the result of the anomaly detection model is below a certain match threshold, the process can return to step 312 to obtain more measurements.

[0108] Figure 4 is a signaling diagram that illustrates the operation of the system 100 of Figure 1, in accordance with another embodiment of the present disclosure. In this embodiment, the analysis is tenant-driven. More specifically, in this alternative embodiment, the analysis is performed by a software program owned by the tenant 102 (or a member of the same security group / having access to the same namespace). This is beneficial e.g., in scenarios where the process is performed on a single machine, i.e., where the tenant, orchestrator and server are co-located. It may also be beneficial in scenarios where the tenant 102 does not want to expose the anomaly model to the orchestrator 106. The steps of the procedure of Figure 4 are as follows:

[0109] Step 400: The orchestrator 106 receives the first software program 104, from the tenant 102.

[0110] Step 402: The orchestrator 106 receives an evaluator process from the tenant 102. The evaluator process and / or the tenant 102 has privileges to request power measurements from the Monitor API 120 for the first software program 104.

[0111] Step 404: The evaluator process requests side channel measurements of the first software program 104 via the Monitor API 120 exposed by the SCA monitor 108.

[0112] Step 406: The SCA monitor 108 sends instructions to the OS scheduler 138 or hypervisor scheduler 140 to measure side channel of the first software program 104 executed on a particular server 110 (referred to here as a “first server”).

[0113] Step 408a: The OS scheduler 138 schedules the first software program 104 to, in step 408b, execute on at least one processor core 128 on at least one processor 126, e.g., a CPU, on the server 110. In parallel, in step 408c, the OS scheduler 138 instructs the MU 124 to start measuring on the hardware resources (i.e., processor(s), core(s)) scheduled for the first software program 104. Based on this instruction, MU collects the measurements in step 408d. Step 410: The OS scheduler 138 writes the scheduling data (i.e. , execution time (e.g., start and stop times) and processor / core ID(s)) to the execution database 136.

[0114] Step 411: The MU 124 writes physical side-channel measurements to the measurement cache 134.

[0115] Step 412a: The SCA monitor 108 collects system time, core ID, and process ID from the execution database 136 at the orchestrator 106. Note that while the arrow for step 412a is shown directly from the execution database 136 to the SCA monitor 108, this collected data may alternatively be communicated to the SCA monitor 108 from the OS scheduler 138 (i.e., the OS scheduler 138 may obtained this data from the execution database 136 and send the data to the SCA monitor 108).

[0116] Step 412b: The SCA monitor 108 also collects the physical side-channel measurements made by the MU 124 for the first software program 104 for the execution time from the MU 124 at the server 110. The process steps 408-412b can be repeated several times for multiple execution times (e.g., multiple time periods defined by respective start and stop times) for the first software program 104.

[0117] Step 414: The SCA monitor 108 (e.g., the stitching function 116 of the SCA monitor 108) forms a continuous measurement profile for the first software program 104 from the received physical side-channel measurements as previously discussed and supplies it to the monitor API 120.

[0118] Step 416: The tenant 102 (specifically the evaluator including the side-channel analyzer 114) obtains, from the SCA monitor 108 through a defined API, the generated measurement profile for the first software program 104. In other words, the monitor API 120 at the SCA monitor 108 supplies the measurements to the tenant 102. At the tenant 102 the generated measurement profile for the first software program 104 is provided to the evaluator process (including the side-channel analyzer 114 which in this example is implemented at the tenant 102 (or namespace or security group).

[0119] Step 418: The evaluator process (specifically the side-channel analyzer 114) performs anomaly detection as described herein and decides upon appropriate action(s) depending on the result.

[0120] Aspects of Stitching

[0121] If the first software program 104 is executed on a single processor 126, but potentially on different processor cores 128, in sequential manner, the stitching of the received physical sidechannel measurements into the measurement profile of the first software program 104 is performed by merging the physical side-channel measurements into sequence based on the respective timestamps.

[0122] In one embodiment, the stitching is performed such that, if there is uncertainty to which software program a measurement belongs (e.g., due to mismatch of MU 124 and core clock frequency), then that measurement is disregarded. This can be done, for example, in step 312 or of Figure 3 or as a part of the stitching process in step 316 of Figure 3.

[0123] The stitching process also allows for several concurrent parts within the same software program to be analyzed. These can be processed individually, e.g., if two threads of the same software program handle two discrete parts of the process. In this, the stitching function 116 creates two measurements per time unit and the side-channel analyzer 114 compares each measurement set individually.

[0124] In some cases, the threads handle parts of the same software program, meaning that it is reasonable that they can be measured together. In this scenario, the measurements can be merged into a single measurement, e.g., by averaging or measuring the difference between the threads at each point. Such an approach may require identifying a pattern belonging to a certain part of the process to align the measurements of each thread before merging.

[0125] Securing MU Measurements

[0126] As mentioned in the background, fine-grained or repeated MU measurements can be used to mount attacks on processes running on the same hardware. This puts requirements on protecting the MU 124 from both local and remote attackers trying to utilize this information to attack processes running on the server 110. So, steps 310-314 of Figure 3, for example, are preferably protected to ensure that no unauthorized party is allowed to query the information.

[0127] As discussed above, the SC A monitor 108 sends a request to the MU 124 (or rather the server 110) and requests the measurements. First and foremost, the requests originating from the SCA monitor 108 are, in the preferred embodiments, protected from replay-attacks (e.g., by using timestamps), impersonation (e.g., by using cryptographic signatures or establishing a secure channel (e.g., an encrypted logical channel or a channel over a dedicated physical connection) between the server and the SCA monitor), and eavesdropping (e.g., by encrypting the responses from the server 110). Secondly, the process receiving the request on the server 110 is, in the preferred embodiments, trusted by the SCA monitor 108, e.g., by attesting the boot sequence of the server 110 or by the receiving process using a hardware-protected key, e.g., generated by a Physically Unclonable Function (PUF). The process receiving the request uses its own access right, e.g., having privileged access in the server 110, to prove to the MU 124 that it is authorized to request measurements. There are several use cases where the interface to the MU 124 is used by the OS itself, e.g., for performance and power management purposes, so the MU 124 will receive requests both originating internally and externally. However, the most secure solution would be for the MU 124 to both validate that the request is from a privileged process and, if the requester is external, validate that the requester (in this case, the SCA monitor 108), is authorized to request the information.

[0128] In some cases, the authorization check could also be done by the OS of the server 110, as a part of mapping execution of a software program to physical side-channel measurements (e.g., in step 312 of Figure 3). For example, if a request is for measurements performed on the behalf of the 102 tenant, only processes belonging to the tenant 102 are allowed to be measured.

[0129] Trusted Execution Environment (TEE) on the Server

[0130] In some embodiments, the goal is to not expose the software to the service provider and therefore set up a TEE 142 (see Figure 1) on the server 110 prior to supplying the software program to the server 110. In such an embodiment, the software program (e.g., the first software program 104) is supplied encrypted and is only decrypted prior to being executed within the TEE 142 on the server 110. Relevant TEE solutions include, e.g., Intel SGX enclave or trusted virtualization environment such as Intel TDX or AMD SEV. The tenant 102 can supply an encrypted software program, either to the orchestrator 106 directly or supply an address to the orchestrator 106 which indicates from where the server 110 can request to download the software program, e.g., as a part of step 3 of Figure 3.

[0131] The setup of the TEE 142 can further be attested by the tenant 102 or third party, prior to continuing execution of the software program and / or supplying a decryption key to the server 110.

[0132] Multiple Servers Executing the Software Program

[0133] In some embodiments, the software program (e.g., the first software program 104) is executed on more than one server 110. Hence, the SCA monitor 108 receives physical side-channel measurements from the MUs 124 of more than one server 110.

[0134] In such scenarios, in one embodiment, a baseline power profile of each server 110 may be obtained. Each server 110 may have an individual measurement profile, and knowing this enables the SCA monitor 108 to better understand how the measurements should be stitched together (e.g., using a normalization process where the measurements are altered to have a joint max, min, and step granularity). The measurement profile for each server can be explicitly communicated to SCA monitor 108 by the MU 124 and / or something that the SCA monitor 108 can extrapolate from received measurements over time.

[0135] Tenant-Controlled OS

[0136] In some embodiments, the service provider offers an infrastructure as a service, i.e., service offering that the tenant 102 provides the OS. In these use cases, it may not be possible for the SCA monitor 108 to contact the server 110 to extract the measurements without support from the tenant 102. However, the service provider can provide a plugin, e.g., a kernel module, to the OS of the server 110 which can enable physical side-channel monitoring of software programs. This could either be mandatory or be offered as an additional service which the service provider can perform on behalf of the tenant.

[0137] The embodiment of Figure 4 is also possible in an Infrastructure-as-a-Service (laaS) setting where the tenant 102 is then responsible for implementing both the hypervisor scheduler 140 as well as the SCA monitor 108.

[0138] Virtual Cores

[0139] In future hardware designs, it is plausible that virtual cores, i.e., cores which are not necessarily bound to a physical core, can also be measured. This can, e.g., be implemented using hyperthreading, where two cores share parts for the pipeline stages, i.e., the execute stage. In this case, more fine-grained configuration options may be provided for controlling and measuring the power within the processor 126, e.g., collecting measurement units in each of one or more execution units within a processor core 128 of the processor 126 individually. Alternatively, the additional parallel processing can be seen as additional random noise that will degrade monitoring accuracy but can be managed by normal means as used in side-channel analysis.

[0140] Several Measurements of the Same Process

[0141] In some embodiments, it is valuable to let the software program (e.g., the first software program 104) run several times before performing the evaluation. In these cases, the orchestrator 106 may request that (e.g., a part ol) the process should be repeated several times to increase the number of available measurements.

[0142] Further Description Figure 5 is a schematic block diagram of a server 110 / 502 according to some embodiments of the present disclosure. As illustrated, the server 110 / 502 may include one or more processors 504 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and / or the like), memory 506, and a network interface 508. The one or more processors 504 are also referred to herein as processing circuitry. Particularly, the processing circuitry may be configured to cause the server 110 / 502 to perform a set of operations, or steps, as disclosed above. The one or more processors 504 operate to provide one or more functions of the server 110 / 502 as described herein.

[0143] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the server 110 / 502 according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

[0144] Figure 6 is a schematic block diagram of a SCA monitor 108 / 602 according to some embodiments of the present disclosure. As illustrated, the SCA monitor 108 / 602 may include one or more processors 604 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and / or the like), memory 606, and a network interface 608. The one or more processors 604 are also referred to herein as processing circuitry. Particularly, the processing circuitry may be configured to cause the SCA monitor 108 / 602 to perform a set of operations, or steps, as disclosed above. The one or more processors 604 operate to provide one or more functions of the SCA monitor 108 / 602 as described herein.

[0145] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the SCA monitor 108 / 602 according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

[0146] Figure 7 is a schematic block diagram of a computing system 702 according to some embodiments of the present disclosure. The computing system 702 may, for example, implement all or part of the functionality of the SCA monitor 108, as described herein. As illustrated, the computing system 702 includes one or more processors 704 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and / or the like), memory 706, and a network interface 708. The one or more processors 704 are also referred to herein as processing circuitry. The one or more processors 704 operate to provide one or more functions of the SC A monitor 108 as described herein. In some embodiments, the SCA monitor 108 is implemented in software that is stored, e.g., in the memory 706 and executed by the one or more processors 704.

[0147] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the SCA monitor 108 according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., anon-transitory computer readable medium such as memory).

[0148] Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and / or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according to one or more embodiments of the present disclosure.

[0149] While processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).

[0150] Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered within the scope of the concepts disclosed herein.

Claims

Claims1. A method performed by a server (110, 502) for enabling program-specific side channel analysis, SCA, for anomaly detection, the method comprising:• receiving (204), from an orchestrator (106), an instruction to execute a first software program;• executing (207) the first software program on at least one processor core (128) of at least one processor (126) at the server (110, 502); and• sending (214) measurement data for the first software program to a side channel analysis, SCA, monitor for anomaly detection, the measurement data for the first software program comprising, for each processor core of the at least one processor core for each of the at least one processor on which the first software program is executed at the server (110, 502): o for each time period of one or more time periods during which the first software program was executed on the processor core, one or more physical side-channel measurements related to the processor core made during the time period during which the first software program was executed by the processor core.

2. The method of claim 1 , wherein the measurement data for the first software program further comprises, for each processor core of the at least one processor core for each of the at least one processor on which the first software program is executed at the server (110, 502), information indicative of the one or more time periods during which the first software program was executed on the processor core.

3. The method of claim 1 or 2, wherein the one or more physical side-channel measurements related to the processor core comprise one or more physical side-channel measurements indicative of power consumption of the processor core.

4. The method of any of claims 1 to 3, further comprising, prior to sending (214) the measurement data for the first software program to the SCA monitor: receiving (210), from the SCA monitor, a request for the measurement data for the first software program; and obtaining (212) the measurement data for the first software program by mapping the time periods during which the first software program was executed on the at least one processor core of the at least one processor to corresponding physical side-channel measurements stored for the at least one processor core of the at least one processor for the respective time periods.

5. The method of claim 4, wherein the request for the measurement data for the first software program is protected.

6. The method of claim 4, wherein the request for the measurement data for the first software program is protected via any one or more of the following protection mechanisms: a timestamp; a cryptographic signature; a message authentication code (MAC); using a secure channel between the server and the SCA monitor.

7. The method of any of claims 4 to 6, wherein a function at the server (110, 502) that receives the request from the SCA monitor is trusted by the SCA monitor.

8. The method of any of claims 4 to 7, further comprising validating (210) the request prior to obtaining (212) the measurement data for the first software program.

9. The method of any of claims 1 to 8, wherein sending (214) the measurement data for the first software program to the SCA monitor comprises sending (214) the measurement data for the first software program to the SCA monitor via a secure channel between the server and the SCA monitor and / or in an encrypted manner.

10. The method of any of claims 1 to 9, wherein the measurement data further comprises, for each processor core of the at least one processor core for each of the at least one processor on which the first software program is executed, information indicative of the processor core.

11. The method of any of claims 1 to 10, wherein each of the one or more physical side-channel measurements related to the processor core made during the time period during which the first software program was executed by the processor core is a physical side-channel measurement made at a specific time during the time period.

12. The method of any of claims 1 to 11, further comprising:performing and storing (200) physical-side channel measurements and corresponding timestamps related to one or more processor cores (128) in one or more processors (126) at the server (110, 502); wherein the one or more physical side-channel measurement related to the processor core made during the time period during which the first software program was executed by the processor core are a subset of the stored physical-side channel measurements that were made on the processor core and have corresponding timestamps within the time period.

13. The method of claim 12, wherein performing and storing (200) the physical-side channel measurements comprises continuously performing and storing (200) the physical-side channel measurements and corresponding timestamps for each of one or more processing cores in each of one or more processors at the server.

14. The method of claim 12, wherein performing and storing (200) the physical-side channel measurements comprises performing and storing (200) the physical-side channel measurements and corresponding timestamps for at least one of one or more processing cores in at least one of one or more processors at the server responsive to an activation trigger.

15. The method of claim 14, wherein the activation trigger is reception of an associated request to activate physical side-channel measurements.

16. The method of claim 14, wherein the activation trigger is reception of an associated request to activate physical side-channel measurements for the first software program.

17. The method of any of claims 1 to 16, further comprising obtaining and storing (207-208) execution data comprising, for each processor core (128) of the at least one processor core for each processor (126) of the at least one processor on which the first software program is scheduled to execute: information indicative of the processor core; and information indicative of one or more time periods during which the first software program is executed on the processor core in accordance with the scheduling (206); wherein the one or more time periods during which the first software program was executed on the processor core are identified based on the stored execution data.

18. The method of any of claims 1 to 17, wherein the first software program is executed in a trusted execution environment on the server.

19. The method of any of claims 1 to 18, wherein each of the one or more physical side-channel measurements related to the processor core made during the time period during which the first software program was executed by the processor core is a physical side-channel measurement made at a specific time during the time period for at least one execution unit of the processor core.

20. The method of any of claims 1 to 18, wherein each of the one or more physical side-channel measurements related to the processor core made during the time period during which the first software program was executed by the processor core is a physical side-channel measurement made at a specific time during the time period for the processor core.

21. The method of any of claims 1 to 20, wherein the instruction from the orchestrator to execute the first software program comprises an instruction to allow the first software program to be executed at least a certain number of times before sending the measurement data to the SCA monitor.

22. A server (110, 502) for enabling program-specific side channel analysis, SCA, for anomaly detection, the server (110, 502) adapted to:• receive (204), from an orchestrator (106), an instruction to execute a first software program;• execute (207) the first software program on at least one processor core (128) of at least one processor (126) at the server (110, 502); and• send (214) measurement data for the first software program to a side channel analysis, SCA, monitor for anomaly detection, the measurement data for the first software program comprising, for each processor core of the at least one processor core for each of the at least one processor on which the first software program is executed at the server (110, 502): o for each time period of one or more time periods during which the first software program was executed on the processor core, one or more physical side-channel measurements related to the processor core made during the time period during which the first software program was executed by the processor core.

23. The server (110, 502) of claim 22, further adapted to perform the method of any of claims 1 to 21.

24. A server (110, 502) for enabling program-specific side channel analysis, SCA, for anomaly detection, the server (110, 502) comprising:• one or more processors (126) each comprising one or more processor cores (128); and• at least one scheduler (138, 140) configured to: o receive (204), from an orchestrator (106), an instruction to execute a first software program; o execute (207) the first software program on at least one processor core (128) of at least one processor (126) of the one or more processors (126) at the server (110, 502); and o send (214) measurement data for the first software program to a side channel analysis, SCA, monitor for anomaly detection, the measurement data for the first software program comprising, for each processor core of the at least one processor core for each of the at least one processor on which the first software program is executed at the server (110, 502):■ for each time period of one or more time periods during which the first software program was executed on the processor core, one or more physical side-channel measurements related to the processor core made during the time period during which the first software program was executed by the processor core.

25. A method performed by a side channel analysis, SCA, monitor (108, 602) for programspecific anomaly detection, the method comprising:• receiving (214, 215), from a server, measurement data for a first software program, the measurement data comprising, for each processor core of at least one processor core for each of at least one processor on which the first software program was executed at the server: o for each time period of one or more time periods during which the first software program was executed on the processor core, one or more physical side-channel measurements related to the processor core made during the time period during which the first software program was executed by the processor core;• processing (216) the measurement data to form a measurement profile of the first software program; andperforming (218) anomaly detection for the first software program based on the measurement profile of the first software program and an anomaly detection model for the first software program.

26. The method of claim 25, wherein the measurement data for the first software program further comprises, for each processor core of the at least one processor core for each of the at least one processor on which the first software program is executed at the server, information indicative of the one or more time periods during which the first software program was executed on the processor core.

27. The method of claim 25 or 26, further comprising: sending (210), to the server, one or more requests for the measurement data for the first software program; wherein receiving (214, 215) the measurement data for the first software program from the server comprises receiving (214, 215) the measurement data for the first software program from the server responsive to the one or more requests.

28. The method of claim 27, wherein the one or more physical side-channel measurements related to the processor core comprise one or more physical side-channel measurements indicative of power consumption of the processor core.

29. The method of claim 27 or 28, wherein each of the one or more requests for the measurement data for the first software program is protected.

30. The method of claim 27 or 28, wherein each of the one or more requests for the measurement data for the first software program is protected via any one or more of the following protection mechanisms: a timestamp; a cryptographic signature; using a secure channel between the server and the SCA monitor.

31. The method of any of claims 27 to 30, wherein a function at the server that receives the one or more requests from the SCA monitor at the server is trusted by the SCA monitor.

32. The method of any of claims 27 to 31, wherein the one or more requests for the measurement data for the first software program consist of a single request for the measurement data for the first software program.

33. The method of any of claims 27 to 31, wherein sending (210, 215) the one or more requests for the measurement data for the first software program and receiving (214, 215) the measurement data responsive to the one or more requests comprises: sending (210), to the server, a first request for measurement data for the first software program; receiving (214), from the server, first measurement data for the first software program, responsive to the first request; sending (210, 215), to the server, one or more additional requests for measurement data for the first software program; and receiving (214, 215), from the server, one or more additional measurement data for the first software program, responsive to the one or more additional requests, respectively; wherein the measurement data for the first process comprises the first measurement data for the first process and the one or more additional measurement data for the first process.

34. The method of any of claims 25 to 33, wherein receiving (214, 215) the measurement data for the first software program from the server comprises receiving (214, 215) the measurement data for the first software program from the server via a secure channel between the server and the SCA monitor and / or in an encrypted manner.

35. The method of any of claims 25 to 34, wherein the measurement data further comprises, for each processor core of the at least one processor core for each of the at least one processor on which the first software program is executed at the server, information indicative of the processor core.

36. The method of any of claims 25 to 35, wherein each of the one or more physical sidechannel measurements related to the processor core made during the time period during which the first software program was executed by the processor core is a physical side-channel measurement made at a specific time during the time period.

37. The method of any of claims 25 to 36, wherein during processing (216) of the measurement data to form the measurement profile of the first software program, one or more of the physical side-channel measurements are discarded.

38. The method of claim 37 wherein the one or more discarded physical side-channel measurements comprise either or both of: one or more of the physical side-channel measurements that were made within a predefined amount of time prior to an end of their respective time periods; one or more of the physical side-channel measurements that were made within a predefined amount of time after a start of their respective time periods.

39. The method of any of claims 25 to 38, wherein the first software program is executed on the server and one or more additional servers, and processing (216) the measurement data to form the measurement profile of the first software program comprises processing (216) the measurement data for the first software program received from the server together with measurement data for the first software program received from the one or more additional servers to form the measurement profile of the first software program.

40. The method of claim 39, wherein the measurement data is pre-processed to normalize the measurement data across the server and the one or more additional servers prior to processing (216) to form the measurement profile of the first software program.

41. A side channel analysis, SCA, monitor (108, 602) for program-specific anomaly detection, the SCA monitor (108, 602) adapted to:• receive (214, 215), from a server, measurement data for a first software program, the measurement data comprising, for each processor core of at least one processor core for each of at least one processor on which the first software program was executed at the server: o for each time period of one or more time periods during which the first software program was executed on the processor core, one or more physical side-channel measurements related to the processor core made during the time period during which the first software program was executed by the processor core;• process (216) the measurement data to form a measurement profile of the first software program; andperform (218) anomaly detection for the first software program based on the measurement profile of the first software program and an anomaly detection model for the first software program.

42. The SCA monitor (108, 602) of claim 41, further adapted to perform the method of any of claims 26 to 40.

43. A computing system (702) for implementing a side channel analysis, SCA, monitor (108) for program-specific anomaly detection, the computing system (702) comprising:• a network interface (708); and• one or more processors (704) associated with the network interface (708), the one or more processors (704) configured to cause the computing system (702) to: o receive (214, 215), from a server, measurement data for a first software program, the measurement data comprising, for each processor core of at least one processor core for each of at least one processor on which the first software program was executed at the server:■ for each time period of one or more time periods during which the first software program was executed on the processor core, one or more physical side-channel measurements related to the processor core made during the time period during which the first software program was executed by the processor core; o process (216) the measurement data to form a measurement profile of the first software program; and o perform (218) anomaly detection for the first software program based on the measurement profile of the first software program and an anomaly detection model for the first software program.

Images