PresentationPDF Available

CIDPro: Custom Instructions for Dynamic Program Diversification

  • August 2018
  • Conference: 28th International Conference on Field Programmable Logic & Applications (FPL)
Authors:
Thinh Hung Pham at University of Bristol
Thinh Hung Pham
Arnab Kumar Biswas
Arnab Kumar Biswas
Arnab Kumar Biswas
  • This person is not on ResearchGate, or hasn't claimed this research yet.
Siew Kei Lam at Nanyang Technological University
Siew Kei Lam
Nandeesh Veeranna at The Hong Kong Polytechnic University
Nandeesh Veeranna
Show all 5 authorsHide
Download file PDF
Read file
Download citation

Abstract and Figures

Slides of the oral presentation of the corresponding paper (https://www.researchgate.net/publication/327495855_CIDPro_Custom_Instructions_for_Dynamic_Program_Diversification)
Figures - uploaded by Alexander Fell
Author content
All figure content in this area was uploaded by Alexander Fell
Content may be subject to copyright.
Content uploaded by Alexander Fell
Author content
All content in this area was uploaded by Alexander Fell on Sep 07, 2018
Content may be subject to copyright.
CIDPro
Custom Instructions for Dy-
namic Program Diversifica-
tion
Thinh Hung Pham, Alexan-
der Fell, Arnab Kumar
Biswas, Siew-Kei Lam,
Nandeesha Veeranna
August 28, 2018
Outline
Introduction
CIDPro Framework
Results and Discussion
Architecture Overview
Hardware Resources
Comparison to Existing Solutions
Conclusion
References
Side-Channel Attacks
IUnintentional leakage of information through side-channels caused by variations
in:
Ipower consumption of the processor
Itemperature
Ielectromagnetic emittance
Iduration of program execution
I. . .
Aim:
Protect the secret of a program executed in a low noise environment (i.e. bare-metal)
with minimal hardware modifications.
Side-Channel Attacks
IUnintentional leakage of information through side-channels caused by variations
in:
Ipower consumption of the processor
Itemperature
Ielectromagnetic emittance
Iduration of program execution
I. . .
Aim:
Protect the secret of a program executed in a low noise environment (i.e. bare-metal)
with minimal hardware modifications.
Example Program
Input: data y, private key k, integer N
Output: ykmod N
1: function modExp(y,k,N)
2: r←1
3: for all hki|i∈kido
4: if (ki= 1) then Critical Condition
5: r←(r×y) mod N
6: end if
7: y←y2mod N
8: end for
9: return rmod N
10: end function
Execution Times of the Example Program
4,200 4,300 4,400 4,500 4,600 4,700
0
100
200
300
400
(a) Baseline
6,800 6,900 7,000 7,100 7,200
0
100
200
300
400
(b) Conditional Assignment
key0 key1
6,700 6,800 6,900 7,000 7,100 7,200
0
100
200
300
(c) Cross-Copying
3,300 3,400 3,500 3,600 3,700 3,800
0
100
200
300
(d) Left-to-Right Sliding Window
CIDPro Framework I
Definition
Diversified Instructions
{DI1, DI2, ..., DIm}
Hardware Diversification
Integration
{CoPr(II11, II12, ..., II1n),
CoPr(II21, II22, ..., II2n),
...
CoPr(IIm1, IIm2, ..., IImn)} Secured Processor
Processor
Custom
Instr.
Co-Processor
PRNG
Diversity
Control
{II11, II21, ..., IIm1}
{II12, II22, ..., IIm2}
{II1n, II2n, ..., IImn}
(1..n)
Diversification
Framework
Custom Instruction (CI)
Generation
DIi -> CIi ; i = 1..m
Custom Instruction
Integration
Diversified Instruction (DI)
Implementation
DIi ->{IIi1, IIi2, ..., IIin}
Program
LLVM
LLVM IR
Compiler
executable file
CIDPro Framework II
Definition
Diversified Instructions
{DI1, DI2, ..., DIm}
Hardware Diversification
Integration
{CoPr(II11, II12, ..., II1n),
CoPr(II21, II22, ..., II2n),
...
CoPr(IIm1, IIm2, ..., IImn)} Secured Processor
Processor
Custom
Instr.
Co-Processor
PRNG
Diversity
Control
{II11, II21, ..., IIm1}
{II12, II22, ..., IIm2}
{II1n, II2n, ..., IImn}
(1..n)
Diversification
Framework
Custom Instruction (CI)
Generation
DIi -> CIi ; i = 1..m
Custom Instruction
Integration
Diversified Instruction (DI)
Implementation
DIi ->{IIi1, IIi2, ..., IIin}
Program
LLVM
LLVM IR
Compiler
executable file
Let DI ={DI1,DI2,...,DIm}a set of diversified instructions with
each element DIiconsisting of {II 1
i,II 2
i,...,II n
i}implementations.
CIDPro Framework III
Definition
Diversified Instructions
{DI1, DI2, ..., DIm}
Hardware Diversification
Integration
{CoPr(II11, II12, ..., II1n),
CoPr(II21, II22, ..., II2n),
...
CoPr(IIm1, IIm2, ..., IImn)} Secured Processor
Processor
Custom
Instr.
Co-Processor
PRNG
Diversity
Control
{II11, II21, ..., IIm1}
{II12, II22, ..., IIm2}
{II1n, II2n, ..., IImn}
(1..n)
Diversification
Framework
Custom Instruction (CI)
Generation
DIi -> CIi ; i = 1..m
Custom Instruction
Integration
Diversified Instruction (DI)
Implementation
DIi ->{IIi1, IIi2, ..., IIin}
Program
LLVM
LLVM IR
Compiler
executable file
f(II n
i)6=f(II n
j) with i6=j.
Let Tbe the execution time such that T(II 1
i)6=· · · 6=T(II n
i).
CIDPro Framework IV
Definition
Diversified Instructions
{DI1, DI2, ..., DIm}
Hardware Diversification
Integration
{CoPr(II11, II12, ..., II1n),
CoPr(II21, II22, ..., II2n),
...
CoPr(IIm1, IIm2, ..., IImn)} Secured Processor
Processor
Custom
Instr.
Co-Processor
PRNG
Diversity
Control
{II11, II21, ..., IIm1}
{II12, II22, ..., IIm2}
{II1n, II2n, ..., IImn}
(1..n)
Diversification
Framework
Custom Instruction (CI)
Generation
DIi -> CIi ; i = 1..m
Custom Instruction
Integration
Diversified Instruction (DI)
Implementation
DIi ->{IIi1, IIi2, ..., IIin}
Program
LLVM
LLVM IR
Compiler
executable file
The Secured Coprocessor activates the appropriate DIi. A pseudo
random generator selects II j
i.
CIDPro Framework V
Definition
Diversified Instructions
{DI1, DI2, ..., DIm}
Hardware Diversification
Integration
{CoPr(II11, II12, ..., II1n),
CoPr(II21, II22, ..., II2n),
...
CoPr(IIm1, IIm2, ..., IImn)} Secured Processor
Processor
Custom
Instr.
Co-Processor
PRNG
Diversity
Control
{II11, II21, ..., IIm1}
{II12, II22, ..., IIm2}
{II1n, II2n, ..., IImn}
(1..n)
Diversification
Framework
Custom Instruction (CI)
Generation
DIi -> CIi ; i = 1..m
Custom Instruction
Integration
Diversified Instruction (DI)
Implementation
DIi ->{IIi1, IIi2, ..., IIin}
Program
LLVM
LLVM IR
Compiler
executable file
Custom Instruction Integration: Search through the source code, re-
placing original instructions OI with f(OI ) = f(DIi).
Modified Example Program
Let DI1=×and DI2= mod
Input: data y, private key k, integer N
Output: ykmod N
1: function modExp(y,k,N)
2: r←1
3: for all hki|i∈kido
4: if (ki= 1) then
5: r←(r×y) mod N
6: end if
7: y←y2mod N
8: end for
9: return rmod N
10: end function
Input: data y, private key k, integer N
Output: ykmod N
1: function modExp(y,k,N)
2: r←1
3: for all hki|i∈kido
4: m←ki×(−1)
5: rr ←(rDI1y)DI2N
6: r←(m∧rr)∨(¬m∧r)
7: y←(yDI1y)DI2N
8: end for
9: return rDI2N
10: end function
Test Environment
IRISC-V Rocket Core [3] on a Zynq7000 XC7Z020 FPGA
I64bit
I50MHz
IBranch Prediction
IL1 Instruction and Data Cache
IL2 Cache
IFPU
IH/W Multiplier and Division Unit with Early Out
IRocket Chip Co-Processor
IBare Metal Program Execution
IRSA modular exponentiation (modExp) to encrypt or decrypt a message [8] from
the benchmark suite introduced in [5]
IModular multiplication (mulMod16) from the IDEA cipher [4]
Architecture Overview I
BTB
Instr.
Cache
Data
Cache
Reg.
Files
+4
Dec.
Mul-Div
FPU
ALU
RoCC
ALU
BTB
Dec.
FPU
Instr.
Mul-Div
Reg.
RoCC
Rocket Pipeline
Fetch Decode
PCGen Execute Memory Commit
: Arithmetic Logic Unit
: Branch Target Buffer
: Decoder
: Floating Point Unit
: Instruction
: Multiplier-Divider
: Register
: Rocket Chip Co-processor
Architecture Overview II
Rocket
Comand
Interface
Response
Interface
PRNG
Truncate Truncate
Timer
Compare
RoCC
Cmd
Resp
RoCC
Interface
funct
data
valid
Di-
ALU dl dl
Hardware Resources
RocketTile CPU FPU RoCC
Slices 6612 1331 3458 84
DSPs 34 4 20 10
Diversification Result
4,000 4,100 4,200 4,300 4,400 4,500
0
50
100
150
200
(a) dl = 3
4,200 4,300 4,400 4,500 4,600 4,700 4,800
0
20
40
60
80
100
120
(b) dl = 4
key0 key1
4,800 5,000 5,200
0
20
40
60
(c) dl = 5
5,400 5,600 5,800 6,000 6,200 6,400 6,600
0
10
20
30
(d) dl = 6
Channel Capacity
1234567
0
0.2
0.4
0.6
0.8
1
Diversification Level
Channel Capacity
BL Ca Cc LR PrBL PrLR
Average Execution Time
1234567
0
0.2
0.4
0.6
0.8
1
Diversification Level
Channel Capacity
BL Ca Cc LR PrBL PrLR
1234567
0
2,000
4,000
6,000
8,000
Diversification Level
Execution Times (Cycles)
Execution Time Comparison to Existing Solutions
Figure: modExp
BL Ca Cc Pr
0
50
100
150
200
( % )
Figure: mulMod16
Conclusion
Hardware Overhead: 1%
Timing side-channel capacity reduction: 80% (modExp) and 86% (mulMod16)
Average Execution Time Increase: 13% (modExp) and 75% (mulMod16)
Thank you
References I
[1] J. Agat.
Transforming out Timing Leaks.
In Proceedings of the 27th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, pages 40–53, 2000.
[2] T. Chothia, Y. Kawamoto, and C. Novakovic.
A Tool for Estimating Information Leakage, pages 690–695.
Springer, CAV 2013, 2013.
[3] K. A. et al.
The Rocket Chip Generator.
Technical Report UCB/EECS-2016-17, EECS Department, University of California, Berkeley, Apr. 2016.
[4] X. Lai.
On the design and security of block ciphers.
Phd thesis, ETH Zurich, 1992.
[5] H. Mantel and A. Starostin.
Transforming Out Timing Leaks, More or Less.
In European Symposium on Research in Computer Security., pages 447–467. Springer, Cham, 2015.
[6] A. J. Menezes, P. C. Van Oorschot, and S. A. Vanstone.
Handbook of applied cryptography.
CRC press, 1996.
[7] D. Molnar, M. Piotrowski, D. Schultz, and D. Wagner.
The Program Counter Security Model: Automatic Detection and Removal of Control-Flow Side Channel Attacks.
In Information Security and Cryptology, pages 156–168. Springer Berlin Heidelberg, 2006.
[8] R. L. Rivest, A. Shamir, and L. Adleman.
A Method for Obtaining Digital Signatures and Public-key Cryptosystems.
Communications of the ACM, 21(2):120–126, Feb. 1978.
[9] C. E. Shannon.
A mathematical theory of communication.
The Bell System Technical Journal, 27(3):379–423, July 1948.
Cross Copying
Input: data y, private key k, integer N
Output: ykmod N
1: function modExp(y,k,N)
2: r←1
3: for all hki|i∈kido
4: if (ki= 1) then Critical Condition
5: r←(r×y) mod N
6: else
7: rr ←r
8: r←(r×y) mod N
9: r←rr
10: end if
11: y←y2mod N
12: end for
13: return rmod N
14: end function
Conditional Assignment
Input: data y, private key k, integer N
Output: ykmod N
1: function modExp(y,k,N)
2: r←1
3: for all hki|i∈kido
4: m←ki×(−1)
5: rr ←(r×y) mod N
6: r←(m∧rr)∨(¬m∧r)
7: y←y2mod N
8: end for
9: return rmod N
10: end function
Microarchitectural Side-Channel Threats, Weaknesses and Mitigations: A Systematic Mapping Study
Article
Full-text available
  • Jan 2023
Over the course of recent years, microarchitectural side-channel attacks emerged as one of the most novel and thought-provoking attacks to exfiltrate information from computing hardware. These attacks leverage the unintended artefacts produced as side-effects to certain architectural design choices and proved difficult to be effectively mitigated without incurring significant performance penalties. In this work, we undertake a systematic mapping study of the academic literature related to the aforementioned attacks. We, in particular, pose four research questions and study 104 primary works to answer those questions. We inquire about the origins of artefacts leading up to exploitable settings of microarchitectural side-channel attacks; the effectiveness of the proposed countermeasures; and the lessons to be learned that would help build secure systems for the future. Furthermore, we propose a classification scheme that would also serve in the future for systematic mapping efforts in this scope.
View
View
View
View
The Program Counter Security Model: Automatic Detection and Removal of Control-Flow Side Channel Attacks
Conference Paper
Full-text available
  • Jul 2006
We introduce new methods for detecting control-flow side channel attacks, transforming C source code to eliminate such attacks, and checking that the transformed code is free of control-flow side channels. We model control-flow side channels with a program counter transcript, in which the value of the program counter at each step is leaked to an adversary. The program counter transcript model captures a class of side channel attacks that includes timing attacks and error disclosure attacks. Further, we propose a generic source-to-source transformation that produces programs provably secure against control-flow side channel attacks. We implemented this transform for C together with a static checker that conservatively checks x86 assembly for violations of program counter security; our checker allows us to compile with optimizations while retaining assurance the resulting code is secure. We then measured our technique’s effect on the performance of binary modular exponentiation and real-world implementations in C of RC5 and IDEA: we found it has a performance overhead of at most 5× and a stack space overhead of at most 2×. Our approach to side channel security is practical, generally applicable, and provably secure against an interesting class of side channel attacks.
View
A Tool for Estimating Information Leakage
Conference Paper
  • Jul 2013
We present leakiEst, a tool that estimates how much information leaks from systems. To use leakiEst, an analyst must run a system with a range of secret values and record the outputs that may be exposed to an attacker. Our tool then estimates the amount of information leaked from the secret values to the observable outputs of the system. Importantly, our tool calculates the confidence intervals for these estimates, and tests whether they represent real evidence of an information leak in the system. leakiEst is freely available and has been used to verify the security of a range of real-world systems, including e-passports and Tor.
View
Transforming Out Timing Leaks, More or Less
Conference Paper
  • Sep 2015
We experimentally evaluate program transformations for removing timing side-channel vulnerabilities wrt. security and overhead. Our study of four well-known transformations confirms that their performance overhead differs substantially. A novelty of our work is the empirical investigation of channel bandwidths, which clarifies that the transformations also differ wrt. how much security they add to a program. Interestingly, we observe such differences even between transformations that have been proven to establish timing-sensitive noninterfer-ence. Beyond clarification, our findings provide guidance for choosing a suitable transformation for removing timing side-channel vulnerabilities. Such guidance is needed because there is a trade-off between security and overhead, which makes choosing a suitable transformation non-trivial.
View
Handbook of Applied Cryptography
Article
  • Jan 1997
From the Publisher: A valuable reference for the novice as well as for the expert who needs a wider scope of coverage within the area of cryptography, this book provides easy and rapid access of information and includes more than 200 algorithms and protocols; more than 200 tables and figures; more than 1,000 numbered definitions, facts, examples, notes, and remarks; and over 1,250 significant references, including brief comments on each paper.
View
View
A Method for Obtaining Digital Signatures and Public-Key Cryptosystems
Article
  • Jan 1983
An encryption method is presented with the novel property that publicly re- vealing an encryption key does not thereby reveal the corresponding decryption key. This has two important consequences: 1. Couriers or other secure means are not needed to transmit keys, since a message can be enciphered using an encryption key publicly revealed by the intended recipient. Only he can decipher the message, since only he knows the corresponding decryption key. 2. A message can be \signed" using a privately held decryption key. Anyone can verify this signature using the corresponding publicly revealed en- cryption key. Signatures cannot be forged, and a signer cannot later deny the validity of his signature. This has obvious applications in \electronic mail" and \electronic funds transfer" systems. A message is encrypted by representing it as a number M, raising M to a publicly specied
View
View