STMicroelectronics - UNAM · STMicroelectronics PDE_UNAM_PRE_12_001 « On Using B to Design Secure MCU’s, M. Benveniste 2o12/03/14 2o12/03/14 On Using B in the Design of Secure

STMicroelectronics PDE_UNAM_PRE_12_001

« On Using B to Design Secure MCU’s, M. Benveniste 2o12/03/14

2o12/03/14

On Using B in the Design of Secure

Microcontrollers: An Experience Report

Marc BENVENISTE ([email protected])

STMicroelectronics

Secure Microcontrollers Division

Rousset, France

2

PDE_UNAM_PRE_12_001, On Using B in the Design of Secure MCU’s 2o12/03/14

STMicroelectronics



3


Secure Microcontrollers Division http://www.st.com/internet/mcu/family/143.jsp

USIM M2M SE NFC

TPM Brand

Protection

Embedded Security Mobile / Computer / Consumer

PayTV

Transport Identity

Personal Security Smartcards

SMD Market Focus

Banking

4

PDE_UNAM_PRE_12_001, On using B in the Design of Secure MCU’s 2o12/03/14

Chip Security is not (only) Design Correctness...

* BSI-PP-0035 version 1.0

Security IC Platform Protection Profile , by Eurosmart, 2007/06/15

*

http://images.google.fr/imgres?imgurl=http://img163.imageshack.us/img163/220/notion7ye.png&imgrefurl=http://www.clubic.com/forum/audio-mp3-home-cinema/debuter-avec-une-parabole-id112776-page1.html&h=137&w=350&sz=72&hl=fr&start=25&tbnid=5uwdM-j2TYBfqM:&tbnh=47&tbnw=120&prev=/images?q=canal++terminal&start=21&gbv=2&hl=fr&sa=N

http://www.kalysis.com/content/images/nationalID.jpg



5


Chip Security (only) builds on Design Correctness

• Accurate & complete documentation

• Exhaustive verification & validation

• ... the very least to start working on security

*

* http://www.hsconsortium.co.uk/workplacesafety.html

6


B to Design Secure Microcontrollers: An advanced R&D experience report

• The feasibility case study

• From correctness to robustness

• Algorithm verification: a diverted use

• Concluding remarks



7







8


MPU: Complete Programmable Access Control

• Memory Protection Unit: All accesses monitored

Various SIZES

MEMORIES

RAM

ROM

NVM

Key:

Optional

Modules Kernel

Modules

Controlled Resources

Contact Interface

CRYPTO MODULES

Various ALGORITHMS

MPU

µ-Processor CORE (CPU, Logical Functions &

Dedicated Firmware)

I/O MODULES

Various PROTOCOLS

http://images.google.be/imgres?imgurl=http://www.booze-cruise.net/images/passport.jpg&imgrefurl=http://www.booze-cruise.net/guidance.htm&h=202&w=214&sz=12&hl=nl&start=1&tbnid=mEkXlwxpRLzECM:&tbnh=100&tbnw=106&prev=/images?q=france+passport&svnum=10&hl=nl



9


MPU - Overview

• Segment: addressable window in memory, defined by • Start / End addresses

• A clearance level

• Access rights (Read, Write, eXecute)

• Active status (mapped, not mapped)

• Clearance level: privilege level of a program • A value in [Supervisor .. Public] (actually [0 .. 3])

• Each segment is given a clearance level

• Read & write access to peripheral registers are globally denied/granted for each clearance level

• Program clearance change control is enabled/disabled for each clearance level (call gates)

• Access control principles: code (eXecute) & data (Read/Write) controls • A program can enforce clearance change control based on current and previous program clearance levels

• All needed data for a given program must be located in its own clearance (or Public data) segments

10


A complex flow...

Design & RTL Coding in HDL

Synthesis

Scan Chains Insertion (DFT)

Layout

Clock Tree & Routing

Model Checking

(Equivalence)

Model Checking

(Equivalence)

Functional

Simulation

Preliminary Static

Timing Analysis

Post Layout

Timing Analysis

Back-Annotated

Simulations

Netlists + Constraints

Netlists + Constraints

Netlists + Layout

Netlists + Delays

Model Checking

(Equivalence)



11


Source HDL Classical Development Flow

Implementation

Specification

Functional

Specification

Gate Level

Representation

Verification

Specification

Interface

SpecificationData Sheet

VHDL

"hand made"

Sim

ula

tio

ns

RTL

Representation

Autotesting

Binaries

Compiling

Compiling

Synthesis

Test Plan &

Programs

Ve

rifica

tio

n

Ca

mp

aig

n

12


New Proved Source HDL Development Flow

Functional

Specification

Gate Level

Representation

Verification

Specification

Property Level

Model

Adding Details

Architecture

Level Details

Interface

SpecificationData Sheet

Implementation

Level Details

Real Interface Generated

VHDL

Sim

ula

tio

ns

B4SYN

RTL

Representation

Autotesting

Binaries

Compiling

Test Plan &

Programs

Parameter Values

(Constants)

Ve

rifica

tio

n

Cam

pa

ign

Compiling

Synthesis

Abstraction

Proof

Obligations

Event B

(System Modeling)



13


Initial (Simple) Models

a0

d0

t0

v0

c0

R0

r0

a

...

t

...

...

...

... ...

......

c d

RESET/POR

m0=0

m0=1

m0=2

RESET/POR

PHI

ACCESS

RESET/POR

RESET/

POR

PSI

14


Final (Complex) Models

Addr

In

Ctrl

Clk

Viol

Out

Reset/BadPower

Segment Rights 0

Segment Rights 1

Segment Rights 2

Segment Rights 3

Segment Rights 4

Segment Rights 5

Segment Rights 6

Segment Rights 7

Segment Rights 8

Segment Rights 9

Segment End Address 0










Segment Start Address 0










Unmapped W ProtReg

OverX R X CGate Underflow

Lock Overflow

LockRd2Rd3

Rd1 Rd0

Cg2Cg3

Cg1 Cg0

Current Previous



15


Observations on resulting implementation

• Built static structure is quite complex

~60 constants, ~50 variables

Just imagine if verification had to start at this (RTL) level ! What would you verify ?

• A lot of individual cases 56 events

• Although very simple cases ~12 lines each

• Built with proved exhaustive assurance of: • Correctness: no contradiction regarding all specified behaviors

• Determinism: no overlapping specified behaviors

• Completeness preservation: no development holes

16


Trying a rough comparison

Criteria Classical Flow Experimental Flow

Effort person.days

~145 ~145

(~200 translator)

Volume commented source lines

~3 600 VHDL ~7 500 B

~3 500 VHDL

Proof

number of items

- ~1 600 obligations

~ 600 with ~4000 cmds

Structure module number

~15 tightly linked 4 loosely linked (only 1 generated module)

Simulation RTL & gate level

~30 patterns Ok ~30 patterns Ok

(better debug signals)

Size equivalent nand gates

~5 Kgates



17


Benefits & drawbacks

• Benefits

• Zero bug macros become feasible

• Highly parameterized coding is encouraged

• Focus can safely turn onto security concerns

• Drawbacks • No composition mechanism to assemble units

• Not yet ready for industry (both method & tool)

• Future work • Extend to other case studies

• Propose language support enhancements

18









19







20


Vulnerable ICs



21


• B variables store their assigned values…

[ x ≔ c ]

• …But faulty flip-flops may loose them

[ x ≔ c ]

[ x ∶∊ T ]

B semantics and the real world

⋢ breaking

correctness refinement ⊑

22


Counter-measures are functions, so…

• Start with an “equipped” system

R0 ≙ [ x ≔ c ; e ∶∊ BOOL ]

• Specify your counter-measure

CM ≙ ( x = r-1(y) ⋁ e = TRUE)

[ x ≔ c ] ⊑ [ x ≔ c ∥ y ≔ r(c) ]

[ e ∶∊ BOOL ] ⊑ [ e ≔ bool( x ≠ r-1(y) ) ]

• Refine the system with counter-measure

R0 ⊑ [ ( x ≔ c ∥ y ≔ r(c) ) ; e ≔ bool( x ≠ r-1(y) ) ] ≙ R1



23


…what about CM effectiveness ?

• Choose your fault model

INV ≙ ( f = 0 ⇒ x1 = x ⋀ y1 = y ⋀ e1 = e )

CM[ x1,y1,e1/x,y,e ] ≙ ( x1 = r-1(y1) ⋁ e1 = TRUE)

[ ( x1 ∶∊ T ∥ f ≔ 1 ) ⌷ ( x1 ≔ c ∥ f ≔ 0 ) ]

• Refine your “robust” system with fault injection

R2 ≙ [

( ( x1 ∶∊ T ∥ f ≔ 1 ) ⌷ ( x1 ≔ c ∥ f ≔ 0 ) ∥ y1 ≔ r(c) )

; e1 ≔ bool(x1 ≠ r-1(y1) )

]

• Prove CM effectiveness R1 ⊑INV ⋀ CM R2

24


Benefits & drawbacks

• Benefits

• Security can become functional

• Separation of correctness vs. effectiveness

• Drawbacks • No systematic process

• No sound theory exhibited

• Future work • Extend to other case studies

• Propose language support enhancements



25







26









27


What is DPA / CPA?

M0

M1

.

.

.

Mn

M0, M1, ..., Mn

M0

M1

.

.

.

Mn

Hi = 0

Hi = 1

ki

-

k0

k1

k2

k3

k4

k5

k6

a)

b)

28


Security properties

• Defining properties is necessary for

• Guidance during design and implementation

• Proof work

• Example of security property

• “Any value depending on both the input message and the key must be masked with a random”

• Design according to security properties



29


Example of vulnerability

• If Mux selection is incorrect, information leaks

• Security property is broken

D1 m1

+

Mux

0 D2 m2

Op

Op(D1 m1 , D2 m2)

D1

m1

30


DPA focus on mux vulnerability (1/4)

• Values in algorithm become dependencies in model

• Algorithm steps update dependencies in model

• reg_d := mux_out m1 → d_reg_d := d_mux_out – {m1}

D1 m1

+ Mux

0 D2 m2

Op

Op(D1 m1 , D2 m2)

D1

m1 -

U

{ D1, m1 }

Mux

{} { D2, m2 }

{ D1, D2, m1, m2 }

{ }

{ m1 }

reg_d

mux_out

d_reg_d

d_mux_out



31


DPA focus on mux vulnerability (2/4)

• Security property is a condition on dependencies • “Any value depending on both the input message and the key must be masked with a random”

• “D1 and D2 are never unmasked”

• SECRET = { {D1}, {D2}, {D1, D2} }

• SECRET ∩ { d_reg_d, d_reg_1, d_reg_2, d_reg_r } = { }

D1 m1

+ Mux

0 D2 m2

Op

Op(D1 m1 , D2 m2)

D1

m1

reg_d

mux_out

-

U

{ D1, m1 }

Mux

{} { D2, m2 }

{ D1, D2, m1, m2 }

{ }

{ m1 }

d_reg_d

d_mux_out

d_reg_2 d_reg_1

d_reg_r

32


Check that the property always holds… (3/4)

{ D1, m1 }

-

Mux

{ } { D2, m2 }

U

{ D1, m1 , D2, m2 }

{ }

{ m1 }

d_reg_d

d_reg_1 d_reg_2

d_reg_r

d_mux_out



33


…or show a counter-example (4/4)

{ D1, m1 }

+

Mux

{ } { D2, m2 }

U

{ D1, m1 , D2, m2 }

{ D1 }

{ m1 }

d_reg_d

d_reg_1 d_reg_2

d_reg_r

d_mux_out

LP

34


Formal verification of the design

• Benefit

• Provides high confidence that the algorithm fulfills the security properties

• Limitation: it’s necessary but not sufficient

• Proves only the defined security properties

• Proves the algorithm satisfies them but not the implementation



35







36









37


Concluding remarks

• Correctness

• Zero bug macros become feasible

• Highly parameterized coding is encouraged

• Robustness • No systematic process to functional treatment

• No sound theory defined

• Confidentiality • Articulation with other techniques required

• Proposals awaited from research community


Credits & Acknowledgement

The FORmal CO-developMENT & Biop@ss Projects

B Models : B4SYN Translator: Screenplay, Direction & Realization : Support Design :

L. Mussat, Clearsy T. Lecomte & A. Requet, Clearsy

M. Benveniste, STMicroelectronics D. Chomaud, STMicroelectronics



Thank You !

Any Question?

BACKUP SLIDES

Use only in case of emergency



41


41


What’s an Event B System ?

• An observation contract over a state space

• State space:

• the set of all valuations of a given set of typed variables

• Observation contract:

• if the system reaches a point where the invariant holds, then all observable transitions of the system are kept within this invariant subspace

• Invariant:

• logical condition statement about the system variables

• Observable transition:

• labeled guarded event fired infinitely often when open

42


42

2o12/03/14

What’s an Event B Refinement ?

• A change of observation space preserving bound contracts

• State Space usually expands as the represented system becomes more

precisely defined

• Observable transitions can be split or joined according to description needs:

• stretching observation or folding behaviors, for instance

• If “allow” refines “access”, then:

• “allow” occurs at most as often as “access”

(guard strengthening)

• “allow” preserves the expanded invariant

(everlasting contract)

• “allow” doesn’t do something “access” would not do

(no contradiction)



43


Refining State & Behavior in sync... (1/6)

r0

a c d

...

t

...

...

...

... ...

......

R0

ALLOW DENYRESET/

POR

ACCESSRESET/

POR

44



r0

a c d

...

t

...

...

...

... ...

......

R0

ACCESS

ALLOW DENY

RESET/

POR

RESET/

POR

RESET/

PORREAD



45



tR

rr1

a c

... ...

... ...

r0

a c d

...

t

...

...

...

... ...

......

R0

RR1

ACCESS

ALLOW DENY

RESET/

POR

RESET/

POR

RESET/

PORREAD

Let’s take a closer look at this event...

46



tR

rr1

a c

... ...

... ...

r0

a c d

...

t

...

...

...

... ...

......

R0

RR1

ACCESS

ALLOW DENY

RESET/

POR

RESET/

POR

RESET/

PORREAD

REFINEMENT

mpu02

...

EVENTS

...

; read

ref allow

=

SELECT

m0 = 2

& t0 = TyR

& a0 |-> c0 : rr1

THEN

m0 := 0

|| v0 := FALSE

END



47



tR

rr1

a c

... ...

... ...

r0

a c d

...

t

...

...

...

... ...

......

R0

RR1Ds

ACCESS

ALLOW DENY

RESET/

POR

RESET/

POR

RESET/

PORREAD

48



rr1

a c

... ...

... ...

r0

a c d

...

t

...

...

...

... ...

......

rw1

a c d

... ...

...

... ... ...

rx1

a c

... ...

... ...

rb1

a c

... ...

... ...

re1

a c

... ...

... ...

R0

RR1 RW1 RX1 RB1 RE1

ACCESS

ALLOW DENY

RESET/

POR

RESET/

POR

RESET/

PORREAD WRITE FETCH IACK IRET DENYNONE



49



tR tW tX tB tE tN

rr1

a c

... ...

... ...

r0

a c d

...

t

...

...

...

... ...

......

rw1

a c d

... ...

...

... ... ...

rx1

a c

... ...

... ...

rb1

a c

... ...

... ...

re1

a c

... ...

... ...

R0

RR1 RW1 RX1 RB1 RE1

Ds Ds Ds Ds Ds

As Cs

ACCESS

ALLOW DENY

RESET/

POR

RESET/

POR

RESET/


50


Let’s Refine

REFINES mpu00

...

; allow ref access =

SELECT

m0 = 2

& a0 |-> c0 |-> d0 |-> t0 : r0

THEN

m0, v0 := 0, FALSE

|| c0 :: CLs

|| r0 :: ADs * CLs * BYs <-> TYs

END

; deny ref access =

SELECT

m0 = 2

& a0 |-> c0 |-> d0 |-> t0 /: r0

THEN

m0, v0 := 0, TRUE

END

SYSTEM

mpu00

...

EVENTS

...

; access =

SELECT

m0 = 2

THEN

m0 := 0

END

⊑



51


“allow” Refines “access”

REFINES mpu00

...


SELECT

m0 = 2

& a0 |-> c0 |-> d0 |-> t0 : r0

THEN

m0, v0 := 0, FALSE

|| c0 :: CLs


END

; deny ref access =

SELECT

m0 = 2

& a0 |-> c0 |-> d0 |-> t0 /: r0

THEN

m0, v0 := 0, TRUE

END

SYSTEM

mpu00

...

EVENTS

...

; access =

SELECT

m0 = 2

THEN

m0 := 0

END

⊑ ⇐

52


“deny” Refines “access”

REFINES mpu00

...


SELECT

m0 = 2

& a0 |-> c0 |-> d0 |-> t0 : r0

THEN

m0, v0 := 0, FALSE

|| c0 :: CLs


END

; deny ref access =

SELECT

m0 = 2

& a0 |-> c0 |-> d0 |-> t0 /: r0

THEN

m0, v0 := 0, TRUE

END

SYSTEM

mpu00

...

EVENTS

...

; access =

SELECT

m0 = 2

THEN

m0 := 0

END

⊑ ⇐



53


Refinement is not enough...

REFINES mpu00

...


SELECT

m0 = 2

& a0 |-> c0 |-> d0 |-> t0 : r0

THEN

m0, v0 := 0, FALSE

|| c0 :: CLs


END

; deny ref access =

SELECT

m0 = 2

& a0 |-> c0 |-> d0 |-> t0 /: r0

THEN

m0, v0 := 0, TRUE

END

SYSTEM

mpu00

...

EVENTS

...

; access =

SELECT

m0 = 2

THEN

m0 := 0

END

⊑

m0 = 2 &

not( a0 |-> c0 |-> d0 |-> t0: r0 ) &

m0 = 2 &

a0 |-> c0 |-> d0 |-> t0: r0 &

"`Check refinement exclusivity - companion model'“

=>

bfalse

54


...exclusive refinement is still not enough...

REFINES mpu

...


SELECT

m0 = 2

& a0 |-> c0 |-> d0 |-> t0 : r0

THEN

m0, v0 := 0, FALSE

|| c0 :: CLs


END

; deny ref access =

SELECT

m0 = 2

& a0 |-> c0 |-> d0 |-> t0 /: r0

THEN

m0, v0 := 0, TRUE

END

SYSTEM

mpu

...

EVENTS

...

; access =

SELECT

m0 = 2

THEN

m0 := 0

END

m0 = 2 &

not( m0 = 2 & not( a0|-> c0|-> d0|-> t0: r0 ) ) &

"`Check refinement liveness - companion model'"

=>

a0 |-> c0 |-> d0 |-> t0: r0

⊑ ⇐ ⇒



55


...now we can be confident it’s all there...

REFINES mpu00

...


SELECT

m0 = 2

& a0 |-> c0 |-> d0 |-> t0 : r0

THEN

m0, v0 := 0, FALSE

|| c0 :: CLs


END

; deny ref access =

SELECT

m0 = 2

& a0 |-> c0 |-> d0 |-> t0 /: r0

THEN

m0, v0 := 0, TRUE

END

SYSTEM

mpu00

...

EVENTS

...

; access =

SELECT

m0 = 2

THEN

m0 := 0

END

⊑ ⇔

56


56

2o12/03/14

Refine by “squeezing” events

ACCESS

ALLOW DENY

RESET/

POR

RESET/

POR

TRUE

RESET/


Refinement, Liveness et Exclusivity:

Localized properties, stepwise provable, hence simplified



57


The Refinement Plan (1/3)

N° Step Main Purpose

1 Host_1 Host execution model

2 Complete Policy Abstract complete access policy

3 Split Access Rights matrix split for each access type

Allow cases split by access type

4 Exceptions By-passing checks automata

Interrupts & reset management

5 Split Deny Deny cases split by access type

Clearances stack introduced (interrupts)

6 Registers_1 Registers access policy (mem. vs. reg.)

Supervisor clearance introduced

Implementation

Policy

Specification

58


The Refinement Plan (2/3) N° Step Main Purpose

7 Data Data access policy

Public clearance introduced

8 Code Code access policy, Call gates introduced

9 Segments_1 Segments as sets of addresses

Constructive set expressions defined

10 Alarms_1 Identification of denied accesses

Alarm bits introduced

11 Alarms_2 Denied access cases grouped by alarm

12 Segments_2 Segments as address ranges (start & end)

Mapped segment bit introduced

13 Registers_2 MPU register access policy

Their symbolic addresses introduced

Implementation

Policy

Specification



59


The Refinement Plan (3/3)

N° Step Main Purpose

14 Segments_3 Segments granularity

Implementation optimization

15 Registers_3 MPU registers effective read, Output defined

Constant read access functions

Symbolic addresses are bytes now

16 Registers_4 Effective write of MPU registers

Constant write access functions

17 Host_2 Physical interface for meaning (access type)

All input cases covered, sampling on “tick”

18 Translate Expression simplifications for VHDL

Prop. not translated, types drive translator

Implementation

Policy

Specification

60


60

2o12/03/14

Event & Variables Build up Graph

0

10

20

30

40

50

60

70

Hos

t_1

Com

plete

Polic

y

Spl

it Acc

ess

Exc

eptio

ns

Spl

it Den

y

Reg

iste

rs_1

Dat

a

Cod

e

Seg

men

ts_1

Ala

rms_

1

Ala

rms_

2

Seg

men

ts_2

Reg

iste

rs_2

Seg

men

ts_3

Reg

iste

rs_3

Reg

iste

rs_4

Hos

t_2

Trans

late

Refinement steps

Nu

mb

er

of

Impacted Events Events Variables Constants

*

* Steve Wright in

“Quite Big Model Presentation”

Rodin Workshop, 2009/07/17



61


61

2o12/03/14

Proof Obligations Build up Graph

0

50

100

150

200

250

300

350

400

Hos

t_1

Com

plete

Polic

y

Split Acc

ess

Excep

tions

Split Den

y

Reg

iste

rs_1 D

ata

Cod

e

Segm

ents_1

Alarm

s_1

Alarm

s_2

Segm

ents_2

Reg

iste

rs_2

Segm

ents_3

Reg

iste

rs_3

Reg

iste

rs_4

Hos

t_2

Trans

late

Refinement Steps

Nu

mb

er

of

Pro

ved

Ob

lig

ati

on

s &

In

tera

cti

ve

Pro

ver

Co

mm

an

ds

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Perc

en

tag

e o

f A

uto

mati

c P

roo

f

Auto User % Auto Commands

62


62

2o12/03/14

Proof Obligation Breakdown Graph (1/2)

85 34 20 75 62 18 26 50 27 18 28 45 60 55 69 374 41

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

POs

Contributions by Refinement Step

Host_1 Complete Policy Split Access Exceptions Split Deny Registers_1 Data

Code Segments_1 Alarms_1 Alarms_2 Segments_2 Registers_2 Segments_3

Registers_3 Registers_4 Host_2 Translate



63


63

2o12/03/14

Proof Obligation Breakdown Graph (2/2)

3531109 141

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

POs

Contribution by Models

Refinement main column Exclusivity companion Liveness companion

64


Example of protection – start of DES round

D1 m1

+

Expansion

E(D1) m2

m2

32

48 E(D1 m1) = E(D1) E(m1)

48

+

E(D1) E(m1) m2

E(m1) 48

48

Calculation with masked data

Drift linked to mask is controlled throughout

the calculation

Documents

STMicroelectronics - UNAM · STMicroelectronics PDE_UNAM_PRE_12_001 « On Using B to Design Secure MCU’s, M. Benveniste 2o12/03/14 2o12/03/14 On Using B in the Design of Secure