D3.5: Hardware Vulnerability and Leakage Detection (first version)

Hardware Vulnerability and Leakage Detection (first version) PROJECT Project Number 101120962 Project Acronym RESCALE Project Title Revolutionised Enhanced Supply Chain Automation with Limited Threats Exposure Start Date 01.10.2023 Programme HORIZON-CL3-2022-CS-01-02 DELIVERABLE Deliverable Type Report Workpackage WP3 Deliverable Lead ISI Editors Apostolos Fournaris (ISI), Charis Dimopoulos (ISI), Ioannis Morianos (DIE) Contributors Evangelos Haleplidis (ISI), Fenia Paraskevopoulou (ISI) Dissemination Level Public Abstract In this deliverable we summarize the activities of Task 3.3 till M14 of the RESCALE project focusing on the design and initial implementation of the Dynamic Hardware Analyzer component of the RESCALE architecture. This component, as Task 3.3 indicates, provides side channel leakage assessment of some cryptography hardware or software Intellectual Property (IP) block. The designed and developed platform is adopting the latest research directives on Side Channel Attack (SCA) assessment and takes also into account remote SCAs on cloud based Field Programmable Gate Array (FPGA) units that accommodate multiple tenants. The deliverable initially provides an overview of the SotA on the SCA research domain and then analyzes the Dynamic Hardware Analyzer architecture and its components. Furthermore, in the deliverable we map open issues and future activities on hardware vulnerabilities and leakage detection that will be incorporated in the Dynamic Hardware Analyzer in the future (till the end of T3.3) and describe a brief road-map on the next activities to achieve this goal while in parallel also providing some initial results. Disclaimer The information in this document is provided “as is”, and no guarantee or warranty is given that the information is fit for any particular purpose. The content of this document reflects only the author’s view – the European Commission is not responsible for any use that may be made of the information it contains. The users use the information at their sole risk and liability. This project has received funding from the European Union’s Horizon Europe research and innovation programme under grant agreement No 101120962 Ref. Ares(2024)9281430 - 31/12/2024 Hardware Vulnerability and Leakage Detection (first version) Internal Reviewers 1. Narges Yousefnezhad (BNR) 2. Christiano Giuffrida (VUA) Revisions Version Date Partner Overview 0.1 09/07/2024 ISI ToC 0.2 10/11/2024 ISI, DIE First draft 0.3 30/11/2024 ISI, DIE Finished draft 0.4 15/12/2024 ISI Reviewer comments collected 0.5 19/12/2024 ISI, DIE Comments addressed 0.8 23/12/2024 ISI Final version 0.9 23/12/2024 ISI, AEGIS Final comments 1.0 30/12/2024 ISI Final version RESCALE – Public – Page 2 / 38 Table of Contents 1 Introduction 7 1.1 Scope&Contribution............................... 7 1.2 Relation to Work Packages, Deliverables, and Activities . . . . . . . . . . . . . 7 1.3 Contribution to WP3 and Project Objectives . . . . . . . . . . . . . . . . . . . 7 1.4 DocumentStructure................................ 8 2 Overview of Leakage Assessment and Side Channel Attacks 9 2.1 Definition and Importance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2 StateoftheArt .................................. 9 2.3 Limitations and Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3 Dynamic Hardware Analyzer Architecture and Components 12 3.1 OverallArchitecture................................ 12 3.2 TraceCollector .................................. 13 3.3 TraceAnalyzer .................................. 17 4 Open Issues 25 4.1 IdentifiedChallenges ............................... 25 4.2 MitigationSolutions................................ 26 5 Roadmap to Final Version 28 5.1 DevelopmentPlan................................. 28 5.2 InitialEvaluation ................................. 28 6 Main Innovations & Conclusion 35 6.1 MainInnovations ................................. 35 6.2 Conclusion .................................... 35 6.3 FutureWork.................................... 36 3 List of Figures 1 Dynamic Hardware Analyzer Architecture. . . . . . . . . . . . . . . . . . . . . . 13 2 Hardwaresensors.................................... 17 3 SCATraceAnalyzerflow. .............................. 19 4 Jupyter Notebook input for the SCA Trace Analyzer. . . . . . . . . . . . . . . . . 20 5 Configuration of the attack for the SCA Trace Analyzer. . . . . . . . . . . . . . . . 29 6 Trace preprocessing example for the SCA Trace Analyzer. . . . . . . . . . . . . . 30 7 Trace preprocessing example for the SCA Trace Analyzer. . . . . . . . . . . . . . 31 8 Launch Attack Jupyter cell for the SCA Trace Analyzer. . . . . . . . . . . . . . . . 31 9 SCA assessment report generation example. . . . . . . . . . . . . . . . . . . . . . 32 10 SCA in multi-tenant FPGA block diagram. . . . . . . . . . . . . . . . . . . . . . 33 11 AESleakageplot. .................................. 34 12 Pearson’s correlation plot. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4 Hardware Vulnerability and Leakage Detection (first version) List of Abbreviations ADC Analog-to-Digital Converter. 10 AES Advanced Encryption Standard. 4, 10, 32–34 API Application Programming Interface. 14–16 CNN Convolutional Neural Networks. 9 COTS Commercial off-the-shelf. 12, 14, 15 CPA Correlation Power Analysis. 9, 10, 12, 18, 23, 28, 32, 33 CPU Central Processing Unit. 36 CVE Common Vulnerabilities and Exposures. 25 CWE Common Weakness Enumeration. 25 DL Deep Learning. 9, 10, 12, 14, 18, 19, 28, 35 DL-LA Deep Learning Leakage Assessment. 9 DPA Differential Power Analysis. 9, 12, 23 DSCG Dynamic Supply Chain component Guarantee. 7, 28, 36 DuT Device under Test. 12, 18, 22 FPGA Field Programmable Gate Array. 1, 4, 9–16, 22, 25, 26, 28, 29, 32, 33, 35, 36 IP Intellectual Property. 1, 12, 13, 15, 18, 20, 28, 31 JSON JavaScript Object Notation. 20–22, 29 LUT Look-Up-Table. 22 ML Machine Learning. 9, 12, 14, 18, 21–23, 26, 28, 29, 31 MLP Multilayer Perceptrons. 9 PDN Power Distribution Networks. 10, 11, 35 PSCA Power Side Channel Attack. 11, 25, 36 PVT Process Voltage Temperature. 16 RDS Routing Delay Sensors. 10 RF Random Forest. 18, 22, 31 RO Ring Oscillator. 10, 16, 26 RESCALE – Public – Page 5 / 38 Hardware Vulnerability and Leakage Detection (first version) SCA Side Channel Attack. 1, 4, 7–10, 12–22, 25–36 SoC System on Chip. 9, 34 SotA State of the Art. 1, 8, 9 SPA Simple Power Analysis. 9, 12 SVM Support Vector Machine. 18, 22 TBOM Trusted Bill of Materials. 7, 36 TDC Time to Digital Converter. 10, 16, 17, 33 TVLA Test Vector Leakage Assessment. 12, 18, 22 VHDL VHSIC Hardware Description Language. 15 RESCALE – Public – Page 6 / 38 Hardware Vulnerability and Leakage Detection (first version) 1 Introduction This deliverable provides the results of Task 3.3 which is complimentary to the dynamic testing module developed in Task 3.2, focusing on detecting Hardware Vulnerabilities and specifically performing Leakage Detection on Side Channel Attacks (SCAs). Note that Task 3.3 is specifically concerned with physical side-channel attacks (or simply SCAs hereafter), that is attacks that exploit the physical characteristics (e.g., power consumption) of a target system. In contrast, digital side-channel attacks, which exploit digital characteristics (e.g., microarchitectural events) of a target system, are the focus of Task 3.4. 1.1 Scope & Contribution This document is the outcome of the initial phase of Task 3.3, ”Hardware Vulnerability and Leakage Detection”. It outlines the initial design of solutions for security testing of software or hardware IP cores against information leakage due to physical characteristics of the utilized hardware execution environment. The main scope of the solutions described in this deliverable targets physical leakage vulnerabilities, especially Leakage Detection that can be exploited using SCAs. As part of the overall RESCALE platform, these solutions contribute as a standalone hardware attack surface analysis and provide reports that will be embedded in the DSCG portion of the Trusted Bill of Materials (TBOM). 1.2 Relation to Work Packages, Deliverables, and Activities Deliverable D3.5 is the outcome of Task 3.3 within Work Package 3 (WP3). The results from D3.5 will be incorporated into the DSCG report generated by Task 3.2 (WP3), which contributes to the generation of the TBOM in WP4. In addition the tools and methods outlined in D3.5 will be integrated with the rest of the tools from Tasks 3.2 and 3.4, associated with the dynamic testing module, and included into the broader RESCALE solution in WP5. 1.3 Contribution to WP3 and Project Objectives D3.5 directly contributes to WP3, specifically to Objective O3.4, which focuses on implementing hardware vulnerabilities and information leakage detectors, by developing solutions to detect Leakage that can be exploited using SCAs. In addition D3.5 contributes directly to Project Objectives O1 and O2 by providing Hardware vulnerabilities to be incorporated into the auditing toolbox. Finally, D3.5 also contributes indirectly to Project Objectives O3 (by providing essential details to be incorporated into a TBOM) and O5 (by providing details for visibility and awareness of hardware components in the supply chain). RESCALE – Public – Page 7 / 38 Hardware Vulnerability and Leakage Detection (first version) 1.4 Document Structure The deliverable structure is outlined in this section as follows: •Section 2 - Overview of Leakage Assessment and Side Channel Attacks: This section provides background and context, summarizing the findings of D2.3 and presenting additional relevant State of the Art (SotA) research on Leakage Assessment and SCAs. •Section 3 - Dynamic Hardware Analyzer Architecture and Components: This section offers an overview of the architecture of the Dynamic Hardware Analyzer with all the internal components, as well as implementation details and interfaces. •Section 4 - Open Issues: This section discusses the identified challenges of the current work along with possible mitigation solutions. •Section 5 - Roadmap to Final Version: This section provides a development plan on how the work of Task 3.3 as well as the evaluation of the tools are going to move forward. •Section 6 - Main Innovations & Conclusion: This section summarizes the key innovations from the work and outlines the next steps. RESCALE – Public – Page 8 / 38 Hardware Vulnerability and Leakage Detection (first version) 2 Overview of Leakage Assessment and Side Channel Attacks 2.1 Definition and Importance 2.2 State of the Art This section provides a comprehensive overview of the SotA for Hardware Vulnerability and Leakage Detection provided on D2.6. It explores advanced SCAs, security assessment platforms, and the emerging challenges posed by multi-tenant Field Programmable Gate Array (FPGA)s. An FPGA is a type of integrated circuit that can be configured by the user after manufacturing to perform specific digital logic tasks. This is achieved through an array of programmable interconnected logic blocks that can be reprogrammed to implement custom hardware functions through dedicated hardware IP Cores. Multi-tenant FPGAs are shared among multiple users or workloads, often in a cloud or data center environment. This approach allows multiple independent applications or tenants to utilize portions of the FPGA’s resources simultaneously, optimizing utilization and cost-efficiency. Side Channel Attack (SCA) SCAs exploit physical characteristics (e.g., power consumption, electromagnetic emissions) to extract sensitive information from systems like SoCs and FPGAs. These attacks can be categorized into two primary methods: •Non-Profiling Methods: Statistical techniques like Simple Power Analysis (SPA), Differential Power Analysis (DPA), and Correlation Power Analysis (CPA). •Profiling Methods: Techniques using prior device access, including Template Attacks [1][12] and Machine Learning (ML)-based approaches. Deep Learning (DL) has significantly improved SCAs by enhancing attack performance and bypassing countermeasures. Models like Multilayer Perceptrons (MLP) and Convolutional Neural Networks (CNN) require minimal preprocessing and analyze raw traces effectively [11][8][10]. Tools like Deep Learning Leakage Assessment (DL-LA)1further enhance leakage detection. Platforms for Security Assessment Standardized platforms for SCAs include FPGA-based tools like FOBOS [3], INSTAC boards, Sakura-Sasebo project 2boards, and ChipWhisperer systems3. Advanced tools like Riscure Inspector4and DPA Workstation5provide comprehensive evaluation capabilities, but at a higher 1https://github.com/Chair-for-Security-Engineering/DL-LA 2http://satoh.cs.uec.ac.jp/SAKURA/index.html 3https://www.newae.com/chipwhisperer 4https://www.riscure.com 5https://www.rambus.com RESCALE – Public – Page 9 / 38 Hardware Vulnerability and Leakage Detection (first version) 3.2.3 Internal Design/Implementation Assessment Designer: This component consists of two main software libraries: the Designer Software Library and the Sensor Drivers (firmware) library. The Designer Software Library provides an API that abstracts communication with the controlled environment where the trace analysis takes place focusing on the proper establishment of a trace collection execution including the supply of the assessed IP core with test vectors. This library is responsible for defining the assessment characteristics such as the number of inputs and outputs, control signals, and bit lengths. It also provides functions for starting and stopping trace collection experiments, depending on whether the assessment involved a hardware or software IP core. The Sensor Drivers library enables trace collection from in-house created sensors, such as those used for FPGA-based side channel attacks, and includes firmware to support these sensors. When working with hardware IP cores, the Designer also provides support for integrating the FlexLeco v.2.0 bus interface to manage the control of input, output, and control signals dynamically. Assessment Implementor: Continuing the work of the Assessment Designer, this component carries out the actual trace collection process, using the configuration scripts and parameters defined by the Assessment Designer. The implementor interfaces with trace collection equipment, such as oscilloscopes and sensors, and stores the collected traces in a centralized SCA trace repository. For remote FPGA attacks, the Assessment Implementor is tasked with gathering power consumption-related traces from hardware sensors as the cryptographic component operates. Commonly, there exist two main types of voltage sensors for mounting remote power side-channel attacks (Figure 2); the Ring Oscillator (RO) based delay sensor and the taped delay-line or Time-to-Digital Converter (TDC) sensor. •Ring Oscillators RO sensors utilize a NAND gate, with inputs from an external enable signal and the gate’s own output. When activated, the gate generates a continuous oscillation whose frequency varies with changes in voltage, as determined by its propagation delay. By monitoring the oscillation frequency through digital counters, RO sensors provide insights into power consumption. •Time-to-Digital Converters TDC-based sensors, on the other hand, operate by assessing how far a signal can propagate along a path with latches inserted between logic elements, such as a chain of buffers. Since buffer delays are sensitive to changes in process, voltage, and temperature (PVT), these delays are detectable by reading the latches. In this setup, a signal is sent simultaneously to the input of the first buffer and the latch enable signals, so the signal on the wire outruns the signal through the buffer chain. With a precisely timed clock signal, the latches become disabled at half the clock period, preserving the clock’s reach within the chain for further analysis. The initial delay is set to be less than half of the clock period and latches along the buffer chain fall within the delay variation range of interest. This range is selected to balance acceptable area overhead and operating values. In comparison, RO sensors require simpler circuitry and consume fewer resources of the fabric— though they are less accurate due to the limitation of counters, which cannot achieve nanosecondlevel sampling. RO sensors are also more easily flagged as malicious, making them less desirable for attack purposes. TDC sensors, however, enable nanosecond-level voltage fluctuation RESCALE – Public – Page 16 / 38 Hardware Vulnerability and Leakage Detection (first version) measurements and can function as thermal sensors. Additionally, their implementation is harder for design tools to block, making TDC sensors a more effective choice for power side-channel attacks. Figure 2: Hardware sensors. 3.2.4 Interconnections The Assessment Designer interacts with users via a scripting interface, enabling them to configure and execute trace collection experiments following a trace collection flow profile. It connects to the trace collection equipment, including sensors and oscilloscopes, as well as custom-built sensors when necessary. The Assessment Implementor uses the configurations defined by the Designer to manage the trace collection process and store data in the SCA repository, making it available for further analysis. Additionally, for hardware IP cores, the Assessment Designer ensures seamless integration by extending the IP core with the FlexLeco v.2.0 bus interface, facilitating smooth communication during trace collection. 3.3 Trace Analyzer 3.3.1 Features and Supported Processes The Trace Analyzer component is responsible for providing leakage assessment functionality in a generalized and flexible manner. It is designed to offer the SCA analysis for a variety of platforms, both software and hardware and in order to achieve that it encapsulates a unified API that can be easily adaptable. Utilizing a number of leakage assessment functions, the Trace RESCALE – Public – Page 17 / 38 Hardware Vulnerability and Leakage Detection (first version) Analyzer has the ability to make SCA evaluations of the resistance of a given implementation of a cryptographic library with a relatively high degree of confidence. The two high-level processes this component supports can be summarized below: • Non-specific leakage assessment: In cases where a deep understanding of the Device under Test (DuT) is not necessary or feasible, a non-specific leakage assessment approach like TVLA t-test based techniques can help detect leakage points of interest. • Specialized SCAs: Fully fledged attacks that abide to penetration testing principles and adopt various threat models can challenge the resistance of a specific IP core or software implementation against a list of SCAs. A very popular category of techniques is profiling attacks, and by extension the ML/DL approach that enhances their performance in attacking the chosen points of interest that are unique and specific for each assessed target. In a more explicit manner, the processes presented below for each category are characteristic examples of the included SCA functionality: Non-Specific Leakage Assessment The Welch t-test is a popular statistical tool that attempts to highlight possible differences between the means of two different target groups. In the context of SCA, its purpose is mainly to make comparisons between traces (electromagnetic emissions, power consumption) that usually represent different conditions, for example random vs. fixed numerical values as inputs for the cryptographic algorithm. Possible differences in means between these groups are identified by the t-test and can signify a potential leakage of critical information. Despite its ease of use and implementation as a first step for leakage detection, this technique has difficulties in detecting subtle or non-linear dependencies between the traces and requires in many cases very large datasets for reliable leakage detection. The evolution of the Welch t-test for SCA is the Test Vector Leakage Assessment ( TVLA). It computes the t-statistic for traces collected under different conditions, but compares it against a predefined threshold (usually at ±4.5) in order to identify possible leakage. The TVLA technique constitutes a standardized approach to leakage assessment, as it offers semi-automated detection of first-order leakage. Similarly to the Welch t-test, it struggles in identifying more complex leakage forms and requires large amounts of data to do so. Specialized SCA Assessment A more advanced SCA attack is the Correlation Power Analysis (CPA), in which as the name suggests, the correlation between the real dataset (power consumption traces) and a chosen hypothetical power model based on guessed intermediate values is measured. Using these predicted values for different key guesses, CPA identifies through the highest correlation which guess was the correct one, thus further enabling the recovery of the secret key. It is quite effective for many types of SCAs when paired with an accurate power model, but its efficiency is hampered by an incorrect power model or noisy captured traces. For the profiling type of SCAs, where an IP Core is uniquely assessed, techniques based on ML, such as Support Vector Machines (SVMs), Random Forest (RFs), Neural Networks (Deep/Convolutional) have quickly gained popularity in a SCA context. Their ability to learn patterns of leakage that might be nonlinear and complex on already labeled training data and adapt them into unknown traces makes RESCALE – Public – Page 18 / 38 Hardware Vulnerability and Leakage Detection (first version) them a powerful tool for modern side channel analysis, since the variety of data they can handle is pretty large. 3.3.2 Internal Design/Implementation Architecturally, the Trace Analyzer consists of two main submodules, the SCA script library and the trace preprocessing library. The main functionality of the analyzer is offered by the SCA script library, since it facilitates all the leakage assessment functions under a unified API. It is also responsible for the initialization of the SCA assessment flow. To support the SCA analysis, the trace preprocessing library provides implementations of useful signal processing functions to enhance the performance of the submodule. Below, the SCA penetration testing assessment flow is presented in Figure 3: Figure 3: SCA Trace Analyzer flow. The SCA script software library is a flexible tool for the user, since it offers fast implementation of various common SCAs to assess a specific cryptographic implementation. The high level overview of these functions have been discussed in subsection 3.3.1. Based on the type of the attack and the configurations provided by the expert user, the SCA script library is assisted by the trace preprocessing library to prepare the trace dataset tailored for each attack. The trace preprocessing library is a necessary component that aids with the side channel assessment. Even for more advanced DL attacks that can handle noisy data in a more efficient manner, preprocessing the power traces is of paramount importance. Examples of the functions that the trace preprocessing library offers are: • filtering (high-pass, low-pass, band-pass) • cropping • averaging RESCALE – Public – Page 19 / 38 Hardware Vulnerability and Leakage Detection (first version) • scaling • general techniques to increase the Signal-to-Noise ratio After the SCA Assessment is completed, the Trace Analyzer generates an assessment report through a reporting mechanism. This report is a JavaScript Object Notation (JSON) file, containing all the necessary information about the SCA and its structure is explained in Section 3.3.3.2. The report of the tool can act as the building block of the CycloneDX based input to the overall Dynamic Testing Module of the RESCALE architecture further analyzed in Deliverable D3.3. 3.3.3 Interconnections-Input/Output 3.3.3.1 Input Universally collected traces with the aid of the Trace Collector from various controlled environment setups can be considered the data input to the platform. This type of data is usually structured as .csv or .mat files, depending on the configuration of the lab setup. Thus, after the trace collection and correct annotation, the trace dataset is being tested for its SCA resistance by the Analyzer submodule. The user can access the functionality of the Analyzer through an easy-to-use Jupyter Notebook interface. Figure 4: Jupyter Notebook input for the SCA Trace Analyzer. The SCA security expert begins the assessment by selecting all the necessary information to conduct the testing of the implementation as is shown in Figure 4. This process is available through two methods, the first of one is to manually input the information with the Jupyter Notebook functionality. Apart from the mandatory fields that categorize the cryptographic algorithm to be assessed information and the platform the assessed IP Core has been implemented to, the user has additional options related to the attack itself. More specifically, the user can RESCALE – Public – Page 20 / 38 Hardware Vulnerability and Leakage Detection (first version) choose an existing pre-trained ML model for classification of the trace dataset that adheres to the same preprocessing and labeling of the data. On top of that the user can use a pre-computed features file of the same data in order to gain a performance boost, since the processing of the various features of the trace dataset can take a significant amount of time. Additionally, the user can choose the output report directory, where the SCA Assessment report the Trace Analyzer generates will be stored. For the sake of simplicity, there is an additional option available for the user, where an already existing attack configuration file can be used for inserting all the necessary fields required by the Analyzer. This is a JSON file describing the attack in detail. An example of such a file is presented below: { "type": "", "target_settings": { "assessed_system": { "hardware_platform": "", "software_version": "", "operating_system": "", "algorithm": "" }, "report_directory": "", "model_file": "", "trace_file": "", "features_file": "", "retrain": boolean }, "attack_settings": { "cnn_settings": { "layers": , "filters": [], "kernel_size": }, "rf_settings": { "n_estimators": , "max_depth": }, "svm_settings": { "kernel": "", "C": }, "mlp_settings": { "hidden_layers": [], "activation": "" }, "t_test_settings": { "alpha": , "tail": "" }, RESCALE – Public – Page 21 / 38 Hardware Vulnerability and Leakage Detection (first version) "cpa_settings": { "number_of_traces": , "hypothesis": "" }, "dpa_settings": { "number_of_traces": , "threshold": } } } The JSON format offers a quick and flexible way of setting up a new experiment or reiterate one with variations in its parameters. The basic JSON fields of the attack configuration file are explained below: •type: The type of SCA assessment or attack to be executed for this specific attack instance. It can range between simple leakage indicator tests like TVLA or ML attacks (SVM, RF, Convolutional Neural Networks). The type also indicates if the attack is related to remote SCAs (using multi-tenant FPGAs) or local SCA •target settings: Various information regarding the target of the attack, its hardware or software platforms and the underlying cryptographic implementation. •report directory: The output directory of the SCA assessment report. •model file: A pre-trained ML model that is ready to use for inference. •trace file: The file containing the trace dataset. •features file: This field is relevant in cases when the feature preprocessing has already been completed and the relevant features are saved in a separate file. •retrain: A boolean value indicating the retraining of a new ML model based on the trace dataset or the reuse of an existing one. •attack settings: These JSON subfields are utilized as a LUT from the SCA script library, which automatically selects the correct settings based on the type of the attack the security expert has chosen to conduct. 3.3.3.2 Output During the attack process, the user of the platform constantly interacts with the Jupyter Notebook to proceed to the next semi-automated steps of the acrshortSCA vulnerability assessment. Based on predefined thresholds that are unique for each type of attack, a final level of leakage severity is generated for the attack instance. This severity indicator, alongside information about the attack itself, the DuT and possible recommendations for strengthening the underlying cryptographic implementation are included in the acrshortSCA Assessment Report. Its JSON format is explained below: RESCALE – Public – Page 22 / 38 Hardware Vulnerability and Leakage Detection (first version) { { "title": "SCA Toolbox Leakage Assessment Report", "date": "YYYY-MM-DD", "assessed_system": { "system_UUID": "", "hardware_platform": "", "software_version": "", "operating_system": "", "algorithm": "" "Mitigations": { "type": "", "description": "", }, "side_channel_attack": { "SCA_UUID": "", "type": "", "description": "", "tools_used": [], "leakage": { "severity_level": "", "impact_description": "" }, }, "leakage_metrics": { "type_of_metrics": [ "threshold" ], "metric_values": }, "recommendations": "" } •assessed system: The information relevant to the target system to be assessed, including fields like the hardware platform, software version, the operating system if present and the algorithm under attack. •side channel attack: This field gives a brief pre-generated description of the attack to be executed (CPA, DPA, ML etc.). In addition, information is collected about all the possible tools or software libraries that were necessary for the execution of this specific attack. •leakage: This field provides information about the leakage severity level that was attributed after the leakage assessment has been completed. This severity metric is an integer value and indicates the potential vulnerability from side channel attacks the target system to be assessed is under. Thus, it constitutes a quick and easy way to raise potential suggestions about new countermeasures required against such attacks. RESCALE – Public – Page 23 / 38 Hardware Vulnerability and Leakage Detection (first version) •leakage metrics: In this field, technical information related to the specific attack and its corresponding leakage are presented, including various metric values. •recommendations: Possible courses of action to be taken as next steps in order to protect the target system to be assessed when we have high leakage severity. RESCALE – Public – Page 24 / 38 Hardware Vulnerability and Leakage Detection (first version) 4 Open Issues 4.1 Identified Challenges 4.1.1 Generic SCA Assessment Challenges Defining generic assessment strategies of side-channel leakage for software or hardware IP Cores is very difficult to achieve. In fact, the relevant literature relies on custom assessment flows that follow common generic principles per attack type, but are realized in practice differently. This makes it challenging to provide a unified way of assessing multiple different IP cores (i.e., IP Cores with different cryptography functionalities). Creating an exhaustive list of attacks per type of cryptography scheme implementation is not always realistic, hence the challenge of creating an expandable assessment flow remains. Thus, the Dynamic Hardware Analyzer system will have to be structured in such a way that can support a corpus of indicative SCAs that can be used for security testing a given cryptography IP core. However, such a corpus cannot be complete. Instead, proper structures within the Dynamic Hardware Analyzer must be provided to include in the future new SCAs (or SCA updates). Another challenge to consider is the fact that well-known SCAs are not directly reflected in CWE/CVE databases. They are often considered the means to facilitate some more high-level Exploit/Vulnerability. However, in RESCALE we consider that discovering exploitable leakage and pointing to possible exploits of such leakage towards an SCA constitute important information to be considered when an IP Core component needs to be trusted in the Hardware or Software supply chain. Hence, in the RESCALE Dynamic Hardware Analyzer, we need to provide a reporting mechanism, in line with the CycloneDX initiative (promoted in the project) that will provide a measurable indication of the risk and attack severity associated with SCA leakage. An initial attempt towards this end is provided in paragraph 3.3.3.2 and also in the Dynamic Hardware Analyzer CycloneDX declaration of Deliverable 3.3. 4.1.2 Multi-tenant FPGA PSCA challenges Researchers face significant challenges in the context of PSCAs on multi-tenant FPGA environments. In the RESCALE project, we use the Hardware Analyzer module to evaluate potential attacks, demonstrating that, if attackers have sufficient time and resources, they can eventually mount a successful attack. Assessment becomes more complex when several tenants are sharing the same FPGA platform—thus introducing noise in the measurements. This, however, does not mean that an SCA cannot be mounted, but rather that an existing assessment flow must be modified to take into account such noise. Countermeasures on PSCA can increase the amount of time and resources that an attacker needs to mount an attack. However, they cannot prevent a determined attacker with significant resources/time from actually bypassing mitigation mechanisms. Another challenge is that the sensors employed for these attacks and analyzers can impose additional stress on the FPGA, potentially degrading its performance and stability. These challenges emphasize the critical need to understand and address security vulnerabilities in multi-tenant FPGA systems. Furthermore, ensuring fairness in resource allocation while maintaining security is a significant challenge, as implementing defenses often RESCALE – Public – Page 25 / 38 Hardware Vulnerability and Leakage Detection (first version) rics, providing possible countermeasures or general courses of action in case of high leakage severity. However, this step of the process should be manually curated and monitored by the security expert that validates the final report. Figure 9: SCA assessment report generation example. 5.2.2 Multi-tenant FPGA SCA For performing CPA on Multi-tenant FPGA, the open-source SCABox-App9Python application, that is currently partially integrated into the Trace Collector component, is used in tandem with the trace analysis libraries. SCABox-App application can operate on any computer connected through a USB UART interface to an FPGA board emulated a multi-tenant FPGA. The Python application conducts several AES iterations in chunks, collecting sensor measurements during each cycle. After each chunk, it performs a CPA on the final cycle of each AES iteration, using the sensor data alongside the resulting ciphertext. Since the encryption key used in the attack is known, it’s possible to determine when enough data has been collected for a successful outcome. The application also includes a framework that visualizes correlation analysis through plots of the correlation against time samples and the number of traces. The user can specify parameters such as the number of AES iterations (N), the number of chunks (C), and the attack target. The total number of iterations in a single attack is calculated as N x C. The attack can target either the board’s USB port where the design runs or a directory of stored binary files from previous attacks. Although filtering can be applied to the data collected, it is not essential for the attack’s success. CPA operates on the hypothesis that power consumption measurements are correlated to data and operations processed within the cryptographic device. Using this approach, the analyzer 9https://emse-sas-lab.github.io/SCAbox/ RESCALE – Public – Page 32 / 38 Hardware Vulnerability and Leakage Detection (first version) builds a hypothetical power model of the cryptographic process, estimating power consumption based on different possible values of the secret data. By calculating the Pearson correlation coefficient between predicted power values (from the model) and actual measured power traces, the analyzer assesses the linear relationship between them. The Pearson correlation coefficient, which ranges from -1 to +1, quantifies this relationship, with +1 indicating a perfect positive linear correlation and -1 a perfect negative one. If the traces are strongly correlated with a specific model prediction, this signals that the hypothetical model closely matches the actual cryptographic operation, allowing the secret data to be inferred. This statistical approach makes CPA a powerful method for extracting sensitive information from power consumption patterns. The assessment process is sketched in Figure 10. Figure 10: SCA in multi-tenant FPGA block diagram. An example of hardware leakage with TDC sensors is shown in Figure 11. There are 11 distinct spikes, one for every AES cycle. The measurements between those spikes show a similar, repeated pattern. This is due to the same calculations that happen at each AES cycle and the divergence between them is because of the different data that are being processed. This means that the AES functionality is capturable by the TDC sensors and that, each time the AES 128bit output register is overwritten at the end of each cycle, a high voltage drop occurs and is captured by the sensor. Although the cryptographic module’s behavior is observable in the plot of the TDC sensor measurements, this does not mean that the statistical evaluation of the data can successfully lead to the extraction of the key. Multiple AES iterations need to be captured for the CPA to have a good result for any of the key’s bytes. After the CPA, the result in Figure 12 shows the most probable byte value of the key (red line). The sooner the first true byte of the key has the highest correlation and is determined as the most probable by the CPA attack, the more vulnerable the system is. RESCALE – Public – Page 33 / 38 Hardware Vulnerability and Leakage Detection (first version) Figure 11: AES leakage plot. Figure 12: Pearson’s correlation plot. This initial experiment for the SCA in an AES module was conducted on a ZedBoard10 platform with AMD Xilinx Zynq®-7000 SoC actin as a controlled environment for the trace collector. However, the Hardware Analyzer can be evaluated in several other platforms, with different types of SCA scenarios, targeting multiple modules. 10https://www.xilinx.com/products/boards-and-kits/1-8dyf-11.html RESCALE – Public – Page 34 / 38 Hardware Vulnerability and Leakage Detection (first version) 6 Main Innovations & Conclusion 6.1 Main Innovations The goal of the Dynamic Hardware Analyzer with its two components (Trace collector and Trace Analyzer) is to provide a comprehensive SCA leakage assessment approach in a unified, comprehensive way. To this end, we introduce several innovations for both trace collection and trace analysis. The trace collection approach followed in the RESCALE platform is meant to be simple and flexible, especially when it comes to hardware IP Core assessment. The provided APIs can be easily used in order to create an assessment flow and remain, up to a point, controlled environment agnostic. Regarding the Trace Analyzer component, while we cannot provide a complete assessment library (i.e., for every SCA type and for every cryptography scheme implementation type), we provide a unified mechanism for assessment and reporting. Beyond that, Trace Analysis is focused on the most potent SCAs (i.e., DL profiling attacks) and how to apply this approach to new and popular cryptography scheme implementations like Public Key Cryptography—and more specifically Postquantum Cryptography (for standardized schemes). The outcome of this research innovation is to introduce new SCAs in order to assess such target systems. Furthermore, in the RESCALE project, our work extends traditional SCA scenarios on multitenant FPGAs by considering the involvement of multiple other users in addition to the attacker and the victim. These additional users contribute to the system by generating voltage noise within the PDN and altering various environmental variables, which can introduce complexity into the analysis. Additionally, in another scenario, the user implementing the cryptographic algorithm introduces deliberate noise to mask the process and obscure side-channel leakage. This expanded scenarios aim to better reflect real-world conditions in multi-tenant cloud environments, where multiple workloads and mitigations can influence the vulnerability of cryptographic systems and affect the accuracy of side-channel leakage detection. 6.2 Conclusion In this deliverable we described the overall concept, architecture, and functionalities of the hardware vulnerability and leakage detection mechanism introduced in the RESCALE project. This mechanism is consolidated into the Dynamic Hardware Analyzer solution and its components were also described at a high level. We also described open issues that we plan to consider after the submission of the deliverable till the end of Task 3.3. It can be concluded that there are several research directions to be explored in terms of SCA assessment, but also several obstacles to overcome—both practical and theoretical. The SCA research domain is huge and diverse, which highlight the need to focus on specific concepts in Task 3.3 and integrate them into the Dynamic Hardware Analyzer platform. Finally, in this Deliverable, we describe how the overall solution will be provided within the RESCALE platform (i.e., split into two different blocks, trace collection and trace analysis). RESCALE – Public – Page 35 / 38 Hardware Vulnerability and Leakage Detection (first version) 6.3 Future Work The Dynamic Hardware Analyzer tool will be upgraded to aggregate a wide range of SCA outcomes from various subplatforms, including FPGAs and CPUs focusing on the further integration of the multi-tenant FPGA assessment approaches. This enhancement will involve creating a robust report management system designed to simplify the analysis process, enabling users to consolidate, compare, and interpret data across different attack vectors and hardware configurations. The reporting mechanism will be made more fine-grained to ensure that it is both comprehensive and detailed, while remaining adaptable to changing requirements. This design will facilitate seamless integration into advanced frameworks like DSCG and TBOM. The Hardware Analyzer platform will be further evaluated in more complex environments with multiple users to assess its effectiveness and adaptability in realistic multi-tenant scenarios as well as in traditional controlled environments for existing hardware and software IP Core cryptography implementations (mostly Public Key cryptography). Furthermore, since PSCAs are often difficult to fully mitigate by allowing an attacker, in many cases, to eventually succeed with sufficient time and resources, the platform will also focus on analyzing the severity of vulnerabilities over time. By incorporating time-based standards, the Dynamic Hardware Analyzer will help quantify how quickly a system could be compromised, offering critical metrics to prioritize security measures and assess the practical risks of such attacks. This quantification will be consolidated in severity level metrics that resemble traditional risk analysis metrics in the relevant research literature. Task 3.3 will be collaborating with the RESCALE use-case pilots (especially the PST pilot) to identify how the Dynamic Hardware Analyzer can be evaluated by assessing IP Cores on the IoT platform or cloud infrastructure of the pilots. RESCALE – Public – Page 36 / 38 Hardware Vulnerability and Leakage Detection (first version) References [1] Suresh Chari, Josyula R. Rao, and Pankaj Rohatgi. Template attacks. In Burton S. Kaliski, c¸etin K. Koc¸, and Christof Paar, editors, Cryptographic Hardware and Embedded Systems - CHES 2002, pages 13–28, Berlin, Heidelberg, 2003. Springer Berlin Heidelberg. [2] Christos Diktopoulos, Konstantinos Georgopoulos, Andreas Brokalakis, Georgios Christou, Grigorios Chrysos, Ioannis Morianos, and Sotiris Ioannidis. Assessing the effectiveness of active fences against scas for multi-tenant fpgas. In 2022 32nd International Conference on Field-Programmable Logic and Applications (FPL), pages 391–396, 2022. [3] Eduardo Ferrufino, Luke Beckwith, Abubakr Abdulgadir, and Jens-Peter Kaps. Fobos 3: An open-source platform for side-channel analysis and benchmarking. In Proceedings of the 2023 Workshop on Attacks and Solutions in Hardware Security, ASHES ’23, page 5–14, New York, NY, USA, 2023. Association for Computing Machinery. [4] Apostolos P. Fournaris, Athanassios Moschos, and Nicolas Sklavos. Side Channel Assessment Platforms and Tools for Ubiquitous Systems, pages 147–163. Springer International Publishing, Cham, 2021. [5] Ognjen Glamoˇ canin, Louis Coulon, Francesco Regazzoni, and Mirjana Stojilovi´ c. Are cloud fpgas really vulnerable to power analysis attacks? In 2020 Design, Automation & Test in Europe Conference & Exhibition (DATE), pages 1007–1010, 2020. [6] Joseph Gravellier, Jean-Max Dutertre, Yannick Teglia, and Philippe Loubet-Moundi. High-speed ring oscillator based sensors for remote side-channel attacks on fpgas. In 2019 International Conference on ReConFigurable Computing and FPGAs (ReConFig), pages 1–8, 2019. [7] Yanning Ji, Ruize Wang, Kalle Ngo, Elena Dubrova, and Linus Backlund. A side-channel attack on a hardware implementation of crystals-kyber. In 2023 IEEE European Test Symposium (ETS), pages 1–5, 2023. [8] Xiangjun Lu, Chi Zhang, Pei Cao, Dawu Gu, and Haining Lu. Pay attention to raw traces: A deep learning architecture for end-to-end profiling attacks. IACR Transactions on Cryptographic Hardware and Embedded Systems, 2021(3):235–274, Jul. 2021. [9] A. Moschos, A. P. Fournaris, and O. Koufopavlou. A flexible leakage trace collection setup for arbitrary cryptographic ip cores. In 2018 IEEE International Symposium on Hardware Oriented Security and Trust (HOST), pages 138–142, Los Alamitos, CA, USA, may 2018. IEEE Computer Society. [10] Guilherme Perin, Lichao Wu, and Stjepan Picek. Exploring feature selection scenarios for deep learning-based side-channel analysis. IACR Transactions on Cryptographic Hardware and Embedded Systems, 2022(4):828–861, Aug. 2022. [11] Stjepan Picek, Guilherme Perin, Luca Mariot, Lichao Wu, and Lejla Batina. Sok: Deep learning-based physical side-channel analysis. ACM Computing Surveys, 55(11), feb 2023. RESCALE – Public – Page 37 / 38 Hardware Vulnerability and Leakage Detection (first version) [12] Zehua Qiao, Yuejun Liu, Yongbin Zhou, Jingdian Ming, Chengbin Jin, and Huizhong Li. Practical public template attacks on crystals-dilithium with randomness leakages. IEEE Transactions on Information Forensics and Security, 18:1–14, 2023. [13] Junichi Sakamoto, Kazuki Tachibana, and Tsutomu Matsumoto. Application of profiled analysis to adc-based remote side-channel attacks. In 2023 IEEE 9th Intl Conference on Big Data Security on Cloud (BigDataSecurity), IEEE Intl Conference on High Performance and Smart Computing, (HPSC) and IEEE Intl Conference on Intelligent Data and Security (IDS), pages 115–121, 2023. [14] Falk Schellenberg, Dennis R.E. Gnad, Amir Moradi, and Mehdi B. Tahoori. An inside job: Remote power analysis attacks on fpgas. In 2018 Design, Automation & Test in Europe Conference & Exhibition (DATE), pages 1111–1116, 2018. [15] David Spielmann, Ognjen Glamocanin, and Mirjana Stojilovic. Rds: Fpga routing delay sensors for effective remote power analysis attacks. Cryptology ePrint Archive, Paper 2023/043, 2023. https://eprint.iacr.org/2023/043. [16] Mark Zhao and G. Edward Suh. Fpga-based remote power side-channel attacks. In 2018 IEEE Symposium on Security and Privacy (SP), pages 229–244, 2018. RESCALE – Public – Page 38 / 38