A formal model for proving hardware timing properties and identifying timing channels

Integration, the VLSI Journal xxx (xxxx) xxx

Contents lists available at ScienceDirect

Integration, the VLSI Journal journal homepage: www.elsevier.com/locate/vlsi

A formal model for proving hardware timing properties and identifying timing channels Maoyuan Qin a , Xinmu Wang a , Baolei Mao b, ∗ , Dejun Mu a , Wei Hu a a b

Northwestern Polytechnical University, 127 West Youyi Road, Xi’an, China Zhengzhou University, 100 Kexue Road, Zhengzhou, China

A R T I C L E

I N F O

Keywords: Hardware security Timing channel Information flow model Formal verification Security vulnerability

A B S T R A C T

Timing channels are becoming a critical threat to hardware security. When exploited, secret information can be revealed by analyzing the execution time statistically. There are a variety of methods for detecting timing channels such as statistical analysis, testing and formal verification. However, existing methods cannot guarantee that the timing channels can be identified due to limited test coverage or high performance overhead. In this work, we introduce a novel model for evaluating timing variations of the hardware design. Furthermore, we propose a systematical solution that integrates time label enhanced tracking logic and formally verifies the timing invariant property of hardware designs in order to identify hardware timing channels. We demonstrate our solution on several hardware implementations, including arithmetic units, cryptographic cores and cache. The proof results show that our solution can detect hardware timing channels effectively.

1. Introduction Hardware timing channel provides a new attack surface for hackers due to unbalanced execution paths such as conditional branches, cache hit/miss and fast paths in arithmetic units that run in non-fixed time [1]. The adversaries can extract the private key by leveraging the correlation between secret information and execution time of the system [2] or steal confidential information by exploiting the CPU branch predictor out-of-order execution/speculative prediction mechanism and cache timing channel [1,3]. Since hardware vulnerabilities are hard to patch after fabrication, an effective pre-silicon approach to identify timing flows and detect timing channel vulnerability can be crucial. In order to address this security threat resulting from hardware timing channels, many detection methods have been proposed recently. Statistical based analysis identifies hardware timing channels by performing statistical test of the run-times. Reparaz et al. employ statistical tests such as t-test and non-parametric tests to check whether two sets of run-times are statistically different [4]. Mao et al. quantify the timing leakage through information theoretic methods and timing attacks to analyze the influence of the key on the timing variations [5]. While test-based analysis will identify timing channels by fuzzing, concolic testing and simulation methods. For example, He et al. employ

Coverage-Guided Greybox Fuzzing to detect two-safety property violations, including constant-time property [6]. SecVerilog enables designers to precisely deduce timing information flow using a security type system whose operational semantics correspond directly to hardware simulation at RTL abstraction. These RTL simulations accurately reflect the timing behaviors of synthesized hardware [7]. However, all these approaches are only applicable to inspect hardware designs by test, or they are always limited by low test coverage and huge overhead. Although exhaustively analysis may provide high test coverage for hardware design, it is unrealistic for large-scale designs because of timeconsuming and intensive resource requirements. Another representative approach to identify hardware timing flows is formal verification by model checking and deductive verification. Formal verification proves the correctness of the intended design with respect to required specifications or properties. It can help verify important security properties such as confidentiality, integrity and isolation. If the proof passes, it indicates the design is secure. This significantly shortens the verification time with high verification coverage. Especially, information flow tracking (IFT) based solutions are proposed to identify timing information flows. These solutions propose different IFT models to verify whether the properties of the circuit violate the security policies [8]. Unfortunately, these IFT models are incapable

∗ Corresponding author. E-mail addresses: [email protected] (M. Qin), [email protected] (X. Wang), [email protected] (B. Mao), [email protected] (D. Mu), [email protected] (W. Hu). https://doi.org/10.1016/j.vlsi.2020.02.001 Received 10 December 2019; Accepted 3 February 2020 Available online XXX 0167-9260/© 2020 Elsevier B.V. All rights reserved.

Please cite this article as: M. Qin, et al., A formal model for proving hardware timing properties and identifying timing channels, Integration, the VLSI Journal, https://doi.org/10.1016/j.vlsi.2020.02.001

M. Qin et al.

Integration, the VLSI Journal xxx (xxxx) xxx

of isolating timing flows from functional flows. Oberg et al. propose a framework based on Gate Level Information Flow Tracking (GLIFT) to identify timing flows. However, this framework can only verify the timing flow when timing flow exists and function flow does not[9]. Ardeshiricham et al. integrate functional flow tracking logic into the solution to identify timing flows in RTL hardware design. It requires constructing all the control flow graphs and data flow graphs in the abstract syntax tree of hardware design and traversing all the conditional branch statements, which is a complicated and challenging task for hardware designers [10]. In this work, we illustrate the timing invariant property of hardware design to guarantee timing channel security and propose a method for modeling timing variations of hardware designs. By associating each bit of the variable with a time label that carries the timing information and tracking the time label propagation, we can understand how input variations affect the timing variation of the output ruling out the sophisticated effect of functional flows. Based on the timing variation model, we propose a solution to detect hardware timing channels during the design phase. This solution provides a self-developed tracking logic generation tool to automatically model the time label propagation of the original design. And the generated time label tracking logic is integrated into verification tools for formal proof of the timing invariant property. Finally, we can identify the timing channel effectively according to the proof results. In this paper, we show how to use the proposed solution to prove that various architectures have timing variations, indicating potential hardware timing channels; or we will prove that some hardware designs have constant execution time, being free of timing channel vulnerabilities. More specifically, the major contributions of this paper are as follows:

In this work, we perform formal security verification during the design or verification stage. Our security analysis focuses on verifying the RTL hardware design code or gate-level net-list, and does not consider security vulnerabilities that have already been fabricated into the chip. To perform our security analysis, we assume that we have access to the RTL codes or gate-level net-list for the given hardware designs and are allowed to construct the verification model for them. Although we identify timing channel vulnerabilities through formal proof in this work, we will not try to extract secret information for simplicity. For simplicity, we do not consider the effect of transistor switching characteristics on time delay. We focus on modeling the timing variation of the hardware system at logic level. 3. Preliminaries In this section, we first illustrate the timing properties of hardware design. Then we elaborate on the limitation of existed hardware IFT approaches for detecting hardware timing flow, the motivation for characterizing timing variation by the model associated with time label, and the preliminary definitions for this model. 3.1. Timing properties of hardware design Hardware timing flows exist from the input to the output of hardware design if the hardware execution time varies with different input values. To better represent the timing properties of hardware design, we formulate it in a symbolic manner. A hardware design S is defined as a function O = S(I), where I and O are the input and the output; the execution time for S can be retrieved by a function time(∗ ). Hence, we can derive two timing properties for the hardware design as follows:

• Proposing a new method for modeling timing variations of hardware design by associating a set of time labels and tracking their propagation. • Providing a solution for detecting hardware timing channels by formal proof of timing invariant property of the time label tracking logic for hardware design. • Demonstrating the effectiveness of the proposed timing channel detection solution in several hardware designs, such as cryptographic functions, arithmetic units and cache design.

• The timing property for a hardware design S without timing flows: For any different input values, the execution time of the hardware design is a constant time C.

∀i1 , i2 ∈ I , time(S(i1)) = time(S(i2 ))

(1)

• The timing property for a hardware design S with timing flows: There are different input values, the execution time of the hardware design is not a constant time C.

The reminder of the paper is organized as follows. Section 2 describes the hardware timing channel threat model. Section 3 introduces the preliminaries about timing invariant property, the motivation for IFT techniques identifying timing flows, and the preliminary definitions. Section 4 illustrates how to model timing variations and derive time label propagation rules. Section 5 elaborates on the hardware timing channel detection methodology in detail. Section 6 presents experimental results of the proposed solution on different hardware implementations such as cryptographic functions, arithmetic units, and cache. Section 7 reviews related work in hardware timing channel detection. Finally, we conclude in Section 8.

∃i1 , i2 ∈ I , time(S(i1)) ≠ time(S(i2))

(2)

Assuming that the run-times are timing samples from the hardware timing channel, we can prove that the Shannon entropy for Equation (1) is zero, indicating there is no timing channel information leakage. While the Shannon entropy for Equation (2) is non-zero, indicating there is timing channel information leakage. Therefore, the timing invariant property for hardware design without timing flows is formalized and proved by information theory.

3.2. Hardware IFT technique and timing flow 2. Threat model The existed hardware IFT approaches employ the general label method and label propagation rules to capture all logical information flow in hardware design. In their label methods, each data variable is associated with a security label for indicating the security attribute of the variable such as secret/untrusted and unclassified/trusted. Through tracking the propagation of security attribute labels, the designer can verify important security properties such as whether the secret information leaks to an unclassified output or if the untrusted data overwrites a trusted memory block. However, logical information flow can be classified into functional flow or timing flow. If the hardware design including both functional flow and timing flow violates the security properties such as confidentiality and integrity, it is difficult for the designer to distinguish the timing flow from logical information flow and determine if timing flow plays the most important role. This significantly limits the

A hardware system is composed of different components to achieve different functions. For example, CPU contains lots of arithmetic units such as multiplication and division, as well as control units such as conditional branches. Hardware design may integrate cache to improve RAM read/write efficiency or integrate cryptographic functions for authentication and encryption. However, all these implementations themselves may be insecure because of secret information leakage due to timing variations. We assume that a given hardware design may contain timing channels resulting from unbalanced conditional branches, cache hit/miss or fast paths in arithmetic units that do not run in constant time. It is very likely that these security vulnerabilities are to leak secret information when exploited by the adversary.

2

M. Qin et al.

Integration, the VLSI Journal xxx (xxxx) xxx

application of IFT techniques in such cases where the functional flow is inevitable, while timing flow should be eliminated [11]. To address this limitation, we propose a new set of time labels and propagation rules for modeling timing variation. We associate each logic variable with a time label carrying the timing information instead of a security label carrying the security attributes. And the time labels propagate based on the time label propagation rules. By tracking time label propagation through the time label tracking logic, we can observe whether different inputs lead to timing variation of the output, resulting in timing invariant property violation. If the timing invariant property is violated, we can identify the timing channel directly, regardless of any effect from the functional flow.

Table 1 Truth table of the time label tracking logic for AND-2. #

(A, At )

(B, Bt )

(O, Ot )

1 2 3 4

(0, x) (0, x) (1, x) (1, x)

(0, y) (1, y) (0, y) (1, y)

(0, min(x, y)) (0, x) (0, y) (1, max(x, y))

Table 2 Truth table of the time label tracking logic for OR-2.

3.3. Preliminary definition To facilitate modeling timing variation, we define the preliminary notions for time, time label, and the tuple of logic variable and time label as follows:

#

(A, At )

(B, Bt )

(O, Ot )

1 2 3 4

(0, x) (0, x) (1, x) (1, x)

(0, y) (1, y) (0, y) (1, y)

(0, max(x, y)) (1, y) (1, x) (1, min(x, y))

• Definition 1 — Time: The time refers to the global clock cycles in modeling timing variations.

• Definition 2 — Time Label: The time label is a multi-bit label which

logic value of the input (A, At ) equals 0, the logic value of the output (O, Ot ) is determined by the logic value of the input (A, At ) regardless of the logic value of the input (B, Bt ). Hence, the time label of the input (A, At ) should propagate to the output, i.e., time(O, Ot ) = x. Thus, we can derive that when A and B are 0 and 1, respectively, time(O, Ot ) equals time(A, At ). Then let us consider row3 ((A, At ) = (1, x), (B, Bt ) = (0, y)). In this case, as long as the logic value of the input (B, Bt ) equals 0, the logic value of the output (O, Ot ) is determined by the logic value of the input (B, Bt ) regardless of the logic value of the input (A, At ). Hence, the time label of the input (B, Bt ) should propagate to the output, i.e., time(O, Ot ) = y. Thus, we can derive that when A and B are 1 and 0, respectively, time(O, Ot ) equals time(B, Bt ). Let us consider row4 ((A, At ) = (1, x), (B, Bt ) = (1, y)). In this case, the logic values of both inputs are 1. If x < y, the logic value of the input (A, At ) updates to 1 earlier than the input (B, Bt ), thereby the logic value of the output (O, Ot ) is determined by the input (B, Bt ). Hence, the time label of the input (B, Bt ) should propagate to the output, i.e., time(O, Ot ) = y. If x > y, the logic value of the input (B, Bt ) updates to 1 earlier than the input (A, At ), thereby the logic value of the output (O, Ot ) is determined by the input (A, At ). Hence, the time label of the input (A, At ) should propagate to the output, i.e., time(O, Ot ) = x. Therefore, we derive that when both the input logic values are 1, the time label of the output is consistent with the time label of the last update input, i.e., (O, Ot ) = (0, max(time(A, At ), time(B, Bt ))). The above analysis indicates that the timing variation for AND-2 depends on not only the values of the input variables, but also their time labels.

associates with each logic variable to represent the update time of the logic variable. (In the rest of the article, letters with a subscript t denote the time labels of logic variables such as At and Bt , letters without a subscript denote logic variables such as A and B.) • Definition 3 — Tuple: The logic variable v and its time label vt are represented as one tuple (v, vt ), where the Boolean value of v and the time value of vt can be retrieved by the functions eval(v, vt ) and time(v, vt ), respectively. 4. Modeling timing variations For simplicity, we model timing variations for primitive logic functions (AND, OR, NOT, and D flip-flop) instead of the sophisticated RTL operations and derive their time label propagation rules. 4.1. Time label propagation rule for AND-2 The general form for a two-input AND gate (AND-2) is O = A · B, where A, B and O are the inputs and the output. We tag A, B and O with time labels At , Bt and Ot , respectively. Hence, the inputs and the output of the time label tracking logic for AND-2 can be represented as (A, At ), (B, Bt ) and (O, Ot ), respectively. If both inputs update at the same clock cycle (time(A, At ) = time(B, Bt )), the output is synchronous with the inputs. Its time label should equal At or Bt . Therefore, we only discuss the scenarios where the inputs update at different clock cycles (time(A, At ) ≠ time(B, Bt )). Table 1 is the truth table of the time label tracking logic for AND2, where (A, At ), (B, Bt ) and (O, Ot ) are the inputs and the output. In Table 1, we assume that time(A, At ) = x and time(B, Bt ) = y. If x < y, the input (A, At ) updates earlier than the input (B, Bt ). If x > y, the input (B, Bt ) updates earlier than the input (A, At ). Firstly, let us consider row1 in Table 1 ((A, At ) = (0, x), (B, Bt ) = (0, y)). In this case, the logic values of both inputs are 0. If x < y, the logic value of the input (A, At ) updates to 0 earlier than the input (B, Bt ), thereby the logic value of the output (O, Ot ) is determined by the input (A, At ). Hence, the time label of the input (A, At ) should propagate to the output, i.e., time(O, Ot ) = x. If x > y, the logic value of the input (B, Bt ) updates to 0 earlier than the input (A, At ), thereby the logic value of the output (O, Ot ) is determined by the input (B, Bt ). Hence, the time label of the input (B, Bt ) should propagate to the output, i.e., time(O, Ot ) = y. Therefore, we derive that when both the input logic values are 0, the time label of the output is consistent with the time label of the first update input, i.e., (O, Ot ) = (0, min(time(A, At ), time(B, Bt ))). Let us consider row2 ((A, At ) = (0, x), (B, Bt ) = (1, y)). In this case, as long as the

4.2. Time label propagation rule for OR-2 The general form for a two-input OR gate (OR-2) is O = A + B, where A, B and O are the inputs and the output, respectively. We tag A, B and O with time labels At , Bt and Ot , respectively. Hence, the inputs and the output of the time label tracking logic for OR-2 can be represented as (A, At ), (B, Bt ) and (O, Ot ), respectively. To evaluate timing variation of OR-2 for different inputs, we toggle the inputs at different clock cycles (time(A, At ) ≠ time(B, Bt )) and observe the output. Table 2 is the truth table of the time label tracking logic for OR-2. Similarly, we assume that time(A, At ) = x and time(B, Bt ) = y. According to the analysis based on DeMorgan Law, the timing variation for OR-2 is exactly the opposite of AND-2. Specifically, if both A and B are 0, the time label of the output is consistent with the time label of the last update input, i.e., (O, Ot ) = (0, max(time(A, At ), time(B, Bt ))); if A and B are 0 and 1, respectively, the time label of the output is consistent with the time label of the input (B, Bt ), i.e., (O, Ot ) = (1, time(B, Bt )); if A and B are 1 and 0, respectively, the time label of 3

M. Qin et al.

Integration, the VLSI Journal xxx (xxxx) xxx

and Qt , respectively. Hence, the input and the output of the time label tracking logic for D flip-flop can be represented as (I, It ) and (Q, Qt ), respectively. D flip-flop latches the input data in the current clock cycle and validates it on the output in the next clock cycle. Thus, the time value of Qt should equal the sum of 1 and the time value of It . Let us consider row1 ((I, It ) = (0, x)) and row2 ((I, It ) = (1, y)) in Table 4, which is the truth table of time label tracking logic for D flip-flop. When the logic value of the input is set to 0 in the x clock cycle, the logic value of the output should update to 0 in the next clock cycle, the time value of the output equals x + 1. When the logic value of the input is set to 1 in the y clock cycle, the logic value of the output should update to 1 in the next clock cycle, the time value of the output equals y + 1. Similarly, the time label of the output for D flip-flop is determined by the time label of the input.

Table 3 Truth table of the time label tracking logic for NOT. #

(I, It )

(O, Ot )

1 2

(0, x) (1, x)

(1, x) (0, x)

Table 4 Truth table of the time label tracking logic for D flip-flop. #

(I, It )

(Q, Qt )

1 2

(0, x) (1, y)

(0, x + 1) (1, y + 1)

the output is consistent with the time label of the input (A, At ), i.e., (O, Ot ) = (1, time(A, At )); if both A and B are 1, the time label of the output is consistent with the time label of the first update input, i.e., (O, Ot ) = (1, min(time(A, At ), time(B, Bt ))). Thus, we can derive that the timing variation for OR-2 are influenced by both the logic values of the inputs and their time labels.

5. Detection methodology We develop a systematic solution to detect timing flows in hardware design. The design flow is shown in Fig. 1. This solution contains four parts: (i) Constructing time label tracking logic library; (ii) Modeling the time label tracking logic for the hardware design; (iii) Deriving timing invariant properties; (iv) Identifying hardware timing flows by formally verifying that the time label tracking logic follows the timing invariant properties. In the following subsections, we will specifically illustrate this design flow in more detail.

4.3. Time label propagation rule for NOT The general form for an NOT gate is O = ¬I, where I and O are the input and the output, respectively. We tag I and O with time labels It and Ot , respectively. Hence, the input and the output of the time label tracking logic for NOT can be represented as (I, It ) and (O, Ot ), respectively. The output for an NOT gate is always synchronous with the update of the input. Hence, the time label of the output is consistent with the time label of the input. Let us consider row1 ((I, It ) = (0, x)) and row2 ((I, It ) = (1, x)) in Table 3, which is the truth table of the time label tracking logic for NOT. If the logic value of the input (I, It ) equals 0 in the x clock cycle, the logic value of the output should update to 1 immediately. If the logic value of the input (I, It ) equals 1 in the x clock cycle, the logic value of the output should update to 0 immediately, too. Therefore, we can derive that the time label of the output for the NOT gate is consistent with the time label of the input.

5.1. Time label tracking logic library The time label tracking logic is a circuit for modeling timing variation of the Boolean circuit. It can be created by associating each logic variable with a time label and performing time label propagation. In the time label tracking logic, the time label propagates based on the time label propagation rules described in Section 4. For better understanding, we take the AND-2 gate shown in Fig. 2 (a) as an example. A, B and O are the inputs and the output; At , Bt and Ot denote the time labels of A, B and O, respectively. The time label of the AND-2 output is determined by both the logic values of the inputs and their time labels following the time label propagation rule illustrated in Section 4.1. Thus, we can construct the time label tracking logic for AND-2 similar to the structure of MUX-4 shown in Fig. 2 (b), where At , Bt , the maximum between At and Bt , the minimum between At and Bt are the inputs; (A, B) is the select line; O and Ot are the logical output and the output time label, respectively. When the select line (A, B) is (0, 0), or (0, 1), or (1, 0), or (1, 1), the time label Ot will equal the minimum

4.4. Time label propagation rule for D flip-flop The general form for a D flip-flop is Q = I, where I and Q are the input and the output, respectively. We tag I and Q with time labels It

Fig. 1. Design flow of the proposed solution. 4

M. Qin et al.

Integration, the VLSI Journal xxx (xxxx) xxx

5.3.1. Deriving timing invariant property We construct the timing invariant property in three steps. Firstly, we identify the output signals of the computation result and the signals which indicate the completion of the hardware execution (e.g. the ready, done, or complete signals) in the primary outputs. Because their time labels always carry information about the execution time based on the time label propagation rules. Secondly, we estimate the execution time for these time labels. It can be achieved by using offthe-shelf EDA tools or verification tools to test the time label tracking logic by a set of random inputs. In this case, the test result reveals the time values of these time labels directly. Assuming the time label tracking logic is timing invariant, these time labels will always remain the estimated values for a set of arbitrary inputs. Finally, we can translate the timing invariant properties into the standard HDL assertion statements. For example, we consider a time label tracking logic for a hardware design, where A, B and O are the inputs and the output, At , Bt and Ot are their time labels. Suppose the output O is synchronized with the ‘finish’ signal ready. When the signal ready is raised, the output result O and its time label Ot are valid, equalling a calculation result and a time constant C, respectively. Therefore, we formalize the property into the HDL assertion statements Property System-ready shown as below, where Ot should always equal the constant time C when ready is raised.

Fig. 2. (a): AND-2 (b): The time label tracking logic for AND-2.

between At and Bt , or At , or Bt or the maximum between At and Bt , respectively. On the basis of representing the time label tracking logic for AND-2 in HDL, the time label tracking logic for AND-2 can be generated. Similarly, the time label tracking logic for other logics such as OR-2, NOT, D Flip-Flop can also be generated to form the minimum functionally complete tracking logic library. Since the minimum functionally complete tracking logic library is capable of describing all the standard HDL designs to automate the computation of both the logic values and the time labels, it can be integrated into off-the-shelf EDA or verification tools easily.

Property System-ready: @(posedge clock) $rose(ready) |-> ((Ot = = C)) endproperty assert property (System-ready)

5.2. Time label tracking logic for hardware design 5.3.2. Formal verification In this subsection, we will illustrate how to use formal verification to identify timing channels. As shown in Fig. 1, the time label tracking library is integrated into the formal verification tool for translating and understanding time label propagation. The time label tracking logic and the standard HDL assertion for representing the derived timing invariant property are input to the hardware formal verification tool for formal proof. If the proof passes, it indicates that the time label for the output remains the same value no matter how the input changes. The hardware design is free of timing channels. Otherwise, the proof fails and the formal verification tool provides a counterexample that violates the timing invariant property. There will be a timing channel identified in this design. This solution contrasts sharply with existed IFT timing channel detection methods. Firstly, the security label and propagation rules used by other IFT methods are specific for modeling all logical information flows. They are incapable of distinguishing the timing flow from logical information flows directly and independently. In contrast, the time label and propagation rules used in this solution are specific for modeling timing variations of hardware design, and this solution can identify timing channels directly and accurately. Secondly, the time label tracking logic library, the timing invariant properties, and the time label tracking logic can be integrated into off-the-shelf formal verification tools to perform formal verification, lest the designer rewrites the new tracking system. Therefore, this solution is much more convenient and easier to use in practical.

In this subsection, we will illustrate how to model time label tracking logic for the original hardware design. Once the time label tracking logic library is set up, the time label tracking logic for the original design can be generated in a constructive manner. Firstly, the original hierarchical RTL design is synthesized into the net-list. Then, the required time label tracking logic can be instantiated by discretely mapping each logic gate in the net-list to the time label tracking logic library. For better understanding, given a one-bit full adder, it is synthesized into the net-list consisting of five AND-2 gates, three OR-2 gates, and one NOT gate. Subsequently, the time label tracking logic for this adder can be generated by discretely mapping each gate in the netlist to the time label tracking logic library. Once instantiating the time label tracking logic for the net-list and declaring all the time labels for related signals in the signal list, the time label tracking logic for the original hardware design can be obtained. However, manually modeling the time label tracking logic for the large hardware design is impractical due to over workload and unavoidable human errors. Thus, we develop one automatic tracking logic generation tool shown in Fig. 1, which allows us to generate the time label tracking logic for any Boolean circuit constructively. The input to the tracking logic generation tool is the hardware design in the form of RTL code or net-list. This tool automatically synthesizes the original design to the net-list by using the synthesis tool and then translates the netlist to the time label tracking logic. Generating a time label tracking logic in this constructive manner is efficient because it can be finished in polynomial time. For more information about the complexity, please refer to Ref. [12] for more details.

6. Experimental results In this section, we will use some benchmarks from trust-hub.org and opencores.org to illustrate and demonstrate our proposed solution in detecting hardware timing channels. Firstly, we introduce the experimental setup. Then we employ two different modular multiplication implementations to illustrate how to detect hardware timing channels

5.3. Timing channel detection through formal verification We detect the hardware timing channels in two steps: deriving the timing invariant property for the hardware design, and formally verifying this specified property of the time label tracking logic. 5

M. Qin et al.

Integration, the VLSI Journal xxx (xxxx) xxx

Fig. 3. Experimental setup.

by formal proof. Further, we formally verify the timing invariant property of several universally applicable hardware implementations such as arithmetic units, cryptographic functions and cache. Finally, we summarize and discuss their proof results. 6.1. Experimental setup Fig. 3 shows our experimental setup. Given a hardware design in RTL, we first use the tracking logic generation tool to generate the time label tracking logic required for detecting hardware timing channels. We then use Simulink to test the generated time label tracking logic so that we can estimate the execution time (the value of the output time label) of the design. Next, we model the timing invariant property by formalizing the execution time test results as the assertion statements. Finally, we integrate the generated time label tracking logic, the time label tracking logic library, and the assertion statements with Questa Formal for formal proof. If the proof passes, the original design is secure. Otherwise, one potential hardware timing channel can be identified if the proof fails.

Fig. 4. Basic RSA modular multiplication.

cant non-zero bit of the multiplier determines the execution time of the basic RSA modular multiplication. This creates a timing channel. For example, when the multiplier equals 11011 or 01011, respectively, the execution time differs by one clock cycle, as shown in Fig. 4.

6.2. Experimental results 6.2.1. Modular multiplication Modular multiplication is widely used in public-key cryptosystems. The modular multiplication implementation can be performed using different algorithms, and different implementations may result in different timing characteristics. In this section, we employ two representative implementations, one basic RSA modular multiplication core [13] and one Montgomery modular multiplication core [14], to show how to use our solution to test these two designs and verify their timing invariant properties.

Property modmult-ready: @(posedge clk) disable iff(reset) $rose(ready) |=> readyt = = 20′ h00003; endproperty assert property (modmult-ready)

We assess the timing invariant property of the modmult design by initializing all input time labels as 20′h0 and observe the time label value of the ready signal. We generate the time label tracking logic for the modmult design and formalize the property modmultready, in which the time value of time label readyt equals the constant 20′h00003 (estimated by simulation) when the ready signal is raised. After that, we formally prove the modmult-ready property that the module modmult runs in constant time by Questa Formal. However, the proof fails. The proof result shows that the value of readyt varies with the input value, not always equalling the constant 20′h00003. We can conclude that there is a timing channel in the modmult design.

6.2.1.1. Basic RSA modular multiplication. The basic RSA modular multiplication core modmult uses the Shift-and-Add algorithm, which shifts the binary bit of the multiplier from left to right iteratively. Specifically, if the shifted multiplier equals 0, the ready signal is raised for indicating the completion of the computation; otherwise, it continues the rest operations of modular multiplication. There are timing differences for different multipliers with different lengths. Although there is a conditional branch in modular multiplication iteration, there is no timing difference for each iteration. If the least significant bit is 1, it performs an addition; if the lowest bit equals 0, it performs an assignment directly. Both of them are masked by subtraction and other operations, costing the same clock cycles. Therefore, the location of the signifi-

6.2.1.2. Montgomery modular multiplication. Montgomery modular multiplication implements fast modular multiplication by converting 6

M. Qin et al.

Integration, the VLSI Journal xxx (xxxx) xxx

always remains the constant 20′h00001 regardless of any inputs. Therefore, we verify that there is no timing channel in the adder design. property qaddr_c: @(posedge clock) ct = = 20′ h00001; endproperty assert property (qaddr_c)

6.2.2.2. Multiplier. The 32-bit multiplier (a top module qadd, two submodule qtwosComp) takes two numbers (a and b) and returns the product c. We formalize the property qmult_c and verify the timing invariant property of the product c as we do for the adder. The proof result shows that the time label ct always remains the constant 20′h00001 regardless of any inputs. Therefore, we conclude that there is no timing channel in this design.

Fig. 5. Montgomery multiplication.

property qmult_c: @(posedge clock) ct = = 20′ h00001; endproperty assert property (qmult_c)

all calculations into the Montgomery field [15]. Generally, the timing channel of Montgomery multiplication comes from the additional reduction if the intermediate result is higher than the modulus, as shown in the bottom dotted box of Fig. 5.

6.2.2.3. Divider. The 32-bit divider (module qdiv) takes two numbers dividend and divisor and returns the quotient quotient_out. When the quotient_out is available, the signal complete is set for indicating the finish of the division. Therefore, the finish time for division is identical to the time for setting the complete signal. We assess the execution time of the module qdiv by initializing all input time labels as 20′h0 and proving that the time label of the complete is a constant. We formalize the property qdiv_complete, where the time label completet of the output complete remains the constant 20′h0002f when the complete signal is raised. The proof result shows that the time label completet always remains the constant 20′h0002f regardless of any inputs. So we make sure that the divider contains no timing channel.

Property Montgomery-ready: @(posedge clk) disable iff(!start) $rose(ready) |=> readyt = = 20′ h00041; endproperty assert property (Montgomery-ready)

In this experiment, we assess the timing invariant property of a Montgomery multiplication core from opencores.org. We first observe the time label value of the finish signal ready by initializing all input time labels as 20′h0. We generate the time label tracking logic for this design and formalize the property Montgomery-ready, in which the time value of the time label readyt remains the constant 20′h00041 when the ready signal is raised. The proof result shows that the time value of the time label readyt always remains the constant 20′h00041 regardless of any input values. Therefore, we conclude that there is no timing channel in this Montgomery multiplication design. When we check the design, we find that the conditional branch is balanced, and the execution time for both branches is the same. In addition, Montgomery multiplication performs the same round state machine iterations (the round number equals the operated word length as Fig. 5 shown) to implement modular multiplication in the Montgomery field, eliminating the same kind of timing differences as basic RSA modular multiplication.

property qdiv_complete: @(posedge clk) disable iff(start) $rose(complete) |- > completet = = 20′ h0002f; endproperty assert property (qdiv_complete)

In comparison, we insert a conditional branch into the original divider. The branch assesses the value of the divisor. If the divisor equals 1, the quotient_out will output the dividend directly within only one clock cycle. Otherwise this modified divider performs the same operations as the original divider. We model the modified divider design by the same timing invariant property and verify it as we did before. However, the proof fails. It shows that the time label completet equals 20′h00001 or 20′h0002f when the complete is raised. We conclude that the inserted conditional branch brings a fast path into the design, resulting in a timing channel.

6.2.2. Arithmetic units In this section, we will use some common arithmetic units to test our solution. These arithmetic units come from a fixed point math libraries from opencores.org [16], including a 32-bit adder (module qadd), a 32bit divider (module qdiv) and a 32-bit multiplier (module qmult). As claimed by the designer, these cores are supposed to run in constant time.

6.2.3. Cryptographic functions 6.2.3.1. Basic RSA implementation. RSA is a well-known asymmetric cryptographic algorithm, and modular exponentiation is the most important operation in RSA. Generally, the timing channel always comes from the conditional branch in modular exponentiation implementation. In this experiment, we employ a 32-bit RSA core from trust-hub.org [13], which performs square-and-multiply algorithm as shown in Fig. 6. The modular exponentiation is calculated by shifting each key bit from right to left repeatedly. If the key bit is 1, it performs a modular multiplication; otherwise, it performs a simple assignment. However, the

6.2.2.1. Adder. The 32-bit adder (module qadd) takes two inputs (a and b), and returns the sum c. To verify this adder, we initialize the time labels of a and b as 20′h0 and prove that the execution time of addition is constant. Therefore, we formalize the property qaddr_c, which models that the time label ct of the output c remains the constant 20′h00001. After that, we use Questa Formal to verify the timing invariant property of this design by proving that the generated tracking logic is consistent with the property qaddr_c. The proof result shows that the time label ct 7

M. Qin et al.

Integration, the VLSI Journal xxx (xxxx) xxx

6.2.3.3. SHA-1. Secure Hash Algorithm 1 (SHA-1) implements a series of operations such as appending padding bit, appending length, initializing buffer and performing compression functions with 80 iterations (4 rounds, each containing 20 iterations) to produce a 160-bit message digest. We employ one SHA-1 hardware implementation from opencores.org [17] to demonstrate its timing channel security. The SHA-1 design is made up of a balanced state-machine with 80 states, where the state transition depends on one internal counter having nothing to do with sensitive information and each state costs only one clock cycle. Considering the plain-text goes through all the states, the SHA-1 is expected to be free of timing channels. We generate the time label tracking logic for this design and formalize the property SHA-1-text-out, in which the time label text-outt for the hash function output text-out remains the estimated execution time 20′h0005d. Then we formally prove this property with Questa Formal. It shows that the proof for the property SHA-1-text-out passes. Thus, we verify that the SHA-1 implementation contains no timing channel. Property SHA-1-text-out: @(posedge clk_i) disable iff(rst_i) $fell(busy) |=> text-outt = = 20′ h0005d; endproperty assert property (SHA-1-text-out)

Fig. 6. The Architecture of the Square-and-Multiply algorithm.

execution time of performing modular multiplication is longer than that of performing a simple assignment. There is a correlation between the encryption/decryption time and the key bits. In addition, the plaintext contributes to timing variation of modular multiplication as Section 6.2.1 shown, which also leads to modular exponentiation timing variation. In order to identify the timing channel, we first assess the execution time of this design by Simulink through initializing all input time labels as 20′h0. Then, we generate the time label tracking logic for this design and formalize the property RSA-ready that the time label readyt always remains the estimated value 20′h0036B when the signal ready is raised. However, the proof fails. The proof result shows that the time value of the time label readyt changes with different plain-texts or keys. The RSA implementation contains timing channels.

6.2.3.4. XTEA. Extended Tiny Encryption Algorithm (XTEA) is a lightweight cryptographic algorithm dedicated to resource-constrained systems with 8 bytes blocksize and 16 bytes Keysize (128-bit). It generally requires six or more iteration rounds to achieve good diffusion property theoretically. The encryption time scales linearly with the number of iteration rounds. We employ a hardware XTEA core shown in Fig. 7 from Ref. [18], which is also made up of a balanced state-machine with 18 states for encryption. State transition depends on the state register, which is irrelevant to the secret key. And each state only costs one clock cycle. Considering the state transitions do not change with any plaintext or key, the XTEA design should be free of timing channels. To facilitate verifying this core, we insert two status registers complete_0 and complete_1 to indicate the finish of the cipher-text output v0 and v1, respectively. We generate a time label tracking logic for this modified XTEA core, and check the execution time to perform 64 rounds encryption. Thus, we initialize all input time labels as 20′h0 and prove two properties XTEA-v0 and XTEA-v1, where the time labels v0t and v1t for cipher-text output v0 and v1 equal 20′h00103 and 20′h00105, respectively if both complete_0 and complete_1 signals are set to 1. The results show that the proofs for both properties pass regardless of the values of the plain-text or key. Therefore, we verify that the XTEA core is free of timing channels.

Property RSA-ready: @(posedge clock) disable iff(reset) $rose(ready) |=> readyt = = 20′ h0036B; endproperty assert property (RSA-ready)

6.2.3.2. AES. Theoretically, the AES timing channel is caused by the unbalanced conditional modular reduction in the xtime primitive of MixColoumns operation. In this experiment, we use a 128-bit AES core AES-T100 from trust-hub.org [13]. In order to check its timing channel security, we first assess the execution time of this AES design by initializing all input time labels as 20′h0. Then, we generate the time label tracking logic for this design and formalize the property AES-textout that the time label for the signal text-out remains the estimated value 20′h00015. After that, we can formally prove that the generated tracking logic follows this property. The proof result shows that the time label text-outt always remains the constant 20′h00015 regardless of any inputs. Therefore, we verify that there is no timing channel in this AES core. Furthermore, when we check the xtime primitive in the AES core, it is balanced to the constant execution time.

Property XTEA-v0: @(posedge clk) disable iff(rst) $rose(complete_0) |=> ##255 (v0t = = 20′ h00103); endproperty assert property (XTEA-v0) Property XTEA-v1: @(posedge clk) disable iff(rst) $rose(complete_1) |=> ##257 (v1t = = 20′ h00105); endproperty assert property (XTEA-v1)

Property AES-text-out: @(posedge clk) text-outt = = 20′ h00015; endproperty assert property (AES-text-out)

6.2.4. Cache The cache is used to speed up data access between processor registers and the main storage. It generally stores the data accessed recently and frequently. If the data read hits the cache, the CPU will retrieve the 8

M. Qin et al.

Integration, the VLSI Journal xxx (xxxx) xxx

ing that the run-times for cache miss and cache hit are not the same. Therefore, we conclude that there is a timing channel in this cache design. 6.2.5. Summary and discussion Table 5 summarizes the experimental results (✓ indicates that the design contains timing channel based on our detection method, × indicates that the design is free of timing channel). Through formally verifying the timing invariant property of two different modular multiplication implementations (basic RSA modular multiplication and Montgomery modular multiplication), we demonstrate that our solution is capable of identifying hardware timing channels from different algorithm implementations for modular multiplication. Then, through formal proof of the timing invariant property for four arithmetic units (an adder, a multiplier, a divider and a divider with a fast path), we prove that the three arithmetic units from the fixed point math library are free of timing channel, but a fast path can introduce a timing channel to the modified divider. Moreover, through verifying four commonly used hardware cryptographic functions, we prove that three cryptographic hardware implementations (AES, SHA1, and XTEA) are free of timing channel, but unbalanced conditional branches make the basic RSA implementation suffer from timing channel. Finally, we prove that cache hit/miss leads to a timing channel. These results demonstrate that our method can verify timing invariant property of hardware design and identify hardware timing channels effectively.

Fig. 7. One round of the XTEA architecture.

Fig. 8. The data cache architecture.

data from the cache directly. If the data read misses the cache, the CPU has to access the main storage and retrieve the data. The latency for accessing cache is much lower than that for accessing the main memory [19]. Therefore, cache hit/miss will lead to specified timing characteristics [2]. By measuring the time for cache hit/miss and extracting the cache access pattern of the process executing secret information, the attackers can deduce the secret information without physical access to the hardware. We use a data cache (D_Cache) implementation shown in Fig. 8 to illustrate the detection of the cache timing channel. CPU first launches data read request by setting data read address signal (cpu_addr), read signal (cpu_rd_data) and data request signal (data_req). If the data requested is in the cache, the cache sets the signal hit high to indicate cache hit. Otherwise, the signal hit is set low to indicate cache miss unless the data fetched from the main storage is in the cache.

7. Related work There are lots of research works that detect hardware timing channels. These researches employ different approaches to discover and analyze timing channel characteristics. And most of these techniques can be classified into three categories: (i) Statistical based analysis; (ii) Testbased analysis; (iii) Formal verification based analysis. Statistical based analysis identifies hardware timing channels by sampling the execution time of the hardware design and performing statistical analysis. Kocher examines the timing channel issues of DiffieHellman, RSA, DSS cryptographic systems by calculating the mean and the variance of the execution time[2]. Mao et al. employ information theoretic metrics to quantify the amount of information leakage across a variety of cryptographic hardware by sampling the execution time [5]. Reparaz et al. employ statistical tests such as t-test and nonparametric tests to check whether the run-times are statistically different [4]. Pasareanu et al. combine symbolic execution with model counting to explore execution paths and quantify information leakage from the probabilities of execution paths [20]. However, these detection techniques will not guarantee a solid qualitative assessment on the timing variation, but only provides statistical evidence of timing leakage. Test-based analysis identifies timing channels by fuzzing, concolic test and simulation. He et al. employ Coverage-Guided Greybox Fuzzing to detect two-safety property violations, including constant-time property [6]. Brennan et al. perform symbolic execution based analysis to eliminate infeasible control flow paths to accelerate side-channel detection [21]. GLIFT employs a gate-level hardware IFT solution to capture all information flow, but it can only identify the timing flow when function flow does not exist [9]. SecVerilog enables designers to precisely reason about timing information flow through a security type system with expressive type annotations at compile time. Its operational semantics correspond directly to hardware simulation at RTL abstraction, and these RTL simulations accurately reflect the behavior of synthesized hardware [7]. RTLIFT defines label propagation rules for RTL expressions and identifies timing flows in the design phase, which can detect higher-level dependencies (e.g., variable correlation due to reconvergent fanout) between design signals better than GLIFT framework [10]. However, these methods suffer from the problem of

property CacheMiss; @(posedge clock) disable iff(rst) $rose(hit) |- > hitt = = 20′ h0000B; endproperty assert property (CacheMiss); property CacheHit; @(posedge clock) disable iff(rst) $rose(hit) |- > hitt = = 20′ h0000C; endproperty assert property (CacheHit);

Therefore, we can assess the timing invariant property of this design by proving that the execution time of the cache hit equals the execution time of the cache miss. In addition, we improve the cache implementation so that it can handle one cache miss and one cache hit in order continuously. We generate the time label tracking logic for the cache design and initializing all input time labels as 20′h0 to assess the execution time of this design. Meanwhile, we formalize two properties CacheMiss and CacheHit for proving that the execution time for cache miss and cache hit are 20′h0000B and 20′h00001, respectively. Because the cache miss and hit execute continuously, the total execution time for both operations is 20′h0000C. After that, we prove these two properties with Questa Formal. The proof results show that these two properties pass, indicat9

M. Qin et al.

Integration, the VLSI Journal xxx (xxxx) xxx

Table 5 Test design, properties and proof results. #

Design

Modules

Property

Result

1

Basic RSA Modular Multiplication Montgomery modular multiplication

modmult.vhd

The time label for the output ready remains a constant.

✓

ModMultlter_SM.vhd ModularMultiplierIterative.vhd MontMult4inMux.vhd qadd.v qtwosComp.v qmult.v qdiv.v qdiv-modifed.v modmult.vhd rsacypher.vhd round.v table.v aes_128.v sha1.v round_f.vhd key_schedule.vhd xtea.vhd D_Cache.v

The time label for the output ready remains a constant.

×

The time label for the output c remains a constant. The time label for the output c remains a constant. The time label for the output complete remains a constant. The time label for the output complete remains a constant. The time label for the output ready remains a constant. The time label for the output text-out remains a constant. The time label for the output text-out remains a constant. The time labels for both output v0 and v1 are constant, respectively.

× × ×

2

3 4 5 6 7 8 9 10

Adder Multiplier Divider Divider with fast path RSA AES SHA-1 XTEA

11

Cache

The time label for cache hit remains a constant while the time label for cache miss remains the other constant.

✓ ✓

× × × ✓

Acknowledgments

complexity growing exponentially or path explosion due to exhaustive fuzzing or symbolic execution. While random test tends to reduce the detection accuracy because of limited test coverage, the limited number of simulations cannot guarantee the design is free of timing channels in case the simulations do not cover the specified path from input to output (e.g., the execution time for the shortest path is different from others). Formal verification techniques generally require constructing a security model (especially information flow model) for hardware design so that it can perform model checking and deductive verification to identify timing channels. Cassion enforces information flow control with additional security static type system [22]. Jin and Bidmeshki et al. propose a data secrecy protection framework to enforce information flow security verification by formalizing HDL codes to Coq formal languages and perform formal proof of the Coq theorems [23,24]. These approaches always construct a security system to enforce timing information flow security. It always requires designers to learn a new formal language to rewrite the hardware design for building the new security system, which is laborious to use in practical. And some tracking systems have to downgrade the sensitivity level of security label allowing for design function correctness and efficiency, which always renders timing information flow analysis conservative. Ardeshiricham et al. model hardware timing flow based on finite state machine by evaluating timing variations and provide the tool Clepsydra for automatically generating circuit for tracking timing flows and functional flows within hardware designs in two distinct channels[11]. VeriSketch extends CEGIS [25] to design secure hardware from high-level specifications and verify hardware timing invariant property through HDL codes [26]. However, these methods track both functional flows and timing flows using the same set of labels and propagation rules, which is challenging to isolate timing flows from functional flows independently. And it is difficult for all these methods to understand and reason about the essence of timing flow independent of function flow as we do in this work.

This work was supported in part by the Natural Science Foundation of China, under Grant 61672433, the Natural Science Foundation of Shaanxi Province, under Grant 2019JM-244 and the National Crypto Development Foundation, under Grant MMJJ20170210. References [1] M. Lipp, M. Schwarz, D. Gruss, T. Prescher, W. Haas, A. Fogh, J. Horn, S. Mangard, P. Kocher, D. Genkin, Y. Yarom, M. Hamburg Meltdown, Reading kernel memory from user space, in: 27th USENIX Security Symposium, USENIX Security18, Baltimore, MD, USA, Aug 2018. [2] C. Paul, Kocher. Timing attacks on implementations of diffie-hellman, rsa, dss, and other systems, in: Koblitz Neal (Ed.), Advances in Cryptology CRYPTO 96, Springer Berlin Heidelberg, Berlin, Heidelberg, 1996, pp. 104–113. [3] Kocher Paul, Jann Horn, Fogh Anders, Daniel Genkin, Daniel Gruss, Werner Haas, Mike Hamburg, Moritz Lipp, Stefan Mangard, Thomas Prescher, Michael Schwarz, Yuval Yarom, Spectre Attacks: Exploiting Speculative Execution, 2019. arXiv:1801.01203. [4] Oscar Reparaz, Josep Balasch, Ingrid Verbauwhede, Dude, is my code constant time? in: Design, Automation & Test in Europe Conference & Exhibition (DATE), 2017, IEEE, 2017, pp. 1697–1702. [5] B. Mao, W. Hu, A. Althoff, J. Matai, Y. Tai, D. Mu, T. Sherwood, R. Kastner, Quantitative analysis of timing channel security in cryptographic hardware design, IEEE Trans. Comput. Aided Des. Integrated Circ. Syst. 37 (9) (Sep. 2018) 1719–1732. [6] Shaobo He, Michael Emmi, F. Gabriela, Ciocarlie. Ct-Fuzz: Fuzzing for Timing Leaks, 2019. CoRR, abs/1904.07280. [7] Danfeng Zhang, Yao Wang, G. Edward Suh, Andrew C. Myers, A hardware design language for timing-sensitive information-flow security, SIGPLAN Not 50 (4) (March 2015) 503–516. [8] Wei Hu, Jason Oberg, Irturk Ali, Mohit Tiwari, Timothy Sherwood, Dejun Mu, Kastner Ryan, Theoretical fundamentals of gate level information flow tracking, IEEE Trans. Comput. Aided Des. Integrated Circ. Syst. 30 (8) (Jun 2011) 1128–1140. [9] J. Oberg, S. Meiklejohn, T. Sherwood, R. Kastner, Leveraging gate-level properties to identify hardware timing channels, IEEE Trans. Comput. Aided Des. Integrated Circ. Syst. 33 (9) (Sep. 2014) 1288–1301. [10] Armaiti Ardeshiricham, Wei Hu, Joshua Marxen, Kastner Ryan, Register transfer level information flow tracking for provably secure hardware design, in: Design, Automation & Test in Europe Conference & Exhibition, DATE17, IEEE, Lausanne, Switzerland, Mar 2017, pp. 1695–1700. [11] Armaiti Ardeshiricham, Wei Hu, Kastner Ryan, Clepsydra: modeling timing flows in hardware designs, in: IEEE/ACM International Conference on Computer-Aided Design, ICCAD17, IEEE, Irvine, CA, USA, Dec 2017, pp. 147–154. [12] Wei Hu, Jason Oberg, Irturk Ali, Mohit Tiwari, Timothy Sherwood, Dejun Mu, Kastner Ryan, On the complexity of generating gate level information flow tracking logic, IEEE Trans. Inf. Forensics Secur. 7 (3) (2012) 1067–1080. [13] B. Shakya, T. He, H. Salmani, D. Forte, S. Bhunia, M. Tehranipoor, Benchmarking of hardware trojans and maliciously affected circuits, J. Hardware Syst. Secur. 1 (1) (Apr 2017) 85–102. [14] K. Gajewski, Montgomery Modular Multiplier and Exponentiator. https:// opencores.org/projects/mod_mult_exp, Aug 23 2019. [15] Nitha Thampi, Meenu Elizabath Jose, Montgomery multiplier for faster cryptosystems, Procedia Technol. 25 (2016) 392–398 1st Global Colloquium on Recent Advancements and Effectual Researches in Engineering, Science and Technology - RAEREST 2016 on April 22nd & 23rd April 2016.

8. Conclusion In this work, we propose a new method for modeling timing variations of hardware design and propose a solution to detect timing channels by formal verification of the timing invariant property of hardware design. The experiments prove the timing invariant properties across various hardware architectures by using this formal method and the experimental results show that our solution can identify hardware timing channels effectively and soundly.

10

M. Qin et al.

Integration, the VLSI Journal xxx (xxxx) xxx [22] Xun Li, Mohit Tiwari, Jason K. Oberg, Vineeth Kashyap, Frederic T. Chong, Timothy Sherwood, and Ben Hardekopf. Caisson: a hardware description language for secure information flow, ACM Sigplan Not. 46 (6) (2011) 109–120. [23] Yier Jin, Xiaolong Guo, Raj gautam Dutta, Bidmeshki Mohammad-Mahdi, Makris Yiorgos, Data secrecy protection through information flow tracking in proof-carrying hardware ippart i: framework fundamentals, IEEE Trans. Inf. Forensics Secur. 12 (10) (May 2017) 2416–2429. [24] M. Bidmeshki, X. Guo, R.G. Dutta, Y. Jin, Y. Makris, Data secrecy protection through information flow tracking in proof-carrying hardware ippart ii: framework automation, IEEE Trans. Inf. Forensics Secur. 12 (10) (Oct 2017) 2430–2443. [25] Armando Solar-Lezama, Program sketching, Int. J. Software Tool. Technol. Tran. 15 (5) (Oct 2013) 475–495. [26] Armaiti Ardeshiricham, Yoshiki Takashima, Sicun Gao, Kastner Ryan, Verisketch: Synthesizing Secure Hardware Designs with Timing-Sensitive Information Flow Properties, 2019.

[16] S. Skalicky, fixed_point_arithmetic_parameterized, Jan 2018, http://www. opencores.org/project,fixed_point_arithmetic_parameterized. [17] Marsgod. Sha-Core. https://opencores.org/projects/sha_core, Mar 2009. [18] Sam Skalicky. Xteacore. https://opencores.org/projects/xteacore, Jun 23 2015. [19] Shuai Wang, Pei Wang, Xiao Liu, Danfeng Zhang, Dinghao Wu, Cached: identifying cache-based timing channels in production software, in: Proceedings of the 26th USENIX Conference on Security Symposium, SEC17, USENIX Association, Berkeley, CA, USA, 2017, pp. 235–252. [20] Corina S. Pasareanu, Quoc-Sang Phan, Pasquale Malacaria, Multi-run side-channel analysis using symbolic execution and max-smt, in: 2016 IEEE 29th Computer Security Foundations Symposium (CSF), IEEE, 2016, pp. 387–400. [21] Tegan Brennan, Seemanta Saha, Tevfik Bultan, Corina S. Psreanu, Symbolic path cost analysis for side-channel detection, in: Proceedings of the 27th ACM SIGSOFT International Symposium on Software Testing and Analysis, ACM, 2018, pp. 27–37.

11