A Token-based Access Control Mechanism for Automated Capture and Access Systems in Ubiquitous Computing

We discuss the problems related to access control in automated capture and access systems, which capture, store and retrieve information gathered through sensors in physical environments. We discuss several unique requirements that set capture and access apart from traditional information processing systems, and that make existing access control approaches such as role-based access control (RBAC) and digital rights management (DRM) unsuitable for this domain. Drawing from access control theory research, we devise an access control system that satisfies these requirements. Further, we describe its implementation within an existing capture and access system, and discuss emergent issues relating to retention time, rights management and information sharing. We argue that some traditional security requirements might not in fact be appropriate when applied to environmental captured information, due to the perceptual and social characteristics of such data. Finally, we provide an example of how this access control architecture might fit in a capture and access system composed of mobile devices. Introduction and Related Work Automated capture and access (CA 2) systems have emerged from the need for many different ubiquitous computing (ubicomp) applications to support the collection and retrieval of information from the physical world, such as audio and video feeds, the location of individuals and objects, or other kinds of environmental information ( e.g., temperature, concentration of airborne chemicals). Capture and access systems have been used to build, among others, recording applications for meetings [15] and classrooms [1], personal memory aid tools [12, 21, 8], and therapeutic support systems [23]. Design and architectural considerations are leading to the consolidation of collection and retrieval functions in generic infrastructural systems, similarly to data networking services, available to multiple applications. Due to their instrumental 1 This article is available at www.gvu. gatech.edu as Georgia Institute of T chnology GVU Center Technical Report GIT-GVU-05-06. 2 Not to be confused with the same acronym for Certification Authority. A Token-based Access Control Mechanism for Automated Capture and Access Systems in Ubiquitous Computing 2 nature, CA technologies are on their way to becoming one of the upcoming large information infrastructures. Securing collected data is an obvious requirement for CA systems. Privacy and security have represented concerns in the wider ubicomp community from the beginning of the ‘90s [22, 2]. Early work concentrated mostly on social acceptability and legal issues, especially in relation to privacy, and access control has not been generally addressed due to the priority given to functional issues. Recently however, researchers has started analyzing access control problems in ubiquitous computing systems from various perspectives. For example, Sampemane et l. have shown how to employ generalized role-based access control (RBAC) to secure ubiquitous information services [20] ( e.g., for annexing information or computing services overlaid with physical environments), and Covington has used environmental sensed data as inputs to RBAC evaluation functions [7]. As opposed to the two mentioned approaches, we are interested in providing access control for the information collected in physical environments — not for ubiquitous services — in a way appropriate to the perceptual characteristics of such data. We propose to associate a set of tokens to each environmental data item stored by the CA system; tokens are also distributed to the users who need to access the information. The user must subsequently show the token to the system in order to gain access to that data item. This approach is similar to the key-lock pair access control techniques first used in early multiprocessing systems and documented by Graham and Denning [10]. In that article, Graham and Denning also describe capability lists, in which each user is associated with a set of access capab ilities on data and access control lists (or ACL), in which objects are associated with access permissions. However, our system differs from their key-lock approach in that users do not need to be identified ahead of time and tokens are automatically associated at the time of capture with incoming streaming data. Token-based access control also differs from capability lists in that the user, not the system, keeps track of tokens. Further, tokenbased access control differs from both capability lists and ACL in that it does not require to identify users to evaluate the access control functions ( i.e., to grant or deny access). Tokens can be thought of as “memory handles” which allow access only to the segments of information that a user chooses, or is allowed, to “remember,” as proven by retaining the token. The effectiveness of this access control scheme depends on how the captured data items are annotated with location and temporal attributes. Moreover, tokens have rather weak security properties in some respects. We argue below, however, that considering automated capture and access in its broader context, these weaknesses might be the result of the intrinsic nature of people’s understanding of everyday experience, and that it might be impossible to control such data exchanges by using any access control technique. Below, we present the requirements analysis of an access control system for CA applications and describe how we implemented it within an existing infrastructure system, the InCA toolkit [19]. We do expose how the structure of InCA has influenced part of the design of the access control system, and which aspects are independent of InCA. We further develop some comments on how access control A Token-based Access Control Mechanism for Automated Capture and Access Systems in Ubiquitous Computing 3 could be used in a variety of environmental capture applications, concentrating specifically on the case in which personal, portable terminals can be used as brokers between users and system components.