winlab home page - ez- access automation systemscrose/capstone12/entries/ez...page 1 ez- access...

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

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

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

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].

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).

Sensor Node

Gateway Node

Fig 1: A Wireless Sensor Network

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.

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

Host Controller BT

Client 1 BT

BT Client 2

Piconet

Figure 1: Bluetooth Communication between Host and Client [3]

Individual Channels

Frequency Hop

Figure 2: Frequency Hopping Spread Spectrum [7]

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]

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.

Figure 3a-b: Direct Sequence Spread Spectrum [7]

Figure 4: Network Topologies Star Cluster

Mesh

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 sub-

system. Table displayed below shows comparisons between the 2 protocols.

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

Characteristic Zigbee Bluetooth Max Range (m) 400 100

Data Rate (Kbps) 250 1000

1) Adding a New Node 30ms 20s

2) Waking up a Slave Node 15ms 3s

Power Profile Years Days

Security 128 bit AES (App layer) 64 Bit (Link Layer)

Complexity Simple Complex

No. of Devices per network 65000 8

Reliability High Medium

Table 1: Bluetooth vs. ZigBee Protocol

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 small-

scale.

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

Hierarchy of Objects

TCP/IP

Network

Figure 5: Working Mechanism of LDAP [11]

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.

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!

Figure 6: LDAP Framework [11]

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.

Figure 7: A QR Code Figure 8: QR Code Explained [9]

http://qrcode.kaywa.com/

Blue-tooth enabled smart phone

Blue Tooth Adapter

Arduino Microcontroller #1

Key-Less door opener

Power Switch controller

Power Switch

Blue Tooth Adapter

Blue tooth Link

Blue tooth LinkB

lue

tooth

Lin

k

Arduino Microcontroller

Blue Tooth Adapter

Servo Motor/ Door opener device

Main Controller

Blue Tooth Adapter

Blue Tooth Adapter

Blu

e t

oo

th L

ink

Arduino Microcontroller

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:

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.

Figure 8: Initial System Model

New System Model

A Simplified complete system architecture is shown below.

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

Figure 9: New System Architecture

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.

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.

16 Bytes 16 Bytes 16 Bytes 16 Bytes

1111 Main Controller ID Device MAC 0000 Command Flag

Figure 10: Packet Structure

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

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:

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 11: Desktop version of the Website

Figure 12: Mobile version of the Website

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:

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 EZ-

access 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. [email protected] 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

mailto:[email protected]

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.

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

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 Ez-

Access 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.

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

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.

Cost Analysis No matter how many bells and whistles a product might have, it needs to be cost-effective. 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 1 49.03 49.03

Arduino Board Uno 5 26.56 132.8

Arduino Ethernet Shield 1 45.95 45.95

XBee Radio 11 19 209

Arduino Pro Mini 5 18.95 94.75

FTDI Basic Breakout 5 14.95 74.75

Bluetooth SMIRF Adapter 1 39.99 41.31

Arduino Board Uno 1 34.99 37.44

Acrylic Sheet 2 3.69 7.50

Accessories 13

Grand total 705.03

Item Quantity Unit Cost ($) Total Cost ($)

Main Controller 1 113 121 Arduino Board Mega 1 49 52

Arduino Ethernet Shield 1 45 49

XBee 1mW 1 19 20

Sub-Devices 3 45 146 Arduino Board Uno 1 26 28

XBee 1mW 1 19 20

Grand Total 267

Table 2: Proposed Parts List

Table 3: Product Parts List

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.

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 user-

friendly. 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).

References: [1] I.F.Alyildiz W. Su, Y. Sankarasubramaniam, E.Cayirci

“A survey on sensor networks” IEEE Communications Magazine, vol. 40, no 8, pp 102-114, 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

http://www.qrme.co.uk/qr-code-resources/understanding-a-qr-code.html

http://marksprague.wordpress.com/qr-codes-technology/understanding-qr-codes/

based home automation systems”

winlab home page - ez- access automation systemscrose/capstone12/entries/ez...page 1 ez- access...

Documents