Journal of Computer Security 27 (2019) 137–163
DOI 10.3233/JCS-181136
IOS Press
137
Verifying constant-time implementations by
abstract interpretation
Sandrine Blazy ∗ , David Pichardie and Alix Trieu
Univ Rennes, Inria, CNRS, IRISA, France
Abstract. Constant-time programming is an established discipline to secure programs against timing attackers. Several realworld secure C libraries such as NaCl, mbedTLS, or Open Quantum Safe, follow this discipline. We propose an advanced static
analysis, based on state-of-the-art techniques from abstract interpretation, to report time leakage during programming. To that
purpose, we analyze source C programs and use full context-sensitive and arithmetic-aware alias analyses to track the tainted
flows.
We give semantic evidence of the correctness of our approach on a core language. We also present a prototype implementation
for C programs that is based on the CompCert compiler toolchain and its companion Verasco static analyzer. We present
verification results on various real-world constant-time programs and report on a successful verification of a challenging SHA256 implementation that was out of scope of previous tool-assisted approaches.
Keywords: Abstract interpretation, constant-time programming, timing attacks, verification of C implementations
1. Introduction
To protect their implementations, cryptographers follow a very strict programming discipline called
constant-time programming. They avoid branchings controlled by secret data as an attacker could use
timing attacks, which are a broad class of side-channel attacks that measure different execution times of
a program in order to infer some of its secret values [1,17,27,32]. They also avoid memory loads and
stores indexed by secret data because of cache-timing attacks. Several real-world secure C libraries such
as NaCl [12], mbedTLS [36], or Open Quantum Safe [40], follow this programming discipline.
Despite the name, constant-time programming does not ensure that the program runs in constanttime, only that its running time does not depend on secrets. For instance, two different branches may
have different execution times, but it is not harmful if the branching cannot leak information on secrets.
Balancing the running time of branches by adding no-op instructions may seem an attractive solution,
but they may be removed by compilers, and it is still open to other attacks as illustrated by [50].
The constant-time programming discipline requires the transformation of source programs. These
transformations may be tricky and error-prone, mainly because they involve low-level features of C and
non-standard operations (e.g., bit-level manipulations). We argue that programmers need tool assistance
to use this programming discipline. First, they need feedback at the source level during programming,
in order to verify that their implementation is constant time and also to understand why a given implementation is not constant time as expected. Second, they need to trust that their compiler will not break
the security of source programs when translating the guarantees obtained at the source level. Indeed,
* Corresponding
author. E-mail: sandrine.blazy@irisa.fr.
0926-227X/19/$35.00 © 2019 – IOS Press and the authors. All rights reserved
138
S. Blazy et al. / Verifying constant-time implementations by abstract interpretation
compiler optimizations could interfere with the previous constant-time transformations performed by
the programmer. In this paper, we choose to implement a static analysis at source level to simplify error
reporting, but couple the static analyzer to the highly trustworthy CompCert compiler [35]. This strategic
design choice allows us to take advantage of static analysis techniques that would be hard to apply at the
lowest program representation levels.
Static analysis is frequently used for identifying security vulnerabilities in software, for instance to detect security violations pertaining to information flow [23,30,44]. In this paper, we propose an advanced
static analysis, based on state-of-the-art techniques from abstract interpretation [19] (mainly fixpoint
iterations operating over source programs, use of widening operators, computations performed by several abstract domains including a memory abstract domain handling pointer arithmetic), to report time
leakage during programming.
Data originating from a statement where information may leak is tainted with the lowest security
level. Our static analysis uses two security levels, that we call secret (high level) and public (low level);
it analyzes source C programs and uses full context-sensitive (i.e., the static analysis distinguishes the
different invocations of a same function) and arithmetic-aware alias analyses (i.e., the cells of an array
are individually analyzed, even if they are accessed using pointer dereferencing and pointer arithmetic)
to track the tainted flows.
We follow the abstract interpretation methodology: we design an abstract interpreter that executes over
security properties instead of concrete values, and use approximation of program executions to perform
fixpoint computations. We hence leverage the inference capabilities of advanced abstract interpretation
techniques as relational numeric abstractions [37], abstract domain collaborations [28], arithmetic-aware
alias analysis [14,38], to build a very precise taint analysis on C programs. As a consequence, even if a
program uses the same memory block to store both secret and public values during computations, our
analysis should be able to track it, without generating too many spurious false alarms. This programming
pattern appears in real-world implementations, such as the SHA-256 implementation in NaCl that we
are able to analyze.
In this paper, we make the following contributions:
• We define a new methodology for verifying constant-time security of C programs. Our static analysis is fully automatic and sound by construction.
• We instrument our approach in the Verasco static analyzer [31]. Verasco is a formally-verified static
analyzer, that is connected to the formally-verified CompCert C compiler. We thus benefit from the
CompCert correctness theorem, stating roughly that a compiled program behaves as prescribed by
the semantics of its source program.
• We report our results obtained from a benchmark of representative cryptographic programs that are
known to be constant time. Thanks to the precision of our static analyzer, we are able to analyze
programs that are out of reach of state-of-the-art tools.
This paper is organized as follows. First, Section 2 presents the Verasco static analyzer. Then, Section 3 explains our methodology and details our abstract interpreter. Section 4 describes the experimental
evaluation of our static analyzer. Related work is described in Section 5, followed by conclusions.
2. The Verasco abstract interpreter
Verasco is a static analyzer based on abstract interpretation that is formally verified in Coq [31]. Its
proof of correctness ensures the absence of runtime errors (such as out-of-bound array accesses, null
S. Blazy et al. / Verifying constant-time implementations by abstract interpretation
139
pointer dereferences, and arithmetic exceptions) in the analyzed C programs. Verasco relies on several
abstract domains, including a memory domain that finely tracks properties related to memory contents,
taking into account type conversions and pointer arithmetic [14].
Verasco is connected to the CompCert formally-verified C compiler, that is also formally verified in
Coq [35]. Its correctness theorem is a semantics preservation theorem; it states that the compilation
does not introduce bugs in compiled programs. More precisely, Verasco operates over C#minor a C-like
language that is the second intermediate language in the CompCert compilation pipeline.
Verasco raises an alarm as soon as it detects a potential runtime error. Its correctness theorem states
that if Verasco returns no alarm, then the analyzed program is safe (i.e., none of its observable behaviors
is an undefined behavior, according to the C#minor semantics). The design of Verasco is inspired by
Astrée [13], a milestone analyzer that was able to successfully analyze realistic safety-critical software
systems for aviation and space flights. Verasco follows a similar modular architecture as Astrée, that is
shown in Fig. 1.
First, at the bottom of the figure, a large hub of numerical abstract domains is provided to infer numerical invariants on programs. These properties can be relational as for example j + 1 i j + 2 in
a loop (with Octagons or Polyhedra abstract domains). All these domains finely analyze the behavior of
machine integers and floating-points (with potential overflows) while unsound analyzers would assume
ideal arithmetic. They are connected all-together via communication channels that allow each domain
to improve its own precision via specific queries to other domains. As a consequence, Verasco is able to
Fig. 1. Architecture of the Verasco static analyzer.
140
S. Blazy et al. / Verifying constant-time implementations by abstract interpretation
infer subtle numerical invariants that require complex reasoning about linear arithmetic, congruence and
symbolic equalities.
Second, on top of these numerical abstractions sits an abstract memory functor [14] that tracks finegrained aliases and interacts with the numerical domains. This functor can choose to represent every
cell of the same memory block with a single property, or to finely track each specific property of every
position in the block. Contrary to many other alias analyses, this approach allows us to reason on local
and global variables with the same level of precision, even when the memory addresses are manipulated
by the programmer. Some unavoidable approximations are performed when the target of a memory
dereference corresponds to several possible targets, but Verasco makes the impact of such imprecision as
limited as possible. Because of ubiquitous pointer arithmetic in C programs (even simple array accesses
are represented via pointer arithmetic in C semantics), the functor needs to ask advanced symbolic
numerical queries to the abstract numerical domain below it. In return, its role is to hide from them the
load and store operations, and only communicate via symbolic numerical variables.
Third, the last piece of the analyzer is an advanced abstract interpreter that builds a fixpoint for the
analysis result. This task is a bit more complex than in standard dataflow analysis techniques that look
for the least solution of dataflow equation systems. In such settings, each equation is defined by means
of monotone operators in a well-chosen lattice without infinite ascending chains. By computing the
successive iterates of the transfer functions attached to each equation, starting from a bottom element,
the fixpoint computation always terminates on the least element of the lattice that satisfies all equations.
In contrast, the Verasco abstract interpreter relies on infinite lattices, where widening and narrowing
operators [19] are used for ensuring and accelerating the convergence. Smart iteration strategies are
crucial when using such accelerating operators because they directly impact the precision of the analysis
diagnosis. Verasco builds its strategy by following the structure of the program. On every program loop,
it builds a local fixpoint using accelerating techniques. At every function call, it makes a recursive call
of the abstract interpreter on the body of the callee. The callee may be resolved thanks to the state
abstraction functor in presence of function pointers. The recursive nature of the abstract interpreter
makes the analysis very precise because each function is independently analyzed as many times as there
are calling contexts that invoke it.
Furthermore, C#minor is classically structured in functions, statements, and expressions. Expressions
have no side effects; they include reading temporary variables (which do not reside in memory), taking
the address of a non-temporary variable, constants, arithmetic operations, and dereferencing addresses.
The arithmetic, logical, comparison, and conversion operators are roughly those of C, but without overloading: for example, distinct operators are provided for integer multiplication and floating-point multiplication. Likewise, there are no implicit casts: all conversions between numerical types are explicit.
Statements offer both structured control and goto with labels. C loops as well as break and continue statements are encoded as infinite loops with a multi-level exit n that jumps to the end of the
(n + 1)th enclosing block.
3. Verifying constant-time security
Our static analyzer operates over C#minor programs. In this paper, we use a simpler While toylanguage for clarity. It is defined in the first part of this section. Then, we detail our model for constanttime leakage, and explain the tainting semantics we have defined to track data dependencies in programs.
Last, we explain the main algorithm of our static analyzer, and detail its proof of correctness.
S. Blazy et al. / Verifying constant-time implementations by abstract interpretation
141
Fig. 2. Syntax of While programs.
3.1. The While language
Our While language is classically structured in statements and expressions, as shown in Fig. 2. Expressions include integer constants, array identifiers, variable identifiers, arithmetic operations and tests.
Statements include skip statements, stores ∗x ← y, loads x ← ∗y, assignments x ← y, sequences, if
and while statements.
Our While language is peculiar as it supports arrays in order to model memory aliasing. We will mainly
use a for array identifiers and x for variable identifiers. As an example, the program x ← a + 2; y ←
∗(x + 3) first starts by assigning the value a + 2 to variable x and then loads the value at offset 5 of the
array a into the variable y. In this example, x − 2 is an alias of a.
The semantics of While is defined in Fig. 3 using a small-step style for statements and a big-step style
for expressions, supporting the reasoning on non-terminating programs. Contrary to the C language, the
semantics is deterministic (and so is the semantics of C#minor).
A location, usually named l, is a pair of an array identifier and an offset represented by a positive
integer. A value v can either be a location or an integer. An environment σ is a pair (σX , σA ) composed
of a partial map from variables in set X of variable identifiers to values and a partial map from memory
locations A×N to values where A is a set of array identifiers and values V are either locations or integers.
We will write σ (x) to mean σX (x) and σ (l) for σA (l).
Given an environment σ , an expression e evaluates to a value v (written σ, e → v). A constant
is interpreted as an integer. An array identifier a evaluates to its location, it is equivalent to writing
a + 0. To evaluate a variable, its value is looked up in the environment σ and more precisely in its σX
component. Finally, to evaluate e1 ⊕ e2 , it is simply needed to evaluate e1 and e2 separately and combine
the resulting values by interpreting ⊕ into its corresponding operator ⊞, where ⊞ is the usual semantics
of the operator ⊕ ∈ {+, −, ×, /, =, <, >}. For example, e1 = e2 returns 0 if the test is false, and 1
otherwise.
The execution of a statement s results in an updated state with a new environment σ ′ and a new
statement to execute s ′ , written σ, s → σ ′ , s ′ . We write σ (e) to denote the value of expression e in
state σ (i.e., σ, e → σ (e)) and we use σ [l → v] to denote the environment that behaves the same
as σ except that it returns value v for location l. We consider all arrays to be of finite size and initially
declared, similarly to global variables in C. Thus, σ (x, n) and σ [(a, n) → v] may fail either because
a is not a valid array name or because it is an out-of-bound access. σ (l) = v means that l is a valid
location for σ , whereas σ (l) = ⊥ means the opposite. Similarly, σ [l → v] = σ ′ indicates the success
of the update. We assume a memory model similar to C’s except that variables have no addresses but
behave more like registers.
To execute a store ∗e1 ← e2 , it is first needed for e1 to evaluate into a location l and e2 to evaluate into a
value v; the environment is then updated so that location l maps to v. Similarly, to execute a load x ← ∗e,
the expression e must first evaluate into a location l. It is then needed to retrieve its corresponding value
v in the environment and update the environment so that x maps to v. To execute the assignment x ← e,
it is only needed to evaluate e and update the environment so that x maps to the resulting value. To
142
S. Blazy et al. / Verifying constant-time implementations by abstract interpretation
Fig. 3. Semantics of While programs.
execute a sequence p1 ; p2 , either p1 is a skip and p2 is the only statement left to execute, or we first need
to execute p1 , resulting in a new state σ ′ , p1′ . Then, p1′ ; p2 is left to execute in the new environment σ ′ .
Classically, in order to execute a conditional branching if e then p1 else p2 , it is needed to
evaluate e and execute accordingly the appropriate branch. Similarly, a loop while e do p stops if e
evaluates to false and continues otherwise.
As a remark, the evaluation of an expression can only be stuck in two ways, either because it is trying
to retrieve the value of an undefined variable (i.e., σ (x) fails when x is not defined in σ ), or because
S. Blazy et al. / Verifying constant-time implementations by abstract interpretation
143
v1 ⊞ v2 is not defined (e.g., because of a division by 0). Finally, the execution of statements can only be
stuck when the semantic rule evaluates an expression and gets stuck, or the corresponding result has the
wrong value type, or the result is a non-valid location. For instance, a branching statement cannot branch
on a location value, or σ (l) fails because it is an out-of-bound access or there is no associated value yet
in the environment.
The reflexive transitive closure of this small-step semantics represents the execution of a program.
When the program terminates (resp. diverges, e.g. when an infinite loop is executed), it is a finite (resp.
infinite) execution of steps. The execution of a program is safe iff either the program terminates (i.e., its
final semantic state is σ, skip, meaning that there is no more statement to execute) or the program
diverges. The execution of a program is stuck on σ, s when s differs from skip and no semantic
rule can be applied. A program is safe when all of its executions are safe. We write (σi , pi )i for the
execution σ0 , p0 → σ1 , p1 → . . . of program p0 with initial environment σ0 .
3.2. Constant-time security
In our model, we assume that branching statements and memory accesses may leak information
through their execution. We use a similar definition of constant-time security to the one given in [3]. We
define a leakage model L as a map from semantic states σ, p to sequences of observations L (σ, p)
with ε being the empty observation. Two executions are said to be indistinguishable when their observations are the same:
L σ0 , p0 · L σ1 , p1 · . . . = L σ0′ , p0′ · L σ1′ , p1′ · . . . .
Definition 1 (Constant-time leakage model). Our leakage model is such that the following equalities
hold.
(1)
(2)
(3)
(4)
(5)
(6)
L (σ, if e then p1 else p2 ) = σ (e)
L (σ, while e do p) = σ (e)
L (σ, ∗e1 ← e2 ) = σ (e1 )
L (σ, x ← ∗e) = σ (e)
L (σ, p1 ; p2 ) = L (σ, p1 )
L (σ, p) = ε otherwise
The first and second lines mean that the value of branching conditions is considered as leaked. The
third and fourth lines mean that the address of a store and load access is also considered as leaked. The
fifth line explains that a sequence leaks exactly what is leaked by the first part of the sequence; this is
due to the semantics of sequence which depends on the execution of the first statement. Finally, the other
statements produce a silent observation. Given this leakage model, the following lemma follows.
Lemma 1 (Same control-flow). If (σ1 , p1 ) → (σ2 , p2 ) and (σ1′ , p1′ ) → (σ2′ , p2′ ) such that p1 =
p1′ and L (σ1 , p1 ) = L (σ1′ , p1′ ) then p2 = p2′ .
Proof. By induction on (σ1 , p1 ) → (σ2 , p2 ):
• In the assign, store and load cases, p2 = p2′ = skip.
• In the skipseq case, there exists p such that p1 = p1′ = skip;p and thus p2 = p2′ = p.
144
S. Blazy et al. / Verifying constant-time implementations by abstract interpretation
• In the seq case, there exists q1 , q1′ , q1′′ and q2 such that p1 = p1′ = q1 ; q2 and (σ1 , q1 ) → (σ2 , q1′ )
and (σ1′ , q1 ) → (σ2′ , q1′′ ). In order to use the induction hypothesis to prove q1′ = q1′′ , we first
need to prove that L (σ1 , q1 ) = L (σ1′ , q1 ). This is true by definition since L (σ1 , p1 ) =
L (σ1 , q1 ; q2 ) = L (σ1 , q1 ) and also L (σ1′ , p1′ ) = L (σ1′ , q1 ; q2 ) = L (σ1′ , q1 ) and
L (σ1 , p1 ) = L (σ1′ , p1′ ). Thus, since p2 = q1′ ; q2 and p2′ = q1′′ ; q2 , we have finally p2 = p2′ .
• In the iftrue, iffalse, whiletrue and whilefalse cases, we simply use L (σ1 , p1 ) = L (σ1′ , p1′ ) to
justify that the same branch is taken.
Finally, the following theorem follows by induction.
Theorem 1. Two indistinguishable executions of a program necessarily have the same control flow.
Proof. Suppose we have two indistinguishable executions (σi , pi )i and (σi′ , pi′ )i such that p0 = p0′ .
We prove by induction on i that for all i, pi = pi′ .
• It’s true by hypothesis for i = 0.
• Suppose that pi = pi′ .
∗ If the execution is stuck for σi , pi , then necessarily it is because pi tries to write or read an
invalid location (i.e. the value is not a location but a constant or it is an out-of-bound location) or
it tries to branch on a non-boolean value. However, by definition of indistinguishability and the
leakage model, these values must be the same in both executions, thus the execution is also stuck
for σi′ , pi′ .
∗ Symmetrically, if the execution is stuck for σi′ , pi′ , it is also stuck for σi , pi .
′
′
′
′
∗ If σi , pi → σi+1 , pi+1 , then there exists σi+1
, pi+1
such that σi′ , pi′ → σi+1
, pi+1
or both
′
.
executions would have been stuck. By using the previous lemma, we prove that pi+1 = pi+1
Both executions have thus the same control flow.
Given a program, we assume that the attacker has access to the values of some of its inputs, which we
call the public input array variables, and does not have access of the other ones, which we call the secret
input array variables. Given a set X of array names, and two environments σ and σ ′ , we say that σ and
σ ′ are X-equivalent if σ and σ ′ both share the same public input values. Two executions (σi , pi )i and
(σi′ , pi′ )i are initially X-equivalent if σ0 and σ0′ are X-equivalent.
Definition 2 (Constant-time security). A program p is constant time if for any set Xi of public input
array variables, all of its initially Xi -equivalent executions are indistinguishable.
This definition means that a constant-time program is such that, any pair of its executions that only
differ on its secrets must leak the exact same information. This also gives a definition of constant-time
security for infinite execution.
3.3. Reducing security to safety
In order to prove that a program satisfy constant-time security as defined in Definition 2, we reduce
the problem to checking whether the program is safe in a different semantics. The issue is thus twofold,
we first need to prove that safety in this instrumented semantics implies constant-time security in the
standard semantics and second, we need to design an analyzer for this second semantics. This can also
S. Blazy et al. / Verifying constant-time implementations by abstract interpretation
145
Fig. 4. Methodology.
be obtained by modifying an analyzer for the standard semantics as illustrated by Fig. 4. Plain lines
indicate what we assume to already have, while dashed lines indicates what needs to be designed or
proved.
We introduce an intermediate tainting semantics for While programs in Fig. 5, and use the symbol
to distinguish its executions from those of the original semantics. The tainting semantics is an instrumentation of the While semantics that tracks dependencies related to secret values. In the tainted semantics,
a program gets stuck if branchings or memory accesses depend on secrets. We introduce taints, either
H (High) or L (Low) to respectively represent secret and public values and a union operator on taints
defined as follows: L ⊔ L = L and for all t, H ⊔ t = t ⊔ H = H. It is used to compute the taint of
a binary expression. In the instrumented semantics, we take into account taints in semantic values: the
semantic state σ becomes a tainted state σ , where locations are now mapped to pairs made of a value
and a taint.
Let us note that for a dereferencing expression ∗e to have a value, the taint associated to e must be L.
Indeed, we forbid memory read accesses that might leak secret values. This concerns dereferencing
expressions (loads) and assignment statements. Similarly, test conditions in branching statements must
also have a L taint.
The instrumented semantics strictly forbids more behaviors than the regular semantics (defined in
Fig. 3) as shown by the following lemma.
Lemma 2. Any execution (σi , pi )i of program p0 in the tainting semantics implies that (σi , pi )i is
an execution of p0 in the regular semantics where for all i, σi = E ◦ σi and E (a, b) = a for all pairs
(a, b) is an erasure function.
Proof. For all σ , σ ′ , p, p′ such that σ , p → σ ′ , p′ , we can easily prove by immediate induction that
σ, p → σ ′ , p′ where σ = E ◦ σ and σ ′ = E ◦ σ ′ .
Finally, by induction on the execution and using this lemma, the theorem is easily proven.
However, the converse is not necessarily true. For instance, suppose that variable x contains a secret
value. Then, ∗(a + x) ← 2 is not safe in the instrumented semantics because a + x has taint H, while it
is safe in the regular semantics provided that a + x corresponds to a valid location.
An immediate consequence of the lemma is that the instrumented semantics preserves the regular
behavior of programs, as stated by the following theorem.
146
S. Blazy et al. / Verifying constant-time implementations by abstract interpretation
Fig. 5. Tainting semantics for While programs.
Theorem 2. Any safe execution (σi , pi )i of program p0 in the tainting semantics implies that the
execution (σi , pi )i is also safe in the regular semantics.
As an immediate corollary, any safe program according to the tainting semantics is also safe according
to the regular semantics.
S. Blazy et al. / Verifying constant-time implementations by abstract interpretation
147
Proof. Let (σi , pi )i be a safe execution of p0 in the tainting semantics. As it is a safe execution, it
either diverges or terminates.
• If (σi , pi )i is diverging (i.e. infinite), then so is (σi , pi )i thanks to the previous lemma.
• If (σi , pi )i is terminating, then there exists some n such that pn = skip, therefore (σi , pi )in
is also terminating.
(σi , pi )i is a safe execution in the regular semantics.
Theorem 2 is useful to prove our main theorem relating our instrumented semantics and the constanttime property we want to verify on programs.
Theorem 3. Any safe program w.r.t. the tainting semantics is constant time.
Proof. Let p0 be a safe program with respect to the tainting semantics. Let Xi be a set of public variables
and let (σi , pi )i and (σi′ , pi′ )i be two safe executions of p0 that are initially Xi -equivalent.
We now need to prove that both executions are indistinguishable. Let σ0 be such that for all x ∈ Xi ,
/ Xi , n ∈ N, σ0 (x, n) = (σ0 (x, n), H).
n ∈ N, σ0 (x, n) = (σ0 (x, n), L) and also for all x ∈
By safety of program p0 according to the tainting semantics, there exists some states σ1 , σ2 , . . . such
that σ0 , p0 σ1 , p1 . . . is a safe execution. Let σn′ = E ◦ σn , we prove by strong induction on n
that σn′ = σn .
• It is clearly true for n = 0 by definition of σ0 .
• Suppose it is true for all k < n and let us prove it for n. By using theorem 2, we know that there
exists a safe execution σ0 , p0 → σ1′ , p1′ → · · · → σn′ , pn′ → . . .. Furthermore, the semantics
is deterministic and we know that σ0 , p0 → σ1 , p1 → . . .. Therefore, we have the following
series of equalities: σ1′ = σ1 , p1′ = p1 , . . . σn′ = σn , pn′ = pn .
Thus, for all k ∈ N, the state σk verifies σk = E ◦ σk . Similarly, we define σ0 ′ , σ1 ′ , . . . for the second
execution which also satisfies the same property by construction.
Finally, we need to prove that for all n ∈ N, L(σn , pn ) = L(σn′ , pn′ ).
First, we informally define the notation σn =L σn′ for all n ∈ N as σ n and σ ′n , as previously defined,
agree on the taints of both variables and locations, and if the taint is L, then they also agree on the value.
Formally, this means that for all r where r is either a location l or a variable x, either σ n (r) and σ ′n (r)
are undefined, or there exists a taint t such that σ n (r) = (σn (r), t) and σ ′n (r) = (σn′ (r), t) and if t = L,
then σn (r) = σn′ (r).
Second, we prove by induction on e that for all n and e that if σn =L σn′ , σn , e (v, t) and
σn′ , e (v ′ , t ′ ), then t = t ′ and if t = t ′ = L, then v = v ′ .
• This is trivially true if e = n or e = a.
• If e = x, then it is true by definition of σn =L σn′
• If e = e1 ⊕e2 , then we apply the induction hypotheses on σn , e1 (v1 , t1 ) and σn ′ , e1 (v1′ , t1′ )
and on σn , e2 (v2 , t2 ) and σn ′ , e2 (v2′ , t2′ ). Since t = t1 ⊔ t2 and t ′ = t1′ ⊔ t2′ and t1 = t1′
and t2 = t2′ , we have that t = t ′ . If t = t ′ = L, then t1 = t1′ = L and t2 = t2′ = L, thus
v = v1 ⊞ v2 = v1′ ⊞ v2′ = v ′ .
This lemma is thus proven.
′
Finally, for all n ∈ N, let us prove by induction on pn that if pn = pn′ and σn =L σn′ , then pn+1 = pn+1
′
and σn+1 =L σn+1
.
148
S. Blazy et al. / Verifying constant-time implementations by abstract interpretation
′
′
• If pn = skip;p′ , it is true because pn+1 = pn+1
= p′ , σn+1 = σn and also σn+1
= σn′ .
′
• If pn = p; p , it is true by induction hypothesis.
′
• If pn = if e . . . or pn = while e . . ., we have σn+1 = σn and σn+1
= σn′ . Furthermore, we
know that there exists some v such that σn , e (v, L) and similarly, there exists v ′ such that
σn ′ , e (v ′ , L) because of the safety in the tainting semantics. Since σn (e) = v, σn′ (e) = v ′ and
′
.
σn =L σn′ , we have v = v ′ by using the previous lemma and thus pn+1 = pn+1
′
• If pn = x ← ∗e, we can prove as previously that σn (e1 ) = σn (e1 ) = l. Furthermore, we have
′
′
pn+1 = pn+1
= skip. It is left to prove that σn+1 =L σn+1
. If σn (l) = (v, t) and σn ′ (l) = (v ′ , t ′ ),
′
′
′
′
′
= σn′ [x →
then t = t since σn =L σn . If t = t = L, then v = v and σn+1 = σn [x → v] and σn+1
′
′
′
′
v ], thus σn+1 =L σn+1 . Similarly, if t = t = H, then σn+1 =L σn+1 .
′
= skip. Furthermore, there exists v, v ′ , t, t ′ such that
• If pn = x ← e, we know that pn+1 = pn+1
′
′ ′
σn , e (v, t) and σn , e (v , t ). By using the previous lemma, we know that t = t ′ , and if
′
.
t = t ′ = L, then v = v ′ . Thus σn+1 = σn [x → v] =L σn′ [x → v ′ ] = σn+1
′
• If pn = ∗e1 ← e2 , we have pn+1 = pn+1 = skip. By using the same reasoning as previously,
we can prove that σn (e1 ) = σn′ (e1 ) = l. There exists v, v ′ , t, t ′ such that σn , e2 (v, t) and
′
[l → v ′ ]. By using the previous lemma,
σn ′ , e2 (v ′ , t ′ ) and thus σn+1 = σn [l → v] and σn+1
′
′
′
′
we know that t = t and if t = t = L, then v = v and σn+1 =L σn+1
. If t = t ′ = H, then
′
by definition.
σn+1 =L σn+1
Finally, by exploiting this lemma, an induction proves that for all n ∈ N, pn = pn′ and σn =L σn′ .
Furthermore, a direct consequence is that for all n ∈ N, L(σn , pn ) = L(σn′ , pn′ ) and thus both
executions are indistinguishable: the program is constant time.
3.4. Abstract interpreter
To prove that a program is safe according to the tainting semantics, we design a static analyzer based
on abstract interpretation. It computes a correct approximation of the execution of the analyzed program,
thus if the approximative execution is safe, then the actual execution must necessarily be safe.
Similarly to how we built a tainting semantics from a regular semantics, we explain how to modify an
abstract interpreter for the regular semantics into an abstract interpreter for the tainting semantics. First,
we suppose that the regular abstract interpreter provides a domain of abstract values V♯ that supports an
operator concretize♯ : V♯ → P (V) which takes an abstract value and returns the concrete values represented by the abstract value. We also suppose that the abstract interpreter provides M♯ , an abstraction
of concrete environments that maps locations and variables to values. We do not need nor want to know
exactly how M♯ is defined, as it might use relational definitions which are quite complex. We only need
to use M♯ to modify the abstract analyzer.
Finally, we suppose that the abstract analyzer provides the following abstract operators:
• eval♯ : M♯ → expr → V♯ takes an abstract environment, an expression and evaluates it in the
abstract environment and returns the corresponding abstract value;
• assign♯ : M♯ → X → expr → M♯ takes an abstract environment, a variable identifier, an expression and models an assignment to a variable;
• store♯ : M♯ → expr → expr → M♯ takes an abstract environment and two expression e1 and e2
and models ∗e1 ← e2 ;
• load♯ : M♯ → X → expr → M♯ takes an abstract environment, a variable identifier, an expression
and models a load x ← ∗e;
S. Blazy et al. / Verifying constant-time implementations by abstract interpretation
149
Fig. 6. Abstract taint lattice.
• assert♯ : M♯ → expr → M♯ takes an abstract environment, an expression and returns an abstract
environment where the expression is true. This is useful when analyzing a branching condition such
as x < 5, if we know beforehand that x ∈ [0, 42], we can restrict x to [0, 4] in the “then” branch,
and restrict it to [5, 42] in the “else” branch.
The abstract operators form an interface that is parameterized by V♯ and M♯ that we will name
AbMem(V♯ , M♯ ).
Now, in order for the analyzer to handle the tainting semantics, we need to introduce an abstraction
of taints T♯ = {L♯ , H♯ } which forms a lattice represented in Fig. 6. We will use L♯ to indicate a value
that has exactly taint L while H♯ indicates that a value may have taint L or H. In order to analyze the
following snippet, it is necessary to correctly approximate the taint of the value that will be assigned to
variable x after execution.
As it can either be L or H, we use the approximation H♯ . We could have used H♯ to indicate that a
variable or location can only have a H value, however constant-time security is not interested in knowing
that value has exactly H taint, but only in knowing that it may have a H taint.
Now, we explain how to modify the analyzer so that it can track abstract taints, this effectively forms
♯
♯
a functor from the previous interface AbMem(V♯ , M♯ ) to a new interface AbMem(V , M ) that can track
♯
♯
abstract taints where V = V♯ × T♯ and M = M♯ × ((X + L) → T♯ ).
♯
♯
We first start by defining taint : M → expr → T♯ + ⊥ which returns the abstract taint corresponding
to the evaluation of an expression. We use T (a, b) = b as tainting function, the companion of the erasure
function E .
♯
♯
♯
taint σ ♯ , n = L♯
taint σ ♯ , a = L♯
taint σ ♯ , x = T σ ♯ (x)
♯
♯
♯
taint σ ♯ , e1 ⊕ e2 = taint σ ♯ , e1 ⊔♯ taint σ ♯ , e2
We now define the following abstract operators (i.e., transfer functions).
♯
♯
• eval (σ ♯ , e) = (eval♯ (E (σ ♯ ), e), taint (σ ♯ , e))
♯
♯
• assign (σ ♯ , x, e) = (assign♯ (E (σ ♯ ), x, e), T (σ ♯ )[x → taint (σ ♯ , e)])
150
S. Blazy et al. / Verifying constant-time implementations by abstract interpretation
♯
• assert (σ ♯ , e) = (assert♯ (E (σ ♯ ), e), T (σ ♯ ))
♯
♯
• store (σ ♯ , e1 , e2 ) = (store♯ (E (σ ♯ ), e1 , e2 ), T (σ ♯ )[l → taint (σ ♯ , e2 )]l∈concretize♯ (eval♯ (E (σ ♯ ),e1 )) )
♯
• load (σ ♯ , x, e) = (load♯ (E (σ ♯ ), x, e), T (σ ♯ )[x → ♯l∈concretize♯ (eval♯ (E (σ ♯ ),e)) T (σ ♯ )(l)])
♯
♯
♯
The definitions of eval , assign and assert reuse the operators of AbMem(V♯ , M♯ ) and modify
♯
♯
slightly the tainting part. The definitions of store and load are more complex. In both cases, we
♯
need to use eval to deduce all possible locations affected by the memory accesses and suitably up♯
date the tainting parts. For store (σ ♯ , e1 , e2 ), all possible write locations given by the concretization of
♯
eval♯ (E (σ ♯ ), e1 ) are updated, as for load (σ ♯ , x, e), we approximate the taints from all possible read lo♯
♯
cations given by the concretization of eval♯ (E (σ ♯ ), e). This concludes the definition of AbMem(V , M ).
Finally, the abstract analysis ❏p❑(σ ♯ , τ ♯ ) of program p starting with tainted abstract environment
♯
σ is defined in Fig. 7. To analyze (p1 ; p2 ), first p1 is analyzed and then p2 is analyzed using the
environment given by the first analysis. Similarly, to analyze a statement (if e then p1 else p2 ),
p1 is analyzed assuming that e is true and p2 is analyzed assuming the opposite, ⊔♯ is then used to get
an over-approximation of both results.
The loop (while e do p) is the trickiest part to analyze, as the analysis cannot just analyze one
iteration of the loop body and then recursively analyze the loop again since this may never terminate. The
analysis thus tries to find a loop invariant. The standard method in abstract interpretation is to compute
a post-fixpoint of the function iter(e, p, σ ♯0 , ·) as defined in Fig. 7. It represents a loop invariant, the
final result is thus the invariant where the test condition does not hold anymore. In order to compute the
post-fixpoint, we use pfp(f ) which computes a post-fixpoint of monotone function f by successively
computing ⊥, f (⊥), f (f (⊥)), . . ., and forces convergence using a widening-narrowing operator on the
M♯ part. Computing ⊥, f (⊥), f (f (⊥)), . . . converges toward the least fixpoint (i.e., the most precise
invariant) when the process terminates according to Kleene theorem, but this process is not guaranteed
to end. The usual solution in abstract interpretation to ensure termination is to use a widening operator ∇
which overapproximates the limit of ⊥, f (⊥), f (f (⊥)), . . . by instead computing the sequence x0 = ⊥,
Fig. 7. Abstract execution of statements.
S. Blazy et al. / Verifying constant-time implementations by abstract interpretation
151
xn+1 = xn ∇f (xn ) which converges in a finite number of step. However, the resulting post-fixpoint may
be grossly imprecise, and a narrowing operator can be used in the same way to improve precision.
The taint part does not require convergence help because taints form a finite lattice.
3.5. Correctness of the abstract interpreter
In order to specify and prove the correctness of the analyzer, we follow the usual methodology in
abstract interpretation and define a collecting semantics, aiming at facilitating the proof. The semantics
still expresses the dynamic behavior of programs but takes a closer form to the analysis. It operates over
properties of concrete environments, thus bridging the gap between concrete environments and abstract
environments, which represent sets of concrete environments.
The collecting semantics aims at describing the resulting environments that can be reached given a
specific instruction and a set of environments. The collecting semantics of a program p with a set of
concrete environments is written ❏p❑().
Similarly to the abstract interpreter, we define Assign, Store, Load, Assert. They will respectively
♯
♯
♯
♯
serve as counterparts to assign , store , load and assert . We first start with Assign:
Assign(, x, e) = σ x → (v, t) |∃v ∈ V, t ∈ T, σ (e) = (v, t) ∧ σ ∈
Given a set of concrete environments , Assign(, x, e) computes the set of all possible reachable
environments from environments in after executing x ← e in the tainting semantics.
Next are Store and Load:
Store(, e1 , e2 ) = σ l → (v, t) |
∃l ∈ L, v ∈ V, t ∈ T, σ (e1 ) = (l, L) ∧ σ (e2 ) = (v, t) ∧ σ ∈
Load(, x, e) = σ x → (v, t) |∃l ∈ L, v ∈ V, t ∈ T, σ (e) = (l, L) ∧ σ (l) = (v, t) ∧ σ ∈
Given a set of concrete environments , Store(, e1 , e2 ) (resp. Load(, x, e)) computes the set of all
possible reachable environments from environments in after executing ∗e1 ← e2 (resp. x ← ∗e) in
the tainting semantics.
Assert removes the environments where e is not true:
Assert(, e) = σ ∈ |∃t, σ (e) = (true, t)
Finally, the collecting semantics is defined in Fig. 8. Looking at the rules in Fig. 7 and Fig. 8, one can
notice that the collecting semantics follows closely the shape of the abstract interpreter. The collecting
♯
semantics of assignment is defined using Assign, the counterpart of assign . Similarly to the abstract
interpreter, to evaluate conditional branchings, the first branch is evaluated assuming the condition is
true using Assert and the second branch is evaluated assuming the opposite. The results are then merged
to obtain all the possible states that can be reached.
We first start by proving that the collecting semantics is sound with regards to the tainting semantics.
Theorem 4. For any programs p and environment σ , σ , p ∗ σ ′ , skip =⇒ σ ′ ∈ ❏p❑({σ }).
152
S. Blazy et al. / Verifying constant-time implementations by abstract interpretation
Fig. 8. Definition of the collecting semantics ❏·❑(·).
Proof. This is a fairly standard proof in abstract interpretation. As the theorem statement does not directly fit well with induction, we first start by proving the following more general lemma:
∀p, σ , σ ′ , , σ ∈ =⇒ σ , p ∗ σ ′ , skip =⇒ σ ′ ∈ ❏p❑()
The proof is by induction on p.
• If p = skip, it is trivially true.
• If p = ∗e1 ← e2 or p = x ← ∗e or p = x ← e, it is true by definition of Store, Load, Assign and
by definition of the tainting semantics.
• If p = p1 ; p2 , then there exists σ ′′ such that σ , p1 ∗ σ ′′ , skip and σ ′′ , p2 ∗ σ ′ , skip.
By induction hypothesis on the first execution, we obtain that σ ′′ ∈ ❏p1 ❑(). Combining this
with using the induction hypothesis on the second execution allows us to conclude that σ ′ ∈
❏p2 ❑(❏p1 ❑()) = ❏p1 ; p2 ❑() = ❏p❑().
• If p = if e then p1 else p2 , then either σ (e) = true and σ , p1 ∗ σ ′ , skip or
σ (e) = false and σ , p2 ∗ σ ′ , skip. In the first case, σ ∈ Assert(, e) and in the latter,
σ ∈ Assert(, not e) which allows us to conclude in both cases by using the induction hypothesis.
• If p = while e do p, then we know that σ ′ (e) = false. Furthermore, we remark that for all
σ ′′ such that σ , while e do p ∗ σ ′′ , while e do p, σ ′′ ∈ I by definition of I. Thus,
σ ′ ∈ I and since σ ′ (e) = false, σ ′ ∈ Assert(I, not e).
The lemma is thus proven, and the theorem is a direct consequence of it.
The regular semantics also has a collecting semantics with the operators Assign, Store, Load, Assert
and a corresponding soundness theorem that we will not detail. The operators are defined as follows:
Assign(, x, e) = σ [x → v]|∃v ∈ V, σ (e) = v ∧ σ ∈
Store(, e1 , e2 ) = σ [l → v]|∃l ∈ L, v ∈ V, σ (e1 ) = l ∧ σ (e2 ) = v ∧ σ ∈
Load(, x, e) = σ [x → v]|∃l ∈ L, v ∈ V, σ (e) = l ∧ σ (l) = v ∧ σ ∈
Assert(, e) = σ ∈ |σ (e) = true
S. Blazy et al. / Verifying constant-time implementations by abstract interpretation
153
Finally, we also need to introduce the concept of concretization to state and prove the correctness of
our abstract interpreter. We already introduced concretize♯ previously which is actually a concretization
function. We will rename it γV♯ as γ is the usual name for a concretization function in abstract interpretation. We use v ∈ γV♯ (v ♯ ) to say that v is in the concretization of abstract value v ♯ , which means that v ♯
represents a set of concrete values of which v is a member.
The abstract memory domain M♯ also provides a concretization function γM♯ : M♯ → P (M) which is
used to define the correctness of the assign♯ , store♯ , load♯ and assert♯ operators:
Assign γM♯ σ ♯ , x, e ⊆ γM♯ assign♯ σ ♯ , e
Store γM♯ σ ♯ , e1 , e2 ⊆ γM♯ store♯ σ ♯ , e1 , e2
Load γM♯ σ ♯ , x, e ⊆ γM♯ load♯ σ ♯ , x, e
Assert γM♯ σ ♯ , e ⊆ γM♯ assert♯ σ ♯ , e
♯
We now need to define γT♯ : T♯ → P (T) and γM♯ : M → P (M).
The first one is simple, γT♯ (L# ) = {L} and γT♯ (H# ) = {L, H}. L# corresponds to value that we know
are necessarily public data, while H# corresponds to value that we only know may depends on secrets.
Now, we define γM♯ :
γM♯ σ ♯ = σ |E ◦ σ ∈ γM♯ E σ ♯ ∧ ∀r, T σ (r) ∈ γT♯ T σ ♯ (r)
This means that an environment σ is in the concretization of σ ♯ if there exists σ ∈ γM♯ (E (σ ♯ )) such
that E ◦ σ = σ and such that T (σ (r)) ∈ γT♯ (T (σ ♯ )(r)) for all location or variable r.
♯
♯
♯
♯
We now need to prove the correctness of the assign , store , load and assert operators:
♯
Assign γM♯ σ ♯ , x, e ⊆ γM♯ assign σ ♯ , x, e
♯
Store γM♯ σ ♯ , e1 , e2 ⊆ γM♯ store σ ♯ , e1 , e2
♯
Load γM♯ σ ♯ , x, e ⊆ γM♯ load σ ♯ , x, e
♯
Assert γM♯ σ ♯ , e ⊆ γM♯ assert σ ♯ , e
♯
Proof. We need to prove that for all σ ∈ Assign(γM♯ (σ ♯ ), x, e), σ ∈ γM♯ (assign (σ ♯ , e)). We first
define E () = {E ◦ σ |σ ∈ } for all ∈ P (M). We then notice that E (Assign(γM♯ (σ ♯ ), x, e)) =
Assign(γM♯ (E (σ ♯ )), x, e) by definitions.
Then, by correctness of assign♯ , we have that Assign(γM♯ (E (σ ♯ )), x, e) ⊆ γM♯ (assign♯ (E (σ ♯ ), x, e)).
♯
♯
And by definition of assign , we have that E (assign (σ , x, e)) = assign♯ (E (σ ♯ ), x, e). Thus,
♯
γM♯ (E (assign (σ , x, e))) = γM♯ (assign♯ (E (σ ♯ ), x, e)) which implies that E (Assign(γM♯ (σ ♯ ), x, e)) ⊆
♯
♯
γM♯ (E (assign (σ , x, e))) and therefore, there exists σ ∈ γM♯ (E (assign (σ , x, e))) such that E (σ ) = σ .
♯
♯
It is then left to prove that for all r, T (σ (r)) ∈ γT♯ (T (assign (σ ♯ , x, e))(r)). By definition of assign ,
♯
♯
T (assign (σ ♯ , x, e)) = T (σ ♯ )[x → taint (σ ♯ , e)]. By definition of Assign, we know that there exists
♯
σ 1 ∈ γM♯ (σ ) such that σ = σ 1 [x → (v, t)] with σ 1 (e) = (v, t).
154
S. Blazy et al. / Verifying constant-time implementations by abstract interpretation
♯
The correctness of taint can easily be proven by induction on e:
♯
σ ∈ γM♯ σ ♯ =⇒ T σ (e) ∈ γT♯ taint σ ♯ , e
♯
By exploiting the lemma, the correctness of assign is thus proven. The correctness of the other operators is similarly proven.
The following theorem which states the correctness of the abstract analyzer with regards to the collecting semantics can now be proven.
Theorem 5. For all abstract environment σ ♯ and program p,
❏p❑ γM♯ σ ♯ ⊆ γM♯ ❏p❑♯ σ ♯
Proof. We first remark that ❏p❑ is a monotone function, i.e. 1 ⊆ 2 =⇒ ❏p❑(1 ) ⊆ ❏p❑(2 ). The
proof is by induction on p. The theorem is also proven by induction on p. We have that:
• if p = skip, it is trivially true;
• if p = ∗e1 ← e2 or p = x ← e or p = x ← ∗e, it is a direct consequence of the correctness of the
corresponding operators;
• if p = p1; p2, we have ❏p1 ❑(γM♯ (σ ♯ )) ⊆ γM♯ (❏p1 ❑♯ (σ ♯ )) by induction hypothesis on p1 and
❏p2 ❑(γM♯ (❏p1 ❑♯ (σ ♯ ))) ⊆ γM♯ (❏p2 ❑♯ (❏p1 ❑♯ (σ ♯ ))) on p2 . And by monotony of ❏p2 ❑, we have
❏p1 ; p2 ❑(γM♯ (σ ♯ )) = ❏p2 ❑(❏p1 ❑(γM♯ (σ ♯ ))) ⊆ ❏p2 ❑(γM♯ (❏p1 ❑♯ (σ ♯ ))) ⊆ γM♯ (❏p2 ❑♯ (❏p1 ❑♯ (σ ♯ ))) =
γM♯ (❏p1 ; p2 ❑♯ (σ ♯ )) which is what we needed to prove;
♯
• if p = if e then p1 else p2 , it is a consequence of the correctness of assert ;
• if p = while e do p, it is a consequence of the correctness of pfp with regard with the invariant,
♯
and the correctness of assert .
The theorem is thus proven.
This theorem intuitively means that the abstract analyzer is correct with regards to the collecting
semantics since if γM♯ (❏p❑♯ (σ ♯ )) is empty, ❏p❑(γM♯ (σ ♯ )) must necessarily be empty too, and thus the
execution is stuck with regards to the collecting semantics.
Finally, combining Theorems 4 and 5, the following correctness theorem is a direct consequence:
Theorem 6. For all program p, environment σ and abstract environment σ ♯ such that σ ∈ γM♯ (σ ♯ ), if
we have the execution σ , p ∗ σ ′ , skip, then we also have σ ′ ∈ γM♯ (❏p❑♯ (σ ♯ )).
This is the main theorem of correctness of the abstract interpreter. It ensures that we compute correct
over-approximations of reachable states in the tainting semantics. We can then safely perform abstract
tests on the program to check that no tainting state may reach a stuck configuration. By that, we mean
that the analyzer may fail or raise alarms during the analysis. For instance, when analyzing if (e)
..., it may raise an alarm to say that e may potentially depend on a secret (i.e., it has a high taint)
at this program point. Hence, we can conclude that if no alarm is raised, then the program is safe with
regard to the tainting semantics and is thus constant-time.
Finally, Fig. 9 summarizes the relationships between the different semantics and the theorems that
links them.
S. Blazy et al. / Verifying constant-time implementations by abstract interpretation
155
Fig. 9. Diagram relating the different semantics.
4. Implementation and experiments
Following the methodology presented in Section 3, we have implemented a prototype leveraging the
Verasco static analyzer. We have been able to evaluate our prototype by verifying multiple actual C
code constant-time algorithms taken from different cryptographic libraries such as NaCl [12], mbedTLS
[36], Open Quantum Safe [16] and curve25519-donna [24]. The implementation is available at the
following address http://www.irisa.fr/celtique/ext/esorics17/.
In order to use our tool, the user simply has to indicate which variables are to be considered as secrets
and the prototype will either raise alarms indicating where secrets may leak, or indicate that the input
program is constant time. The user can either indicate a whole global variable to be considered as secret
at the start of the program, or use the verasco_any_int_secret built-in function to produce a
random signed integer to be considered as secret.
The While language we presented has a few differences with the C#minor language of CompCert
that we analyze using Verasco. First, C#minor allows more constructs such as switch and does not
use while loops, but infinite loops that must be exited using a break statement. Secondly, C#minor
expressions can contain memory reads whereas our While language models a memory load as a statement. However, this is only a slight difference as C#minor programs such as x = ∗y + ∗z are already
transformed into x1 = ∗y; x2 = ∗z; x = x1 + x2 by Verasco in order to improve the precision of the
analysis.
4.1. Memory separation
By leveraging Verasco, the prototype has no problem handling difficult problems such as memory
separation. For example, the small example of Fig. 10 is easily proven as constant time. In this program,
an array t is initialized with random values, such that the values in odd offsets are considered as secrets,
contrary to values in even offsets. So, the analyzer needs to be precise enough to distinguish between the
array cells and to take into account pointer arithmetic. The potential leak happens on line 6. However,
156
S. Blazy et al. / Verifying constant-time implementations by abstract interpretation
Fig. 10. An example program that is analyzed as constant time.
the condition on line 5 constrains i%2 == 0 to be true, and thus i must be even on line 6, so t[i]
does not contain a secret. A naive analyzer would taint the whole array as secret and would thus not be
able to prove the program constant-time, however our prototype has no problem to prove it.
Interestingly, an illustration of the problem can be found in real-world programs. For example, the
NaCl implementation of SHA-256 is not handled by [3] due to this. Indeed, in this program, the hashing
function uses the following C struct as an internal state that contains both secret and public values
during execution.
The hashing function is defined as follows.
It first starts by initializing the internal state with some constant value and then updates it using
the input value in which is considered secret as it can be a password that an user is trying to hash.
Both fields state and buf may contain secret dependent values as a result of the update. Last,
crypto_hash_sha256_final contains a conditional branching that depends on the count field
of the internal state: if ((state->count[1] += bitlen[1]) < bitlen[1]). However,
the whole internal state struct is allocated as a single memory block at low level (i.e., LLVM) and
[3] does not manage to prove the memory separation and cannot thus ensure that the hashing function is
secure.
S. Blazy et al. / Verifying constant-time implementations by abstract interpretation
157
Table 1
Verification of cryptographic primitives
Example
aes
curve25519-donna
des
rlwe_sample
salsa20
sha3
snow
tea
Size
1171
1210
229
145
341
531
871
121
Loc
1399
608
436
1142
652
251
460
109
Time
41.39
586.20
2.28
30.76
5.34
57.62
4.37
3.47
bear_aes_ct
bear_des_ct
bear_sha1
bear_sha256
803
454
243
259
766
560
197
329
1.97
2.54
2.45
2.83
nacl_chacha20
nacl_sha256
384
368
307
287
0.34
1.85
mbedtls_sha1
mbedtls_sha256
mbedtls_sha512
544
346
310
354
346
399
0.33
0.62
0.58
1959
939
933.37
mee-cbc
Result
4.2. Cryptographic algorithms
We report in Table 1 our results on a set of cryptographic algorithms. All executions times reported
were obtained on a 3.1 GHz Intel i7 with 16 GB of RAM. Sizes are reported in terms of numbers of
C#minor statements (i.e., close to C statements), lines of code are measured with cloc and execution
times are reported in seconds. The last column indicates whether the corresponding program has been
managed to be secure by the analysis.
The first block of lines gathers test cases for the implementations of a representative set of cryptographic primitives including TEA [47], an implementation of sampling in a discrete Gaussian distribution by Bos et al. [16] (rlwe_sample) taken from the Open Quantum Safe library [40], an implementation of elliptic curve arithmetic operations over Curve25519 [11] by Langley [24] (curve25519donna), and various primitives such as AES, DES, etc. The second block reports on implementations
from the BearSSL library [9]. The third block reports on different implementations from the NaCl library [12]. The fourth block reports on implementations from the mbedTLS [36] library. Finally, the last
result corresponds to an implementation of MAC-then-Encode-then-CBC-Encrypt (MEE-CBC).
All the analyses are done using the interval abstract domain to track numerical values as it is sufficient
in our case and is the fastest. Prior to analysis, the programs are slightly transformed using the funload option of Verasco which lifts loads out of expressions. For instance, x = *(p + 3) + 4 is
transformed into y = *(p + 3); x = y + 4 where y is a fresh variable. This allows the analysis
to be more precise. Furthermore, Verasco is not able to compute a precise enough loop invariant for some
of the programs, we thus indicate to Verasco to unroll these loops. Some of the timings differ with the
results reported in the conference version due to a bug in the modification made to Verasco which caused
158
S. Blazy et al. / Verifying constant-time implementations by abstract interpretation
it to silently fail. Unfortunately, nacl_sha512 was erroneously reported as verified in the conference
version.
All these examples are proven constant time, except for AES and DES which both make use of look up
tables. Our prototype rightfully reports memory accesses depending on secrets, so these two programs
are not constant time. Similarly to [3], rlwe_sample is only proven constant time, provided that the
core random generator is also constant time, thus showing that it is the only possible source of leakage.
The last example mee-cbc is a full implementation of the MEE-CBC construction using low-level
primitives taken from the NaCl library. Our prototype is able to verify the constant-time property of this
example, showing that it scales to large code bases (939 loc).
Our prototype is able to verify a similar amount of programs than [3], except for a constant-time fixed
point operations library named libfixedtimefixedpoint [4] which unfortunately does not use
standard C and is not handled by CompCert. The library uses extensively a GNU extension known as
statement-expressions and would require heavy rewriting to be accepted by our tool.
On the other hand, our tool shows its agility with memory separation on the program SHA-256 that
was out of reach for [3] and its restricted alias management. In terms of analysis time, our tool behaves
similarly to [3]. On a similar experiment platform, we observe a speedup between 0.1 and 10. This is
very encouraging for our tool whose efficiency is still in an upgradeable stage, compared to the tool of
[3] that relies on decades of implementation efforts for the LLVM optimizer and the Boogie verifier.
5. Related work
This paper deals with static program verification for information-flow tracking [44]. Different formal
techniques have been used in this area. The type-based approach [39] provides an elegant modular
verification approach but requires program annotations, especially for each program function. Because
a same function can be called in very different security contexts, providing an expressive annotation
language is challenging and annotating programs is a difficult task. This approach has been mainly
proposed for programming languages with strong typing guarantees such as Java [39] and ML [41]. The
deductive approach [21] is based on more expressive logics than type systems and then allows to express
subtle program invariants. On the other hand, the loop invariant annotation effort requires strong formal
method expertise and is very much time consuming.
The static analysis approach only requires minimal annotation (the input taints) and then tries to infer
all the remaining invariants in the restricted analysis logic. This approach has been followed to track
efficiently implicit flows using program dependence graphs [29,43]. We also follow a static approach but
our backbone technique is an advanced value analysis for C, that we use to infer fine-grained memory
separation properties and finely track taints in an unfolded call graph of the program. Building a program
dependence graph for memory is a well-known challenge and scaling this approach to a Verasco (or
Astrée) memory analysis is left for further work.
This paper deals however with a restricted notion of information flow: constant-time security. Here,
implicit flow tracking is simplified since we must reject1 control-flow branching that depends on secret
inputs. Our abstract interpretation approach proposes to companion a taint analysis with a powerful value
analysis. The tool tis-ct [46] uses a similar approach but based on the Frama-C value analysis, instead
of Verasco (and its Astrée architecture). The tool is developed by the TrustInSoft company and not
associated with any scientific publication. It has been used to analyze OpenSSL. Frama-C and Verasco
1 We
could accept some of them if we were able to prove that all branches provide a similar timing behavior.
S. Blazy et al. / Verifying constant-time implementations by abstract interpretation
159
value analysis are based on different abstract interpretation techniques and thus the tainting power of
tis-ct and our tool will differ. As an example of difference, Verasco provides relational abstraction of
memory contents while tis-ct is restricted to non-relational analysis (like intervals). CacheAudit [25] is
also based on abstract interpretation but analyzes cache leakage at binary level. Analyzing program at
this low level tempers the inference capabilities for memory separation, because the memory is seen as a
single memory block. Verasco benefits from a source-level view where each function has its own region
for managing local variables.
In a previous work of the second author [8], C programs were compiled by CompCert to an abstraction
of assembly before being analyzed. A simple data-flow analysis was then performed, flow insensitive for
every memory block except the memory stack, and constant-time security was verified. The precision
of this approach required to fully inline the program before analysis. It means that every function call
was replaced by its function body until no more function call remained. This has serious impact on the
efficiency of the analysis and a program like curve25519-donna was out of reach. The treatment
of memory stack was also very limited since no value analysis was available at this level of program
representation. There was no way to finely taint an array content if this array laid in the stack (which
occurs when C arrays are declared as local variables). Hence, numerous manual program rewritings were
required before analysis. Our current approach releases these restrictions but requires more trust on the
compiler (see our discussion in the conclusion).
A very complete treatment of constant-time security has been recently proposed by the ct-verif tool
[3]. Its verification is based on a reduction of constant-time security of a program P to safety of a product
program Q that simulates two parallel executions of P . The tool is based on the LLVM compiler and
operates at the LLVM bytecode level, after LLVM optimizations and alias analyses. Once obtained, the
bytecode program is transformed into a product program which, in turn, is verified by the Boogie verifier
[6] and its traditional SMT tool suite. In Section 4, we made a direct experimental comparison with this
tool. We list here the main design differences between this work and ours.
First we do not perform the analysis at a similar program representation. LLVM bytecode is interesting
because one can develop analyses that benefit from the rich collection of tools provided by the LLVM
platform. For example, [3] benefits from LLVM data-structure analysis [33] to partition memory objects
into disjoint regions. Still, compiler alias analyses are voluntarily limited because compilers translate
programs in almost linear time. Verasco (and its ancestor Astrée) follows a more ambitious approach and
tracks very finely the content of the memory. Using Verasco requires a different tool design but opens
the door for more verified programs, as for example the SHA-256 example. Second, we target a more
restricted notion of constant-time security than [3] which relaxes the property with a so-called notion of
publicly observable outputs. The extension is out of scope of our current approach but seems promising
for specific programs. Only one program in our current experiment is affected by this limitation. At last,
we embed our tool in a more foundational semantic framework. Verasco and CompCert are formally
verified. It leaves the door open for a fully verified constant-time analyzer, while a fully verified ct-verif
tool would require to prove SMT solvers, Boogie verifier and LLVM. The Vellvm [49] is a first attempt
in the direction of verifying the LLVM platform, but it is currently restricted to a core subset (essentially
the SSA generation) of the LLVM passes, and suffers from time-performance limitations.
Constant-time security is part of the larger field of high-assurance cryptography [7] which is a fertile
area that has spawned many recent projects. There are two broad categories of methods of ensuring high
assurance: either it is formally verified using a proof assistant such as Coq or F*, or it is verified using
automatic tools such as Boogie. Each method has its own drawbacks: the former usually needs a highly
160
S. Blazy et al. / Verifying constant-time implementations by abstract interpretation
experienced user to be accomplished while the latter is automatic but needs to trust in unverified and
non-trivial tools such as SMT solvers. Our work places itself in the first category.
Vale [15] is a tool for producing verified cryptographic assembly code. Users write code in the Vale
language which is similar to assembly, and then add a functional specification of the code in Dafny
[34], an automatic program verifier. The tool then automatically verifies that the code complies with the
specification by using SMT solvers such as Z3 [22]. The authors also implemented a verified analyzer
to ensure absence of timing and cache based side channels. However, like [3], their analyzer does not
handle memory separation problems well and has to rely on handwritten annotation from the user. For
instance, they also cannot automatically handle the same SHA256 example as [3].
HACL* [51] is a formally verified C cryptographic library. Similarly to [15], the library was created
by first writing cryptographic code in the proof assistant F* [45]. The code is then verified for functional
correctness, memory safety and freedom of timing side channels. However, unlike [15], proofs are entirely manual and thus need an experienced user. While their work tackles functional correctness and
constant-time security of cryptographic programs, an experienced user is needed, whereas ours is automatic but only deals with constant-time security. Furthermore, as F* is a high-level language, it is more
difficult to make sure that these properties are preserved during compilation, while our work focuses on
C#minor which is a language closer to assembly than F*.
Jasmin [2] is a formally-verified compiler from the Jasmin language down to assembly. The Jasmin
language is a small low-level language similar to Bernstein’s qhasm that also supports function calls
and high-level control-flow constructs such as loops. The authors have implemented a sound embedding
of Jasmin into Dafny and users can thus automatically prove memory safety and constant-time security
of their Jasmin programs using SMT solvers. Constant-time security is proven using product programs
similarly to the ct-verif tool [3]. However, they do not mention if they suffer from the same memory
separation issues.
FaCT [18] proposes a domain-specific language (DSL) to replace C as it is very prone to errors that
can enable side channels. Their DSL can be basically seen as C enhanced with new annotations for
expressing security levels such as which inputs can be considered secret or public. The language contains
also new instructions that directly map to useful hardware instructions such as add-with-carry that are
rarely produced by general purpose compilers. They use the Z3 SMT solver to prove memory safety
of code written in this new language. Furthermore, as secret and public annotations are built in the
language, they can adjust the compiler in order to take advantage of constant-time aware optimizations.
Finally, as the tool is built upon LLVM, they can use the ct-verif tool [3] to verify that the generated
code is secure, but must thus suffer the same limitations.
Fiat-crypto [26] is a formally verified compiler specifically optimized for generating efficient ellipticcurve code used in cryptography. However, the proven properties are only concerned with functional
correctness. The compilation results in straightline code and they thus do not have to worry about secret
dependent branching, but only about secret dependent memory accesses. The resulting code is thus not
entirely proven constant-time.
In a series of publications [5,10,48], the authors leverage the Verified Software Toolchain and CompCert to prove the functional correctness of an ASM implementation of SHA-256 and an implementation
of HMAC with SHA-256, as well as functional correctness and cryptographic security of an implementation of HMAC-DBRG. However, they do not prove anything about side-channels resistance.
Other approaches rely on dynamic analysis (e.g. [20] that extends of Valgrind in order to check
constant-address security) or on statistical analysis of execution timing [42]. These approaches are not
sound, contrary to our approach.
S. Blazy et al. / Verifying constant-time implementations by abstract interpretation
161
6. Conclusion
In this paper, we presented a methodology to ensure that a software implementation is constant time.
Our methodology is based on advanced abstract interpretation techniques and scales on commonly used
cryptographic libraries. Our implementation sits in a rich foundational semantic framework, Verasco
and CompCert, which give strong semantic guarantees. The analysis is performed at source level and
can hence give useful feedback to the programmer that needs to understand why his program is not
constant time.
There are multiple possible directions for future work. The first one concerns semantic soundness. By
inspecting CompCert transformation passes, we conjecture that they preserve the constant-time property
of source programs that have been successfully analyzed. Informally, no conditional branching is added
during compilation. Furthermore, memory accesses can only be added due to spilling during register
allocation; however, these spilled variables are allocated at constant offsets on the stack and cannot thus
depend on secrets. We left as further work a formal proof of this conjecture.
A second direction concerns expressiveness. In order to verify more relaxed properties, we could try to
mix the program-product approach of [3] with the Verasco analysis. The current loop invariant inference
and analysis of [3] are rather restricted. Using advanced alias analysis and relational numeric analysis
could strengthen the program-product approach, if it was performed at the same representation level as
Verasco.
Another possible direction is to also verify that multiplications and divisions are not secret dependent
as on some platforms, their execution times may differ depending on the data they operate on.
References
[1] O. Aciiçmez, Ç.K. Koç and J.-P. Seifert, On the power of simple branch prediction analysis, in: ACM Symposium on
Information, Computer and Communications Security, ACM, 2007, pp. 312–320.
[2] J. Almeida, M. Barbosa, G. Barthe, A. Blot, B. Grégoire, V. Laporte, T. Oliveira, H. Pacheco, B. Schmidt and P.-Y. Strub,
Jasmin: High-assurance and high-speed cryptography, in: CCS 2017 – Proceedings of the 2017 ACM SIGSAC Conference
on Computer and Communications Security, 2017.
[3] J.B. Almeida, M. Barbosa, G. Barthe, F. Dupressoir and M. Emmi, Verifying constant-time implementations, in: 25th
USENIX Security Symposium, USENIX Security 16, Austin, TX, USA, August 10–12, 2016, 2016, pp. 53–70.
[4] M. Andrysco, D. Kohlbrenner, K. Mowery, R. Jhala, S. Lerner and H. Shacham, On subnormal floating point and abnormal timing, in: Proceedings of the 2015 IEEE Symposium on Security and Privacy, SP ’15, IEEE Computer Society,
Washington, DC, USA, 2015, pp. 623–639. ISBN 978-1-4673-6949-7. doi:10.1109/SP.2015.44.
[5] A.W. Appel, Verification of a cryptographic primitive: SHA-256, ACM Transactions on Programming Languages and
Systems (TOPLAS) 37(2) (2015), 7. doi:10.1145/2701415.
[6] M. Barnett, B.E. Chang, R. DeLine, B. Jacobs and K.R.M. Leino, Boogie: A modular reusable verifier for object-oriented
programs, in: Proc. of FMCO 2005, 2005, pp. 364–387.
[7] G. Barthe, High-assurance cryptography: Cryptographic software we can trust, IEEE Security & Privacy 13(5) (2015),
86–89. doi:10.1109/MSP.2015.112.
[8] G. Barthe, G. Betarte, J.D. Campo, C.D. Luna and D. Pichardie, System-level non-interference for constant-time cryptography, in: ACM SIGSAC Conference on Computer and Communications Security, 2014, pp. 1267–1279.
[9] BearSSL, https://www.bearssl.org/.
[10] L. Beringer, A. Petcher, Q.Y. Katherine and A.W. Appel, Verified correctness and security of OpenSSL HMAC., in:
USENIX Security Symposium, 2015, pp. 207–221.
[11] D.J. Bernstein, Curve25519: New Diffie-Hellman speed records, M. Yung, Y. Dodis, A. Kiayias and T. Malkin, eds,
Springer, Berlin, Heidelberg, 2006, pp. 207–228. ISBN 978-3-540-33852-9.
[12] D.J. Bernstein, T. Lange and P. Schwabe, The security impact of a new cryptographic library, in: International Conference
on Cryptology and Information Security in Latin America, Springer, 2012, pp. 159–176.
[13] B. Blanchet, P. Cousot, R. Cousot, J. Feret, L. Mauborgne, A. Miné, D. Monniaux and X. Rival, A static analyzer for large
safety-critical software, in: Programming Language Design and Implementation, ACM, 2003, pp. 196–207.
162
S. Blazy et al. / Verifying constant-time implementations by abstract interpretation
[14] S. Blazy, V. Laporte and D. Pichardie, An abstract memory functor for verified C static analyzers, in: Proc. of the 21st
ACM SIGPLAN Int. Conference on Functional Programming (ICFP 2016), ACM, 2016.
[15] B. Bond, C. Hawblitzel, M. Kapritsos, K.R.M. Leino, J.R. Lorch, B. Parno, A. Rane, S. Setty and L. Thompson, Vale:
Verifying high-performance cryptographic assembly code, in: Proceedings of the USENIX Security Symposium, 2017.
[16] J.W. Bos, C. Costello, M. Naehrig and D. Stebila, Post-quantum key exchange for the TLS protocol from the ring learning
with errors problem, in: 2015 IEEE Symposium on Security and Privacy, SP 2015, San Jose, CA, USA, May 17–21, 2015,
2015, pp. 553–570.
[17] B. Canvel, A. Hiltgen, S. Vaudenay and M. Vuagnoux, Password interception in a SSL/TLS channel, in: CRYPTO, LNCS,
Vol. 2729, Springer, 2003, pp. 583–599.
[18] S. Cauligi, G. Soeller, F. Brown, B. Johannesmeyer, Y. Huang, R. Jhala and D. Stefan, FaCT: A flexible, constant-time programming language, in: Cybersecurity Development (SecDev), 2017 IEEE, IEEE, 2017, pp. 69–76. doi:10.1109/SecDev.
2017.24.
[19] P. Cousot and R. Cousot, Abstract interpretation: A unified lattice model for static analysis of programs by construction
or approximation of fixpoints, in: Conference Record of the Fourth ACM Symposium on Principles of Programming
Languages,, ACM, 1977, pp. 238–252.
[20] ctgrind, https://github.com/agl/ctgrind.
[21] Á. Darvas, R. Hähnle and D. Sands, A theorem proving approach to analysis of secure information flow, in: Proc. 2nd International Conference on Security in Pervasive Computing, D. Hutter and M. Ullmann, eds, LNCS, Vol. 3450, SpringerVerlag, 2005, pp. 193–209. doi:10.1007/978-3-540-32004-3_20.
[22] L. De Moura and N. Bjørner, Z3: An efficient SMT solver, in: International Conference on Tools and Algorithms for the
Construction and Analysis of Systems, Springer, 2008, pp. 337–340.
[23] D.E. Denning, A lattice model of secure information flow, Commun. ACM 19(5) (1976), 236–243. doi:10.1145/360051.
360056.
[24] donna, https://code.google.com/archive/p/curve25519-donna.
[25] G. Doychev, D. Feld, B. Köpf, L. Mauborgne and J. Reineke, CacheAudit: A tool for the static analysis of cache side
channels, in: USENIX Conference on Security, USENIX Association, Berkeley, CA, USA, 2013, pp. 431–446.
[26] A. Erbsen, J. Philipoom, J. Gross, R. Sloan and A. Chlipala, Simple high-level code for cryptographic arithmetic – With
proofs, without compromises, in: Proceedings of the 40th IEEE Symposium on Security and Privacy (S&P’19), 2019.
[27] N.J.A. Fardan and K.G. Paterson, Lucky thirteen: Breaking the TLS and DTLS record protocols, in: Symp. on Security
and Privacy (SP 2013), IEEE Computer Society, 2013, pp. 526–540. doi:10.1109/SP.2013.42.
[28] J. Feret, Static analysis of digital filters, in: European Symposium on Programming (ESOP’04), LNCS, Vol. 2986,
Springer, 2004.
[29] C. Hammer and G. Snelting, Flow-sensitive, context-sensitive, and object-sensitive information flow control based on
program dependence graphs, Int. J. Inf. Sec. 8(6) (2009), 399–422. doi:10.1007/s10207-009-0086-1.
[30] D. Hedin and A. Sabelfeld, A perspective on information-flow control, in: Software Safety and Security – Tools for
Analysis and Verification, IOS Press, 2012, pp. 319–347.
[31] J.-H. Jourdan, V. Laporte, S. Blazy, X. Leroy and D. Pichardie, A formally-verified C static analyzer, in: Proc. of the 42th
ACM SIGPLAN–SIGACT Symposium on Principles of Programming Languages, POPL 2015, ACM, 2015, pp. 247–259.
[32] P. Kocher, Timing attacks on implementations of Diffie-Hellman, RSA, DSS, and other systems, in: Advances in Cryptology – CRYPTO ’96, LNCS, Vol. 1109, Springer, 1996, pp. 104–113.
[33] C. Lattner, A. Lenharth and V.S. Adve, Making context-sensitive points-to analysis with heap cloning practical for the
real world, in: Proc. of PLDI’07, 2007, pp. 278–289. doi:10.1145/1250734.1250766.
[34] K.R.M. Leino, Dafny: An automatic program verifier for functional correctness, in: International Conference on Logic for
Programming Artificial Intelligence and Reasoning, Springer, 2010, pp. 348–370. doi:10.1007/978-3-642-17511-4_20.
[35] X. Leroy, Formal verification of a realistic compiler, Communications of the ACM 52(7) (2009), 107–115. doi:10.1145/
1538788.1538814.
[36] mbed TLS (formerly known as PolarSSL), https://tls.mbed.org/.
[37] A. Miné, The octagon abstract domain, Higher-Order and Symbolic Computation 19(1) (2006), 31–100. doi:10.1007/
s10990-006-8609-1.
[38] A. Miné, Field-sensitive value analysis of embedded C programs with union types and pointer arithmetics, in: Proc. of the
ACM SIGPLAN–SIGBED Conference on Languages, Compilers, and Tools for Embedded Systems (LCTES’06), ACM,
2006, pp. 54–63.
[39] A.C. Myers, JFlow: Practical mostly-static information flow control, in: Proc. of POPL’99, 1999, pp. 228–241. doi:10.
1145/292540.292561.
[40] Open Quantum Safe, https://openquantumsafe.org/.
[41] F. Pottier and V. Simonet, Information flow inference for ML, ACM Trans. Program. Lang. Syst. 25(1) (2003), 117–158.
doi:10.1145/596980.596983.
[42] O. Reparaz, J. Balasch and I. Verbauwhede, Dude, is my code constant time, in: Proc. of DATE 2017, 2017.
S. Blazy et al. / Verifying constant-time implementations by abstract interpretation
163
[43] B. Rodrigues, F.M. Quintão Pereira and D.F. Aranha, Sparse representation of implicit flows with applications to sidechannel detection, in: Compiler Construction, ACM, 2016, pp. 110–120.
[44] A. Sabelfeld and A.C. Myers, Language-based information-flow security, IEEE Journal on Selected Areas in Communications 21(1) (2003), 5–19. doi:10.1109/JSAC.2002.806121.
[45] N. Swamy, J. Chen, C. Fournet, P. Strub, K. Bhargavan and J. Yang, Secure distributed programming with valuedependent types, in: Proceeding of the 16th ACM SIGPLAN International Conference on Functional Programming, M.M.T. Chakravarty, Z. Hu and O. Danvy, eds, ACM, 2011, pp. 266–278, https://www.microsoft.com/en-us/
research/publication/secure-distributed-programming-with-value-dependent-types/. ISBN 978-1-4503-0865-6. doi:10.
1145/2034773.2034811.
[46] TIS-CT, http://trust-in-soft.com/tis-ct/.
[47] D.J. Wheeler and R.M. Needham, TEA, a tiny encryption algorithm, B. Preneel, ed., Springer, Berlin, Heidelberg, 1995,
pp. 363–366. ISBN 978-3-540-47809-6.
[48] K.Q. Ye, M. Green, N. Sanguansin, L. Beringer, A. Petcher and A.W. Appel, Verified correctness and security of mbedTLS
HMAC-DRBG, in: Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, CCS
’17, ACM, New York, NY, USA, 2017, pp. 2007–2020, http://doi.acm.org/10.1145/3133956.3133974. ISBN 978-1-45034946-8. doi:10.1145/3133956.3133974.
[49] J. Zhao, S. Zdancewic, S. Nagarakatte and M. Martin, Formalizing the LLVM intermediate representation for verified
program transformation, in: POPL’12, ACM, New York, NY, USA, 2012, pp. 427–440. doi:10.1145/2103656.2103709.
[50] M. Zhao and G.E. Suh, FPGA-based remote power side-channel attacks, in: 2018 IEEE Symposium on Security and
Privacy (SP), pp. 839–854, doi.ieeecomputersociety.org/10.1109/SP.2018.00049. ISSN 2375-1207. doi:10.1109/SP.2018.
00049.
[51] J.-K. Zinzindohoué, K. Bhargavan, J. Protzenko and B. Beurdouche, HACL*: A verified modern cryptographic library,
in: Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, CCS ’17, ACM, New
York, NY, USA, 2017, pp. 1789–1806, http://doi.acm.org/10.1145/3133956.3134043. ISBN 978-1-4503-4946-8. doi:10.
1145/3133956.3134043.
Keep reading this paper — and 50 million others — with a free Academia account
Used by leading Academics
Álvaro Figueira, PhD
Faculdade de Ciências da Universidade do Porto
Christopher Crick
Oklahoma State University
Qusay F. Hassan
Dag I K Sjoberg
University of Oslo
