Criticality Aware Access Control Model for
Pervasive Applications
Sandeep K. S. Gupta, T. Mukherjee, K. VenkatasubramanianImpact Lab (http://impact.asu.edu)Department of Computer Science & EngineeringIra A. Fulton School of EngineeringArizona State UniversityTempe, Arizona, USA
Supported in part by Mediserve Inc and US National Science Foundation
Overview
Motivation Critical Events, Criticality Criticality Aware Access Control (CAAC) Challenges Architecture Specification Verification Conclusions and Future Work
Access Control in Smart Spaces Smart spaces – e.g. homes, hospitals – allow inhabitants
to physically interact with information-rich virtual entities. Access control necessary to prevent unauthorized
access for malicious use. How to balance access Flexibility and Security?
Stringent access control may prevent expedited mitigative actions in case of emergencies
Relaxing access control may invite malicious use Traditional access control models (mechanisms +
policies) are not suitable Mainly reactive and not designed to handle emergency (critical)
scenarios. Goal: To design a smart-space access control model
that provides necessary flexibility for handling access control in case of emergencies while minimizing security risks.
Critical events Events which cannot be responded to, using the routine
set of capabilities of the subjects.
Examples: Tornado is a critical event for a smart-home. Heart-attack is a critical event in a home environment.
Critical Events
Mitigation
Emergency SituationNormal Situation
Emergency policyRoutine policy
Characteristics of Critical Events Requires exceptional set of actions
for controlling the emergency – avoiding catastrophic failure.
Request based reactive context evaluation is inadequate.
Proactive context monitoring is required.
We define the term ‘Criticality’ as the measure of responsiveness
required for an emergency situation
Normal actions
Critical event
Exceptional actions
Temporal Requirement for Criticality
Every critical event has a Window of opportunity (Wo) to respond.
Value of Wo is criticality dependent.
WoCritical Event Mitigation
Time
Normal actions
Mitigative actions
Examples of Criticality and Wo
Heart attack - 1st one hour critical (golden hour).
Tornado – evacuation within 5 minutes of first warning. *
Data-center - 90 seconds after cooling failure.
Disaster Recovery – 30 days time. **
*http://www.fema.gov/pdf/rrr/ndis_rev_oct27.pdf **http://www.fema.gov/pdf/library/fema_apa_ch4.pdf
Goals of Criticality Aware Access Control
Facilitate timely mitigation of criticality May require change in access privileges Proactive – automatic and continuous context evaluation Duration of change in access privileges should be finite. If critical emergency,
choose users provide access
Traditional access control is inadequate Reactive – explicit request-based context evaluation If ok, provides access
Criticality Aware Access Control (CAAC)
CAAC
Allow another doctor toAccess Patient Data Treat Patient
Patient Emergency
(Doctor not available)
CAAP mode
Patient (NoEmergency)
Normal mode
In this mode, an alternate setof access privileges are enforcedfor facilitating mitigative actions
CAAC Challenges / Properties Responsiveness
How fast to react ?
Correctness How to evaluate context / detect criticality?
Liveness How long to impose CAAP-mode?
Non-Repudiability How to deter malicious behavior as a result of
privilege changes in CAAP-mode?
Responsiveness
Measures the speed with which the alternate set of policies is enforced after the occurrence of a critical event.
If, Ta is the time to take mitigative actions for a critical event D is the time to initiate the enforcement.
Then, The Critical Event can be successfully handled iff
D + Ta ≤ Wo
Liveness
The duration of policy changes (TCAAP), in response to critical events, should be: Finite Lasts only as long as needed
If, TEOC is the time instant when a criticality is controlled. TEU is the time instant when all the necessary mitigative steps for
a criticality have been taken.
Then, assuming criticality occurred at time 0,
TCAAP = min (TEOC, TEU, Wo)
Correctness and Non-Repudiability
Correctness CAAP-mode should only be initiated in response to a
critical event. Highly system dependent.
Non-Repudiability All system activities performed in the CAAP-mode,
should be monitored for ensuring accountability. Deters malicious use of system during criticality, when
alternate (possibly elevated) privileges are in place.
CAAC Architecture
Ac c es s C o n tr o l M eta- D ata ( AC M )
R o les P r iv ileg esS u b jec ts
C r it ic a lity M an ag em en t Un it( C M U)
Ac c o u n tab ilityM an ag em en t Un it
( AM U)
D y n a mic Co n te xtM a n a g e me n t U n it
(D CM U )
Co n te xt Ga th e rin gP la t fo rm (CGP )
A c c e s s Co n t ro l P o lic y M a n a g e me n t(A CP M )
R o le M an ag em en t Un it ( R M U)
• Extends Context Aware Role Based Access Control (CA-RBAC) by introducing CMU.
• CA-RBAC is an event with Wo = infinity
• Proactive context evaluation as opposed to reactive in CA-RBAC.
Criticality Management Unit (CMU)
C rit ica lity L e v e lD e te rm in a t io n Un it
(C L D )
C ritic ality N o tific atio nU n it (C N U )
N o n -c rit ic alC o n te x tH an d le r(N C H )
A c c e s s C o n tro lM e ta-d ata P ro v id e r(A C M P )
C o n te x t In te rp re te r (C I )
Proactively monitors for the context andintelligently detects the occurrence of acritical event
Determines the level of criticality and the associated Wo based on the input from CI
Moves the system into CAAP-modeand informs other components in thearchitecture about this
Provides the access control meta-datato the CNU for determining the policiesfor the CAAP-mode
Queries specific context information during normal mode (as in CA-RBAC)
CAAC – Big Picture
WoCritical Event TEOC
Time
Normal mode
CAAP-mode
WoCritical Event
Time
Sce
nario
1S
cena
rio 2
CAAP is reverted after
Wo expires
CAAP is reverted when the criticality is
mitigated
Domain of CAAC
Criticality AwareAccess Control (Proactive) Role Based
Access Control
CA-RBAC (Reactive)CAAC
Context Aware Access Control (Reactive)
Criticality Aware Access Control
(non-role based)
CAAC Model
Access to resources provided based on: Criticality Other contexts
Privileges given to subjects implemented using Role Based Access Control (RBAC) model.
Two types of roles:System Role (rsys): role assigned when subject joins the
system, doctor in hospital. Space Role (rspace): role assigned based on subject’s domain
of work, surgeon in ED.
CAAC Model (Contd..) Each resource maintains a list of roles
and associated privileges called Access Control List (ACL).
The function f maps the users’ space roles onto a corresponding role in the ACL.
The presence of criticality leads to the mapping of the users’ space role to a different one in the ACL.
Our sample specification, always promotes the users’ roles in the event of criticality. Promoted Role Table (PRT) is
maintained for accountability
Space Role
Role 1
Role 2
Role N
Privileges for Role 1
Privileges for Role 2
Privileges for Role N
f
CriticalityDetection
Role Privileges
ACL
CAAC- Policy Specifications Specify rules for accessing service provided by
resource.
Two types of policies: Administrative
Define the rules for administrative function within the system.
Access Control Define the rules based on which access is given to
subjects for both critical and non-critical situations.
Access Control Specification Promote Role – elevates subject’s privileges when criticality is detected
(system goes into CAAP-mode)
Demote Role – resets subject’s privileges when criticality is mitigated (or Wo is expired).
Notify Critical proactively monitors for critical events determines the appropriate elevation/reset of subject’s privileges
using promoterole function.
Access Control Predicate (ACP) Boolean condition that determines the access to resources when explicit
access requests are made.
Promote Role
Step 1: Determine the occurrence of Criticality
Step 2: If one found Determine Wo
Compute new Space Role with elevated privileges. Update PRT.
Step 3: Return the new space role
Demote Role
Step 1: For each resource reset the role of users back to their original space role.
Step 2: Update PRT accordingly.
Notify Critical Continuously monitor system for occurrence of criticality
If no criticality found AND system is in CAAP-mode (TEOC) Demote role Revert system to normal state
If criticality found AND system is in CAAP-mode, BUT Wo expired
Demote role Revert system to normal state
All mitigate steps have been taken (TEU) Demote role Revert system to normal state
If criticality found AND system is not in CAAP-mode Set system to CAAP-mode Find and notify appropriate users Promote their roles.
Access Control Predicate
Previous specifications catered for: Proactive context monitoring Automatic policy changes
ACP is used for providing access on explicit request from users, based on Current context Validity of the request Availability of required services
Administrative Policies
Adding and removing Space Roles.
Adding and removing System Roles.
Role Accountability examines activities during the period when
subject’s privileges are elevated. checks the PRT.
Verification of the specification
Correctness: The system can enter the CAAP-mode iff there is a critical event (ensured by Notify Critical).
Liveness: For a single critical event, a subject’s role is promoted for a maximum of Wo time (ensured by Notify Critical).
Responsiveness: When a critical event occurs: The subject is immediately notified (using Notify Critical) If required the subject’s access privileges are elevated (role promotion
using Promote Role) Any role promotion is active until either the criticality is controlled or it
cannot be controlled anymore (this is ensured by Notify Critical and Demote Role).
Non-repudiation: Malicious use of elevated privileges after the occurrence of a critical event is non-repudiable (ensured by Role Accountability).
Conclusions
Criticality Aware Access Control
Proactive context monitoring
Ideal for emergency management
Automated and flexible
Push based access
Traditional Access Control
Reactive context monitoring
Slower for emergency management
Manual and inflexible
Pull based access
Future Work
Studying the interdependencies among the different properties of CAAC e.g. how does fast response affects mitigation
capability?
Studying multiple simultaneous criticalities What policies to enforce in the CAAP mode? How to model the resulting emergency situation? What are the conditions for mitigation of all the
criticalities?
Reference F. Adelstein, S. K. S. Gupta, G. G. Richard and L. Schwiebert,
“Fundamentals of Mobile and Pervasive Computing'‘, McGraw Hill, 2005
R. Sandhu, E. Coyne, H. Feinstein and C. Youman, ``Role Based Access Control Models'‘, In IEEE Computer, Feb, 1996.pp 38-47
A. Kumar, N. Karnik and G. Chafle, ``Context Sensitivity in Role-based Access Control'‘, In ACM SIGOPS OS Review 36(3), July, 2002
Working Group on Natural Disaster Information Systems, ``Effective Disaster Warning'‘, November, 2000
G. Sampemane, P. Naldurg and R. Campbell, ``Access control for Active Spaces'‘, In Proc. of ACSAC, 2002