DECLARATION BY THE CANDIDATE

I Y. PAVAN KUMAR (10102197), hereby declare that the project report

titled “ON SECURING THE DEVICE TAG MANAGEMENT” under the esteemed

guidance of Dr. J.K.R. SASTRY, Professor, Dept. of CSE; is submitted in the partial

fulfillment of the requirements for the award of the degree of Master of Technology in

Embedded Systems. This is a record of bonafide work carried out by me and the results

embodied in this project report have not been reproduced or copied from any source .The

results embodied in this project report have not been submitted to any other university for the

award of any other degree.

By,

Y. PAVAN KUMAR,

10102197.

ACKNOWLEDGEMENTS

Apart from the efforts of me, the success of any work depends largely on the

encouragement and guidelines of many others. I take this opportunity to express my gratitude

to the people who have been instrumental in the successful completion of this thesis.

I would like to show my greatest appreciation to my internal guide Dr. J.K.R Sastry,

Professor, Dept. of CSE. I can’t say thank you enough for his tremendous support and help.

I feel motivated and encouraged every time I attend his meetings. Without his encouragement

and guidance this thesis would not have materialized and implemented.

I am deeply indebted to my Head of the Department Prof. S. Balaji, Dept. of ECM; who

modeled me both technically and morally for achieving greater success in life.

I express my utmost gratitude to my thesis coordinators Dr. A.S.N. Chakravarthy,

Professor, Dept. of ECM; Mr. G. Kalyan Mohan, Associate Professor, Dept. of ECM;

for their timely advices and guidance in the course of my thesis work.

Finally, I owe a lot to the teaching and non-teaching staff of the Dept. of ECM for their

direct or indirect support in the entire course of my thesis work.

KONERU LAKSHMAIAH UNIVERSITYDEPARTMENT OF ELECTRONICS & COMPUTER ENGINEERING

GREEN FIELDS, VADDESWARAM.

ON SECURING THE DEVICE TAG MANAGEMENT

Student Details : Y. Pavan Kumar 10102197, M. Tech (Embedded Systems), Department of ECM.

Internal guides : Dr. J.K.R Sastry

Professor, Department of CSE.

Dissertation Coordinators : Dr. A.S.N Chakravarthy

Professor, Department of ECM. : Mr. G. Kalyan Mohan Associate Professor, Department of ECM.

A DISSERTATION

ON

ON SECURING THE DEVICE TAG MANAGEMENT

BY

Y. PAVAN KUMAR

10102197

Prepared the dissertation report on “ON SECURING THE DEVICE TAG MANAGEMENT” in the partial fulfillment of requirements in degree of Master of Technology (M. Tech) in Embedded Systems.

DEPARTMENT OF ELCETRONICS & COMPUTER ENGINEERING

KONERU LAKSHMAIAH UNIVERSITY

GREEN FIELDS, VADDESWARAM.

2011-12

KONERU LAKSHMAIAH UNIVERSITYDEPARTMENT OF ELECTRONICS & COMPUTER ENGINEERING

GREEN FIELDS, VADDESWARAM.

Duration of the Dissertation:

Date of Start:

Date of Submission:

Dissertation carried out at: “K.L. UNIVERSITY, VADDESWARAM.”

Title of the Project: “ON SECURING THE DEVICE TAG MANAGEMENT”

Student Details : Y. Pavan Kumar 10102197, M. Tech (Embedded Systems), Department of ECM.

Internal Guides : Dr. J.K.R Sastry

Professor, Department of CSE.

Research Areas : Security of communication standards, Communication.

Key Words : Intelligent Tag, Mobile Device (HOST), Security

mechanisms, Bluetooth, Wi-Fi.

ABSTRACT:

TAG is a small embedded system which is used for storing and remotely retrieving data

about objects the reader wants to manage. As the technology is getting advanced, these

TAGS are being made intelligent by providing functions like securing, tamper proofing,

power management, communication with hand-held devices etc. The TAG and the HOST

will have to communicate with each other for supporting many of the functions such as

identification, information on location etc.

For implementing any of the intelligence within the Tag, the TAG must communicate

with a remote HOST which in this case is the Mobile Device. The communication between a

Tag and Mobile Device has to be established using wireless communication standards like

Bluetooth, Wi-Fi etc. As the communication medium is wireless, there is a scope for the

attacker to perform various attacks on the communication between a Tag and Mobile Device.

The communication between the TAG and the HOST being intelligent must be secured to

protect the secrecy built into the system. To implement the appropriate security measures to

the communication between a Tag and Mobile Device, the following dissertation has mainly

focused on implementing an intelligent mechanism to sense whether there is any possibility

for attacking the communication between a Tag and Mobile Device and activate appropriate

counter-measures against that attacks. Software architecture has been proposed and the

software is developed for implementing in the pilot project.

Signature of the Student

Dr. J.K.R. Sastry Prof. S. BalajiProfessor Head of the DepartmentDepartment of CSE Department of ECMK L University K L University

TABLE OF CONTENTS

1. INTRODUCTION 1

1.1 TERMINOLOGY AND DEFINITIONS 11.2 THEORETICAL FOUNDATION 41.2.1 BLUETOOTH 41.2.1.1 Security Mechanisms 41.2.1.2 Bluetooth security features 51.2.1.3 Bluetooth security issues 51.2.1.4 Counter-measures for attacks on Bluetooth 81.2.2 WI-FI 101.2.2.1 Wireless LAN Architecture 111.2.2.2 Wi-Fi Security Threats 111.2.2.3 Counter measures for Wi-Fi vulnerabilities 131.3 PROBLEM DEFINITION 141.4 SCOPE 151.5 METHODOLOGY 151.6 LIMITATIONS 16

2. LITERATURE SURVEY 17

3. RESEARCH FINDINGS 20

3.1 BUILDING INTELLIGENCE FOR SECURING THE COMMUNICATION BETWEEN THE TAGS AND THE MOBILE DEVICES 203.1.1 SUMMARY OF FINDINGS 203.1.2 INTRODUCTION 203.1.3 INVESTIGATIONS 213.1.4 CONCLUSIONS 243.2 SOFTWARE ARCHITECTURE FOR BUILDING INTELLIGENCE TO SECURE THE COMMUNICATION BETWEEN THE TAGS AND THE MOBILE DEVICES 253.2.1 SUMMARY OF FINDINGS 253.2.2 INTRODUCTION 253.2.3 INVESTIGATIONS 263.2.4 CONCLUSIONS 27

4. REQUIREMENTS ENGINEERING 28

4.1 TAG SIDE REQUIREMENTS ENGINEERING 284.1.1 OVERVIEW OF THE SYSTEM 284.1.2 PROCESS FLOW MODELING 294.1.3 HARDWARE REQUIREMENTS 304.1.4 FUNCTIONAL REQUIREMENTS 30

4.1.5 NON FUNCTIONAL REQUIREMENTS 314.1.6 TRACING THE FUNCTIONAL REQUIREMENTS THROUGH USE CASES 314.1.7 TRACING THE BUSINESS OBJECTS THROUGH CLASSES 314.2 MOBILE SIDE REQUIREMENTS ENGINEERING 324.2.1 OVER VIEW OF MOBILE SIDE DESCRIPTION 324.2.2 PROCESS FLOW MODELING 334.2.3 HARDWARE REQUIREMENTS 344.2.4 FUNCTIONAL REQUIREMENTS 354.2.5 NON FUNCTIONAL REQUIREMENTS 354.2.6 TRACING THE FUNCTIONAL REQUIREMENTS THROUGH USE CASES 354.2.7 TRACING THE BUSINESS OBJECTS THROUGH CLASSES 36

5. ANALYSIS 37

5.1 TAG SIDE ANALYSIS 375.1.1 HARDWARE ANALYSIS 375.1.2 USE CASE MODELING 375.1.3 BUSINESS PROCESS MODELING THROUGH HW RELATED CLASS DIAGRAM 385.1.4 BUSINESS PROCESS MODELING THROUGH SW RELATED CLASS DIAGRAM 395.1.5 BUSINESS PROCESS MODELING RELATED TO INTERFACING OF HW AND SW COMPONENTS 415.2 MOBILE SIDE ANALYSIS 425.2.1 HARDWARE ANALYSIS 425.2.2 USE CASE MODELING 425.2.3 BUSINESS PROCESS MODELING THROUGH HW RELATED CLASS DIAGRAM 435.2.4 BUSINESS PROCESS MODELING THROUGH SW RELATED CLASS DIAGRAM 445.2.5 BUSINESS PROCESS MODELING RELATED TO INTERFACING OF HW AND SW COMPONENTS 45

6. DESIGN 47

6.1 TAG SIDE DESIGN 476.1.1 HARDWARE DESIGN 476.1.1.1 Block Diagram 476.1.1.2 Object Modeling 496.1.1.3 Design of Hardware Elements 516.2 SOFTWARE DESIGN 676.2.1 OBJECTS MODELING 676.2.2 INTEGRATION DESIGN 69

7. IMPLEMENTATION 70

7.1 CLIENT SIDE CODE 707.2 MOBILE SIDE CODE 75

8. EXPERIMENTATION RESULTS 89

9. SUMMARY AND CONCLUSIONS 92

10. FUTURE WORK 92

LIST OF FIGURES

FIGURE 3.1 COMMUNICATION ARCHITECTURE OF INTELLIGENT TAG MANAGEMENT SYSTEM

..........................................................................................................................................22FIGURE 3.2 IMPLEMENTATION OF INTELLIGENCE FOR SECURING THE COMMUNICATION

BETWEEN TAG AND MOBILE DEVICE................................................................................23FIGURE 3.3 PARAMETERS AND APPROPRIATE COUNTER MEASURES FOR ENSURING SECURITY

..........................................................................................................................................24FIGURE.3.4 SOFTWARE ARCHITECTURE FOR BUILDING INTELLIGENCE TO SECURE THE

INTELLIGENT TAG MANAGEMENT SYSTEM......................................................................27FIGURE 4.1 OVERVIEW OF THE INTELLIGENT TAG APPLICATION...........................................28FIGURE 4.2 PROCESS FLOW MODELING FOR SECURITY MANAGEMENT ON TAG SIDE...............29FIGURE 4.3 OVERVIEW OF THE INTELLIGENT TAG APPLICATION ON MOBILE SIDE...............32FIGURE 4.4 PROCESS FLOW MODELING FOR SECURITY MANAGEMENT ON MOBILE SIDE......34FIGURE 5.1 USE CASE DIAGRAM SHOWING FUNCTIONAL REQUIREMENTS OF SECURITY

MANAGEMENT...................................................................................................................38FIGURE 5.2 HARDWARE CLASS DIAGRAM OF SECURITY MANAGEMENT................................39FIGURE 5.3 SOFTWARE CLASS DIAGRAM OF THE SECURITY MANAGEMENT..........................41FIGURE 5.4 CLASS DIAGRAM INTERFACES OF HW AND SW COMPONENTS ON TAG SIDE......42FIGURE 5.5 USE CASE MODELING ON MOBILE SIDE...............................................................43FIGURE 5.6 HARDWARE CLASS DIAGRAM OF IDENTIFICATION SYSTEM ON MOBILE SIDE.....44FIGURE 5.7 SOFTWARE CLASS DIAGRAM OF SECURITY MANAGEMENT ON MOBILE SIDE......45FIGURE 5.8 CLASS DIAGRAM INTERFACES HW AND SW COMPONENTS ON MOBILE DEVICE

SIDE...................................................................................................................................46FIGURE 6.1: TAG SIDE DESIGN DIAGRAM................................................................................47FIGURE 6.2 HARDWARE BLOCK DIAGRAM OF INTELLIGENT TAG............................................49FIGURE 6.3 OBJECT MODELING DIAGRAM OF TAG DESIGN....................................................50FIGURE 6.4: PIN DIAGRAM OF ARM CONTROLLER.................................................................52FIGURE 6.5: GENERAL TIMING DIAGRAM................................................................................53FIGURE 6.6: ADDRESS TIMINGS................................................................................................53FIGURE 6.7: DATA WRITE CYCLES..........................................................................................53FIGURE 6.8: DATA READ CYCLES; DBE IS HIGH DURING THE CYCLE SHOWN......................54FIGURE 6.9: DATA BUS CONTROL............................................................................................54FIGURE 6.10: CONFIGURATION DIAGRAM................................................................................54FIGURE 6.11: EXCEPTION TIMING............................................................................................54FIGURE 6.12: CLOCK TIMING OF ARM7..................................................................................55FIGURE 6.13: UART INTERFACING PIN OUT DIAGRAM...........................................................56FIGURE 6.14: TIMING DIAGRAM OF UART..............................................................................56FIGURE 6.15: PIN DIAGRAM OF EEPROM...............................................................................57FIGURE 6.16: I2C PROTOCOL IC FOR INTERFACING EEPROM...............................................58

FIGURE 6.17: TIMING DIAGRAM FOR I2C.................................................................................58FIGURE 6.18: USB INTERFACE.................................................................................................60FIGURE 6.19: LCD 2X16 WITH ITS PIN DESCRIPTION..............................................................61FIGURE 6.20: TIMING DIAGRAM OF LCD.................................................................................61FIGURE 6.21: 4X4 MATRIX KEYPAD........................................................................................62FIGURE 6.22: SHOWS THE TIMING DIAGRAM OF MATRIX KEYPAD.........................................62FIGURE 6.23: POWER SUPPLY CIRCUIT....................................................................................64FIGURE 6.24: BLUETOOTH MODULE UART INTERFACED.......................................................65FIGURE 6.25: BLUETOOTH MODULE INTERFACED WITH LPC2148.........................................66FIGURE 6.26: XBEE WI-FI MODULE.........................................................................................67FIGURE 6.27 SOFTWARE OBJECT INTERACTION ON THE TAG SIDE........................................68FIGURE 6.28 INTERACTION BETWEEN THE HW OBJECTS AND SW OBJECTS ON THE TAG SIDE

..........................................................................................................................................69FIGURE 8.1 ATTACK ON THE TAG SIDE....................................................................................90FIGURE 8.2 ATTACK ON THE MOBILE SIDE..............................................................................90

LIST OF TABLES

TABLE 1-1 KEY WORDS AND THEIR DEFINITIONS OF THE SECURITY MECHANISMS...................3TABLE 1-2 SELECTING A SECURE PIN.......................................................................................9TABLE 4-1 HARDWARE REQUIREMENTS ON TAG SIDE............................................................30TABLE 4-2 FUNCTIONAL REQUIREMENTS OF TAG THROUGH USE CASES.................................31TABLE 4-3 BUSINESS OBJECTS THROUGH CLASSES.................................................................32TABLE 4-4 HARDWARE REQUIREMENTS ON MOBILE SIDE......................................................35TABLE 4-5 FUNCTIONAL REQUIREMENTS THROUGH USE CASES.............................................35TABLE 4-6: MOBILE DEVICE BUSINESS OBJECTS THROUGH CLASSES.....................................36TABLE 5-1: HARDWARE ANALYSIS OF THE TAG......................................................................37TABLE 5-2: USE CASE DESCRIPTION........................................................................................38TABLE 8-1 EXPERIMENTAL RESULTS FOR COUNTER ATTACKING METHODS............................91

1. INTRODUCTION

The Intelligent Tag Management System consists of Mobile Devices (as Tag readers),

group of Tags and some sort of middleware integrated in it. The tag is attached to an object to

be tracked. It picks up signals from a reader or scanner and then return the signals, usually

with some additional data like a unique serial number or other customized information. In

this, Mobile Device is being used as Tag reader. So, the Mobile Device has to communicate

with Tags by using various wireless communication standards like Bluetooth, WI-Fi, NFC

etc. As the medium is through wireless, the attackers have scope to compromise the

communication between Mobile device and Tags. Hence, the aspects of security are getting

highlighted in these types of systems.

1.1 Terminology and definitions

Terminology

Tag:

A tag is a combination of a microchip and antenna that can be programmed with

information to identify items and transmit that information to a receiver. Some tags can also

receive new information, such as location information during shipment.

Active Tags:

Active Tags use batteries as a partial or complete source of power to boost the effective

operating range of the tag and to offer additional features over passive tags, such as

temperature sensing.

Reader:

A device used to communicate with RFID tags. The reader has one or more antennas,

which emit radio waves and receive signals back from the tag. The reader is also sometimes

called an interrogator because it interrogates the tag.

Authorization

Authorization is finding out if a user, once identified, is permitted to have the resource.

This is usually determined by finding out if that user is a part of a particular group, if that

user has paid admission, or has a particular level of security clearance. Authorization is

equivalent to checking the guest list at an exclusive party, or checking for your ticket when

you go to the opera.

Authentication

Authentication is any process by which you verify that someone is who they claim they

are. This usually involves a username and a password, but can include any other method of

demonstrating identity, such as a smart card, retina scan, voice recognition, or fingerprints.

Authentication is equivalent to showing your driver’s license at the ticket counter at the

airport.

Encryption

Encryption is the conversion of data into a form, called a cipher text, which cannot be

easily understood by unauthorized people. Simple ciphers include the substitution of letters

for numbers, the rotation of letters in the alphabet, and the "scrambling" of voice signals by

inverting the sideband frequencies. Complex ciphers work according to sophisticated

computer algorithms that rearrange the data bits in digital signals.

Decryption

Decryption is the process of converting encrypted data back into its original form, so it

can be understood. In order to easily recover the contents of an encrypted signal, the correct

decryption key is required. The key is an algorithm that undoes the work of the encryption

algorithm.

Bluetooth

Bluetooth is a wireless technology for creating personal networks operating in the 2.4

GHz unlicensed band, with a range of 10 meters. Networks are usually formed ad-hoc from

portable devices such as cellular phones, handhelds and laptops. Unlike the other popular

wireless technology, Wi-Fi, Bluetooth offers higher level service profiles, e.g. FTP-like file

servers, file pushing, voice transport, serial line emulation, and more.

Wi-Fi

Wi-Fi short for "wireless fidelity" is a term for certain types of wireless local area

network (WLAN) that uses specifications in the 802.11 family. The term Wi-Fi was created

by an organization called the Wi-Fi Alliance. It is a mechanism for wirelessly connecting

electronic devices. A device enabled with Wi-Fi, such as a personal computer, video game

console, Smartphone, tablet, or digital audio player, can connect to the Internet via a wireless

network access point.

Access Points

A wireless access point (WAP) is a device that allows wireless devices to connect to a

wired network using Wi-Fi, Bluetooth or related standards. The WAP usually connects to a

router (via a wired network), and can relay data between the wireless devices (such as

computers or printers) and wired devices on the network. Wireless security includes: WPA-

PSK, WPA2, IEEE 802.1x/RADIUS, WDS, WEP, TKIP, and CCMP (AES) encryption.

Unlike some home consumer models, industrial wireless access points can also act as a

bridge, router, or a client.

Peer-to-peer Networks

A peer-to-peer (P2P) network is created when two or more PCs are connected and share

resources without going through a separate server computer. A P2P network can be an ad hoc

connection in which a couple of computers can be connected via a Universal Serial Bus to

transfer files. A P2P network also can be a permanent infrastructure that links half-a-dozen

computers in a small office over copper wires. Or a P2P network can be a network on a much

grander scale in which special protocols and applications set up direct relationships among

users over the Internet.

DefinitionsTable 1-1 Key words and their definitions of the security mechanisms

S.No Key Words Definition1 ACL Asynchronous Connection-Less is a communication protocol used as

a transmission link for data communication in the Bluetooth system with access code (72bit) + packet header (54bit) + payload + CRC (16bit).

2 SCO Synchronous Connection-Oriented link is a point-to-point link between the master and specific slave. It has symmetric 64 kbps rate, typically used for voice transmission.

3 WEP WEP is a standard network protocol that adds security to 802.11 Wi-Fi networks at the data link layer

4 WPA Wi-Fi Protected Access (WPA) and Wi-Fi Protected Access II (WPA2) are two security protocols developed by the Wi-Fi Alliance to secure wireless computer networks implemented in the majority of the IEEE 802.11i standard.

1.2 Theoretical Foundation

Several communication protocols are being used for establishing communication between

various mobile devices. As they involve communication within the wireless medium, several

security issues will be considered to provide secured and uninterruptable data transfer

between the devices. The different communication protocols, the vulnerabilities encountered

in the respective protocols and their possible countermeasures are presented here.

1.2.1 Bluetooth

Bluetooth devices operate on an unlicensed frequency band between 2.4 to 2.4835 GHz.

To avoid interference with other devices operating on the same band, the technology uses a

frequency hopping algorithm with 1600 frequency hops per second. So it can be implemented

to operate in noisy frequency environments also. The time during which devices operate in a

certain frequency is called a time slot and is 625 microseconds in duration. Units in a Piconet

change frequency at the same time on command from the master unit, based on a pseudo-

random hopping sequence. The frequency band is broken up into 79 channels spaced 1 MHz

apart. Data is transmitted in frames, which can span 1, 3 or 5 slots.

There are two types of connection: ACL (asynchronous connectionless) and SCO

(synchronous connection-oriented).

The first type of connection is used to transfer data that can be handled at any time. A

slave unit can have only one ACL connection to the master unit. The second link type is used

for transferring data in real time, e.g. for transmitting voice data. A slave unit can have up to

3 SCO links with the main unit, each with a rate of 64 kb/sec.

1.2.1.1 Security Mechanisms

According to the specification, user information can be protected by encrypting

transmitted data, while the access code and the packet header are transmitted over an

unencrypted channel. Data is encrypted using the E0 stream cipher. Attacks at the

communication link level are therefore clearly possible. Bluetooth can operate in one of three

Security Modes:

Unprotected (no security): In this mode no encryption or authentication is used, while the

device itself operates in a non-discriminating, i.e. in broadcasting (promiscuous) mode.

Application/service based (L2CAP): In this mode, once a connection is established,

Security Manager performs authentication, thereby restricting access to the device.

Link layer PIN authentication/ MAC address encryption: Authentication is performed

prior to a connection be established. Although transparent encryption is used, even in this

mode the device can be compromised.

Bluetooth security is based on the generation of keys using a PIN code, which can be 1 to

16 bytes in length. Most devices currently use 4-byte PINs. First, the E2 algorithm is used to

generate a 16-byte Link Key based on the PIN code. Then an Encryption Key based on the

Link Key is calculated using the E3 algorithm. The first key is used for authentication, the

second for encryption.

The authentication process is as follows:

1. The device initiating the connection sends its address (BD_ADDR). This 48-bit address is unique, like a network adaptor's MAC address. A device's manufacturer can be determined by this address.

2. In response a random 128-bit challenge sequence is sent (AU_RAND).3. Both devices generate an authentication response string called SRES based on

BD_ADDR, Link Key and AU_RAND. 4. The device trying to establish the connection sends its SRES. 5. The other device compares the SRES received with its own and if the two strings match,

establishes a connection.

1.2.1.2 Bluetooth security features

Basically Bluetooth offers two modes to connect with other Bluetooth devices. They are:

Discoverable Mode: It is a feature of Bluetooth which is used to make the visible in order to

find it. If the device is invisible or hidden, then no other device can find it. When the device

is in visible mode it is very easy to find it using any Bluetooth enabled devices like PC,

Laptop etc.

Non-Discoverable Mode: With this feature the Bluetooth device cannot found by any other

Bluetooth enabled device. It can be only visible for those devices which have its MAC

address and have information about this device.

1.2.1.3 Bluetooth security issues

There was number of ways in which Bluetooth Security can be penetrated which is

because of the little processing capability of the devices. The major forms of attacks that can

be performed on the Bluetooth communication are as follows:

1. Blue jacking: Blue jacking involves the hacker making an attempt to send a phone

contact or business card to another nearby phone. The ‘name' field of the contact can be

misused by replacing it with a suggestive text so that the target device reads it as a part of

intimation query displayed on its screen. This may be thought of as equivalent to spam e-

mail since both are unsolicited messages displayed on recipients' end without consent,

and by exploiting the inherent nature of communication. In this, the attacker uses the

Bluetooth to send the messages, which is an example of push attack.

Devices generally require pairing or prompt the owner before they allow a remote

device to use any or most of their services. Some devices, such as mobile phones, usually

accept OBEX business cards and notes without any pairing or prompts. This is why the

regular Blue Jacking attacks use the OBEX Business card protocol. But we can dispatch

readable messages even easier. After we have the Bluetooth address of the "victim", we

can simply require pairing to the remote device, and the user will get prompt in order to

allow or deny the process. When this happens, the remote device receives the name of the

device that initiated the pairing sequence. In this case, it's the name of our device. So all

we need to do is to set a message instead of our Bluetooth device name, and initiate a pair

request to the remote device, the "victim".

2. Blue Snarfing: Blue Snarfing goes a step further and actually accesses or steals data like

messages, calendar, phone book etc., from the target device in an unauthorized manner

which includes bypassing the usual paring requirement, while leaving no trace of the

attack. Any device with its Bluetooth connection turned on and set to “discoverable” (able

to be found by other Bluetooth devices in range) can be attacked. By turning off this

feature you can be protected from the possibility of being Blue Snarfed. But here, the

problem is bigger since there have been reports of the tools that use methods such as

device address guessing and brute force in order to break-in, even when device is

configured as ‘invisible'.

In this attack, attacker does not send anything to take out the data, thus this is known

as pull attack. This attack uses the OBEX (OBject EXchange) protocol, by this it forcibly

pulls out the data from the victim’s phone. Hence this kind of attack is also popularly

known as OBEX pull attack.

3. Blue Bugging: The next level of sophistication in Bluetooth hacking is Blue Bugging,

where the victim device is controlled by the attacker, who sends commands to perform

actions as if having physical access to the device. Thus, a hacker could eavesdrop on

phone conversations, place phone calls, send and receive text messages, and even connect

to the Internet. This is functionality analogous to Trojans. The tools for Blue Bugging

include ones that run off the PCs, which means laptops with high range Bluetooth

connectivity, which makes things even worse. The Blue Bug security loophole allows to

issue AT commands via a covert channel to the vulnerable phones without prompting the

owner of this phone.

4. PIN Cracking: A sniffer records Bluetooth packets and can decode the packets to

determine the information contained in them. If you capture packets that are involved in

the process of authenticating two Bluetooth devices, you can use information from those

packets to determine the user PIN. The packet data doesn't contain the PIN itself, but it

contains information derived from the PIN. With some number crunching, you can

recover the PIN.

5. Denial of Service Attack: A denial of service attack can be carried out as flooding

messages in Bluetooth devices. In flooding denial of service attack unnecessary data is

sent as much as possible to a victim. As a result, network bandwidth is wasted, disk space

is filled with unnecessary data or processing power is spent for useless purposes.

6. Eavesdropping: Eavesdropping on Bluetooth packets is largely depended upon two

variables, the MAC address and the clock. The MAC address is a unique identifier

allocated to the each device. The clock is a 3.2 kHz counter stored in a 28 bit number, and

it wraps approximately every 23 hours. Bluetooth uses frequency hopping over 79

channels in order to minimize interference and (usually) hops once every 625 micro sec,

sending one packet per channel. The hopping sequence is determined by the MAC

address of the master device and its clock.

The second hurdle to eavesdropping on data carried in Bluetooth connections is that

packets are whitened (scrambled) in order to improve error resilience and security. The

whitening is determined by six bits of the master device's clock. Thus, in order to

eavesdrop on a Bluetooth connection two pieces of information are needed: the MAC

address and clock of the master device. With this information, one can calculate the

hopping sequence and tune to the correct radio channel, and then un-whiten the received

packets.

7. Man-in-the-Middle Attack: In this attack, an attacker who has already obtained the link

keys and unit keys (BD_ADDR) of two Bluetooth devices can intercept the

communication and initiate new communications to both devices posing as the other. The

attacker impersonates the victim devices to each other thus the victim devices believe

they are communicating directly with each other.

In another person-in-the-middle attack scenario, vulnerabilities involving memory

constrained devices are exploited. Memory constrained devices rely on its unit key for

encryption to reduce the number of keys it is required to store. An un-trusted device, call

it C, can establish communications with the memory constrained device, call it A. This

connection may have other purposes other than obtaining the unit key for the purposes of

the attack. In any case, the memory constrained device, A, has shared its unit key with the

un-trusted device, C. When device A initiates communications with a differing device,

call it B, device C can use the obtained unit key and spoof an address to monitor the

communications between device A and B without the either party realizing it.

1.2.1.4 Counter-measures for attacks on Bluetooth

1. Blue Jacking:

1.1 Disable Bluetooth: Only enable Bluetooth when it is needed and disable it while in

crowded places or upon receiving an anonymous message.

1.2 Employ Undiscoverable/Hidden mode: Configure Bluetooth settings and putting the

Bluetooth device in the Undiscoverable or Hidden mode is a more practical

countermeasure. A Bluetooth device can be set to this option after pairing it with any

Bluetooth-enabled devices or accessories in use. This ensures that when an attacker

(who is not in the allowed list) searches for Bluetooth devices, your Bluetooth device

will not show up. At the same time, you can continue using Bluetooth to connect to

other devices.

2. Blue Snarfing:

2.1 Updating the devices: It's not Bluetooth itself that leaves the devices vulnerable to

Blue Snarfing, but certain quirks in older Bluetooth-enabled phones and PDAs. Early

models often came with a default discoverable mode; because manufacturers thought

most people wouldn't want to go through complex security procedures to share

business cards and phone numbers wirelessly. These loopholes have been eliminated

in most new device models.

2.2 Hiding the Devices: Make it a regular practice to switch your Bluetooth-enabled

devices to non-discoverable mode anytime you're not actively exchanging data with a

trusted device, or when you're in an unknown hot-spot area.

2.3 Longer pairing code: The Bluetooth protocol allows 16-digit pairing codes.

Unfortunately, many applications continue to use only 4-digit pairing codes. This

makes Bluetooth-enabled devices using a short pairing code vulnerable to brute force

attacks executed with the help of a Bluetooth-enabled computer. Hence, an attacker

can use brute force to crack the pairing code and execute further malicious activities.

Unfortunately, most people have the tendency to select and use short pairing codes.

3. Blue bugging: Mobile operators must establish a gateway level security solution in the

network to be able to flexibly filter the traffic. A real-time up-to-date antivirus client is

required in all smart phones, with a mechanism for automatically delivering updates

directly to the device.

4. PIN Cracking: Trivial PINs such as “0000” and “1234” should be avoided. A secure PIN

is approximately 64 bits in length, making it infeasible to break under the attack. The

following table.1 is a recommendation for selecting a secure PIN.Table 1-2 Selecting A Secure PIN

Character set used Recommended PIN length Minimum PIN length0-9 (10 characters) 19 characters ( = 63 bits) 12 characters ( = 40 bits) 0-9 A-Z (36 characters) 12 characters ( = 62 bits) 8 characters ( = 41 bits) 0-9 A-Z, a-z (62 characters) 11 characters ( = 65 bits) 7 characters ( = 42 bits) (Printable) ASCII (95 characters)

10 characters ( = 66 bits) 6 characters ( = 39 bits)

5. Denial of Service Attack:

5.1 When the pairing message is sent by one device: Denial of Service attack can be

avoided by storing the address of Bluetooth device, which is failed to authenticate

more than predefined number of unsuccessful attempts.

5.2 When the pairing messages sent by more than one device: In this type of attack

also if in particular time duration, the number of unsuccessful pairing is more than the

particular predicted number, the Bluetooth device can guess that the Denial of Service

attack is attempted. It can send the alert signal to the security manager to stop the

interaction with these devices.

5.3 When the attacker is changing the Bluetooth address of itself with another

Bluetooth address: In this type of attack if the attacker changes his Bluetooth address

with another Bluetooth device, he can send the wrong authentication response in reply

to the message sent by the verifier. The verifier will first update its failed

authentication device list by adding the address of the device which is not at present

in try to make the pairing but the attacker will use its address. The verifier’s device

itself sends message to the device after some time duration to authenticate the device.

If it is the right device, it will make the connection, otherwise it will fail to

authenticate.

6. Eavesdropping: Select the lowest power level on Bluetooth devices, so that user’s

transmission remains within a secure perimeter. Avoid pairing with wireless devices that

have an extended transmission range of 100 meters, because the Bluetooth signal could be

detected within and up to a 30-foot range.

Create a new PIN code for each Bluetooth pairing session with another device. If an

eavesdropping attack occurs on the Bluetooth device, and the PIN code that often uses

could easily be detected, and used by the attacker to pair with your wireless device.

7. Man-in-the-Middle Attack: While one of the initiating or non-initiating devices is trying

to connect with each other, the attacker will send wrong signals which leads to the

corruption of the original signal. So, the legitimate users thinks that, there may be some

sort of genuine jam in the network and gets frustrated, and deletes all the information

about the other devices. We have to stop these jamming attacks which are attacking PHY

layer. By considering the prevention schemes of jamming attack, we can avoid the MITM

attack. After that, the process of SSP will be followed for the secure communication. The

prevention schemes of PHY layer are also called anti-jamming techniques.

1.2.2 Wi-Fi

Wi-Fi means Wireless Fidelity technology and stands for all those technologies that fall

under the specifications of IEEE 802.11 including 802.11a, 802.11b and 802.11g. The

association of the term Wi-Fi with various technologies is merely because of the promotions

made by the Wi-Fi Alliance.

It is commonly known as Wireless LAN, in which high frequency radio waves are

required for transmission of data from one place to another. It operates on several hundred

feet between two places of data transmission.

1.2.2.1 Wireless LAN Architecture

Wireless LAN architecture is composed of different components which help in

establishing the local area network between different operating systems. These components

are very essential for Wi-Fi architecture.

1. Access Points: A special type of routing device that is used to transmit the data between

wired and wireless networking device is called as AP. It is often connected with the help

of wired devices such as Ethernet. It only transmits or transfers the data between wireless

LAN and wired network by using infra structure mode of network. One access point can

only support a small group of networks and works more efficiently. It is operated less

than hundred feet. It is denoted by AP.

2. Clients: Any kind of device such as personal computers, Note books, or any kind of

mobile devices which are inter linked with wireless network area referred as a client of

wireless LAN architecture.

3. Bridge: A special type of connectors which is used to establish connections between

wired network devices such as Ethernet and different wireless networks such as wireless

LAN. It is called as bridge. It acts as a point of control in wireless LAN architecture.

1.2.2.2 Wi-Fi Security Threats

1. Data Interception: Today, it’s widely understood that data sent over Wi-Fi can be

captured by eavesdroppers easily, within a few hundred feet; even farther with directional

antennas. Fortunately, all Wi-Fi certified products now support AES-CCMP data

encryption and integrity. Unfortunately, there are still legacy products that only speak

TKIP, and many WLANs are configured to accept both AES and TKIP. But TKIP is

vulnerable to message integrity check (MIC) attacks that allow a limited set of spoofed

frames to be injected – for example, ARP. Although resulting risks are modest, the

writing is on the wall: The time has come to retire TKIP and require AES-CCMP.

2. Denial of Service: WLANs are inherently vulnerable to DoS. Everyone shares the same

unlicensed frequencies, making competition inevitable in populated areas. The good

news: As enterprise WLANs migrate to 802.11n, they can use channels in the larger, less-

crowded 5 GHz band, reducing “accidental DoS”. Moreover, contemporary access points

(APs) can auto-adjust channels to circumvent interference. But that still leaves DoS

attacks: Phony messages sent to disconnect users, consume AP resources, and keep

channels busy. To neutralize common DoS attack methods like Death Floods, look for

newer products that support 802.11w management frame protection.

3. Rouge Access Points: Business network penetration by unknown, unauthorized APs has

long been a top worry. Fortunately, most enterprise WLANs now use legitimate APs to

scan channels for possible rogues in their spare time. Unfortunately, verifying “true

rogues” by tracing their wired network connectivity is a skill that ordinary WLAN gear

has yet to perfect. Without accurate classification, automated rogue blocking is a risky

proposition. To not just detect, but effectively mitigate rogue APs, deploy a Wireless IPS

that can reliably differentiate between harmless neighbors, personal hotspots, and

network-connected rogues that pose real danger, taking policy-based action to trace,

block, and locate the latter.

4. Wireless Intruders: Wireless IPS products like Motorola Air Defense, Air Magnet, and

Air Tight can also detect malicious Wi-Fi clients operating in or near a business’ airspace.

However, truly effective defense requires up-to-date, properly deployed WIPS sensors. In

particular, 802.11a/b/g sensors must be updated to monitor new 5 GHz channels

(including 40 MHz channels), parse 802.11n protocols, and look for new 802.11n attacks.

Furthermore, because 802.11n clients can connect from farther away, WIPS sensor

placement must be reviewed to satisfy both detection and prevention needs.

5. Evil Twin APs: Fraudulent APs can easily advertise the same network name (SSID) as a

legitimate hotspot or business WLAN, causing nearby Wi-Fi clients to connect to them.

Evil Twins are not new, but easier-to-use hacker tools have increased your risk of running

into one. Tools like Karmetasploit can now listen to nearby clients, discover SSIDs

they’re willing to connect to, and automatically start advertising those SSIDs. Once

clients connect, DHCP and DNS are used to route client traffic through the Evil Twin,

where local (phony) Web, mail, and file servers execute man-in-the-middle attacks. The

only effective defense against Evil Twins is server authentication, from 802.1X server

validation to application server certificate verification.

6. Wireless Phishing: In addition to the above man-in-the-middle application attacks,

hackers continue to develop new methods to phish Wi-Fi users.  For example, it’s

possible to poison Wi-Fi client Web browser caches, so long as the attacker can get into

the middle of a past Web session – such as by using an Evil Twin at an open hotspot.

Once poisoned, clients can be redirected to phishing sites long after leaving the hotspot,

even when connected to a wired enterprise network.  One technique for mitigating this

threat is to clear your browser’s cache upon exit.  Another possibility is to route all

hotspot traffic (even public) through a trusted (authenticated) VPN gateway.

1.2.2.3 Counter measures for Wi-Fi vulnerabilities

1. Use of Encryption: The most effective way to secure your wireless network from

intruders is to encrypt, or scramble, communications over the network. Most wireless

routers, access points, and base stations have a built-in encryption mechanism. If your

wireless router doesn’t have an encryption feature, consider getting one that does.

Manufacturers often deliver wireless routers with the encryption feature turned off. You

must turn it on.

2. Use anti-virus software and firewall: Devices on a wireless network need the same

protections as any computer connected to the Internet. Install anti-virus and anti-spyware

software, and keep them up-to-date. If the user’s firewall was shipped in the “off” mode,

it must be turned on.

3. Turn off identifier broadcasting: Most wireless routers have a mechanism called

identifier broadcasting. It sends out a signal to any device in the vicinity announcing its

presence. You don’t need to broadcast this information if the person using the network

already knows it is there. Hackers can use identifier broadcasting to home in on

vulnerable wireless networks. Disable the identifier broadcasting mechanism if your

wireless router allows it.

4. Change the default identifier on router: The identifier for your router is likely to be a

standard, default ID assigned by the manufacturer to all hardware of that model. Even if

your router is not broadcasting its identifier to the world, hackers know the default IDs

and can use them to try to access your network. Change your identifier to something only

you know, and remember to configure the same unique ID into your wireless router and

your computer so they can communicate. Use a password that’s at least 10 characters

long: The longer your password, the harder it is for hackers to break.

5. Change router’s pre-set administrator password: The manufacturer of your wireless

router probably assigned it a standard default password that allows you to set up and

operate the router. Hackers know these default passwords, so change it to something only

you know. The longer the password, the tougher it is to crack.

6. Allow only authorized computers to access wireless network: Every computer that is

able to communicate with a network is assigned its own unique Media Access Control

(MAC) address. Wireless routers usually have a mechanism to allow only devices with

particular MAC addresses access to the network. Some hackers have mimicked MAC

addresses, so don’t rely on this step alone.

7. Turn off wireless network: Hackers cannot access a wireless router when it is shut

down. If you turn the router off when you’re not using it, you limit the amount of time

that it is susceptible to a hack.

1.3 Problem Definition

In an intelligent tag management system, a Tag has to be in communication with the

remote Host i.e., Mobile Device. The communication between mobile device and intelligent

tags can be effected by using any of communication mechanism which includes Bluetooth,

Wi-Fi, etc. When communication is effected using these modes, the signals are emitted which

are available in a local area leading to huge vulnerability for attacking.

Several of security enforcement mechanisms are available to ensure security of the

devices. These mechanisms however will be active from the system startup and they don’t get

disabled even with the absence of attacks on the communication link. With the continuous

enabling of these security mechanisms, the unimportant tasks will get the maximum share of

the system functionality. Hence the system overhead will increase and the performance of the

system will degrade.

So there is a need for developing intelligence to the Tag for securing the communication

link between the Tag and the mobile device. By building intelligence to the system, it will

detect whether any attacks are being performed and enables the appropriate counter-attacking

mechanisms.

1.4 Scope

The scope of the project consists of the following individual elements of the research and

development project:

1. Conducting the literature survey of the various counter-attacking mechanisms against the different attacks on the communication link between a Tag and Mobile device.

2. Analysis of the various counter-measures with respect to securing the communication link and performance of the system.

3. Investigation of new security mechanism that builds intelligence into the Intelligent Tag Management System.

4. Investigation of software architecture that implements the proposed security mechanism.

5. Develop intelligent TAG related embedded system by using the proposed security mechanism and its software architecture.

6. Develop an application on the mobile device side which helps in establishing communication in between the TAG and the mobile device.

7. Experimenting with the new embedded systems and posting the experimental results considering both the applications on the TAG and the mobile device side.

8. Drawing conclusions.

1.5 Methodology

The methodology used for this project includes two phases, the Research Phase followed

by the Development Phase.

Research Phase

The following methodology is used during the research phase

1. Conduct literature survey related to various attacks that can be performed on the communication link between a Tag and the Mobile device and the corresponding counter-measures that can be applied to counter those attacks.

2. Investigate and develop efficient security mechanism which builds intelligence to the system.

3. Conduct literature survey related to software architecture and find the suitability of the same for implementing the investigated security mechanisms.

4. Investigate and develop suitable software architectures

Development Phase

1. Conduct requirement engineering for building intelligence to the system for securing the communication link between a Tag and the Mobile device.

2. Analyze and design an embedded system considering both Hardware and software considering both TAG and the remote HOST

3. Develop software that considers the investigated security mechanism and its software architecture.

4. Test the security mechanism and publish the results.

1.6 Limitations

The investigated security mechanism that builds intelligence to the Intelligent Tag and its

software will be tested and verified only using the ARM7 Controller on the Tag side and the

application developed for the Android OS on the Mobile device (Host) side.

2. LITERATURE SURVEY

Various counter-measure protocols have been proposed to address the security concerns

of systems that communicate with the tags.

“Security and privacy aspects of low-cost radio frequency identification systems” by

Dieter Hutter et al. [1] - suggested a model such that each tag will transmit a randomly

chosen key by encrypting the key value with the Hash function computations i.e. h (key).

Only the reader with exact corresponding key will be able to respond to a tag and then only

the specific tag will transmit the ID value of it. But in his proposal the ID value is static. So,

there is maximum chance for the adversary to trace that particular tag and to perform

eavesdropping on the communication between reader and tag. Later he suggested an

advanced version of his previous protocol by implementing the randomness to the key value.

But it was not providing forward security for the communication between them and is

vulnerable to replay attacks.

“Cryptographic approach to “privacy-friendly” tags” by Miyako Ohkubo,

Koutarou Suzuki and Shingo Kinoshita [2] - used Hash chains to propose a protocol. It

mainly concentrated on the implementation of forward security such that the data sent by the

tag is needed to be secured even when tags have been compromised to reveal the information

within the tag. But it has not succeeded because of the computational overhead involved in

the calculation of the hash chains at the back-end database.

“Hash-based enhancement of location privacy for radio-frequency identification

devices using varying identifiers” by Dirk Henrici and Paul Müller [3] - suggested the

usage of one way hash functions such that the location secrecy of a tag can be enhanced by

changing the identifier values of that tag for every reading instant by using a simple message

exchange. The adversary will be successful in making a tag undetectable to get access to

communicate with its reader by blocking the communication using DOS) denial of service

attacks or by employing the Kill Tag approach.

“A lightweight RFID protocol to protect against traceability and cloning attacks” by

Tassos Demetrio [4] - proposed a protocol which ensures privacy and resistance to tag

cloning. In this scheme the secret key value will be shared between tag and reader such that it

will be modified for successful successive identification. In addition the authentication is

verified on both reader and tag sides using a single secret key. But tracking of tag is still

possible because a value transmitted by the tags will be remained static between two

successful identifications. Hence, it is vulnerable to a database de-synchronization attack.

“Efficient authentication for low-cost RFID systems” by Young J. Hwang et.al [5] -

suggested an authentication protocol similar to Demetrio’s, which consists of two one way

hash functions that can be used to provide privacy for low cost RFID tags whose constraints

are low power sources, low die-size and limited computational capabilities. It is framed as

Low Cost Authentication Protocol (LCAP). But as said earlier these types of low

computational supporting tags are vulnerable to replay attacks, database de-synchronization

attacks and tracking attacks.

“Privacy and security in library RFID: Issues, practices, and architectures” by

Molnar and Wagner [6] - suggested a model in which a tag and a database should have to

share two secret values called identifier of tag and secret key. These values along with two

words, used especially for computations generated by the reader and the tag are fed into a

pseudorandom function. This scheme ensures privacy and protection against tracking attacks

but does not offer forward security.

“An approach to security and privacy of RFID system for supply chain” by Zhe

(Alex) Xiang et al. [7] - suggested a scheme which is used to exploit randomized access

control and that should be able to prevent hostile tracking and MIM (Man in the middle)

attacks. This scheme offers limited computational overhead and it is useful for systems with

several RFID tags. But it does not offer forward security and is vulnerable to replay attacks.

“Blue Sniff: Eve meets Alice and Bluetooth” by Dominic Spill et.al [8] - suggested

that when two wireless devices are intended to communicate with each other using various

communication standards like Bluetooth, Wi-Fi, NFC etc, a pairing procedure is necessary to

ensure the privacy of a system. This can be achieved by using necessary encryption at link

layer level. But this method will not yield good results to the user and is vulnerable while

attacker performs eavesdropping on the pairing procedure.

Dr Sastry et.al [9], [10] has proposed a security mechanism that implements the

intelligence to sense the situations of attacking and bring into the scope the counter attacking

mechanisms. The counter attacking mechanisms must only come into play at the time when

an attack is initiated. The counter attacking mechanisms are not to be inbuilt as in-stream

procedures as it effects the response time and as such both the TAG and the mobile devices

are short in resources and also the components of ES solution are basically slow devices and

the permanent residence and inline execution of any of the code actually hampers the design

parameters of the embedded systems.

3. RESEARCH FINDINGS3.1 Building intelligence for securing the communication between the Tags

and the Mobile Devices3.1.1 Summary of Findings

Tag is a small embedded system meant for identification of an object to which it is

attached and in addition the TAGS can be made to be intelligent such that they can identify

its own location, alert the master about an event occurring in its vicinity, sensing tampering

with its own etc. For implementing any of the intelligence within the Tag, the TAG must

communicate with a remote HOST which in this case is the Mobile Device. Tags can

communicate with the HOST by using the available interface at either end for transmitting

the data from the TAG side and for receiving commands from the HOST. The

communication system as such is vulnerable and therefore can be attacked. In this thesis,

various attacking and counter attacking mechanisms are discussed and an efficient method of

securing the communication between the TAG and the HOST is presented.

3.1.2 Introduction

The Intelligent Tag Management System consists of Mobile Devices (as Tag readers),

group of Tags and some sort of middleware integrated in it. Tag is a small embedded system

which is combined with a communication module inbuilt in a compact package. The

packaging is structured to allow the tag to be attached to an object to be tracked. The tags

pick up signals from a reader or scanner and then return the signals, usually with some

additional data like a unique serial number or other customized information.

Although usage of Tags is promising and may potentially have numerous applications,

they are vulnerable and subject to a wide range of attacks due to its compromising nature in

security, difficulty in physical protection, absence of infrastructure and so on. For example,

an illegal reader attempts to compromise tag identity by sending out queries. If a tag

continuously reports its identity to every reader without any verification, then adversary can

easily track moving objects (e.g., products and persons) by recognizing tag IDs carried with

them. Thus, the potential vulnerability of easy tracking presents a serious obstacle to its

usage.

In this, Mobile Device is being used as Tag reader. So, the Mobile Device has to

communicate with Tags by using various wireless communication standards like Bluetooth,

Wi-Fi, NFC etc. As the medium is through wireless, the attackers have scope to compromise

the communication between Mobile device and Tags. Hence, the aspects of security are

getting highlighted in these types of systems. The key security issues that have to be

considered while establishing wireless communication between them are:

i) Confidentiality: Confidentiality means that the data can only be used by authorized users and/or parties.

ii) Integrity: Integrity means that the data cannot be modified and stored by adversaries during transfer.

iii) Availability: Availability means that the data is always available for authorized use.iv) Un-traceability: Un-traceability means that intruder cannot recognize readers and tags

which he has already seen, at another time or in another place.

All the above mentioned security related issues must be handled within the tags and the

mobile device with minimal of the hardware and software support. The securing of the

communication between the Target and the HOST must also be achieved considering various

types of communication protocols which include Wi-Fi, Bluetooth and NFC that too in

various combinations of protocol versions. In this thesis, various counter attacking

mechanisms have been proposed that takes into account various types of communication

combinations.

3.1.3 Investigations

In the aspect of providing security for an Intelligent Tag, the key requirements on both

sides i.e. on the host side and the target side are Bluetooth, WI-Fi communication modules.

As the Tag has to be made intelligent to perform functions like identifying its own location,

alerting the master about an event occurring in its vicinity, sensing tampering with its own

etc, the Tags should communicate with the host by using the available interface at either end

for transmitting the data from the Tag side and for receiving commands from the host. Figure

3.1 explains the communication architecture to facilitate communication between the

communicating devices.

The communication interfaces that are mainly needed to establish communication

between a Tag and a Remote Host (Mobile Device) are Bluetooth and Wi-Fi modules. As the

devices on either side have to communicate using the available and active interfaces on either

side, there is need for implementing the exchange of the protocol i.e., from Bluetooth to Wi-

Fi and Wi-Fi to Bluetooth. This can be achieved by introducing a protocol converter in

between Bluetooth and Wi-Fi interfaces in the communication architecture as shown in the

figure 3.1. Using this Protocol Converter, if the communication interfaces available on the

tag side and mobile device side are Bluetooth and Wi-Fi respectively, then the data needed to

be transmitted to mobile device will be converted from Bluetooth protocol to Wi-Fi protocol

by sending via protocol converter. In this way the conversion of protocol from Wi-Fi to

Bluetooth will be implemented.

Figure 3.1 Communication Architecture of Intelligent Tag Management System

The main issue here in the aspect of Intelligent Tag Management System is providing the

enough intelligence such that the system will be able to detect the presence of any possible

attack on the communication link between a Tag and the Mobile Device. This provision of

intelligence to the system can be achieved by developing Intelligence Module along with

Counter-measure Selector on both tag side and mobile device side. Figure.3.2 shows the

layout of implementing intelligence module and counter-measure selector on either side of

the system.

The functionality of Intelligence Module depicted in the figure.3.2 will be such that it

senses whether there is any possibility of performing any attack on the communication link

between a Tag and the Mobile Device. If it is confirmed then it passes the information about

the type of attack to the Counter-measure Selector. Then depending on the information about

the type of attack, the Counter-measure Selector will implement the appropriate counter

attacking mechanism to the available communication interface so that the communication

link between a Tag and the Mobile Device will be secured. If the Intelligence Module senses

that there is no possibility of attack on the communication link, then the Counter-measure

Selector will be gone to idle state and the communication establishment will be done without

any overhead of the counter attacking mechanism. Figure.3.3 depicts the provision of

intelligence to the system for sensing certain attacks based on specific parameters.

Figure 3.2 Implementation of Intelligence for Securing the Communication between Tag and Mobile Device

The intelligence can be provided to the system by utilizing the Intelligence Module so

that it can sense the possibility of any type of attack on the communication link and informs

the Counter-measure Selector to implement appropriate counter attacking mechanisms. To

perform this, the Intelligence Module is designed to sense the attacking based on certain

parameters.

If the device on either side wants to send / receive data through Object exchange Protocol

(OBEX), then the intelligence module senses the frequency of access to critical data elements

that govern the system. Frequency of accessing the critical data shall be recognized as an

attack and automatically the requirement of authentication shall be implemented.

In the case of device attacking if the intruder tries for a handshake with variable number

of frequencies the attack will be sensed and the counter measure of implementing RF

signatures will be enforced. The device attacking sensor recognizes that an attack is taking

place when frequency parameter is changing quite frequently while trying to establish the

handshake.

When a man in the middle tries to attack after the hand shake between the peer team takes

place, the transmission speeds varies drastically. The man in the middle is sensed while

monitoring the transmission speeds and if the transmission speed varies and differ from the

transmission speed established at the time of handshake an attack is sensed and immediately

the counter attacking mechanism like encryption and decryption shall be implemented in

which case some of the low priority services shall be suspended.

Figure 3.3 Parameters and Appropriate Counter Measures for Ensuring Security

When a communication link is established between two partners of the peer team, and

one partner is transmitting messages of very high speed are when the same message is

transmitted quite frequently, it will be sensed that an attack has been initiated, then a counter

attacking mechanism is effected that terminates the communication Link.

In the case replay attacks, sensing can be implemented by noticing the receipt of identical

responses but with varying speeds in which case session tracking tokens will be implemented.

The mechanism of session tracking will be enforced only when the repay attack is sensed [9].

3.1.4 Conclusions

The devices used in the intelligent TAG systems are limited in the resources. The peer to

peer communication between the TAG and the Mobile device is quite vulnerable. Adding the

entire required infrastructure to the TAG and the mobile device will require many resources

and providing such kind of resources is impracticable. Adding any software load for

implementing the permanent counter attacking measures will drastically effect the response

time and throughput of transacting between the mobile device and the TAG. Intelligence has

to be added for sensing any attack and the counter attacking measure should only come into

force when any of the attacks are initiated. Counter attacking measure should come into force

when an attack is initiated. When counter attacking is implemented the peer to peer

communication method will temporarily be slow down at which some of the un-important

services can be suspended.

3.2 Software Architecture for building intelligence to secure the communication between the Tags and the Mobile devices

3.2.1 Summary of Findings

The communication between a Tag and Mobile Device has to be established using

wireless communication standards like Bluetooth, Wi-Fi etc. As the communication medium

is wireless, there is a scope for the attacker to perform various attacks on the communication

between a Tag and Mobile Device. The authors of this thesis have focused on implementing

an intelligent mechanism to sense whether there is any possibility for attacking the

communication between a Tag and Mobile Device and activate appropriate counter-measures

against that attacks. To implement this proposed sensing and counter attacking mechanisms,

software architecture has been proposed and the same is used for development of the

software. Software has been developed and implemented and the intelligence built has been

tested by setting-up the experimental models. The experimental results have also been

presented in the thesis.

3.2.2 Introduction

The Intelligent Tag Management System involve Tags (as target devices) and Mobile

Devices (as Hosts) being communicated with using different wireless communication

standards like Bluetooth, WI-Fi etc. The security of the data transmission is the major

concern while using wireless medium. The attackers may perform various attacks like eaves

dropping; replay attacks, Man-in-the-Middle attacks etc., and make the operations of the

system affected.

To ensure that data transmission is done securely, several authors had proposed various

security mechanisms which includes authentication protocols, encryption / decryption

mechanisms etc. These mechanisms are acceptable in the context of providing efficient

security to the system. But implementing any of the counter attacking systems, the

performance of the embedded system will severely get affected due the addition of heavy

overhead on the computing requirements.

The literature survey revealed that many of the security enforcements have been proposed

and implemented that counter attack any of the attacking mechanism. All the methods

propose direct implementation of counter attacking system. The counter attacking code is

executed in line with the ES application code thus adding heavy overhead and most of the

times lead to performance bottlenecks. The author of this thesis have proposed a system that

builds intelligence into the applications to be able to sense the attacking and then only

activating appropriate counter attacking mechanism there by reducing overhead due to

implementation of inline security mechanisms.

In this thesis, a Software Architecture has been proposed for implementing the sensing of

attacking mechanisms and then implementing the related counter attacking mechanism. The

software architecture has been used for the development of software that implements the

intelligent security enforcement system. The software has been implemented and experiments

have been conducted and the experimental results have been published. The experimental

results have shown that the sensing and implementing mechanisms have not only provided

adequate security but also resulted in reducing the overhead on computing requirements.

3.2.3 Investigations

The software architecture for implementing security mechanism by building Intelligence

to the tag is shown in figure.3.4 using 3-tier architecture. In tier I all modules related to

intelligent tag application shall be made to be resident. The overall task execution is

implemented within the main control logic which is resident in the tier II. The main task is

designed to incorporate all real time functions using µCos operating system. The software

components through which communication is effected either through Wi-Fi or Bluetooth are

represented as communication module situated in tier II. It can be invoked through the

Controller module. The communication modules related to remote mobile HOST are situated

in tier III. Communication modules which are in tier II and III shall be connected to

Intelligence module and Counter-measure selector module and the counter-measure

implementation module to make the system sense the possibility of attacking and choosing

the appropriate counter-measures. The Intelligence and Counter-measure selector modules

also reside within the tier-II.

Figure.3.4 Software Architecture for Building Intelligence to Secure the Intelligent Tag Management

System

3.2.4 Conclusions

The software architecture for building intelligence to the system for securing the

communication between Host and a Tag has been presented in this thesis. This architecture is

well suited to implement in the embedded systems with security as a major concern. The

software required for the system was designed using the architecture presented in this thesis

and the same has been implemented within the separately designed embedded system.

4. REQUIREMENTS ENGINEERING4.1 Tag Side Requirements Engineering

4.1.1 Overview of the system

Intelligent TAG is an embedded system provided with sensors and logic to sense the

changes taking place in the surrounding environment and inform the changes to a remote

mobile device through a communication interface. The Tag will have inbuilt intelligence to

sense the changes taking place in its environment. For example every time TAG is moved

from one location to the other, the TAG will identify itself with all the mobile devices which

are in its vicinity.

The intelligent TAG will be in communication with remote HOST which is a Mobile

Phone. The mobile device shall have the application components that processes the requests

received from the Intelligent Tags and take the actions necessary either to store the

environment data or make available data to the intelligent TAG for controlling purposes if

any. The Intelligent Tag related application components must be in Co-existence with other

components that are natively situated in the mobile phone.

Figure 4.5 Overview of the Intelligent TAG Application

Figure 4.1 shows an overview of the intelligent TAG application. The intelligent Tag has

the intelligence to communicate with the mobile device based on the existence of the active

and working communication devices on either side of the TAG and the HOST. The

intelligent TAG application will have all the logic to store its own code that can be uniquely

recognized under the influence of noise, interference and various types of attacks. The

intelligent TAG system will implement all those techniques to protect the identification code

of the TAG when it is transmitted to the remote HOST. The intelligent TAG will use variety

of communication interfaces such as Bluetooth and Wi-Fi for establishing the communication

links and use the same for effecting the communication.

4.1.2 Process Flow Modeling

The following figure 4.2 represents the process flow for Security Management on tag

side. The Process flow modeling gives the descriptions of various activities that take place in

the proper functioning of the system.

check for availability of ports from TAG Side

Establish Communication

Select Counter-measure

Dynamic Configuration of available ports

attack detection on communication link

is attack detected?

Implement Counter-measure

Efficient Communication

Yes

No

Start

End

Figure 4.6 Process flow modeling for security management on Tag side

4.1.3 Hardware Requirements

Table 4-3 Hardware Requirements on Tag Side

S.No Hardware Required

1 ARM7 Evaluation Board (LPC2148)

2 Wi-Fi 802.11 B/G/N (UART Interface)

3 Bluetooth (USB Interface)

4 GPS

5 EEPROM (512KB)

4.1.4 Functional requirements

The following are the functional requirements that are to be met for implementing the

intelligent security system with the TAG Management system.

i) Trace the availability of communication ports on the Mobile device side and establish the required communication interfaces through dynamic configuration

ii) Trace the availability of communication ports on the Tag side and establish the required communication interfaces through dynamic configuration

iii) Establish the communication links between the Tag and the mobile device

iv) Initiate the communication.

v) Attack Detector.

This component will sense any of the attack (Blue Snarfing attack, Blue Bugging attack, Man-in-the-Middle attack, Denial of Service attack, Evil Twin Access Point attack, Replay attack) on the communication between the TAG and the Mobile device and then communicate the same to counter attack selector.

vi) Counter-measure Selector.

The Counter-measure Selector will receive the information from the attack detector about the attack being made and then selects appropriate counter attacking system and inform the Counter Attack implementing mechanism

vii)Counter attack implementer.

Suspend the regular code that process the communication and then invoke the code that implements the counter attacking mechanisms by implementing dynamic linking and embedding.

viii) Sense the continuation of the threat and reconfigure the scheduling of the execution of the tasks when the threat is not in existence any more.

4.1.5 Non Functional requirements

1) The average response time for processing any of the external events must be within 3 Mille Seconds.

2) A minimum of 10 Events must be processed within a second.

4.1.6 Tracing the functional requirements through use Cases

The following table 4.2 shows the various use cases involved in processing the functional

requirements of Tag. Study of both the functional and non functional requirements reflects

the initiation of the following use cases.Table 4-4 Functional requirements of Tag through use cases

Serial Number

Use Case Code

Description of the Use Case

Major Events to Handel

1. IDUC01 Communication port availability and Dynamic Configuration (TAG)

Checks the availability of ports on Tag side.

2. IDUC02 Communication port availability and Dynamic Configuration (HOST)

Checks the availability of ports on Host side.

3. IDUC03 Establish Communication

Communication link establishment

4. IDUC04 Communicate Ready to communicate

5. IDUC05 Detect Attacker Checks whether any attacks on the communication link.

6. IDUC06 Set Undetected Communication establishes normally when no attack is detected.

7. IDUC07 Counter-measure Selector

Select appropriate counter-measure for the attack performed.

8. IDUC08 Counter Attack Implementer

Enables appropriate Counter-measure on the communication link.

4.1.7 Tracing the business objects through classes

Analysis of the business process flow reveals that the classes shown in the table 4.3 are

required to realize the use cases.

Table 4-5 Business Objects Through Classes

Serial Number

Class code Description of the Class

1. IDCL01 Main control logic process 2. IDCL02 ARM73. IDCL03 LCD4. IDCL04 LCD process5. IDCL05 LED6. IDCL06 LED process7. IDCL07 Bluetooth8. IDCL08 Mobile Bluetooth9. IDCL09 Wi-Fi10. IDCL10 Mobile Wi-Fi11. IDCL11 Communication Port Availability checker (TAG)12. IDCL12 Communication Port Availability checker (HOST)13. IDCL13 Communication Link Establisher14. IDCL14 Attack Detector15. IDCL15 Counter-measure Selector16. IDCL16 Counter-measure Implementer17. IDCL18 EEPROM18. IDCL19 EEPROM process

4.2 Mobile side Requirements Engineering

4.2.1 Over View of Mobile side Description

Figure 4.7 Overview of the Intelligent TAG Application on Mobile Side

The overview of the application components that reside on the mobile phone are shown in

the figure 4.3. The application resident on the mobile device will be running under the

control Android operating system and will have necessary components that help locating

active communication devices and also help establishing the communication link with the

TAG. The application components should also be able to store the data related to all the Tags

that are established by it. The mobile device shall be built around ARM7 technologies which

provide communication interfaces to communicate with the TAG using both Bluetooth and

Wi-Fi Communication. An EEPROM of size 32GB be provided on the mobile side for

maintain a repository of the valid tags. An USB interface shall be used for migrating code

developed on the PC to the Mobile device as an add-on application.

4.2.2 Process Flow Modeling

The following figure 4.4 represents the process flow modeling for communication system

on mobile side. Process flow modeling gives the descriptions of various activities that take

place in the proper functioning of the system.

Listen to active communication ports

check for active ports from Mobile side

Dynamic Configuration of available ports

Sense for attackingon communication link

establish secured communication

Choose Counter-measure

Establish communication link

Implement Counter-measure

establish communication without counter-measure overhead

If attack sensed?

Yes

No

Start

End

Figure 4.8 Process Flow Modeling for Security Management on Mobile Side

4.2.3 Hardware Requirements

Table 4.4 shows the hardware requirements on mobile side for implementing efficient

security mechanisms by building intelligence to the system. These devices are recognized

based on the Process flow described in the previous sections.

Table 4-6 Hardware Requirements on Mobile Side

Mobile Features

Samsung L9100 GALAXY S2

ARM7 Dual Core 1.2 GHz Cortex A9 Wi-Fi 802.11 A/B/G/N Bluetooth V3.0 Memory up to 32 GB extendable USB

4.2.4 Functional requirements

The following are the typical functions that must be implemented by the mobile software.

a) The Mobile Device checks for availability of the communication ports and makes its devices listen the requests of the Tags.

b) Facilitates the establishment of communication.

c) Performs the checking of communication link to detect any attacks on it.

d) It will make the system to set undetected, if no attack is sensed on the communication link.

e) System will be set to detect and the counter-measure selector will be enabled, if an attack is sensed on the communication link between a Tag and the Mobile Device.

f) The Counter-measure implementer will be enabled to implement the appropriate counter attacking mechanisms.

4.2.5 Non Functional requirements

The communication between the Mobile device and the Tag must take place within 1

second whether Wi-Fi or Bluetooth communication interface is used.

4.2.6 Tracing the functional requirements through use Cases

Study of the process flow and the functional requirements on the mobile side reveal the

requirement of use cases shown in Table 4.5.

Table 4-7 Functional Requirements through Use Cases

Serial Number

Use Case Code

Description of the Use Case Major Events to Handel

1. IDUC01 Port Configuration Checker Internal Trigger.

2. IDUC02 Communication manger Internal Trigger.3. IDUC03 Detect Attack Sensing of attacks on

communication link.4. IDUC04 Counter-measure selector Chooses appropriate counter-

measure on detecting an attack.5. IDUC05 Counter-measure Implementer Enables appropriate counter-

attacking mechanism.

4.2.7 Tracing the business objects through classes

The following Table 4.6 reveals the various classes that are involved in interfacing the

add-on module to already existing applications that are resident on mobile phone which are

developed on pc using android development environment.Table 4-8: Mobile Device Business Objects through Classes

Serial Number

Class code Description of the CLASS

1. IDCL01 ARM 72. IDLC02 MOBILE-Main control logic process3. IDCL03 LCD process4. IDCL04 USB interface5. IDCL05 EEPROM6. IDCL06 Mobile Bluetooth7. IDCL07 Tag Bluetooth8. IDCL08 Mobile Wi-Fi

9. IDCL09 Tag Wi-Fi

10. IDCL10 Physical Communication Manager on mobile side process11. IDCL11 Physical Communication Manager on Tag side process12. IDCL12 Attack Detector process13. IDCL13 Counter-measure Selection process14. IDCL14 Counter-measure Implementation process15. IDCL15 TAG side communicator16. IDCL16 MOBILE side communicator17. IDCL17 LCD18. IDCL18 EEPROM process

5. ANALYSIS5.1 Tag Side Analysis

5.1.1 Hardware Analysis

Table 5.1 shows the hardware analysis of the tag. The table explains device name, type of

device, latency of the device, the ports to which the device is connected, and type of output

from the device.Table 5-9: Hardware Analysis of the Tag

Serial Number of the device

Device Code Type of Device

Latency of the Device

Port to which connected

Description of the device

1 ARM7 - - - Controlling and monitoring

2 BLUETOOTH DOFB 0.020 USB

Communication with remote device using Bluetooth interface

3WI-FI DOFB 0.010 UART0

Communication with remote device using Wi-Fi interface

4 EEPROM DOFB 0.020 I2C For data repository5

LCD DOFB 0.020 GPIOAlerting the system for securing the communication link.

6BUZZER DOFB 0.020 GPIO

Alerting the system for securing the communication link.

5.1.2 Use case Modeling

The uses cases that have been identified during the requirement engineering stage have

been further analyzed to find the functionality of each of the use case. The description of the

use case is shown in the Table 5.2. The inter relationships among use cases has also been

analyzed. The events that trigger the use cases and the flow of execution of the use cases have

been analyzed and the same have been shown in the Figure 5.1.

Table 5-10: Use Case Description

Serial Number

Use Case Code Use case description Preceding usage case

1. IDUC01 Communication ports availability and dynamic configuration (Host)

-

2. IDUC02 Communication ports availability and dynamic configuration (Tag)

-

3. IDUC03 Establish Communication Link -

4. IDUC04 Ready to communicate -

5. IDUC05 Sense any attacks on the Communication link IDUC04

6. IDUC06 Choose appropriate counter-measure IDUC05

7. IDUC07 Implement selected Counter-measure IDUC06

8. IDUC09 Senses no attack IDUC05

Communication ports availability and dynamic configuration (HOST)

HOST

Communication ports availability and dynamic configuration (TAG)

Counter Attack implementor

Establish communication

TAG

Set undetectedCommunicate

Detect Attackar

Undetected

Select Counter Measuer

Detected

Figure 5.9 Use Case Diagram Showing Functional Requirements of Security Management

5.1.3 Business process modeling through HW related class diagram

The security mechanism for developing intelligence into the Tag requires different

hardware modules interfaced with each other. For every hardware component that is directly

connected to the Microcontroller, it can be defined as individual class. Defining the

functionality of each class and relationships among different classes forms the hardware

architecture. The main control logic that drives the application is shown as ARM7 class.

Tag communicates with mobile reader using communication protocols. Communication

protocols classes like Bluetooth class and Wi-Fi class are connected to ARM7 class. Various

Communication protocol classes are used for tracking the devices using a range of

frequencies. Communication protocol classes of the tag such as Bluetooth, Wi-Fi, are

dependent on the communication protocol classes of the mobile device as the application

developed provides the security for the communication between the Host and Intelligent tags.

The communication protocol classes are defined as Bluetooth mobile and Wi-Fi mobile

classes. EEPROM is attached to ARM7 for storing the data of valid mobile devices. Buzzer

and LCD communicate with ARM7 for notifying the status of securing the communication

link. The hardware class diagram of security management is shown in figure 5.2.

Bluetooth (Mobile)

Wi-Fi (Mobile)

Buzzer

EEPROM

Bluetooth (Tag)

Wi-Fi (Tag)

ARM 7

LCD

Figure 5.10 Hardware Class Diagram of Security Management

5.1.4 Business process modeling through SW related Class Diagram

The Intelligent Tag Management System consists of different hardware modules

interfaced with each other. For every hardware module that is directly connected to the

Microcontroller, a software component is created in the ES application which is modeled as a

Class. The each software component related to a hardware device is recognized as a single

class.

The Software Architecture can be defined by using the functions performed by each class

and by establishing the relationships among different classes. The key component that

requires the application to run on the Tag side is shown as Main Logic Controller class. The

Main Logic Controller class is associated with a communication management class. The

communication management looks for readily available communication ports for

communication by writing a polling mechanism through an s/w code written at the controller

side.

To secure the wireless data transmission on either side, an efficient security mechanism is

implemented by developing an application on both Host side and Tag side through attack

detector class. The detector class invokes Counter-measure selector class whenever attacking

of particular types is noticed. The Counter attack implementer class implements the counter

attack method selected by the selector class. If a counter attacking mechanism is selected and

an attack does no more exist the counter attack is reset.

The communication devices are connected to Peripheral IO bus which is responsible for

interfacing external modules like Bluetooth and Wi-Fi. So the peripheral IO communication

manager class maintains information regarding the available active ports connected i.e. mode

of communication for establishing the communication. LCD class is connected to the ARM7

class to display the output to the user. The class diagram that ensures security to the

Intelligent Tag Management System is shown in figure.5.3.

Bluetooth Process (HOST)

Wi-Fi Process (HOST)

Bluetooth Process (TAG)

Wi-Fi Process (TAG)

Attack Persistent Checker

Peripheral communication manager

not detected

Counter Attack Implementor

communication management

Attack Detector

Counter-measure selector

detected

LCD Process

Buzzer Process

Main Logic Controller

EEPROM Process

Figure 5.11 Software Class Diagram of The Security Management

5.1.5 Business process modeling related to interfacing of HW and SW components

The figure 5.4 shows the diagram of interfacing hardware components and software

components on Tag side. All the hardware components integrated on the Tag have a software

code for driving them.

communication management

LCD Process

EEPROM Process

Buzzer ProcessAttack Detector

Counter-measure selector

LCD

EEPROM

Buzzer

Bluetooth Process (TAG)

Bluetooth (Host)

Bluetooth Process (Host)

Wi-Fi (Mobile)

Wi-Fi Process (Host)

Attack Persistent Checker

detected

Counter Attack Implementor

Bluetooth (Tag)

Wi-Fi Process (TAG)

Wi-Fi (Tag)

Peripheral communication manager

not detected

ARM 7Main Logic Controller

Figure 5.12 Class Diagram Interfaces of HW and SW Components on Tag Side

5.2 Mobile Side Analysis

5.2.1 Hardware Analysis

Table 5.3 shows the hardware analysis of the tag. The table explains device name and

description of the device.Table 5-3 Hardware Analysis on Mobile Side

Serial number

Device name description

1 ARM7 Dual Core 1.2 GHz Cortex A9

Controlling and monitoring

2 Wi-Fi 802.11 A/B/G/N

This is meant for communicating the devices using Wi-Fi interface

3 Bluetooth V3.0 This is meant for communicating the devices using Bluetooth interface

4 Memory up to 32 GB extendable

Used for data repository

5 USB Migrating code developed on the PC

5.2.2 Use case Modeling

The uses cases that have been identified during the requirement engineering stage have

been further analyzed to find the functionality of each of the use case. The description of the

use case is shown in the Table 5.4. The inter relationships among use cases have also been

analyzed. The events that trigger the use cases and the flow of execution of the use cases have

been analyzed and the same have been shown in the Figure 5.5.

Checking available active ports

Configure available ports

Establishment of Communication link

Checking available active ports

Tag

Set undetected

Sense for any attacks on communication link

undetected

Choose appropriate Counter-measure

detected

Implement Counter mechanism

Mobile Device

Figure 5.13 Use Case Modeling On Mobile Side

Table 5-4: Description of the Use Case

Serial Number

Use Case Code Use case description Preceding usage case

1. IDUC01 Checking available active ports -

2. IDUC02 Configure available ports -

3. IDUC03 Establish Communication Link -

4. IDUC04 Attack Detector IDUC03

5. IDUC05 Counter-measure Selector (if detected) IDUC04

6. IDUC06 Counter-measure Implementer IDUC05

7. IDUC07 Set Undetected (if no attack) IDUC04

5.2.3 Business process modeling through HW related class diagram

The security management of the Intelligent Tag Management System developed on

mobile side consists of different hardware modules interfaced with each other. For every

hardware module that is directly connected to the Micro controller, each hardware component

can be defined as individual class. Defining the functionality of each class and relationships

among different classes forms the hardware architecture. The main control logic that drives

the application is shown as ARM7 class.

Mobile device communicates with Tag using communication protocols. Communication

protocols classes like Bluetooth class and Wi-Fi class are connected to ARM7 class. Various

Communication protocol classes are used for tracking the devices using a range of

frequencies. All the communication protocols of the mobile device are connected to ARM7.

USB class is defined separately which is used for dumping the code developed on PC to

mobile. EEPROM is defined as separate class in which the data repository of the related

TAG’s information is stored. The hardware class diagram for security management on the

mobile side is shown in figure 5.6.

Bluetooth (Tag)

Wi-Fi (Tag)

Bluetooth (Mobile)

Wi-Fi (Mobile)

EEPROM

USB Interface

ARM 7 (Mobile)

Figure 5.14 Hardware Class Diagram for Security Management on Mobile Side

5.2.4 Business process modeling through SW related Class Diagram

The security management for the Intelligent Tag development consists of different

hardware modules interfaced with each other. For every Hardware module that is directly

connected to the Microcontroller, a Software component exists. The software component

related to a hardware device is recognized as a single class. Defining the functionality of each

class and relationships among different classes forms the software architecture. The main

control logic that drives the application is shown as ARM7 class. The Mobile Side

Communication Manager class is defined to configure the required active communication

ports. USB class is defined separately to show that the software code for securing the

communication link is developed on PC and dumped into the Mobile. EEPROM is defined as

separate class to show that a data repository is used for storing the Tag related information.

Attack Detector process is defined to sense whether there is any notice of attack on the

communication link between a Tag and the Mobile Device. If any attack is sensed, then

counter-measure selector class, defined below, chooses the appropriate counter attacking

mechanism depending upon the protocol and type of attack sensed. Then the Counter-

measure Implementer enables the specified counter attacking mechanism and it is processed

by the Communication manager class which is defined as the software class dependent on the

Tag side communication manager. The class diagram of security management is shown in

figure 5.7.

Bluetooth process (Tag)

Wi-Fi process (Tag)

USB process EEPROM process

Counter-measure Selector

Main Logic Controller (Mobile)

Attack Detector

Attack DetectedMobile Bluetooth

process

Mobile Wi-Fi process

Mobile Side Communication Manager

No attack detected

Counter-measure Implementer

Figure 5.15 Software Class Diagram of Security management on Mobile Side

5.2.5 Business process modeling related to interfacing of HW and SW components

Figure 5.8 shows the interfacing of hardware components and software components on

mobile side. All the hardware components integrated on the Tag have a software code for

driving them.

Counter-measure Selector

EEPROM EEPROM process

USB Interface USB process

Attack Detector

Attack Detected

Bluetooth (Mobile)

Mobile Bluetooth process

Bluetooth Process(Tag)

Bluetooth (Tag)

Wi-Fi (Mobile)

Wi-Fi Process(Tag)

Wi-Fi (Tag)

Mobile Wi-Fi process

Counter-measure Implementer

Mobile Side Communication Manager

No Attack

ARM 7 (Mobile) Main Logic Controller (Mobile)

Figure 5.16 Class Diagram Interfaces HW and SW Components on Mobile Device Side

6. DESIGN6.1 Tag Side Design

The Tag side HW design related to Intelligent TAG system is shown in figure 6.1.

Figure 6.17: Tag Side Design Diagram

The total HW details includes the details of the ARM7 controller, the devices that are

connected on to the same board on which the ARM7 controller is situated and the peripheral

devices which are outside the controller board connected the ARM7 controller through its

internal devices

6.1.1 Hardware Design

6.1.1.1 Block Diagram

The interconnection between hardware devices forms the hardware design related to

intelligent tag identification system. Figure.6.2 shows the interconnection diagram. ARM 7

acts as main controller to which most of the devices are interfaced directly through various

busses. To the AHP Bus which is a main bus, VLSI Peripheral bus and Local bus are

connected. To the VLSI bus, GPIO bus and I2C bus are connected. All the devices are

connected to one of the busses mentioned above.

External memory which is EEPROM is connected Via I2C Bus. The communication

modules namely Bluetooth and Wi-Fi are used for establishing communication on both sides.

The Bluetooth module is connected through USB (Universal serial bus) to the microcontroller

through VLSI bus. Similarly the Wi-Fi is connected to the microcontroller through UART01

and VLSI bus. LCD, Keypad, and reset gate are connected to the Micro controller through

GPIO and VLSI Bus. LCD is used for displaying the environmental changes taking place in

and around the intelligent TAG with the mobile phone.

The Intelligent Tag System uses LPC22148, a 16/32-bit RISC microprocessor that is the

product of PHILIPS Co. Ltd. An outstanding feature of this is its CPU core, a 16/32-bit

ARM7TDMI RISC processor designed by advanced RISC machines Ltd. Hence it has low

power consumption, high instruction throughput and an excellent real-time interrupt

response. In addition, it has rich on-chip integrated functions such as watchdog timer, real-

time clock and so on. All these, facilitates the hardware and software designing of the

intelligent device. Because the processor uses a pipeline to increase the speed of the flow of

instructions, it allows several operations to take place simultaneously and the processing and

memory systems to operate continuously. Thus the intelligent device based on the ARM

processor can deal with much more complicated tasks that cannot be solved by most

conventional lower MCU.

The microcontroller is loaded with ES application such that it provides an efficient

security mechanism by building intelligence into the system. With this application, the

system will be able to sense whether there is any scope of attacking the communication

between Host and a Tag. Then depending on the type of attack, appropriate counter-measures

will be enabled using that application. The architecture of the Intelligent Tag Management

System based on the LPC22148 microprocessor is as shown in the figure.6.2.

Figure 6.18 Hardware Block diagram of Intelligent Tag

6.1.1.2 Object Modeling

The classes that encapsulates the specification of each the Hardware and the distinct

functions performed by every hardware device are recognized based the types of processing

to be done by each of the device and also considering the signals that flows across the

hardware devices through interfacing. The Figure 6.3 shows class diagram that is flushed

with details of the properties and the functions that each of the hardware devices performs.

ARM7nameoscillating frequency

main()memory management()interrupt handling()

communication management

active nodeactive port

bluetooth transmit()bluetooth receive()wi-fi transmit()wi-fi receive()

Bluetooth (HOST)Host Id

Activate()receive()transmit()deactivate()

Wi-Fi (HOST)nameHost address

Turn ON()search()connect()transmit()receive()Turn OFF()

Attack Detector

OBEX sensor()variable frequency sensor()MITM attack sensor()replay attack sensor()

Bluetooth (TAG)Tag Idtransmitting frequency

Power ON()Power OFF()Reset()receive message()transmit message()

Wi-Fi (TAG)nameaddresstransmitting frequency

reset()Turn ON()intialize transmit()transmit()receive()Turn OFF()

Attack Persistent Checker

Senses occurance of attack()

Counter-measure selector

authentication()RF signatures()encryption/decryption()session tokens()

detected

Peripheral communication manager

bluetooth communication through USB()wi-fi comunication through UART()

not detected

Counter Attack Implementor

invoke counter attacking mechanism()

Figure 6.19 Object Modeling Diagram of Tag Design

6.1.1.3 Design of Hardware Elements

A. Design of the ARM7 Controller

The LPC2148 microcontroller is based on a 16-bit/32-bit ARM7TDMIS CPU with real-

time emulation and embedded trace support, that combine microcontroller with embedded

high speed flash memory ranging from 32 kB to 512 kB. A 128-bit wide memory interface

and unique accelerator architecture enable 32-bit code execution at the maximum clock rate.

For critical code size applications, the alternative 16-bit Thumb mode reduces code by more

than 30 % with minimal performance penalty.

Due to their tiny size and low power consumption, LPC2148 are ideal for applications

where miniaturization is a key requirement, such as access control and point-of-sale. Serial

communications interfaces ranging from a USB 2.0 Full-speed device, multiple UARTs, SPI,

SSP to I2C-bus and on-chip SRAM of 8 kB up to 40 kB, make these devices very well suited

for communication gateways and protocol converters, soft modems, voice recognition and

low end imaging, providing both large buffer size and high processing power. Various 32-bit

timers, single or dual 10-bit ADC(s), 10-bit DAC, PWM channels and 45 fast GPIO lines

with up to nine edge or level sensitive external interrupt pins make these microcontrollers

suitable for industrial control and medical systems. Figure 6.4 shows Pin diagram of ARM

controller.

Features

16-bit/32-bit ARM7TDMI-S microcontroller in a tiny LQFP64 package.

8kB to 40 kB of on-chip static RAM and 32 kB to 512 kB of on-chip flash memory.

128-bit wide interface/accelerator enables high-speed 60 MHz operation.

In-System Programming/In-Application Programming (ISP/IAP) via on-chip boot loader

Software. Single flash sector or full chip erase in 400 ms and programming of 256 bytes in 1 ms.

Embedded ICE RT and Embedded Trace interfaces offer real-time debugging with the

on-chip Real Monitor software and high-speed tracing of instruction execution.

USB 2.0 Full-speed compliant device controller with 2 kB of endpoint RAM.

In addition, the LPC2146/48 provides 8 kB of on-chip RAM accessible to USB by DMA.

One or two (LPC2141/42 vs. LPC2144/46/48) 10-bit ADCs provide a total of 6/14

Single 10-bit DAC provides variable analog output (LPC2142/44/46/48 only).

Two 32-bit timers/external event counters (with four capture and four compare Channels each), PWM unit (six outputs) and watchdog.

Low power Real-Time Clock (RTC) with independent power and 32 kHz clock input.

Multiple serial interfaces including two UARTs (16C550), two Fast I2C-bus (400 kbit/s),

Up to 45 of 5 V tolerant fast general purpose I/O pins in a tiny LQFP64 package.

Up to 21 external interrupt pins available.

On-chip integrated oscillator operates with an external crystal from 1 MHz to 25 MHz.

Individual enable/disable of peripheral functions as well as peripheral clock scaling for additional power optimization.

Processor wake-up from Power-down mode via external interrupt or BOD.

Single power supply chip with POR and BOD circuits.

PIN Diagram

Figure 6.20: Pin Diagram of ARM Controller

Timing diagram

Figure 6.5 shows general timing diagram. Diagram shows nWAIT and ALE are both

HIGH during the cycle. Figure 6.6 shows the address timings of ARM7 controller.

Figure 6.21: General Timing Diagram

nWAIT and ALE are both HIGH during the cycle shown.

Figure 6.22: Address Timings

Figure 6.23: Data Write Cycles

Tald is the time by which ALE must be driven LOW in order to latch the current address

in phase. If ALE is driven low after Tald, then a new address will be latched. Figure 6.7

shows data write cycles. Diagram shows DBE is high during the cycle. Figure 6.8 shows

data read cycles.

Figure 6.24: Data Read Cycles; DBE Is High During the Cycle Shown

Figure 6.25: Data Bus Control

Figure 6.9 shows data bus control. The cycle shown is a data write cycle since nENOUT

was driven low during phase 1. Here, DBE has been used to modify the behavior of Nenout.

Figure 6.10 shows configuration diagram. Figure 6.11 shows Exception timing.

Figure 6.26: Configuration Diagram

Figure 6.27: Exception Timing

Tirs guarantees recognition of the interrupt (or reset) source by the corresponding clock

edge. Tirm guarantees non-recognition by that clock edge. These inputs may be applied fully

asynchronously where the exact cycle of recognition is unimportant.

Figure 6.28: Clock Timing of ARM7

Figure 6.12 shows clock timing of ARM 7. The ARM core is not clocked by the HIGH

phase of MCLK enveloped by nWAIT. Thus, during the cycles shown, nMREQ and SEQ

change once, during the first LOW phase of MCLK, and A[31:0]change once, during the

second HIGH phase of MCLK. For reference, ph2 is shown. This is the internal clock from

which the core times all its activity. This signal is included to show how the high phase of the

external MCLK has been removed from the internal core clock.

B. Design of the devices that are on the ARM 7 control board

The main controller device which is ARM 7 has been fitted with many of the devices that

include UART, EEPROM, I2C Port, USB Port, A/D Converter, LCD, Buzzer, 4x4 Keyboard,

and LED. These ports are connected to a BUS architecture that includes various buses such as

AHP Bus, GPIO Bus. The details of these devices which are on the ARM 7 Controller board

are provided below:

a) UART

UART (universal asynchronous receiver/transmitter) is an integrated circuit designed for

implementing the interface for serial communications. A UART includes a transmitter and a

receiver. The transmitter is essentially a special shift register that loads data in parallel and

then shifts it out bit by bit at a specific rate. The receiver, on the other hand, shifts in data bit

by bit and then reassembles the data. In intelligent tag on board circuit consists of 2 UART

ports used for interfacing Wi-Fi and GPS modules. Figure 6.13 shows UART interfacing pin

out diagram.

Figure 6.29: UART Interfacing Pin out Diagram

Features 16 byte Receive and Transmit FIFOs

Register locations conform to ‘550 industry standard.

Receiver FIFO triggers points at 1, 4, 8, and 14 bytes.

Built-in fractional baud rate generator with auto bauding capabilities.

Mechanism that enables software and hardware flow control implementation.

Timing Diagram

Figure 6.14 shows the timing diagram of UART.

Figure 6.30: Timing Diagram of UART

b) EEPROM

EEPROM stands for Electrically Erasable Programmable Read-Only Memory and is a

type of non-volatile memory used in computers and other electronic devices. There are

different types of electrical interfaces to EEPROM devices. Main categories of these interface

types are: serial bus, parallel bus. Most common serial interface types are SPI, I2C, Micro

wire, UNI/O, and 1-Wire. These interfaces require between 1 and 4 control signals for

operation, resulting in a memory device in an 8 pin package. The serial EEPROM typically

operates in three phases: OP-Code Phase, Address Phase and Data Phase.

In ARM LPC2148 AT24C01A/02/04/08/16 provides 1024/2048/4096/8192/16384 bit of

serial electrically erasable and programmable read only memory (EEPROM) organized as

128/256/512/1024/2048 word of 8 bit each. Figure 6.15 shows pin diagram of EEPROM.

Figure 6.31: Pin Diagram of EEPROM

Features

Internally organized 128x8(1K), 256x8(2K), 512x8(4K)

2-wire serial interface

Bi directional data transfer protocol

100 KHz (1.8V, 2.5V, 2.7V) and 400 KHz (5V) compatibility

Write protect pin for hardware data protection

c) I2C

The LPC2148 each contain two I2C-bus controllers. The I2C-bus is bidirectional, for

inter-IC control using only two wires: a Serial Clock Line (SCL) and a Serial Data line

(SDA). Each device is recognized by a unique address and can operate as either a receiver-

only device. Transmitters and/or receivers can operate in either master or slave mode,

depending on whether the chip has to initiate a data transfer or is only addressed. The I2C-

bus is a multi-master bus, it can be controlled by more than one bus master connected to it.

The I2C-bus implemented in LPC2148 supports bit rates up to 400 kbps. Figure 6.16 shows

I2C protocol IC for interfacing EEPROM. In intelligent tag ARM board, one I2C is used for

interface EEPROM to LPC2148 using serial data SDA and serial clock SCK lines.

Figure 6.32: I2C Protocol IC for Interfacing EEPROM

Features

Standard I2C compliant bus interfaces that may be configured as Master, Slave, or Master/Slave.

Arbitration between simultaneously transmitting masters without corruption of serial data on the bus.

Programmable clock to allow adjustment of I2C transfer rates.

Bidirectional data transfer between masters and slaves.

Serial clock synchronization allows devices with different bit rates to communicate via one serial bus.

Serial clock synchronization can be used as a handshake mechanism to suspend and resume serial transfer.

The I2C-bus may be used for test and diagnostic purposes.

Timing Diagram

Figure 6.17 shows timing diagram for I2C

Figure 6.33: Timing Diagram for I2C

d) ADC

An ADC is an electronic device that converts an input analog voltage or current to a

digital number proportional to the magnitude of the voltage or current. In ARM LPC2148 on

chip ADC basic clocking is provided by the VPB clock. A programmable divider is included

in each converter, to scale this clock to the 4.5 MHz (max) clock needed by the successive

approximation process. A fully accurate conversion requires 11 of these clocks. While the

ADC pins are specified as 5 V tolerant the analog multiplexing in the ADC block is not.

More than 3.3 V (VDDA) +10 % should not be applied to any pin that is selected as an ADC

input, or the ADC reading will be incorrect. By using this ADC pressure sensor is interface to

LPC2148.

Features

10 bit successive approximation analog to digital converter (one in LPC2141/2 and two in LPC2144/6/8).

Input multiplexing among 6 or 8 pins (ADC0 and ADC1).

Power-down mode.

Measurement range 0 V to VREF

Burst conversion mode for single or multiple inputs.

Optional conversion on transition on input pin or Timer Match signal.

Global Start command for both converters (LPC2144/6/8 only).

Backward compatibility with other earlier devices is maintained with legacy registers appearing at the original addresses on the VPB bus

e) LEDs

Light emitting diodes (LEDs) the most commonly used components, usually for

displaying pin’s digital states. The ARN214X has 8 numbers of point LEDs, connected with

port pins (P1.16-P1.23), to make port pins high LED will glow.

In intelligent tag LEDs are used for multiple purposes like low battery indication, alerting

system, tamper proofing system, location identification system and communication failure

indication etc.

f) USB Controller

The USB is a 4 wire bus that supports communication between a host and a number (127

max.) of peripherals. The host controller allocates the USB bandwidth to attached devices

through a token based protocol. This bus support hot plugging, un-plugging and dynamic

configuration of the devices. All transactions are initiated by the host controller. The device

controller enables 12 Mb/s data exchange with a USB host controller. Figure 6.18 shows

USB interface.

Figure 6.34: USB Interface

Features

Fully compliant with USB 2.0 Full Speed specification

Supports 32 physical (16 logical) endpoints

Supports Control, Bulk, Interrupt and Isochronous endpoints

Endpoint Maximum packet size selection by software at run time

RAM message buffer size based on endpoint realization and maximum packet size

Supports bus-powered capability with low suspend current

Support DMA transfer with the DMA RAM of 8 kB on all non-control endpoints (LPC2146/8 only)

One Duplex DMA channel serves all endpoints (LPC2146/8 only)

Allows dynamic switching between CPU controlled and DMA modes (available on LPC2146/8 only)

Double buffer implementation for Bulk & Isochronous endpoints.

g) LCD 2x16 in 4-BIT MODE

The ARM214X kit, have 2x16 character LCD. 7pins are needed to create 4-bit interface;

4data bits (P0.19-P0.22, D4-D7), address bits (RS-P0.16), read/write bit(R/W-P0.17) and

control signal (E-P0.18). The LCD controller is a standard KS0070B or equivalent, which is a

very well known interface for smaller character based LCDs. The LCD is powered from the

5Vpower supply enabled by switch SW28. In intelligent tag application LCD used for

displaying the location of the object, displaying message during alert conditions and power

save modes. Figure 6.19 shows LCD 2x16 with its pin description.

Figure 6.35: LCD 2x16 with Its Pin Description

Timing Diagram:

Figure 6.20 shows timing diagram of LCD.

Figure 6.36: Timing Diagram of LCD

h) 4X4 Matrix Keypad

Keypads arranged by matrix format, each row and column section pulled by high or low

by selection J5, all row lines (P1.24-P1.27) and column lines (P1.28-P1.31) connected

directly by the port pins. Figure 6.21 shows 4X4 matrix keypad.

Figure 6.37: 4X4 Matrix Keypad

Timing Diagram:

Figure 6.22 shows the timing diagram of matrix keypad.

Figure 6.38: Shows the Timing Diagram of Matrix Keypad

i) Buzzer

A small piezoelectric buzzer on the ARM214X kit, by pulling pin P0.7 low, current will

flow through buzzer and relatively sharp, single tone frequency will be heard. The alternative

PWM features of pin P0.7 can be used to modulate the buzzer to oscillate around different

frequencies. It’s not the pulse width feature that is used to change the frequency. Only the

volume of the sound will be changed by alerting the pulse width. The buzzer can be

disconnected by removing jumper JP1, and this is also the default position for this jumper

since the buzzer sound can be quite annoying if always left on.

In intelligent tag buzzer plays a major role in many cases like when the power goes down,

communication failure between tags and mobile, tampering occurs, for locating the tag from

remote host.

j) GPIO

Features

Every physical GPIO port is accessible via either the group of registers providing an enhanced features and accelerated port access or the legacy group of registers

Accelerated GPIO functions:

GPIO registers are relocated to the ARM local bus so that the fastest possible I/O timing can be achieved, mask registers allow treating sets of port bits as a group, leaving other bits unchanged, all registers are byte and half-word addressable, Entire port value can be written in one instruction

Bit-level set and clear registers allow a single instruction set or clear of any number of bits in one port

Direction control of individual bits

All I/O default to inputs after reset

k) Fast GPIO

Device pins that are not connected to a specific peripheral function are controlled by the

GPIO registers. Pins may be dynamically configured as inputs or outputs. Separate registers

allow setting or clearing any number of outputs simultaneously. The value of the output

register may be read back, as well as the current state of the port pins.

Features

Bit-level set and clear registers allow a single instruction set or clear of any number of bits in one port.

Direction control of individual bits.

Separate control of output set and clear.

All I/O default to inputs after reset.

l) Advanced High Performance Bus (AHB)

A simple transaction on the AHB consists of an address phase and a subsequent data

phase (without wait states: only two bus-cycles). Access to the target device is controlled

through a multiplexer (non-tristate), thereby admitting bus-access to one bus-master at a time.

Features

Single edge clock protocol

Split transactions

Several bus masters

Burst transfers

Pipelined operations

Single-cycle bus master handover

Non-tristate implementation

Large bus-widths (64/128 bit).

m) Power Supply

The external power can be Ac or DC, with a voltage between (9V/12V, 1A output) at

230V AC input. The ARM board produces +5V using an LM7805 voltage regulator, which

provides supply to the peripherals. LM1117 fixed +3.3V positive regulator used for processor

and processor related peripherals. USB socket meant for power supply and USB

communication, user can select either USB or Ext power supply through JP14. Separate

on/off switch (SW24) for controlling power to the board. Figure 6.23 shows Power supply

circuit.

Figure 6.39: Power Supply Circuit

n) Power on Reset

A power on reset (PoR) generator is a microcontroller or microprocessor peripheral that

generates a reset signal when power is applied to the device. It ensures that the device starts

operating in a known state.

C. Design of the peripheral devices connected to ARM 7 controller

Many of the peripheral devices are connected to the ARM7 main Controller to realize the

functional requirements related to the Intelligent Identification management system.

Following are the design details of the peripheral devices connected to the ARM7 controller.

i. Bluetooth (Promi ESD-02 )

Parani-ESD Series is OEM Bluetooth-Serial Module type product line based on Bluetooth

technology. Parani-ESD Series is designed for integration into user devices by on-board

installation. They are connected to the device via built-in UART interface and communicate

with other Bluetooth device. Parani-ESD Series enables RS232-based serial devices to

communicate wirelessly throughout the range of 30m~300m(Parani-ESD210-Class 2) or

100m~1000m(Parani-ESD110-Class 1).

Parani-ESD100/200 has a built-in on-board antenna. Users may configure the Parani-ESD

Series by using easy-to-use Windows-based utility software or by using standard AT

command set. Promi-ESD-02 is a board type of Promi-SD™, Class 2 OEM version, which

can be embedded in your applications such as mobile terminals or any kinds of machines for

Wireless serial communications of long range, easy-to-install, and low-cost. Provided is

point-to-point wireless connection without standard RS232 cables. Figure 6.24 shows

Bluetooth module interfaced with UART. Figure 6.25 shows Bluetooth module interfaced

with LPC2148.

Bluetooth Diagram

Bluetooth Features

Figure 6.40: Bluetooth Module UART Interfaced

Output Interface UART, Compliant Bluetooth stack v1.2-improved AFH (Adaptive

Frequency Hopping), Fast connection Transmit Power, ESD100/110: Max. +18dBm,

ESD200/210: Max. +4dBm Receiving Sensitivity, ESD100/110: -88dBm (0.1%BER),

ESD200/210: -80dBm (0.1%BER)

Antenna gain Chip : 0dBi, Stub : +2dBi, Dipole : +3dBi, Patch : +9dBi

Provides transparent RS232 serial cable replacement.

Supports Bluetooth Serial Port Profile.

Interoperability with PDA, laptops etc.

Built-in chip antenna included

Supports firmware upgrade via windows-based software (Parani Updater)

Working distance(In an open field)

Parani-ESD100 : Class 1, Nom. 100 meters

Parani-ESD200 : Class 2, Nom. 30meters

Figure 6.41: Bluetooth Module Interfaced With LPC2148

ii. XBEE WI-FI Module

The XBee/XBee-PRO ZNet 2.5 OEM (formerly known as Series 2 and Series 2 PRO) RF

Modules were engineered to operate within the ZigBee protocol and support the unique needs

of low-cost, low-power wireless sensor networks. The modules require minimal power and

provide reliable delivery of data between remote devices. The modules operate within the

ISM 2.4 GHz frequency band and are compatible with the following. Figure 6.26 shows

XBEE Wi-Fi module.

Figure 6.42: Xbee Wi-Fi Module

Features

Bluetooth Ver. 2.0+ EDR certification

Transmit Power up to +18dBm (class1)

Low current consumption:

Hold, Sniff, Park, Deep sleep mode

3.0V to 3.6V operation

Full Bluetooth Data rate over UART and USB

Support up to 7 ACL links and 3 SCO links

Enhanced Data Rate (EDR) compliant

For both 2Mbps and 3Mbps modulation modes

Interface: USB, UART&PCM (for voice codec)

SPP pro_le comes as standard,

HSP/HFP, HID, DUN pro_les are available

Support for 802.11 Co - Existence

RoHS Compliant

Small outline: 30mm x 27mmX 2.8 mm.

6.2 Software Design

6.2.1 Objects Modeling

The business objects identified at the analysis stage have further been designed by

flushing the attributes and behavior of the objects through member functions. Figure 6.27

shows the interaction between the software objects. The functions of the objects have been

realized based on the responsibilities that the objects must meet. The analysis of use cases

also revealed the necessity of the objects and the functions that must be supported by them.

Main Logic Controller

main()memory management()interrupt handling()

communication management

bluetooth transmit()bluetooth receive()wi-fi transmit()wi-fi receive()

Bluetooth (HOST)

Activate()receive()transmit()deactivate()

Wi-Fi (HOST)

Turn ON()search()connect()transmit()receive()Turn OFF()

Attack Detector

OBEX sensor()variable frequency sensor()MITM attack sensor()replay attack sensor()

Bluetooth (TAG)

Power ON()Power OFF()Reset()receive message()transmit message()

Wi-Fi (TAG)

reset()Turn ON()intialize transmit()transmit()receive()Turn OFF()

Attack Persistent Checker

Senses occurance of attack()

Counter-measure selector

authentication()RF signatures()encryption/decryption()session tokens()

detected

Peripheral communication manager

bluetooth communication through USB()wi-fi comunication through UART()

not detected

Counter Attack Implementor

invoke counter attacking mechanism()

Figure 6.43 Software Objects Interaction on the TAG Side

6.2.2 Integration design

The Hardware objects and software objects interact with each other for realizing the use

cases. The interaction between the HW objects and SW objects on the TAG side is shown in

Figure 6.29. The functions recognized for HW objects are the internal processing undertaken

within the projects. All the software components are resident within the micro controller and

some of the components of the software have been built with all the processing required to

drive the hardware devices connected to the micro controller. Some of the software

components have been identified for processing self triggered events.

Bluetooth (Mobile)Mobile_ID

Activate()Search()Read Message()Write Message()Accept()

EEPROM Process

Select Data()Process Data()

LCD ProcessRSRWEnable

LCD_data()LCD_cmd()

Wi-Fi (Mobile)AddressNameSignal Strength

Active()Search()Connect()Transmit()Receive()

Counter-measure Selector

Authentication()RF signature()Encryption/Decryption()Session Tokens()

Attack Detector

OBEX sensor()Replay sensor()Variable frequency sensor()MITM sensor()

Attack Detected

Counter-measure Implementer

Invoke Counter-attacking mechanism()

Main Logic ControllernameOperating frequency

Main()Interrupt Handling()Memory Management()Alerting System()

LCDEnableRegister SelectWrite

Data()Command()

EEPROM

Store Data()

BluetoothTag_ID

Power ON()Reset()Transmit()Receive()Initialize Transmit()

Tag Side Communication Manager

Establish Communication with Mobile()

no attack

Wi-FiAddressname

Activate()Transmit()Receive()

ARM7nameOperating Frequency

Power management()Interrupt Handling()Memory Management()

Figure 6.44 Interaction between the HW Objects and SW Objects on the TAG Side

7. Implementation7.1 Client side code

The code used for the implementation on tag side is written in Embedded C. The code is

as follows:

#include <LPC214x.H>

#define RS 0x10000

#define RW 0x20000s

#define EN 0x40000

#define CR 0x0D

unsigned char msg[] = {"requesting data "}; //msg

//unsigned char msg2[];

unsigned char msg1[]= {"requesting data x "};

void Serial_Init(void);

unsigned int Receive(void);

void LCD_init4(void);

void LCD_cmd4(unsigned long int);

void LCD_dat4(unsigned char);

void LCD_puts(unsigned char *);

void DelayMs(unsigned int);

int putchar(int);

unsigned long int DATA;

unsigned char Chr,i=0;

void main()

{

DelayMs(10);

Serial_Init();

LCD_init4();

DelayMs(100);

LCD_cmd4(0x80);

LCD_puts(msg);

LCD_cmd4(0xc0);

LCD_puts(msg);

While (1)

{

Chr=Receive();

Switch (Chr)

{

case 0x33: IOSET0 |= 0x0080; break;/* buzzer on-from mobile press 3*/

case 0x34: IOCLR0 |= 0x0080; break; /* buzzer off-from mobile press 4*/

}

i=0;

Chr = msg1[i];

While (Chr != 'x')

{

putchar (Chr);

i++;

Chr = msg1[i];

}

i=0;

Chr = msg1[i];

While (Chr != 'x')

{

putchar (Chr);

i++;

Chr = msg1[i];

}

i=0;

Chr = msg1[i];

while(Chr != 'x')

{

putchar (Chr);

i++;

Chr = msg1[i];

}

i=0;

Chr = msg1[i];

while(Chr != 'x')

{

putchar (Chr);

i++;

Chr = msg1[i];

}

i=0;

Chr = msg1[i];

while(Chr != 'x')

{

putchar (Chr);

i++;

Chr = msg1[i];

}

i=0;

Chr = msg1[i];

while(Chr != 'x')

{

putchar (Chr);

i++;

Chr = msg1[i];

}

i=0;

Chr = msg1[i];

while(Chr != 'x')

{

putchar (Chr);

i++;

Chr = msg1[i];

}

/* i=0;

Chr = msg3[i];

while(Chr != 'x')

{

putchar (Chr);

i++;

Chr = msg3[i];

}*/

}

}

void Serial_Init(void)

{

PINSEL0 | = 0X00000005; //Enable Txd0 and Rxd0

U0LCR = 0x00000083; //8-bit data, no parity, 1-stop bit

U0DLL = 0x00000061; // for Baud rate=9600,DLL=82

U0LCR = 0x00000003; //DLAB = 0;

}

unsigned int Receive(void) /* Read character from Serial Port */

{

while (!(U0LSR & 0x01));

return (U0RBR);

}

void LCD_init4(void)

{

IO0DIR = 0xFFFFFFFF;

LCD_cmd4(0x33);

LCD_cmd4(0x22);

LCD_cmd4(0x22);

LCD_cmd4(0x22);

LCD_cmd4(0x28);

LCD_cmd4(0x06);

LCD_cmd4(0x0c);

LCD_cmd4(0x01);

}

void LCD_cmd4(unsigned long int cmd)

{

DATA = ((cmd<<15) & 0x00780000);

IOCLR0 = ((DATA^0xFFFFFFFF)& 0x00780000) | RS | RW;

IOSET0 = DATA | EN;

IOCLR0 | = EN;

DATA = ((cmd<<19) & 0x00780000);

IOCLR0 = ((DATA^0xFFFFFFFF)& 0x00780000) | RS | RW;

IOSET0 = DATA | EN;

IOCLR0 | = EN;

DelayMs(3);

}

void LCD_dat4(unsigned char byte)

{

DATA = ((byte<<15) & 0x00780000);

IOCLR0 = ((DATA^0xFFFFFFFF)& 0x00780000) | RW;

IOSET0 = DATA | RS | EN;

IOCLR0 | = EN;

DATA = ((byte<<19) & 0x00780000);

IOCLR0 = ((DATA^0xFFFFFFFF)& 0x00780000) | RW;

IOSET0 = DATA | RS | EN;

IOCLR0 | = EN;

DelayMs(3);

}

void LCD_puts(unsigned char *string)

{

while(*string)

LCD_dat4(*string++);

}

void DelayMs(unsigned int Ms)

{

int delay_cnst;

while(Ms>0)

{

Ms--;

for(delay_cnst = 0;delay_cnst <220;delay_cnst++);

}

}

int putchar (int ch) /* Write character to Serial Port */

{

if (ch == 'x')

{

while (!(U0LSR & 0x20));

U0THR = CR; /* output CR */

}

while (!(U0LSR & 0x20));

return (U0THR = ch);

}

7.2 Mobile side Code

The code used for the implementation on mobile side is written in Java. The code is as

follows:

Bluetooth Share

package com.ram.tag;

import android.provider.BaseColumns;

import android.net.Uri;

/** Exposes constants used to interact with the Bluetooth Share manager's content provider.

*/

public final class BluetoothShare implements BaseColumns{

private BluetoothShare(){

}

/** The permission to access the Bluetooth Share Manager */

public static final String PERMISSION_ACCESS =

"android.permission.ACCESS_BLUETOOTH_SHARE";

/** The content:// URI for the data table in the provider */

public static final Uri CONTENT_URI =

Uri.parse("content://com.android.bluetooth.opp/btopp");

/** Broadcast Action: this is sent by the Bluetooth Share component to transfer complete.

The request detail could be retrieved by app as _ID is specified in the intent's data. */

public static final String TRANSFER_COMPLETED_ACTION =

"android.btopp.intent.action.TRANSFER_COMPLETE";

/** This is sent by the Bluetooth Share component to indicate there is an incoming file need

user to confirm. */

public static final String

INCOMING_FILE_CONFIRMATION_REQUEST_ACTION =

"android.btopp.intent.action.INCOMING_FILE_NOTIFICATION";

/** This is sent by the Bluetooth Share component to indicate there is an incoming file

request timeout and need update UI. */

public static final String USER_CONFIRMATION_TIMEOUT_ACTION =

"android.btopp.intent.action.USER_CONFIRMATION_TIMEOUT";

/** The name of the column containing the URI of the file being sent/received. */

public static final String URI = "uri";

/** The name of the column containing the filename that the incoming file request

recommends. When possible, the Bluetooth Share manager will attempt to use this filename,

or a variation, as the actual name for the file. */

public static final String FILENAME_HINT = "hint";

/** The name of the column containing the filename where the shared file was actually

stored. */

public static final String _DATA = "_data";

/** The name of the column containing the MIME type of the shared file. */

public static final String MIMETYPE = "mimetype";

/** The name of the column containing the direction (Inbound/Outbound) of the transfer. See

the DIRECTION_* constants for a list of legal values. */

public static final String DIRECTION = "direction";

/** The name of the column containing Bluetooth Device Address that the transfer is

associated with. */

public static final String DESTINATION = "destination";

/** The name of the column containing the flags that controls whether the transfer is

displayed by the UI. See the VISIBILITY_* constants for a list of legal values. */

public static final String VISIBILITY = "visibility";

/** The name of the column containing the current user confirmation state of the transfer.

Applications can write to this to confirm the transfer. The USER_CONFIRMATION_*

constants for a list of legal values. */

public static final String USER_CONFIRMATION = "confirm";

/** The name of the column containing the current status of the transfer. Applications can

read this to follow the progress of each download. See * the STATUS_* constants for a list of

legal values. */

public static final String STATUS = "status";

/** The name of the column containing the total size of the file being transferred. */

public static final String TOTAL_BYTES = "total_bytes";

/** The name of the column containing the size of the part of the file that has been transferred

so far.*/

public static final String CURRENT_BYTES = "current_bytes";

/** The name of the column containing the timestamp when the transfer is initialized. */

public static final String TIMESTAMP = "timestamp";

/** This transfer is outbound, e.g. share file to other device. */

public static final int DIRECTION_OUTBOUND = 0;

/** This transfer is inbound, e.g. receive file from other device. */

public static final int DIRECTION_INBOUND = 1;

/** This transfer is waiting for user confirmation. */

public static final int USER_CONFIRMATION_PENDING = 0;

/** This transfer is confirmed by user. */

public static final int USER_CONFIRMATION_CONFIRMED = 1;

/** This transfer is auto-confirmed per previous user confirmation. */

public static final int USER_CONFIRMATION_AUTO_CONFIRMED = 2;

/** This transfer is denied by user. */

public static final int USER_CONFIRMATION_DENIED = 3;

/** This transfer is timeout before user action. */

public static final int USER_CONFIRMATION_TIMEOUT = 4;

/**This transfer is visible and shows in the notifications while in progress and after

completion */

public static final int VISIBILITY_VISIBLE = 0;

/** This transfer doesn't show in the notifications. */

public static final int VISIBILITY_HIDDEN = 1;

/** Returns whether the status is informational (i.e. 1xx). */

public static boolean isStatusInformational(int status) {

return (status >= 100 && status < 200);

}

/**Returns whether the transfer is suspended. (i.e. whether the transfer won't complete

without some action from outside the transfer manager). */

public static boolean isStatusSuspended(int status) {

return (status == STATUS_PENDING);

}

/**Returns whether the status is a success (i.e. 2xx). */

public static boolean isStatusSuccess(int status) {

return (status >= 200 && status < 300);

}

/**Returns whether the status is an error (i.e. 4xx or 5xx). */

public static boolean isStatusError(int status) {

return (status >= 400 && status < 600);

}

/**Returns whether the status is a client error (i.e. 4xx). */

public static boolean isStatusClientError(int status) {

return (status >= 400 && status < 500);

}

/**Returns whether the status is a server error (i.e. 5xx). */

public static boolean isStatusServerError(int status) {

return (status >= 500 && status < 600);

}

/**Returns whether the transfer has completed (either with success or error). */

public static boolean isStatusCompleted(int status) {

return (status >= 200 && status < 300) || (status >= 400 && status < 600);

}

/**This transfer hasn't stated yet */

public static final int STATUS_PENDING = 190;

/**This transfer has started */

public static final int STATUS_RUNNING = 192;

/**This transfer has successfully completed. Warning: there might be other status values that

indicate success in the future. Use isSucccess() to capture the entire category. */

public static final int STATUS_SUCCESS = 200;

/**This request couldn't be parsed. This is also used when processing requests with

unknown /unsupported URI schemes. */

public static final int STATUS_BAD_REQUEST = 400;

/**This transfer is forbidden by target device. */

public static final int STATUS_FORBIDDEN = 403;

/**This transfer can't be performed because the content cannot be handled. */

public static final int STATUS_NOT_ACCEPTABLE = 406;

/**This transfer cannot be performed because the length cannot be determined accurately.

This is the code for the HTTP error "Length Required", which is typically used when making

requests that require a content length but don't have one, and it is also used in the client when

a response is received whose length cannot be determined accurately (therefore making it

impossible to know when a transfer completes). */

public static final int STATUS_LENGTH_REQUIRED = 411;

/**This transfer was interrupted and cannot be resumed. This is the code for the OBEX error

"Precondition Failed", and it is also used in situations where the client doesn't have an ETag

at all. */

public static final int STATUS_PRECONDITION_FAILED = 412;

/**This transfer was canceled */

public static final int STATUS_CANCELED = 490;

/**This transfer has completed with an error. Warning: there will be other status values that

indicate errors in the future. Use isStatusError() to capture the entire category. */

public static final int STATUS_UNKNOWN_ERROR = 491;

/**This transfer couldn't be completed because of a storage issue. Typically, that's because

the file system is missing or full. */

public static final int STATUS_FILE_ERROR = 492;

/**This transfer couldn't be completed because of no sd card. */

public static final int STATUS_ERROR_NO_SDCARD = 493;

/**This transfer couldn't be completed because of sdcard full. */

public static final int STATUS_ERROR_SDCARD_FULL = 494;

/**This transfer couldn't be completed because of an unspecified un-handled OBEX code. */

public static final int STATUS_UNHANDLED_OBEX_CODE = 495;

/**This transfer couldn't be completed because of an error receiving or processing data at the

OBEX level. */

public static final int STATUS_OBEX_DATA_ERROR = 496;

/**This transfer couldn't be completed because of an error when establishing connection */

public static final int STATUS_CONNECTION_ERROR = 497;

}

Intelligent tag activity code

package com.ram.tag;

import java.io.IOException;

import java.io.InputStream;

import java.io.OutputStream;

import java.util.ArrayList;

import java.util.Set;

import java.util.UUID;

import android.app.Activity;

import android.bluetooth.BluetoothAdapter;

import android.bluetooth.BluetoothDevice;

import android.bluetooth.BluetoothSocket;

import android.content.BroadcastReceiver;

import android.content.Context;

import android.content.Intent;

import android.content.IntentFilter;

import android.os.Bundle;

import android.provider.Settings.Secure;

import android.telephony.TelephonyManager;

import android.view.ContextMenu;

import android.view.ContextMenu.ContextMenuInfo;

import android.view.MenuItem;

import android.view.View;

import android.view.View.OnClickListener;

import android.view.Window;

import android.widget.Button;

import android.widget.EditText;

import android.widget.TextView;

import android.widget.Toast;

public class IntelligentTagActivity extends Activity {

public static final int REQUEST_ENABLE_BT = 1;

BluetoothAdapter mBluetoothAdapter;

TextView mTitle;

private ConnectThread mConnectThread;

private ConnectedThread mConnectedThread;

EditText tag;

TelephonyManager tManager;

/** Called when the activity is first created. */

@Override

public void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.main);

getWindow().setFeatureInt(Window.FEATURE_CUSTOM_TITLE,R.layout.custom_ti

tle);

// Set up the custom title

mTitle = (TextView) findViewById(R.id.title_left_text);

// mTitle.setText(R.string.app_name);

tag = (EditText) findViewById(R.id.tagname);

Button btn = (Button) findViewById(R.id.button1);

btn.setOnClickListener(new OnClickListener() {

@Override

public void onClick(View v) {

// TODO Auto-generated method stub

registerForContextMenu(v);

}

});

tManager = (TelephonyManager)

getSystemService(Context.TELEPHONY_SERVICE);

// Register the BroadcastReceiver

IntentFilter filter = new IntentFilter(BluetoothDevice.ACTION_FOUND);

registerReceiver(mReceiver, filter); // Don't forget to unregister

// during onDestroy

}

public void onCreateContextMenu(ContextMenu menu, View v, ContextMenuInfo

menuInfo) {

menu.add(0, 1, 0, "Via Bluetooth");

menu.add(0, 2, 0, "Via Wifi");

super.onCreateContextMenu(menu, v, menuInfo);

}

@Override

public boolean onContextItemSelected(MenuItem item) {

switch (item.getItemId()) {

case 1:

checkstatus();

return true;

case 2:

return true;

default:

return super.onContextItemSelected(item);

}

}

private void checkstatus() {

// TODO Auto-generated method stub

mBluetoothAdapter = BluetoothAdapter.getDefaultAdapter();

if (mBluetoothAdapter == null) {

// Device does not support Bluetooth

Toast.makeText(getApplicationContext(),

"Device does not support Bluetooth", Toast.LENGTH_SHORT).show();

}

else if (!mBluetoothAdapter.isEnabled()) {

Intent enableBtIntent = new Intent(

BluetoothAdapter.ACTION_REQUEST_ENABLE);

startActivityForResult(enableBtIntent, REQUEST_ENABLE_BT);

/*Intent discoverableIntent = new // to make device discoverable

* Intent(BluetoothAdapter.ACTION_REQUEST_DISCOVERABLE);

* discoverableIntent

* .putExtra(BluetoothAdapter.EXTRA_DISCOVERABLE_DURATION, 300);

* startActivity(discoverableIntent); */

}

else if (mBluetoothAdapter.isEnabled()) {

Set<BluetoothDevice> pairedDevices = mBluetoothAdapter

.getBondedDevices();

ArrayList<String> mArrayAdapter = new ArrayList<String>();

// If there are paired devices

if (pairedDevices.size() > 0) {

// Loop through paired devices

for (BluetoothDevice device : pairedDevices) {

// Add the name and address to an array adapter to show in a List View

mArrayAdapter.add(device.getName() + "\n"+ device.getAddress());

System.out.println("list :" + device.getName() + "\n"+ device.getAddress());

}

// if(!mArrayAdapter.contains("Wave525"))

mBluetoothAdapter.startDiscovery();

/* else { System.out.println("discovered....."); }*/

}

}

}

@Override

protected void onDestroy() {

// TODO Auto-generated method stub

if(mBluetoothAdapter != null)

mBluetoothAdapter.disable();

unregisterReceiver(mReceiver);

super.onDestroy();

}

// Create a BroadcastReceiver for ACTION_FOUND

private final BroadcastReceiver mReceiver = new BroadcastReceiver() {

public void onReceive(Context context, Intent intent) {

String action = intent.getAction();

// When discovery finds a device

if (BluetoothDevice.ACTION_FOUND.equals(action)) {

// Get the BluetoothDevice object from the Intent

BluetoothDevice device =

intent .getParcelableExtra(BluetoothDevice.EXTRA_DEVICE);

System.out.println("discovering.. :" + device.getName() + "\n"+ device.getAddress());

if (device.getName().contains(tag.getEditableText().toString())) {

System.out.println("discovered.....");

if (mBluetoothAdapter != null)

// mBluetoothAdapter.cancelDiscovery();

mConnectThread = new ConnectThread(device);

mConnectThread.start();

}

}

}

};

private void sendMessage(String message) {

// Create temporary object

ConnectedThread r;

// Synchronize a copy of the ConnectedThread

synchronized (this) {

r = mConnectedThread;

}

// Perform the write unsynchronized

//if(r!= null)

System.out.println("writing...");

r.write(message.getBytes());

}

private class ConnectThread extends Thread {

private final BluetoothSocket mmSocket;

private final BluetoothDevice mmDevice;

public ConnectThread(BluetoothDevice device) {

mmDevice = device;

BluetoothSocket tmp = null;

// Get a BluetoothSocket for a connection with the

// given BluetoothDevice

try {

final String androidId = Secure.getString(

getApplicationContext().getContentResolver(),

Secure.ANDROID_ID);

UUID MY_UUID = UUID.nameUUIDFromBytes(androidId.getBytes("utf8"));

String uuid = tManager.getDeviceId();

// UUID MY_UUID = UUID.fromString(uuid);

UUID.nameUUIDFromBytes(uuid.getBytes("utf8"));

MY_UUID = UUID.randomUUID();

tmp = device.createRfcommSocketToServiceRecord(MY_UUID);

}

catch (IOException e) {

e.printStackTrace();

// Log.e(TAG, "create() failed", e);

}

mmSocket = tmp;

}

public void run() {

System.out.println("BEGIN mConnectThread");

setName("ConnectThread");

// Always cancel discovery because it will slow down a connection

mBluetoothAdapter.cancelDiscovery();

// Make a connection to the BluetoothSocket

try {

// This is a blocking call and will only return on a

// successful connection or an exception

mmSocket.connect();

}

catch (IOException e) {

System.out.println("connection failed");

// connectionFailed();

// Close the socket

try {

mmSocket.close();

}

catch (IOException e2) {

}

return;

}

// Start the connected thread

connected(mmSocket, mmDevice);

}

public void cancel() {

try {

mmSocket.close();

}

catch (IOException e) {

// Log.e(TAG, "close() of connect socket failed", e);

}

}

}

private class ConnectedThread extends Thread {

private final BluetoothSocket mmSocket;

private final InputStream mmInStream;

private final OutputStream mmOutStream;

public ConnectedThread(BluetoothSocket socket) {

// Log.d(TAG, "create ConnectedThread");

mmSocket = socket;

InputStream tmpIn = null;

OutputStream tmpOut = null;

// Get the BluetoothSocket input and output streams

try {

tmpIn = socket.getInputStream();

tmpOut = socket.getOutputStream();

} catch (IOException e) {

// Log.e(TAG, "temp sockets not created", e);

}

mmInStream = tmpIn;

mmOutStream = tmpOut;

}

public void run() {

// Log.i(TAG, "BEGIN mConnectedThread");

byte[] buffer = new byte[1024];

int bytes;

while (true) {

try {

// Read from the InputStream

bytes = mmInStream.read(buffer);

} catch (IOException e) {

// Log.e(TAG, "disconnected", e);

// connectionLost();

break;

}

}

}

/* * Write to the connected OutStream.

* @param buffer

* The bytes to write */

public void write(byte[] buffer) {

try {

mmOutStream.write(buffer);

} catch (IOException e) {

// Log.e(TAG, "Exception during write", e);

}

}

public void cancel() {

try {

mmSocket.close();

}

catch (IOException e) {

// Log.e(TAG, "close() of connect socket failed", e);

}

}

}

public synchronized void connected(BluetoothSocket socket,

BluetoothDevice device) {

// Cancel the thread that completed the connection

if (mConnectThread != null) {

mConnectThread.cancel();

mConnectThread = null;

}

// Cancel any thread currently running a connection

if (mConnectedThread != null) {

mConnectedThread.cancel();

mConnectedThread = null;

}

// Cancel the accept thread because we only want to connect to one device

// Start the thread to manage the connection and perform transmissions

mConnectedThread = new ConnectedThread(socket);

mConnectedThread.start();

sendMessage("hi");

}

}

8. EXPERIMENTATION RESULTS

A software component has been installed on the TAG side to simulate the occurrence of

a particular type of attack so that the software developed using the architecture proposed is

tested thoroughly. Communication is effected through different combinations of the

communication protocols. The kind of attack that is affected is displayed on the Tag side

LCD and Mobile Side display system. Messages indicating the attack are sent from TAG side

to mobile side. The messages are also displayed on the Tag side LCD and the mobile side

display system. The output displayed on the TAG and mobile side are tabulated and shown in

the table 8.1. It could be seen from the table 8.1 that under the conductions, the date and time

of transmission and reception are also displayed on the LCD and Display system and then

same are also recorded in the table 8.1. It could be seen from the table that the response time

achieved is still within the limits even though more amount of code has to be executed due to

implementation of counter attacking method.

The proposed method of security mechanism is implemented through Embedded-C under

Integrated KEIL development tool kit. The Tag searches for the available devices within its

vicinity. With the developed security mechanism, if there is no sign of attack on the

communication link between a Tag and the mobile device, the system will perform the

communication without any overhead of enabling the counter-measure mechanisms. If the

system detects any attack being performed, then the appropriate counter-attacking mechanism

will be enabled and secures the communication link between them. This can be demonstrated

by providing the experimental results as shown below.

The intelligence module on the Tag side and Mobile side has sensed an attack which

sends continuous requests to each device to suspend its communication with each other. This

can be known to the user by using the user interface on either side as shown in figure 8.1 and

figure 8.2. By enabling the counter-measure selector to choose the appropriate counter

attacking mechanisms, the processing time of the communication link and the transmission

time and reception time of data on either side are as depicted in the table 8.1.

Figure 8.45 Attack on the Tag Side

Figure 8.46 Attack on the Mobile side

Table 8-11 Experimental results for counter attacking methods

Attack Initiated

Counter Attack Initiated

Port Selected on the Tag side

Message sent from Tag side

Transmission Port Selected on the Mobile side

Message Received on the Mobile Side

Reception

Wi-Fi Bluetooth Date Time of Transmission

Wi-Fi Bluetooth

Date Time Response in secs

1 - - √ POWS 10/06

10.00 √ POWS

10/06

10.01 0.01

2 Blue Snarfing attack

Authentication using PINs or Passwords

√ BSAT 10/06

10.05 √ BSAT

10/06

10.07 0.02

3 Blue Bugging attack

RF Signatures √ BBAT 10/06

10.10 √ BBAT

10/06

10.12 0.02

4 Man-in-the-Middle attack

Encryption / Decryption with Time-out Mechanism

√ MMAT 10/06

10.20 √ MMAT

10/06

10.22 0.02

5 Denial of Service attack

Intrusion Detection System

√ DSAT 10/06

10.25 √ DSAT

10/06

10.27 0.02

6 Evil Twin Access Point attack

Avoid SSID broadcasting

√ ACAT 10/06

10.30 √ ACAT

10/06

10.32 0.02

7 Replay attack

Assignment of Session Tokens

√ RAAT 10/06

10.35 √ RAAT

10/06

10.37 0.02

9. Summary and Conclusions

The devices used in the intelligent TAG systems are limited in the resources. The peer to

peer communication between the TAG and the Mobile device is quite vulnerable. Adding the

entire required infrastructure to the TAG and the mobile device requires many resources and

providing such kind of resources is impracticable. Adding any software load for

implementing the permanent counter attacking measures drastically effects the response time

and throughput of transacting between the mobile device and the TAG. Intelligence has been

added for sensing any attack and the counter attacking measure only come into force when

any of the attacks are initiated.

The software architecture has been presented for building intelligence to the system for

securing the communication between Host and a Tag. This architecture is well suited to

implement intelligence into the embedded systems with security as a major concern. The

software required for the system was designed using the architecture presented in this thesis

and the same has been implemented within the separately designed embedded system.

10. FUTURE WORK

REFERENCES:

1. Dieter Hutter, Günter Müller, Werner Stephan, and Markus Ullmann, March 2003,

“Security and privacy aspects of low-cost radio frequency identification systems,” in

Int. Conf. on Security in Pervasive Computing, volume 2802 of Lecture Notes in

Comput. Science, pages 454–469.

2. Miyako Ohkubo, Koutarou Suzuki, and Shingo Kinoshita, November

2003,“Cryptographic approach to “privacy-friendly” tags,” in RFID Privacy

Workshop, MIT, MA, USA,.

3. Dirk Henrici and Paul Müller, March 2004,“Hash-based enhancement of location

privacy for radio-frequency identification devices using varying identifiers,” in Int.

Workshop on Pervasive Computing and Communication Security – PerSec pages

149–153.

4. Tassos Dimitriou, September 2005, “A lightweight RFID protocol to protect against

traceability and cloning attacks,” in International Conference on Security and Privacy

for Emerging Areas in Communication Networks, IEEE, pages 59-66.

5. Su-Mi Lee, Young Ju Hwang, Dong Hoon Lee, and Jong In Lim Lim, 2005,

“Efficient authentication for low-cost RFID systems,” in Int. Conf. on Computational

Science and its Applications - ICCSA.

6. David Molnar and David Wagner, October 2004, “Privacy and security in library

RFID: Issues, practices, and architectures,” in Conf. on Comput. and Commun.

Security – ACM CCS, pages 210–219, Washington, DC, USA.

7. Xingxin (Grace) Gao, Zhe (Alex) Xiang, Hao Wang, Jun Shen, Jian Huang, and Song

Song, September 2005, “An approach to security and privacy of RFID system for

supply chain,” in International Conference on E-Commerce Technology for Dynamic

E-Business – CEC-East’04, pages 164–168, Beijing, China.

8. Dominic Spill and Andrea Bittau, “Blue Sniff: Eve meets Alice and Bluetooth”,

University College London.

9. Dr JKR Sastry, N. Venkatram, Y. Pavan Kumar, N. Rajesh Babu, May 2012, “On

building intelligence for securing communication between the Tags and the Mobile

Devices” in International Journal Of Mobile and Adhoc Network - IFRSA, Volume 2,

Issue 2.

10. Dr JKR Sastry, N. Venkatram, Y. Pavan Kumar, N. Rajesh Babu, June 2012,

“Development of Software Architecture for Building Intelligence to Secure the

Communication between the Tags and Mobile Devices” in IJVES – Technical

Journals, Volume 3, Issue 2.

11. www.arm.com

12. LPC2148 Manual

13. http://en.wikipedia.org/wiki/EEPROM

14. M. A. Mazidi, J. C. Mazidi, R. D. Mckinaly, “The 8051 Microcontroller and

Embedded Systems”, Pearson Education, 2011.

15. www.quectel.com

16. www.sena.com/download/certification/Bluetooth_SIG_Guide-V1.pdf

17. www.digi.com/pdf/ds_xbeewifi.pdf

18. http://www.keil.com/uvision/db_sim.asp

APPENDIX