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

Boxed Ambients Instructor Network Mail Classroom Mailer Destination

Boxed Ambients Instructor Network Mail Classroom Mailer Destination msg

Boxed Ambients Instructor Network Mail Classroom Mailer Destination

Boxed Ambients Instructor Network Mail Classroom Mailer Destination

Boxed Ambients Instructor Network Mail Classroom Mailer Destination

Boxed Ambients Instructor Network Mail Classroom Mailer Destination route

Boxed Ambients Instructor Network Mail Classroom Mailer Destination

Boxed Ambients Instructor Network Mail Classroom Mailer Destination

Boxed Ambients Instructor Network Mail Classroom Mailer Destination msg

Boxed Ambients Student Network Mail Classroom Mailer Destination

Boxed Ambients Student Network Mail Classroom Mailer Destination msg

Boxed Ambients Student Network Mail Classroom Mailer Destination

Boxed Ambients Student Network Class Resp Classroom Mailer Destination

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

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

Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

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

Boxed Ambients with Security Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

Boxed Ambients with Security Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

Boxed Ambients with Security Network GetInfo Patient2 Doctor CPAP Patient1 CPAP

Boxed Ambients Network GetInfo Patient2 Doctor CPAP Patient1 CPAP X

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

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

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

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)

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

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.

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

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

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.

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.

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.

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

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

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 )

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})

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 )

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 )

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

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

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.

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

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

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.

- Thank You!