1. Mobile Access Control Adriana Compagnoni Stevens Institute of Technology Joint work with Elsa L Gunter (UI-UC) Rutgers, February 3, 2006

2. Boxed Ambients Instructor Network Mail Classroom Mailer Destination

3. Boxed Ambients Instructor Network Mail Classroom Mailer Destination msg

4. Boxed Ambients Instructor Network Mail Classroom Mailer Destination

5. Boxed Ambients Instructor Network Mail Classroom Mailer Destination

6. Boxed Ambients Instructor Network Mail Classroom Mailer Destination

7. Boxed Ambients Instructor Network Mail Classroom Mailer Destination route

8. Boxed Ambients Instructor Network Mail Classroom Mailer Destination

9. Boxed Ambients Instructor Network Mail Classroom Mailer Destination

10. Boxed Ambients Instructor Network Mail Classroom Mailer Destination msg

11. Boxed Ambients Student Network Mail Classroom Mailer Destination

12. Boxed Ambients Student Network Mail Classroom Mailer Destination msg

13. Boxed Ambients Student Network Mail Classroom Mailer Destination

14. Boxed Ambients Student Network Class Resp Classroom Mailer Destination

15. Security is Necessary for Correct Functionality l Embedded 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

16. CPAP Machines - Current Method l Doctor sends you a Smart Card l You insert the smart card into your machine l When the machine is done interacting 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 Security derives from the “belief” that the card is secure l Networking is the way of the future

17. Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

18. Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

19. Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

20. Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

21. Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

22. Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

23. Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

24. Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

25. Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

26. Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

27. Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

28. Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

29. Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

30. Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

31. Privacy l How do we guarantee that only authorized agents access your CPAP?

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

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

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

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

36. 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: UserPolicy : User  Role set  Role set

37. 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 Priv : Amb  Role set  Role set  Role set enter read write

38. Ambient l Assume set of (public) ambient names Amb l Ambients given by: A ::= m u [P]@  »Where m  Amb »   Roles (active roles for that process) »u  Users »P is a Process

39. Processes (simplified) l Similar to  -calculus  |  c |  c (local | with parent | with child) l P :: = nil | (P 1 | P 2 ) | !P | (n:  ) P (creates a new ambient n) | .P (send message M on  ) | (x) .P (receive message into x on  ) | 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)

40. 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

41. Dynamic Semantics l to activate or deactivate a role. l to describe when one ambient may enter or exit another. l to describe local communication, and communication across ambient boundaries.

42. Dynamic Semantics: activate l m u [activate ( r ).P]@   m u [P]@(  { r }) l m u [deactivate ( r ). P]@   m u [P]@(  - { r })

43. Dynamic Semantics l *.P | (x)*.R  P| R {x:=M} (local communication) l m u [  c.P | n v [ (x)  c.R]@  n ]@  m  m u [P | n v [R {x:=M}]@  n ]@  m (to child) l Similarly to parent

44. Dynamic Semantics: in n u [in m (c 1 ).P 1 | R 1 ] @  n | m v [in (c 2 ).P 2 | R 2 ] @  m  m u [n v [P 1 {c 1 : = c} | R 1 ]@  n | P 2 {c 2 := c} | R 2 ]@  m -The capabilities in m (c 1 ) and in (c 2 ) are consumed. - m and n now share a new communication channel c.

45. Dynamic Semantics: out l p u [n v [m w [out p (c 1 ). P 1 | R 1 ]@  m | R 2 ] @  n | out (c 2 ).P 2 | R 3 ] @  p  p u [n v [R 2 ] @  n | m w [P 1 {c 1 : = c} | R 1 ]@  m | P 2 {c 2 := c} | R 3 ] @  p -The capabilities out p (c 1 ) and out (c 2 ) are consumed. - m and p now share a new communication channel c.

46. Type System l Our Type System prevents two forms of security violations: »Attempting to enter an ambient without proper authorization, and »Attempting to read from or write to channels without the corresponding permissions.

47. What can we do statically? l Give static types to channels and ambients l Ambient types:  :: = amb (  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

48. Typing Judgements l ,  here,  deact,m,u |- P:  act Where »P is a process »m is the enclosing ambient »u is the user that owns m »  here is the set of roles authorizing P to be in m »  deact is the set of roles that P can deactivate »  act is the set of currently active roles. »  typing environment for message identifiers and channel names

49. Typing Judgements l Other typing judgements have similar forms. l The typing judgement for actions reflect how the different role sets are modified. ,  here,  deact,  act,m,u |- a : ( ,  here,  act )

50. Typing Rules: Role Activation r  U (u,  act ) ,  here,  deact,  act,m,u |- activate ( r ): ( ,  here,  act  {r}) r   deact (  act - {r} -  deact )   here   ,  here,  deact,  act,m,u |- deactivate ( r ):( ,  here,  act - {r})

51. Typing Rules: Data Exchange Input ,m|-  : (  r,  w,  ) (  act -  deact )   r   ,  here,  deact,  act,m,u |- (x)  : (  + x: ,  here,  act ) Output ,m|-  : (  r,  w,  ) (  act -  deact )   w    |-M :  ,  here,  deact,  act,m,u |-  : ( ,  here,  act )

52. Type Rules: Entrance In  (n)=amb(  in,  ) (  act -  deact )   in   ,  here,  deact,  act,m,u |- in n (c) : (  + c: ,  in,  act ) Co-in  (m)=amb(  in,  ) ,  here,  deact,  act,m,u |- in(c) : (  + c: ,  here,  act )

53. 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

54. CPAP Example l No matter how we specify 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

55. Results l We defined an un-typed and a typed (not shown) transitional semantics. l We show that on well-typed processes both transitional semantics coincide. l The typed transitional semantics is of independent interest, and it is relevant to situations where the access control policy is only known at runtime.

56. Future Work l Trusted and untrusted locations l Role hierarchies l Subtyping: Can a more (or less) restrictive type be used than the one given? l Multiple channels between communicating ambients l Design a programming language based on this calculus

57. Related Work l Bonelli,Compagnoni,Dezani,and Garralda (MFCS04) »The calculus splits communication and mobility by using ambient names and port names. l Braghin, Gorla, and Sassone (CSFW04) »They develop a type system for statically (and dynamically) checking code in the  -calculus with roles. 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 or locations »No movement of locations, only code

58. Contributions l We defined a boxed ambient calculus with Distributed Role-Based Access Control, where the privileges associated to processes change during computation. l Privileges depend on location, owner, activated roles, and security policy. l First calculus with distributed RBAC mechanism where the location of a process conditions its ability to move and communicate.

59. - Thank You!