1. Role-based Access Control in a Mobile Environment Elsa L Gunter (UI-UC) Joint work with Adriana Compagnoni (Stevens) Pablo Garralda (Stevens)

2. Security in Necessary for Correct Functionality l Embeded devices often need to receive data (and increasingly new code) from remote sources l If data (or new code) is corrupt, the functionality of device is at risk l Need methods to verify security of communications

3. CPAP Machines - Current Method l Doctor send you a Smart Card l You insert the smart card into your machine l When the machine is done intercating with the smart card, you take it out l You mail the card back to the doctor l The doctor places the smart card in his reader l Secuirity derives from the “belief” that the card is secure l Networking is the way of the future

4. Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

5. Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

6. Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

7. Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

8. Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

9. Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

10. Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

11. Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

12. Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

13. Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

14. Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

15. Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

16. Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

17. Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

18. l How do we guarantee that the only authorized agents access your CPAP?

19. Boxed Ambients with Security Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

20. Boxed Ambients with Security Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

21. Boxed Ambients with Security Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

22. Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP X

23. Role-Based Access Control l Separate control into roles for users and access privileges for roles l Give one relation of users (and possibly active roles) to roles (that can be activated) l Give separate relation of roles to privileges l Access privileges: P : Role set  Acc set l User roles: U : User  Role set  Role set

24. Local Role-Based Access Control l Have a notion of a location (boxed ambient) l Each ambient assigns privileges to the resources it controls: »Entry into itself »Read access to its channel »Write access to its channel l P : Amb  Role set  Role set  Role set enter read write

25. Ambient l Assume set of (public) ambient names Amb l Ambients given by: A ::= m u [P 1 @  1 ...  P n @  n ] »Where m  Amb »  i  Roles (representing roles current for that process) »u  Users »P i a Process

26. Process (some what simplified) l Similar to  -calculus l P ::= A | nil | (P 1 | P 2 ) | !P | (n:(  in,  r,  w )) P (creates a new ambient) | c.P (send message M on channel c) | c(x).P (receive message into x on c) | activate(r).P (activate role r for P) | deactivate( r ).P (deactivate role r for P) | C(c).P (execute capability C, creating local channel c) l Message is a capabilty or variable (containing a capabilty)

27. Capabilities l Two main kinds of capabilities: communicating and non-communicating (quiet) l Quiet Capabilities: Q ::= inQ m | outQ m | inQ | outQ l Capabilities: C ::= in m | out m | in | out | Q | Q.C l Capabilities are the content of messages (M) and actions of processes

28. Dynamic Semantics l Give Dynamic Semantics to describe when one ambient may enter, exit, or communicate with another. l Requires run-time access to role-based access policy

29. Dynamic Semantics l  maps ids to types l m u [activate ( r ).P@  ],   m u [P @(  { r })],  if r  U (u,  ) l m u [deactivate ( r ). P@  ],   m u [P @(  - { r })],  l m u [ (n:  ).P @  ],   m u [P @  ],  +(n :  ) l m u [c.P 1 @  1  c(x).P 2 @  2 ],   m u [P 1 @  1  P 2 {x:=M}@  2 ],  if  (c) = (  r,  w ) and  r   2   and  w   1  

30. Dynamic Semantics: in l n u [in m (c 1 ).P 1 @  1  R 1 ] @  n  m v [in (c 2 ).P 2 @  2  R 2 ] @  m,   m u [n v [P 1 {c 1 : = c}@  1  R 1 ]@  n  P 2 {c 2 :=c}@  2  R 2 ]@  m,  + (c : (  ’ r   ’’ r,  w ) ) where  (m) = (  ’ in,  ’ r,  ’ w ) and  (n) = (  ’’ in,  ’’ r,  ’’ w ) l inQ, same but update  + (c : ({ }, { })) (aka shh)

31. Dynamic Semantics: out l p u [n v [m w [out p (c 1 ). P 1 @  1  R 1 ] @  m  R 2 ] @  n  out (c 2 ).P 2 @  2  R 3 ] @  p,   p u [n v [R 2 ] @  n  m w [P 1 {c 1 : = c}@  1  R 1 ] @  m  P 2 {c 2 :=c}@  2  R 3 ] @  p,  + (c : (  ’ r   ’’ r,  w ) ) where  (m) = (  ’ in,  ’ r,  ’ w ) and  (p) = (  ’’ in,  ’’ r,  ’’ w ) l outQ same, but update  + (c : shh) l Nested Ambients: m u [R 1 ]  m u [R’ 1 ] if R 1  R’ 1

32. Example l Previous example can now work: l Give members of doctor’s office the doctor role l Patient allows GetInfo procedures with doctor role to enter, but not GetInfo procedures from other patients l Patients can’t (in general) activate the doctor role

33. What can we do statically? l Give static types to channels and ambients l Ambient types:  ::= (  in,  ) l Channel types:  ::= (  r,  w,  ) | ssh l Being in  in guarantees you can enter the ambient l Being in  r guarantees you can read from the channel l Being in  w guarantees you can write to the channel l shh means you cannot read or write to the channel

34. Static Semantics l Develop type system that checks if access to local resources is authorized l If process statically type checks, activate and deactivate may be ignored at runtime l Requires complete static knowledge of local role-based access control policy

35. Some Typing Rules l  assigns types to channels and ambients l Roled processes: , u,  |- P , u |- R 1 , u |- R 2 , u |- P @  , u |- R 1  R 2 l Processes: , v |- R , u,  |- nil , u,  |- m v [R]

36. Typing Rules: Role Activation r  U (u,  ) , u,  { r } |- P , u,  |- activate ( r ).P , u,  |- P , u,  - { r } |- deactivate ( r ).P

37. Typing Rules: Data Exchange  |- c: (  r,  w,  )  r      +(x’:  ), u,  |- P{x:=x’} x’ fresh , u,  |- c(x).P  |- c: (  r,  w,  )  w     , u,  |- P  |- M :  , u,  |- c.P

38. Type Rules: Entrance  |- m : (  in,  )  in      +(c’:  ), u,  |- P{c:= c’} c’ fresh , u,  |- in m (c).P@   |- m : (  in,  )  in      +(c’: ssh), u,  |- P{c:= c’} c’ fresh , u,  |- inQ m (c).P@ 

39. CPAP Example l No matter how we specifify types for the ambients, the Patient1 GetInfo process will not type check if it requests to enter Patient2 l We can find types that allow the Doctor GetInfo program to type check

40. Limitations l Coming up with the types for the ambients is difficult »They go in the code making writing code infeasible l The size of the types quickly becomes enormous l The type of a channel is fixed for all communication »Some form of session types seems possible »Would make the types in code even worse

41. Limitations l The types have a finite nature, bounding the level of indirect learning from a channel »Some natural examples that are fine don’t type check »A form of recursive type might help here »Simplest solution: same type for channel and data –  = (  in, (  r,  w,  ) ) –Type system makes sense and can handle at least one example above can’t, but tends to force all ambients to have the same type

42. Future Work l Subtyping: Can a more (or less) restrictive type be used than the one given? »Covariant / contrvariant problem l Support for “open” (delivering running code) l Multiple channels between communicating ambients l Implement on top of the Tunnel Calculus (Carl Gunter and Alwyn Goodloe)

43. Related Work l Braghin, Gorla, and Sassone (CSFW04) »They develop a type system for stactically (and dynamically) checking code in the  -calculus »Their type system is similar finitary limitation l Hennessy (TGC05) »Type system for the D  -calculus »Uses dependent types to allow privileges to vary by the message received »No nesting of different user code »No movement of laocations, only code »Has residual run-time type checks

45. l Ambients given by: A ::= m u [P 1 @  1 ...  P n @  n ] »Where m  Amb »  1  Roles (representing roles current for that process) »u  Users »P i a Process

46. l Assume set of (public) ambient names Amb l Ambients given by: A ::= m u [P 1 @  1 ...  P n @  n ] »Where m  Amb »  1  Roles (representing roles current for that process) »u  Users »P i a Process

47. l l l l