The level of impact, or potential risk, of an unauthorised access is closely related to the sensitivity level of the requested resource object. The higher the object’s sensitivity level, the higher the level of impact should the object be accessed by an unauthorised entity. To provide an effective level of protection, while at the same time not introducing unnecessary overheads, the applied security protection level should be linked to the sensitivity level of the objects under protection. One way to achieve this just-enough-security protection is to link an authorisation decision to the Level of Assurance (LoA) in identifying the entity requesting access to an object. In other words, the higher the requested object’s sensitivity level, the higher the Requester’s LoA (RLoA) a user has to satisfy before granting access to the resource object.
A user’s RLoA may also be influenced by the user’s contextual information (i.e. both static and dynamic). In other words, we could design an access con- trol solution that takes into consideration, not only a user’s static contextual
CHAPTER 3. UBICOMP ACCESS CONTROL: A SURVEY 61
attributes, but also the dynamic contextual attributes. The access control solu- tion derives RLoA values, based on the static and dynamic contextual attributes, then feeds the RLoA values into the authorisation engines for a proper control of resources in UbiComp environments. In this way, we could adapt an access con- trol decision in response to the resource object’s sensitivity level and the changes in the user’s LoA-affecting contextual information, thus achieving fine-grained access control.
Our proposal is summarised as follows: -
1. The resource objects are classified into groups based on their sensitivity lev- els. This is done as an off-line process that could be repeated if necessary. Thus, every resource object will have an Object’s LoA value (OLoA) that denotes the required level of assurance a user has to satisfy before releas- ing the resource object. It is worth emphasising that the OLoA value is computed with respect to the object sensitivity level2.
2. On every access request of a particular user, the contextual information of the user (i.e. both static and dynamic) is used to compute a LoA value in the identity of the user (i.e. RLoA).
3. The authorisation engine will then compare OLoA against RLoA. If RLoA ≥ OLoA, then access is granted. Otherwise, access is denied.
4. The user’s contextual information is monitored, and any change in such information will be captured and the access control decision will need to be re-assessed based on the new contextual information.
The use of LoA introduces a level of abstraction between the contextual in- formation used and the underlying access control model. Thus, we could loosen
2
CHAPTER 3. UBICOMP ACCESS CONTROL: A SURVEY 62
the tight-coupling between the two infrastructures (i.e. ACI and CMI). This could make the solution easily applicable in any UbiComp application domain. Moreover, the solution allows to accommodate, virtually, any set of contextual information without the need to modify the underlying access control system. We believe this is the best way to advance access control in UbiComp environments.
3.6
Chapter Summary
This chapter has surveyed some of the access control models that are proposed for UbiComp environments. In particular, it has critically analysed the CAAC- based proposals, such as GRBAC, SRBAC, TRBAC, DRBAC, and CoCoA. The most notable weakness in these proposals is the tight-coupling between ACI (i.e. responsible for access control decision-making) and CMI (i.e. responsible for contextual information management). As a result, changing the content of the contextual attribute set requires a significant modification in the ACI. In addition, some CAAC-based solutions only consider a limited set of contextual information (e.g. location and time). The potential correlation among multiple contextual attributes have also been overlooked. Recent access control proposals (e.g. the generalised context-based access control model, activity-based models, and trust- based models) have also been investigated. The gap between the issues addressed in these proposals and what is addressed in this thesis has also been identified. For example, some of these models are designed for an open UbiComp environment, which assumes no prior relationships amongst the entities involved exist. Thus, the focus is on how to establish trust under such an assumption. However, our problem scope is how to achieve just-enough security in UbiComp, in adaptation to a resource sensitivity level, while maximising flexibility and extensibility of the solution. We have outlined our vision to design an access control solution that
CHAPTER 3. UBICOMP ACCESS CONTROL: A SURVEY 63
overcomes the existing solutions limitations.
There are some concerns regarding the proposed access control approach such as how to determine the LoA-affecting contextual information, and how to com- pute the RLoA value. These concerns will be covered in the following chapter.
Chapter 4
Context-Risk-Aware Access
Control (CRAAC)
4.1
Chapter Introduction
As explained in Chapter 3, CRAAC achieves LoA-linked access control. In other words, based upon the risk level in the underlying access environment and/or the sensitivity level of the resource object requested, CRAAC requires an access requester to satisfy a minimum level of assurance. The level of assurance is related to the requester’s contextual information. This chapter describes the CRAAC vision in detail. It identifies the contextual attributes that may affect a requester’s level of assurance. It analyses the mutual relationships among the attributes and proposes methods to accommodate the relationships. Thus, at run- time, CRAAC can use the methods to dynamically derive an aggregate level of assurance (i.e. RLoA) for a given requester based upon the requester’s contextual information. Then, it uses the RLoA to govern access control decision-making for the requester.
The remaining part of this chapter is structured as follows: -
CHAPTER 4. CONTEXT-RISK-AWARE ACCESS CONTROL (CRAAC) 65
• Section 4.2 introduces the CRAAC model and its vision in supporting LoA- linked access control.
• Section 4.3 identifies four contextual attributes that may have direct impact on a user’s RLoA and shows how the corresponding LoA may be computed.
• Section 4.4 explores the possible LoA-to-Weight conversion methods.
• Section 4.5 identifies two mutual relationships among multiple contextual attributes and shows how to capture those relationships. In other words, it introduces two situations where the RLoA aggregation may differ: Elevating and Weakest-link.
• Section 4.6 outlines CRAAC four modes of working and the rationale behind the design of those modes.
• Finally, Section 4.7 summarises the chapter.