Access Control Designs for Building Automation Systems

Aalto University
School of Science
Degree Programme of Computer Science and Engineering
Amit Soni
Access Control in Building

Automation and Control Systems
Master’s Thesis
Espoo, September 10, 2012
Supervisor: Professor Tuomas Auora

Instructors: Dr. Sandeep Kumar
Dr. Oscar Garcia Morchon
Dr. Sye Loong Keoh
Aalto University
School of Science ABSTRACT OF
Degree Programme of Computer Science and Engineering MASTER’S THESIS
Author: Amit Soni
Title:
Access Control in Building
Automation and Control Systems
Date: September 10, 2012 Pages: 74
Professorship: Data Communication Software Code: T-110
Supervisor: Professor Tuomas Auora
Instructors: Dr. Sandeep Kumar
Dr. Oscar Garcia Morchon
Dr. Sye Loong Keoh
Building Automation and Control Systems (BACS) are being deployed in com-
mercial buildings to enable monitoring and control of the various intelligent sys-
tems like HVAC, safety, access and lighting systems. Lighting is an integral part
of BACS, allowing for optimized lighting operation where Lighting devices in-
teract with each other, with users, and with other third party systems such as
energy management.
A key need when interacting is the controlled and trustworthy access to services
so that only authenticated and authorized entities can have access and control to
the services provided by a device. However, secure authentication and authoriza-
tion is not easy due to the large-scale nature of future BACS comprising many
resource-constrained sensors and actuators distributed in the building.
The thesis presents centralized and distributed access control architecture designs
for BACS based on their requirements and constraints. We further present a hy-
brid version of an access control architecture which improves existing centralized
or distributed access control methods. The hybrid version allows for the deploy-
ment of re-encoded access control policies to the accessed devices under request.
Re-encoding serves the purpose of efficient storage and evaluation of the policies
in the resource constrained devices.
The proposed access control systems can be applied to generic BACS and run on
top of communication protocols such as ZigBee or 6LoWPAN/CoAP. We have
further implemented a prototype to prove the concept on actual field devices
used by Philips Lighting. The operating system used by devices is Contiki-OS.
The final system requires 10KBs of FLASH and allows caching of access control
policies in the device.
The access control system cane be used in applications scenarios related to the
Internet of Things.
Keywords: building automation, security, access control, sensor networks,
constraint devices
Language: English
2
Acknowledgements
I am deeply grateful to my supervisor Professor Tuomas Aura of Aalto Uni-

versity and my instructors Oscar Garcia Morchon of the Philips Research,
Sandeep Kumar of the Philips Research, and Sye Loong Keoh of the Philips
Research for providing me the opportunity to work on this project.
I thank Oscar Garcia, Sandeep Kumar, and Sye Loong Keoh for providing
constant feedback on my work. They always helped me to stay on track of
the subject by providing detailed and constructive comments. I especially
appreciate the enormous time spent by Sandeep and Tuomas when revising
my thesis.
I also thank all my friends in the Philips Research, Eindhoven and Aalto
University, Finland for providing moral support.
Espoo, September 10, 2012
Amit Soni
3
Abbreviations and Acronyms
AES Advanced Encryption Standard

ANSI American National Standards Institute
ARCNET Attached Resource Computer NETwork
ASHRAE American Society of Heating, Refrigerating and Air
Conditioning Engineers
BACS Building Automation and Control System
CoAP Constraint Application Protocol
DALI Digital Addressable Lighting Interface
HTTP Hypertext Transfer Protocol
IBECS Integrated Building Environmental Communications
System
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
ISO International Organization for Standardization
JSON JavaScript Object Notation
LAN Local Area Network
LoWPAN Low power Wireless Personal Area Networks
MAC Message Authentication Code
PDP Policy Decision Point
PEP Policy Enforcement Point
PIP Policy Information Point
PSK Pre-Shared Key
RAM Random Access Memory
RBAC Role Based Access Control
REST REpresentational State Transfer
ROM Read Only Memory
SOD Separation Of Duties
SRAM Static Random Access Memory
XACML eXtensible Access Control Markup Language
XML Extensible Markup Language
4
Contents
Abbreviations and Acronyms 4
1 Introduction 7
1.1 Problem domain and context . . . . . . . . . . . . . . . . . . . 8
1.2 Structure of the Thesis . . . . . . . . . . . . . . . . . . . . . . 8
2 Background 10
2.1 Building automation and control systems . . . . . . . . . . . . 10
2.1.1 Communication protocols in BACS . . . . . . . . . . . 10
2.1.2 Communication frameworks and functional architec-
tures in BACS . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.1 XACML: eXtensible Access Control Markup Language 18
2.2.2 Kerberos: Centralized authentication system . . . . . . 20
3 Use cases and requirements 22

3.1 Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4 Design of access control system for BACS 26

4.1 Access control in stand alone lighting control system . . . . . 26
4.1.1 Design 1: Basic access control . . . . . . . . . . . . . . 27
4.1.2 Design 2: Context handling . . . . . . . . . . . . . . . 34
4.1.3 Design 3: Addressing range of devices . . . . . . . . . . 37
4.2 Access control with third party interactions . . . . . . . . . . 39
4.2.1 Design 4: Third party interactions . . . . . . . . . . . 39
5 Implementation and system prototype 44

5.1 Implemented designs . . . . . . . . . . . . . . . . . . . . . . . 44
5.2 Hardware specifications . . . . . . . . . . . . . . . . . . . . . . 45
5.3 Implementation details . . . . . . . . . . . . . . . . . . . . . . 46
5
5.3.1 Implementation 1: Centralized decision point . . . . . 47
5.3.2 Implementation 2: Hybrid decision point . . . . . . . . 51
6 Evaluation 60
6.1 Memory requirements . . . . . . . . . . . . . . . . . . . . . . . 60
6.1.1 Code size . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.1.2 Policy size . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.2 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.2.1 Time measurements . . . . . . . . . . . . . . . . . . . . 62
7 Discussion 63
7.1 Complexity of the overall architecture . . . . . . . . . . . . . . 63
7.2 Context handling in third-party domains . . . . . . . . . . . . 64
7.3 BACS current and future . . . . . . . . . . . . . . . . . . . . . 64
8 Conclusions 66
A JSON protoype 72
6
Chapter 1
Introduction
Building automation and control systems (BACS) provide automatic control

of the conditions of indoor environments. Originally, BACS mostly consisted
of heating, ventilation and air-conditioning (HVAC) systems. For large build-
ings such as schools, hospitals, and offices the construction costs constitute
only one seventh of the overall operational costs [16]. Therefore, BACS pro-
vided a great savings potential by reducing the operational costs.
The role of building automation and control system has been broaden-
ing beyond reducing building energy and maintenance costs. Additionally,
number and the capabilities of devices used by the BACS is also increasing
owing to the cheap hardware costs and advances in the wireless technologies.
BACS is on its way to become a prime example of a distributed control sys-
tem equipped with sensors and monitoring devices along with the actuators
(e.g ballasts) to use them for data acquisition, service automation and man-
agement purposes. In future, BACS would be the major part of building
information systems backbone. Machine-to-machine networking would drive
every connected component to being internet addressable. Commissioning,
monitoring, trending and archiving (see section 7.3) will become a norm.
The proper access control in the BACS becomes a matter of concern
when a security attack could cause unwanted consequences. These unwanted
consequences range from simple privacy breach (e.g. spying on trends of
a particular office room) to life threatening situation (e.g. compromised
ventilation system). In the field of BACS, the intended flow of information is
dependent not only on the static rules governed by centralized access control
entities but also on the dynamic environment and the context of the devices.
A simple example of such a situation would be to disallow any remote request
to turn on the heating when there is no one present in the room as detected
by the presence sensors. The handling of this dynamism in the access rules
along with the constrained resources on the field devices makes the access
7
CHAPTER 1. INTRODUCTION 8
control system non-trivial requiring new solutions in this area.
1.1 Problem domain and context

This study focuses on access control in the field of the BACS. Background
study points out that insufficient work has been done to design BACS based
on its safety and security, and therefore it is possible to compromise the sys-
tem in numerous ways [28]. This poses new requirements for access controls
(including authorization and authentication) on all the services provided and
consumed by the building systems.
Access control language is another essential part of the thesis. The lan-
guage in which various entities in the access control system would commu-
nication has to be clearly defined. The language should be concise, scalable,
and efficient to evaluate on the resource constrained devices. It is notable
that for efficient storage and evaluation of the access rules in the constrained
devices, they must be in the binary encoded format. However, binary for-
mat is not easily manageable while modifying and adding the access rules.
Therefore, we also need a module for encoding and decoding of the access
rules from the text and binary format.
The access rules are dependent on the environment of the device being
accessed. Therefore, when access rules are stored and evaluated in a central
entity, there needs to be a procedure to partially evaluate the rules at the
central entity leaving the environment variables for the device to evaluate by
itself. Access rules related to the emergency situation also need to prioritized
so that delay in those scenarios can be minimized.
Since, this work is based on real-world problems, a major chunk of effort
is directed to the provide a prototype working of the access control system.
With these analysis and feedback from the prototypes, an attempt is made
to propose possible future direction on the topic.
The aim of this thesis is to analyze the access control requirements in
the field of BACS. Based on these requirements and existing access control
mechanisms in various fields, we design and develop an access control system
for BACS. Finally, a prototype of the access control system is implemented
and evaluated on a wireless sensor network as proof-of-concept.
1.2 Structure of the Thesis

The thesis report is organized as follows.
CHAPTER 1. INTRODUCTION 9
• Chapter 2 provides the relevant background information related to the

problem domain. In the background chapter, first we discuss vari-
ous communication protocols, then the communication frameworks and
functional architecture in BACS. Next, we describe the classical access
control mechanisms along with some specific relevant authorization and
authentication frameworks.
• In Chapter 3, we contemplate over possible use cases for access control

in BACS. The final subsection enumerate the requirements for access
control architecture based on the use cases.
• In Chapter 4, we propose various designs by cumulatively satisfying

the requirements.
• Chapter 5 contains the details regarding two prototype implementa-

tions of the proposed designs.
• Chapter 6 evaluates the prototype implementations based on memory

requirements and latency.
• In Chapter 7, we discuss some topics which are not directly related to

our study. However, it helps in understanding the overall picture of the
study.
• The achievements of the thesis are summarized in the Chapter 8. The

thesis is concluded with a survey of possible future tasks.
Chapter 2
Background
2.1 Building automation and control systems

Services in BACS are typically provided by various sub-systems e.g. a sub-
system providing lighting at one floor might be different from the sub-system
providing lighting on a different floor and these might be completely different
from the sub-system providing the heating services somewhere else in the
building. It is a highly complex network of devices since a group of services
provided by each sub-system might have its own communication architecture
and protocol. An effective access control architecture cannot be designed
if we do not consider the current functional architectures along with the
communication topologies and protocols in the BACS.
2.1.1 Communication protocols in BACS

BACnet: BACnet is an ASHRAE[2], ANSI[1], and ISO[15] standard pro-
tocol. As a data communication protocol BACnet is a set of rules
that apply to a device’s hardware and software. The standard com-
munication protocol forms the communication portion of each device.
The protocol is realized by a virtual entities named objects. An object
is a set of information related to a specific function that is uniquely
addressed and accessed over a network. Therefore, an object may rep-
resent not only a single physical device but also a logical grouping of
devices that perform a particular function. Since BACnet is essentially
a communication protocol it can work for different networking tech-
nologies (e.g. Ethernet, ARCNET, LonTalk). Translators are required
if different LAN technologies are present in the network. Figure 2.1
shows typical network architecture in BACnet.
10
CHAPTER 2. BACKGROUND 11
Figure 2.1: Typical network architecture for BACnet [3]
Although the protocol seems general, there are operational character-

istics unique to different systems that are not explicitly supported by
the BACnet object. For example, in lighting control, features such
as preset scenes cannot be easily implemented using current BACnet
functions [33].
DALI: DALI (Digital Addressable Lighting Interface) [13] is a all-in-one

communication protocol specifically designed for addressing and con-
trolling the ballasts in the Lighting Network. It is highly specific in the
sense that there is no concept of network stack in this protocol which
makes it highly efficient but rigid and unscalable.
DyNet: DyNet [30] is another highly specific communication protocols used

in the lighting systems. It is a modified version of RS-485 [32] for ad-
dressing and controlling the lighting devices. This protocol also requires
translation and bridging in order to integrate with other building au-
tomation standards.
ZigBee: Zigbee [17] is suite of communication protocols for low power wire-
less sensor devices. The ZigBee specification enhances the IEEE 802.15.4
Figure 2.2: Network Stack for ZigBee [17]
(wireless) standard by adding network and security layers, and an ap-

plication framework. ZigBee’s network layer is responsible for node
joining or leaving the network, node configuration, node addressing,
overall routing and network security. Application layer functionality
includes discovery of devices and binding devices based on their ser-
vices and needs. Zigbee has applications in wireless light switches,
electricity meters, and other devices that require short range wireless
controllability. Figure 2.2 presents the ZigBee’s protocol stack.
6LoWPAN/CoAP: 6LoWPAN (IPv6 over Low power Wireless Personal

Area Networks) is a IETF working group to overlay IP on IEEE 802.15.4
[18], [24]. They advocate various advantages of using IP in the field
of LoWPAN, such as – using existing infrastructure of IP, open and
freely available specifications, already available tools for diagnostics,
management, and commissioning of IP networks and high connectiv-
ity with IP networks without using translators. Adaptation layer has
been proposed in [24] to allow the transmission of IPv6 datagrams over

IEEE 802.15.4 networks. Encapsulation formats defined in this adap-
tation layer are the payload in the IEEE 802.15.4 MAC protocol data
unit (PDU). The 6LoWPAN payload follows an encapsulation header.
Functionality of the adaptation layer include multiplexing various types
of headers such as mesh addressing header, broadcast header, fragmen-
tation header, etc. Then various types of fragmentation protocols are
specified owing to difference in payload formats in the IPv6 and IEEE
802.15.4. Protocols for address mapping, unicast, multicast, and header
compression are also specified.
CoAP (Constrained Application Protocol) [35], is an application layer
RESTful protocol for constrained environments. It is analogous to
HTTP in web and is easily translated to HTTP for mutual integra-
tion. It minimizes the HTTP complexity, reduces the header overhead
and simplifies the caching to adapt to the constrained environments.
It also provides features such as discovery of resources and publication
and subscription to the services.
2.1.2 Communication frameworks and functional ar-

chitectures in BACS
Based on the above discussed application layer communication protocols and
others proprietary protocols, various integrated and hierarchical communi-
cation frameworks have been proposed for Building Automation Systems.
Communication frameworks are generally studied in combination with func-
tional architectures since it helps to understand the logic behind both of
them. We present here few of them.
1. The figure 2.3 describes the architecture of Building Services (BS) pro-
posed by [14]. We see that BS might have to interact with various
external systems e.g. water system, sewer system, power distribution
network, heating network, gas distribution network, alarm network,
mobile network, etc. The top level BACS unit in the figure 2.4 is re-
sponsible for the management, installation, firmware update, and other
high level functionality. The lower level corresponds to the various BS
systems and their interface with the external services as shown in fig-
ure 2.4. The spaces in the building are at the lowest level of the systems
and contain the base module of the BS system (BSS) which commu-
nicates with an interface for external systems, space devices (actual
devices) and the space controller units (for communication with the
management unit). The space controller ( also called BACS) is re-
Figure 2.3: Position of BS (Building Services) architecture [14]
sponsible for the control of various devices in the space through its
connection with the management layer. Colored lines describe the ser-
vice flows to and from external sources (e.g. electricity, air and water).
This architecture mainly depicts the functionality of the system but
can be easily seen in combination with the communication frameworks
discussed below.
2. A communication framework for IBECS [33] is shown in the figure 2.5.

We see that the management level utilizes the BACnet protocol. The
sub-network (also known as microLAN) uses the IBECS functionality
which exists in connection with the DALI network used for lighting.
We see that translation between the DALI and the IBECS is provided
by a bridge. Since IBECS enabled devices are controlled using the mi-
croLAN (Ethernet), this might be a significant step towards the stan-
dardization of communication frameworks in BACS.
3. Another example of functional architecture and topology as described

Figure 2.4: Detailed structure of BS [14]
in [16] is shown in the figure 2.6. It is almost on the line of the previ-
ously discussed functional architecture [14]. We have the field network
comprising the actual devices collecting data, executing functions, etc.,
on top of which we have the automation network consisting of a unit
controller and dedicated high resource devices, whose functionality in-
clude the aggregation of the data from the field level and presenting
it to the management level (e.g. trending) and executing all prede-
fined and context sensitive automated sequences. The management
level provides the dashboard for manual operations such as modifying
the system parameters at the run time, intervening during emergency
alarms, and scheduling new automated tasks. It also stores the long-
term historical data.
2.2 Access Control

Access control by definition includes authentication and authorization of the
requests to perform some actions in the system. Subjects are defined as the
entities that perform actions in the system and objects are defined as the
resources on which the action is being performed. It is important to note,
Figure 2.5: IBECS communication framework [33]
mainly in the field of BACS, that the subjects can be both human users and
other objects. Role to authentication in the access control is mainly to further
facilitate the authorization of the subjects. Sometimes, especially in the field
of BACS, one way authentication is not sufficient e.g. a device in BACS
might be programmed to execute some action on a certain kind of devices
which could only be verified with the help of authentication. Following are
the few classical access control models that are frequently used to incorporate
access control to various degree depending on the requirements.
Discretionary access control Access policies for the resource are decided
by the owner of the resource. This boils down to two requirements in
the discretionary access control model.
1. Every object in the system has a subject as its owner.

2. The owner decides the control to its resources through access
rights and permissions to other subjects.
Mandatory access control Mandatory access control refers to allowing

access to a resource if and only if there exists a policy that allow a
given user to access the resource. The access policies are designed
Figure 2.6: Network framework [16]
centrally and enforced to the whole system thereafter. Mandatory ac-

cess control rules are often based on security labels on subjects (called
clearance) and objects (called classification). Following two methods
are commonly used for applying mandatory access control:
1. Rule-based (or label-based) access control: A Mandatory Access

Control system implements a simple form of rule-based access con-
trol to determine whether access should be granted or denied by
matching:
• An object’s sensitivity label i.e. object’s classification label
• A subject’s sensitivity label i.e. subject’s clearance label
2. Lattice-based access control: These can be used for complex access
control decisions involving multiple objects and/or subjects. A
lattice model is a mathematical structure that defines greatest

lower-bound and least upper-bound values for a pair of elements,
such as a subject and an object.
Role-based access control RBAC is another non-discretionary access con-
trol model in which subjects are assigned one or many roles determined
by the system. In the basic RBAC model, a role is defined as a set of
permissions on a set of objects and users are allowed to perform an
action if and only if they are assigned at least one role which con-
tains that action. More advanced models also allow hierarchy of roles.
Mathematically, a hierarchy is a partial order defining seniority rela-
tions between roles in which senior roles inherit permissions of their
juniors [9]. More complex properties like, separation of duties (SOD),
are also easily incorporated in the RBAC model. SOD is a simple tech-
nique which reduces the possibility of fraud and enforces responsibility.
Attribute-based access control In attribute based access control model,
access is granted based on the certain attributes. Attributes can be
related to subject and/or object. The implementation of model itself
varies due to the lack of standards; some models enforce subject au-
thentication where as some models operate solely on the attributes.
Example of subject attribute could be “location of the subject”; if the
subject proves that it is at a certain location, then it is allowed to do
a certain action otherwise not. Example of object attribute could be
“color or brightness of the light”; subjects are allowed to access the
object only during certain time periods.
We still need a framework that implements the above mentioned basic
access control models and an authentication mechanism. In the following
section we will discuss XACML [20], a standard which defines a declara-
tive access control policy language and framework. Later, we will discuss
Kerberos as one example of authentication protocol.
2.2.1 XACML: eXtensible Access Control Markup Lan-

guage
XACML (eXtensible Access Control Markup Language) [25] is used for com-
mon terminology and interoperability between authorization implementa-
tions by multiple vendors. The framework core is based on the attribute-
based access control model but can be easily extended to incorporate role-
based access control models also. As the name suggests XACML uses XML
as the mark up language for all the communication between the components.
Figure 2.7: XACML architecture
The detailed functional architecture of XACML is presented in the figure

2.7. Various components of the modular architecture are explained in the
figure itself. XACML policy system defines the syntax for a policy language
and the semantics for processing those policies. The request and response
messages format are also standardized and contain more complex logic that
makes XACML extremely expressive.
Each XACML policy contains a recursive tree of sub-policies with leaves
of the tree representing the various rules related to the policies. Each tree
represents a target, which is a simple set of criteria used to determine a
policy’s applicability to a request. A request consists of attributes associated
with the requesting subjects, the resource acted upon, the action intended
to be performed, and the environment. A response contains any one of four
decisions: permit, deny, not applicable (no applicable policies or rules could
be found), or indeterminate (some error occurred during processing).
In a typical usage scenario, a request is sent by the user to access a
particular resource, the PEP receives the request and forwards the request
to the PDP to check whether the user is allowed to access the particular
resource. The PDP then interacts with the PAP to get the relevant set of
policies related to this request to verify whether the user has access to it. The
PIP is also parallelly queried to get information about attributes to check
if a condition has to be satisfied for granting the user access to a particular
resource. The evaluated response is sent back to the PEP which takes action
according to the response.
2.2.2 Kerberos: Centralized authentication system

XACML discussed in the previous section provides a robust framework for
the authorization, but its capabilities are limited without a proper authen-
tication protocol. Kerberos is a well known authentication framework used
for centralized authentication [27]. The goal of Kerberos is simple – “to al-
low a client to prove its identity to a verifier and vice-versa without sending
sensitive information in the network”. Kerberos builds on symmetric key
cryptography and requires a trusted third party.
Protocol details when the User and the Service are present in the same
domain are as follows:
• Initial authentication of User (U) on Kerberos Authentication Service

(AS):
1. U −→ AS : U, T GS, N1 , AddrU , T L
2. AS −→ U : U, T GT, EKU (KU −T GS , N1 , T GS, AddrU )
• Ticket request to the Ticket Granting Service (TGS):
3. U −→ T GS : S, T GT, AuthenticatorU −T GS , N2 , AddrU

4. T GS −→ U : U, Ticket, EKU −T GS (KU S , N2 , S, AddrU )
• Authentication to Service (S):
5. U −→ S : Ticket, AuthenticatorU S
6. S −→ U : AP REP
where,
KU , KT GS , KS = master keys of User, Ticket Granting Service and Service
KU −T GS = shared key for User and Ticket Granting Service
KU S = shared key for User and Service
T GT = S, EKT GS (INITIAL, KU −T GS , U, Tauth , Texpiry1 , AddrU )
Ticket = S, EKS (KU S , U, Tauth , Texpiry2 , AddrU )
AuthenticatorU −T GS = EKU −T GS (U, Time Stamp1 )

AuthenticatorU S = EKU S (U, Time Stamp2 )
AP REP = EKU S (U, Time Stamp3 )
AddrU = User’s IP address
The same protocol is extended to the scenario when the User and the
Service are present in different domains. Separate domain requires new set
of the Authentication Service and Ticket Granting Service. As shown in the
figure 2.8, if a User in domain X requires to access a Service in domain Y,
the User first get a Ticket for the TGS of domain Y from the TGS of the
domain X and then the TGS of domain Y grants the Ticket for the actual
Service in domain Y.
Domain X Domain Y
AS KDC TGS AS KDC TGS
3. TGT X
1. Auth 4. TGT Y
5. TGT Y
2. TGT X
6. Ticket Service
User Service
7. Ticket Service
8. Mutual Auth
Figure 2.8: Multi-domain Kerberos architecture
The authorization framework XACML together with the authentication

framework Kerberos is used for the overall access control in the distributed
systems. However, the distributed system in our case (BACS) has various
limitations such as low network bandwidth, low CPU cycle frequency and
low memory on the devices. In the chapter 4 we propose various models that
will solve these problems by modifying the existing frameworks.
Chapter 3
Use cases and requirements
We investigate current security requirements in the field of BACS based on

the various use case scenarios. These requirements forms the basis for the
proposed access control architecture. The motivation behind deriving the
requirement from the use cases is to keep the access control architecture
from straying too abstract. The project is industrially motivated and an
access control extremely abstract and general would be of little use in the
field.
3.1 Use cases

Based on discussed communication protocol, frameworks and functional ar-
chitecture in section 2.1.2, we have come up with typical lighting function-
ality architecture in a building which is described in figure 3.1. The green
and blue communication line in the figure 3.1 represents two different do-
mains, providing lighting and window blind services respectively. We also
have the DALI network for keeping the traditional lighting control network
in the scenario. The ‘Router’ and ‘Controller’ are responsible for managing
the communication functionality of the networks and have little to do with
the access control. ‘Domain monitor’ maintains the archive of all the access
patterns of devices in the domain while ‘Automation’ invokes automatic ser-
vices upon certain pre-defined environment conditions. ‘Trust Authority’ is
responsible for trust between different domains. With the above presented
functional architecture in hand, we have noticed various use cases where ac-
cess control in the system is required. Following are few of the use cases that
are applicable in BACS:
1. Typical communication between two devices: In this scenario, a window-

blind device might communicate to the light device in the same room
22
CHAPTER 3. USE CASES AND REQUIREMENTS 23
Office 1 Office 2 Single Floor

Conference Room 1
Building Ethernet
Typical
Typical
light
switch
Domain Monitor/ Decision Point/

Automation Trust Point
DALI
router Floor Monitor/
bridge Automation
2. router
controller 2. router
Gateway
controller
Floor
3. controller
Office 3
OTHER SIMILAR FLOORS
Trust Building Monitor/

Authority Automation
Figure 3.1: Lighting functionality architecture in a building
that the light outside is sufficient for the room illumination. However,
a blind should not be able to communicate with the light in a different
room. There are many other examples which present the requirements
for the device to device access controls. E.g. a door (device) might
want to communicate with the light (device) of same room and should
not able to communicate with the lights of the other rooms.
2. Communication with the devices when context matters: In the build-

ing automation systems, normal user/devices might not be allowed to
manipulate the HVAC devices when fire sensors are activated due to a
fire. Time based access control is yet another typical case where context
(here time) is important. These cases demonstrated the importance of
including the content and context information in the access control.
3. Communication with a range of devices: In the building automa-

tion systems, billing of each floor of a building would require the energy
automation systems to ask for the energy usage of all the devices in
a floor. In other words, the energy automation system might need to
communicate with a range of devices in the floor. A more general use
case could be the one in which user is allowed to control the heating
and air condition devices in all the rooms in which at-least one person
is present. In other words, providing access control to a range of de-
vices based on certain conditions. This would only be possible if the
access control architecture allows us efficient decision of access control
for large number of devices. Therefore, support for access control on a
range of devices based on certain condition is required.
4. Inference restrictions and anonymity: Energy automation systems
need the daily or may be monthly reports of power consumption by
the devices in order to bill the device owners. Device owners might not
want the energy automation systems to infer the up and down time of
each and every device. It might be possible that devices owner would
only communicate details like this to consumer analytic systems which
would help them reduce their energy consumption. The requirement
here is that devices in a particular domain or a group might want to
remain anonymous to certain requests. Another example could be as
follows. At the end of the day, to lock-down the office floor, the main
door of the office might want to know if all the rooms are empty or if
all the lights are turned off but it should not be able to know which
particular room is not empty if indeed there is room which is not empty.
5. Support for legacy system: It might be possible that traditional sys-
tems like DALI [13], DyNet [30] are already present in some parts of
the building. The access control architecture should be such that it
includes those systems for access control.
3.2 Requirements
Discussed use cases and related studies in [10], [38] guide us to categorize
requirements for our access control architecture in following types:
Requirements for the access control from device’s perspective :
1. Fined grained access control: A device should be able to ac-

cess the services provided by another device if and only if it is
authorized to do so.
2. Context and content handling in the policies: Context and

content on the devices providing the services should be incorpo-
rated in the access decisions.
3. DoS protection: Access control system should help protect de-
vices providing services from the denial of service attacks.
4. Role-based access control: Devices and users using the services
provided by the devices should be assigned roles to help facilitate
access control on a larger scale.
Requirements for the access control from system’s perspective :
5. Range and Condition support in policies: Access control
system should be able evaluate and enforce its decision on broad-
cast messages.
6. Inference reduction and anonymity of the devices: Device
providing the service should be able to choose to be anonymous
to certain users and devices.
7. Able to handle exchange of information with 3rd party
systems: Access control system should be able to evaluate and
enforce decision on 3rd party requests seamlessly.
Technical and operational requirements :
8. Efficient access decision: Due to the limited resources on the
sensor nodes, the decision evaluation and enforcement should be
efficient.
9. Suitable for underlying operational architecture in build-
ing control automation systems: Access control system should
be such that it is easy to extend it to the existing automation in-
frastructure in BACS.
10. Modular design of the system: The system should be designed
such that it could be subdivided into various components that
could be independently developed and tested.
11. Feasible for both distributed or centralized operation: Dis-
tributed mode of operation is when the access control decision is
taken on the device itself while the centralized mode of operation
is when a central entity takes the access control decision on behalf
of the device. Access control system should be hybrid so that it
is able to support both the distributed and centralized mode of
operation on sensor network.
Chapter 4
Design of access control system

for BACS
The approach to design the access control architecture for BACS would be
to cumulatively consider each of the enumerated requirements and discuss
advantages and disadvantages as we introduce new components to fulfill those
requirements.
The sequence of incorporating the requirements in the architecture is
presented in the table 4.2. Before we go in to the details of the actual access
control architecture we present the terminology for various components in
table 4.1. These terms are motivated from XACML[20] but are not limited
to that.
For each design we typically consider three variants namely ‘distributed’,
‘centralized’ and ‘hybrid’. When functionality of all the involved compo-
nent are fully distributed to the end-devices we call the variant ‘distributed’.
When any involved component is functional from a centralized entity we
call the variant ‘centralized’. When a component is functional both from
a centralized entity and the end-devices we call the variant ‘hybrid’. The
‘hybrid’ variant is the most general since it can be easily transformed into
the ‘distributed’ or ‘centralized’. If in a design we find the ‘distributed’ and
the ‘centralized’ variants as trivial or not practical to implement, we directly
proceed to the details of the ‘hybrid’ variant.
4.1 Access control in stand alone lighting con-

trol system
In this section we determine ways of access control between devices of the
same domain. Devices in one domain might also be present in other floors of
26
CHAPTER 4. DESIGN OF ACCESS CONTROL SYSTEM FOR BACS27
DP Decision Point makes the access decisions by implementing the

decision procedures.
EP Enforcement Point must implement the decision made by the
DP.
RP Retrieval Point stores the rules or polices which are later fetched
by the DP and/or the AP.
AP Administration Point is the interface to manage access rules or
policies stored in the RP.
Domain A domain represents collection of devices owned by a single en-
terprise. Single domain can be distributed in different commu-
nication network.
TP Trust Point is responsible for the establishing the trust between
any two devices in a domain.
TA Trust Authority is responsible for the establishing the trust be-
tween different domains.
Device End entity with constrained computational and storage re-
sources, characterized by domain (e.g. philips, cisco, etc), type
(e.g. light, presence sensor, heating, etc), location (optional)
(e.g. office number, cartesian coordinates, etc), and id (e.g. ip6,
security key, random alpha-numeric string, etc).
Table 4.1: Terminology for access control architecture for BACS
the building (typically in different communication network) but we assume

that the communication within the domain is trivially possible. We consider
any one of these green or blue domain.
4.1.1 Design 1: Basic access control

Following the table 4.2, we begin with collectively focusing on the require-
ments ‘Suitable for underlying operational architecture in building control
automation systems’, ‘Fined grained access control’ and ‘Efficient access de-
cision’. We keep in mind a simple use case that we do not want switch1
designated for light1 to control light2 even if they are in the same domain.
To implement this, we have following three variants:
Distributed: Pairwise shared keys and access control rules are stored
in the devices(light, switches, etc.) themselves. Key pre-distribution is per-
formed using one of the several ways discussed in [34] and [7]. These keys are
used for subsequent authentication. Assuming that device d1 can discover
the device d2 and hence knows d2 ’s address and services, d1 tries to access
some service provided by d2 . Authentication is the first step in the access
Access control in stand alone lighting control system

Design 1 Suitable for underlying operational architecture in BACS +
Fined grained access control + Efficient access decision
Design 2 Design 1 + Context and content handling in the policies
Design 3 Design 2 + Range and Condition support in policies + Inference
reduction and anonymity of the devices
Access control with third party interactions
Design 4 Design 3 + Able to handle exchange of information with 3rd
party systems
Table 4.2: Sequence of incorporating the requirements in the design
control procedure. Since, the devices have limited resources we would assume
that symmetric key encryption and efficient hash functions are used for con-
fidentiality and authentication. Since confidentiality is not always required
we will concentrate our efforts on authentication. Authentication could be
performed using one of the several schemes discussed in [39], [6]. We use a
very simple form of authentication using message authentication code.
Assuming Kd1 −d2 is the shared key between device d1 and d2 , d1 uses
Kd1 −d2 to apply MAC on the message (m) along with a random nonce (n)
(for freshness). When d2 receives the message, it checks if Kd1 −d2 is correct
and n is fresh. This way it verifies the identity of d1 and freshness of the
message.
d1 −→ d2 : M AC[Kd1 −d2 , (m + n)]
The algorithm is robust against network eavesdropping, replay attacks,
and identity spoofing.
Once mutual authentication of the messages is established, device d2
checks its access control rules and see if the device d1 is allowed to per-
form the action it requests. Therefore, we say the decision point (DP) is
in the device itself. Enforcement follows the decision. Since the DP is in
the same device where we want to perform the enforcement, enforcement is
rather trivial. The process running the device as the DP would inform the
access decision to the process running as the service provider. The whole
scenario is described in the figure 4.1
For monitoring and management of devices, the same scheme is repeated.
Devices would contain appropriate access control rules for the domain mon-
itor, automater, maintainer, etc. When the domain monitor, automater,
maintainer want to execute some actions on the devices, the above discussed
scheme for decision and enforcement is applied.
We have discussed the most trivial design for the access control in the
Device d1 Device d2
Authentication
Service request Evaluating request
Service granted/denied
Figure 4.1: Access control in distributed variant
BACS. Following are the advantages and disadvantage of the design.
Advantages :
1. Simple and efficient in systems where there are small number of

devices and where a device is accessed by a limited number of
other devices.
2. Since the enforcement point (EP) and DP is in the same device,
the implementation becomes easier and communication overhead
is minimal.
Disadvantages :
1. Least scalable architecture. As the number of devices increases

the number of keys and the access rules becomes so large it would
be unfeasible to store and lookup in the device itself.
2. Communication with third party devices (e.g. floor monitor, build-
ing monitor, energy automation systems, etc.) requires a dedi-
cated translator.
Centralized 1: We have two centralized variant essentially to make our

architecture more scalable. Since the access policies takes more resources to
store and evaluate (DP) the first step to make the architecture more scalable
would be to separate the DP and EP by place the DP to a device that has
relatively more resources. In the second centralized variant, we also centralize
the key management.
Here, we again consider the case when device d1 (e.g. switch1) wants to
communicate to device d2 (e.g turn on light1). Authentication phase would
be the same as that in the previous design since the keys are still in the
Device d1 Decision Point Device d2
Authentication
Service request
Evaluation request
Decision
Figure 4.2: Access control in centralized variant 1
device itself. After mutual authentication between d1 and d2 , there needs to

be mutual authentication between the d2 and DP . Device d2 then queries the
DP about the access control rules and whether d1 is allowed to execute the
action it requests. The decision is sent to d2 and enforcement takes place in
the same way as in the previous design. It is always cost effective to place the
DP with already present resourceful device in the domain e.g. automation
device in figure 2.6 or domain monitor device in figure 3.1. However, the DP
process should have high security clearance and the rules should be stored
securely so that other processes are not able to access or modify the rules for
the whole system. When we make the access rules centralized, we may also
add rules governing which devices can be allowed to access the access rules.
The scenario is pictorially presented in figure 4.2.
A simple modification of the above discussed schema would be to enable
rules queries by d1 to DP. This would help us get away with the step of
mutual authentication between d1 and d2 . The logic behind this is simple, if
d1 already knows that it is not able to execute certain action on d2 , it will not
be authenticating itself to d2 in the first place. Following are the advantages
and disadvantage relative to the distributed variant.
Advantages :
1. More scalable since now we can store practically unlimited rules

in the system.
2. Easy management of system wide rules.
Disadvantages :
1. Communication overhead of access rule exchanges.

2. Single point of failure for access rules management.
3. Extra device (DP) has to be installed in the network, if not already

present.
4. Number of possible devices that the system could support are still
limited since keys are stored in the device itself.
Centralized 2: Major hurdle in scaling the previous architecture is that
each device has to store keys for all the other devices to which it wants to give
service access. There are efficient algorithms for storing the pre-shared keys
in large distributed networks as presented in [4] and [5]. These algorithms
are based on the basic principle that distributed entities would be able to
derive the all mutually-shared keys based on the relatively small amount of
pre-shared piece of the data. There are at-least two known problems with
these algorithms
1. There exists dependency between the various pre-shared keys in the
domain (although small), and
2. If a certain number of keys in the domain are compromised, then the
adversary could possible calculate all the pre-shared keys in the domain.
The central entity that mediates the trust between the devices is named
Trust Point (TP). We use the Kerberos protocol discussed in the background
section 2.2.2. The functionality of the TP is realized by the KSC in the
Kerberos.
There can be numerous other ways in which authentication can be es-
tablished using a centralized TP. Once the authentication between d1 and
d2 is established, d2 contacts DP for access decision and the process in the
previous design is repeated again. Figure 4.3 summarizes the details of the
architecture. Following are the advantages and the disadvantages compared
to the previous design.
Advantages :
1. More scalable since now we can have practically unlimited number
of devices in the network.
2. Easy management of the keys in the system e.g. revocation, mul-
tiple keys per device, etc.
Disadvantages :
1. Communication overhead for session (key) establishment.
2. Extra device (TP) if not already present in the network has to be
installed.
Device 1 Decision Point Trust Point Device 2

Ticket request
Ticket reply
Authentication request
Veriﬁcation
+ ticket
Authentication reply
Service request
Evaluation request
Decision
Figure 4.3: Access control in centralized variant 2
3. Centralized trust identity means single point of failure for the

system.
Hybrid: In this design we include the caching feature which would in-
crease the efficiency of access control decision in the system. The benefits
of the caching becomes apparent when there are only few devices frequently
accessing services of any device. The main motivation for the caching in
building automation systems comes from various use cases where it appears
unreasonable to rely on centralized components for each simple service re-
quest (e.g. switch controlling the light). Architecturally, the idea is rather
classical; a device (e.g. light) providing the services would be storing the
mutually shared keys and the access control rules for the devices frequently
accessing it (e.g. switch corresponding to the light). This also requires the
device accessing the services to store the service tickets and mutually shared
keys. Various caching algorithms discussed and proposed in [22] can be used
but from the practical point of view there would be enough resources in the
device to store the key and access control rules for almost all the devices
frequently accessing it. We present below detail of typical access procedure
for two yet mutually unknown devices in the same domain for the hybrid
variant:
1. Discovery: Start of the access procedure depends on how the device d1
is programmed; e.g. a window blind might be programmed to search for
all the lights in the room and dim them whenever there is enough light
outside, a switch might be programmed to find its corresponding light
and turn it off or on, a heater or air-conditioner might be programmed
to find all the windows in the room and shut them off while it is on. In
case of the manual access, the access procedure is explicit as opposed
to the automated device to device access.
Searching a device of interest generally happens in two ways. Field

searching – devices searching each other by themselves and Directory
based searching – Devices rely on TP to search the required device
for them. Field searching requires the two devices to understand a
common application protocol which is the likely possibility since we
are currently dealing with the intra-domain lighting architecture. We
briefly go over each procedure as follows:
In field searching: Device d1 willing to access other interesting de-

vices, broadcasts a discovery protocol message that it is looking
for particular type of devices. This broadcast can either be en-
crypted by the domain wide discovery key or can be plain text.
The encryption of the discovery message is to hide the search
queries from devices outside the domain. Either way, devices of
the requested type understand the broadcast and reply with their
corresponding identities and addresses.
Directory based searching: Device d1 , willing to access other inter-
esting devices, sends the discovery protocol message to the TP
with optional encryption using the domain wide discovery key.
TP simply replies with the identities and addresses of the corre-
sponding devices.
2. Cache-miss access: At this stage, device d1 knows the identity and

the address of the device d2 . We have two types of the caches in the
device, authentication cache containing the mutually shared keys and
tickets between the devices and authorization cache containing the en-
coded access rules of the devices. The access rules are encoded to
reduce the bandwidth overhead of sending the rules in plain text and
also to increase the number of rules that could possibly be stored in the
authorization cache. The access rules in the DP could be stored in the
normal databases, XML format or in the JSON format. These formats
facilitate easy management of the access rules. From that format, the
access rules are encoded to the TLV format. TLV is a standard for
encoding [26] and is extensively used in the many data communication
protocols. We describe the details of the access rules format in the DP
and the TLV protocol in the section 5.3.2. We have following three
cases of cache-miss, when device d1 accesses device d2 :
(a) Device d2 does not know the identity and access clearance of d1
and there is no mutually shared key between the two devices. For
the first time access between d1 and d2 , there is definitely a cache
miss of this type. This might also happen during the subsequent
accesses from d1 to d2 if both the authentication and authorization
caches get cleared. The access procedure takes place similar to the
second centralized variant we discussed before with the notable
difference that DP, along with the final decision, also sends the
access rules responsible for the decision. These access rules are
encoded to reduce the bandwidth overhead.
(b) Devices d2 and d1 have the mutually shared key and device d1 has
the service ticket but device d2 does not know the access clearance
of the device d1 . This happens due to authorization cache-miss.
The access procedure, including both the authentication and au-
thorization, takes place similar to the first centralized variant we
discussed before. However, DP, along with the final decision, also
sends the encoded access rules responsible for the decision.
(c) Device d1 or d2 do not have the mutually shared key but device d2
still has the access rules corresponding to device d1 . This happens
due to authentication cache-miss. In this case, d1 and d2 au-
thenticate mutually using the centralized TP and d2 subsequently
evaluates the decision based on its stored rules.
3. Cache-hit access: The access procedure is similar to the distributed
variant we discussed before. We also propose that the authorization
cache update in the device either happens when the cache is full and
new entry needs to be added or through explicit communication from
the central DP when a cache entry is stale according to the DP.
Figure 4.4 summarizes the details of the hybrid variant.
Advantages :
1. Increased efficiency for frequently communicating devices.
Disadvantages :
1. Added complexity in the system architecture
4.1.2 Design 2: Context handling

Access control in building systems depends extensively on the context. Con-
text can be global (e.g time, fire, etc.) or local to a device (e.g. natural
illumination in the room, presence of people in the room, etc.). We look at
the context handling from an slightly different angle. We view a context pa-
rameter as a service e.g. fire notification is a service provided by fire sensors,
Device 1 Decision Point Trust Point Device 2
Authentication (using PSK or TP)
Service request 1
Evaluation request
Decision,
Policy caching
Encoded policy
Service request 2
based on the cache
Figure 4.4: Access control in hybrid variant
time notification is service provided by the device itself, people presence in the
room is provided by the presence detector, etc. This means that the access
control for a device now depends on the services provided by other devices or
on the services provided by the device itself (e.g. time or presence detector).
Incorporating this would make our access control rules dynamic as opposed
to the static rules that we have been dealing with till now. These dynamic
access control rules are termed access policies based on the study conducted
in [41]. However, we still need a framework to support the dynamism of the
access control rules. Incorporating the access control in our existing architec-
ture will only change the authorization phase while the authentication phase
will remain unmodified. We easily infer that a generalized implementation
of context handling would be impractical in a fully distributed variant e.g.
in case of fire, it would be impractical if a single resource-constrained fire-
alarm device had to inform all the other devices in the building about the
fire context. Therefore, we consider only the centralized and hybrid variant
in case of context handling.
Centralized: We consider device d1 accessing the device d2 . All the context

parameters, including the ones local to the device d2 , are collected by
the monitoring device and stored in a centralized place. This transfer of
the context information is done either through event publish-subscribe
or through explicit context information request. Efficiency of event
publish-subscribe is easily understood from the use case that we would
not want monitoring device to explicitly communicate to fire sensor
each time a device is accessed. The DP fetches these context param-
Device 1 Device 2
Decision
Point (DP)
Policies Contexts
Administrative
Point (AP)
Figure 4.5: Centralized architecture for context evaluation
eters form the centralized context repository at the time of evaluating

the access policies. We design the access control policy language such
that the communication protocol (e.g. pub-sub or explicit request) are
specified for each context parameter. From the device perspective the
access procedure is similar to the centralized variant we discussed in
the design 4.1.1. The scenario is pictorially presented in the figure 4.5.
Hybrid: All the relevant context parameters that can be fetched without
contacting the device d2 are stored in the central context repository
and evaluated at the DP, others are stored in d2 and are evaluated
at the d2 itself. In this approach, the decision evaluation is actually
distributed in the sense that only a part of the decision is taken at
centralized DP. When a particular policy is invoked as result of d2
requesting the access decision from DP , the context parameters present
in the DP are evaluated. The remaining context parameters are left
for the d2 to evaluate. Two logic of the policy, one containing the
unevaluated context parameters and other containing the results of
evaluated contexts, are encoded in the TLV format. The encoded policy
is then sent to the device d2 . d2 first stores the encoded policy in the
authorization cache, then calculates the final decision by substituting
current values of the local context in the partial decision.
In the case of subsequent similar requests from d1 to d2 , d2 acts as
a context repository for all the context present in the policies stored
in its cache. The communication protocol (event publish subscribe or
explicit communication) is specified in the encoded policy itself which
helps the device d2 to gather those context variables.
4.1.3 Design 3: Addressing range of devices

In this section we address the requirement of access control for a range of
devices. There are a number of ways in which a group or a range of devices
can be addressed but the simplest and the most efficient one is by means of
multicast or broadcast. The biggest issue in enforcing access control while
broadcast and multicast is that all the recipient devices receive identical
packets. Authentication itself is not trivial in the broadcast communication
and has been studied in [29], [37], [31], [12]. Moreover, a device executing a
multicast action must not expect any response other than the response code
indicating successful execution in order to avoid response floods. We discuss
following two ways to incorporate the functionality of multicast in BACS.
Centralized: In centralized variant, we assume that broadcast and mul-
ticast is always performed by a specialized and relatively resourceful
entities in the same network as the end-devices. Therefore, if a user
wants to execute a command on multiple devices in a domain, it will
first have to unicast the control sequences to the DP. Once the autho-
rization of the user to broadcast an execution message is confirmed by
the DP, the DP forwards the authentic execution message to all the
broadcast entities in different networks which eventually sends the ac-
tion message all the way to their corresponding end-devices. The logic
behind this is to support communication architectures where a domain
is divided into different communication networks. If in case there is
only single network in a domain the functionality of the DP and the
broadcast entity could be trivially combined.
Consider an example when a single switch is used to turn off all the
lights in a building. The switch will first unicast to the DP of the
domain, a message containing the required the turn off execution com-
mand. The DP checks the access control policies of the required switch.
If the switch is allowed to execute the turn off command, DP forwards
the request to the broadcast entity in all the different networks in the
domain. The broadcast entity ultimately send the command to the
end-devices.
We present here following two ways to implement the centralized vari-
ant:
1. The client device first authenticates itself to the DP in the domain.

This is achieved using the pre-shared keys between client and the
DP (the same procedure was discussed in 4.1.1). After the ini-
tial authentication, DP accepts the action request from the client
and evaluates the policies to determine if the client is allowed to
multicast the requested action. If the client is not allowed then
appropriate error response is sent back to the client, otherwise the
action is multicasted to the devices through the broadcast enti-
ties. DP multicasts the action using a network wide pre-shared key
with the end devices. The original action must be appended with
a time stamp in order to prevent anonymous replay attacks. The
end devices must only send an acknowledgement if the response is
a success code. Its only the simplicity which makes this approach
attractive. However, following are the few obvious security issues
with this implementation:
• Any node can potentially execute any action on a node present
in the same communication network. The attacker node broad-
casts the action it wants to execute using the network wide
pre-shared key.
• Once the group shared key is compromised, an outside at-
tacker can execute actions on any node.
2. The second approach differs from the first one only in the way DP
authenticates itself. The DP authenticates their action messages
using the µTESLA approach discussed in [19]. Following are the
pitfalls of this approach:
• Highly complex to implement.
• Requires strict time synchronization between the DP and the
end-devices.
Hybrid: In the hybrid variant, if an end-device wants to execute an action

on a range of devices, it will multicast the action in its own communica-
tion network and unicast the control sequences to the DP to eventually
forward the action messages to the other networks. The basic prob-
lem with the hybrid variant is similar to the one in distributed variant.
Since the message goes directly from the device executing the multicast
message to all the recipient devices in the network, all the devices have
to main the access policies for all the other devices. This approach is
not practical and has issues similar to the distributed variant of the
Design 1 discussed in 4.1.1.
4.2 Access control with third party interac-

tions
Third-party domain (e.g. blue in figure 3.1) with respect to a domain (green)
refers to a collection of devices that are not trusted in the domain (green).
It is reasonable to assume that 3rd party devices might communicate us-
ing different application language or possibly have different protocol stack
altogether. However, we will assume that there are appropriate translators
installed on the path to the 3rd party devices. There needs to be a non-empty
set of symmetric encryption algorithms and hashing algorithms common be-
tween the two domains to establish a secure channel between them. The
requirement for trust authority (TA) between two interacting parties comes
from the fact that devices in each domain do not know and trust each other.
Therefore, we also assume that there is a trust authority mediating the trust
between the domains. Following are the requirements for the TA:
• Secure communication channel must be established between the domain
and the TA regardless of the communication address and location of
TA.
• TA must be able to identify the devices present in the domains. The
identification of the devices is either through the centralized TP in the
domain as in the case of centralized architecture or by direct commu-
nication with the device in the distributed architecture.
• Since TA has to interact with the various parties having different com-
munication protocols, we assume that TA has appropriate translation
capabilities.
4.2.1 Design 4: Third party interactions

We develop the design for access control by keeping in mind the following
use case: In figure 3.1, we have the window-blinds domain as blue and the
lighting domain as green. We want the window-blinds in office 1 to have
certain control over the lights in the office 1 and no control over the lights in
other offices. We will view the design from the lighting domain’s perspective
and window-blinds domain would be the 3rd party domain. The window-
blinds domain functional architecture can be any of the three previously
discussed designs. We have the following variants for functional architecture:
distributed-distributed : In this variant, both local domain and the 3rd
party domain have distributed architecture as described in section 4.1.1.
Window-blind (W) domain
TA TP
AS TGS AS TGS
3. TGT TA
1. Auth 4. TGT W
5. TGT W
2. TGT TA
6. Ticket Service
Lighting (L) domain
User Service
Device Device
7. Ticket Service
8. Mutual Auth
Figure 4.6: Step by step authentication in distributed-centralized variant
Fully distributed-distributed model is highly limited in the number of

devices it can support. Effectively, this will generate a model analogous
to the single domain model with centralized TP. In place of TP we here
have TA. Since this model is not very practical, we would not go into
the details of it.
distributed-centralized In this variant, the local domain has distributed

architecture and the 3rd party domain has the centralized architecture
for trust as described in section 4.1.1. Inter-domain authentication in
this scenario would be performed using the Kerberos itself. The eight
step authentication is described pictorially in figure 4.6. The local user
device in lighting domain authenticates itself to the Authentication
Service of the TA and receives a Ticket-granting ticket for the TGS in
TA which we named TGT TA. Using TGT TA the user device receives
TGT W from the TGS in TA to be used for the TGS in the TP of
Window-blind domain. Using TGT W the device receives the actual
Ticket for the service form TGS in the TP of the Window-blind do-
main. This ticket is used for the mutual authentication between the
user device and the 3rd party service device.
After the authentication phase is completed authorization is performed
trivially using a DP in the window-blind domain. The service device
TA
AS TGS
5. TGT TA
6. TGT W
Lighting (L) domain Window-blind (W) domain
TP TP
AS TGS AS TGS
3. TGT L
1. Auth 4. TGT TA
2. TGT L 7. TGT W
8. Ticket Service
User Service
Device Device
9. Ticket Service
10. Mutual Auth
Figure 4.7: Step by step authentication in centralized-centralized variant
contact the DP to check if the user device light is allowed to perform the
requested action. The service request is allowed or rejected according
to the decision provided by the DP in the window-blind domain.
The model centralized-distributed can be easily understood in terms of
this model with the parties interchanged.
centralized-centralized : In this variant, both the local and and the 3rd
party domain have centralized architecture for access control. For au-
thentication between devices of different domain, as presented in the
figure 4.7, we have transited domain TA which facilitates the trust rela-
tion. Overall, the authentication is a ten step process and is analogues
to the distributed-centralized variant except we have one more TGS (in
the local domain).
Once the authentication in between the devices is established, the au-
thorization is performed by the domain providing the service as was in

the distributed-centralized variant.
hybrid-hybrid : This variant explain the scenario when both local and
3rd party domain have hybrid architecture for access control. There
can be many other combinations with the hybrid variant, such as,
hybrid-distributed, centralized-hybrid, but understanding of hybrid-
hybrid would trivialize them. Again, the main motivation for the
hybrid-hybrid variant come from the fact that it would be impracti-
cal to have so much communication overhead for a window-blind to
just dim the light present in the same room. In hybrid-hybrid variant
the devices store the session keys of the devices in the authentication
cache.
The same pattern follows with the authorization policies. Once the
authorization decision is evaluated by the DP in the domain providing
the service, the encoded policies are sent to the actual device providing
the service. Hence, upon receiving subsequent similar requests, the
device providing the services would not need to contact the DP of its
domain. The authorization cache update procedure is similar to the
single domain architecture. It either happens when the cache is full
and new entry needs to be added or through explicit communication
from the central DP when a cache entry is stale according to the DP.
Context parameters are handled in almost the similar way as in the case
of single party domain except the context variables can now be shared
between the domains. We propose that all the context variables whose
values are obtained from outside the domain are categorized as global
context variable and hence be processed at the central DP and stored
at the central context database. This proposal not only simplifies the
architecture but also increases the scalability in case of multiple 3rd
party domains.
Step by step procedure is presented in the figure 4.8. In figure 4.8, we
present the procedure when the authentication and authorization cache
are empty. In the case when encoded policy is present in the cache of
the device, device evaluates the policy by itself and access procedure is
trivial. Context parameters from the third party are handled centrally.
Therefore, context from the third-party are stored and evaluated at
DP. The access control on the context variables themselves from the
third-party domain is discussed in detail in the discussion chapter 7.2.
Overall the architecture is very similar to the one presented in the
centralized-centralized variant except the caching functionality.
TA
AS TGS
5. TGT TA
6. TGT W
Lighting (L) domain Window-blind (W) domain
TP TP
AS TGS AS TGS
3. TGT L
1. Auth 4. TGT TA
2. TGT L
12. Policy Request DP
7. TGT W
15. Policy Response
8. Ticket Service
14. Context
13. Context
Response
Request
User Service
Contexts
Device 9. Ticket Service Device
10. Mutual Auth
11. Service Request
16. Service Response
Figure 4.8: Step by step access procedure in hybrid-hybrid variant
We discussed a very basic model for the 3rd party access control system.
There are various aspects for the future work. Notably, a framework for
the discovery of devices based on various attributed and automated policy
definition for the device just after the discovery.
Chapter 5
Implementation and system pro-

totype
Implementation as a proof-of-concept is a fundamental part of this work.

The first section of this chapter describes the details of the designs that we
implement along with various justifications. The second section provides the
details of the hardware and the operating systems used in the setup. It is a
typical example of a BACS device. The third section presents step by step
details of implementations.
5.1 Implemented designs

We implemented two designs as prototypes. Design 2 described in sec-
tion 4.1.2 with centralized authorization variant is our first implementation.
We improved the design by adding the caching of the authorization policies
in our second implementation. Therefore, Design 2 described in the sec-
tion 4.1.2 with the hybrid variant is our second implementation. The choice
of the designs implemented depend on following factors:
• The hybrid design presented in the section 4.1.2 is the most sophisti-
cated design which is feasible to implement in the planned time period.
• We used the centralized design presented in the section 4.1.2 as the first
step to implement the hybrid design so that we could later compare the
time efficiency and memory requirements of the two designs.
We do not implement the authentication part of the designs mainly be-

cause we assume the authentication to be performed by a generic protocol
like DTLS for sensor networks which authenticates all the messages in the
44
CHAPTER 5. IMPLEMENTATION AND SYSTEM PROTOTYPE 45
Figure 5.1: Front Figure 5.2: Back
application layer. The DTLS for sensor network is a system developed and
implemented by a parallel project which is based on generic DTLS protocol
[23].
5.2 Hardware specifications

We use a standard PC hardware with Linux as the operating system for the
resourceful devices e.g. decision point (DP), trust point (TP), etc. We use
the MC1322x Econotags [21] running Contiki OS for constrained devices [8]
as wireless sensor nodes. Figures 5.1 and 5.2 describes the model hardware.
The relevant hardware specification of MC1322x are as follows:
• IEEE 802.15.4 standard compliant on-chip transceiver/modem
– 2.4GHz
– 16 selectable channels
• Advanced encryption/decryption hardware engine (AES 128-bit)
• 32-bit ARM7TDMI-S CPU core with programmable performance of up

to 26 MHz (24 MHz typical)
• Extensive on-board memory resources
– 128 Kbyte serial FLASH memory (can be mirrored into RAM)

– 96 Kbyte SRAM
– 80 Kbyte ROM
5.3 Implementation details

In both the implementations, policies in the centralized DP are stored in the
JSON format. We switched from XML (used in XACML) to JSON primarily
because of following reasons:
• JSON is less verbose as compared to XML.
• Interpreting the JSON is more efficient as compared to XML.
Although all the components described in the XACML are not incorporated
in the implementation, the policy language (JSON) is such that it has one-
to-one mapping to the markup language for future enhancements.
A part of the model policy file in the DP is presented in the figure 5.1.
The policy file has been designed such that target device is on the top of
the JSON hierarchy. This is because encoding the policy related to the
target device becomes more efficient, which we will see in the details of the
hybrid implementation. The JSON policy language supports the role based
definitions of the policies. Therefore, we are able to aggregate the policies for
large numbers of users in the BACS. Each target devices is mapped with a
number of roles which applies on it. Therefore, if a request comes to a target
device from a certain user, then the user must belong to one of the mapped
roles in order to successfully execute the action.
Inside each role we have a set of the actions that are associated with
the role e.g. “action” : “on” in the role admin as seen in the figure 5.1.
Each action is further associated with an array of conditions related to con-
text variables. Details regarding each context variable starts with the tag
attribute. Following are the details of subtags of attribute:
id: Context variable is identified by the tag id .
communication: Inside the tag attribute we also have communication pro-

tocol using which the value of the context variable is supposed to be
updated.
priority: This tag is used to denote the priority of the context variable
during caching. Caching algorithm is supposed to use this tag for
intelligent caching.
scope: It decides if the context variable is evaluated by the DP when the

tag value is global or if the context variable is evaluated by the device
itself when the tag value is local .
eval: Finally, we have a recursive structure of eval tags which depicts a series
of nested binary condition to which the context variable is subjected.
We would again like to mention that we do not implement the authenti-

cation part of the designs since it is developed and implemented by a parallel
project. Following subsections discuss the two implementation in details:
5.3.1 Implementation 1: Centralized decision point

Figure 5.3 presents the overview of the software components in the system
and the transaction flow for the authorization phase.
Application layer is composed of RESTful constrained application pro-
tocol (CoAP) server [35] running on Contiki OS [8] on sensor nodes. On
resourceful DP, the CoAP server runs on standard Linux kernel. Both the
device services and the DP services are exposed through the CoAP server.
Following are the key steps involved in execution of an access request.
1. Service request from Node 1 to Node 2: When CoAP client in Node

1 requests a service from Node 2, it is first intercepted by the access
control layer before it is served by the actual service, as denoted by
transaction numbers 1 and 2 in the figure 5.3.
2. Service request forwarded to DP for access evaluation: The access

control layer in Node 2 spawns a new CoAP client and sends its own
(Node 2) principal name along with the Node 1’s principal name, and
Node 1’s service request to the DP. DP has a global scope IPv6 address
and hence the message from the Node 2 is intercepted by the Bridge
and ultimately forwarded to the DP outside the 802.15.4 network. This
set of conversation is denoted by transaction number 3 - 5 in the figure.
3. Policy evaluation by DP and decision sent to Node 2: The CoAP

server at the DP receives the request from the Node 2 and checks if it
is allowed to access the polices related to the request it sent using the
meta-access control policies. If allowed, the request parameters (Node
1’s principal name, Node 1’s service request and Node 2’s local con-
text parameters) are passed to the JSON interpreter. The open source
library used for JSON parser is JSMN[40]. JSMN works with tokens.
To explain further, consider the following JSON string:
‘{ "name" : "Dave", "age" : 54 }’
It holds the following tokens:

Object: ‘{ "name" : "Dave", "age" : 54}’ (the whole object)

Strings: ‘"name"’, ‘"Dave"’, ‘"age"’ (keys and some values)
Number: ‘54’
In JSMN, tokens do not hold any memory for the data, but point to
token boundaries in JSON string instead. JSMN has following token
types:
Object: a container of key-value pairs, e.g.:‘ “foo”:“bar”, “x”:0.3 ’

Array: a sequence of values, e.g.: ‘[ 1, 2, 3 ]’
String: a quoted sequence of chars, e.g.: “foo”
Primitive: a number, a boolean (‘true’, ‘false’) or ‘null’
Once the token boundaries are extracted, the user loops over the to-
ken to match the interested objects. On our case, the process works
according to the pseudocode 1. The JSON interpreter evaluates the
policies containing the context variables to get the decision. It returns
the final decision to the CoAP server. The CoAP server sends the final
evaluated decision to the CoAP client in Node 2. The message pass-
ing is again done through the Bridge. These set of conversation are
denoted by transaction number 5 - 11.

Input: UserDevice, ServiceDevice, Action, RolesDB, JSONPolicyFile,
ContextParameterValuesDB
Output: FinalDecision
allRoleNames := findRoleNames(UserDevice, RolesDB);
currentRoleName := allRoleNames.first;
jsmnTokens := jsmnParse(JSONPolicyFile);
while currentRoleName is not NULL do
roleDetails := findRole(currentRoleName, jsmnTokens);
if roleDetails.allow(Action) then
allRelevantContexts := findContexts(jsmnTokens, roleDetails);
contextAllows := TRUE;
foreach currentContext in allRelevantContexts do
if evaluteContext(currentContext,
ContextParameterValuesDB) == FALSE then
contextAllows := FALSE;
break;
end
end
if contextAllows == TRUE then
FinalDecision := “ALLOWED”;
return FinalDecision;
end
end
currentRole := allRoleNames.next;
end
FinalDecision := “DENIED”;
return FinalDecision;
Algorithm 1: Policy evaluation at central DP
4. Decision received by Node 2: The CoAP client in the Node 2 receives

the final decision and returns it to the access control layer. The access
control thread closes the CoAP client and clears all the buffers, denoted
by 12 and 13 in the figure.
5. Service granted or denied based on the decision: If the decision re-

ceived by the access control layer is negative, it denies the service action
requested by the Node 1 and forwards the appropriate error response
to the Node 1. Otherwise, if the decision received by the access control
layer is positive, the action request is forwarded to the service. The
CoAP server at Node 2 executes the action, returns the response to the
CoAP client in the Node 1 and clears the buffer related to connection
802.15.4 Network
Node 1 (service requestor) Bridge (802.15.4 - 802.3)

MC1322x Econotag Hardware MC1322x Econotag Hardware
Device
Services
AC Layer
5 10
CoAP Client
CoAP server
4
DP
CoAP server
11
6 9
1 16 JSON
Interpretor
8
CoAP server JSON ﬁle
7
2 CoAP Client Database
15
12
AC Layer
14 13 3
CoAP Client
Device
Services
MC1322x Econotag Hardware PC Hardware
Node 2 (service provider) DP
Figure 5.3: Centralized Authorization Implementation

after the successful reception of the message by the CoAP client at

Node 1. This conversation is reflected by the transaction number 14 -
16 in the figure.
5.3.2 Implementation 2: Hybrid decision point

In this section we discuss various implementation details of the hybrid design
proposed in the section 4.1.2. Following are the steps:
1. Service request from Node 1 to Node 2: As we already discussed in

the design section 4.1.1, the major problem with the centralized variant
is that every simple service request, such as turning on a light, has to
go through the centralized DP. This creates a system bottleneck for the
service requests at the DP. To solve this problem, we proposed caching
of policies at the device level.
Therefore, if there is a cache hit when receiving the request from the
Node 1 the access control decision is evaluated in the device itself. We
further explain the pseudo code of the evaluation while discussing the
caching algorithm later in this section. In case of cache miss, this step
is similar to the implementation in centralized variant 5.3.1.
2. Service request forwarded to DP for access evaluation: In case of

the cache miss the request is forwarded to the DP for access control
evaluation and encoded policies. The forwarding procedure is same as
that in the implementation 5.3.1.
3. Policy evaluation and encoding by DP, and result sent to Node 2:

There are three sub-steps in this major step. First, the policy is par-
tially evaluated since the context parameters are present both in the DP
and the device. Second, the policy is encoded and third, the encoded
policy sent to the device.
The partial evaluation is done according to the pseudo code 2. There
are two major changes as compared to pseudo code 1. First, only the
global context variables are evaluated at the DP since the local context
variables are supposed to be evaluated in the device itself. Second, the
return value is the encoded policy containing both the global and local
context variables as compared to the final decision.

Input: UserDevice, ServiceDevice, Action, RolesDB, JSONPolicyFile,
ContextParameterValuesDB
Output: EncodedPolicy
allRoleNames := findRoleNames(UserDevice, RolesDB);
currentRoleName := allRoleNames.first;
jsmnTokens := jsmnParse(JSONPolicyFile);
while currentRoleName is not NULL do
roleDetails := findRole(currentRoleName, jsmnTokens);
if roleDetails.allow(Action) then
allGlobalContexts := findGlobalContexts(jsmnTokens, currentRole);
contextAllows := TRUE;
foreach currentContext in allGlobalContexts do
if evaluteContext(currentContext,
ContextParameterValuesDB) == FALSE then
contextAllows := FALSE;
break;
end
end
if contextAllows == TRUE then
EncodedPolicy := EncodePolicy(roleDetails);
return EncodedPolicy;
end
end
currentRole := allRoleNames.next;
end
EncodedPolicy := NULL;
Algorithm 2: Policy evaluation at hybrid DP
For example, consider a complex policy presented in the Appendix A.
For the role admin and action on, the attribute time is global whereas
the attributes people presence and natural illumination are local to
the target device light. Hence, the attribute time is evaluated at the
DP to check if the request is received after the noon but attributes
people presence and natural illumination are left as is for the device to
evaluate.
The caching functionality at the device would be effective only if we
take care of the size of the policy and its efficient evaluation at the
device level. A simple analysis of the policy at 5.1 corresponding to a
device and an action gives us the size of around 300 bytes in ascii. In
other words, we use around 300 bytes corresponding to the each unique
tuple of requester principal name and action. Keeping in mind the

hardware specification, if we allocate a modest amount of 3 kilobytes
for the authorization cache, then we could possibly serve only around
10 unique requests without contacting the centralized DP. Moreover,
interpreting the JSON text in the constrained devices also consumes
significant amount of active memory. For these reasons, we encode the
policies in the DP before sending them to the devices.
As mentioned in the design section 4.1.1, we encode the policies in the
TLV format [26]. We use four bits to represent each type in the system.
With reference to the model policy file presented in the figure 5.1, our
standard types in the TLV format are presented in the table 5.1:
condition 0000
attribute 0001
id 0010
communication 0011
priority 0100
scope 0101
eval 0110
function 0111
value 1000
Table 5.1: TLV pre-defined types
Each type has a value. The scope of the value in the encoded policy is
de-limited by the length. The length describes number of bits in which
the value is represented. The basic length is represented by four bits.
If the first bit of those four bits is 0, then the next 3 bits describes the
actual length of the value. Otherwise, if the first bit is 1, then the next
3 bits describe the length of the actual length in four bit words.
The values in the system are also pre-defined. For example, the type
‘id’ has the pre-defined values of length four presented in the table 5.2.
If in future, the number of pre-defined values for the type ‘id’ increases
beyond 16 (= 24 ) we increase the length and interpret the value in
the big-endian format. Therefore, if we increase the length of the type
‘id’ from four to five we have the values presented in the table 5.3.
The comprehensive table 5.4 presents all the basic types and their pre-
defined value till now.
time 0001 time 00001

fire 0010 fire 00010
people presence 0011 people presence 00011
natural illumination 0100 natural illumination 00100
temperature 0101 temperature 00101
humidity 0110 humidity 00110
Table 5.2: TLV pre-defined values for Table 5.3: TLV pre-defined values
the type ‘id’ changes for the type ‘id’
For example, again consider the role admin and action on in the policy
presented in the Appendix A. The encoding of the policy is showed in
the table 5.5. The pseudo code for encoding and decoding of the policy
consists of trivial mapping and hence omitted.
This encoded policy is sent to the device as the reply. The sending
procedure is similar to the sending procedure of the final decision of
the centralized implementation 5.3.1.
4. Encoded policy cached by Node 2: The CoAP client in the Node 2

receives the encoded policy and returns it to the access control layer.
The access control thread closes the CoAP client and clears all the
buffers, denoted by 12 and 13 in the figure.
The caching algorithm implemented is the classical least recently used.
We discards the least recently used items first. We used circular linked
list as the data structure to store the encoded policies. The most
recently used policy is automatically placed at the head of the linked
list. Therefore, when the linked list is full we remove the tail element
of the linked list to introduce the new policy at the head. The circular
linked list data structure is good for the variable length policies because
the memory for the storing the policies is obtained from the central
memory management module and only the pointers to those memory
location are arranged in the circular linked list.
When there is a cache miss and a new policy is received by the Node
2, the cache is updated according to the simple pseudo code 3

Input: UserDevice, Action, Role, EncodedPolicy, List
Output: List
listElement := createListElement(UserDevice, Action, Role,
EncodedPolicy);
if List.size >= MAX then
lruElement := List.previous;
lruElement.previous.next := List;
List.previous := lruElement.previous;
delete(lruElement);
List.size := List.size - 1;
end
listElement.next := List;
listElement.previous := List.previous;
List.previous := listElement;
List.previous.next := listElement;
List := listElement;
return List;
Algorithm 3: Cache update at device in hybrid architecture
When there is a cache hit the cache is searched and updated according
to the pseudo code 4
Input: UserDevice, Action, Role, List
Output: EncodedPolicy
listElement := List;
while listElement is not NULL do
if listElement.userDevice == UserDevice and
listElement.action == Action then
EncodedPolicy := listElement.encodedPolicy;
listElement.previous.next := listElement.next;
listElement.next.previous := listElement.previous;
listElement.next := List.next;
listElement.previous := List.previous;
List.previous.next := listElement;
List.previous := listElement;
List := listElement;
end
listElement := listElement.next;
end
return NULL;
Algorithm 4: Cache search at device in hybrid architecture
5. Service granted or denied based on the decision: Once the encoded

policy is evaluated at the device, the decision is enforced by the access
control layer either by sending the error code to the Node 1 in case of
access denied or by allowing the CoAP server to serve the request.
1 {
2 "target":"light1",
3 "admin" : [{
4 "action" : "on",
5 "condition" : [{
6 "attribute":{
7 "id":"time",
8 "communication":"expcomm",
9 "priority":"normal",
10 "scope":"local",
11 "eval":{
12 "function": "lt",
13 "value":"12"
14 }
15 }
16 }],
17 },
18 ...
19 ],
20 "user" : [{
21 "action" : "on",
22 "condition" : [{
23 "attribute":{
24 "id":"time",
25 "communication":"pubsub",
27 "scope":"local",
28 "eval":{
29 "function":"OR",
30 "eval":{
31 "function":"AND",
32 "eval":{
33 "function":"lt",
34 "value":"20"
35 },
36 "eval":{
37 "function":"gt",
38 "value":"16"
39 }
40 }
41 "eval":{
42 "function":"eq",
43 "value":"3"
44 }
45 }
46 }
47 }],
48 },
49 ...
50 }
Listing 5.1: JSON policies

type
length
value
condition 0000
attribute 0001
id 0010
4 0100
time 0001
fire 0010
people presence 0011
natural illumination 0100
temperature 0101
humidity 0110
communication 0011
1 0001
pubsub 0
expcomm 1
priority 0100
2 0010
high 00
normal 01
low 10
scope 0101
1 0001
local 0
global 1
eval 0110
function 0111
4 0100
AND 0000
OR 0001
gt 0010
lt 0011
eq 0100
value 1000
Table 5.4: TLV pre-defined types and values

“condition” : [{ 0000 1011 0001 0010 1011

“attribute”:{ 0001 1010 0110 0100
“id”:“time”, 0010 0100 0001
“communication”:“expcomm”, 0011 0001 1
“priority”:“normal”, 0100 0010 01
“scope”:“global”, 0101 0001 1
“eval”:{ 0110 1010 0010 1100
“function”: “lt”, 0111 0100 0011
“value”:”12” }}, 1000 1010 0001 0000
0011 0001 0011 0010
“attribute”:{ 0001 1010 0010 1100
“id”:“people presence”, 0010 0100 0011
“scope”:“local”, 0101 0001 0
“eval”:{ 0110 1010 0010 1100
“function”: “eq”, 0111 0100 0100
“value”:“true” }}, 1000 0001 1
“attribute”:{ 0001 1010 0010 1100
“id”:“natural illumination”, 0010 0100 0100
“scope”:“local”, 0101 0001 0
“eval”:{ 0110 1010 0010 1100
“function”: “lt”, 0111 0100 0011
“value”:“1000”}}}] 1000 1001 1100
0011 1110 1000
Table 5.5: Encoding of the policy presented in the Appendix A

Chapter 6
Evaluation
In this chapter, we present an evaluation of the implementation described in

the previous chapter. The first section includes the memory requirements of
the code while the second section presents the performance measured from
the service provider’s perspective.
6.1 Memory requirements

Memory requirements by the access control engine is an important parameter
to evaluate the system prototype when the basic requirement is to serve
constrained devices. The first part of this section covers the size of the
compiled code in the RAM of the device while the second section compares
the size of the JSON policies in the DP with the size of the encoded policies
in the constrained devices.
6.1.1 Code size

We present the size of the compiled binary code which provides the function-
ality of the access control system. This excludes the size of the code which
provides the functionality of the CoAP server through which the service is
provided. Needless to mention, this size also excludes the size of the uIP
stack code. In total, the size of the access control system is 4908 bytes which
is acceptable to us with respect to the hardware we use.
The code size of each part of the access control system is presented in the
table 6.1. General purpose CoAP handler functions notably include retriev-
ing and setting the query options, header content type, and the payload. It
also contains the size of the code responsible for parsing the binary CoAP
packet when it arrives. Other classifications are self explanatory.
60
CHAPTER 6. EVALUATION 61
Other than the size of the code presented in the table 6.1, we use 2000
bytes to store all the data structures for the CoAP and the access control
system. Moreover, we use extra 2000 bytes as the cache to store various
policies in a linked-list data-structure.
Size in bytes Description

1496 General purpose CoAP handler functions
626 CoAP client to get the encoded policies from the DP
1196 Searching and evaluating the decision from the cache
980 Extracting the query parameters from the CoAP request
600 Other helper functions
Table 6.1: Code size of the each part of the access control system
6.1.2 Policy size

In general, the policy size depends on the way the policies are structured for
the BACS system. Nevertheless, we present here the size of the typical policy
for the single device both in JSON format and the binary encoded format.
The size of the JSON format including two roles is approximately 1270 bytes.
The full JSON prototype policy file is presented in the appendix A. The size
of one role in the JSON format is typically 600 bytes whereas the size of the
same role when encoded in the binary format is around 15 bytes.
We use the cache size of the 2000 bytes for the policies in the RAM.
Therefore, simple calculation shows that we could store only 3-4 roles in the
cache if we use the JSON format for the policies. However, with the encoding
in place we now store approximately 100 roles in the cache. Once again, we
would like to highlight the fact that the prototype roles only contained 2-3
permissions on a single resource and hence the size calculations would vary
greatly depending on the role formations.
6.2 Performance
We have strict requirement for low latency in the BACS e.g. there must not
be a notable lag between the action switch on and actual turning on of the
light. The following section presents the time required for serving a typical
request in the system prototype.
CHAPTER 6. EVALUATION 62
6.2.1 Time measurements

It is important to note that the purpose of the time measurements provided
in this section is just to compare the hybrid and the centralized version of
the implementation. These time measurements do not reflect the on field
efficiency of the devices because of the following reasons.
• The devices in the prototype setup were in close proximity.
• The devices in the prototype setup were limited in number.
• There were almost no packet loss because of the noise.
The time required by the device between receiving the request and sending
the reply (i.e. between steps 1 and 16 according to the figure 5.3) when using
the central DP to get the decision is approximately 0.09 secs. This does not
include the time required to put the policy in the cache. The time required
when there is a cache hit in hybrid architecture is approximately 0.02 secs.
The number of significant digits in the time measurements comes from the
limitation of the system clock in the device. These time measurements are
averaged over 10 samples. The increased time efficiency of the system in the
hybrid version is clearly perceived. Following are the main reasons for this
increase in the time efficiency:
• No network overhead to contact the DP.
• Evaluation of the encoded policies is more efficient than the JSON

policies.
Chapter 7
Discussion
7.1 Complexity of the overall architecture

All the proposed architectures are based on the fact that in the end the ser-
vice request-response is through device to device communication as opposed
to central controller for each and every communication. In distributed sce-
nario, the communication is entirely device to device. In centralized scenario,
the starting access control is through central entities and subsequent request-
response is device to device. Whereas, in hybrid, the starting access control
might be through central entities depending on the cache hit or miss but the
service request-response is again device to device. There is one basic reason
why we did not study the case when every communication is through central
controller. Using central controllers for each and every communication be-
tween the devices scales very poorly. With some 20000 devices in a typical
building [36], constant communication between them would require a lot of
extra resourceful hardware to serve as controllers. This adds the system cost
in various areas such as extra energy consumption, maintenance, system ad-
ministration and not to mention the hardware cost itself. However, without
any central automated control installing new devices manually could be te-
dious and impractical. Therefore, we assume the case when bootstrapping
of the devices is done centrally and subsequent communication is device to
device.
From the access control perspective there is a huge difference between us-
ing central controller for every communication verses using central controller
for only bootstrapping purposes. In the case of the central controller per-
forming every communication, existing access control frameworks from the
information technology could be used without any modification since all the
modules corresponding to the access control system will be on the resourceful
63
CHAPTER 7. DISCUSSION 64
central controllers. Whereas, in the case of the central controller being used
for only bootstrapping and initial configuration purposes, there needs to a
new framework for access control since service request-response is device to
device and devices have constrained resources.
7.2 Context handling in third-party domains

Context variables whose values are obtained from the 3rd party domain are
categorized as global context variable and hence be processed at the central
DP and stored at the central context DP. Similarly, the local domain would
have its context variables to share with the 3rd party domain. What all
context variable should be shared to the 3rd party domain is another branch
of access control. Access control in the context variable depends on the
negotiations between the two party and is implemented in the bootstrapping
stage. For example, there might be negotiation between the lighting domain
and the window-blind domain that window-blind domain would share its
natural illumination context values to the lighting domain. On the other
hand, there might be no such negotiations between the window-blind domain
and the heating and air-conditioning domain.
7.3 BACS current and future

As we have already discussed in the introduction section 1, BACS is inter-
linked, networks of hardware and software, which monitor and control the
environment in building facilities. Following are the few systems that are a
part of BACS:
• Chillers
• Fan coil units
• Boilers
• Ventilation units
• Roof-top units
• Power monitoring
• Heat pump units

CHAPTER 7. DISCUSSION 65
• Security system
• Plumbing and water monitoring
• Close circuit video (CCTV)
• Card and keypad access
• Lighting
• Fire alarm system
• Elevators and escalators
The list is dynamic and new systems frequently gets added. There are
various management units that run behind these systems for cost optimiza-
tion and security purposes. Some such units are as follows:
Building commissioning is a quality-oriented process for achieving, veri-

fying, and documenting that the performance of facilities, systems, and
assemblies meets defined objectives and criteria [11].
Building Monitoring is the continuous process of checking the health of

every device of each system in the building. It is done through the
automated monitoring unit which continuously probes different devices
to check if they are working as intended.
Trending units are deployed in the building to find the patterns in the
devices’ service accesses. These patterns are typically used by the au-
tomation units to optimize the energy consumption. The patterns are
also used in the commissioning and maintenance of the building.
Archiving of various service accesses is performed to be used in the com-

missioning and maintenance of the building.
In future, wireless technology for communication would most certainly re-

place the existing wired communication technology owing to the cost effective
installation and maintenance, and new researches in the wireless technology.
Devices would become a part of the internet making BACS a part of Internet
of Things.
Chapter 8
Conclusions
This thesis presents various functional models for the access control in BACS.
The access control models are primarily based on the various use-cases for
access control in BACS. The presented models fulfill the requirements and
satisfy most of the use-cases. In other words, the models provide efficient,
context-aware, role based access control with no single point of failure in
BACS.
In the distributed model for access control, we have all the pre-shared
keys and the access control rules were stored in the devices themselves. Al-
though time efficient, this model has the limitation that a particular device
can possibly serve only a few other devices. In the centralized model for
the access control, we have a centralized trust point (TP) for establishing
authentication between two devices and centralized decision point (DP) for
the evaluating the policies stored in the central repository named retrieval
point (RP). Although highly scalable and manageable, this model has high
latency in providing the service. Moreover, it has various bottlenecks and
single points of failure.
Combining the distributed and centralized model, we proposed a hybrid
model in which we cache the session key between the pair of devices. We also
cache the encoded policies in the device. This enables us to intelligently store
the policies and session keys related to the important devices. Although, the
efficiency is the same as in the centralized model if there is a cache miss, the
efficiency is as good as distributed model for most of the subsequent similar
requests. We have also incorporated context awareness in the hybrid model
by first partially evaluating the context parameters at the DP, then send-
ing the policy to the device containing equations to evaluate the remaining
context parameters which local to the device.
To facilitate storing, communication, and total and partial evaluation
of the policies we have defined a JSON based policy language. The policy
66
CHAPTER 8. CONCLUSIONS 67
language also takes care of the role based grouping of the user devices. The
policy language is designed in such a way that communication protocol (e.g.
pub-sub or explicit communication), caching priority and scope are specified
for each context variable. A general boolean formula for the evaluation of
each context variable can also be specified in the policy language. To evaluate
the policy corresponding to a service request from a user device, firstly all
the roles of the user device are extracted. Then each role is checked one by
one to see if the user device is allowed the requested service. In case a role is
found, all the context variable with global scope are evaluated and the one
with the local scope are left for the device to evaluate. The role is encoded
and send to the device. In case no role is found, the user request is denied.
We have also proposed an encoding format for the policies. This not
only reduces the memory footprint of the policies but also facilitates efficient
evaluation of the policies. The encoding of the policies also saves significant
bandwidth during the transfer of the policies from the DP to the device.
Therefore, policies inside the devices are stored in the encoded format. The
encoding is done in the compressed TLV format. Appropriate translation
algorithms are devised from JSON to TLV format and vice versa. The design
for access control is not only limited for the application in BACS but also to
general embedded systems.
As a proof of concept, we have implemented a prototype of the centralized
and the hybrid design including all the functionality proposed in the design.
We have implemented the evaluation algorithm for the policies which also
include their partial evaluation at the central decision point. The encoding
and decoding algorithms of the policies were also implemented. We then
compared the memory footprint and the latency of both the designs and the
results were as expected. The hybrid design is more efficient in serving the
devices with little more memory footprint (used for caching) compared to the
centralized design. Excluding the cache memory and the memory required
for various data-structures, the access control engine requires approximately
5 KB of memory. Needless to mention, the hybrid prototype provides a
practical solution for efficient and scalable access control in constrained en-
vironments.
Bibliography
[1] ANSI. Standards. American National Standards Institute.
[2] ASHRAE. Fundamentals. American Society of Heating, Refrigerating

and Air Conditioning Engineers, Atlanta (2001).
[3] BACnet. A data communication protocol for building and automation

control networks. http://www.bacnet.org/.
[4] Blom, R. An optimal class of symmetric key generation systems. In

Advances in Cryptology (1985), Springer, pp. 335–338.
[5] Blundo, C., Mattos, L., and Stinson, D. Trade-offs between com-
munication and storage in unconditionally secure schemes for broadcast
encryption and interactive key distribution. In Advances in Cryptology-
CRYPTO’96 (1996), Springer, pp. 387–400.
[6] Chen, Y.-c., and Yeh, L.-y. An Efficient Authentication and Access
Control Scheme Using Smart Cards. Review Literature And Arts Of The
Americas (2005).
[7] Du, W., Deng, J., Han, Y., Varshney, P., Katz, J., and
Khalili, A. A pairwise key predistribution scheme for wireless sen-
sor networks. ACM Transactions on Information and System Security
(TISSEC) 8, 2 (2005), 228–258.
[8] Dunkels, A., Gronvall, B., and Voigt, T. Contiki-a lightweight

and flexible operating system for tiny networked sensors. In Local Com-
puter Networks, 2004. 29th Annual IEEE International Conference on
(2004), IEEE, pp. 455–462.
[9] Ferraiolo, D., Sandhu, R., Gavrila, S., Kuhn, D., and Chan-
dramouli, R. Proposed nist standard for role-based access control.
ACM Transactions on Information and System Security (TISSEC) 4, 3
(2001), 224–274.
68
BIBLIOGRAPHY 69
[10] Grummt, E., and Muller, M. Fine-grained access control for epc
information services. In Proceedings of the 1st international conference
on The internet of things (2008), Springer-Verlag, pp. 35–49.
[11] Handbook, A. Hvac applications. ASHRAE Handbook, Fundamentals

(2003).
[12] Hardjono, T., and Dondeti, L. Multicast and group security.

Artech House Publishers, 2003.
[13] Hein, P. Dali-a digital addressable lighting interface for lighting elec-
tronics. In Industry Applications Conference, 2001. Thirty-Sixth IAS
Annual Meeting. Conference Record of the 2001 IEEE (2001), vol. 2,
IEEE, pp. 901–905.
[14] i3con. Industrialized, integrated, inteligent construction.

http://www.i3con.org/.
[15] ISO. Standards. International Organization for Standardization.
[16] Kastner, W., Neugschwandtner, G., Soucek, S., and New-

mann, H. Communication systems for building automation and control.
Proceedings of the IEEE 93, 6 (2005), 1178–1203.
[17] Kinney, P., et al. Zigbee technology: Wireless control that simply
works. In Communications design conference (2003), vol. 2.
[18] Kushalnagar, N., Montenegro, G., and Schumacher, C.

IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals. RFC 4919 (In-
formational), Aug. 2007.
[19] Liu, D., and Ning, P. Multilevel µtesla: Broadcast authentication

for distributed sensor networks. ACM Transactions on Embedded Com-
puting Systems (TECS) 3, 4 (2004), 800–836.
[20] Lorch, M., Proctor, S., Lepro, R., Kafura, D., and Shah, S.
First experiences using xacml for access control in distributed systems.
In Proceedings of the 2003 ACM workshop on XML security (2003),
ACM, pp. 25–37.
[21] MC1322x. Mc13224 hardware guide.

http://mc1322x.devl.org/hardware.html.
BIBLIOGRAPHY 70
[22] Megiddo, N., and Modha, D. Arc: A self-tuning, low overhead

replacement cache. In Proceedings of the 2nd USENIX Conference on
File and Storage Technologies (2003), pp. 115–130.
[23] Modadugu, N., and Rescorla, E. The design and implementation
of datagram tls. In Proceedings of ISOC NDSS (2004).
[24] Montenegro, G., Kushalnagar, N., Hui, J., and Culler, D.
Transmission of IPv6 Packets over IEEE 802.15.4 Networks. RFC 4944
(Proposed Standard), Sept. 2007. Updated by RFC 6282.
[25] Moses, T. extensible access control markup language tc v2. 0 (xacml).
Organization for the Advancement of Structured Information Standards
(OASIS)(February 2005) (2005).
[26] Myers, M., Ankney, R., Malpani, A., Galperin, S., and
Adams, C. X. 509 internet public key infrastructure online certificate
status protocol-ocsp. Tech. rep., RFC 2560, 1999.
[27] Neuman, B., and Ts’o, T. Kerberos: An authentication service for
computer networks. Communications Magazine, IEEE 32, 9 (1994),
33–38.
[28] Novak, T., Treytl, A., and Palensky, P. Common approach
to functional safety and system security in building automation and
control systems. In Emerging Technologies and Factory Automation,
2007. ETFA. IEEE Conference on (2007), IEEE, pp. 1141–1148.
[29] Perrig, A., Canetti, R., Tygar, J., and Song, D. The tesla
broadcast authentication protocol.
[30] Philips. Philips dynalite control system.
http://www.lighting.philips.com/main/subsites/dynalite/.
[31] Ramkumar, M., and Menon, N. Pre-loaded key based multicast and
broadcast authentication in mobile ad-hoc networks. In Global Telecom-
munications Conference, 2003. GLOBECOM’03. IEEE (2003), vol. 3,
IEEE, pp. 1405–1409.
[32] Ratner, B. Rs-485 multipoint power line modem, Nov. 4 1997. US
Patent 5,684,826.
[33] Rubinstein, F., Treado, S., and Pettler, P. Standardizing com-
munication between lighting control devices. In IEEE Industry Appli-
cations Society Annual Meeting (2003), pp. 805–811.
BIBLIOGRAPHY 71
[34] Ruj, S., Nayak, A., and Stojmenovic, I. Key predistribution

in wireless sensor networks when sensors are within communication
range. Theoretical Aspects of Distributed Computing in Sensor Networks
(2011), 787–832.
[35] Shelby, Z., Hartke, K., Bormann, C., and Frank, B. Con-
strained application protocol (coap). An online version is available
at http://www. ietf. org/id/draft-ietf-core-coap-01. txt (08.07. 2010)
(2010).
[36] Snoonian, D. Smart buildings. Spectrum, IEEE 40, 8 (2003), 18–23.
[37] Wang, J., Sinnarajah, R., Chen, T., Wei, Y., and Tiedemann,
E. Broadcast and multicast services in cdma2000. Communications
Magazine, IEEE 42, 2 (2004), 76–82.
[38] Weber, R. Internet of things-new security and privacy challenges.

Computer Law & Security Review 26, 1 (2010), 23–30.
[39] Woo, T., and Lam, S. Authentication for distributed systems. Com-
puter 25, 1 (1992), 39–52.
[40] Zaitsev, S. A. Jsmn: Json parser in c.

http://zserge.bitbucket.org/jsmn.html, March 2011.
[41] Zhi, L., Jing, W., Xiao-su, C., and Lian-xing, J. Research on
policy-based access control model. In Networks Security, Wireless Com-
munications and Trusted Computing, 2009. NSWCTC’09. International
Conference on (2009), vol. 2, IEEE, pp. 164–167.
Appendix A
JSON protoype
1 {
2 "target":"light1",
3 "admin" : [{
4 "action" : "on",
5 "condition" : [{
6 "attribute":{
7 "id":"time",
8 "communication":"expcomm",
10 "scope":"global",
11 "eval":{
13 "value":"12"
14 }
15 },
16 "attribute":{
17 "id":"people presence",
19 "scope":"local",
20 "eval":{
21 "function": "eq",
22 "value":"true"
23 }
24 },
25 "attribute":{
26 "id":"natural illumination",
72
APPENDIX A. JSON PROTOYPE 73
28 "scope":"local",
29 "eval":{
31 "value":"1000"
32 }
33 }
34 }],
35 },
36 {
37 "action" : "off",
38 "condition" : [{
39 "attribute":{
40 "id":"time",
43 "scope":"local",
44 "eval":{
45 "function": "gt",
46 "value":"13"
47 }
48 }
49 }],
50 }],
51 "user" : [{
52 "action" : "on",
53 "condition" : [{
54 "attribute":{
55 "id":"time",
58 "scope":"local",
59 "eval":{
60 "function":"OR",
61 "eval":{
62 "function":"AND",
63 "eval":{
64 "function":"lt",
65 "value":"20"
66 },
67 "eval":{
68 "function":"gt",
APPENDIX A. JSON PROTOYPE 74
69 "value":"16"
70 }
71 }
72 "eval":{
73 "function":"eq",
74 "value":"3"
75 }
76 }
77 }
78 }],
79 },
80 {
81 "action" : "off",
82 "condition" : [{
83 "attribute":{
84 "id":"time",
87 "scope":"local",
88 "eval":{
89 "function": "gt",
90 "value":"13"
91 }
92 }
93 }],
94 }]
95 }
Listing A.2: JSON polocies

Access Control Designs for Building Automation Systems

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Access Control Designs for Building Automation Systems

Hochgeladen von

Copyright:

Verfügbare Formate

Aalto University

Access Control in Building

Supervisor: Professor Tuomas Auora

I am deeply grateful to my supervisor Professor Tuomas Aura of Aalto Uni-

Espoo, September 10, 2012

AES Advanced Encryption Standard

Abbreviations and Acronyms 4

3 Use cases and requirements 22

4 Design of access control system for BACS 26

5 Implementation and system prototype 44

Building automation and control systems (BACS) provide automatic control

control system non-trivial requiring new solutions in this area.

1.1 Problem domain and context

1.2 Structure of the Thesis

• Chapter 2 provides the relevant background information related to the

• In Chapter 3, we contemplate over possible use cases for access control

• In Chapter 4, we propose various designs by cumulatively satisfying

• Chapter 5 contains the details regarding two prototype implementa-

• Chapter 6 evaluates the prototype implementations based on memory

• In Chapter 7, we discuss some topics which are not directly related to

• The achievements of the thesis are summarized in the Chapter 8. The

2.1 Building automation and control systems

2.1.1 Communication protocols in BACS

Figure 2.1: Typical network architecture for BACnet [3]

Although the protocol seems general, there are operational character-

DALI: DALI (Digital Addressable Lighting Interface) [13] is a all-in-one

DyNet: DyNet [30] is another highly specific communication protocols used

Figure 2.2: Network Stack for ZigBee [17]

(wireless) standard by adding network and security layers, and an ap-

6LoWPAN/CoAP: 6LoWPAN (IPv6 over Low power Wireless Personal

been proposed in [24] to allow the transmission of IPv6 datagrams over

2.1.2 Communication frameworks and functional ar-

Figure 2.3: Position of BS (Building Services) architecture [14]

2. A communication framework for IBECS [33] is shown in the figure 2.5.

3. Another example of functional architecture and topology as described

Figure 2.4: Detailed structure of BS [14]

2.2 Access Control

Figure 2.5: IBECS communication framework [33]

1. Every object in the system has a subject as its owner.

Mandatory access control Mandatory access control refers to allowing

Figure 2.6: Network framework [16]

centrally and enforced to the whole system thereafter. Mandatory ac-

1. Rule-based (or label-based) access control: A Mandatory Access

lattice model is a mathematical structure that defines greatest

2.2.1 XACML: eXtensible Access Control Markup Lan-

Figure 2.7: XACML architecture

The detailed functional architecture of XACML is presented in the figure

2.2.2 Kerberos: Centralized authentication system

• Initial authentication of User (U) on Kerberos Authentication Service

• Ticket request to the Ticket Granting Service (TGS):

3. U −→ T GS : S, T GT, AuthenticatorU −T GS , N2 , AddrU

• Authentication to Service (S):

AuthenticatorU −T GS = EKU −T GS (U, Time Stamp1 )

AS KDC TGS AS KDC TGS

Figure 2.8: Multi-domain Kerberos architecture

The authorization framework XACML together with the authentication

Use cases and requirements

We investigate current security requirements in the field of BACS based on

3.1 Use cases

1. Typical communication between two devices: In this scenario, a window-

Office 1 Office 2 Single Floor

Domain Monitor/ Decision Point/

OTHER SIMILAR FLOORS