Vigil : Enforcing Security in Ubiquitous Environments

1. Vigil : Enforcing Security in Ubiquitous Environments Authors : Lalana Kagal, Jeffrey Undercoffer, Anupam Joshi, Tim Finin Presented by : Amit Choudhri CMSC 628 Spring 2002 UMBC

2. Introduction • Focal point of paper : Ubiquitous / pervasive computing .i.e. : access to services and information ANYWHERE and EVERYWHERE • Existing technologies for security in such environments : • Simple Public Key Infrastructure ( SPKI ) • Role Based Access Control ( RBAC )

3. Vigil complements these with “ distributed trust management “ • Vigil is applied to Smart Spaces • Smart Space : provides services and resources accessible by short-range wireless communication.

4. Vigil uses the Centaurus model for the SmartSpace architecture. • Centaurus SM proxies for clients • Vigil infrastructure : • reduce load on mobile devices • media independent • provides services and information

5. Security Challenges • Cannot provide unique user id and login for everyone  not scalable. • Cannot have a central authority per space. • No access control information available when new users are authenticated. • Heterogeneity of environments and inconsistent interpretations of policy.

6. Architecture • Clients can move, attach, detach and re – attach at any point in the framework. • Vigil uses “ trust management “ • Establishing trust relationships • NOT quantifying trust • Similar to RBAC • Access rights are computed from its properties !

7. Components • Vigil has 6 components : • Service Broker • Communication Manager • Certificate Controller • Security Agent • Role Assignment Manager • Clients ( users & services )

9. Service Broker • The Service Broker is responsible for : • Processing Client Registration/De-Registration requests • responding to registered Client requests for a listing of available services, • brokering Subscribe/Un-Subscribe and Command requests from users to services • sending service updates to all subscribed users

10. Service brokers in different spaces form a tree hierarchy  core of the Vigil system • Identified by their handles , i.e. position in the hierarchy • Trust between clients in transitive through the Service Brokers

11. Client • All users and services are clients • Clients register with a Service Broker in a space. • Digital certificate and Showall flag sent during registration • Clients can request services from brokers and other clients, via service brokers.

12. Certificate Controller • Generates x.509 version 3 digital certificates for system entities • Verifies certificates presented by entities • These certificates are stored on the clients smartcard • Verification is based on a list of trusted CA’s and a set of verification rules and policies.

13. Role Assignment Manager • Assigns roles to entities in a space • Maintains an Access Control List ( ACL ) • Uses rules from the security policy to assign roles. • Allows multiple roles for an entity and dynamic updating of roles.

14. Security Agent • Maintains “ distributed trust ” in the system. • Policy has rules for : • Role assignment • Access control • Delegation • Revocation • Policies • Global – organization level • Local – Space level

15. Policy has • Permissions • Prohibitions  negative access rights • Knowledge base is created using Prolog • All queries are converted to Prolog • More complex than RBAC or ACL because access rights can be delegated. • Delegations are not random  from authorized entity to authorized entities, follow policy.

16. Service Access • On registration, user gets an interface to all accessible services • Also services that have their ShowAll flag set are displayed User cannot access them , but can request access for them • User can get a list of services from its Service Broker. • Service Broker grants access after checking clients role and querying the Security Agent for the users rights. • If valid request, it forwards request to the service.

17. Delegation • User can see services, but cannot use them  Showall flag • User can request another user or service to delegate it the required access rights. • To request delegation, user sends request with digital certificate • If delegated rights, Security Agent is informed

18. Delegated rights are valid only for a specific time. • Delegated rights can be re-delegated if allowed • When time expires  renew rights again • Delegating user can revoke delegated rights by informing Security agent.

19. Terms • Role Based Access Control ( RBAC ) : • Rights are associated with pre-defined roles, and not with users. • Roles can change in different environments, while user remains the same  context – dependent semantics ! • Rules for assigning roles are the main access control mechanism • Dynamic creation of roles is possible, based on inferences • Drawback : dynamic delegation of rights not possible

20. Public Key Infrastructure (PKI) • PKI uses on-line repository for certificates • PKI provides on-line Certificate Revocation List (CRL) • PKI imposes a high overhead and increased traffic. • Simplified Public Key Infrastructure (SPKI) • Entities send their certificate to SA • SA sends back its own certificate to entity • Certificates verified using certificate controller • Certificate has list of CA’s and rules for verification • All entities can communicate by attaching their certificates to initial message.

21. Implementation • Security Agent uses Prolog for reasoning • Java was the development platform • Centaurus framework which is used uses Centaurus Capability ML (CCML) • CCML is used as data exchange format between service requester and provider

22. Related Research • Unisys Corporation / Orange experimental house ( Hertford, England ) • UC Berkeley’s Ninja Project • Uwash’s Portolano project • Stanford’s Interactive Workspaces Project

23. Further Work • Implementing distributed belief based on gossip for the SA • Using RDF or DAML instead of Prolog for encoding the trust information