Distributed Physical Access Control A Constrained Resource Solution

Distributed Physical Access Control A Constrained Resource Solution Adriaan Slabbert Master’s Thesis∗ Department of Computer and Systems Sciences Royal Institute of Technology May 31, 2007 ∗ This thesis corresponds to 20 credits of full-time work for the author. IV Summary. Physical access control involves restricting physical access by clients to system resources. Such control systems are non-trivial to design and implement correctly due to trade-offs between for example cost, reliability, survivability, resource consumption, centralisation, and user-friendliness. In systems which are dynamic and distributed it can be difficult to correctly administrate access rights, since the resources are not necessarily located within the physical boundaries of the system. An added constraint is limited resources available for access control decision-making. In this thesis a solution covering most aspects of the above problem is proposed and implemented. Acknowledgement. I would like to thank everyone who supported me - whether through suggestions, criticism or friendship - during the course of this thesis. A special word of gratitude goes to my mentor, Babak Sadighi, for his unending patience and attention. I am grateful to SICS for providing an environment conducive to productivity and also the opportunity to perform this research. Contents Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IV Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VI List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VII 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1 Problem statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.3 Intended Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.4 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.5 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Theoretical Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Prior research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Existing implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Abstract System Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 System and Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.3 Proposed system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.4 Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.5 Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Development Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Component Choice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 1 2 2 2 2 2 3 5 5 6 7 11 11 11 12 14 15 20 23 23 2 3 VI Contents 3.2.2 Resulting Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Policy Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Policy Language Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1 Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Proof-of-concept Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Resources Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Implementation Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.2 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.3 ADEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Key Implementation Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 Data Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.2 Data Storage and Retrieval . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.3 Cryptographical Functions . . . . . . . . . . . . . . . . . . . . . . . . . . 26 27 28 29 29 37 37 38 38 38 38 39 39 40 40 40 42 43 5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.1 Implementation Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.2 Demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Future Research and Development . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 51 51 53 6 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 List of Figures 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 A conceptual schematic of the system. . . . . . . . . . . . . . . . . . . . . . . . System entities, boundaries and information flows . . . . . . . . . . . . Configuration Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Client Access Rights distribution and use . . . . . . . . . . . . . . . . . . . . Entity-Relationship Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Trust in the system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Delegation in the system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Policy Language Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Server fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Client fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ADEP fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scenario: succesful AR download (no revocation) . . . . . . . . . . . . . Scenario: successful AR submission . . . . . . . . . . . . . . . . . . . . . . . . . 14 15 19 19 21 22 23 28 29 30 30 31 32 4.1 Proof-of-concept System Composition. . . . . . . . . . . . . . . . . . . . . . . . 38 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 Testbench composition 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Testbench composition 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Client screenshots: generating a keypair. . . . . . . . . . . . . . . . . . . . . . Client screenshots: initial AR download. . . . . . . . . . . . . . . . . . . . . . Server screenshot: client public key not recognised. . . . . . . . . . . . Client screenshots: AR download successful. . . . . . . . . . . . . . . . . . Server screenshot: AR download successful. . . . . . . . . . . . . . . . . . . Client screenshots: setting the client role via the “options” command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.9 Client screenshots: AR submission. . . . . . . . . . . . . . . . . . . . . . . . . . . 45 46 47 47 47 48 48 49 49 O 1 Introduction 1.1 Context In the security field of Access Control (AC) the crucial problem of deciding and enforcing who gets to access what, where, when, and in which manner has been approached a variety of ways. One such methodology is Role-Based Access Control [1, pages 182–185], which entails that the client’s privileges are determined by their role in the organisation, and is one of the most costeffective [2], dynamic and widely-used techniques. Physical AC involves controlling physical access by clients to system resources (e.g. unlocking a door to a secured area), and is not trivial to design and implement correctly. Issues like fine-grainedness of control, seamless integration with system processes, scalability, low obtrusiveness, userfriendliness, reliability, and initial and running costs must be carefully balanced, otherwise the security measures become less efficient and hence costineffective. In systems which are dynamic and distributed it can be difficult to correctly administrate access rights, since the resources are not necessarily located within the physical reach of the system. One of the ways to implement AC in such a system is by decentralising it [3, page 3]: a request to access a remote resource is accompanied by a set of unforgeable credentials issued by a central server to the client at an earlier time; the resource Access Decision and Enforcement Point (ADEP) evaluates the request against the credentials, makes an access control decision based on information contained in access policies, and enforces the decision locally. 1.1.1 Problem statement Designing and implementing a Distributed Physical Access Control (DPAC) infrastructure is a non-trivial task; one of the problems is that although a 2 1 Introduction certain amount of theoretical research has been done in this field, not much research has been done on the implementation design and development of such systems. Thus, it would be useful to determine the scope of the functionality of such a system when subjected to resource constraints. Or, given the constraints listed above and taking into consideration realistic (i.e. severe) resource constraints, what are the features that could be incorporated in such a system, and what compromises would have to be made? 1.2 Thesis 1.2.1 Goal The goal of this thesis is to design a Limited Resource Distributed Physical Access Control System (LRDPACS), and to implement it as a prototype. Hence, the thesis type is artifact development, with the primary focus being on the local access control point. 1.2.2 Purpose The thesis results would demonstrate the limits of the capabilities of this particular solution, and highlight the pitfalls and compromises related to its design and implementation. As such, it would be useful primarily for researchers and developers as a reference point in development of more advanced Distributed Physical Access Control (DPAC) systems. 1.2.3 Intended Audience It is assumed that a reader of this thesis has a basic grounding in the Information Technology Security and Computer Science fields. As stated above, the audience is expected to consist mainly of researchers in related fields. 1.2.4 Method The research method is deductive, i.e. from hypothesis or question to empirical data: a literature study is done, functional requirements and constraints are taken into consideration, the system is designed, and finally a prototype is implemented. The prototype is evaluated according to the functional requirements to confirm that it serves as proof-of-concept. 1.2 Thesis 3 1.2.5 Limitations The system design will be useful only as base for further development, and the prototype will serve as demonstration platform. It is not expected that the prototype will be commercialised in its current form. O 2 Background 2.1 Theoretical Background In this thesis we use the definition of access control as provided by Stallings [4, page 10]: The prevention of unauthorised use of a resource (i.e., this service controls who can have access to a resource, under what conditions access can occur, and what those accessing the resource are allowed to do). There are various approaches to this question, of which the following are the most commonly encountered [1, pages 103–104,182–183]: • Identity Based Access Control (IBAC): also known as Discretionary Access Control (DAC), this approach entails that a user which has the right to access a resource can control access to that resource by other users or groups, based on their identity. • Mandatory Access Control (MAC): here the access of users to a resource is entirely controlled by the system security policy, as defined by the system administrator. Access decisions are based on the requirements of the resource involved as well as the security level of the supplicant. • ORiginator CONtrolled access control (ORCON): the creator of a resource or item of information controls the dissemination of its access rights among users. For example, the creator gives access rights for a resource to a set of users, and prohibits them from giving these rights to other, untrusted users. • Role Based Access Control (RBAC): access to resources are granted to a user depending on their role within the system, according to the system security policy. A user might assume various roles, each of which has a set of rights to certain resources, and these sets are not necessarily mutually exclusive since roles may overlap in functionality. 6 2 Background Users are usually grouped according to some shared attribute (e.g., the resources they have to access or the roles they can assume), or alternatively roles can be defined as collections of privileges and users [5, pages 397– 399]. There have been much debate in the access control field as to the differences between groups and roles (if any), but no clear conclusion or compromise has been reached in the contention between the various camps [6]. We will use the terms “role” and “group” interchangeably in this thesis, and define it as a set of users who all have the same function (and hence the same privilege) within the system. Group membership is not exclusive, and can vary with time. In addition to the strategies described above, access control can be implemented virtually or physically. In the first case, authentication tokens are usually virtual, access control is performed virtually, and the resource in question is intangible: e.g., entering a password via keyboard to log into an operating system. The second case involves physical tokens which are associated in realworld manner with the user, and are used in physical manner to gain access to a physical resource; for example, user information is stored on a magnetic stripe card which has a picture of the user printed on it for identification purposes, and the card can be used in conjunction with a card reader to gain access to a secure area. Security systems for critical resources rarely rely on only one or the other type of access control since each type has its strengths and weaknesses and suitable applications: virtual and physical access controls are usually employed in complementary fashion. Physical authentication techniques include biometric attribute recognition (such as fingerprints, voices or faces) [1, pages 328-330] and the carrying by the user of a token, e.g. a magnetic stripe card, or a Radio Frequency IDentification (RFID) embedded tag [7]. 2.2 Prior research As mentioned in Section 1.1, research has been done on decentralised access control with the focus on delegation of privileges [3]. This was motivated by the shortcomings of popular access control methodologies (e.g. Access Control List) when implemented in distributed systems. Role Based Access Control can be combined with delegation of privilege in distributed access control systems, but the problems of hidden membership and hidden privilege pose a challenge [8]. The Hidden Membership Problem is defined as “the task of determining whether a particular [unique user] is a member of an authorised group or role” (the user referred to is requesting 2.3 Existing implementations 7 authorisation to make use of a privilege). The Hidden Privilege Problem is similar to and builds on the Hidden Membership Problem, and deals with delegation of authority over a set of privileges to a user: the question is how to determine the delegation chain(s) from the user with delegated authority to the user requesting authorisation for a privilege. These problems arise out of the necessity for the local access control point to iterate through complex relationship trees to determine the group membership of or privilege assignment to a client: the trees can be nested or cyclical, or even both. No standardised way exists to optimise traversal of these authorisation chains, because it is impossible to define a worst-case input (in terms of time and space complexity) to the client’s traversal algorithm, and leads to great difficulties when implementing such authorisation schemes to be non-trivial. A scalable system design for distributed credential management (essentially the same as decentralised access control management) has been proposed [9], but resource constraints were not taken into consideration: for example, it was assumed that the local access control point would always be able to communicate with the central server infrastructure, e.g. when it has to update the credentials in the trust chain (i.e. its copy of central database credential information). In his Master’s thesis Cao Ling proposed a policy-based resource-limited DPACS which focuses on the use of mobile phones as clients and the infrastructure of such a system [10] 1 . The resource constraints on the system include the absence of direct communication between local access control points and the central server. The results from his research has been used as a starting point and as inspiration for this thesis, which focusses mainly on the local access control point’s role. 2.3 Existing implementations The development and implementation of a distributed credential management system [9] in which smart cards are used as authentication tokens was described comprehensively [11]. This is a useful study, since it demonstrates the successful integration of different technologies under circumstances and constraints which are related to this project. Nevertheless, the basic design relies heavily on the connectedness of its network infrastructure, which limits geographic scalability and flexibility. 1 The work done in his thesis has been submitted as a patent proposal, No. 0600959-1 Sverige 8 2 Background Several other DPAC systems have been developed independently, but each one has at least one weakness or lack of functionality: • Kjeller University’s mKey [12] is designed with the focus on delegation of access rights: users receive access rights to their mobile phones via SMS from a central server, and can give these rights to other users by forwarding the SMS’s. Access rights are stored securely in the mobile phone, and are submitted to an access control point for evaluation via Near Field Communication (NFC). The NFC protocol [13, 14] is a short-distance Radio Frequency (RF) protocol based on the well-known RF Identification (RFID) [15] protocol operating in the 13.56 MHz frequency band. Using SMS as distribution channel does allow the system to integrate seamlessly with older mobile phones, but also causes fragmentation of the data if it’s longer than the SMS payload size, and could lead to long delays in delivery. Encryption of access rights has not been incorporated in the design, nor is it clear if any information other than the data from the SMS is required to authenticate a user to an access point. Revocation of access rights has not been addressed. Secure storage of access rights is achieved by using a smart card-type chip in the mobile phone. Access control to resources (zones) is performed by stand-alone NFC-compatible door locks; it is unclear how the system allows the lock soft-/firmware to be updated. • ASSA Abloy’s VingCard derivative [16] is designed for the hotel industry, and employs NFC smart cards as physical tokens. Access request evaluation and enforcement is done by stand-alone NFC-compatible door locks. The smart cards allow secure storage of access rights, but management (updating or revocation) of issued access rights and lock firmware remains a major problem. • Index Okinawa’s Kesaka Home Entry-lock [17] also incorporates standalone door locks for home use and employs mobile phones as physical tokens, but uses a short-range wireless communications protocol called FeliCa [18] for submitting access requests. FeLiCa was developed for use in smart cards by Sony and is the de facto standard for mobile payment and ticketing in Japan [19], and is also becoming popular in other Far East countries. Unfortunately, the standard is proprietary and must be licensed for development purposes, which restricts the community support base and widespread adoption. In the West FeLiCa and its mobile device counterpart Mobile FeLiCa has not succeeded in competing with other standards such as Philips’ MiFare or NFC. The lock hardware has the advantage of integrating smoothly with existing door locks, but it can not handle a large set of users or complex access right specifications. Kesaka 2.3 Existing implementations 9 claims to offer some centralised networking ability for these locks, but no further information on this topic has been found. • MJST’s RF Self-powered Internal Cargo Lock [20] is a lock system for the transport industry: it comprises a lock with self-contained battery, Global Positioning System (GPS), Radio Frequency (RF) configuration interface, and logging or auditing functionality. The physical authentication tokens are “keyless RF transmitters”; the frequency and protocol appears to be proprietary and secret. This system seems the perfect solution for the logistics field, but is too bulky for easy installation in other fields. Since the communication technology and access rights format are proprietary, it is unknown whether this system can easily be integrated with other infrastructures. Thse examples serve to demonstrate the current solutions available on the marke and their features. In the next chapter we propose a system which addresses most of the abovementioned shortcomings. O 3 System Design The first step of the design process involves analysis of the system, specification of functional requirements, and proposition of the system model. After this the core design and implementation issues are taken into consideration. Finally, the system architecture is formalised. 3.1 Abstract System Analysis Analysis of this problem can be conveniently done according to General Systems Theory (GST) as described by Schoderbek, Schoderbek and Kafalas [21, chapters 1–2]. 3.1.1 System and Environment According to the GST definition [21, page 13], a system is: [...] here defined as a set of objects together with relationships between the objects and between their attributes related to each other and to their environment so as to form a whole. This model makes it easier to analyse the system processes, objects, relationships, and information flow, and to identify the various resulting implications. It is assumed that the boundary between system and environment is clearly defined, i.e. that each entity within the system is well-defined. This allows the environment to be defined as “everything that is not inside the system”. Note that a trust relationship is possible between two systems: A might completely trust B and give B full access rights to its own entities, but they remain separate systems. Intersystem relationships (i.e. between entities within the system and those outside) and intersystem information flow (informational input to and output from the system) expose and make the system vulnerable to the environment which is considered hostile by default. 12 3 System Design 3.1.2 Functional Requirements The functional requirements listed below (in decreasing order of priority) were obtained through an analysis of the features and disadvantages of existing solutions and combining this with various usage scenarious. They comprise a description of the balance between the confidentiality, integrity and assurance security aspects [1, pages 4–6] and address the weaknesses or shortcomings identified in other solutions to the DPAC problem. Integrity and Confidentiality Integrity of sensitive information is of the highest priority: decisions made by the system should always be based on reliable information. However, confidentiality of sensitive information during storage (e.g. private keys) and processing (e.g. decision-making process) is essential, since this information could be used in a replay or man-in-the-middle attack on the system. It is relatively hard to detect interception of sensitive information when it is transmitted and a skillful attacker would be likely to succeed without being detected, making the access control system pointless, dangerous (because of misplaced trust) and cost-inefficient. It follows that the system should be designed so far as possible to avoid making sensitive information freely available to external actors. In the event of failure, the system should fail securely: its default failure state should be one of denial of access. Refer to Section 3.4.1 for a discussion of threats to the proposed system. Resilience and Reliability As far as the Assurance/Availability security attribute is concerned, the system should be able to withstand all known types of attack (e.g. man-in-themiddle) originating in the environment, and should be designed to have a good chance of recovering from unknown types of attack. The system should also be resilient in the event of natural disasters (e.g. floods) and performance of its core functions (e.g. ability to store vital data, and decision-making capabilities) should be guaranteed under harsh operating conditions (e.g. high humidity, vibration). These requirements rule out a system design which relies on being constantly connected or highly centralised, i.e. a system design which has a single point of failure should not be considered. From this it follows that system entities should be self-reliant in terms of resources required for vital functions; consumption of these resources should be minimised where necessary and possible. 3.1 Abstract System Analysis 13 The system should be hardened against attacks originating internally, within reason. For example, social engineering attacks against employees such as system administrators are always a possibility which means their privileges should be restricted, but the administrators require a a high level of trust to perform their organisational role; balancing the risk versus the cost of risk prevention is always a non-trivial problem. Granularity, Dynamism and Scalability Privilege administration should be fine-grained: the project would be pointless if too much access control functionality is sacrificed at the cost of, for example, optimising resource consumption. The system design should be dynamic and scalable, i.e. able to cope with demands that change over time, and should make provision for system expansion. Accountability Any access control system should allow administrators to keep track of user activity in order to make it feasible to hold a user accountable for their actions in case of a security breach (attempted or successful). It should also assist administration and distribution of access rights. In an access control system which relies on physical tokens like door keys it is hard to determine who has a key at any time, how many copies there are in the system, and each one’s history. Consequently, revocation of keys and updating door locks can not be accomplished correctly or at low cost, nor is it possible to ensure efficiency in terms of man-hours spent on administration. These issues should be addressed by a DPACS if it is to be a viable solution. User-friendliness A field study [22] focussing on user behaviour in a DPAC which uses smartphones as tokens concluded that the importance of the psychological impact on users of having an unobtrusive, fast, reliable and simple access control system should not be underestimated. The main advantage of not using multiple physical tokens for resource access is user-friendliness: every additional token requires more time and space overhead during user-system interaction and requires more space for storage. Having one token which stores the information required by any user-system interaction is also less obtrusive and ergonomic. 14 3 System Design Cost The component, installation, running and maintenance costs should not be too high, otherwise a centralised system would be more cost-efficient even though less reliable. 3.1.3 Proposed system The GST model of an LRDPACS which would embody the required functionality is presented; a discussion of development considerations (including constraints) follows in Section 3.2. Fig. 3.1. A conceptual schematic of the system. The organisation’s DPAC infrastructure can be modelled as follows (refer to Fig. 3.2): entities include the central administration server, clients, resources integrated with Access Decision and Enforcement Points (ADEPs), and the infrastructure facilitating information flow between the abovementioned entities. Entities also include processes such as authentication by the client and decision-making by an ADEP. The system proposed by Cao Ling [10] entails that a mobile client submits an access request to a remote, networked access enforcement point (AEP) which forwards the request to a central where an access decision is made and returned to the AEP to be enforced. LRDPACS extends this model in terms of decentralisation of access control: access decisions are made by the ADEPs, rather than by the central server as in Ling’s model. The only way for a client to obtain access to a resource is via the ADEP which has ownership of that resource. This greatly reduces the server’s workload and resource consumption: it assumes a co-ordinating and administrative rather than active function. Furthermore, it makes the entire system less vulnerable to failure (e.g. in case of a disaster) since individual ADEPs are not dependent on the central server when making access decisions or obtaining required access control information. The system is distributed in the sense that its physical boundaries are not the same as its logical boundaries: the resources and ADEPs can be geographically remote and physically separate from the rest of the organisational in- 3.1 Abstract System Analysis 15 frastructure, but form part of the logical AC structure. Hence, an ADEP and its resource form a physical island in the sea of the environment, delimited by the components and interaction (e.g. the ADEP for a door is physically connected to the lock and part of the door), while being logically a part of the system. Clients are mobile islands, physically merging with the resource islands or the rest of the infrastucture. Physical distribution of the system’s resources and decentralised control over their application makes sense from the reliability perspective: a disaster or attack will take significant time to directly affect remote resources, yet a targeted attack can easily compromise the centralised control infrastructure [23]. The LRDPACS is designed to function under circumstances when network or power connections to outlying resources cannot be established or are unreliable, and to preserve as much system functionality (i.e. user access to remote resources) as possible. 3.1.4 Entities Fig. 3.2. System entities, boundaries and information flows Fig. 3.2 depicts the system from a GST perspective. Note that clients are mobile and can access resources from inside our outside the system’s physical boundaries. 16 3 System Design Objects According to the GST view, an object in the system has two defining fields, namely “Attributes” (circumscriptive features) and “Functions” (abilities and actions). • Resource: As mentioned above, an ADEP determines and enforces access rights to its resource (i.e. there is a one-to-one mapping between ADEP and resource). The ADEP and its resource are considered to be integrated, but note that the policy mentioned below is used by the ADEP and not by the resource. Low-level (i.e. at least up to Evaluation Assurance Level 4) confidentiality and integrity of all information stored and processed by the ADEP is assumed to be guaranteed. Availability of functionality is assumed under reasonable operating circumstances, i.e. no compensation is made for extreme natural forces and disastrous events. – Attributes: a unique identifier, and policy. – Functions: The Policy Decision Point (PDP) is an implementation of the access decision algorithm (Section 3.4.1). The Policy Enforcement Point (PEP) takes the output of the PDP and enforces it (if applicable). Example actions: updating the root policy with one supplied by the client, or opening a lock. • Server: The central server stores various types of information relating to its privilege, key, resource and client management functions. Like the ADEP the server is assumed to ensure confidentiality and integrity at low level of all information it stores and processes, and to be immune to internal attacks (e.g. social engineering, viruses). It is assumed that backup of all information is done regularly and can be restored quickly. A backup server running in parallel is recommended but not necessary, since access to resources does not depend on it. – Attributes: PKI public-private keypair (refer to the Authentication process described in Section 3.1.4), lists of client certificates, clients, groups (including their privilege) and resources (ADEPs), client-group mappings, group-resource mappings, and policies which encode the mappings. – Functions: maintenance of client, group, resource and privilege lists and mappings, and generation and issuing of policies (both client and ADEP) and client certificates. • Client: A client is a token physically carried around by a human user; clients and users have a one-to-one relationship. A client can communicate with either the server or the ADEP (if it is within range), but not both at once. The client is assumed to store sensitive information (i.e. its 3.1 Abstract System Analysis 17 private key) confidentially and to ensure its integrity. This is not essential in the case of other information, since the server and ADEP require client authentication, and the ADEP validates client-submitted information. – Attributes: PKI public-private keypair, an unencrypted, signed policy for each group to which it belongs, and an encrypted certificate proving its identity and group membership. – Functions: register with central server, receive certificate and policies, and provide these to an ADEP. • Infrastructure: This is the integrated framework of hardware, protocols, software, etc. which allow the abovementioned objects to interact safely and successfully, the processes to be performed correctly, and the relational integrity to be preserved. Processes • Authentication: The decision to use an asymmetric cryptographical system (PKI, e.g. RSA) rather than a symmetrical one (shared key, e.g. AES) was influenced by the former’s use in certificates which are essential for trust-delegation systems (see Sections 3.1.5 and 3.1.5). A client authenticates itself using PKI and a challenge-response model on two occasions: firstly, when it obtains a certificate and/or policies from the server; secondly, when it supplies this information to the ADEP in an access request. The authentication process is essentially the same in both cases and is described in the first parts of the algorithms in Section 3.4. The client implicitly trusts the central server and ADEP, and they do not authenticate themselves to the client. The motivation is as follows: 1. The functional requirements specify that communication should be confidential as far as possible; this is most easily accomplished by ensuring that communication takes place over extremely short distances, which would make it unlikely that the user of the client device will be unaware if a third party attempts to initiate an impersonation attack on the client. 2. If an interception attack succeeds against the system, the information that is revealed about the client should not compromise the integrity and availability of the system. Ensuring this means a third party wishing to impersonate a client cannot do so: some of the client information essential for authenticating itself is never revealed (i.e. its private key: see Section 3.4). The most feasible alternative method of attack is a Denial-of-Service (DoS) against an ADEP where an attacker pretends to be a client: the 18 3 System Design attacker will succeed in proceeding exactly one step further in the authentication process - i.e. supplying a fake certificate - before being rejected because they are unable to prove their identity. Refer to Section 3.4.1. 3. Requiring authentication by the server/ADEP to the client would not provide sufficient additional security to justify the increased resource overheads: if an attacker managed to impersonate a client (which is the most vulnerable entity in the system), the server/ADEP-side of the authentication step becomes irrelevant. Note that the electrical power consumed by each step in the ADEP algorithm is not known, and should be investigated (as mentioned in Section 6.2) in order to determine the exploitation potential; currently not enough information about this is available to justify including mutual authentication between client and ADEP. The additional power and memory consumption would be completely wasted from the ADEP’s point of view, and would be contrary to the functional requirement that resource consumption should be minimised by default and as far as reasonably possible. Section 3.4.1 contains further discussion on threats to LRDPACS. • Configuration: The configuration of the objects in the system is initially done by administrative staff: first, the necessary runtime software is loaded on the server, client and ADEP. Second, the basic configuration of this software is done (e.g. key-pair generation). Third, the necessary client, resource, group and privilege relationships are established in the database by the staff. After this the Client Information Distribution flow continues, with the variation here that the client policy will contain a new ADEP policy, which is destined to overwrite the default ADEP policy. • Client Information Distribution: The client requests an access rights update from the server which then generates a new certificate for the client, as well as a policy for each group to which the client belongs. The scheduling of these credential renewals is done by administrative staff (e.g. the client certificate does not have to be updated every time the client requests an AR update). The credentials are then sent to the client which stores them, and later presents a subset of them to an ADEP as part of an access request. • Access Decision: The ADEP’s access decision and enforcement thereof takes place locally, using only resources locally available, and represents the core functionality of the system and culmination of a User Information Flow. Section 3.4.1 describes the algorithm. 3.1 Abstract System Analysis 19 Fig. 3.3. Configuration Process Fig. 3.4. Client Access Rights distribution and use • Maintenance: The administrative staff perform the necessary administration tasks on the information in the server, as described in its functions. Updating a client takes place as described in Client Information Distri- 20 3 System Design bution process described above. Updating an ADEP takes place as in the last part of the Configuration process. The administrative advantages of having a client carry their own credentials and access control information (i.e. policies) are significant: users can be employed to update ADEPs’ policies in the course of their normal functions without being aware of doing so, which simplifies policy distribution and makes it more cost-effective. It should be noted that the processes above describe aspects of information flow via a channel from the server to the client and then to the ADEP, but no reverse flow of information exists, due to the nature of the trust and delegation relationships between these objects. 3.1.5 Relationships Relationships exist in various forms: Groups and Roles In RBAC systems, the organisational role of a user determines their access rights to resources. We will assume that users can be grouped together if they have the same role, and the group has a one-to-one relationship with the role. This leads us to not distinguish semantically between the terms “role” and “group”, and they are used interchangeably in this report. As mentioned in Section 2.1, this issue is considered a grey area even by experts in the RBAC field, and no consensus has been reached in the ongoing debate on this topic. Each client belongs to one or more groups and a group has one or more client members. A group has a privilege or right which applies to a set of one or more resources. Each group has its own policy which implements this mapping. This model may seem restrictive at first glance, but it satisfies the scaling and dynamic functional requirements: system growth and changes in client-privilege mappings are feasible and practical within reasonable bounds. This way of mapping of clients to resource privileges allows for finegrained access control (i.e. assigning to a particular user exactly those rights they need - no more and no less), and facilitates dynamic administration (updating these mappings as requirements change) since it is a technique which scales well. LRDPACS is designed with the goal of reducing complexity and resource consumption while maintaining a high level of flexibility, scalability, reliability and security. To this end, the group trees are limited to a depth of one level, thus altogether avoiding the problems of hidden membership and hidden privilege since there is no nesting of groups (refer to Section 2.2 for more detail). 3.1 Abstract System Analysis 21 Fig. 3.5. Entity-Relationship Diagram Policies Policies state the relationships between clients, groups, resources and privileges. An Access Control List (ACL) does not allow delegation of trust and privilege, nor does it allow complex group and privilege relationships to be represented and processed efficiently. ACL-based protocols also do not facilitate changes or updates to the protocol. A policy-based access control protocol does not have these problems, but requires substantially more resources to represent and process even simple relationships. LRDPACS should incorporate maximum functionality and dynamism, which motivates the choice of policies to encode access information. Trust “Trust” is the belief - based on certain evidence - by one party that the other party is who they claim they are and conform to a particular pattern of behaviour. In some cases, no evidence is required; e.g. the trust can be implicit, as in the case of the client’s trust in the server. In the LRDPACS, the client implicitly and always trusts both server and ADEP, which is appropriate since it is the supplicant, and also never reveals 22 3 System Design Fig. 3.6. Trust in the system sufficient information for impersonation attacks to be feasible. Once the client has authenticated itself to the central server, the server is assured of the client’s identity and trusts that it can safely send access rights to the client for the duration of the session. The server assumes that its commands to the client (e.g. client deletion of a policy revoked by the server) are correctly carried out; if a storage error occurs client-side, the client software will detect this and notify the server and user. It is then up to the user to reset their client software or to contact the system administrator for assistance. The ADEP trusts the client for a session if it authenticates itself by presenting its certificate generated and signed by the server. Before trusting policies submitted by the client the ADEP verifies that they originate from the central server. The ADEP implicitly and permanently trusts the server to generate access rights and credentials. The following section discusses this in more detail. Delegation “Delegation” means to authorise someone to act as your agent by granting them certain privileges, and is based on conferred trust. Delegation is similar to Discretionary Access Control (DAC) [24] in that a user can grant both access and administrative privileges (but not one or the other) to some other user; the difference between these methodologies is that a delegation policy specifically states who may receive the privilege, whereas DAC allows any user to receive the privilege unless explicitly forbidden. 3.2 Development Considerations 23 Fig. 3.7. Delegation in the system The ADEP is considered to be the authority root since it performs the access request evaluation and enforcement. It delegates administrative rights to a central server to perform all issuing of access policies to clients in its stead. The ADEP also delegates the specification of its root policy to the server, and obtains a new root policy via the normal channel as an “upload” request; after validating it, the client assumes that the new root policy is safe to be used. The ADEP trusts the server to establish policies which will not compromise the system, but it has no way of determining whether a valid policy is “harmful” or not. 3.2 Development Considerations Having specified the theoretical structure of the LRDPACS, we consider the choice of hardware and software components and the functionality conveyed by each component; these will unavoidably impose more constraints on the architecture. 3.2.1 Component Choice The server and client communication should take place via WAP which is widely implemented in most mobile devices, and is relatively fast and stable and has good geographical coverage. Interaction between ADEP and client will take place using Near Field Communication (NFC). The advantages of using NFC are numerous: 24 3 System Design • Secure: The maximum signal range is 10cm, which makes it less susceptible to eavesdropping and interference without detection; established protocols such as Bluetooth or RFID work over much longer distances (ca. 1-5m). • Low Power Consumption: NFC and devices supporting it are designed to consume very little electrical power. • Standardised: The protocol is well-defined, and is supported by leading companies in the industry like Sony and Philips (NXP) [25, 26], Nokia [27], Samsung [28], SanDisk [29], etc. • Future Growth: Several bodies (e.g. NFC Forum [30]) promote development co-operation between vendors and service providers with the goal of making NFC as ubiquitous as RFID and Bluetooth. The protocol is gaining popularity and is expected to be widely implemented in a variety of roles (e.g. ticketing, payment and customer loyalty systems) over the next five years [31, 32, 33]. Using a mobile phone with embedded NFC capability as client has the following advantages: • Secure: The phone provides secure storage in its memory card, SIM card or Secure Chip (as well as secure processing in the case of the latter). Future mobile phones may contain a third-party Secure Module incorporating all NFC functions including storage, but this is still under discussion - no development has been done in this direction. • User-friendly: This is one of the main advantages from the client perspective, since the user merely has to take the phone out of their pocket and present it to the reader for one or two seconds. Furthermore, an NFCcapable phone can be used in many systems other than the LRDPACS, which means that the LRDPACS security is enhanced: a user is unlikely to lose their phone without noticing it soon and taking appropriate steps, and they would also not easily consider lending their phone out since it functions as an e-wallet. • Affordable: Even though NFC products do not dominate the market, vendors attempt to keep their prices reasonably low in order to promote wider adoption of their wares. Once the technology is ubiquitous, prices are expected to drop as vendors compete with each other for market share. Development of a limited resources ADEP is feasible and affordable, since the basic components are already available: currently NXP - a spin-off company of Philips - has the greater part of the components market, and offers its products at reasonable prices. In most of their components storage and processing 3.2 Development Considerations 25 of information is secure and reliable. A small number of vendors provide electromechanical locks (for example ASSA ABLOY). The central server can be any computer (desktop or dedicated server) featuring a minimal amount of memory and a reasonably powerful processor, and supporting an off-the-shelf NFC-reader (e.g. Omnikey [34], Feig [35]). Following the general choices for hardware, specific choices have to be made so that a initial point for development can be established. Since hardware vendors usually design their products to support the prevailing industry standard software, the decision was made to first specify the software for each object in the system, and then the hardware. JCOP [36] by IBM was chosen as operating system for the ADEP: it is wellestablished in the industry as one of the leading operating systems for Smart Cards and limited embedded systems, with a large developer base and extensive support network. Its development environment is JCOP Tools [37] which implements JavaCard [38], a specialised subset of Java by Sun Microsystems for smart cards which is compatible with the widely-used OpenCard Platform (OCF) [39] standard for Java in smart cards. J2ME was chosen as software environment for the client, since it is platform-independent and very popular among vendors and developers, and is continually being developed and improved. J2ME code developed for one mobile phone profile can be easily adapted for a different Mobile Information Device Profile (MIDP) since it is built using Sun Microsystems’ Wireless Toolkit (WTK) [40]. However, implementation of NFC in mobile devices is as of January 2007 - still vendor-dependent: the standardised API for NFC implementation in J2ME, Java Specification Request 257 (J2ME Contactless Communications API) [41], was released in August 2006, but does not include support for NFC because the NFC Forum had not completed all aspects of the protocol specification (e.g. NFC peer-to-peer communication) when the JSR was released. It is expected that JSR257 will soon be updated to include all NFC features and functionality. In short, for the foreseen future any J2ME midlet development will require proprietary drivers and API. Nokia has a great commercial interest in NFC implementation in mobile phones, and has been driving the development of related software tools (e.g. “Carbide.j” a.k.a. the Nokia Developer’s Suite for J2ME [42]). Taking these facts into consideration, and also the popularity of Nokia’s software development tools, we recommend using Carbide.j and WTK for development of the client software. Java is recommended as a software environment for the server, for the same reasons listed above, and also because it has the Application-Programmer Interfaces (APIs) necessary for cryptographic functions (e.g. certificate generation) and database interaction. The database software and operating system 26 3 System Design on the server are flexible choices, since there is great compatibility between the various software packages. Since the ADEP should be compatible with JCOP, support NFC and cryptographic functions, provide secure storage, and should also be designed to optimise the usage of its limited resources, a microcontroller similar to those embedded in Smart Cards would be suitable (e.g. NXP’s PN65K 1 ). Additionally, a circuit board with antenna, crystal oscillator, power supply (battery) and actuation relay would be required: this could be built using the vendorsupplied or in-house-designed blueprint and using off-the-shelf components. The actuation relay outputs power when access is granted, and the EM lock should have a simple two-contact-pin interface which opens when power is applied and closes when the power is cut off. This makes the system extremely flexible since can it can be adapted to the requirements of almost any door or security device. Note that the proposed system components and software make it feasible to ensure a safe default state in case of failure: e.g. a run-time environment based on Java relies on a secure virtual machine and incorporates exception management which makes it easy to control the state of the system even when errors occur on application or system level. 3.2.2 Resulting Constraints The software constraints imposed by JCOP and JavaCard Runtime Environment include a lack of support for code recursion and system time functions. Integrated circuits used in smart cards have very little memory (the PN65K has 72 KB of EEPROM for non-volatile storage, 160 KB of ROM for static code, and about 4 KB of RAM for volatile storage), slow processing units and no network connectivity. Information Flow There is a flow of information from server to ADEP via the client but the reverse is not true: the client is considered unreliable and unpredictable in its behaviour because it is mobile and can physically enter the environment outside the system boundaries. This severely constrains the possibilities for including client accountability as well as certificate and policy revocation. Accountability Realtime reporting of access requests by clients and ADEP access decisions and status cannot be communicated with the central server, since there is 1 http://www.nxp.com/acrobat/other/identification/sfs_pn65k_rev1_3.pdf 3.3 Policy Language 27 no reverse communication channel. Consequently, clients can not be held accountable for accessing resources, and policies must be issued while keeping this in mind: the principle of least privilege (i.e. a client must be able to access only those resources which they require to fulfil their function) must be prioritised and consistently followed. Revocation The LRDPACS cannot rely on timestamps in policies to facilitate fine-grained access control, since the ADEP does not keep track of time. It follows that the ADEP can, at best, determine what the most recently client-submitted timestamp is, i.e. it cannot be proven that the actual time is not later. The only possible timestamp functionality is that of supercession of access information: the ADEP can compare the issue date and time of a client policy or certificate with that of its own policy to determine whether it is of valid age. If the client could be trusted, it would serve as source for timestamps for the ADEP. Another possibility is for the client to download signed timestamps from a trusted timestamp authority, but this might cause delays during the access request submission process. Revocation of certificates and policies can be done only when the client interacts with the server, i.e. when the client requests new ones: the server instructs the client to delete its certificate or specified policies. Subsequent access requests by the client to ADEPs will be denied based on whether the policy or certificate is respectively outdated or invalid. It is the client’s responsibility to manage its stored access rights, since the server cannot enforce actions taken by the client. Future improvements in this area might include implementing RMI and signing the client MIDlet (see Sections 4.3.2 and 4.4.1). 3.3 Policy Language The Limited Policy Language (LPL) is used to encode policies, and is derived from the OASIS eXtensible Access Control Markup Language 2.0 (XACML) [43]. The decision to define LPL as a subset of XACML is based on the following reasons: 1. XACML is generic and applicable to any infrastructure, lends itself to creating distributed policies, and is well-documented. 2. An administrative system using XACML for encoding policies could also be used for administration of LRDPACS policies: translation between XACML and LPL could be done with little difficulty. 28 3 System Design 3. Anyone who knows XACML will be able to familiarise themselves with LPL within a relatively short time, and combined with XACML’s increasing popularity in and support by the industry [44] this means that LRDPACS will more easily gain market share if it undergoes further development and enters production. 3.3.1 Policy Language Model The model in Figure 3.8 is a trimmed-down version of the one described in the XACML specification [43, page 19]. Fig. 3.8. Policy Language Model Target A target consists of a combination of a set of one or more resources, a set of one or more subjects and a set of one or more actions. Figures 3.9,3.10, and 3.11 depict this in more detail. Policy A policy has exactly one target, and vice versa. A policy target can be described as the formal mapping of the relationships between groups, privileges and resources (refer to Figure 3.5 for the relations between groups and policies). The policy target of a client differs from that of an ADEP: 3.4 Architecture 29 • A client policy target has exactly a subject set consisting of one element, namely the group to which the policy applies, whereas an ADEP policy target has a subject set of one or more groups. • The ADEP policy target’s resource set contains only the ADEP (policy owner) identity, while the client policy target specifies that its resource set contains one or more ADEP identities. • The action set in the client policy target contains exactly one action or privilege, but the ADEP policy target’s action set defines all possible actions that this ADEP allows. PolicySet A policyset consists of one or more policies and one target. A policyset target is defined as the union of the targets of policies belonging to the policyset. The rule for combining results of evaluating policies in the policyset is “permit overrides”: if any of the policies being evaluated result in “allow”, this will be the result for the policyset. Note that a policyset for a client differs from that of an ADEP: • A client policyset can contain many policies, while the ADEP policy (“root” policy) contains only one policy. • It follows that the ADEP policyset and policy target are equal to each other, while this is not true for a client. 3.4 Architecture Figures 3.9, 3.10 and 3.11 define the information contained by the objects in the system, as referred to by the server-side and ADEP-side algorithms. 3.4.1 Algorithms The following algorithms describe the interaction between objects in the system. Refer to Figures 3.12 and 3.13 Fig. 3.9. Server fields 30 3 System Design Fig. 3.10. Client fields Fig. 3.11. ADEP fields Server-side Algorithm Administrative staff ensure that client xj ’s information (public key, group membership, certificate, policies) as well as the group-privilege mappings in the database on server z is updated prior to this interaction. 1. Authentication: 1.1. xj sends its public key Kxj to z. 1.2. If Kxj is not in z’s database then 1.2.1. Client not listed: go to 5. 3.4 Architecture 31 Fig. 3.12. Scenario: succesful AR download (no revocation) 1.3. z sends the message digest of a timestamp as challenge to xj . 1.4. xj returns the challenge signed with its private key Kxj . 1.5. z verifies the signature using Kxj . 1.6. If verification fails then 1.6.1. Authentication failed: go to 5. 2. Certificate management: 2.1. If xj ’s certificate C stored in z’s database is marked as “to issue” then 2.1.1. Send C to xj , which overwrites the older certificate if it exists. 2.1.2. Mark C in the database as “issued”. 2.2. Else, if xj ’s certificate C stored in z’s database is marked as “to revoke” then 2.2.1. Instruct xj to delete its certificate. 2.2.2. Delete C from the database. 3. Policy management: 3.1. In z’s database, for each issued policy P which is in xj ’s “to revoke” list: 3.1.1. Instruct xj to delete policy P . 3.1.2. Update database: remove the P entry from xj ’s “to revoke” list. 4. In z’s database, for each issued policy P which is in xj ’s “to issue” list: 4.1. Send policy P to xj . 4.2. Update database: remove the P entry from xj ’s “to issue” list. 5. End. 32 3 System Design Comments: • The authentication security model is one-way challenge-response, and forces the client to prove it possesses the private key matching its advertised public key at the moment of the transaction. Also, the server requires that the client’s public key is in its database: this allows a mapping between the client’s key-pair and its identity in the organisation’s administrative system. If the client succeeds in doing this, the server trusts it and is prepare to vouch for its identity by issuing a signed certificate containing the client public key. • The challenge sent by the server to the client is the message digest of a timestamp (refer to Section 3.1.4). • The client MIDlet must be considered untrustworthy by default (Sections 3.4.1 and 6.2 discusses this issue). The server application should enforce adherence by the client to the above algorithm as far as possible. ADEP-side Algorithm Fig. 3.13. Scenario: successful AR submission 1. Authentication: 1.1. Client xj sends its certificate C to ADEP yk . 1.2. yk checks that its copy (in its root policy R) of the message digest of the server z’s public key Kz is the same as the message digest created from the server public key contained in C, i.e. h(C.Kz ) = R.h(Kz ). 3.4 Architecture 33 1.3. yk uses Kz to verify the certificate’s signature, and obtains the client’s public key Kxj from the certificate. 1.4. If either of the above steps failed, then 1.4.1. Authentication failed: go to 5. 1.5. yk sends a random number as challenge to xj . 1.6. yk sends its unique identifier (R.yk ) to xj . 1.7. xj replies with the response, namely the challenge signed with its private key Kxj . 1.8. yk verifies the response signature using Kxj . 1.9. If the verification fails, then 1.9.1. Authentication failed: go to 5. 2. xj submits an access request to yk consisting of a policy P . 3. yk evaluates the following conditions: 3.1. Proof of client policy origin (1): the policy’s message digest of the server public key is compared with the ADEP’s copy, i.e. P.h(Kz ) = R.h(Kz ). 3.2. Proof of client policy origin (2): policy signature P.S of the policy data fields is verified using Kz . This also confirms that the policy data has not changed since it was issued. 3.3. Proof of client group membership: the client policy’s subject (group) is an element of the set of all groups to which the client belongs: P.gi ∈ C.G. 3.4. Proof of client policy validity: the ADEP policy and client certificate is older than the client policy (R.T < P.T , C.T < P.T ). 3.5. Applicability of client policy: the client policy’s associated group is in the set of groups which may apply for access to this ADEP (P.gi ∈ R.G), and this ADEP is in the client policy’s allowed resource list (R.yk ∈ P.Y ). 3.6. Validity of access privilege: the client policy’s action is in the ADEP’s set of allowed actions (P.a ∈ R.A). 3.7. If all of the above are true, then 3.7.1. Go to 4. else if the client has more policies to submit, then 3.7.2. Go to 2. else 3.7.3. Go to 5. 4. Access granted: 4.1. Output P to the Policy Enforcement Point for actuation. 4.2. Go to 6. 5. Access denied: 34 3 System Design 6. End. Comments: • The authentication method is similar to that described in the Server Algorithm, with the exception that the ADEP does not require a database containing the client’s public key, and the challenge is a random number. • At installation time, the ADEP has no root policy Ryk and does not know the server’s public key Kz . If the policy being submitted by the client does not contain a reconfiguration policy, the algorithm rejects the server public key and ends. Otherwise, the integrity of the reconfiguration policy is verified (Step 3.2) using the server public key from the clien certificate, after which the algorithm proceeds to Step 4 where the new root policy is loaded, and the algorithm ends. • The ADEP’s root policy can be updated by a client policy containing a reconfiguration policy, but only if all the conditions are satisfied in the algorithm above. For example, if the server’s public key has changed, a client would authenticate itself with a certificate signed with and containing the old public key, and would submit a reconfiguration policy containing a new ADEP root policy which contains the server’s new public key. After successful loading of the new root policy, the ADEP will not accept client certificates containing the old server public key. • Step 3.1 is done before step 3.2, because checking the client policy’s “Issuer identity” field (P.h(Kz )) is computationally much less expensive than verifying the policy’s signature; this is the best way to detect policies which originated from an incorrect issuing authority. Threats against LRDPACS Attacks with the highest estimated likelihood of being attempted and the greatest potential impact are discussed first. Please refer to the description of the Authentication process (Section 3.1.4) and to the functional requirements list (Section 3.1.2) for additional information. 1. Denial of service: The Denial of Service (DoS) class of attacks pose the greatest threat to continued operation of and service delivery by the system. The server can be flooded with AR download requests which prevent legitimate clients from updating their credentials, but with sufficiently advanced traffic analysis algorithms in the server firewall these attempts can be logged, analysed, predicted and blocked. 3.4 Architecture 35 The client is less vulnerable, since it is the initiator of communication with external entities; however, while it communicates with the server or ADEP, interference with traffic (TCP/IP or NFC) can prevent it from completing a session correctly. Countermeasures such as logging and detecting DoS attempts would impose high overheads on the client MIDlet and especially its applet, so any such measures should be implemented using best design practices and only after careful consideration of the DoS threat’s impact in a specific system. If an ADEP relies on internal battery power, DoS attacks would succeed in draining its battery and ultimately cause it to shut down, denying other subsequent clients from gaining access to the resource. Possible countermeasures include logging and detection of attempts, but, as mentioned above, these countermeasures come at an excessively high price. A better solution would be to implement an RF beacon in the ADEP which activates and notifies the central server if any DoS (and even other types of) attempts are detected, but this would go against the design principle of access control points which are independent of a central infrastructure. 2. Penetration: The server is easily shielded against penetration attacks with a firewall, traffic analysis modules, and possibly counter-attack modules. External penetration of the server is not considered a serious threat, but internal attacks via social engineering are a major risk. The client MIDlet may be modified via internal (hardware analysis and code reverse engineering) or external methods (service exploits, e.g. BlueTooth). The MIDlet code executes inside a Java Virtual Machine (JVM) which does not allow runtime modification of the MIDlet’s memory space. However, an attacker could modify the client MIDlet program code before it is executed without being detected if the MIDlet is not signed (refer to Section 4.3.2). One counter-measure is obfuscation of the MIDlet package at compile time: this makes it much harder for an attacker to gain insight into the code through inspection. Such an attack would require complete reverse engineering of the code and would be highly resource intensive, and is thus not considered likely. The client applet is not considered vulnerable, since it is stored and runs in an applet on a Secure Chip similar to those used in smart cards (see immediately below). The ADEP should contain a mechanism for detecting and preventing penetration and modification attacks; without this, it is not useful as a trusted platform. Fortunately, most smart cards are equipped with applet firewalls which are highly effective in preventing abuse of legitimate channels and privileges. 36 3 System Design 3. Impersonation: Impersonation of the server or ADEP might be attempted to gather information about the client (e.g. building a dictionary of message digests for authentication); these can occur, but are ultimately pointless because of the security architecture used (Section 3.4): neither the client’s private key, which is essential to the authentication process, nor the server’s private key, which is used for all server signatures in certificates and policies, are ever revealed. The most critical point is the registration of a new client with the server: the server explicitly conveys trust and authority to the client by creating an entry in its database, which will later be used when a client certificate is issued. It is recommended that the system administrator be in close physical proximity to a user when registering their phone, in order to verify the user’s identity and the phone’s serial number. O 4 Implementation 4.1 Proof-of-concept Detail Development and implementation of a proof-of-concept system serves a triple purpose: firstly, it serves to demonstrate that the core functionality, features and protocols of the designed LRDPAC system can be successfully implemented under the constraints discussed in the previous chapter; secondly, the code developed is portable and can be re-used in further development; thirdly, experience obtained from the development process will be invaluable for any future work on the LRDPAC system as well as in implementations in related fields. The proof-of-concept implementation incorporates the following features: • Authentication protocol between client and server/ADEP; • Management of client access rights (AR’s; i.e. certificates and policies) by the server, including issuing and revocation of policies to/from a physically remote client, and keeping track of these actions; • Secure storage of the AR’s by the client; • Submission of AR’s by the client to an ADEP; • Evaluation (including verification and validation) of the submitted AR’s by the ADEP; • Enforcement of access decision by ADEP: uploading of new ADEP root policy by the client. Design and implementation has been done in such a way that the code generated and experience gained can be re-used when implementing the full system design. Due to various reasons, e.g. time and budget constraints, and the requirement of advanced electronical engineering expertise (point 2), the following features were not implemented: • User-friendly interface for use by the server administrator when managing policies; 38 4 Implementation • Enforcement of access decision by ADEP: granting physical access to a resource by sending an electronic signal to an external relay. 4.2 Resources Used 4.2.1 Software Development was done in Windows XP using the Eclipse software development environment. The server application was developed for Java v1.5.0.2, and MySql v5.0 (with MySQL-Java Connector v5.0.5) was used for database management. JCOP Tools v3.1.1b (Eclipse plugin) was used to develop the JavaCard v2.2.2 applets. The phone’s MIDlet required Carbide.j v1.5 (Nokia Developer’s Suite for J2ME), the Nokia Secure Chip SDK 1.0, and other software1 . 4.2.2 Hardware All development took place on a PC, and required contactless smart cards (JCOP v3.1) and a contactless card reader (Omnikey CardMan 5321). 4.3 Implementation Description Fig. 4.1. Proof-of-concept System Composition. 1 Refer to the SC SDK manual for the complete list of software. 4.3 Implementation Description 39 4.3.1 Server The server is a Java application running on a PC, and performs the following functions: • Management of entity relationships stored in a database; • Generation and management of the server’s RSA keypair (also stored in the database); • Processing of entity relational data and server public key into client-usable access rights (certificates and policies); • Issuing and revocation of access rights to the client, via TCP/IP. Entry of entity relationships into the database is the responsibility of the system administrator, and is most easily accomplished through the use of various scripts. 4.3.2 Client The client consists of a Java Mobile Edition (J2ME) MIDlet and JavaCard applet. The MIDlet runs on a Nokia 3220 mobile phone and performs the following functions: • • • • Serves as Graphical User Interface (GUI) for user of the mobile phone; Downloads AR’s from the server via a GPRS connection; Submits AR’s to the ADEP via NFC; Sends and receives AR data to/from the Secure Chip. The Nokia 3220 does not allow MIDlets to be signed and verified using custom root certificates: the MIDlet and code must be submitted to a trusted Certificate Authority (CA) such as Verisign or Thawte which will then perform a number of tests to determine whether the MIDlet meets the requirements of the testing authority. If it does, it is signed with the CA’s private key and returned to the developers can be installed on the Nokia phone which contains the CA’s certificate in its set of root certificates. However, this scheme is expensive: it costs about $200 per testing session per MIDlet. Furthermore, it can take months before a MIDlet is approved. Therefore, it was decided not to have the proof-of-concept MIDlet signed: it is to be considered completely untrustworthy when used in the field. The applet runs in the mobile phone’s Secure Chip (SC) and is responsible for: • Restricting access to the applet’s functions by way of a PIN; • Generating and managing the client’s RSA keypair; 40 4 Implementation • Securely storing and retrieving AR data (including the client’s public key) when requested by the MIDlet; • Generating on-demand signatures of challenges, using the client’s private key. 4.3.3 ADEP The ADEP is a JavaCard applet, designed to run on a contactless JavaCard. It enforces strict adherence to the ADEP algorithm (refer to 3.4.1) and determines whether Access Rights received from the client MIDlet are genuine, correct and applicable to its root policy. As mentioned in Section 4.1, enforcement of ordinary access control decisions (e.g. “open” command) has not been implemented. 4.4 Key Implementation Concerns The various problems which were encountered during development and implementation are described and their solutions are discussed. 4.4.1 Data Transmission Between Application and MIDlet The MIDlet requests AR’s from the server application via TCP/IP over WAP (GPRS) which can suffer serious delays in case of network congestion, which can in turn cause read timeouts at both the server application and MIDlet. To this end, it is desirable to synchronise communication between them, so that each side is aware of the other’s state and can anticipate its response, which reduces the chances of miscommunication. Requiring strict adherence to such a protocol follows logically, since it improves algorithmic efficiency: each state accepts only a few legitimate inputs and complex decision structures are avoided. The session data is sent in a stream, punctuated with control packets and length headers. The server application accepts and handles only one client connection at a time; multiple connections are not supported, since that would require extensive measures to ensure that server resources (database tables and application fields) are used safely and cannot cause server deadlocks. Note that the AR transmission process does not ensure the correctness of data transmitted or received, since that would impose time and processing overheads at the client’s side which are unnecessary due to two reasons: 4.4 Key Implementation Concerns 41 firstly, TCP/IP underlies ARTP and already ensures reliable, in-order delivery of packets; secondly, the ADEP will verify the AR’s that the client submit to it and reject invalid data. Between MIDlet and Applet Data exchange between the applet (client Secure Chip/ADEP) and MIDlet employs the message-passing or Application Protocol Data Unit (APDU) model rather than the Remote Method Invocation (RMI) model (refer to [45]). The second approach would allow more flexibility and abstraction of many of the implementation details (e.g. transmission control) and which would accordingly reduce development time, but unfortunately the version of JCOP which was available when proof-of-concept development started does not fully support JavaCard RMI. An additional barrier to implementation of the high-level protocols (e.g. authentication; AR transmission) was the lack of support by JCOP for the APDU Block protocol (parameter T=1) which allows sending of long (up to 32767B payload) messages. Only the default protocol (parameter T=0) was available, which restricts the message data length to ≈ 250 bytes and does not facilitate message chaining. A data transmission protocol incorporating chopping, chaining and synchronisation functionality for long messages had to be implemented on each side (J2ME and JavaCard). The JavaCard methods were implemented in a general manner which means they are usable by both applets without having to be customised, according to the principle of code re-use. The custom APDU chaining protocol is simple: the MIDlet and applet each has two methods, namely “send” and “receive”. The MIDlet initiates the sending or receiving of a long message by calling its relevant method, which then repeatedly sends APDUs to the applet where they are routed to the corresponding method. A single call of either of the applet methods involves a sub-block of data from the complete message, starting at an offset which the client explicitly specified (if it’s the first block) or which is implicity assumed (the default case: the offset is read from an internal counter in the applet). Note that the custom APDU chaining protocol is not responsible for ensuring reliable delivery, since the underlying APDU messaging protocol already performs this function. The custom protocol keeps track only of the progress of transmitting its current message and ensures that the entire message is transmitted. 42 4 Implementation 4.4.2 Data Storage and Retrieval Server Application Entity-relational and PKI data is stored on the server in a MySQL database; doing this facilitates access to data for testing purposes and also allows future development of e.g., the administrator GUI, to be done with ease: MySQL is a well-documented and an industry-accepted DBMS, and is compatible with many programming languages and operating systems. Data retrieved from the database, AR’s generated from this data, and data received from the client (after authentication) is not subjected to validation except for basic field value and length checks. The AR’s generated by the server application are signed with the server’s private key so that the ADEP can verify their correctness. Client MIDlet The client MIDlet serves as data transmission intermediary and does not perform any data validation other than field value and length checking. The MIDlet does not perform any housekeeping in the event of an interrupted AR download: the client applet handles all Secure Chip memory management. If the Secure Chip’s memory becomes full or unusable due to incomplete downloads, the user can choose to wipe the applet’s data via the MIDlet. Client and ADEP Applets The memory limitations of the JavaCards propagate throughout the proofof-concept system: for example, there is an upper value of 127 imposed on the number of groups, policies, resources and clients in the system. This limit can be increased if necessary, but this eventuality is not considered likely: each client can be a member of 127 groups, each of which can access 127 resources, giving a total of 16129 resources addressable per client. The typical “ordinary” policy has a size of about 320 bytes, and a “maintenance” policy containing an ADEP root policy is around 600 bytes in length. Certificates are around 800 bytes in size. The client applet stores its AR’s in byte arrays: it has one certificate, and allows dynamic allocation of policy arrays by way of an array of pointers. Memory management is done manually by applet methods which access the AR’s. The client keypair is stored in native key objects, and managed by the applet’s genKeyPair method. There is no method which allows retrieval of the private key by external entities, which means that its confidentiality is at least as safe as that of any other data in the smart card’s memory. 4.4 Key Implementation Concerns 43 Length and value checks are performed on data received, generated and retrieved by the client applet. The ADEP applet performs these same checks, and in addition confirms the origin and correctness of received data by signature verification. Furthermore, it requires that the received AR fields must meet certain validation requirements (i.e. applicability testing; for example, checking whether a policy timestamp is younger than the client’s certificate timestamp). The ADEP applet contains a root policy which is stored in a byte array; overwriting the root policy is possible if and only the new root policy contained in access rights presented by the client satisfies all the ADEP’s verification and validation requirements. Modification of the ADEP root policy is done atomically; that is, once overwriting of the policy has started, it is guaranteed to complete even in the case of a power failure. If the authentication by the client to the ADEP fails or is interrupted the ADEP applet resets all its submitted client fields to default values, which forces the client to start at the a new session from the beginning. However, if the client has been authenticated to the ADEP and a policy submission fails or is interrupted, only the submitted policy data in the ADEP applet is reset: the client’s authentication status is not reset. Should the client not adhere to any part of the AR submission protocol, an ADEP applet reset is triggered (similar to authentication failure). 4.4.3 Cryptographical Functions JavaCard implements a subset of the cryptographical functions available in Java and J2ME, and, since the entities in the proof-of-concept system should be cryptographically compatible, the JavaCard security API largely determined the choice of algorithms. PKI Keys Asymmetric cryptography was used throughout the system: public and private keys are generated according to the 2048-bit RSA protocol by the server application as well as the client applet. This keysize should provide sufficient security until the year 2030, as recommended by RSA Labs [46]. The implementation of the key generator differs between Java and JavaCard, but the resulting keys can be manipulated to be interoperable. Message Digests Message digests are used in these cases: 44 4 Implementation • During authentication, the server creates a 64-byte digest of the raw challenge data (a 17-byte timestamp). • The server is identified as the issuing authority by the ADEP which compares its copy of the digest of the server public key with the one included in a policy or recreated from the public key included in a certificate. • The server keeps track of issued policies using the digests of their signatures, as does the client applet. The server supplies a policy signature digest to the client when instructing that a policy should be revoked. Server authentication challenges are created using the SHA-512 algorithm, which is the logical choice considering the NIST recommendation and absence of server resource constraints. The algorithm used for non-authentication digests is SHA-1, which is not considered to be particularly strong: NIST has recommended that algorithms from the SHA-2 family (SHA-224, SHA-256, SHA-384, SHA-512) should be used rather than SHA-1 because of the latter’s cryptographic vulnerabilities [47]. However, the secrecy of plaintext in the AR’s is not important or even relevant: policies, certificates, and server/client public keys are not considered to be of a sensitive nature. These are transmitted in plaintext along with their signatures as part of the AR distribution and submission protocols. In short, SHA-1 is used here to ensure uniqueness of policy identifiers (i.e. to avoid the possibility of collisions) and to compress data rather than to obscure information. Signatures Signatures were used to provide means of verifying the correctness of data contained in a certificate and policy, and also to enable the client to authenticate itself by signing the server/ADEP challenge. In both cases creation of a signature involves a Java/JavaCard function which works as follows: first, create an initial SHA-1 digest of the plaintext; second, pad the digest according to the PKCS1 standard; third, sign the resulting data using the RSA algorithm and a private key. The verification of signatures is done by using the counterpart to the above function, which requires as parameters the plaintext, the signature and the public key complementing the private key. O 5 Evaluation 5.1 Implementation Description Development testing of the client MIDlet was accomplished using Nokia’s S40 mobile phone simulator coupled with the NFC phone cover emulator. The client and ADEP applets were tested in the JCOP Tools applet simulator (nCop), in the secure chip embedded in the phone, and also in contact and dual-interface (contact/contactless) smart cards. All the software functioned correctly when tested individually under these circumstances. The software components were also tested as depicted in Figure 5.1: the client MIDlet running in the mobile phone simulator connects to the client and ADEP applets running on a smart card via the NFC phone cover emulator and a card reader. Access Rights are downloaded to the client MIDlet via a TCP/IP connection (as in the case when using a real phone) from the server application. In this configuration, the results indicated correct functioning of all components. Fig. 5.1. Testbench composition 1 Testing the client MIDlet and client applet on a real phone (Nokia 3220 with NFC cover) similarly gave encouraging results: AR’s are successfully downloaded, stored, retrieved and revoked. However, when the phone is used 46 5 Evaluation in conjunction with an ADEP applet running on a contactless smart card, i.e. with the phone in NFC “active” mode and functioning as a card reader(refer to Figure 5.2), unexpected errors are reported by the smart card. Inspection revealed the cause to be ADEP instructions which require extensive processing time (e.g. generating RSA keypairs; creating or verifying a signature). These instructions are carried out correctly when the applet runs on exactly the same smart card but using a card reader connected to the PC, and also executes correctly when the applet runs in the smart card emulator. There have been no reports on any of the support websites of this error; nevertheless, because the other tests were successful, the conclusion is that the problem lies with the mobile phone. A possible explanation for this anomaly is that the request by the smart card to the phone for an extension in processing time is not handled correctly by the phone’s contactless card manager. We plan on testing the ADEP applet with other NFC-enabled mobile phones (e.g. the recently released Nokia 6131; the Samsung SGH-X700) in order to determine whether this is a modelspecific or manufacturer-specific bug, before reporting it to Nokia. Fig. 5.2. Testbench composition 2 5.2 Demonstration After installation of the MIDlet and applet on the client (in this case, the phone emulator and a smart card), the client must generate its RSA keypair by choosing “Reset SC”, as shown in Figure 5.3; this takes about 30 seconds for 2048-bit keys. When the client requests an AR download (Figure 5.4), it submits its public key as part of the authentication process. If the key is not in the server’s database, the server application will not recognise the client 5.2 Demonstration 47 Fig. 5.3. Client screenshots: generating a keypair. (Figure 5.5), and will report the client’s public key so that the administrator can enter it in a database. Fig. 5.4. Client screenshots: initial AR download. Fig. 5.5. Server screenshot: client public key not recognised. 48 5 Evaluation Once the key has been entered into the database, the client can again request an AR download from the server. The authentication process takes approximately 5-6 seconds when using the Nokia 3220, after which the server issues certificates and policies (ca. 2 seconds per item). AR revocation is not shown here, but typically takes 1 second per item. Figures 5.6 and 5.7 show respectively the server application and client MIDlet output after completion of the AR download. Fig. 5.6. Client screenshots: AR download successful. Fig. 5.7. Server screenshot: AR download successful. If one or more of the AR’s downloaded by the client contains a root policy, it can be uploaded to the applicable ADEP (as specified in the policy’s resource list) with the user in a “maintenance” role (Figure 5.8. Uploading a new ADEP root policy (Figure 5.9) takes approximately 510 seconds. Thereafter, the policy containing this root policy cannot be used again on this ADEP. The client might have other, newer “maintenance” policies: if so, these will be submitted sequentially. The user will usually submit “ordinary” access requests to the ADEP: for example, in the proof-of-concept system an ordinary access request involves 5.2 Demonstration 49 Fig. 5.8. Client screenshots: setting the client role via the “options” command. Fig. 5.9. Client screenshots: AR submission. the “open” action, as in the case where the ADEP controls the locking of a door. One such request takes about 5 seconds to be submitted and evaluated, but subsequent requests in the same session require only about 3 seconds, because the authentication step does not have to be repeated. The default operating mode of the client MIDlet is “ordinary” (the user does not have to set the role each time); the user only has to choose the “Submit AR” command as shown above and the applicable policies will be submitted sequentially (after client authentication) until one of these is approved or the end of the policy list is reached. O 6 Conclusion 6.1 Results The proof-of-concept implementation described in the previous two chapters performed adequately well and met our initial expectations: AR distribution does not take an impractical amount of time, and the ADEP is able to make access decisions within a reasonable length of time (5-10 seconds). Some unexpected problems arose (as mentioned in Chapter 5) but were, for the most part, circumvented or solved. The only insurmountable problem that was encountered was the incorrect functioning of the Nokia 3220 mobile phone when it is employed as a card reader. The lack of standards and component availability has been - and will continue to be - a significant impediment to development of NFC-related systems. The industry giants which have interests in promoting the widespread implementation of NFC in mobile devices will drive growth in this field, but we do not expect this to happen over night. In fact, the consensus is that NFC market penetration will be complete only by 2010-11, and this must be taken into account when designing access control systems which make use of NFC. 6.2 Future Research and Development Certain aspects of LRDPACS were not implemented in the proof-of-concept due to the scope of study and time constraints, e.g. system administrator interface and ADEP access decision enforcement. Other potential areas of research, listed in order of decreasing priority, include the following: • Access decision enforcement: a physical access control module interfacing with the ADEP should be developed so that the ADEP’s access decision can be enforced, e.g. an electromagnetic door lock and relay circuit. 52 6 Conclusion • Client-ADEP authentication: currently the client’s authentication to the ADEP and the processing of access requests take too long. Ideally, the entire process, from beginning of authentication to the end of the last access decision, should take no more than three seconds. One way to accomplish this would be to use symmetric crypto-algorithms instead of asymmetric algorithms for authentication, and to use smaller key sizes for both client authentication and verification of data. Another way to improve response and processing times is to design a dedicated hardware ADEP platform. Smart cards were not designed for fast data processing, and using them in the proof-of-concept implementation imposed certain feature and performance constraints on the rest of the system. • ADEP clock: providing the ADEP with some means of determining the time would allow a more stringent and flexible access control protocol, and would also make auditing functionality possible. • Network connectivity: it might be useful if the ADEP had network connectivity in scenarios where the ADEP’s root policy should be updated at short notice. For example, when a user’s mobile phone is stolen the current LRDPACS design requires that a technician physically visit and update remote ADEPs to which the user has access rights, which unavoidably imposes a delay of several hours or even days during which an attacker might gain access to sensitive resources. Connecting ADEPs to a central network (e.g. wired connections for ADEPs near fixed-line infrastructure, or wireless connections such as GSM or GPRS for remote ADEPs) would allow better control over system resources, increase system security and also allow auditing features. In short, the designing the current LRDPACS required a careful tradeoff between update time and survivability (i.e. independence of central infrastructure), but improvements are possible. • Client MIDlet as trusted entity: making the client completely trustworthy would be beneficial to the design of the system as a whole, and could be accomplished by using Java/JavaCard RMI and also by having the client MIDlet signed by a certification authority so that it can be verified before execution. Accomplishing this would greatly improve the LRDPAC system’s security, and would remove the unreliability associated with the client-side access rights revocation process. • ADEP dynamic memory management: ADEP memory management is restricted and primitive in the proof-of-concept implementation, and this could be improved so that more clients, resources, policies and groups can be addressed. 6.3 Conclusion 53 • Multiple client certificates: if a client were to have more than one certificate, this could make the LRDPAC system more flexible and adaptable to real-life scenarios. Modification of existing design and code to incorporate this feature can be done with little difficulty. • Vulnerability testing: any implementation of LRDPACS should be tested extensively for vulnerabilities, e.g. resilience against electro-magnetic interference, and emission by the ADEP of internal information via hidden channels such as power consumption. • Performance evaluation: various performance characteristics of the client and ADEP should be measured with the goal of optimisation, e.g. memory use and power consumption. • ADEP distribution: If the full LRDPAC system is to be implemented, one crucial issue that should be investigated is the business model concerning ADEP distribution to clients; for example, should ADEPs be preprogrammed by a central body and then distributed to customers via security brokers (e.g. Securitas), or would it be better to provide the end customer the possibility to program and maintain their own ADEPs? 6.3 Conclusion In this thesis the problem of physical access control in a distributed, resourcelimited system was described, and a solution - LRDPACS - was proposed and demonstrated. The LRDPAC design incorporates the majority of the functional requirements detailed in Section 3.1.2, and the proof-of-concept implementation served to demonstrate the feasibility of performing advanced access control decisions using extremely limited hardware obtained off-the-shelf without sacrificing functionality. The research done during the course of this thesis will be useful for design and implementation of LRDPAC-type systems: the major pitfalls that are likely to occur during similar projects have been pointed out, and a basis for further development has been established. Glossary AC AR ADEP API DPAC(S) GPRS GST GUI LRDPAC(S) MIDP NFC PDP PEP RFID SC SDK WAP Access Control Access Right Access Decision and Enforcement Point Application-Programmer Interface Distributed Physical Access Control (System) General Packet Radio Services General Systems Theory Graphical User Interface Limited Resource Distributed Physical Access Control (System) Mobile Information Device Platform Near Field Communication Policy Decision Point Policy Enforcement Point Radio Frequency IDentification Secure Chip Software Development Kit Wireless Application Protocol References 1. Matt Bishop. Computer Security: Art and Science. Addison-Wesley, first edition, 2003. 2. Michael P. Galleher, Allan C. O’Connor, and Brian Kropp. The economic impact of role-based access control. NIST Planning Report 02-1, March 2002. http://www.nist.gov/director/prog-ofc/report02-1.pdf. 3. Olav Bandmann, Babak Sadighi, and Olle Olsson. Decentralized management of access control. Technical report, SICS, 2001. http://www.sics.se/spot/document/FMVReport.ps. 4. William Stallings. Network Security Essentials: Applications and Standards. Prentice Hall, international edition, 2003. 5. Charlie Kaufman, Radia Perlman, and Mike Speciner. Network Security: Private Communication in a Public World. Prentice Hall, second edition, 2002. 6. Ravi Sandhu. Roles vs groups. In Proc. of the ACM RBAC Workshop. ACM 0-89791-759-6/95/0011, pages I25–I26, 1996. 7. RFID 101: A beginner’s guide to RFID. http://www.rfidgazette.org/2004/06/rfid_101.html, June 2004. 8. O. C´novas and A. F. G´mez. Delegation in distributed systems: Challenges and a o open issues. In Proc. of the TrustBus’03 Workshop. Dexa Conference, pages 499–503, September 2003. http://ditec.um.es/~ocanovas/papers/delegation.pdf. 9. O. C´novas and A.F. G´mez. A distributed credential management system for a o spki-based delegation scenarios. In Proc. of the 1st Annual PKI Research Workshop, April 2002. http://ditec.um.es/~ocanovas/papers/dcms.pdf. 10. C. Ling. Mobile phone-based authentication and authorization. Master’s thesis, Royal Institute of Technology, 2006. 11. O. C´novas, A.F. G´mez, H. Mart´ a o ınez, and G. Mart´ ınez. Different smartcard-based approaches to physical access control. In Proc. of INFRASEC 2002. Lecture Notes in Computer Science 2437, pages 214–216. Springer Verlag, October 2002. http://ditec.um.es/~ocanovas/dkronos.pdf. 12. Thomas Halvorsen and Haakon Eikenes. Mobile Key (mKey). http://wiki.unik.no/index.php/Main/RFID-Doorkeeper, October 2006. 58 References 13. International Standards Organization. ISO14443: Proximity Cards, October 2003. http://www.iso.org/iso/en/CatalogueDetailPage. CatalogueDetail?CSNUMBER=28728&ICS1=35&ICS2=240&ICS3=15. 14. International Standards Organization. ISO18092: Near Field Communication, January 2007. http://www.iso.org/iso/en/CatalogueDetailPage. CatalogueDetail?CSNUMBER=38578. 15. International Standards Organization. ISO15693: Vicinity Cards, July 2000. http://wg8.de/sd1.html,http://en.wikipedia.org/wiki/ISO_15693. 16. Jonathan Collins. Nfc-enabled phones to unlock hotel rooms. RFID Journal, June 2006. http://www.rfidjournal.com/article/view/2451/. 17. Index-Holdings. Index Okinawa launches FeliCa-enabled key entry system. 18. FeLiCa: An overview. http://www.sony.net/Products/felica/abt/dvs.html, 2007. 19. FeLiCa: Wikipedia. http://en.wikipedia.org/wiki/FeliCa, 2007. 20. MJST. RF Self-powered internal lock. http://www.power-in-lock.com/Security_Solutions_RFDL.htm. 21. Peter P. Schoderbek, Charles G. Schoderbek, and Asterios G. Kafalas. Management Systems. McGraw-Hill Companies Inc., custom edition, 1998. 22. L.Bauer, L.Cranor, M.K. Reiter, and K.Vaniea. Lessons learned from the deployment of a smartphone-based access-control system. Technical report, Carnegie Mellon University CyLab, 2006. http://www.cylab.cmu.edu/files/cmucylab06016.pdf. 23. R.Albert, H.Jeong, and A-L.Barab´si. Error and attack tolerance of complex a networks. Nature, 406, July 2000. http://www.nature.com. 24. United States Department of Defence. Trusted Computer Security Evaluation Criteria (Orange Book), DOD 5200.28-STD, 1985. 25. Near Field Communication technology jointly developed by Sony and Philips approved as ISO/IEC international standard. http://www.sony.net/SonyInfo/News/Press_Archive/200312/03-059E/, December 2003. 26. NXP homepage. http://www.nxp.com. 27. Nokia 6131 NFC-enabled mobile phone. http://europe.nokia.com/A4307095. 28. Samsung sgh-x700 NFC-enabled mobile phone. http://mobilementalism.com/2006/02/11/ samsung-and-philips-to-show-off-protoype-nfc-phone-at-3gsm/ #more-381. 29. SanDisk and Philips join forces to ensure security in ticketing and mobile payment applications. http://www.sandisk.com/Corporate/PressRoom/ PressReleases/PressRelease.aspx?ID=3422, May 2006. 30. Near Field Communication forum. http://www.nfc-forum.org/aboutnfc/, 2007. 31. World’s largest NFC trial. http: //www.nxp.com/news/identification/articles/success/otm83/nfctrial/, September 2006. References 59 32. First commercial NFC rollout. http://www.nxp.com/news/identification/articles/otm82/firstnfc/. 33. NFC : come closer, go further. http://www.nxp.com/news/identification/articles/otm81/nfc/, March 2006. 34. Omnikey smart card readers. http://www.smartcardfocus.com/shop/ilp/se~7/p/. 35. Feig smart card readers. http://www.feig.de/index.php?option=com_ content&task=view&id=112&Itemid=115. 36. JCOP homepage. http://www.zurich.ibm.com/csc/infosec/jetz.html. 37. JCOP Tools homepage. http://www-306.ibm.com/software/wireless/wecos/tools.html. 38. JavaCard homepage. http://java.sun.com/products/javacard/. 39. OpenCard Platform homepage. http://www.gemplus.com/techno/opencard/whitepapers/ibm/index.html. 40. Sun Microsystems Wireless Toolkit 2.2. http://java.sun.com/products/sjwtoolkit/download-2_2.html. 41. JSR 257: J2ME Contactless Communications API. http://jcp.org/en/jsr/detail?id=257. 42. Nokia Carbide.j 1.5. http://forum.nokia.com/info/sw.nokia.com/id/ d9f7e9b2-3932-4358-9e8e-aa5cd26be54e.html. 43. T. Moses. OASIS eXtensible Access Control Markup Language v2.0, February 2005. http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2. 0-core-spec-os.pdf. 44. Carol Geyer. XACML 2.0 Access Control Markup Language approved as OASIS standard. OASIS NEWS, March 2005. http://www.oasis-open.org/news/oasis_news_03_02_05_a4.pdf. 45. C. E. Ortiz. An introduction to Java Card technology, part 1. http://developers.sun.com/techtopics/mobility/javacard/articles/ javacard1/. 46. Burt Kaliski. TWIRL and RSA key size. Technical report, RSA Labs, 2003. http://www.rsa.com/rsalabs/node.asp?id=2004#. 47. NIST Comments on Cryptanalytic Attacks on SHA-1. http://csrc.nist.gov/CryptoToolkit/shs/NISTHashComments-final.pdf, April 2005.