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

ii

KONERU LAKSHMAIAH UNIVERSITY

DEPARTMENT 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. : Dr. J.K.R Sastry Professor, Department of CSE.

Internal guides

Dissertation Coordinators

: Dr. A.S.N Chakravarthy Professor, Department of ECM. : Mr. G. Kalyan Mohan Associate Professor, Department of ECM.

iii

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

iv

KONERU LAKSHMAIAH UNIVERSITY

DEPARTMENT OF ELECTRONICS & COMPUTER ENGINEERING GREEN FIELDS, VADDESWARAM.

Duration of the Dissertation: Date of Start: Date of Submission: Dissertation carried out at: Title of the Project: Student Details K.L. UNIVERSITY, VADDESWARAM. ON SECURING THE DEVICE TAG MANAGEMENT : Y. Pavan Kumar 10102197, M. Tech (Embedded Systems), Department of ECM. : Dr. J.K.R Sastry Professor, Department of CSE.

Internal Guides

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 Professor Department of CSE K L University

Prof. S. Balaji Head of the Department Department of ECM K L University

vi

TABLE OF CONTENTS
1. INTRODUCTION 1 1 4 4 4 5 5 8 10 11 11 13 14 15 15 16 17 20

1.1 TERMINOLOGY AND DEFINITIONS 1.2 THEORETICAL FOUNDATION 1.2.1 BLUETOOTH 1.2.1.1 Security Mechanisms 1.2.1.2 Bluetooth security features 1.2.1.3 Bluetooth security issues 1.2.1.4 Counter-measures for attacks on Bluetooth 1.2.2 WI-FI 1.2.2.1 Wireless LAN Architecture 1.2.2.2 Wi-Fi Security Threats 1.2.2.3 Counter measures for Wi-Fi vulnerabilities 1.3 PROBLEM DEFINITION 1.4 SCOPE 1.5 METHODOLOGY 1.6 LIMITATIONS 2. 3. 3.1 LITERATURE SURVEY RESEARCH FINDINGS

BUILDING INTELLIGENCE FOR SECURING THE COMMUNICATION BETWEEN THE TAGS AND 20 3.1.1 SUMMARY OF FINDINGS 20 3.1.2 INTRODUCTION 20 3.1.3 INVESTIGATIONS 21 3.1.4 CONCLUSIONS 24 3.2 SOFTWARE ARCHITECTURE FOR BUILDING INTELLIGENCE TO SECURE THE COMMUNICATION BETWEEN THE TAGS AND THE MOBILE DEVICES 25 3.2.1 SUMMARY OF FINDINGS 25 3.2.2 INTRODUCTION 25 3.2.3 INVESTIGATIONS 26 3.2.4 CONCLUSIONS 27
THE MOBILE DEVICES

4. 4.1 4.1.1 4.1.2 4.1.3 4.1.4

REQUIREMENTS ENGINEERING TAG SIDE REQUIREMENTS ENGINEERING OVERVIEW OF THE SYSTEM PROCESS FLOW MODELING HARDWARE REQUIREMENTS FUNCTIONAL REQUIREMENTS

28 28 28 29 30 30 vii

4.1.5 4.1.6 4.1.7 4.2 4.2.1 4.2.2 4.2.3 4.2.4 4.2.5 4.2.6 4.2.7 5. 5.1 5.1.1 5.1.2 5.1.3 5.1.4 5.1.5 5.2 5.2.1 5.2.2 5.2.3 5.2.4 5.2.5 6.

NON FUNCTIONAL REQUIREMENTS TRACING THE FUNCTIONAL REQUIREMENTS THROUGH USE CASES TRACING THE BUSINESS OBJECTS THROUGH CLASSES MOBILE SIDE REQUIREMENTS ENGINEERING OVER VIEW OF MOBILE SIDE DESCRIPTION PROCESS FLOW MODELING HARDWARE REQUIREMENTS FUNCTIONAL REQUIREMENTS NON FUNCTIONAL REQUIREMENTS TRACING THE FUNCTIONAL REQUIREMENTS THROUGH USE CASES TRACING THE BUSINESS OBJECTS THROUGH CLASSES ANALYSIS TAG SIDE ANALYSIS HARDWARE ANALYSIS USE CASE MODELING BUSINESS PROCESS MODELING THROUGH HW RELATED CLASS DIAGRAM BUSINESS PROCESS MODELING THROUGH SW RELATED CLASS DIAGRAM BUSINESS PROCESS MODELING RELATED TO INTERFACING OF HW AND SW COMPONENTS MOBILE SIDE ANALYSIS HARDWARE ANALYSIS USE CASE MODELING BUSINESS PROCESS MODELING THROUGH HW RELATED CLASS DIAGRAM BUSINESS PROCESS MODELING THROUGH SW RELATED CLASS DIAGRAM BUSINESS PROCESS MODELING RELATED TO INTERFACING OF HW AND SW COMPONENTS DESIGN

31 31 31 32 32 33 34 35 35 35 36 37 37 37 37 38 39 41 42 42 42 43 44 45 47 47 47 47 49 51 67 67 69 70 70 75 89 viii

6.1 TAG SIDE DESIGN 6.1.1 HARDWARE DESIGN 6.1.1.1 Block Diagram 6.1.1.2 Object Modeling 6.1.1.3 Design of Hardware Elements 6.2 SOFTWARE DESIGN 6.2.1 OBJECTS MODELING 6.2.2 INTEGRATION DESIGN 7. 7.1 7.2 8. IMPLEMENTATION CLIENT SIDE CODE MOBILE SIDE CODE EXPERIMENTATION RESULTS

9. 10.

SUMMARY AND CONCLUSIONS FUTURE WORK

92 92

LIST OF FIGURES
FIGURE 3.1 COMMUNICATION ARCHITECTURE OF INTELLIGENT TAG MANAGEMENT SYSTEM . 22 FIGURE 3.2 IMPLEMENTATION OF INTELLIGENCE FOR SECURING THE COMMUNICATION BETWEEN TAG AND MOBILE DEVICE ................................................................................. 23 FIGURE 3.3 PARAMETERS AND APPROPRIATE COUNTER MEASURES FOR ENSURING SECURITY 24 FIGURE.3.4 SOFTWARE ARCHITECTURE FOR BUILDING INTELLIGENCE TO SECURE THE INTELLIGENT TAG MANAGEMENT SYSTEM ....................................................................... 27 FIGURE 4.1 OVERVIEW OF THE INTELLIGENT TAG APPLICATION ............................................. 28 FIGURE 4.2 PROCESS FLOW MODELING FOR SECURITY MANAGEMENT ON TAG SIDE.................. 29 FIGURE 4.3 OVERVIEW OF THE INTELLIGENT TAG APPLICATION ON MOBILE SIDE .................. 32 FIGURE 4.4 PROCESS FLOW MODELING FOR SECURITY MANAGEMENT ON MOBILE SIDE ......... 34 FIGURE 5.1 USE CASE DIAGRAM SHOWING FUNCTIONAL REQUIREMENTS OF SECURITY MANAGEMENT................................................................................................................... 38 FIGURE 5.2 HARDWARE CLASS DIAGRAM OF SECURITY MANAGEMENT .................................. 39 FIGURE 5.3 SOFTWARE CLASS DIAGRAM OF THE SECURITY MANAGEMENT ............................ 41 FIGURE 5.4 CLASS DIAGRAM INTERFACES OF HW AND SW COMPONENTS ON TAG SIDE ......... 42 FIGURE 5.5 USE CASE MODELING ON MOBILE SIDE................................................................. 43 FIGURE 5.6 HARDWARE CLASS DIAGRAM OF IDENTIFICATION SYSTEM ON MOBILE SIDE ........ 44 FIGURE 5.7 SOFTWARE CLASS DIAGRAM OF SECURITY MANAGEMENT ON MOBILE SIDE ......... 45 FIGURE 5.8 CLASS DIAGRAM INTERFACES HW AND SW COMPONENTS ON MOBILE DEVICE SIDE ................................................................................................................................... 46 FIGURE 6.1: TAG SIDE DESIGN DIAGRAM ................................................................................. 47 FIGURE 6.2 HARDWARE BLOCK DIAGRAM OF INTELLIGENT TAG .............................................. 49 FIGURE 6.3 OBJECT MODELING DIAGRAM OF TAG DESIGN ...................................................... 50 FIGURE 6.4: PIN DIAGRAM OF ARM CONTROLLER ................................................................... 52 FIGURE 6.5: GENERAL TIMING DIAGRAM ................................................................................. 53 FIGURE 6.6: ADDRESS TIMINGS ................................................................................................ 53 FIGURE 6.7: DATA WRITE CYCLES ........................................................................................... 53 FIGURE 6.8: DATA READ CYCLES; DBE IS HIGH DURING THE CYCLE SHOWN ......................... 54 FIGURE 6.9: DATA BUS CONTROL ............................................................................................. 54 FIGURE 6.10: CONFIGURATION DIAGRAM ................................................................................. 54 FIGURE 6.11: EXCEPTION TIMING ............................................................................................. 54 FIGURE 6.12: CLOCK TIMING OF ARM7 ................................................................................... 55 FIGURE 6.13: UART INTERFACING PIN OUT DIAGRAM ............................................................. 56 FIGURE 6.14: TIMING DIAGRAM OF UART ............................................................................... 56 FIGURE 6.15: PIN DIAGRAM OF EEPROM ................................................................................ 57 FIGURE 6.16: I2C PROTOCOL IC FOR INTERFACING EEPROM ................................................. 58 FIGURE 6.17: TIMING DIAGRAM FOR I2C .................................................................................. 58
ix

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

LIST OF TABLES
TABLE 1-1 KEY WORDS AND THEIR DEFINITIONS OF THE SECURITY MECHANISMS ...................... 3 TABLE 1-2 SELECTING A SECURE PIN ........................................................................................ 9 TABLE 4-1 HARDWARE REQUIREMENTS ON TAG SIDE .............................................................. 30 TABLE 4-2 FUNCTIONAL REQUIREMENTS OF TAG THROUGH USE CASES .................................... 31 TABLE 4-3 BUSINESS OBJECTS THROUGH CLASSES .................................................................. 32 TABLE 4-4 HARDWARE REQUIREMENTS ON MOBILE SIDE ........................................................ 35 TABLE 4-5 FUNCTIONAL REQUIREMENTS THROUGH USE CASES............................................... 35 TABLE 4-6: MOBILE DEVICE BUSINESS OBJECTS THROUGH CLASSES ....................................... 36 TABLE 5-1: HARDWARE ANALYSIS OF THE TAG ....................................................................... 37 TABLE 5-2: USE CASE DESCRIPTION ......................................................................................... 38 TABLE 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
1

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 drivers 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: WPAPSK, 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.

Definitions
Table 1-1 Key words and their definitions of the security mechanisms

S.No 1

Key Words ACL

SCO

3 4

WEP WPA

Definition 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). 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. WEP is a standard network protocol that adds security to 802.11 WiFi networks at the data link layer 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.
3

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 pseudorandom 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.
4

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:
5

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 email 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 victims 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
7

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
8

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 0-9 (10 characters) 0-9 A-Z (36 characters) 0-9 A-Z, a-z (62 characters) (Printable) ASCII (95 characters) 5. Denial of Service Attack:

Recommended PIN length 19 characters ( = 63 bits) 12 characters ( = 62 bits) 11 characters ( = 65 bits) 10 characters ( = 66 bits)

Minimum PIN length 12 characters ( = 40 bits) 8 characters ( = 41 bits) 7 characters ( = 42 bits) 6 characters ( = 39 bits)

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
9

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 verifiers 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 users 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

10

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, its 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.
11

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, lesscrowded 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 theyre 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

12

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, its 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 browsers 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 doesnt 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 users 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 dont 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
13

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 thats at least 10 characters long: The longer your password, the harder it is for hackers to break. 5. Change routers 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 dont 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 youre 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 dont 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.

14

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.

15

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.

16

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 Mller [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
17

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 Demetrios, 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
18

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.

19

3. RESEARCH FINDINGS
3.1 Building intelligence for securing the communication between the Tags and the Mobile Devices
3.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,
20

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 WiFi and Wi-Fi to Bluetooth. This can be achieved by introducing a protocol converter in
21

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.

INTELLIGENT TAG
ARM CONTROLLER

Communication link using Bluetooth / Wi-Fi

MOBILE DEVICE
ANDROID OS Intelligent Tag

Memory Chip

Bluetooth

Bluetooth

Protocol Converter

Protocol Converter

Wi-Fi

Wi-Fi

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
22

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.
INTELLIGENT TAG MOBILE DEVICE

ARM Controller

Intelligence Module Counter Measure Selector

Android OS Intelligent Tag Intelligence Module Counter Measure Selector

Bluetooth

Bluetooth

Protocol Converter

Protocol Converter

Wi-Fi

Wi-Fi

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
23

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.
INTELLIGENCE MODULE
Parameters to be sensed

Counter-measure Selector Authentication Mechanism Verify RF Signatures Bluetooth / W-Fi Communication Interfaces

OBEX Sensor Device Attacking sensor Man in the Middle sensor

Enables Encryption

Denial of service sensor Replay attack sensor

Turn-off Communication Link Generate Session Tokens

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
24

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

25

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

Tier-I Intelligent Tag Application

Tier-II

Controller Module

Communication Module

Intelligence Module

Counter-measure Selector

uCOS Module
Counter-measure Selector

Tier-III
Host Communication Module

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.

27

4. REQUIREMENTS ENGINEERING
4.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.
INTELLIGENT TAG POWER SOURCE MOBILE

EXTERNAL MEMORY ARM CONTROL LER PRESSURE SENSOR PUSH TO ON SWITCH

ANDROID OS
INTELLIGENT TAG INTERFCE APP OTHER INSTALLED APPS

BLUETOOTH BLUETOOTH WI-FI GPS BUZZER GPS

COMMUNICATION

WI-FI

Figure 4.1 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
28

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.

Start

check for availability of ports from TAG Side

Dynamic Configuration of available ports

Establish Communication

attack detection on communication link

is attack detected? Yes Select Countermeasure No

Implement Counter-measure

Efficient Communication

End

Figure 4.2 Process flow modeling for security management on Tag side

29

4.1.3 Hardware Requirements

Table 4-1 Hardware Requirements on Tag Side

S.No 1 2 3 4 5

Hardware Required ARM7 Evaluation Board (LPC2148) Wi-Fi 802.11 B/G/N (UART Interface) Bluetooth (USB Interface) GPS 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.

30

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-2 Functional requirements of Tag through use cases

Serial Use Case Number Code 1. IDUC01

Description of the Use Case Communication port availability and Dynamic Configuration (TAG) Communication port availability and Dynamic Configuration (HOST) Establish Communication Communicate Detect Attacker Set Undetected Counter-measure Selector Counter Attack Implementer

Major Events to Handel Checks the availability of ports on Tag side. Checks the availability of ports on Host side. Communication link establishment Ready to communicate Checks whether any attacks on the communication link. Communication establishes normally when no attack is detected. Select appropriate counter-measure for the attack performed. Enables appropriate Counter-measure on the communication link.

2.

IDUC02

3. 4. 5. 6. 7. 8.

IDUC03 IDUC04 IDUC05 IDUC06 IDUC07 IDUC08

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.

31

Table 4-3 Business Objects Through Classes

Serial Number 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.

Class code IDCL01 IDCL02 IDCL03 IDCL04 IDCL05 IDCL06 IDCL07 IDCL08 IDCL09 IDCL10 IDCL11 IDCL12 IDCL13 IDCL14 IDCL15 IDCL16 IDCL18 IDCL19

Description of the Class Main control logic process ARM7 LCD LCD process LED LED process Bluetooth Mobile Bluetooth Wi-Fi Mobile Wi-Fi Communication Port Availability checker (TAG) Communication Port Availability checker (HOST) Communication Link Establisher Attack Detector Counter-measure Selector Counter-measure Implementer EEPROM EEPROM process

4.2 Mobile side Requirements Engineering

4.2.1 Over View of Mobile side Description
INTELLIGENT TAG POWER SOURCE MOBILE Intelligent tag app
Port configuration Attack Detector handshake Counter-measure Selector

EXTERNAL MEMORY ARM CONTROL LER PRESSURE SENSOR PUSH TO ON SWITCH

Counter-measure Implementer

BLUETOOTH
COMMUNICATION

BLUETOOTH WI-FI

WI-FI BUZZER

Figure 4.3 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
32

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.

33

Start

check for active ports from Mobile side

Dynamic Configuration of available ports

Listen to active communication ports

Establish communication link

Sense for attackingon communication link

If attack sensed? Yes Choose Counter-measure No Implement Counter-measure

establish secured communication

establish communication without counter-measure overhead

End

Figure 4.4 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.

34

Table 4-4 Hardware Requirements on Mobile Side

Mobile

Features 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

Samsung L9100 GALAXY S2

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-5 Functional Requirements through Use Cases

Serial Use Case Number Code 1. IDUC01 2. 3. 4. 5. IDUC02 IDUC03 IDUC04 IDUC05

Description of the Use Case Port Configuration Checker Communication manger Detect Attack Counter-measure selector Counter-measure Implementer

Major Events to Handel Internal Trigger. Internal Trigger. Sensing of attacks on communication link. Chooses appropriate countermeasure on detecting an attack. Enables appropriate counterattacking mechanism.
35

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-6: Mobile Device Business Objects through Classes

Serial Number 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.

Class code IDCL01 IDLC02 IDCL03 IDCL04 IDCL05 IDCL06 IDCL07 IDCL08 IDCL09 IDCL10 IDCL11 IDCL12 IDCL13 IDCL14 IDCL15 IDCL16 IDCL17 IDCL18

Description of the CLASS ARM 7 MOBILE-Main control logic process LCD process USB interface EEPROM Mobile Bluetooth Tag Bluetooth Mobile Wi-Fi Tag Wi-Fi Physical Communication Manager on mobile side process Physical Communication Manager on Tag side process Attack Detector process Counter-measure Selection process Counter-measure Implementation process TAG side communicator MOBILE side communicator LCD EEPROM process

36

5. ANALYSIS
5.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-1: Hardware Analysis of the Tag

Serial Device Code Number of the device 1 ARM7 2

Type of Device

Latency of the Device -

Port to which connected -

Description of the device

BLUETOOTH DOFB 3 WI-FI 4 5 EEPROM LCD 6 BUZZER DOFB DOFB DOFB DOFB

0.020 USB

0.010 UART0 0.020 I2C 0.020 GPIO

0.020 GPIO

Controlling and monitoring Communication with remote device using Bluetooth interface Communication with remote device using Wi-Fi interface For data repository Alerting the system for securing the communication link. 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.

37

Table 5-2: Use Case Description

Serial Use Case Code Number IDUC01 1. 2. 3. 4. 5. 6. 7. 8. IDUC02 IDUC03 IDUC04 IDUC05 IDUC06 IDUC07 IDUC09

Use case description Communication ports availability and dynamic configuration (Host) Communication ports availability and dynamic configuration (Tag) Establish Communication Link Ready to communicate Sense any attacks on the Communication link Choose appropriate counter-measure Implement selected Counter-measure Senses no attack

Preceding usage case IDUC04 IDUC05 IDUC06 IDUC05

Communication ports availability and dynamic configuration (HOST)

Communication ports availability and dynamic configuration (TAG)

HOST Establish communication

TAG

Communicate Undetected

Set undetected

Detected Detect Attackar

Select Counter Measuer

Counter Attack implementor

Figure 5.1 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
38

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.

Buzzer

Bluetooth (Tag)

Bluetooth (Mobile)

ARM 7

EEPROM

LCD

Wi-Fi (Tag)

Wi-Fi (Mobile)

Figure 5.2 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

39

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.

40

Main Logic Controller

LCD Process

EEPROM Process

communication management

Buzzer Process

Attack Detector

Counter-measure selector

detected

Attack Persistent Checker

Counter Attack Implementor

not detected

Peripheral communication manager

Bluetooth Process (TAG)

Wi-Fi Process (TAG)

Bluetooth Process (HOST)

Wi-Fi Process (HOST)

Figure 5.3 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.

41

Main Logic Controller LCD Process LCD

ARM 7

EEPROM Process communication management

EEPROM

Buzzer Process Attack Detector

Buzzer Bluetooth (Tag) Wi-Fi (Tag)

Counter-measure selector Bluetooth Process (TAG) detected Attack Persistent Checker Counter Attack Implementor not detected Bluetooth (Host) Wi-Fi (Mobile) Peripheral communication manager Wi-Fi Process (TAG)

Bluetooth Process (Host) Wi-Fi Process (Host)

Figure 5.4 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 Device name number 1 ARM7 Dual Core 1.2 GHz Cortex A9 2 Wi-Fi 802.11 A/B/G/N 3 Bluetooth V3.0 4 5 Memory up to 32 GB extendable USB

description Controlling and monitoring This is meant for communicating the devices using Wi-Fi interface This is meant for communicating the devices using Bluetooth interface Used for data repository 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.

42

Checking available active ports

Checking available active ports

Configure available ports

Mobile Device

Tag Establishment of Communication link

Sense for any attacks on communication link

undetected Set undetected

detected

Choose appropriate Counter-measure

Implement Counter mechanism

Figure 5.5 Use Case Modeling On Mobile Side Table 5-4: Description of the Use Case

Serial Use Case Code Number IDUC01 1. 2. 3. 4. 5. 6. 7. IDUC02 IDUC03 IDUC04 IDUC05 IDUC06 IDUC07

Use case description Checking available active ports Configure available ports Establish Communication Link Attack Detector Counter-measure Selector (if detected) Counter-measure Implementer Set Undetected (if no attack)

Preceding usage case IDUC03 IDUC04 IDUC05 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.
43

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 TAGs information is stored. The hardware class diagram for security management on the mobile side is shown in figure 5.6.

Bluetooth (Tag)

Bluetooth (Mobile)

EEPROM

ARM 7 (Mobile)

Wi-Fi (Tag)

Wi-Fi (Mobile)

USB Interface

Figure 5.6 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 Countermeasure Implementer enables the specified counter attacking mechanism and it is processed
44

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.

Main Logic Controller (Mobile)

USB process

Mobile Side Communication Manager

EEPROM process

Attack Detector No attack detected Attack Detected Counter-measure Selector Mobile Bluetooth process Bluetooth process (Tag)

Mobile Wi-Fi process Counter-measure Implementer

Wi-Fi process (Tag)

Figure 5.7 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.

45

ARM 7 (Mobile)

Main Logic Controller (Mobile)

EEPROM

EEPROM process

Bluetooth (Mobile) USB Interface Wi-Fi (Mobile) Mobile Bluetooth process Mobile Side Communication Manager Bluetooth Process(Tag) No Attack Wi-Fi Process (Tag) Bluetooth (Tag) Wi-Fi (Tag) Attack Detected Attack Detector USB process

Mobile Wi-Fi process

Counter-measure Selector

Counter-measure Implementer

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

46

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

Figure 6.1: 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.

47

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, realtime 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.

48

ARM7 PRIMER BOARD

BATTERY POWER SUPPLY
XTAL1 XTAL2

Power on Reset
/RST

P0[31 28] and P0[25 0] Fast GPIO

ARM7 LPC2148

P1[31 16]

SYSTEM FUNCTIONS

ARM7 TDMIS AHB BRIDGE ARM7 LOCAL BUS

AHB BUS

AHB TO VPB BRIDGE RX0 TX0 CTS,DSR,DTR,RTS,DC D,RI RX1 TX1

WI - FI

UART0 VLSI peripheral bus UART1

P1.22

BEEPER

P0.7

BUZZER

GPS

BLUETOOTH

CTS,DSR,DTR,RTS,DC D,RI D+ USB Dcontroller

P0.16 P0.22

LCD

GPIO P1.24 P1.31 KEYPAD

ADC

P0.16 P0.22

LEDs

EEPROM

SCL SDA

I2C 1 Bus

P0.14 P0.15

Push to on switches

Figure 6.2 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.

49

Figure 6.3 Object Modeling Diagram of Tag Design

50

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

51

 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.4: Pin Diagram of ARM Controller

52

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.5: General Timing Diagram

nWAIT and ALE are both HIGH during the cycle shown.

Figure 6.6: Address Timings

Figure 6.7: 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
53

shows data write cycles. Diagram shows DBE is high during the cycle. Figure 6.8 shows data read cycles.

Figure 6.8: Data Read Cycles; DBE Is High During the Cycle Shown

Figure 6.9: 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.10: Configuration Diagram

Figure 6.11: Exception Timing

54

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.12: 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

55

ports used for interfacing Wi-Fi and GPS modules. Figure 6.13 shows UART interfacing pin out diagram.

Figure 6.13: 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.14: 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
56

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.15: 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 receiveronly 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 I2Cbus 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.

57

Figure 6.16: 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.17: 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
58

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

59

Figure 6.18: 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.

60

Figure 6.19: LCD 2x16 with Its Pin Description

Timing Diagram: Figure 6.20 shows timing diagram of LCD.

Figure 6.20: 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.

61

Figure 6.21: 4X4 Matrix Keypad

Timing Diagram: Figure 6.22 shows the timing diagram of matrix keypad.

Figure 6.22: 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. Its 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

62

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.

63

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.23: Power Supply Circuit

64

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

Figure 6.24: Bluetooth Module UART Interfaced

65

Bluetooth Features 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.25: 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
66

ISM 2.4 GHz frequency band and are compatible with the following. Figure 6.26 shows XBEE Wi-Fi module.

Figure 6.26: 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.

67

Figure 6.27 Software Objects Interaction on the TAG Side

68

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.

Figure 6.28 Interaction between the HW Objects and SW Objects on the TAG Side

69

7. Implementation
7.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 "}; //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)
70

//msg

{ Chr=Receive(); Switch (Chr) { case 0x33: case 0x34: } 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')
71

IOSET0 IOCLR0

|= 0x0080; break;/* buzzer on-from mobile press 3*/ |= 0x0080; break; /* buzzer off-from mobile press 4*/

{ 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);
72

i++; Chr = msg3[i]; }*/ } } void Serial_Init(void) { PINSEL0 | U0LCR U0DLL U0LCR } unsigned int Receive(void) { while (!(U0LSR & 0x01)); return (U0RBR); } void LCD_init4(void) { IO0DIR = 0xFFFFFFFF; /* Read character from Serial Port */ = = = = 0X00000005; 0x00000083; 0x00000061; 0x00000003; //Enable Txd0 and Rxd0 //8-bit data, no parity, 1-stop bit // for Baud rate=9600,DLL=82 //DLAB = 0;

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 IOCLR0 IOSET0 = = = ((cmd<<15) & 0x00780000); ((DATA^0xFFFFFFFF)& 0x00780000) | RS | RW; DATA | EN;
73

IOCLR0 | DATA IOCLR0 IOSET0 IOCLR0 | DelayMs(3); }

= = = = =

EN; ((cmd<<19) & 0x00780000); ((DATA^0xFFFFFFFF)& 0x00780000) | RS | RW; DATA | EN; EN;

void LCD_dat4(unsigned char byte) { DATA IOCLR0 IOSET0 IOCLR0 | DATA IOCLR0 IOSET0 IOCLR0 | 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 */
74

= = = = = = = =

((byte<<15) & 0x00780000); ((DATA^0xFFFFFFFF)& 0x00780000) | RW; DATA | RS | EN; EN; ((byte<<19) & 0x00780000); ((DATA^0xFFFFFFFF)& 0x00780000) | RW; DATA | RS | EN; EN;

{ if (ch == 'x') { while (!(U0LSR & 0x20)); U0THR } while (!(U0LSR & 0x20)); return (U0THR = ch); } = CR; /* output CR */

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";

75

/** 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";

76

/** 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); }
77

/**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. */
78

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;
79

} 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;
80

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");
81

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()) {
82

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);
83

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(),
84

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) { }
85

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() {
86

// 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,
87

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"); } }

88

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.

89

Figure 8.1 Attack on the Tag Side

Figure 8.2 Attack on the Mobile side

90

Table 8-1 Experimental results for counter attacking methods

S.No

Attack Initiated

Counter Attack Initiated

Port Selected on the Tag side

Message sent from Wi-Fi Bluetooth Tag side

Transmission

Date

1 2

Blue Snarfing attack Blue Bugging attack Man-intheMiddle attack Denial of Service attack Evil Twin Access Point attack Replay attack

Authenticatio n using PINs or Passwords RF Signatures

POWS BSAT

Time of Trans missi on 10/06 10.00 10/06 10.05

Port Selected on the Mobile side Wi-Fi Bluet ooth

Mess Reception age Recei ved Date Time Response on the in secs Mobil e Side POW S BSA T BBA T MM AT 10/0 6 10/0 6 10/0 6 10/0 6 10.01 10.07 0.01 0.02

BBAT

10/06

10.10

10.12

0.02

Encryption / Decryption with Time-out Mechanism Intrusion Detection System Avoid SSID broadcasting

MMAT

10/06

10.20

10.22

0.02

DSAT

10/06

10.25

DSA T ACA T

10/0 6 10/0 6

10.27

0.02

ACAT

10/06

10.30

10.32

0.02

Assignment of Session Tokens

RAAT

10/06

10.35

RAA T

10/0 6

10.37

0.02

91

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

92

REFERENCES: 1. Dieter Hutter, Gnter Mller, 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 454469. 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 Mller, 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 149153. 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 210219, 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-East04, pages 164168, 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
93

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

94

APPENDIX

95