Detecting Hardware Trojans in Unspecified Functionality Usi - PowerPoint Presentation

Slide1

Detecting Hardware Trojans in Unspecified Functionality Using Mutation Testing

Nicole FernK.-T. Tim ChengUC Santa Barbara

1Slide2

Main Contributions

Information leakage Trojan only modifying unspecified functionalityMutation testing based detection methodDiscovered vulnerabilities and verification holes in UART design with sophisticated

testbench

2Slide3

Hardware Trojans

Malicious circuitry inserted in the hardware designCan be inserted by any party with access to the design!Goals: leak information, induce faults, chip failure, gain root privileges, etc.

3Slide4

Trojan Classes

The logic functions of some design signals are altered, system specifications are violatedThe Trojan leaks information through side-channelsThe logic functions of

only those design signals which have unspecified behavior are altered to add malicious functionality

without violating system specifications

4Slide5

FIFO Example

What is the value of read_data when read_en is 0?

5Slide6

Threat Model

Trojans can be inserted in the RTL and all subsequent design stagesOur method analyzes RTL code, identifies Trojans which leak information from the circuit by hiding in unspecified functionality Behavior of circuit under Trojan activation condition is

unspecified and unverifiedTrojan can be active frequently, yet go undetected!

6Slide7

Detection Methodology Overview

Goal: design independent method to identify dangerous unspecified functionality Use mutation testing to uniformly sample possible design modifications (can think of as very simple Trojan modifications)Use additional information to determine if modification is “dangerous”

7Slide8

Mutation TestingBasic Idea

: If the testbench cannot detect an artificial error, testbench likely incapable of detecting a real error

8

DUT

Tests

Checker

Detected

Undetected

Add more tests

FixSlide9

Mutation Testing

Used in software domain since the 1970’s to test program correctness Can also identify security weaknesses 1,2 Used in hardware domain for testbench qualification

3,4Long simulation runtime and manual effort required for mutant analysis are drawbacks

Jia and Harman. An analysis and survey of the development of mutation testing. TSE, 2011.

Breech et al. An attack simulator for systematically testing program-based security mechanisms. ISSRE, 2006.

Bombieri

et al. Functional qualification of TLM verification. DATE, 2009.

Lisherness

et al.

Mutation Analysis with Coverage Discounting. DATE, 2013.

9Slide10

Interpreting Undetected Faults

2 Classifications:Affect Poorly Tested Functionality

Ex. Interrupt line set to static 0Redundant Fault: does not affect design functionality

Ex. for (int

i

= 0;

i

< 10;

i

++)

Ex. Adder output toggled only during intermediate cycles

10

Coverage Discounting: automated analysis to identify Class 1 faults

Lisherness

et al. Mutation Analysis with Coverage Discounting. DATE, 2013

.

!=Slide11

Identifying Dangerous Faults

Attacker-observable signals:

primary outputs, software-visible registers, network interface, bus interface,…Information leakage possible if

undetected fault causes change in attacker-observable signals

11

if

(

key)

{

code w/ fault;

}

else

{

original code;

}

key

0

1

0/1

1

/

0

Attacker-observable signalSlide12

Dangerous Unspecified Functionality

Undetected Fault Classes:Affect Poorly Tested Functionality

Ex. Interrupt line set to static 0Redundant Fault: does not affect design functionality

Ex. for (int

i

= 0;

i

< 10;

i

++)

Ex. Adder output toggled only during intermediate cycles

12

!=

Undetected Fault Classes

:

Affect Poorly Tested Functionality

Ex. Interrupt line set to static 0

Affect

attacker-observable

signals, but

not

design functionality

Causes no

change

in

any

signal values (truly redundant)

Automated method to identify only dangerous Class 2 faultsSlide13

Trojan Detection Methodology

13

DUT

Tests

Checker

Detected

Undetected

Add more tests

Fix

Before Fault Injection

Record functional coverage

Record attacker-observable signals

Functional coverage differs?

Fault affects poorly tested specified functionality

Attacker-observable signals differ?

Fault affects dangerous unspecified functionality

Refine SpecificationSlide14

Poorly Tested Specified v.

Dangerous Unspecified Functionality

Redundant

14Slide15

Methodology Applied to FIFO Example

What is the value of read_data when read_en is 0?

Fault is

undetected

Causes changes in

attacker-observable

signal

read_data

!

15

||Slide16

Fault Ranking MechanismMight be too expensive to analyze all faults classified as dangerous

Ideal to identify and fix functionality related to the “most dangerous” faults firstQuantities easy to measure for each fault:Number of attacker-observable bits differing

Total time attacker-observable signals differ Number of distinct

tests producing differences in attacker-observable signals

16Slide17

UART Controller Case Study

OpenCores IP, OVM testbench from EDA vendorVerification Infrastructure: 80 tests, 846 coverpoints

Mutation Testing: 1183 total faults injected110 faults not detected

32 caused differences in attacker-observable signals4 discounted coverpoints

UART

w

b_dat_o

i

nt_o

wb_ack_o

b

aud_o

s

tx_pad_o

r

ts_pad_o

dtr_pad_o

Output signals going to main processor

Output signals for serial data transmission

17

38 attacker-observable bitsSlide18

Wishbone Bus Trojan

Analyzed 3 most dangerous faultsAll affect bus between UART and main processorAll affect output enable signal for data busInformation can be leaked on data bus if a valid read transaction is NOT occurring!

UART

w

b_dat_o

i

nt_o

wb_ack_o

b

aud_o

s

tx_pad_o

18

r

ts_pad_o

dtr_pad_oSlide19

Wishbone Bus Trojan

The 3 Undetected Faults:

Write enable is de-asserted (read transaction)

Slave is selected

Valid bus cycle in progress

|

|

|

Undetected Faults changing & to |

19Slide20

Wishbone Bus Trojan

Data can be leaked on wb_dat_o whenever all 4 conditions for a valid read transaction are not simultaneously met!

|

We will leak data when

wbstate

==01

but not during a

valid

read transaction

20Slide21

Improving Bus CheckerData during invalid bus cycle, or output data

during write cycles was not checkedNew assertion added: value of wb_dat_o cannot change unless design has been reset or read request is being acknowledgedNew check detects 3 faults and bus Trojan

21

Method able to highlight unspecified functionality in on-chip bus protocols allowing attacker to leak information using the system bus Slide22

Interrupt Functionality

5 possible interrupt sources, 1 interrupt bit Next most dangerous fault causes int_o to become X for many cycles during 49 of 80 tests!Attacker can spuriously change

int_o to encode information

UART

w

b_dat_o

i

nt_o

wb_ack_o

b

aud_o

s

tx_pad_o

22

r

ts_pad_o

dtr_pad_oSlide23

Why was this fault undetected?Interrupt Identification Register (IIR) reveals source of interrupt

For all 5 events which cause interrupts, testbench checks that IIR is properly set, and that int_o is set within 10 cyclesDue to a

bug in the testbench if int_o

is X this check is skipped!23Slide24

Interrupt Functionality

Functional coverage did not change, suggesting that the coverage model is insufficient!

24

Method able to highlight verification hole relating to specified interrupt functionalitySlide25

Conclusions

Illustrated how unspecified functionality can be altered for malicious purposes Automated analysis methodology:Uncovered Trojan leaking information through unspecified functionality in a standard bus protocol

Identified verification hole for interrupt functionality

25Slide26

Questions?

26Slide27

Payload violates Design Specification

Relies on rare triggering conditions Detection likely if triggered during verification/testingDetection methods identify “almost unused logic” Ex. When specific 128-bit plaintext value appears, dump key bits to output

Payload operates completely within unspecified functionality

Design behavior unspecified

for activation conditions

Likely

not

detected if triggered during testing

F

unctionality Trojan modifies is

unspecified

and

unverified

Activation condition can occur frequently during testing (ex.

read_en

== 0)

27

Comparison of Trojans in Logic DomainSlide28

Coverage Discounting

DUT

Tests

Checker

Detected

Undetected

Add more tests

No

Yes

Fix

Coverage

Changed?

28