EZ- Access
Automation Systems
Capstone Design - Wireless Communications
Advisor: Dr. Christopher Rose
May 2nd, 2012
Team Members
Siddharth Paradkar
Kush Patel
Michael Montemarano
Neipaul Angad
Page 1
Table of Contents
1) Introduction…………………………………………………………….………3
2) Motivation……………………………………………………………….………3
3) Theoretical Considerations……………………………………….……….4
4) System Architecture………………………………………………….……..12
-
Initial Design…………………………………………………………………..………..12
New System Architecture…………………………………………………………....13
Network Architecture…………………………………………………………………14
Website…………………………………………………………………………………….16
Databases………………………………………………………………………...………18
Management……………………………………………………………………...……..19
5) Security…………………………………………………………………….……21
6) Cost Analysis………………………………………………………………….25
7) Conclusion………………………………………………………………….…26
-
Usability………………………………………………………………………………..........26
Security…………………………………………………………………………………………26
Scalability…………………………………………………………………………………..…26
Cost-Effective………………………………………………………………………………...27
8) References……………………………………………………………………...28
Page 2
Introduction
The essence of this project is to design an enterprise-oriented automation system.
Current Home Automation Systems provide users the ability to control devices remotely
however; they are not robust and are prone to security risks. This project provides a unique
solution where users can remotely control and monitor devices either via a Personal Computer
(PC) or a Smartphone. It addresses security issues by authorizing users via a University LDAP
Authentication system. This way, this automation system will operate in a more secured
fashion. This additional convenience will not only save time and effort, but also give users
peace of mind.
Motivation
Initially, this project aimed at designing an automation system which would, on a
command sent from a smartphone via Bluetooth, change its state. This however, is not scalable
and limits the functionality of the device outside a certain range. To account for this issue, a
more distinctive system was required. With the recent advancement in IP Technology, remote
communication between hosts has become possible. Allowing remote connectivity between
users and their devices would not only eliminate the issue of limited functionality but also
provide a centralized platform to monitor and control these devices.
Mobile technology, such as smartphones have become an integral part of our lives.
Unlike the existing automation systems, this project provides the enhancement of controlling
devices via a mobile website. This mobile website will make the content easy to access and
interactive on their smartphones, hereby improving the overall user-experience.
Lastly, and most importantly, security is a key feature of this project. Just so that our
system is built against the various existing encryption methods out there, a more secure
authentication scheme need to be integrated with the system. This project uses the Lightweight
Directory Access Protocol (LDAP) to authenticate its users prior to granting access to EZ-Access
services. LDAP is an industry standard for accessing directory services over a network.
Due to the complexity, one can face several challenges in developing a robust
Automation System. Thus, the following aspects will be considered in the design process.
-
Usability
Security
Accessibility/Controllability
Cost-Effective
Scalability
Page 3
Theoretical Considerations
Several protocols, electronic components and theories have been used to design this
project. A short theoretical description for some important concepts is provided below for the
reader.
Wireless Sensor Networks
Wireless Sensor Networks, has been and still is an emerging field in Communications,
since their deployment. In the past, their scope was only limited to military and industrial
applications, but due to its high potential, it has also expanded to Health Care and Home
Automation [1].
Sensor Node
Gateway Node
Fig 1: A Wireless Sensor Network
A wireless sensor network is a collection of nodes organized into a cooperative network
[2]. Within this network are sensor nodes or radios that are connected to and controlled by a
gateway node, as illustrated in Fig. 1. This gateway node commands the rest of nodes to
perform certain functions. The sensor nodes are established on a mini micro-controller that
interface with an electronic device. These sensor nodes communicate wirelessly with the
gateway node and vice versa.
ZigBee/802.15.4 is a famous standard that is used with Wireless sensor networks.
Bluetooth
Bluetooth is a technology standard used for wireless communications between nodes.
In today’s market, Bluetooth is widely used in mobile devices, digital cameras etc. Exchange of
data over short distances, because the frequency over which it operates on has a shorter range.
It operates over the unlicensed ISM 2.4 Ghz band. It has a range of about 50 meters (can be
extended to 100 meters if more power is transmitted).
Page 4
BT
Host Controller
Client 1
BT
BT
Client 2
Piconet
Figure 1: Bluetooth Communication between Host and Client [3]
The communication channel over which Bluetooth devices “talk” is called a piconet. The
Bluetooth device that initiates the connection is called a master device and the end devices are
the slaves. Bluetooth uses frequency hopping modulation scheme to send data.
Frequency Hop
Individual Channels
Figure 2: Frequency Hopping Spread Spectrum [7]
In frequency hopping, the carrier is switched randomly among many channels to reject
unauthorized interception or jamming of information, as shown in Fig. 2. For Bluetooth, these
Page 5
available channels are over the range of 2.400 GHz- 2.483.5 GHz. This frequency hopping
scheme eliminates degradation of data since 2.4 is an unlicensed band and is shared used for
various other protocols.
For transmission, master will first attempt to locate a slave (Bluetooth device) in its
piconet by sending a special inquiry packet. Upon confirmation, it determines a hopping
sequence that will be used to transmit data. This sequence is conveyed to the slave during
initialization. The slave synchronizes with the master accordingly. Once this is complete, the
piconet is established and data can be transferred.
Bluetooth uses a minimal level of security at the link layer which supports
authentication and encryption [4]. The authentication and encryption process is shared
between 2 devices using a 4 digit passcode. When devices communicate with each other for the
first time, both devices need to be paired with a security key. This key is only known to the
master and the slave. Other devices in the piconet do not have any knowledge of this security
key. Once devices are paired, information can be relayed to the other device respectively.
In summary, Bluetooth provides a secure protocol for transmission of data.
ZigBee
ZigBee protocol is a standard used with wireless sensor networks. If the ZigBee protocol
is being implemented, each of the sensor nodes can be called a ZigBee device. There are three
kinds of ZigBee devices namely ZigBee Coordinator (ZC), ZigBee Router (ZR) and ZigBee End
Device (ZED). There is always one ZigBee Coordinator in a network. This node contains
information about the network and the slave nodes residing in its network. ZigBee Routers are
nodes which can relay data to other nodes. This however, can be done on command from the
ZC. Lastly, ZigBee End Device is a slave node and it can only “talk” to the ZC or ZR. Unlike ZR, it
cannot relay information to other nodes.
ZigBee protocol, just like Bluetooth, operates on the unlicensed 2.4 GHz band. The
modulation scheme however, is different. ZigBee uses the Direct Sequence Spread Spectrum
(DSSS) scheme to send data. DSSS is explained below.
Figure 3: Direct Sequence Spread Spectrum [7]
Page 6
Figure 3a-b: Direct Sequence Spread Spectrum [7]
The transmitter side spread the data across a broad range of frequencies using a
mathematical key as seen in Fig. 3. This algorithm for the key is known to all the nodes in the
network. Before sending a data, the sender encrypts the data with a key. When the sender is
ready to send data to a particular node, it assigns a key to the slave node. This key is the same
key the sender will use to encrypt the data.
DSSS transmits with a low density power to make detection harder. These keys are also
considered pseudo-noise sequences. This is because each key acts like noise to nodes other
than the intended node. Upon receiving the packet, the intended node will be correctly able to
decode the signal since it has the correct sequence, shown in Fig. 3b. The rest of the nodes
would not be able to decode the data and this transmission will act as narrowband interference
and the receiver will ignore the signal, shown in Fig. 3a. Prior to transmission, the ZC scans the
list of available channels and selects the best channel with least interference.
In wireless sensor networks, ZigBee nodes can go to sleep when there is no activity. This
saves battery power since it is not processing any information. When information is sent to the
node, it wakes up, performs the function, and goes back to sleep. The transition from sleep
mode to active mode takes approximately 15 msec. or less [8].
As far as the network topology for ZigBee is concerned, the protocol supports 3 different
structures namely Star, Cluster and Mesh. Figures of each kind are shown below.
Star
Mesh
Cluster
Figure 4: Network Topologies
Page 7
This particular project is implemented on a smaller scale for now, hence a Star topology
will be considered. However, this project can be expanded to a Mesh network by adding ZR
nodes to relay messages to different nodes.
From a security standpoint, ZigBee’s DSSS scheme is unique and its use of private keys
to transmit information is secure in itself. However, firmware can be loaded onto each ZigBee
node to implement additional security.
Bluetooth vs. ZigBee
Having described the ZigBee and the Bluetooth protocols, their comparison is
important. This will help an engineer choose which protocol to implement for a particular subsystem. Table displayed below shows comparisons between the 2 protocols.
Characteristic
Zigbee
Bluetooth
Max Range (m)
Data Rate (Kbps)
1) Adding a New Node
2) Waking up a Slave Node
Power Profile
Security
Complexity
No. of Devices per network
Reliability
400
250
30ms
15ms
Years
128 bit AES (App layer)
Simple
65000
High
100
1000
20s
3s
Days
64 Bit (Link Layer)
Complex
8
Medium
Table 1: Bluetooth vs. ZigBee Protocol
The Bluetooth has its disadvantages too. Its range is only about 100m; i.e. the MC
cannot be accessed remotely. Bluetooth, despite its link layer encryption, is not secure. The 4
digit-code can be easily-cracked hereby sacrificing the security of the house. Additionally, when
Bluetooth adaptors are configured to have ranges of about 100m, a lot of power will be
required. If an end-device is designed to run on a battery, it can lead to device draining all the
power instantaneously. The sharing of the primary controller between multiple devices incurs
access delay as well [5]. Additionally, the transition from a sleeping mode to an active mode for
a Bluetooth device is 3 seconds [8], much slower than ZigBee. A system that uses Bluetooth
technology is therefore not scalable.
One of the drawbacks that the ZigBee possesses is its data rate. Bluetooth is 4 times as
fast. However, our system does not require audio or video streaming. ZigBee requires typically
Page 8
few tens of bytes to transmit its sensor reading. Therefore, the data rate need not be
considered for our system.
In conclusion, the ZigBee protocol proves to be beneficial than Bluetooth for this
project. Hence, ZigBee protocol will be implemented in the design aspect.
Lightweight Directory Access Protocol (LDAP)
Lightweight Directory Access Protocol is a promising technology that has been widely
used due to its flexibility with web-based applications. LDAP is considered as a directory-access
method. This directory access method is a service where the web-application searches a
database repository to acquire any sort of information. LDAP accommodates the need of high
level of security, single sign-on and centralized user management which offers services of
security and integrated directory especially with capability of storing and managing user
information in a directory [11].
Rutgers University uses LDAP authentication method to authorize users prior to granting
them access to the various online services. LDAP is a client/server model which uses the famous
TCP/IP protocol to access and manage information from a LDAP directory. As mentioned above,
LDAP server, in this case, will contain information regarding student, what they have access to,
their RUID etc. Prior to accessing them, the server needs to verify that the user is valid. The user
will first send a query, usually it will be done through the web-application. The credentials
entered by user (username and password) will be transmitted over TCP/IP destined for the
server. The server will than look for identifier on a LDAP Directory Information Tree (DIT),
which is also stored on the server. If the value is true, user will be granted access. If not, an
error will be sent. Fig. 5 below displays a working mechanism of the LDAP Protocol, on a smallscale.
Hierarchy of Objects
TCP/IP
Network
Figure 5: Working Mechanism of LDAP [11]
One of biggest advantages of LDAP is centralized storage of user-information and their
management. This makes LDAP scalable and appealing to industries and universities. When
LDAP is implemented in a university wide scale, there are many more components that will be
Page 9
part of the network. Fig. 6 below shows a framework of the LDAP protocol to access data stored
in LDAP databases. Comparing to Fig.5, Fig 6 is large scale and centralized. Authentication is
more secure since there SASL protocol (Simple Authentication and Security Layer) is used for
authentication binding. This sort of binding will establish a security layer over which the
authentication will conduct.
Figure 6: LDAP Framework [11]
Quick Response (QR) Codes
QR codes are two-dimensional bar codes which consists of black modules (black
squares) arranged in a square pattern. The traditional bar codes are one dimensional and do
not possess the capability to hold longer numeric strings or characters. QR codes, on the other
hand, can contain numbers in decimal or binary, alphanumeric characters etc. It is the idea of
digitally connecting consumers of your paper-based concept to the internet [9]. It gives users
the ability to scan these codes, using a smartphone and decode information, which can contain
websites, name cards, phone numbers, email addresses etc.
For example, a QR code that will be used for this project is shown in Fig. 7. Embedded
within this code contains a link to mobile website of our project. The user will scan this code
using a commercial QR code reader. QR readers are available freely in android and apple
application markets. When scanned, the reader will direct user to the mobile website, without
having the user to remember the website address. It’s as easy as that!
Page
10
Figure 7: A QR Code
Figure 8: QR Code Explained [9]
Here is some brief information on QR Codes. Fig. 8 above provides a guide on
understanding QR codes. Of all these fields, Data and Version information fields are of
importance. Detailed information on individual fields can be obtained in [10]. QR codes range
from version 1 through 40 where each version corresponds to different modules. A module can
be thought of as an n X n matrix. Information is stored in the data field, horizontally and
vertically. Message is placed from right to left in a zigzag pattern. An additional feature QR
codes uses is an error correction scheme. They are namely L, M, Q, H, S with increasing order of
data recovery. This is based of Reed-Solomon Algorithm. QR Code represents its error
correction rate as a ratio of the total codewords [10]. Level M correction scheme is most often
used. Q and H are used for dirty environments since dust accumulating on the code can make
decoding a bit harder. For this project, level L will be used.
There are several QR code generators that are available on the internet.
http://qrcode.kaywa.com/ website will be used to generate QR Codes for this project.
Page
11
System Architecture
Initial Design
The initial design of the EZ-access system was focused to a small user base to communicate to
small devices over the Bluetooth protocol. A system diagram can be found below:
Main Controller
Blue-tooth
enabled smart
phone
BBlu
luee tt
ooothh
LLiinnkk
Blue Tooth Adapter
Arduino Microcontroller #1
Power Switch controller
Li
ot
h
to
Bl
ue
Blue Tooth Adapter
Key-Less door opener
Blue Tooth Adapter
Blue tooth Link
nk
Blue Tooth Adapter
Blue Tooth Adapter
Arduino Microcontroller
Arduino Microcontroller
Power Switch
Servo Motor/ Door opener device
Figure 8: Initial System Model
The design offers many similarities to the current implementation. The main controller
and devices all are Arduino based devices. In this system, all the devices communicated over
Bluetooth. In real world trials, Bluetooth pairing and communication proved unreliable. The
overall system also does not support a large infrastructure. The main controller would be
responsible for talking directly to the user and providing a secure authentication scheme. The
Arduino could not support these processor intensive feature sets, so the design was modified to
add a server to process user requests. However, as pointed out in the Theoretical
Considerations sections, ZigBee offers a better solution for this project. ZigBee proves to be
more advantageous than Bluetooth in terms of functionality, power and is easy to integrate
into a new system.
Page
12
New System Model
A Simplified complete system architecture is shown below.
Figure 9: New System Architecture
A simple walkthrough of the system is as follows. The users access the public available
website. The website is hosted on the Rutgers network to provide access to everyone on the
network. When a user logs in, their credentials are sent to the Rutgers LDAP server for
authentication. This keeps our project from having to manage and secure password storage.
Once the user is authenticated, the LDAP system provides information about the user, which
the system uses to determine roles. The role information is stored in the SQL database. When a
user selects a device to control, the website checks the database to ensure the user has the
privileges to manipulate it. Then, the command is sent over the Rutgers network as an
encrypted packet. The packet is directed at the main controller that is in range of the device the
Page
13
user wants to control. The main controller then parses the incoming packet and performs the
requisite action. A confirmation packet is then sent back to the server and the website updates
to reflect this.
Network architecture
The key to the flexibility of our system is using the underlying Rutgers infrastructure to
provide cheap, fault tolerant communications. The server is connected to the main controllers
using standard TCP/IP. Each main controller has its own IP address inside the Rutgers network.
When a new main controller is activated or reappears on the network, it sends a request to the
server. The server checks to see if the main controller in the database and makes modifications
if necessary. The server and main controller are preprogrammed with a protocol that ensures
communications between the devices are consistent. The packet structure can be found below.
16 Bytes
1111
Main Controller ID
16 Bytes
Device MAC
16 Bytes
16 Bytes
Command
Flag
0000
Figure 10: Packet Structure
The entire packet is also encrypted (blue wrapper) in order to prevent eavesdropping.
Main Controller ID: is responsible for checking that the ID of the packet matches its own ID. If
this is not true, the main controller can replay back to the server to inform the server of the
mistake.
Device MAC: is the mac address of the radio of the device the user wants to connect to. If this
device does not exist according to the main controller, it can reply back with an error message.
Command: is what the device should perform. This information is based on what type of
device you are trying to access. For example, a light would have an on command, but not an
unlock command. Since the Arduino is responsible for simply sending the command to the right
device, it does not necessarily need to know how to device performs its operation. It can relay
the information through the transmission medium and wait for a reply. This reduces the
complexity of the operation by reducing the number of nodes that need to preform low level
analysis of the command. More advanced devices, such as an RFID scanner, can simply request
the command and flag information. The main controller does not need to be aware of the inner
workings of each device.
Page
14
Flag is a multipurpose field with a wide range of applications. It is interpreted first since it can
indicate if an error has occurred, or if the packet has any special instructions. This field can be
expanded to provide more error checking and redundancy features in the future.
1111 and 0000 are checks on the integrity of the packet. If these are sent incorrectly, the
packet is not considered a valid packet in the system. This ensures that packets that contain
flipped bits or other data is minimized. The TCP protocol also provides a checksum in order to
maintain data integrity. With multiple checks on data integrity, preambles, and flags to indicate
errors, our IP based communications are very reliable.
Main controller
The main controller is designed to be the intermediary between the wireless devices
and the server communications. As the user enters a command on the website, the information
is sent over TCP/IP to the main controller associated with the device. The controller takes any
incoming command and determines if the command can be done. It checks if the device
requested is on its network. If the controller does not have a connection to the MAC requested
by the server, it can send an error back. The website can take the error back to the user and
provide a user-friendly page to indicate what happened.
The main controller also shifts communications from standard internet packets to
ZigBee communication. This ensures that wireless communications are used at the shortest
distance possible to minimize errors. Future advancements to the product could be to include
multiple radios such as Bluetooth and WIFI. The extra processing power of the Arduino mega
and the Ethernet shield provides extra room for processing and storage capabilities (SD card
storage on controller) to enable these features.
Devices
The devices were designed with a simple base system. The devices at each base
contained a ZigBee radio and an Arduino mini. This ensured easy prototyping and affordability
in a compact package. The base structure is also flexible enough to power multiple types of
devices.
The devices that were constructed for the demo were designed to be cheap and
effectively demonstrate the system’s capabilities. The first device create was a simple LED
notification. When the main controller received an incoming packet, it would simply send the
requisite signal to the corresponding ZigBee radio. The Arduino interpreted the results and
changed the state of the light. Similarly, a servo motor was connected to emulate a door locking
mechanism. Finally, a Display was shown on the last demo part. This demonstrated that the
Page
15
main controller can successfully send information composed of more than a simple on and off
state.
Website
The original concept of the website consisted of a blank site with a java applet. This type
of website took our previous knowledge from programming courses and provided a real world
application. The java applet was appealing because of its cross platform capabilities. This
meant that our program could be written once for any different browser types and user
platforms. Java virtual machines, the technology that runs applets, are supported on Windows,
Mac and most flavors of Linux. This implementation fell apart very quickly, however, since
mobile support of a java virtual machine is not completely ubiquitous. Our initial testing found
that Android phones do not have a java virtual machine that is stock. This would essentially
cripple the final design, since Android currently holds a majority market share in the smart
phone market .Android also has a significant hold in the tablet market. Since our device is
aimed at the mobile market, this essentially killed the idea of using a java applet as the
implementation of our webpage.
Moving away from the java implementation, we decided to focus on using PHP and
HTML in order to create a website that is compatible with multiple browsers. Generating a
mobile website drastically focused our limited programming resources to create a final product
that was compatible on multiple platforms. To create the same amount of market penetration
with an application based approach, one would have to generate separate code for OSX,
windows, IOS, Android, and possibly Windows phone. The time even to just focus on the core
user groups (IOS, android and windows) became too much and slowed down progress. With a
mobile website, any changes we made to site reflected across all platforms. Multiple
applications, on the other hand, would require a different update for each.
While the website was put in favor of multiple applications, the website itself was
forked into separate subdivisions: Desktop and Mobile. The desktop website is shown below:
Page
16
Figure 11: Desktop version of the Website
The site is optimized for large screens that are over 13” and standard resolutions
(1366x768 and up). This site offers more options up front to the user to take advantage of the
larger screen size. We tested this website on a tablet (7” ACER Iconia Tab) and the mobile
website was preferred. This indicates that although this site works well for desktops, Tablet
user should be redirected to the mobile website.
The corresponding welcome screen for the mobile website is shown below:
Figure 12: Mobile version of the Website
Page
17
The mobile website is designed for touch screens to be able to perform simple
commands quickly. The buttons are very large in order to provide the user with enough room to
be off by a significant margin. This improves the site’s usability and user satisfaction. The QR
code implementation forces the user to this website for this reason. Even if the user is using a
laptop to scan the code, the mobile website will still offer the base functionality of activating
the device that they want to configure. Another reason for this decision is that the majority of
the users that will scan QR codes will be mobile users. It is very unwieldy to attempt to hold a
laptop to a QR code suspended on a door. To facilitate laptop users, the ID of the device is
printed below. This ensures that the user can simply go to the standard website, log in securely,
and then enter the ID of the device they want to manipulate. The security of using a mobile
website is explained in detail in the security section of the report
Database
The core component of the EZ-access system is a fast and secure database that can
accept requests from multiple users. The backbone of our database is MSQL server 5.5 running
off a Windows XP platform. From the MySQL administrator software, we can add and remove
administrative accounts and precisely add and remove privileges for different administrators.
The website requires a connection to this database in order to look up and make edits to
entries. The website has no use for destroying tables or modifying its underlying structure.
Using the administrator privileges, we built an account that cannot delete or remove tables.
This ensures that even if someone were to successfully inject SQL code into our website, they
do not have access to the database to destroy the changes saved by others.
The server that we used in order to provide access from anywhere in the Rutgers
network was located in the Rutgers computing help desk in Hill center 013. This was done for
several reasons. First, the group member primarily responsible for the database had 24/7
access to the room. The room was also locked at night time for security reasons. Finally, the
server was running 24/7 in order to provide support at any time during the day. The server ran
Ubuntu version 11.10 with VirtualBox 4.1.12. VirtualBox ran an instance of Windows XP which
housed our database. This made backup easier and management was done via remote desktop
protocol (RDP). In order to ensure power failures did not permanently shut down the virtual
machine, the virtual machine was run at startup task.
Database Tables and their functions
The SQL database is sorted into five tables: deviceproperties, devices, ldapusers,
maincontroller, and userpriv. This separation allows the system to quickly lookup and update
information. A summary of the roles of each table can be found below:
Page
18
DeviceProperties: this table contains the detailed contents of each end device connected in
the EZ-access system. Unique identifiers, such as Mac address and device ID are stored here.
Devices: this table sorted the relation between the unique ID of a device and the groups that
are allowed to access that device. For example, a light with ID EE103 could be associated with
GUESTS and ECE students
LDAP Users stores the netID, name, email, and roles of a user that logs in successfully to the EZaccess system. The roles of a student can be one of the six primary roles in the university
(EDEN,RCI,PEGASUS,…) this is scraped from the email field when you login. Information in this
table is not modified, and stored from the Rutgers LDAP call.
For example. Montemar@eden.rutgers.edu is placed into the EDEN role.
Maincontroller: stores the ID of each maincontroller and TCP/IP information to communicate
with that host. This consists of an IP address and port.
UserPriv: stores the netID of each user and their Roles in the university to ensure we can
quickly lookup users in our database. Also, more specific roles of the user, such as supervisor
and department are placed here.
These tables are used at different times during the process. When the user logs in, the LDAP
users table is checked if they have logged in before. Once they login, the table has the
information about the user and their status at the university. Then, when a user selects a
device, the devices table is checked to see if it exists and crosschecks the accepted realms with
the user’s roles. So the device the user wants to access must have at least one matching role.
Once the user has sent a command, a packet is formed by looking up the Devices mac address
and information in the devices table. The command information and flag information is
combined with the IP and port data found in the maincontroller table.
Management
In order to make changes to the database, in MySQL administrator has to run command
line type of entries to make edits. This is too slow and arduous for day to day administrative
tasks and testing. In order to provide faster results with our testing, we connected a program
call phpmyadmin. This provides simple frontend modifications to the database in order to make
quick changes to our tables. In summary, the SQL application was used to perform backups and
add and remove admins. Phpmyadmin was used to add and remove tables and modify entries
Even if everything on the server is fault tolerant, accidents and hardware failure still
occur. If the data from our database is not backed up to a secure location, the contents of the
Page
19
database can be lost. In order to prevent data loss from occurring, we performed several
preventative measures.
VM clone
The most infrequent backup was the entire virtual machine. This preserved all OS functions and
the MYSQL administrator program. This information was stored on another offsite machine. If
the server were to be stolen or drastic hardware failure to occur, a simple reinstallation of
virtual box combine with the backup virtual machine will reduce downtime and ensure the
table structure is intact. Ideally, this backup operation would be done nightly to cement any
changes in a production environment.
Database export
The database can be exported from MYSQL administrator in order to dump the contents
of the tables. This requires much less space than cloning the virtual machine, and can be done a
more frequent basis. The VM backup size was roughly 9GB, compared to the database entries
comprising less than a megabyte of space. Wide scale deployment of the system would reduce
the overhead of the Virtual versus the database size.
Both backup procedures combined can be sued to provide extra security against
physical failure. If the server suffers a drastic failure, the backup virtual machine can be loaded
backup and an hourly refresh of the database can be performed. This means that even if
catastrophic events occur, the system can be restored in less than an hour and will suffer little
to no data loss. This analysis excludes any fault tolerance provided by the underlying system,
such as RAID and drive backups.
Other considerations
In the original implementation, Microsoft access was used to act as a database. This worked
well with using the java application since the two can be integrated very easily. After the
project forked over from the java applet to mobile website, an SQL database was implemented
due to its synergy with PHP. PHP has a documented method for accessing MySQL servers and
running simply queries. This documentation is readily available on the PHP website and error
checking for enter queries is native in PHP.
Page
20
Security Implementations
In order for a large-scale automation system to be productive and efficient it has be
secure, and all of the risks of using this product need to be taken into account by its users.
During the developmental stages of this project, we made security our foremost priority,
because we understood that security was quintessential if we were to entice potential users to
use the EZ-Access automation systems. In the following paragraphs, outline the security
measures that we have already implemented into our current version of the Ez-Access
automation system.
First, we have put into place the LDAP authentication protocol into all of our websites,
desktop and mobile. LDAP, which stands for Lightweight Directory Access Protocol, is an
application protocol for accessing and maintaining distributed directory information services
over the internet [11]. Since our project is currently, only for Rutgers use we have setup our
authentication using the Rutgers LDAP server. In order to gain access to this server a client must
authenticate with the server itself using the Rutgers provided username and password. To
access the LDAP service, which in our case is the EZ-Access website, the LDAP client first must
authenticate itself to the service. That is, it must tell the LDAP server who is going to be
accessing the data so that the server can decide what the client is allowed to see and do [12]. If
the user is a registered Rutgers personal, faculty or student, they are allowed to gain access to
the website. Using the Rutgers LDAP server has many advantages, but the most essential is
that it eliminates the need for us to create another database with users for the LDAP services to
cross-reference too. This is because the Rutgers LDAP server searches for users using the
Rutgers main database, which has the entire Rutgers personal listed. For extra security
measure, we have setup a system log, which records all of the users that log into our EZ-Access
system, and it keeps track of the devices that they controlled. This helps to keep track of users
logging in and out of our system, and this helps to identity the user if location was tampered
with. For instance, if someone was to open a door for a lab and some equipment was stolen.
Thru the EZ-Access system, it is possible to pinpoint who exactly the user was. The LDAP
authentication also makes it possible for Rutgers affiliates to use any of our devices, which acts
as another security barrier in itself. This helps to make Rutgers a more student and faculty
friendly zone, because being a part of Rutgers they will be able to go about campus without a
need of a special key.
Although the LDAP authentication system allows only Rutgers affiliates, it does not
prevent these affiliates from controlling devices that they have no use using. For instance, a
music major should not be able to gain access to a biomedical engineering lab, which holds
some very expensive equipment. In order to prevent this from occurring we have developed a
way to assign certain permissions to users. First, if the user is a faculty they are assigned
Page
21
supervisor privileges by looking at their email domain name. For example, when a faculty
member logs into our system, the LDAP authentication takes place, and we pass a query to the
server asking it to return some information about the user. This information includes the user’s
first name, last name, and email. This information is stored in our own database for later
reference. This email domain for a Rutgers faculty is usually @rci.rutgers.edu, this helps to
identify the user as a faculty. Students on the other hand have @eden.rutgers.edu, this
information is stored in our database. If the user is a supervisor they have permission to use all
of the devices, however if the user is a student the authentication is much more rigorous. All
of the students are initially assigned Guest permissions; this means that they will only be able
to control guest devices. In order for students to gain permission they can either contact the
Rutgers EZ-Access team, or contact a faculty member who has the ability to give students
permissions to use certain devices. This step makes it easier for professors to give a student
permission use a lab room, without handing the student a key. This prevents the music student
from opening the BME lab room, because he or she will not have permission to use that device.
By assigning users and devices with a list of permissions, we hope to make EZ-Access a
university wide system.
In order to make our project more scalable and manageable at the same time, we have
employed the use of multiple SQL databases. For the EZ-Access system, we have created a wide
range of databases, ranging from user permissions, device permission, device list, and list of
main controller IP addresses. These databases are located on a secure server; however, they
are still susceptible to cyber-attacks. This vulnerability in web application allows malicious
users to obtain unrestricted access to private and confidential information. An SQL injection is
an attack technique used to exploit websites that construct SQL statements from user supplied
input [13] . This essentially means that if the website has a log in page, where the users has to
enter in his or her information, and this page is referencing items from an SQL database. The
user can potentially just type a SQL query into the text field for the username or password field,
and then the user will be able to gain access to private information. For instance, if the user was
to enter “’ or ‘1’= ‘1” into the password field, then the SQL query becomes String sql = SELECT *
FROM login Where log_id=’XXX’ AND log_pwd = “or ‘1’= ‘1” *3+. This can potentially allow users
to gain access to our website and control devices, which they do not have permissions to do,
which can be devastating. This is only an example of what a malicious user can do, he or she
can also remove all entries from a database, which could potentially crumple the whole EzAccess system. In order to prevent this from taking place, the Ez-Access websites have been
coded to not to rely on the built in PHP magic quotes, which automatically escape any
characters such as signal and double quotes by prefacing them with backward slashes. Instead,
this feature has been turned off and all of the text fields on the website use the function
mysql_real_escape_string for all calls to the MySQL database. This function removes any
random quotations added to a user-inputted string and then properly sanitizes the string.
Page
22
Another security measure that has been implemented to virtually bulletproof the site is the use
of placeholders. This idea is to predefine a SQL query by using the ? characters where data will
appear. Then instead of calling a MySQL query directly, the predefined query is called, and data
is passed to it. This has the effect of ensuring that every item of data entered in inserted
directly into the database and cannot be interpreted as SQL queries. This in other words makes
SQL injection nearly impossible [4]. These two steps have been taken to insure not only the
security of the devices themselves, but also preserve the integrity of the EZ-Access interface.
The EZ-Access websites are the main front of our project, and since the sites have been
main extremely user friendly the need for session security is crucial. In order to pass
information from one page to another in PHP we have the use of session variables, and these
variables are stored on the server and pertain to the current user. However, when a user has
been authenticated and a session has been setup one cannot assume that the session variables
are trustworthy. The reason is that it is possible to use packet sniffing(sampling of data) to
discover session IDs passing across the network[13]. This especially becomes an issue if there is
information being passed in the URL’s of the site pages, such as username or passwords. The
easiest way to prevent this from becoming a big problem is to implement a Secure Socket Layer
(SSL) and run HTTPS instead of HTTP web pages. The problem with this solution is that the
Rutgers network signs its own webpages using a specified signature, but other places outside
Rutgers will not accept the Rutgers signature , which could result in our sites being rejected
anywhere outside the Rutgers network. To stop this from being a very issue we have utilized
the method of Forcing cookie-only sessions, which means that the users on our website have to
enable cookies for our site [14]. This prevents malicious users from getting any information
from packet sniffing because at the end of every session the cookies are destroyed and there is
nothing left to be sniffed.
To insure that the EZ-Access system is relatively secure there has to be some sort of
protection at a network level. As is shown in the system architecture section of the lab report
the EZ-Access automation system spans out over several different type of communication
protocols. First, is the connection between the server and the main controller, an Arudino mega
micro controller, is essentially done across the Rutgers network. However, if someone were to
connect a Hub to the same port where the main controller is connected they would be able to
see all of the packets coming and going between the server and the main controller. In order to
prevent something like this from happening all of the packets being communicated between
the server and the main controller are encrypted using Triple-DES. This means that without the
proper keys and the signatures no one, in a reasonable amount of time will be able to decode
the packets. One of the main problems with cyber security systems is key sharing, meaning how
is one party supposed to alert the other about the keys without giving away the keys. Currently,
we have hardcoded the keys into both the server and the main controller, however in the
Page
23
future we plan to create a method where both the server and the main controller will be able
to publish the keys relatively securely. The second link of main concern is the ZigBee link
between the main controller and the devices themselves. Someone must not be able to directly
send packets to a device without going through all of the other authentication systems. This is
why all of the packets sent on the link between the main controller and the devices are
encrypted using AES with 128 bits of payload information. The AES cipher is made more
effective with the more number of repetitions, and since this cipher is symmetric the same keys
are used for both encryption and decryption. This prevents anyone from sniffing out our ZigBee
packets and helps to make the link between the main controller and the devices more secure.
Page
24
Cost Analysis
No matter how many bells and whistles a product might have, it needs to be costeffective. The motivation is to make a low-cost, secure and a flexible system which is not only
affordable but also robust.
Table 2 below shows the initial cost for all the parts ordered throughout the term of the
project. It also includes cost for parts that were used for the initial system model. After
redefined our project approach, other parts were ordered to be used for a new system model.
Item
Quantity
Unit Cost ($)
Total Cost ($)
Arduino Board Mega
Arduino Board Uno
Arduino Ethernet Shield
XBee Radio
Arduino Pro Mini
FTDI Basic Breakout
Bluetooth SMIRF Adapter
Arduino Board Uno
Acrylic Sheet
Accessories
1
5
1
11
5
5
1
1
2
49.03
26.56
45.95
19
18.95
14.95
39.99
34.99
3.69
49.03
132.8
45.95
209
94.75
74.75
41.31
37.44
7.50
13
Grand total
705.03
Table 2: Proposed Parts List
Item
Main Controller
Quantity
1
Unit Cost ($) Total Cost ($)
113
121
Arduino Board Mega
Arduino Ethernet Shield
XBee 1mW
1
1
1
49
45
19
52
49
20
Sub-Devices
3
45
146
Arduino Board Uno
XBee 1mW
1
1
26
19
28
20
Grand Total
267
Table 3: Product Parts List
Page
25
With the amount of parts ordered, our system can support one Main Controller and 5
additional sub-devices. However our final product (that will be presented to ECE faculty)
consists of one main controller and 3 additional sub-devices.
Page
26
Conclusion
The objective of building an enterprise-oriented automation system was accomplished.
The important aspects that were lacking in the initial project proposal were addressed in this
new design. These aspects include accessibility, security, usability, cost-effective and scalability.
Descriptions below explain how our project addresses these individual aspects.
Accessibility: This project uses an LDAP System which is used to authenticate users prior to
granting them access to the EZ-Access system. Project website is easily accessible from
anywhere, through a Personal Computer (PC) or a smartphone. Only requirement is that the
user will have to VPN into the Rutgers network since the server for our project is located at
Rutgers. Once user has setup a VPN connection to Rutgers, EZ-Access website can be accessed
without any issues.
Security: All of the major security concerns have been taken into account, and the EZ-Access
Automation System has been made relatively secure of everyday university use. By
incorporating the prevention measure of SQL injection and keep a close watch on all created
sessions, the EZ-Access websites have been made very secure from malicious users. In
addition, by adding an extra layer of network security between the server and the main
controllers, and the main controllers and the devices themselves our system ensures that a
user’s information and privacy will always we maintained.
Usability: EZ-Access introduces 2 enhancements to the project which make the system userfriendly. Smartphones have become an important part of our lives and due to its dynamic
nature, they are appealing to the crowd. Our system has not only a desktop website, which can
be accessed from a work station or a laptop, but also a mobile website, which is designed to
operate on smartphones.
Cost-Effective: A main controller can support 5 devices. For under $400, a company can build
out a main controller and 5 base devices. If placed into production, the Main controller cost and
base device cost can decrease sharply, since they use similar technologies.
Scalable: authentication is done via LDAP, which can be scaled to an enterprise sized system.
The mobile website and database can be scaled to support large operations (10,000+users).
Page
27
References:
[1]
I.F.Alyildiz W. Su, Y. Sankarasubramaniam, E.Cayirci
“A survey on sensor networks” IEEE Communications Magazine, vol. 40, no 8, pp 102114, Aug 2002
[2]
J. Hill, R. Szewczyk, A, Woo, S. Hollar, D. Culler, and K. Pister,
System Architecture Directions for Networked Sensors, ASPLOS, November 2000.
[3]
N. Sriskanthan, F. Tan, A. Karande
“Bluetooth based home automation system”, Microprocessors and Microsystems, Vol.
26, no. 6. Pg 281-289, 2002
[4]
Karen Scarfone, John Padgette
“Guide to Bluetooth Security”, Recommendations of the National Institute of Standards
and Technology, Sept 2008
[5]
Khushwinder Gill, Shuang-Hua Yang, Fang Yao and Zin Lu
“A ZigBee-Based Home Automation System”, IEEE Transactions on Consumer
Electronics, Vol. 55, No. 2, May 2009
[6]
John A. Stankovic
“Wireless Sensor Networks”, University of Virginia, Computer Science, June 2006
[7]
Banner Engineering Corp
“Frequency Hop Spread Spectrum vs Direct Sequence Spread Spectrum”, Theory and
Terminology Note, 2007
[8]
Gary Legg
“ZigBee: Wireless Technology For Low-Power Sensor Networks”, eetimes.com, 2004
[9]
http://www.qrme.co.uk/qr-code-resources/understanding-a-qr-code.html
[10]
http://marksprague.wordpress.com/qr-codes-technology/understanding-qr-codes/
[11]
Riri Fitri Sari, Syarif Hidayat
“Integrating Web Server Applications With LDAP Authentication: Case Study on Human
Resources Information System of UI”, Electrical Engg. Dept., Univ. of Indonesia, 2006
[12]
X.500 and LDAP security: A comparative Overview by Vesna Haller
[13]
Learing PHP. MySQL & Java Script by o’Rielly
[14]
Ali Ziya Alkar Member, IEEE, John Roach, Member, IEEE, Dilek Baysal, Member, IEEE“IP
Page
28
based home automation systems”
Page
29