specification and enforcement of information erasure...

MotivationA Language-Based Approach

IssuesSummary

Specification and Enforcement ofInformation Erasure Policies

Sebastian Hunt1 David Sands2 Filippo Del Tedesco2

1City University London

2Chalmers University of Technology, Sweden

The 12th CREST Open WorkshopSecurity and Code

April 2011

Sebastian Hunt, David Sands, Filippo Del Tedesco Information Erasure Policies

IssuesSummary

Outline

1 Motivation

2 A Language-Based Approach

3 Issues

IssuesSummary

Outline

1 Motivation

3 Issues

IssuesSummary

Why Erase?

Erasing sensitive information as soon as possible may givestronger security guarantees:

Erasure of identification tokens in e-voting.Erasure of credit card details on completion of transaction.Erasure of fingerprint data from a left-luggage locker.

IssuesSummary

End-to-End Information Flow Policies

We can’t guarantee to erase information if we don’t knowwhere it has gone.Access control is not enough: we need end-to-end flowpolicies and enforcement.Control of information-flow is necessary. . . is it sufficient?If we can guarantee that information doesn’t flow out of asystem, is there any need to erase it?

IssuesSummary

Keeping Your Memory Clean

IssuesSummary

Cold Boot Attacks

DRAM memory reverts to “ground state” when power isdisconnected, but this takes several seconds.

even longer if memory modules are cooled

Sensitive information residing in RAM can be stolen bycutting power and quickly rebooting into a custom kernel.[Halderman et al, 2008] recover disk-encryption keys

recover even partially degraded keys by exploitingprecomputations kept in RAM by encryption software

IssuesSummary

Cold Boot Attack Countermeasures

No silver bullet: keys must be stored somewhere.[Halderman et al, 2008]:

“Countermeasures begin with efforts to avoidstoring keys in memory. Software shouldoverwrite keys when they are no longer needed,and it should attempt to prevent keys from beingpaged to disk.”

Specific examples:Avoid precomputation; erase precomputed data if unusedfor a given time intervalObfuscate keys in RAM; recreate usable keys asnecessary, erase ASAP

IssuesSummary

Outline

1 Motivation

3 Issues

IssuesSummary

Erasure Policies

Example: credit card number should be erased aftertransactionTo erase contents of a variable, overwrite with a constant:

input cc from user;t := transaction(cc);output t to bank;cc := 0

Not enough to overwrite cc, must control flows from cc

⇒ Can use a flow-sensitive security type system.

IssuesSummary

Erasure Policies

IssuesSummary

Erasure Policies

IssuesSummary

Flow-sensitive Security Type System

Typing judgements: ` Γ {C} Γ′

Γ, Γ′ : Var → L (lattice of security levels)variable types given by Γ on entry to C, by Γ′ on exit

` Γ {x := E} Γ[x 7→ Γ(pc) t Γ(E)]

p = Γ(pc) Γ′ = Γ[pc 7→ p t Γ(E)] ` Γ′ {C} Γ′

` Γ {while E C} Γ

IssuesSummary

` Γ {x := E} Γ[x 7→ Γ(pc) t Γ(E)]

` Γ {while E C} Γ

IssuesSummary

` Γ {x := E} Γ[x 7→ Γ(pc) t Γ(E)]

` Γ {while E C} Γ

IssuesSummary

Block-Structured Erase

Basic idea: input a value x from channel i ; use freely withincommand C; erase x (and all information derived from x)by the time C completesGeneralise: erase to some level a

input x : i erase to a after C

Allows information to be used after C but only at the highersecurity level aComplete erasure captured by choosing a = #: a securitylevel higher than allowed for any variable

IssuesSummary

An Erasure Type System

` Γ[x 7→ p t Γ(i)] {C} Γ1 ` Γ[x 7→ p t a] {C} Γ2

p = Γ(pc) Γ′(y) =

{Γ1(y) if y ∈ OVarΓ1(y) t Γ2(y) otherwise

` Γ {input x : i erase to a after C} Γ′[i += p]

environments track flows between variables and on IOchannels (i ∈ IVar , o ∈ OVar )two typings for body: one for flows inside body, one forflows to rest of program

IssuesSummary

An Erasure Type System

p = Γ(pc) Γ′(y) =

environments track flows between variables and on IOchannels (i ∈ IVar , o ∈ OVar )two typings for body: one for flows inside body, one forflows to rest of program

IssuesSummary

Outline

1 Motivation

3 Issues

IssuesSummary

An Implementation Problem (Solved)Typing is Exponential

p = Γ(pc) Γ′(y) =

Double typing required for C.Nesting an input command inside C doubles the size ofthe derivation.⇒ Typing is exponential in the size of the program.

IssuesSummary

p = Γ(pc) Γ′(y) =

IssuesSummary

p = Γ(pc) Γ′(y) =

IssuesSummary

Solution: Principal Typing

` C : ∆ ∆j = ∆ ; η[x 7→ {pc, ij}] j = 1, 2

∆′(x) =

{∆1(x) if x ∈ OVar∆1(x) ∪∆2(x) otherwise

` input x : i1 erase to i2 after C : ∆′[i1 += {pc}]

(Note: “erased to” type now a variable.)Transformed type system which derives principal type ∆

all other typings can be calculated from ∆

Derivation size linear in size of C ⇒ polynomial typingalso extends to polynomial typing for procedures

IssuesSummary

Type System Too Weak; Erasure Condition Too StrongExample: Fingerprint Locker

input fp : reader erase to # after {locked := true;while (locked) {

input fpTry : reader erase to # after {locked := !match(fpTry, fp);fpTry := "";

}}fp := "";

Outer input is erasing; locked is always false on exit buttype system is too weak to verify thisInner input is not erasing; variation in locked, but weneed to allow this

IssuesSummary

}}fp := "";

IssuesSummary

}}fp := "";

IssuesSummary

Semantic Model Not Sufficiently ExpressiveExample: Special Offer Code

Soundness proof for type system based on a stream modelof the environment which cannot capture what is wrongwith this example:

input cc : user erase to # after {output specialOffer(cc) to user;t := transaction(cc);output t to bank;t := 0;cc := 0;

input special from user;cc := decrypt(special)

IssuesSummary

Semantic Model Not Sufficiently ExpressiveExample: Special Offer Code

Soundness proof for type system based on a stream modelof the environment which cannot capture what is wrongwith this example:

input cc : user erase to # after {output specialOffer(cc) to user;t := transaction(cc);output t to bank;t := 0;cc := 0;

input special from user;cc := decrypt(special)

IssuesSummary

Summary

Verifiable erasure guarantees are an essential aspect ofsecurity.Simple forms of erasure policy can be enforced atlanguage level by type systems.

Care needed to avoid exponential blow-up.

Richer semantic models needed to formalise more flexibleerasure policies.Smarter type system / theorem proving needed to verifythem.

specification and enforcement of information erasure...

Documents