How to Cook a Secure Semantics

cornawakeΛογισμικό & κατασκευή λογ/κού

4 Νοε 2013 (πριν από 3 χρόνια και 5 μήνες)

68 εμφανίσεις

How to Cook a Secure Semantics

Mohammad Mousavi

TU/Eindhoven



SOS 2010, Paris


(Based on joint work with
Doaa

Hassan, Michel Reniers and Jerry den Hartog)

Outline


Motivation


Warming up: A toy language


Language
-
Based Security


Extension to Delegation and Revocation


Secure Flow Properties


Conclusions


Motivation

Revocation


Alice visits a bookshop and

buys a gift for Carol


Alice authorizes Bob (the Shopkeeper)
to access her credit card information


the purchase transaction is completed
and Alice leaves the shop


Bob tries to use Alice’s credit card
information to buy a Rolex watch

4

Restricted Delegation


Bob (the patient) visits Alice (the physician)


Bob gives Alice access to his clinical record


Bob agrees to give Chuck (the specialist)
access if Alice deems necessary


Alice delegates her access permission

to Chuck


Chuck delegates his permissions to

the insurance company

5

Our Order of Business

Understand
semantic
issues involved in
programming
languages for



guaranteeing
end
-
to
-
end
information flow
security



allowing for
restricted delegation
and
revocation

6


Semantics

8

Mathematicians are like Frenchmen;

whatever you say to them

they translate it into their own language

and forthwith it is something totally different.


Goethe


9

Syntax

Semantic Domain

Semantics

Syntax and Semantics

Multiple Levels

Mathematical Objects
→ Formal Semantic

(e.g., Sets, Relations,


Lists, Functions)


A Simple Programming Language


Prog

::=
VarDecl
* Statement*


VarDecl

::= Type
Var

[
=

Val]
;



Statement ::=
Var

=

Exp ;|





if

Exp
then

Body
else

Body
fi

;




while

Exp
do

Body
od

;




10

11

Operational
Semantics: Big Step



,
T x c v v x c
   


,
x e v v x v e
  
 
 
,´,´
,
P v v Q v v
PQ v v

  

  
Assumption: Variables are properly declared before use.

12

Operational
Semantics: Big Step





Q v v
v b false
b P Q v v
 

       
if then else fi




P v v
v b true
b P Q v v
 

       
if then else fi
13

Operational
Semantics: Big Step



,,
,
P v v b P v v
v b true
b P v v
  
        


     
while do od
while do od


,
v b false
b P v v

     
while do od
14

Is My Semantics
Correct
?

Semantics:


is a definition;


is a choice;


can be counter
-
intuitive;


may have/lack interesting properties.



To build confidence:


Simulate Programs;


Prove Properties of the Semantics


Information Flow Security

Information
-
Flow Security


Confidentiality:

only good guys
learn

about
secrets



Integrity:

only good guys
influence trusted
content



Language
-
based security: guarantee security
by providing / analyzing
syntactic

constructs

See: A.
Sabelfeld

and A.C. Myers. Language
-
Based Information
-
Flow
Security. IEEE Journal on Selected Areas in Communications. 21(1), 2003.

16

Principals


Principals: Alice, Bob,
Employees, Managers


Have a
hierarchy
: Alice is
a manager, each
manager is an employee


Form a
lattice

by
defining their meet and
join

17

Policies


Policy: owner’s definition of confidentiality and
integrity


int

{Alice: Bob} x;

Alice is the owner and allows Bob to
read

x



int

{Alice :
!
Bob} x;

Alice is the owner and allows Bob to

write
to x

(Alternatively: Alice is the owner and only
trusts

the values
written by herself or by Bob)


See: P. Li, Y. Mao and S.
Zdancewic
, Information Integrity Policies.
In Proc. of FAST 2003.

18

Labels


Labels: policies arranged in a lattice with join
and meet


int

{Alice: Bob, John} {Chuck: Bob} x;


Equipped with order


(“less restrictive than” ):


more readers for confidentiality


less writers for integrity


See: A. Myers and B.
Liskov
. Protecting Privacy using the
Decentralized Label Model. ACM TOSEM 9(4): 410
-
442, 2000.

ô
ò
19

What to Label


Values: define policies for data items



Variables: define policies for containers

Static vs. Dynamic Flow Analysis


Static: Check at
compile time
whether flow
conforms to policies


Efficient, but
over
-
estimates



Dynamic: Check at
run
-
time


Accurate (potentially), but has
overhead

A Simple Programming Language


Prog

::=
VarDecl
* Statement*


VarDecl

::= Type
Var

[
=

Val]
;



Label ::= Policy*


Policy ::= Principal [
:

([
!
]Principal)* ]


Statement ::=
Var

=

Exp
;

|





if

Exp
then

Body
else

Body
fi

;




while

Exp
do

Body
od

;




[
{
Label
}
]


Typical Issues in

Information
-
Flow
-
Sensitive Semantics


Assignment: the label of the assigning expression is more
restrictive than the static label of the assigned variable

bool

{
Alice:Alice
} x;

bool

{
Alice:Alice,Bob
} y;




y = x;



{
Alice:Alice
}

{
Alice:Alice,Bob
}

24

Operational
Semantics:

Big Step (explicit flow)







,
,,
L s
T x c v v x c
s x L
   






,
,,
s e s x
s
x e v v x
s
v e
  
 
 
ô s
,,,
,
,
,,,
,
P v v s Q v v
P v
s
s
v
s s
Q
s
   
  

 

  


25

Operational
Semantics: Big Step



,
,
,
,
,,
P v v
v b true
b
s s
Q v
s s
P v

 


       


if then else fi


,,
,
,
,,
Q v v
v b false
b P
s
v
s s
Q v
s

 


       


if then else fi
Typical Issues in

Information
-
Flow
-
Sensitive Semantics


Assignment: the label of the assigning expression is more restrictive
than the static label of the assigned variable


Conditional: check for implicit flows


bool

{Bob: Bob} x;

bool

{Alice: Alice} y;


if
x
then
y = true;
else
y = false;
fi
;











{Alice}



{Alice}

Solution: add a fictitious variable PC which:


-

is influenced by the condition


-

influences the body of conditional


See: 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 Proc. of
ICISC 2005.

PC {ᴛ}

PC {Bob}


{Bob}


{Bob}

27

Operational
Semantics:

Big Step (implicit flows)





,,,
,,,
PC s b
PC
P v s v s
v b true
b P Q v s v s
 
 

 
       
ò


if then else fi




,,,
,,,
Q v s v s
v b fal
PC s
se
b P Q v s v s
b
PC
 
 

 
       
ò


if then else fi
28

Operational
Semantics:

Big Step (implicit flows)







,,,

T x L c v s v x c s L
PC
x
   







,,,
x e v s v x v
s e PC s x
PC
e s
  
 
 
ò ô s

,,,,,,
,,,
P v s v s Q v s
PC PC
PC
v s
PQ v s v s
     
  
 
  
’ ’

29

Operational Semantics:

Big Step (implicit flows)





,,,
,,
,,,
P v s v s
b P v v s
v b true
b P v s v s
PC s b
PC
PC
 


  
     

 
     
ò



while do od
while do od


,,,
P
v b f
C
alse
b P v s v s

     

while do od
Typical Issues in

Information
-
Flow
-
Sensitive Semantics


Assignment: the label of the assigning expression is more
restrictive than the static label of the assigned variable


Conditionals: check for implicit flows


Loops: check for implicit flows / termination covert channel




bool

{Bob: Bob} x=true;

bool

{Alice: Alice} y=false;



while
x
do
x = true;
od

; y = true;

30

Typical Issues in

Information
-
Flow
-
Sensitive Semantics


Termination Covert Channel: Bad guys cannot learn about secret data
by
observing termination


Solution: Only allow for loops with the
maximal (least secret) label
in:


the
PC

and


the
condition





Weak termination covert channel: possible (non
-
)
termination
due to
secret

data does not lead to anything observable on the
public data


Solution: small
-
step semantics:
propagate
the updated PC along the
computation


31

32

Is My Semantics
Correct
? (Recap)

Semantics:


is a definition;


is a choice;


can be counter
-
intuitive;


may have/lack interesting properties.



To build confidence:


Simulate Programs;


Prove
Properties of the Semantics


Non
-
Interference

Changing the
initial secret data
does not influence

the
final public data





0 1
0 0 0 1
1 1
,,,
,,,
label
label
v v
P v s v s v v
P v s v s
 
 
 
   
    
 
 
 

 


33


Termination
-
Sensitive

Non
-
Interference

Changing the
initial secret data
does not influence

the
termination
and the
final public data





0 1
0 0
1 1
0 1
,,,
,,,
label
label
v v
P v s v s
P v s v s
v v
 
 

 
 
 
 
 
 
 
  

 
 
 
 
 



34


Theorem

Our semantics is secure:

if P can make a big step, then it is non
-
interfering



35


Type Systems for Information
-
Flow

:

:
x L PC e L
PC x e
 
 
ò
’ ’ e



PC P PC Q
PC P Q
 

’ ’



:

b L PC L P PC L Q
PC b P Q
  
      
ò ò
’ ’ ’

if then else fi


:
b L PC L P
PC b P
 
    
’ ’

ò
while do od
36


Theorem

If P is well
-
typed, then it can make a big step.

What about only if?

37

bool

{Bob: Bob} x=true;

bool

{Alice: Alice} y=false;

if
x
then
x = 0

else
x = y;
od

;

Delimited Information Release


Delegation and Revocation

Introducing Delegation and Revocation


Prog

::=
VarDecl
* Statement*


VarDecl

::= Type
Var

[
{
Label
}
]

[
=

Val]
;



Label ::= Policy*


Policy ::= Principal [
:

([
!
]Principal)* ]


Statement ::=
Var

=

Exp
;

|





if

Exp
then

Body
else

Body
fi

;




while

Exp
do

Body
od

;




Principal
delegates
Var

(
?

|
!
|(
?,!
) ) Chain
;





Principal
revokes

Var

(
?
|
!

|(
?,!
) ) Chain
;



Chain ::= Principal | Principal


Chain

40

Semantics of Delegation


Add dynamic labels: how far the delegation chain (for each
owner) has reached



Alice delegates x ? Bob
-
> Chuck


Alice : Bob
-
> Chuck





Bob delegates x ? Chuck


0

1

41

42

Operational
Semantics:

Big Step (delegation)

?,,
,
( ( )) ( ) ( ) (,1)
,
,[ ( ) (,1)]
PC p x
p owners s x PC s x d x p c
d
d x
c v s
v s
d x p c
    
 

 

 

ô ó

delegates
See: N. Swami, M. Hicks, S.
Tse
, and S.
Zdancewic
. Managing Policy Updates
in Security
-
Typed Languages. In Proc. of CSFW 2006.



1
',,0 1
0
0
(,)
?,
( ) ( )
( ) ( )\(,) (,1)
,
,[ ( )\(,) (,1)]
,
,
c i c
PC
c c p c c c i d x c i p
PC s x d x c i c p c i
d
d x d x c
p x c v s
v s
i c p c i
    
 

  
       

 

 
ô ó

delegates
Typical Issues in

Information
-
Flow
-
Sensitive Semantics


Assignment: the
join
of the static and
dynamic

label of the
assigning expression is more restrictive than the join of the static
and dynamic label of the assigned variable

43

44

Operational
Semantics:

delimited information release

(first attempt)







,,,
,,
s e PC s x
PC x e v s v x
d
e s
d
v
  
 
 
ò ô s









( ) ( )
,,
,,,
d e d x
s e PC s x
PC x e v s v x v
d
e s
d
  
 
 
ó ó
ò ô

Typical Issues in

Information
-
Flow
-
Sensitive Semantics


Assignment: the
join
of the static and
dynamic

label of the
assigning expression is more restrictive than the join of the static
and dynamic label of the assigned variable

45

bool

{Bob: Bob} x=true;

bool

{Alice: Alice} y=false;

bool

{Chuck: Chuck} z=true;



Alice
delegates
y ? Bob

x = y;

Bob
delegates
x ? Chuck

z = x;


46

Operational
Semantics:

delimited information release

(second attempt)







,,,,
,
,
,
s e PC s x
PC x e v s d v x v e s
i i
d
  
 
 
ò ô s











,
,
( ) ( )
,,,
,,
[ ( )]
i
s e d e PC s x d x
PC x e v s d
v x v e s d
i x s e d e

  

 
 
ó
ó ò ô ó

47

Operational
Semantics:

Big Step (delegation
-
revisited)



( ( )) ( ) ( ) (,1)
?,,,
,,[
( ) (,
( ) (,1)]
1)
,
,
p owners s x PC s x d x p c
PC p x c v s d
v s d x d x p c
i x p c
i
i
   
    
 
 
ô ó
ô

delegates


1
',,
0
0 1
0
0
(,) ( ) ( )
( ) ( )\(,) (,1)
?,,,
,,[ ( )
( ) (,1)
,
\(,)
,
(,1)]
c j c
c c p c c c j d x c j p
PC s x d x c j c p c j
i x c p c j
i
i
PC p x c v s d
v s d x d x c j c p c j
  
        

   
    
  
 


ô ó
ô

delegates
Semantics of Revocation


Revocation by an owner: remove the (part of) delegated
dynamic label


Alice delegates x ? Bob
-
> Chuck


Bob delegates x ? Chuck


Alice : Bob





Alice revokes x ? Chuck




1

-
> Chuck

0

48

Semantics of Revocation


Revocation by a grantor: push the delegation index back


Alice delegates x ? Bob
-
> Chuck


Bob delegates Chuck


Alice : Bob
-
> Chuck





Bob revokes x * Chuck




1

0

49

50

Operational
Semantics:

Big Step (revocation)



0 1 2
0
0 1 0 1 2 0 1
(,) | (',) ( )'
( )
( ( ( )))
(,) | (
( ) ( )
?,,,
,) ( ) min(#( ),)
,
x
c i c i d x c c p c c c
d d x
i
PC s x d x
PC
c p p oweners s x
c p c j c p c c c k d
p x c
x j c p c k
v s d i
 
   
 


 
   
 
 



  
 

 

ô ó


revokes
,,[ ],
x
v s d x d i
  

Revocation (Revisited)


Alice visits a bookshop and

buys a gift for Carol


Alice authorizes Bob (the Shopkeeper)
to access her credit card information


the purchase transaction is completed
and Alice leaves the shop


Bob tries to access Alice’s credit card
information

51

Delegation and Revocation:

Semantic Issues


Information
-
flow content (to be revised): expressions influenced
a variable so far


Assignment:


Either the static label of the assigned variable is more restrictive than the
static label of the assigning expression and


the
join
of the static and
dynamic

label of the assigning expression is
more restrictive than the join of the static and dynamic label of the
assigned variable

the
static and dynamic label of the
expressions
of
the assigning
expression is
more restrictive
than its
information flow


52

Secure Information Flow


Non
-
interference: changing the secret data does not influence
publicly observable behavior


Delegation and revocation: secret and public change dynamically


Solutions:


Bisimulation
-
based non
-
interference [
Sabelfeld&Sands
, CSFW’00]


Piecewise parameterized non
-
interference [
Sabelfeld&Myers
, ISSS’03 and
Barthe

et al., CSFW’04]


Coercion, abstract flow semantics, type system [Hicks et al.,
Buodol
,
FAST’08]

53


Conclusions

Conclusions


Extended the language with restricted
delegation and revocation


Main novelties


Restricting possible future delegations


Disallowing “delegated flows” after revocation


Extending the setting to integrity labels

55

Honorable Mentions


M. Hicks, S.
Tse
, B. Hicks, and S.
Zdancewic
.
Dynamic updating of information
-
flow
policies. In
Proc. of FCS'05
, pp. 7
-
18, 2005.


G.
Boudol
. Secure information flow as a safety
property.
In Proc. FAST'08
, pp. 20
-
34, 2008.


N.
Broberg

and D. Sands.
Paralocks
: role
-
based
information flow control and beyond. In
Proc.
POPL'2010
, pp. 431
-
444, ACM, 2010.

56

Future Work


Allowing for expressions checking the possibility of a flow in the
conditional statement


Defining a suitable notion of secure information flow and
proving our semantics correct (ongoing)


Implementation and application in a secure server
-
side scripting
language (ongoing)



For more information, please see:

D. Hassan, M.R.
Mousavi

and M.A.
Reniers
. Restricted Delegation
and Revocation in Language
-
Based Security (Position Paper).
Proc. of PLAS 2010.


57


Thank you very much


Questions?