the device tag management security
DESCRIPTION
tells about the rf tags security issues......TRANSCRIPT
DECLARATION BY THE CANDIDATE
I Y. PAVAN KUMAR (10102197), hereby declare that the project report
titled “ON SECURING THE DEVICE TAG MANAGEMENT” under the esteemed
guidance of Dr. J.K.R. SASTRY, Professor, Dept. of CSE; is submitted in the partial
fulfillment of the requirements for the award of the degree of Master of Technology in
Embedded Systems. This is a record of bonafide work carried out by me and the results
embodied in this project report have not been reproduced or copied from any source .The
results embodied in this project report have not been submitted to any other university for the
award of any other degree.
By,
Y. PAVAN KUMAR,
10102197.
ACKNOWLEDGEMENTS
Apart from the efforts of me, the success of any work depends largely on the
encouragement and guidelines of many others. I take this opportunity to express my gratitude
to the people who have been instrumental in the successful completion of this thesis.
I would like to show my greatest appreciation to my internal guide Dr. J.K.R Sastry,
Professor, Dept. of CSE. I can’t say thank you enough for his tremendous support and help.
I feel motivated and encouraged every time I attend his meetings. Without his encouragement
and guidance this thesis would not have materialized and implemented.
I am deeply indebted to my Head of the Department Prof. S. Balaji, Dept. of ECM; who
modeled me both technically and morally for achieving greater success in life.
I express my utmost gratitude to my thesis coordinators Dr. A.S.N. Chakravarthy,
Professor, Dept. of ECM; Mr. G. Kalyan Mohan, Associate Professor, Dept. of ECM;
for their timely advices and guidance in the course of my thesis work.
Finally, I owe a lot to the teaching and non-teaching staff of the Dept. of ECM for their
direct or indirect support in the entire course of my thesis work.
KONERU LAKSHMAIAH UNIVERSITYDEPARTMENT OF ELECTRONICS & COMPUTER ENGINEERING
GREEN FIELDS, VADDESWARAM.
ON SECURING THE DEVICE TAG MANAGEMENT
Student Details : Y. Pavan Kumar 10102197, M. Tech (Embedded Systems), Department of ECM.
Internal guides : Dr. J.K.R Sastry
Professor, Department of CSE.
Dissertation Coordinators : Dr. A.S.N Chakravarthy
Professor, Department of ECM. : Mr. G. Kalyan Mohan Associate Professor, Department of ECM.
A DISSERTATION
ON
ON SECURING THE DEVICE TAG MANAGEMENT
BY
Y. PAVAN KUMAR
10102197
Prepared the dissertation report on “ON SECURING THE DEVICE TAG MANAGEMENT” in the partial fulfillment of requirements in degree of Master of Technology (M. Tech) in Embedded Systems.
DEPARTMENT OF ELCETRONICS & COMPUTER ENGINEERING
KONERU LAKSHMAIAH UNIVERSITY
GREEN FIELDS, VADDESWARAM.
2011-12
KONERU LAKSHMAIAH UNIVERSITYDEPARTMENT OF ELECTRONICS & COMPUTER ENGINEERING
GREEN FIELDS, VADDESWARAM.
Duration of the Dissertation:
Date of Start:
Date of Submission:
Dissertation carried out at: “K.L. UNIVERSITY, VADDESWARAM.”
Title of the Project: “ON SECURING THE DEVICE TAG MANAGEMENT”
Student Details : Y. Pavan Kumar 10102197, M. Tech (Embedded Systems), Department of ECM.
Internal Guides : Dr. J.K.R Sastry
Professor, Department of CSE.
Research Areas : Security of communication standards, Communication.
Key Words : Intelligent Tag, Mobile Device (HOST), Security
mechanisms, Bluetooth, Wi-Fi.
ABSTRACT:
TAG is a small embedded system which is used for storing and remotely retrieving data
about objects the reader wants to manage. As the technology is getting advanced, these
TAGS are being made intelligent by providing functions like securing, tamper proofing,
power management, communication with hand-held devices etc. The TAG and the HOST
will have to communicate with each other for supporting many of the functions such as
identification, information on location etc.
For implementing any of the intelligence within the Tag, the TAG must communicate
with a remote HOST which in this case is the Mobile Device. The communication between a
Tag and Mobile Device has to be established using wireless communication standards like
Bluetooth, Wi-Fi etc. As the communication medium is wireless, there is a scope for the
attacker to perform various attacks on the communication between a Tag and Mobile Device.
The communication between the TAG and the HOST being intelligent must be secured to
protect the secrecy built into the system. To implement the appropriate security measures to
the communication between a Tag and Mobile Device, the following dissertation has mainly
focused on implementing an intelligent mechanism to sense whether there is any possibility
for attacking the communication between a Tag and Mobile Device and activate appropriate
counter-measures against that attacks. Software architecture has been proposed and the
software is developed for implementing in the pilot project.
Signature of the Student
Dr. J.K.R. Sastry Prof. S. BalajiProfessor Head of the DepartmentDepartment of CSE Department of ECMK L University K L University
TABLE OF CONTENTS
1. INTRODUCTION 1
1.1 TERMINOLOGY AND DEFINITIONS 11.2 THEORETICAL FOUNDATION 41.2.1 BLUETOOTH 41.2.1.1 Security Mechanisms 41.2.1.2 Bluetooth security features 51.2.1.3 Bluetooth security issues 51.2.1.4 Counter-measures for attacks on Bluetooth 81.2.2 WI-FI 101.2.2.1 Wireless LAN Architecture 111.2.2.2 Wi-Fi Security Threats 111.2.2.3 Counter measures for Wi-Fi vulnerabilities 131.3 PROBLEM DEFINITION 141.4 SCOPE 151.5 METHODOLOGY 151.6 LIMITATIONS 16
2. LITERATURE SURVEY 17
3. RESEARCH FINDINGS 20
3.1 BUILDING INTELLIGENCE FOR SECURING THE COMMUNICATION BETWEEN THE TAGS AND THE MOBILE DEVICES 203.1.1 SUMMARY OF FINDINGS 203.1.2 INTRODUCTION 203.1.3 INVESTIGATIONS 213.1.4 CONCLUSIONS 243.2 SOFTWARE ARCHITECTURE FOR BUILDING INTELLIGENCE TO SECURE THE COMMUNICATION BETWEEN THE TAGS AND THE MOBILE DEVICES 253.2.1 SUMMARY OF FINDINGS 253.2.2 INTRODUCTION 253.2.3 INVESTIGATIONS 263.2.4 CONCLUSIONS 27
4. REQUIREMENTS ENGINEERING 28
4.1 TAG SIDE REQUIREMENTS ENGINEERING 284.1.1 OVERVIEW OF THE SYSTEM 284.1.2 PROCESS FLOW MODELING 294.1.3 HARDWARE REQUIREMENTS 304.1.4 FUNCTIONAL REQUIREMENTS 30
4.1.5 NON FUNCTIONAL REQUIREMENTS 314.1.6 TRACING THE FUNCTIONAL REQUIREMENTS THROUGH USE CASES 314.1.7 TRACING THE BUSINESS OBJECTS THROUGH CLASSES 314.2 MOBILE SIDE REQUIREMENTS ENGINEERING 324.2.1 OVER VIEW OF MOBILE SIDE DESCRIPTION 324.2.2 PROCESS FLOW MODELING 334.2.3 HARDWARE REQUIREMENTS 344.2.4 FUNCTIONAL REQUIREMENTS 354.2.5 NON FUNCTIONAL REQUIREMENTS 354.2.6 TRACING THE FUNCTIONAL REQUIREMENTS THROUGH USE CASES 354.2.7 TRACING THE BUSINESS OBJECTS THROUGH CLASSES 36
5. ANALYSIS 37
5.1 TAG SIDE ANALYSIS 375.1.1 HARDWARE ANALYSIS 375.1.2 USE CASE MODELING 375.1.3 BUSINESS PROCESS MODELING THROUGH HW RELATED CLASS DIAGRAM 385.1.4 BUSINESS PROCESS MODELING THROUGH SW RELATED CLASS DIAGRAM 395.1.5 BUSINESS PROCESS MODELING RELATED TO INTERFACING OF HW AND SW COMPONENTS 415.2 MOBILE SIDE ANALYSIS 425.2.1 HARDWARE ANALYSIS 425.2.2 USE CASE MODELING 425.2.3 BUSINESS PROCESS MODELING THROUGH HW RELATED CLASS DIAGRAM 435.2.4 BUSINESS PROCESS MODELING THROUGH SW RELATED CLASS DIAGRAM 445.2.5 BUSINESS PROCESS MODELING RELATED TO INTERFACING OF HW AND SW COMPONENTS 45
6. DESIGN 47
6.1 TAG SIDE DESIGN 476.1.1 HARDWARE DESIGN 476.1.1.1 Block Diagram 476.1.1.2 Object Modeling 496.1.1.3 Design of Hardware Elements 516.2 SOFTWARE DESIGN 676.2.1 OBJECTS MODELING 676.2.2 INTEGRATION DESIGN 69
7. IMPLEMENTATION 70
7.1 CLIENT SIDE CODE 707.2 MOBILE SIDE CODE 75
8. EXPERIMENTATION RESULTS 89
9. SUMMARY AND CONCLUSIONS 92
10. FUTURE WORK 92
LIST OF FIGURES
FIGURE 3.1 COMMUNICATION ARCHITECTURE OF INTELLIGENT TAG MANAGEMENT SYSTEM
..........................................................................................................................................22FIGURE 3.2 IMPLEMENTATION OF INTELLIGENCE FOR SECURING THE COMMUNICATION
BETWEEN TAG AND MOBILE DEVICE................................................................................23FIGURE 3.3 PARAMETERS AND APPROPRIATE COUNTER MEASURES FOR ENSURING SECURITY
..........................................................................................................................................24FIGURE.3.4 SOFTWARE ARCHITECTURE FOR BUILDING INTELLIGENCE TO SECURE THE
INTELLIGENT TAG MANAGEMENT SYSTEM......................................................................27FIGURE 4.1 OVERVIEW OF THE INTELLIGENT TAG APPLICATION...........................................28FIGURE 4.2 PROCESS FLOW MODELING FOR SECURITY MANAGEMENT ON TAG SIDE...............29FIGURE 4.3 OVERVIEW OF THE INTELLIGENT TAG APPLICATION ON MOBILE SIDE...............32FIGURE 4.4 PROCESS FLOW MODELING FOR SECURITY MANAGEMENT ON MOBILE SIDE......34FIGURE 5.1 USE CASE DIAGRAM SHOWING FUNCTIONAL REQUIREMENTS OF SECURITY
MANAGEMENT...................................................................................................................38FIGURE 5.2 HARDWARE CLASS DIAGRAM OF SECURITY MANAGEMENT................................39FIGURE 5.3 SOFTWARE CLASS DIAGRAM OF THE SECURITY MANAGEMENT..........................41FIGURE 5.4 CLASS DIAGRAM INTERFACES OF HW AND SW COMPONENTS ON TAG SIDE......42FIGURE 5.5 USE CASE MODELING ON MOBILE SIDE...............................................................43FIGURE 5.6 HARDWARE CLASS DIAGRAM OF IDENTIFICATION SYSTEM ON MOBILE SIDE.....44FIGURE 5.7 SOFTWARE CLASS DIAGRAM OF SECURITY MANAGEMENT ON MOBILE SIDE......45FIGURE 5.8 CLASS DIAGRAM INTERFACES HW AND SW COMPONENTS ON MOBILE DEVICE
SIDE...................................................................................................................................46FIGURE 6.1: TAG SIDE DESIGN DIAGRAM................................................................................47FIGURE 6.2 HARDWARE BLOCK DIAGRAM OF INTELLIGENT TAG............................................49FIGURE 6.3 OBJECT MODELING DIAGRAM OF TAG DESIGN....................................................50FIGURE 6.4: PIN DIAGRAM OF ARM CONTROLLER.................................................................52FIGURE 6.5: GENERAL TIMING DIAGRAM................................................................................53FIGURE 6.6: ADDRESS TIMINGS................................................................................................53FIGURE 6.7: DATA WRITE CYCLES..........................................................................................53FIGURE 6.8: DATA READ CYCLES; DBE IS HIGH DURING THE CYCLE SHOWN......................54FIGURE 6.9: DATA BUS CONTROL............................................................................................54FIGURE 6.10: CONFIGURATION DIAGRAM................................................................................54FIGURE 6.11: EXCEPTION TIMING............................................................................................54FIGURE 6.12: CLOCK TIMING OF ARM7..................................................................................55FIGURE 6.13: UART INTERFACING PIN OUT DIAGRAM...........................................................56FIGURE 6.14: TIMING DIAGRAM OF UART..............................................................................56FIGURE 6.15: PIN DIAGRAM OF EEPROM...............................................................................57FIGURE 6.16: I2C PROTOCOL IC FOR INTERFACING EEPROM...............................................58
FIGURE 6.17: TIMING DIAGRAM FOR I2C.................................................................................58FIGURE 6.18: USB INTERFACE.................................................................................................60FIGURE 6.19: LCD 2X16 WITH ITS PIN DESCRIPTION..............................................................61FIGURE 6.20: TIMING DIAGRAM OF LCD.................................................................................61FIGURE 6.21: 4X4 MATRIX KEYPAD........................................................................................62FIGURE 6.22: SHOWS THE TIMING DIAGRAM OF MATRIX KEYPAD.........................................62FIGURE 6.23: POWER SUPPLY CIRCUIT....................................................................................64FIGURE 6.24: BLUETOOTH MODULE UART INTERFACED.......................................................65FIGURE 6.25: BLUETOOTH MODULE INTERFACED WITH LPC2148.........................................66FIGURE 6.26: XBEE WI-FI MODULE.........................................................................................67FIGURE 6.27 SOFTWARE OBJECT INTERACTION ON THE TAG SIDE........................................68FIGURE 6.28 INTERACTION BETWEEN THE HW OBJECTS AND SW OBJECTS ON THE TAG SIDE
..........................................................................................................................................69FIGURE 8.1 ATTACK ON THE TAG SIDE....................................................................................90FIGURE 8.2 ATTACK ON THE MOBILE SIDE..............................................................................90
LIST OF TABLES
TABLE 1-1 KEY WORDS AND THEIR DEFINITIONS OF THE SECURITY MECHANISMS...................3TABLE 1-2 SELECTING A SECURE PIN.......................................................................................9TABLE 4-1 HARDWARE REQUIREMENTS ON TAG SIDE............................................................30TABLE 4-2 FUNCTIONAL REQUIREMENTS OF TAG THROUGH USE CASES.................................31TABLE 4-3 BUSINESS OBJECTS THROUGH CLASSES.................................................................32TABLE 4-4 HARDWARE REQUIREMENTS ON MOBILE SIDE......................................................35TABLE 4-5 FUNCTIONAL REQUIREMENTS THROUGH USE CASES.............................................35TABLE 4-6: MOBILE DEVICE BUSINESS OBJECTS THROUGH CLASSES.....................................36TABLE 5-1: HARDWARE ANALYSIS OF THE TAG......................................................................37TABLE 5-2: USE CASE DESCRIPTION........................................................................................38TABLE 8-1 EXPERIMENTAL RESULTS FOR COUNTER ATTACKING METHODS............................91
1. INTRODUCTION
The Intelligent Tag Management System consists of Mobile Devices (as Tag readers),
group of Tags and some sort of middleware integrated in it. The tag is attached to an object to
be tracked. It picks up signals from a reader or scanner and then return the signals, usually
with some additional data like a unique serial number or other customized information. In
this, Mobile Device is being used as Tag reader. So, the Mobile Device has to communicate
with Tags by using various wireless communication standards like Bluetooth, WI-Fi, NFC
etc. As the medium is through wireless, the attackers have scope to compromise the
communication between Mobile device and Tags. Hence, the aspects of security are getting
highlighted in these types of systems.
1.1 Terminology and definitions
Terminology
Tag:
A tag is a combination of a microchip and antenna that can be programmed with
information to identify items and transmit that information to a receiver. Some tags can also
receive new information, such as location information during shipment.
Active Tags:
Active Tags use batteries as a partial or complete source of power to boost the effective
operating range of the tag and to offer additional features over passive tags, such as
temperature sensing.
Reader:
A device used to communicate with RFID tags. The reader has one or more antennas,
which emit radio waves and receive signals back from the tag. The reader is also sometimes
called an interrogator because it interrogates the tag.
Authorization
Authorization is finding out if a user, once identified, is permitted to have the resource.
This is usually determined by finding out if that user is a part of a particular group, if that
user has paid admission, or has a particular level of security clearance. Authorization is
equivalent to checking the guest list at an exclusive party, or checking for your ticket when
you go to the opera.
Authentication
Authentication is any process by which you verify that someone is who they claim they
are. This usually involves a username and a password, but can include any other method of
demonstrating identity, such as a smart card, retina scan, voice recognition, or fingerprints.
Authentication is equivalent to showing your driver’s license at the ticket counter at the
airport.
Encryption
Encryption is the conversion of data into a form, called a cipher text, which cannot be
easily understood by unauthorized people. Simple ciphers include the substitution of letters
for numbers, the rotation of letters in the alphabet, and the "scrambling" of voice signals by
inverting the sideband frequencies. Complex ciphers work according to sophisticated
computer algorithms that rearrange the data bits in digital signals.
Decryption
Decryption is the process of converting encrypted data back into its original form, so it
can be understood. In order to easily recover the contents of an encrypted signal, the correct
decryption key is required. The key is an algorithm that undoes the work of the encryption
algorithm.
Bluetooth
Bluetooth is a wireless technology for creating personal networks operating in the 2.4
GHz unlicensed band, with a range of 10 meters. Networks are usually formed ad-hoc from
portable devices such as cellular phones, handhelds and laptops. Unlike the other popular
wireless technology, Wi-Fi, Bluetooth offers higher level service profiles, e.g. FTP-like file
servers, file pushing, voice transport, serial line emulation, and more.
Wi-Fi
Wi-Fi short for "wireless fidelity" is a term for certain types of wireless local area
network (WLAN) that uses specifications in the 802.11 family. The term Wi-Fi was created
by an organization called the Wi-Fi Alliance. It is a mechanism for wirelessly connecting
electronic devices. A device enabled with Wi-Fi, such as a personal computer, video game
console, Smartphone, tablet, or digital audio player, can connect to the Internet via a wireless
network access point.
Access Points
A wireless access point (WAP) is a device that allows wireless devices to connect to a
wired network using Wi-Fi, Bluetooth or related standards. The WAP usually connects to a
router (via a wired network), and can relay data between the wireless devices (such as
computers or printers) and wired devices on the network. Wireless security includes: WPA-
PSK, WPA2, IEEE 802.1x/RADIUS, WDS, WEP, TKIP, and CCMP (AES) encryption.
Unlike some home consumer models, industrial wireless access points can also act as a
bridge, router, or a client.
Peer-to-peer Networks
A peer-to-peer (P2P) network is created when two or more PCs are connected and share
resources without going through a separate server computer. A P2P network can be an ad hoc
connection in which a couple of computers can be connected via a Universal Serial Bus to
transfer files. A P2P network also can be a permanent infrastructure that links half-a-dozen
computers in a small office over copper wires. Or a P2P network can be a network on a much
grander scale in which special protocols and applications set up direct relationships among
users over the Internet.
DefinitionsTable 1-1 Key words and their definitions of the security mechanisms
S.No Key Words Definition1 ACL Asynchronous Connection-Less is a communication protocol used as
a transmission link for data communication in the Bluetooth system with access code (72bit) + packet header (54bit) + payload + CRC (16bit).
2 SCO Synchronous Connection-Oriented link is a point-to-point link between the master and specific slave. It has symmetric 64 kbps rate, typically used for voice transmission.
3 WEP WEP is a standard network protocol that adds security to 802.11 Wi-Fi networks at the data link layer
4 WPA Wi-Fi Protected Access (WPA) and Wi-Fi Protected Access II (WPA2) are two security protocols developed by the Wi-Fi Alliance to secure wireless computer networks implemented in the majority of the IEEE 802.11i standard.
1.2 Theoretical Foundation
Several communication protocols are being used for establishing communication between
various mobile devices. As they involve communication within the wireless medium, several
security issues will be considered to provide secured and uninterruptable data transfer
between the devices. The different communication protocols, the vulnerabilities encountered
in the respective protocols and their possible countermeasures are presented here.
1.2.1 Bluetooth
Bluetooth devices operate on an unlicensed frequency band between 2.4 to 2.4835 GHz.
To avoid interference with other devices operating on the same band, the technology uses a
frequency hopping algorithm with 1600 frequency hops per second. So it can be implemented
to operate in noisy frequency environments also. The time during which devices operate in a
certain frequency is called a time slot and is 625 microseconds in duration. Units in a Piconet
change frequency at the same time on command from the master unit, based on a pseudo-
random hopping sequence. The frequency band is broken up into 79 channels spaced 1 MHz
apart. Data is transmitted in frames, which can span 1, 3 or 5 slots.
There are two types of connection: ACL (asynchronous connectionless) and SCO
(synchronous connection-oriented).
The first type of connection is used to transfer data that can be handled at any time. A
slave unit can have only one ACL connection to the master unit. The second link type is used
for transferring data in real time, e.g. for transmitting voice data. A slave unit can have up to
3 SCO links with the main unit, each with a rate of 64 kb/sec.
1.2.1.1 Security Mechanisms
According to the specification, user information can be protected by encrypting
transmitted data, while the access code and the packet header are transmitted over an
unencrypted channel. Data is encrypted using the E0 stream cipher. Attacks at the
communication link level are therefore clearly possible. Bluetooth can operate in one of three
Security Modes:
Unprotected (no security): In this mode no encryption or authentication is used, while the
device itself operates in a non-discriminating, i.e. in broadcasting (promiscuous) mode.
Application/service based (L2CAP): In this mode, once a connection is established,
Security Manager performs authentication, thereby restricting access to the device.
Link layer PIN authentication/ MAC address encryption: Authentication is performed
prior to a connection be established. Although transparent encryption is used, even in this
mode the device can be compromised.
Bluetooth security is based on the generation of keys using a PIN code, which can be 1 to
16 bytes in length. Most devices currently use 4-byte PINs. First, the E2 algorithm is used to
generate a 16-byte Link Key based on the PIN code. Then an Encryption Key based on the
Link Key is calculated using the E3 algorithm. The first key is used for authentication, the
second for encryption.
The authentication process is as follows:
1. The device initiating the connection sends its address (BD_ADDR). This 48-bit address is unique, like a network adaptor's MAC address. A device's manufacturer can be determined by this address.
2. In response a random 128-bit challenge sequence is sent (AU_RAND).3. Both devices generate an authentication response string called SRES based on
BD_ADDR, Link Key and AU_RAND. 4. The device trying to establish the connection sends its SRES. 5. The other device compares the SRES received with its own and if the two strings match,
establishes a connection.
1.2.1.2 Bluetooth security features
Basically Bluetooth offers two modes to connect with other Bluetooth devices. They are:
Discoverable Mode: It is a feature of Bluetooth which is used to make the visible in order to
find it. If the device is invisible or hidden, then no other device can find it. When the device
is in visible mode it is very easy to find it using any Bluetooth enabled devices like PC,
Laptop etc.
Non-Discoverable Mode: With this feature the Bluetooth device cannot found by any other
Bluetooth enabled device. It can be only visible for those devices which have its MAC
address and have information about this device.
1.2.1.3 Bluetooth security issues
There was number of ways in which Bluetooth Security can be penetrated which is
because of the little processing capability of the devices. The major forms of attacks that can
be performed on the Bluetooth communication are as follows:
1. Blue jacking: Blue jacking involves the hacker making an attempt to send a phone
contact or business card to another nearby phone. The ‘name' field of the contact can be
misused by replacing it with a suggestive text so that the target device reads it as a part of
intimation query displayed on its screen. This may be thought of as equivalent to spam e-
mail since both are unsolicited messages displayed on recipients' end without consent,
and by exploiting the inherent nature of communication. In this, the attacker uses the
Bluetooth to send the messages, which is an example of push attack.
Devices generally require pairing or prompt the owner before they allow a remote
device to use any or most of their services. Some devices, such as mobile phones, usually
accept OBEX business cards and notes without any pairing or prompts. This is why the
regular Blue Jacking attacks use the OBEX Business card protocol. But we can dispatch
readable messages even easier. After we have the Bluetooth address of the "victim", we
can simply require pairing to the remote device, and the user will get prompt in order to
allow or deny the process. When this happens, the remote device receives the name of the
device that initiated the pairing sequence. In this case, it's the name of our device. So all
we need to do is to set a message instead of our Bluetooth device name, and initiate a pair
request to the remote device, the "victim".
2. Blue Snarfing: Blue Snarfing goes a step further and actually accesses or steals data like
messages, calendar, phone book etc., from the target device in an unauthorized manner
which includes bypassing the usual paring requirement, while leaving no trace of the
attack. Any device with its Bluetooth connection turned on and set to “discoverable” (able
to be found by other Bluetooth devices in range) can be attacked. By turning off this
feature you can be protected from the possibility of being Blue Snarfed. But here, the
problem is bigger since there have been reports of the tools that use methods such as
device address guessing and brute force in order to break-in, even when device is
configured as ‘invisible'.
In this attack, attacker does not send anything to take out the data, thus this is known
as pull attack. This attack uses the OBEX (OBject EXchange) protocol, by this it forcibly
pulls out the data from the victim’s phone. Hence this kind of attack is also popularly
known as OBEX pull attack.
3. Blue Bugging: The next level of sophistication in Bluetooth hacking is Blue Bugging,
where the victim device is controlled by the attacker, who sends commands to perform
actions as if having physical access to the device. Thus, a hacker could eavesdrop on
phone conversations, place phone calls, send and receive text messages, and even connect
to the Internet. This is functionality analogous to Trojans. The tools for Blue Bugging
include ones that run off the PCs, which means laptops with high range Bluetooth
connectivity, which makes things even worse. The Blue Bug security loophole allows to
issue AT commands via a covert channel to the vulnerable phones without prompting the
owner of this phone.
4. PIN Cracking: A sniffer records Bluetooth packets and can decode the packets to
determine the information contained in them. If you capture packets that are involved in
the process of authenticating two Bluetooth devices, you can use information from those
packets to determine the user PIN. The packet data doesn't contain the PIN itself, but it
contains information derived from the PIN. With some number crunching, you can
recover the PIN.
5. Denial of Service Attack: A denial of service attack can be carried out as flooding
messages in Bluetooth devices. In flooding denial of service attack unnecessary data is
sent as much as possible to a victim. As a result, network bandwidth is wasted, disk space
is filled with unnecessary data or processing power is spent for useless purposes.
6. Eavesdropping: Eavesdropping on Bluetooth packets is largely depended upon two
variables, the MAC address and the clock. The MAC address is a unique identifier
allocated to the each device. The clock is a 3.2 kHz counter stored in a 28 bit number, and
it wraps approximately every 23 hours. Bluetooth uses frequency hopping over 79
channels in order to minimize interference and (usually) hops once every 625 micro sec,
sending one packet per channel. The hopping sequence is determined by the MAC
address of the master device and its clock.
The second hurdle to eavesdropping on data carried in Bluetooth connections is that
packets are whitened (scrambled) in order to improve error resilience and security. The
whitening is determined by six bits of the master device's clock. Thus, in order to
eavesdrop on a Bluetooth connection two pieces of information are needed: the MAC
address and clock of the master device. With this information, one can calculate the
hopping sequence and tune to the correct radio channel, and then un-whiten the received
packets.
7. Man-in-the-Middle Attack: In this attack, an attacker who has already obtained the link
keys and unit keys (BD_ADDR) of two Bluetooth devices can intercept the
communication and initiate new communications to both devices posing as the other. The
attacker impersonates the victim devices to each other thus the victim devices believe
they are communicating directly with each other.
In another person-in-the-middle attack scenario, vulnerabilities involving memory
constrained devices are exploited. Memory constrained devices rely on its unit key for
encryption to reduce the number of keys it is required to store. An un-trusted device, call
it C, can establish communications with the memory constrained device, call it A. This
connection may have other purposes other than obtaining the unit key for the purposes of
the attack. In any case, the memory constrained device, A, has shared its unit key with the
un-trusted device, C. When device A initiates communications with a differing device,
call it B, device C can use the obtained unit key and spoof an address to monitor the
communications between device A and B without the either party realizing it.
1.2.1.4 Counter-measures for attacks on Bluetooth
1. Blue Jacking:
1.1 Disable Bluetooth: Only enable Bluetooth when it is needed and disable it while in
crowded places or upon receiving an anonymous message.
1.2 Employ Undiscoverable/Hidden mode: Configure Bluetooth settings and putting the
Bluetooth device in the Undiscoverable or Hidden mode is a more practical
countermeasure. A Bluetooth device can be set to this option after pairing it with any
Bluetooth-enabled devices or accessories in use. This ensures that when an attacker
(who is not in the allowed list) searches for Bluetooth devices, your Bluetooth device
will not show up. At the same time, you can continue using Bluetooth to connect to
other devices.
2. Blue Snarfing:
2.1 Updating the devices: It's not Bluetooth itself that leaves the devices vulnerable to
Blue Snarfing, but certain quirks in older Bluetooth-enabled phones and PDAs. Early
models often came with a default discoverable mode; because manufacturers thought
most people wouldn't want to go through complex security procedures to share
business cards and phone numbers wirelessly. These loopholes have been eliminated
in most new device models.
2.2 Hiding the Devices: Make it a regular practice to switch your Bluetooth-enabled
devices to non-discoverable mode anytime you're not actively exchanging data with a
trusted device, or when you're in an unknown hot-spot area.
2.3 Longer pairing code: The Bluetooth protocol allows 16-digit pairing codes.
Unfortunately, many applications continue to use only 4-digit pairing codes. This
makes Bluetooth-enabled devices using a short pairing code vulnerable to brute force
attacks executed with the help of a Bluetooth-enabled computer. Hence, an attacker
can use brute force to crack the pairing code and execute further malicious activities.
Unfortunately, most people have the tendency to select and use short pairing codes.
3. Blue bugging: Mobile operators must establish a gateway level security solution in the
network to be able to flexibly filter the traffic. A real-time up-to-date antivirus client is
required in all smart phones, with a mechanism for automatically delivering updates
directly to the device.
4. PIN Cracking: Trivial PINs such as “0000” and “1234” should be avoided. A secure PIN
is approximately 64 bits in length, making it infeasible to break under the attack. The
following table.1 is a recommendation for selecting a secure PIN.Table 1-2 Selecting A Secure PIN
Character set used Recommended PIN length Minimum PIN length0-9 (10 characters) 19 characters ( = 63 bits) 12 characters ( = 40 bits) 0-9 A-Z (36 characters) 12 characters ( = 62 bits) 8 characters ( = 41 bits) 0-9 A-Z, a-z (62 characters) 11 characters ( = 65 bits) 7 characters ( = 42 bits) (Printable) ASCII (95 characters)
10 characters ( = 66 bits) 6 characters ( = 39 bits)
5. Denial of Service Attack:
5.1 When the pairing message is sent by one device: Denial of Service attack can be
avoided by storing the address of Bluetooth device, which is failed to authenticate
more than predefined number of unsuccessful attempts.
5.2 When the pairing messages sent by more than one device: In this type of attack
also if in particular time duration, the number of unsuccessful pairing is more than the
particular predicted number, the Bluetooth device can guess that the Denial of Service
attack is attempted. It can send the alert signal to the security manager to stop the
interaction with these devices.
5.3 When the attacker is changing the Bluetooth address of itself with another
Bluetooth address: In this type of attack if the attacker changes his Bluetooth address
with another Bluetooth device, he can send the wrong authentication response in reply
to the message sent by the verifier. The verifier will first update its failed
authentication device list by adding the address of the device which is not at present
in try to make the pairing but the attacker will use its address. The verifier’s device
itself sends message to the device after some time duration to authenticate the device.
If it is the right device, it will make the connection, otherwise it will fail to
authenticate.
6. Eavesdropping: Select the lowest power level on Bluetooth devices, so that user’s
transmission remains within a secure perimeter. Avoid pairing with wireless devices that
have an extended transmission range of 100 meters, because the Bluetooth signal could be
detected within and up to a 30-foot range.
Create a new PIN code for each Bluetooth pairing session with another device. If an
eavesdropping attack occurs on the Bluetooth device, and the PIN code that often uses
could easily be detected, and used by the attacker to pair with your wireless device.
7. Man-in-the-Middle Attack: While one of the initiating or non-initiating devices is trying
to connect with each other, the attacker will send wrong signals which leads to the
corruption of the original signal. So, the legitimate users thinks that, there may be some
sort of genuine jam in the network and gets frustrated, and deletes all the information
about the other devices. We have to stop these jamming attacks which are attacking PHY
layer. By considering the prevention schemes of jamming attack, we can avoid the MITM
attack. After that, the process of SSP will be followed for the secure communication. The
prevention schemes of PHY layer are also called anti-jamming techniques.
1.2.2 Wi-Fi
Wi-Fi means Wireless Fidelity technology and stands for all those technologies that fall
under the specifications of IEEE 802.11 including 802.11a, 802.11b and 802.11g. The
association of the term Wi-Fi with various technologies is merely because of the promotions
made by the Wi-Fi Alliance.
It is commonly known as Wireless LAN, in which high frequency radio waves are
required for transmission of data from one place to another. It operates on several hundred
feet between two places of data transmission.
1.2.2.1 Wireless LAN Architecture
Wireless LAN architecture is composed of different components which help in
establishing the local area network between different operating systems. These components
are very essential for Wi-Fi architecture.
1. Access Points: A special type of routing device that is used to transmit the data between
wired and wireless networking device is called as AP. It is often connected with the help
of wired devices such as Ethernet. It only transmits or transfers the data between wireless
LAN and wired network by using infra structure mode of network. One access point can
only support a small group of networks and works more efficiently. It is operated less
than hundred feet. It is denoted by AP.
2. Clients: Any kind of device such as personal computers, Note books, or any kind of
mobile devices which are inter linked with wireless network area referred as a client of
wireless LAN architecture.
3. Bridge: A special type of connectors which is used to establish connections between
wired network devices such as Ethernet and different wireless networks such as wireless
LAN. It is called as bridge. It acts as a point of control in wireless LAN architecture.
1.2.2.2 Wi-Fi Security Threats
1. Data Interception: Today, it’s widely understood that data sent over Wi-Fi can be
captured by eavesdroppers easily, within a few hundred feet; even farther with directional
antennas. Fortunately, all Wi-Fi certified products now support AES-CCMP data
encryption and integrity. Unfortunately, there are still legacy products that only speak
TKIP, and many WLANs are configured to accept both AES and TKIP. But TKIP is
vulnerable to message integrity check (MIC) attacks that allow a limited set of spoofed
frames to be injected – for example, ARP. Although resulting risks are modest, the
writing is on the wall: The time has come to retire TKIP and require AES-CCMP.
2. Denial of Service: WLANs are inherently vulnerable to DoS. Everyone shares the same
unlicensed frequencies, making competition inevitable in populated areas. The good
news: As enterprise WLANs migrate to 802.11n, they can use channels in the larger, less-
crowded 5 GHz band, reducing “accidental DoS”. Moreover, contemporary access points
(APs) can auto-adjust channels to circumvent interference. But that still leaves DoS
attacks: Phony messages sent to disconnect users, consume AP resources, and keep
channels busy. To neutralize common DoS attack methods like Death Floods, look for
newer products that support 802.11w management frame protection.
3. Rouge Access Points: Business network penetration by unknown, unauthorized APs has
long been a top worry. Fortunately, most enterprise WLANs now use legitimate APs to
scan channels for possible rogues in their spare time. Unfortunately, verifying “true
rogues” by tracing their wired network connectivity is a skill that ordinary WLAN gear
has yet to perfect. Without accurate classification, automated rogue blocking is a risky
proposition. To not just detect, but effectively mitigate rogue APs, deploy a Wireless IPS
that can reliably differentiate between harmless neighbors, personal hotspots, and
network-connected rogues that pose real danger, taking policy-based action to trace,
block, and locate the latter.
4. Wireless Intruders: Wireless IPS products like Motorola Air Defense, Air Magnet, and
Air Tight can also detect malicious Wi-Fi clients operating in or near a business’ airspace.
However, truly effective defense requires up-to-date, properly deployed WIPS sensors. In
particular, 802.11a/b/g sensors must be updated to monitor new 5 GHz channels
(including 40 MHz channels), parse 802.11n protocols, and look for new 802.11n attacks.
Furthermore, because 802.11n clients can connect from farther away, WIPS sensor
placement must be reviewed to satisfy both detection and prevention needs.
5. Evil Twin APs: Fraudulent APs can easily advertise the same network name (SSID) as a
legitimate hotspot or business WLAN, causing nearby Wi-Fi clients to connect to them.
Evil Twins are not new, but easier-to-use hacker tools have increased your risk of running
into one. Tools like Karmetasploit can now listen to nearby clients, discover SSIDs
they’re willing to connect to, and automatically start advertising those SSIDs. Once
clients connect, DHCP and DNS are used to route client traffic through the Evil Twin,
where local (phony) Web, mail, and file servers execute man-in-the-middle attacks. The
only effective defense against Evil Twins is server authentication, from 802.1X server
validation to application server certificate verification.
6. Wireless Phishing: In addition to the above man-in-the-middle application attacks,
hackers continue to develop new methods to phish Wi-Fi users. For example, it’s
possible to poison Wi-Fi client Web browser caches, so long as the attacker can get into
the middle of a past Web session – such as by using an Evil Twin at an open hotspot.
Once poisoned, clients can be redirected to phishing sites long after leaving the hotspot,
even when connected to a wired enterprise network. One technique for mitigating this
threat is to clear your browser’s cache upon exit. Another possibility is to route all
hotspot traffic (even public) through a trusted (authenticated) VPN gateway.
1.2.2.3 Counter measures for Wi-Fi vulnerabilities
1. Use of Encryption: The most effective way to secure your wireless network from
intruders is to encrypt, or scramble, communications over the network. Most wireless
routers, access points, and base stations have a built-in encryption mechanism. If your
wireless router doesn’t have an encryption feature, consider getting one that does.
Manufacturers often deliver wireless routers with the encryption feature turned off. You
must turn it on.
2. Use anti-virus software and firewall: Devices on a wireless network need the same
protections as any computer connected to the Internet. Install anti-virus and anti-spyware
software, and keep them up-to-date. If the user’s firewall was shipped in the “off” mode,
it must be turned on.
3. Turn off identifier broadcasting: Most wireless routers have a mechanism called
identifier broadcasting. It sends out a signal to any device in the vicinity announcing its
presence. You don’t need to broadcast this information if the person using the network
already knows it is there. Hackers can use identifier broadcasting to home in on
vulnerable wireless networks. Disable the identifier broadcasting mechanism if your
wireless router allows it.
4. Change the default identifier on router: The identifier for your router is likely to be a
standard, default ID assigned by the manufacturer to all hardware of that model. Even if
your router is not broadcasting its identifier to the world, hackers know the default IDs
and can use them to try to access your network. Change your identifier to something only
you know, and remember to configure the same unique ID into your wireless router and
your computer so they can communicate. Use a password that’s at least 10 characters
long: The longer your password, the harder it is for hackers to break.
5. Change router’s pre-set administrator password: The manufacturer of your wireless
router probably assigned it a standard default password that allows you to set up and
operate the router. Hackers know these default passwords, so change it to something only
you know. The longer the password, the tougher it is to crack.
6. Allow only authorized computers to access wireless network: Every computer that is
able to communicate with a network is assigned its own unique Media Access Control
(MAC) address. Wireless routers usually have a mechanism to allow only devices with
particular MAC addresses access to the network. Some hackers have mimicked MAC
addresses, so don’t rely on this step alone.
7. Turn off wireless network: Hackers cannot access a wireless router when it is shut
down. If you turn the router off when you’re not using it, you limit the amount of time
that it is susceptible to a hack.
1.3 Problem Definition
In an intelligent tag management system, a Tag has to be in communication with the
remote Host i.e., Mobile Device. The communication between mobile device and intelligent
tags can be effected by using any of communication mechanism which includes Bluetooth,
Wi-Fi, etc. When communication is effected using these modes, the signals are emitted which
are available in a local area leading to huge vulnerability for attacking.
Several of security enforcement mechanisms are available to ensure security of the
devices. These mechanisms however will be active from the system startup and they don’t get
disabled even with the absence of attacks on the communication link. With the continuous
enabling of these security mechanisms, the unimportant tasks will get the maximum share of
the system functionality. Hence the system overhead will increase and the performance of the
system will degrade.
So there is a need for developing intelligence to the Tag for securing the communication
link between the Tag and the mobile device. By building intelligence to the system, it will
detect whether any attacks are being performed and enables the appropriate counter-attacking
mechanisms.
1.4 Scope
The scope of the project consists of the following individual elements of the research and
development project:
1. Conducting the literature survey of the various counter-attacking mechanisms against the different attacks on the communication link between a Tag and Mobile device.
2. Analysis of the various counter-measures with respect to securing the communication link and performance of the system.
3. Investigation of new security mechanism that builds intelligence into the Intelligent Tag Management System.
4. Investigation of software architecture that implements the proposed security mechanism.
5. Develop intelligent TAG related embedded system by using the proposed security mechanism and its software architecture.
6. Develop an application on the mobile device side which helps in establishing communication in between the TAG and the mobile device.
7. Experimenting with the new embedded systems and posting the experimental results considering both the applications on the TAG and the mobile device side.
8. Drawing conclusions.
1.5 Methodology
The methodology used for this project includes two phases, the Research Phase followed
by the Development Phase.
Research Phase
The following methodology is used during the research phase
1. Conduct literature survey related to various attacks that can be performed on the communication link between a Tag and the Mobile device and the corresponding counter-measures that can be applied to counter those attacks.
2. Investigate and develop efficient security mechanism which builds intelligence to the system.
3. Conduct literature survey related to software architecture and find the suitability of the same for implementing the investigated security mechanisms.
4. Investigate and develop suitable software architectures
Development Phase
1. Conduct requirement engineering for building intelligence to the system for securing the communication link between a Tag and the Mobile device.
2. Analyze and design an embedded system considering both Hardware and software considering both TAG and the remote HOST
3. Develop software that considers the investigated security mechanism and its software architecture.
4. Test the security mechanism and publish the results.
1.6 Limitations
The investigated security mechanism that builds intelligence to the Intelligent Tag and its
software will be tested and verified only using the ARM7 Controller on the Tag side and the
application developed for the Android OS on the Mobile device (Host) side.
2. LITERATURE SURVEY
Various counter-measure protocols have been proposed to address the security concerns
of systems that communicate with the tags.
“Security and privacy aspects of low-cost radio frequency identification systems” by
Dieter Hutter et al. [1] - suggested a model such that each tag will transmit a randomly
chosen key by encrypting the key value with the Hash function computations i.e. h (key).
Only the reader with exact corresponding key will be able to respond to a tag and then only
the specific tag will transmit the ID value of it. But in his proposal the ID value is static. So,
there is maximum chance for the adversary to trace that particular tag and to perform
eavesdropping on the communication between reader and tag. Later he suggested an
advanced version of his previous protocol by implementing the randomness to the key value.
But it was not providing forward security for the communication between them and is
vulnerable to replay attacks.
“Cryptographic approach to “privacy-friendly” tags” by Miyako Ohkubo,
Koutarou Suzuki and Shingo Kinoshita [2] - used Hash chains to propose a protocol. It
mainly concentrated on the implementation of forward security such that the data sent by the
tag is needed to be secured even when tags have been compromised to reveal the information
within the tag. But it has not succeeded because of the computational overhead involved in
the calculation of the hash chains at the back-end database.
“Hash-based enhancement of location privacy for radio-frequency identification
devices using varying identifiers” by Dirk Henrici and Paul Müller [3] - suggested the
usage of one way hash functions such that the location secrecy of a tag can be enhanced by
changing the identifier values of that tag for every reading instant by using a simple message
exchange. The adversary will be successful in making a tag undetectable to get access to
communicate with its reader by blocking the communication using DOS) denial of service
attacks or by employing the Kill Tag approach.
“A lightweight RFID protocol to protect against traceability and cloning attacks” by
Tassos Demetrio [4] - proposed a protocol which ensures privacy and resistance to tag
cloning. In this scheme the secret key value will be shared between tag and reader such that it
will be modified for successful successive identification. In addition the authentication is
verified on both reader and tag sides using a single secret key. But tracking of tag is still
possible because a value transmitted by the tags will be remained static between two
successful identifications. Hence, it is vulnerable to a database de-synchronization attack.
“Efficient authentication for low-cost RFID systems” by Young J. Hwang et.al [5] -
suggested an authentication protocol similar to Demetrio’s, which consists of two one way
hash functions that can be used to provide privacy for low cost RFID tags whose constraints
are low power sources, low die-size and limited computational capabilities. It is framed as
Low Cost Authentication Protocol (LCAP). But as said earlier these types of low
computational supporting tags are vulnerable to replay attacks, database de-synchronization
attacks and tracking attacks.
“Privacy and security in library RFID: Issues, practices, and architectures” by
Molnar and Wagner [6] - suggested a model in which a tag and a database should have to
share two secret values called identifier of tag and secret key. These values along with two
words, used especially for computations generated by the reader and the tag are fed into a
pseudorandom function. This scheme ensures privacy and protection against tracking attacks
but does not offer forward security.
“An approach to security and privacy of RFID system for supply chain” by Zhe
(Alex) Xiang et al. [7] - suggested a scheme which is used to exploit randomized access
control and that should be able to prevent hostile tracking and MIM (Man in the middle)
attacks. This scheme offers limited computational overhead and it is useful for systems with
several RFID tags. But it does not offer forward security and is vulnerable to replay attacks.
“Blue Sniff: Eve meets Alice and Bluetooth” by Dominic Spill et.al [8] - suggested
that when two wireless devices are intended to communicate with each other using various
communication standards like Bluetooth, Wi-Fi, NFC etc, a pairing procedure is necessary to
ensure the privacy of a system. This can be achieved by using necessary encryption at link
layer level. But this method will not yield good results to the user and is vulnerable while
attacker performs eavesdropping on the pairing procedure.
Dr Sastry et.al [9], [10] has proposed a security mechanism that implements the
intelligence to sense the situations of attacking and bring into the scope the counter attacking
mechanisms. The counter attacking mechanisms must only come into play at the time when
an attack is initiated. The counter attacking mechanisms are not to be inbuilt as in-stream
procedures as it effects the response time and as such both the TAG and the mobile devices
are short in resources and also the components of ES solution are basically slow devices and
the permanent residence and inline execution of any of the code actually hampers the design
parameters of the embedded systems.
3. RESEARCH FINDINGS3.1 Building intelligence for securing the communication between the Tags
and the Mobile Devices3.1.1 Summary of Findings
Tag is a small embedded system meant for identification of an object to which it is
attached and in addition the TAGS can be made to be intelligent such that they can identify
its own location, alert the master about an event occurring in its vicinity, sensing tampering
with its own etc. For implementing any of the intelligence within the Tag, the TAG must
communicate with a remote HOST which in this case is the Mobile Device. Tags can
communicate with the HOST by using the available interface at either end for transmitting
the data from the TAG side and for receiving commands from the HOST. The
communication system as such is vulnerable and therefore can be attacked. In this thesis,
various attacking and counter attacking mechanisms are discussed and an efficient method of
securing the communication between the TAG and the HOST is presented.
3.1.2 Introduction
The Intelligent Tag Management System consists of Mobile Devices (as Tag readers),
group of Tags and some sort of middleware integrated in it. Tag is a small embedded system
which is combined with a communication module inbuilt in a compact package. The
packaging is structured to allow the tag to be attached to an object to be tracked. The tags
pick up signals from a reader or scanner and then return the signals, usually with some
additional data like a unique serial number or other customized information.
Although usage of Tags is promising and may potentially have numerous applications,
they are vulnerable and subject to a wide range of attacks due to its compromising nature in
security, difficulty in physical protection, absence of infrastructure and so on. For example,
an illegal reader attempts to compromise tag identity by sending out queries. If a tag
continuously reports its identity to every reader without any verification, then adversary can
easily track moving objects (e.g., products and persons) by recognizing tag IDs carried with
them. Thus, the potential vulnerability of easy tracking presents a serious obstacle to its
usage.
In this, Mobile Device is being used as Tag reader. So, the Mobile Device has to
communicate with Tags by using various wireless communication standards like Bluetooth,
Wi-Fi, NFC etc. As the medium is through wireless, the attackers have scope to compromise
the communication between Mobile device and Tags. Hence, the aspects of security are
getting highlighted in these types of systems. The key security issues that have to be
considered while establishing wireless communication between them are:
i) Confidentiality: Confidentiality means that the data can only be used by authorized users and/or parties.
ii) Integrity: Integrity means that the data cannot be modified and stored by adversaries during transfer.
iii) Availability: Availability means that the data is always available for authorized use.iv) Un-traceability: Un-traceability means that intruder cannot recognize readers and tags
which he has already seen, at another time or in another place.
All the above mentioned security related issues must be handled within the tags and the
mobile device with minimal of the hardware and software support. The securing of the
communication between the Target and the HOST must also be achieved considering various
types of communication protocols which include Wi-Fi, Bluetooth and NFC that too in
various combinations of protocol versions. In this thesis, various counter attacking
mechanisms have been proposed that takes into account various types of communication
combinations.
3.1.3 Investigations
In the aspect of providing security for an Intelligent Tag, the key requirements on both
sides i.e. on the host side and the target side are Bluetooth, WI-Fi communication modules.
As the Tag has to be made intelligent to perform functions like identifying its own location,
alerting the master about an event occurring in its vicinity, sensing tampering with its own
etc, the Tags should communicate with the host by using the available interface at either end
for transmitting the data from the Tag side and for receiving commands from the host. Figure
3.1 explains the communication architecture to facilitate communication between the
communicating devices.
The communication interfaces that are mainly needed to establish communication
between a Tag and a Remote Host (Mobile Device) are Bluetooth and Wi-Fi modules. As the
devices on either side have to communicate using the available and active interfaces on either
side, there is need for implementing the exchange of the protocol i.e., from Bluetooth to Wi-
Fi and Wi-Fi to Bluetooth. This can be achieved by introducing a protocol converter in
between Bluetooth and Wi-Fi interfaces in the communication architecture as shown in the
figure 3.1. Using this Protocol Converter, if the communication interfaces available on the
tag side and mobile device side are Bluetooth and Wi-Fi respectively, then the data needed to
be transmitted to mobile device will be converted from Bluetooth protocol to Wi-Fi protocol
by sending via protocol converter. In this way the conversion of protocol from Wi-Fi to
Bluetooth will be implemented.
Figure 3.1 Communication Architecture of Intelligent Tag Management System
The main issue here in the aspect of Intelligent Tag Management System is providing the
enough intelligence such that the system will be able to detect the presence of any possible
attack on the communication link between a Tag and the Mobile Device. This provision of
intelligence to the system can be achieved by developing Intelligence Module along with
Counter-measure Selector on both tag side and mobile device side. Figure.3.2 shows the
layout of implementing intelligence module and counter-measure selector on either side of
the system.
The functionality of Intelligence Module depicted in the figure.3.2 will be such that it
senses whether there is any possibility of performing any attack on the communication link
between a Tag and the Mobile Device. If it is confirmed then it passes the information about
the type of attack to the Counter-measure Selector. Then depending on the information about
the type of attack, the Counter-measure Selector will implement the appropriate counter
attacking mechanism to the available communication interface so that the communication
link between a Tag and the Mobile Device will be secured. If the Intelligence Module senses
that there is no possibility of attack on the communication link, then the Counter-measure
Selector will be gone to idle state and the communication establishment will be done without
any overhead of the counter attacking mechanism. Figure.3.3 depicts the provision of
intelligence to the system for sensing certain attacks based on specific parameters.
Figure 3.2 Implementation of Intelligence for Securing the Communication between Tag and Mobile Device
The intelligence can be provided to the system by utilizing the Intelligence Module so
that it can sense the possibility of any type of attack on the communication link and informs
the Counter-measure Selector to implement appropriate counter attacking mechanisms. To
perform this, the Intelligence Module is designed to sense the attacking based on certain
parameters.
If the device on either side wants to send / receive data through Object exchange Protocol
(OBEX), then the intelligence module senses the frequency of access to critical data elements
that govern the system. Frequency of accessing the critical data shall be recognized as an
attack and automatically the requirement of authentication shall be implemented.
In the case of device attacking if the intruder tries for a handshake with variable number
of frequencies the attack will be sensed and the counter measure of implementing RF
signatures will be enforced. The device attacking sensor recognizes that an attack is taking
place when frequency parameter is changing quite frequently while trying to establish the
handshake.
When a man in the middle tries to attack after the hand shake between the peer team takes
place, the transmission speeds varies drastically. The man in the middle is sensed while
monitoring the transmission speeds and if the transmission speed varies and differ from the
transmission speed established at the time of handshake an attack is sensed and immediately
the counter attacking mechanism like encryption and decryption shall be implemented in
which case some of the low priority services shall be suspended.
Figure 3.3 Parameters and Appropriate Counter Measures for Ensuring Security
When a communication link is established between two partners of the peer team, and
one partner is transmitting messages of very high speed are when the same message is
transmitted quite frequently, it will be sensed that an attack has been initiated, then a counter
attacking mechanism is effected that terminates the communication Link.
In the case replay attacks, sensing can be implemented by noticing the receipt of identical
responses but with varying speeds in which case session tracking tokens will be implemented.
The mechanism of session tracking will be enforced only when the repay attack is sensed [9].
3.1.4 Conclusions
The devices used in the intelligent TAG systems are limited in the resources. The peer to
peer communication between the TAG and the Mobile device is quite vulnerable. Adding the
entire required infrastructure to the TAG and the mobile device will require many resources
and providing such kind of resources is impracticable. Adding any software load for
implementing the permanent counter attacking measures will drastically effect the response
time and throughput of transacting between the mobile device and the TAG. Intelligence has
to be added for sensing any attack and the counter attacking measure should only come into
force when any of the attacks are initiated. Counter attacking measure should come into force
when an attack is initiated. When counter attacking is implemented the peer to peer
communication method will temporarily be slow down at which some of the un-important
services can be suspended.
3.2 Software Architecture for building intelligence to secure the communication between the Tags and the Mobile devices
3.2.1 Summary of Findings
The communication between a Tag and Mobile Device has to be established using
wireless communication standards like Bluetooth, Wi-Fi etc. As the communication medium
is wireless, there is a scope for the attacker to perform various attacks on the communication
between a Tag and Mobile Device. The authors of this thesis have focused on implementing
an intelligent mechanism to sense whether there is any possibility for attacking the
communication between a Tag and Mobile Device and activate appropriate counter-measures
against that attacks. To implement this proposed sensing and counter attacking mechanisms,
software architecture has been proposed and the same is used for development of the
software. Software has been developed and implemented and the intelligence built has been
tested by setting-up the experimental models. The experimental results have also been
presented in the thesis.
3.2.2 Introduction
The Intelligent Tag Management System involve Tags (as target devices) and Mobile
Devices (as Hosts) being communicated with using different wireless communication
standards like Bluetooth, WI-Fi etc. The security of the data transmission is the major
concern while using wireless medium. The attackers may perform various attacks like eaves
dropping; replay attacks, Man-in-the-Middle attacks etc., and make the operations of the
system affected.
To ensure that data transmission is done securely, several authors had proposed various
security mechanisms which includes authentication protocols, encryption / decryption
mechanisms etc. These mechanisms are acceptable in the context of providing efficient
security to the system. But implementing any of the counter attacking systems, the
performance of the embedded system will severely get affected due the addition of heavy
overhead on the computing requirements.
The literature survey revealed that many of the security enforcements have been proposed
and implemented that counter attack any of the attacking mechanism. All the methods
propose direct implementation of counter attacking system. The counter attacking code is
executed in line with the ES application code thus adding heavy overhead and most of the
times lead to performance bottlenecks. The author of this thesis have proposed a system that
builds intelligence into the applications to be able to sense the attacking and then only
activating appropriate counter attacking mechanism there by reducing overhead due to
implementation of inline security mechanisms.
In this thesis, a Software Architecture has been proposed for implementing the sensing of
attacking mechanisms and then implementing the related counter attacking mechanism. The
software architecture has been used for the development of software that implements the
intelligent security enforcement system. The software has been implemented and experiments
have been conducted and the experimental results have been published. The experimental
results have shown that the sensing and implementing mechanisms have not only provided
adequate security but also resulted in reducing the overhead on computing requirements.
3.2.3 Investigations
The software architecture for implementing security mechanism by building Intelligence
to the tag is shown in figure.3.4 using 3-tier architecture. In tier I all modules related to
intelligent tag application shall be made to be resident. The overall task execution is
implemented within the main control logic which is resident in the tier II. The main task is
designed to incorporate all real time functions using µCos operating system. The software
components through which communication is effected either through Wi-Fi or Bluetooth are
represented as communication module situated in tier II. It can be invoked through the
Controller module. The communication modules related to remote mobile HOST are situated
in tier III. Communication modules which are in tier II and III shall be connected to
Intelligence module and Counter-measure selector module and the counter-measure
implementation module to make the system sense the possibility of attacking and choosing
the appropriate counter-measures. The Intelligence and Counter-measure selector modules
also reside within the tier-II.
Figure.3.4 Software Architecture for Building Intelligence to Secure the Intelligent Tag Management
System
3.2.4 Conclusions
The software architecture for building intelligence to the system for securing the
communication between Host and a Tag has been presented in this thesis. This architecture is
well suited to implement in the embedded systems with security as a major concern. The
software required for the system was designed using the architecture presented in this thesis
and the same has been implemented within the separately designed embedded system.
4. REQUIREMENTS ENGINEERING4.1 Tag Side Requirements Engineering
4.1.1 Overview of the system
Intelligent TAG is an embedded system provided with sensors and logic to sense the
changes taking place in the surrounding environment and inform the changes to a remote
mobile device through a communication interface. The Tag will have inbuilt intelligence to
sense the changes taking place in its environment. For example every time TAG is moved
from one location to the other, the TAG will identify itself with all the mobile devices which
are in its vicinity.
The intelligent TAG will be in communication with remote HOST which is a Mobile
Phone. The mobile device shall have the application components that processes the requests
received from the Intelligent Tags and take the actions necessary either to store the
environment data or make available data to the intelligent TAG for controlling purposes if
any. The Intelligent Tag related application components must be in Co-existence with other
components that are natively situated in the mobile phone.
Figure 4.5 Overview of the Intelligent TAG Application
Figure 4.1 shows an overview of the intelligent TAG application. The intelligent Tag has
the intelligence to communicate with the mobile device based on the existence of the active
and working communication devices on either side of the TAG and the HOST. The
intelligent TAG application will have all the logic to store its own code that can be uniquely
recognized under the influence of noise, interference and various types of attacks. The
intelligent TAG system will implement all those techniques to protect the identification code
of the TAG when it is transmitted to the remote HOST. The intelligent TAG will use variety
of communication interfaces such as Bluetooth and Wi-Fi for establishing the communication
links and use the same for effecting the communication.
4.1.2 Process Flow Modeling
The following figure 4.2 represents the process flow for Security Management on tag
side. The Process flow modeling gives the descriptions of various activities that take place in
the proper functioning of the system.
check for availability of ports from TAG Side
Establish Communication
Select Counter-measure
Dynamic Configuration of available ports
attack detection on communication link
is attack detected?
Implement Counter-measure
Efficient Communication
Yes
No
Start
End
Figure 4.6 Process flow modeling for security management on Tag side
4.1.3 Hardware Requirements
Table 4-3 Hardware Requirements on Tag Side
S.No Hardware Required
1 ARM7 Evaluation Board (LPC2148)
2 Wi-Fi 802.11 B/G/N (UART Interface)
3 Bluetooth (USB Interface)
4 GPS
5 EEPROM (512KB)
4.1.4 Functional requirements
The following are the functional requirements that are to be met for implementing the
intelligent security system with the TAG Management system.
i) Trace the availability of communication ports on the Mobile device side and establish the required communication interfaces through dynamic configuration
ii) Trace the availability of communication ports on the Tag side and establish the required communication interfaces through dynamic configuration
iii) Establish the communication links between the Tag and the mobile device
iv) Initiate the communication.
v) Attack Detector.
This component will sense any of the attack (Blue Snarfing attack, Blue Bugging attack, Man-in-the-Middle attack, Denial of Service attack, Evil Twin Access Point attack, Replay attack) on the communication between the TAG and the Mobile device and then communicate the same to counter attack selector.
vi) Counter-measure Selector.
The Counter-measure Selector will receive the information from the attack detector about the attack being made and then selects appropriate counter attacking system and inform the Counter Attack implementing mechanism
vii)Counter attack implementer.
Suspend the regular code that process the communication and then invoke the code that implements the counter attacking mechanisms by implementing dynamic linking and embedding.
viii) Sense the continuation of the threat and reconfigure the scheduling of the execution of the tasks when the threat is not in existence any more.
4.1.5 Non Functional requirements
1) The average response time for processing any of the external events must be within 3 Mille Seconds.
2) A minimum of 10 Events must be processed within a second.
4.1.6 Tracing the functional requirements through use Cases
The following table 4.2 shows the various use cases involved in processing the functional
requirements of Tag. Study of both the functional and non functional requirements reflects
the initiation of the following use cases.Table 4-4 Functional requirements of Tag through use cases
Serial Number
Use Case Code
Description of the Use Case
Major Events to Handel
1. IDUC01 Communication port availability and Dynamic Configuration (TAG)
Checks the availability of ports on Tag side.
2. IDUC02 Communication port availability and Dynamic Configuration (HOST)
Checks the availability of ports on Host side.
3. IDUC03 Establish Communication
Communication link establishment
4. IDUC04 Communicate Ready to communicate
5. IDUC05 Detect Attacker Checks whether any attacks on the communication link.
6. IDUC06 Set Undetected Communication establishes normally when no attack is detected.
7. IDUC07 Counter-measure Selector
Select appropriate counter-measure for the attack performed.
8. IDUC08 Counter Attack Implementer
Enables appropriate Counter-measure on the communication link.
4.1.7 Tracing the business objects through classes
Analysis of the business process flow reveals that the classes shown in the table 4.3 are
required to realize the use cases.
Table 4-5 Business Objects Through Classes
Serial Number
Class code Description of the Class
1. IDCL01 Main control logic process 2. IDCL02 ARM73. IDCL03 LCD4. IDCL04 LCD process5. IDCL05 LED6. IDCL06 LED process7. IDCL07 Bluetooth8. IDCL08 Mobile Bluetooth9. IDCL09 Wi-Fi10. IDCL10 Mobile Wi-Fi11. IDCL11 Communication Port Availability checker (TAG)12. IDCL12 Communication Port Availability checker (HOST)13. IDCL13 Communication Link Establisher14. IDCL14 Attack Detector15. IDCL15 Counter-measure Selector16. IDCL16 Counter-measure Implementer17. IDCL18 EEPROM18. IDCL19 EEPROM process
4.2 Mobile side Requirements Engineering
4.2.1 Over View of Mobile side Description
Figure 4.7 Overview of the Intelligent TAG Application on Mobile Side
The overview of the application components that reside on the mobile phone are shown in
the figure 4.3. The application resident on the mobile device will be running under the
control Android operating system and will have necessary components that help locating
active communication devices and also help establishing the communication link with the
TAG. The application components should also be able to store the data related to all the Tags
that are established by it. The mobile device shall be built around ARM7 technologies which
provide communication interfaces to communicate with the TAG using both Bluetooth and
Wi-Fi Communication. An EEPROM of size 32GB be provided on the mobile side for
maintain a repository of the valid tags. An USB interface shall be used for migrating code
developed on the PC to the Mobile device as an add-on application.
4.2.2 Process Flow Modeling
The following figure 4.4 represents the process flow modeling for communication system
on mobile side. Process flow modeling gives the descriptions of various activities that take
place in the proper functioning of the system.
Listen to active communication ports
check for active ports from Mobile side
Dynamic Configuration of available ports
Sense for attackingon communication link
establish secured communication
Choose Counter-measure
Establish communication link
Implement Counter-measure
establish communication without counter-measure overhead
If attack sensed?
Yes
No
Start
End
Figure 4.8 Process Flow Modeling for Security Management on Mobile Side
4.2.3 Hardware Requirements
Table 4.4 shows the hardware requirements on mobile side for implementing efficient
security mechanisms by building intelligence to the system. These devices are recognized
based on the Process flow described in the previous sections.
Table 4-6 Hardware Requirements on Mobile Side
Mobile Features
Samsung L9100 GALAXY S2
ARM7 Dual Core 1.2 GHz Cortex A9 Wi-Fi 802.11 A/B/G/N Bluetooth V3.0 Memory up to 32 GB extendable USB
4.2.4 Functional requirements
The following are the typical functions that must be implemented by the mobile software.
a) The Mobile Device checks for availability of the communication ports and makes its devices listen the requests of the Tags.
b) Facilitates the establishment of communication.
c) Performs the checking of communication link to detect any attacks on it.
d) It will make the system to set undetected, if no attack is sensed on the communication link.
e) System will be set to detect and the counter-measure selector will be enabled, if an attack is sensed on the communication link between a Tag and the Mobile Device.
f) The Counter-measure implementer will be enabled to implement the appropriate counter attacking mechanisms.
4.2.5 Non Functional requirements
The communication between the Mobile device and the Tag must take place within 1
second whether Wi-Fi or Bluetooth communication interface is used.
4.2.6 Tracing the functional requirements through use Cases
Study of the process flow and the functional requirements on the mobile side reveal the
requirement of use cases shown in Table 4.5.
Table 4-7 Functional Requirements through Use Cases
Serial Number
Use Case Code
Description of the Use Case Major Events to Handel
1. IDUC01 Port Configuration Checker Internal Trigger.
2. IDUC02 Communication manger Internal Trigger.3. IDUC03 Detect Attack Sensing of attacks on
communication link.4. IDUC04 Counter-measure selector Chooses appropriate counter-
measure on detecting an attack.5. IDUC05 Counter-measure Implementer Enables appropriate counter-
attacking mechanism.
4.2.7 Tracing the business objects through classes
The following Table 4.6 reveals the various classes that are involved in interfacing the
add-on module to already existing applications that are resident on mobile phone which are
developed on pc using android development environment.Table 4-8: Mobile Device Business Objects through Classes
Serial Number
Class code Description of the CLASS
1. IDCL01 ARM 72. IDLC02 MOBILE-Main control logic process3. IDCL03 LCD process4. IDCL04 USB interface5. IDCL05 EEPROM6. IDCL06 Mobile Bluetooth7. IDCL07 Tag Bluetooth8. IDCL08 Mobile Wi-Fi
9. IDCL09 Tag Wi-Fi
10. IDCL10 Physical Communication Manager on mobile side process11. IDCL11 Physical Communication Manager on Tag side process12. IDCL12 Attack Detector process13. IDCL13 Counter-measure Selection process14. IDCL14 Counter-measure Implementation process15. IDCL15 TAG side communicator16. IDCL16 MOBILE side communicator17. IDCL17 LCD18. IDCL18 EEPROM process
5. ANALYSIS5.1 Tag Side Analysis
5.1.1 Hardware Analysis
Table 5.1 shows the hardware analysis of the tag. The table explains device name, type of
device, latency of the device, the ports to which the device is connected, and type of output
from the device.Table 5-9: Hardware Analysis of the Tag
Serial Number of the device
Device Code Type of Device
Latency of the Device
Port to which connected
Description of the device
1 ARM7 - - - Controlling and monitoring
2 BLUETOOTH DOFB 0.020 USB
Communication with remote device using Bluetooth interface
3WI-FI DOFB 0.010 UART0
Communication with remote device using Wi-Fi interface
4 EEPROM DOFB 0.020 I2C For data repository5
LCD DOFB 0.020 GPIOAlerting the system for securing the communication link.
6BUZZER DOFB 0.020 GPIO
Alerting the system for securing the communication link.
5.1.2 Use case Modeling
The uses cases that have been identified during the requirement engineering stage have
been further analyzed to find the functionality of each of the use case. The description of the
use case is shown in the Table 5.2. The inter relationships among use cases has also been
analyzed. The events that trigger the use cases and the flow of execution of the use cases have
been analyzed and the same have been shown in the Figure 5.1.
Table 5-10: Use Case Description
Serial Number
Use Case Code Use case description Preceding usage case
1. IDUC01 Communication ports availability and dynamic configuration (Host)
-
2. IDUC02 Communication ports availability and dynamic configuration (Tag)
-
3. IDUC03 Establish Communication Link -
4. IDUC04 Ready to communicate -
5. IDUC05 Sense any attacks on the Communication link IDUC04
6. IDUC06 Choose appropriate counter-measure IDUC05
7. IDUC07 Implement selected Counter-measure IDUC06
8. IDUC09 Senses no attack IDUC05
Communication ports availability and dynamic configuration (HOST)
HOST
Communication ports availability and dynamic configuration (TAG)
Counter Attack implementor
Establish communication
TAG
Set undetectedCommunicate
Detect Attackar
Undetected
Select Counter Measuer
Detected
Figure 5.9 Use Case Diagram Showing Functional Requirements of Security Management
5.1.3 Business process modeling through HW related class diagram
The security mechanism for developing intelligence into the Tag requires different
hardware modules interfaced with each other. For every hardware component that is directly
connected to the Microcontroller, it can be defined as individual class. Defining the
functionality of each class and relationships among different classes forms the hardware
architecture. The main control logic that drives the application is shown as ARM7 class.
Tag communicates with mobile reader using communication protocols. Communication
protocols classes like Bluetooth class and Wi-Fi class are connected to ARM7 class. Various
Communication protocol classes are used for tracking the devices using a range of
frequencies. Communication protocol classes of the tag such as Bluetooth, Wi-Fi, are
dependent on the communication protocol classes of the mobile device as the application
developed provides the security for the communication between the Host and Intelligent tags.
The communication protocol classes are defined as Bluetooth mobile and Wi-Fi mobile
classes. EEPROM is attached to ARM7 for storing the data of valid mobile devices. Buzzer
and LCD communicate with ARM7 for notifying the status of securing the communication
link. The hardware class diagram of security management is shown in figure 5.2.
Bluetooth (Mobile)
Wi-Fi (Mobile)
Buzzer
EEPROM
Bluetooth (Tag)
Wi-Fi (Tag)
ARM 7
LCD
Figure 5.10 Hardware Class Diagram of Security Management
5.1.4 Business process modeling through SW related Class Diagram
The Intelligent Tag Management System consists of different hardware modules
interfaced with each other. For every hardware module that is directly connected to the
Microcontroller, a software component is created in the ES application which is modeled as a
Class. The each software component related to a hardware device is recognized as a single
class.
The Software Architecture can be defined by using the functions performed by each class
and by establishing the relationships among different classes. The key component that
requires the application to run on the Tag side is shown as Main Logic Controller class. The
Main Logic Controller class is associated with a communication management class. The
communication management looks for readily available communication ports for
communication by writing a polling mechanism through an s/w code written at the controller
side.
To secure the wireless data transmission on either side, an efficient security mechanism is
implemented by developing an application on both Host side and Tag side through attack
detector class. The detector class invokes Counter-measure selector class whenever attacking
of particular types is noticed. The Counter attack implementer class implements the counter
attack method selected by the selector class. If a counter attacking mechanism is selected and
an attack does no more exist the counter attack is reset.
The communication devices are connected to Peripheral IO bus which is responsible for
interfacing external modules like Bluetooth and Wi-Fi. So the peripheral IO communication
manager class maintains information regarding the available active ports connected i.e. mode
of communication for establishing the communication. LCD class is connected to the ARM7
class to display the output to the user. The class diagram that ensures security to the
Intelligent Tag Management System is shown in figure.5.3.
Bluetooth Process (HOST)
Wi-Fi Process (HOST)
Bluetooth Process (TAG)
Wi-Fi Process (TAG)
Attack Persistent Checker
Peripheral communication manager
not detected
Counter Attack Implementor
communication management
Attack Detector
Counter-measure selector
detected
LCD Process
Buzzer Process
Main Logic Controller
EEPROM Process
Figure 5.11 Software Class Diagram of The Security Management
5.1.5 Business process modeling related to interfacing of HW and SW components
The figure 5.4 shows the diagram of interfacing hardware components and software
components on Tag side. All the hardware components integrated on the Tag have a software
code for driving them.
communication management
LCD Process
EEPROM Process
Buzzer ProcessAttack Detector
Counter-measure selector
LCD
EEPROM
Buzzer
Bluetooth Process (TAG)
Bluetooth (Host)
Bluetooth Process (Host)
Wi-Fi (Mobile)
Wi-Fi Process (Host)
Attack Persistent Checker
detected
Counter Attack Implementor
Bluetooth (Tag)
Wi-Fi Process (TAG)
Wi-Fi (Tag)
Peripheral communication manager
not detected
ARM 7Main Logic Controller
Figure 5.12 Class Diagram Interfaces of HW and SW Components on Tag Side
5.2 Mobile Side Analysis
5.2.1 Hardware Analysis
Table 5.3 shows the hardware analysis of the tag. The table explains device name and
description of the device.Table 5-3 Hardware Analysis on Mobile Side
Serial number
Device name description
1 ARM7 Dual Core 1.2 GHz Cortex A9
Controlling and monitoring
2 Wi-Fi 802.11 A/B/G/N
This is meant for communicating the devices using Wi-Fi interface
3 Bluetooth V3.0 This is meant for communicating the devices using Bluetooth interface
4 Memory up to 32 GB extendable
Used for data repository
5 USB Migrating code developed on the PC
5.2.2 Use case Modeling
The uses cases that have been identified during the requirement engineering stage have
been further analyzed to find the functionality of each of the use case. The description of the
use case is shown in the Table 5.4. The inter relationships among use cases have also been
analyzed. The events that trigger the use cases and the flow of execution of the use cases have
been analyzed and the same have been shown in the Figure 5.5.
Checking available active ports
Configure available ports
Establishment of Communication link
Checking available active ports
Tag
Set undetected
Sense for any attacks on communication link
undetected
Choose appropriate Counter-measure
detected
Implement Counter mechanism
Mobile Device
Figure 5.13 Use Case Modeling On Mobile Side
Table 5-4: Description of the Use Case
Serial Number
Use Case Code Use case description Preceding usage case
1. IDUC01 Checking available active ports -
2. IDUC02 Configure available ports -
3. IDUC03 Establish Communication Link -
4. IDUC04 Attack Detector IDUC03
5. IDUC05 Counter-measure Selector (if detected) IDUC04
6. IDUC06 Counter-measure Implementer IDUC05
7. IDUC07 Set Undetected (if no attack) IDUC04
5.2.3 Business process modeling through HW related class diagram
The security management of the Intelligent Tag Management System developed on
mobile side consists of different hardware modules interfaced with each other. For every
hardware module that is directly connected to the Micro controller, each hardware component
can be defined as individual class. Defining the functionality of each class and relationships
among different classes forms the hardware architecture. The main control logic that drives
the application is shown as ARM7 class.
Mobile device communicates with Tag using communication protocols. Communication
protocols classes like Bluetooth class and Wi-Fi class are connected to ARM7 class. Various
Communication protocol classes are used for tracking the devices using a range of
frequencies. All the communication protocols of the mobile device are connected to ARM7.
USB class is defined separately which is used for dumping the code developed on PC to
mobile. EEPROM is defined as separate class in which the data repository of the related
TAG’s information is stored. The hardware class diagram for security management on the
mobile side is shown in figure 5.6.
Bluetooth (Tag)
Wi-Fi (Tag)
Bluetooth (Mobile)
Wi-Fi (Mobile)
EEPROM
USB Interface
ARM 7 (Mobile)
Figure 5.14 Hardware Class Diagram for Security Management on Mobile Side
5.2.4 Business process modeling through SW related Class Diagram
The security management for the Intelligent Tag development consists of different
hardware modules interfaced with each other. For every Hardware module that is directly
connected to the Microcontroller, a Software component exists. The software component
related to a hardware device is recognized as a single class. Defining the functionality of each
class and relationships among different classes forms the software architecture. The main
control logic that drives the application is shown as ARM7 class. The Mobile Side
Communication Manager class is defined to configure the required active communication
ports. USB class is defined separately to show that the software code for securing the
communication link is developed on PC and dumped into the Mobile. EEPROM is defined as
separate class to show that a data repository is used for storing the Tag related information.
Attack Detector process is defined to sense whether there is any notice of attack on the
communication link between a Tag and the Mobile Device. If any attack is sensed, then
counter-measure selector class, defined below, chooses the appropriate counter attacking
mechanism depending upon the protocol and type of attack sensed. Then the Counter-
measure Implementer enables the specified counter attacking mechanism and it is processed
by the Communication manager class which is defined as the software class dependent on the
Tag side communication manager. The class diagram of security management is shown in
figure 5.7.
Bluetooth process (Tag)
Wi-Fi process (Tag)
USB process EEPROM process
Counter-measure Selector
Main Logic Controller (Mobile)
Attack Detector
Attack DetectedMobile Bluetooth
process
Mobile Wi-Fi process
Mobile Side Communication Manager
No attack detected
Counter-measure Implementer
Figure 5.15 Software Class Diagram of Security management on Mobile Side
5.2.5 Business process modeling related to interfacing of HW and SW components
Figure 5.8 shows the interfacing of hardware components and software components on
mobile side. All the hardware components integrated on the Tag have a software code for
driving them.
Counter-measure Selector
EEPROM EEPROM process
USB Interface USB process
Attack Detector
Attack Detected
Bluetooth (Mobile)
Mobile Bluetooth process
Bluetooth Process(Tag)
Bluetooth (Tag)
Wi-Fi (Mobile)
Wi-Fi Process(Tag)
Wi-Fi (Tag)
Mobile Wi-Fi process
Counter-measure Implementer
Mobile Side Communication Manager
No Attack
ARM 7 (Mobile) Main Logic Controller (Mobile)
Figure 5.16 Class Diagram Interfaces HW and SW Components on Mobile Device Side
6. DESIGN6.1 Tag Side Design
The Tag side HW design related to Intelligent TAG system is shown in figure 6.1.
Figure 6.17: Tag Side Design Diagram
The total HW details includes the details of the ARM7 controller, the devices that are
connected on to the same board on which the ARM7 controller is situated and the peripheral
devices which are outside the controller board connected the ARM7 controller through its
internal devices
6.1.1 Hardware Design
6.1.1.1 Block Diagram
The interconnection between hardware devices forms the hardware design related to
intelligent tag identification system. Figure.6.2 shows the interconnection diagram. ARM 7
acts as main controller to which most of the devices are interfaced directly through various
busses. To the AHP Bus which is a main bus, VLSI Peripheral bus and Local bus are
connected. To the VLSI bus, GPIO bus and I2C bus are connected. All the devices are
connected to one of the busses mentioned above.
External memory which is EEPROM is connected Via I2C Bus. The communication
modules namely Bluetooth and Wi-Fi are used for establishing communication on both sides.
The Bluetooth module is connected through USB (Universal serial bus) to the microcontroller
through VLSI bus. Similarly the Wi-Fi is connected to the microcontroller through UART01
and VLSI bus. LCD, Keypad, and reset gate are connected to the Micro controller through
GPIO and VLSI Bus. LCD is used for displaying the environmental changes taking place in
and around the intelligent TAG with the mobile phone.
The Intelligent Tag System uses LPC22148, a 16/32-bit RISC microprocessor that is the
product of PHILIPS Co. Ltd. An outstanding feature of this is its CPU core, a 16/32-bit
ARM7TDMI RISC processor designed by advanced RISC machines Ltd. Hence it has low
power consumption, high instruction throughput and an excellent real-time interrupt
response. In addition, it has rich on-chip integrated functions such as watchdog timer, real-
time clock and so on. All these, facilitates the hardware and software designing of the
intelligent device. Because the processor uses a pipeline to increase the speed of the flow of
instructions, it allows several operations to take place simultaneously and the processing and
memory systems to operate continuously. Thus the intelligent device based on the ARM
processor can deal with much more complicated tasks that cannot be solved by most
conventional lower MCU.
The microcontroller is loaded with ES application such that it provides an efficient
security mechanism by building intelligence into the system. With this application, the
system will be able to sense whether there is any scope of attacking the communication
between Host and a Tag. Then depending on the type of attack, appropriate counter-measures
will be enabled using that application. The architecture of the Intelligent Tag Management
System based on the LPC22148 microprocessor is as shown in the figure.6.2.
Figure 6.18 Hardware Block diagram of Intelligent Tag
6.1.1.2 Object Modeling
The classes that encapsulates the specification of each the Hardware and the distinct
functions performed by every hardware device are recognized based the types of processing
to be done by each of the device and also considering the signals that flows across the
hardware devices through interfacing. The Figure 6.3 shows class diagram that is flushed
with details of the properties and the functions that each of the hardware devices performs.
ARM7nameoscillating frequency
main()memory management()interrupt handling()
communication management
active nodeactive port
bluetooth transmit()bluetooth receive()wi-fi transmit()wi-fi receive()
Bluetooth (HOST)Host Id
Activate()receive()transmit()deactivate()
Wi-Fi (HOST)nameHost address
Turn ON()search()connect()transmit()receive()Turn OFF()
Attack Detector
OBEX sensor()variable frequency sensor()MITM attack sensor()replay attack sensor()
Bluetooth (TAG)Tag Idtransmitting frequency
Power ON()Power OFF()Reset()receive message()transmit message()
Wi-Fi (TAG)nameaddresstransmitting frequency
reset()Turn ON()intialize transmit()transmit()receive()Turn OFF()
Attack Persistent Checker
Senses occurance of attack()
Counter-measure selector
authentication()RF signatures()encryption/decryption()session tokens()
detected
Peripheral communication manager
bluetooth communication through USB()wi-fi comunication through UART()
not detected
Counter Attack Implementor
invoke counter attacking mechanism()
Figure 6.19 Object Modeling Diagram of Tag Design
6.1.1.3 Design of Hardware Elements
A. Design of the ARM7 Controller
The LPC2148 microcontroller is based on a 16-bit/32-bit ARM7TDMIS CPU with real-
time emulation and embedded trace support, that combine microcontroller with embedded
high speed flash memory ranging from 32 kB to 512 kB. A 128-bit wide memory interface
and unique accelerator architecture enable 32-bit code execution at the maximum clock rate.
For critical code size applications, the alternative 16-bit Thumb mode reduces code by more
than 30 % with minimal performance penalty.
Due to their tiny size and low power consumption, LPC2148 are ideal for applications
where miniaturization is a key requirement, such as access control and point-of-sale. Serial
communications interfaces ranging from a USB 2.0 Full-speed device, multiple UARTs, SPI,
SSP to I2C-bus and on-chip SRAM of 8 kB up to 40 kB, make these devices very well suited
for communication gateways and protocol converters, soft modems, voice recognition and
low end imaging, providing both large buffer size and high processing power. Various 32-bit
timers, single or dual 10-bit ADC(s), 10-bit DAC, PWM channels and 45 fast GPIO lines
with up to nine edge or level sensitive external interrupt pins make these microcontrollers
suitable for industrial control and medical systems. Figure 6.4 shows Pin diagram of ARM
controller.
Features
16-bit/32-bit ARM7TDMI-S microcontroller in a tiny LQFP64 package.
8kB to 40 kB of on-chip static RAM and 32 kB to 512 kB of on-chip flash memory.
128-bit wide interface/accelerator enables high-speed 60 MHz operation.
In-System Programming/In-Application Programming (ISP/IAP) via on-chip boot loader
Software. Single flash sector or full chip erase in 400 ms and programming of 256 bytes in 1 ms.
Embedded ICE RT and Embedded Trace interfaces offer real-time debugging with the
on-chip Real Monitor software and high-speed tracing of instruction execution.
USB 2.0 Full-speed compliant device controller with 2 kB of endpoint RAM.
In addition, the LPC2146/48 provides 8 kB of on-chip RAM accessible to USB by DMA.
One or two (LPC2141/42 vs. LPC2144/46/48) 10-bit ADCs provide a total of 6/14
Single 10-bit DAC provides variable analog output (LPC2142/44/46/48 only).
Two 32-bit timers/external event counters (with four capture and four compare Channels each), PWM unit (six outputs) and watchdog.
Low power Real-Time Clock (RTC) with independent power and 32 kHz clock input.
Multiple serial interfaces including two UARTs (16C550), two Fast I2C-bus (400 kbit/s),
Up to 45 of 5 V tolerant fast general purpose I/O pins in a tiny LQFP64 package.
Up to 21 external interrupt pins available.
On-chip integrated oscillator operates with an external crystal from 1 MHz to 25 MHz.
Individual enable/disable of peripheral functions as well as peripheral clock scaling for additional power optimization.
Processor wake-up from Power-down mode via external interrupt or BOD.
Single power supply chip with POR and BOD circuits.
PIN Diagram
Figure 6.20: Pin Diagram of ARM Controller
Timing diagram
Figure 6.5 shows general timing diagram. Diagram shows nWAIT and ALE are both
HIGH during the cycle. Figure 6.6 shows the address timings of ARM7 controller.
Figure 6.21: General Timing Diagram
nWAIT and ALE are both HIGH during the cycle shown.
Figure 6.22: Address Timings
Figure 6.23: Data Write Cycles
Tald is the time by which ALE must be driven LOW in order to latch the current address
in phase. If ALE is driven low after Tald, then a new address will be latched. Figure 6.7
shows data write cycles. Diagram shows DBE is high during the cycle. Figure 6.8 shows
data read cycles.
Figure 6.24: Data Read Cycles; DBE Is High During the Cycle Shown
Figure 6.25: Data Bus Control
Figure 6.9 shows data bus control. The cycle shown is a data write cycle since nENOUT
was driven low during phase 1. Here, DBE has been used to modify the behavior of Nenout.
Figure 6.10 shows configuration diagram. Figure 6.11 shows Exception timing.
Figure 6.26: Configuration Diagram
Figure 6.27: Exception Timing
Tirs guarantees recognition of the interrupt (or reset) source by the corresponding clock
edge. Tirm guarantees non-recognition by that clock edge. These inputs may be applied fully
asynchronously where the exact cycle of recognition is unimportant.
Figure 6.28: Clock Timing of ARM7
Figure 6.12 shows clock timing of ARM 7. The ARM core is not clocked by the HIGH
phase of MCLK enveloped by nWAIT. Thus, during the cycles shown, nMREQ and SEQ
change once, during the first LOW phase of MCLK, and A[31:0]change once, during the
second HIGH phase of MCLK. For reference, ph2 is shown. This is the internal clock from
which the core times all its activity. This signal is included to show how the high phase of the
external MCLK has been removed from the internal core clock.
B. Design of the devices that are on the ARM 7 control board
The main controller device which is ARM 7 has been fitted with many of the devices that
include UART, EEPROM, I2C Port, USB Port, A/D Converter, LCD, Buzzer, 4x4 Keyboard,
and LED. These ports are connected to a BUS architecture that includes various buses such as
AHP Bus, GPIO Bus. The details of these devices which are on the ARM 7 Controller board
are provided below:
a) UART
UART (universal asynchronous receiver/transmitter) is an integrated circuit designed for
implementing the interface for serial communications. A UART includes a transmitter and a
receiver. The transmitter is essentially a special shift register that loads data in parallel and
then shifts it out bit by bit at a specific rate. The receiver, on the other hand, shifts in data bit
by bit and then reassembles the data. In intelligent tag on board circuit consists of 2 UART
ports used for interfacing Wi-Fi and GPS modules. Figure 6.13 shows UART interfacing pin
out diagram.
Figure 6.29: UART Interfacing Pin out Diagram
Features 16 byte Receive and Transmit FIFOs
Register locations conform to ‘550 industry standard.
Receiver FIFO triggers points at 1, 4, 8, and 14 bytes.
Built-in fractional baud rate generator with auto bauding capabilities.
Mechanism that enables software and hardware flow control implementation.
Timing Diagram
Figure 6.14 shows the timing diagram of UART.
Figure 6.30: Timing Diagram of UART
b) EEPROM
EEPROM stands for Electrically Erasable Programmable Read-Only Memory and is a
type of non-volatile memory used in computers and other electronic devices. There are
different types of electrical interfaces to EEPROM devices. Main categories of these interface
types are: serial bus, parallel bus. Most common serial interface types are SPI, I2C, Micro
wire, UNI/O, and 1-Wire. These interfaces require between 1 and 4 control signals for
operation, resulting in a memory device in an 8 pin package. The serial EEPROM typically
operates in three phases: OP-Code Phase, Address Phase and Data Phase.
In ARM LPC2148 AT24C01A/02/04/08/16 provides 1024/2048/4096/8192/16384 bit of
serial electrically erasable and programmable read only memory (EEPROM) organized as
128/256/512/1024/2048 word of 8 bit each. Figure 6.15 shows pin diagram of EEPROM.
Figure 6.31: Pin Diagram of EEPROM
Features
Internally organized 128x8(1K), 256x8(2K), 512x8(4K)
2-wire serial interface
Bi directional data transfer protocol
100 KHz (1.8V, 2.5V, 2.7V) and 400 KHz (5V) compatibility
Write protect pin for hardware data protection
c) I2C
The LPC2148 each contain two I2C-bus controllers. The I2C-bus is bidirectional, for
inter-IC control using only two wires: a Serial Clock Line (SCL) and a Serial Data line
(SDA). Each device is recognized by a unique address and can operate as either a receiver-
only device. Transmitters and/or receivers can operate in either master or slave mode,
depending on whether the chip has to initiate a data transfer or is only addressed. The I2C-
bus is a multi-master bus, it can be controlled by more than one bus master connected to it.
The I2C-bus implemented in LPC2148 supports bit rates up to 400 kbps. Figure 6.16 shows
I2C protocol IC for interfacing EEPROM. In intelligent tag ARM board, one I2C is used for
interface EEPROM to LPC2148 using serial data SDA and serial clock SCK lines.
Figure 6.32: I2C Protocol IC for Interfacing EEPROM
Features
Standard I2C compliant bus interfaces that may be configured as Master, Slave, or Master/Slave.
Arbitration between simultaneously transmitting masters without corruption of serial data on the bus.
Programmable clock to allow adjustment of I2C transfer rates.
Bidirectional data transfer between masters and slaves.
Serial clock synchronization allows devices with different bit rates to communicate via one serial bus.
Serial clock synchronization can be used as a handshake mechanism to suspend and resume serial transfer.
The I2C-bus may be used for test and diagnostic purposes.
Timing Diagram
Figure 6.17 shows timing diagram for I2C
Figure 6.33: Timing Diagram for I2C
d) ADC
An ADC is an electronic device that converts an input analog voltage or current to a
digital number proportional to the magnitude of the voltage or current. In ARM LPC2148 on
chip ADC basic clocking is provided by the VPB clock. A programmable divider is included
in each converter, to scale this clock to the 4.5 MHz (max) clock needed by the successive
approximation process. A fully accurate conversion requires 11 of these clocks. While the
ADC pins are specified as 5 V tolerant the analog multiplexing in the ADC block is not.
More than 3.3 V (VDDA) +10 % should not be applied to any pin that is selected as an ADC
input, or the ADC reading will be incorrect. By using this ADC pressure sensor is interface to
LPC2148.
Features
10 bit successive approximation analog to digital converter (one in LPC2141/2 and two in LPC2144/6/8).
Input multiplexing among 6 or 8 pins (ADC0 and ADC1).
Power-down mode.
Measurement range 0 V to VREF
Burst conversion mode for single or multiple inputs.
Optional conversion on transition on input pin or Timer Match signal.
Global Start command for both converters (LPC2144/6/8 only).
Backward compatibility with other earlier devices is maintained with legacy registers appearing at the original addresses on the VPB bus
e) LEDs
Light emitting diodes (LEDs) the most commonly used components, usually for
displaying pin’s digital states. The ARN214X has 8 numbers of point LEDs, connected with
port pins (P1.16-P1.23), to make port pins high LED will glow.
In intelligent tag LEDs are used for multiple purposes like low battery indication, alerting
system, tamper proofing system, location identification system and communication failure
indication etc.
f) USB Controller
The USB is a 4 wire bus that supports communication between a host and a number (127
max.) of peripherals. The host controller allocates the USB bandwidth to attached devices
through a token based protocol. This bus support hot plugging, un-plugging and dynamic
configuration of the devices. All transactions are initiated by the host controller. The device
controller enables 12 Mb/s data exchange with a USB host controller. Figure 6.18 shows
USB interface.
Figure 6.34: USB Interface
Features
Fully compliant with USB 2.0 Full Speed specification
Supports 32 physical (16 logical) endpoints
Supports Control, Bulk, Interrupt and Isochronous endpoints
Endpoint Maximum packet size selection by software at run time
RAM message buffer size based on endpoint realization and maximum packet size
Supports bus-powered capability with low suspend current
Support DMA transfer with the DMA RAM of 8 kB on all non-control endpoints (LPC2146/8 only)
One Duplex DMA channel serves all endpoints (LPC2146/8 only)
Allows dynamic switching between CPU controlled and DMA modes (available on LPC2146/8 only)
Double buffer implementation for Bulk & Isochronous endpoints.
g) LCD 2x16 in 4-BIT MODE
The ARM214X kit, have 2x16 character LCD. 7pins are needed to create 4-bit interface;
4data bits (P0.19-P0.22, D4-D7), address bits (RS-P0.16), read/write bit(R/W-P0.17) and
control signal (E-P0.18). The LCD controller is a standard KS0070B or equivalent, which is a
very well known interface for smaller character based LCDs. The LCD is powered from the
5Vpower supply enabled by switch SW28. In intelligent tag application LCD used for
displaying the location of the object, displaying message during alert conditions and power
save modes. Figure 6.19 shows LCD 2x16 with its pin description.
Figure 6.35: LCD 2x16 with Its Pin Description
Timing Diagram:
Figure 6.20 shows timing diagram of LCD.
Figure 6.36: Timing Diagram of LCD
h) 4X4 Matrix Keypad
Keypads arranged by matrix format, each row and column section pulled by high or low
by selection J5, all row lines (P1.24-P1.27) and column lines (P1.28-P1.31) connected
directly by the port pins. Figure 6.21 shows 4X4 matrix keypad.
Figure 6.37: 4X4 Matrix Keypad
Timing Diagram:
Figure 6.22 shows the timing diagram of matrix keypad.
Figure 6.38: Shows the Timing Diagram of Matrix Keypad
i) Buzzer
A small piezoelectric buzzer on the ARM214X kit, by pulling pin P0.7 low, current will
flow through buzzer and relatively sharp, single tone frequency will be heard. The alternative
PWM features of pin P0.7 can be used to modulate the buzzer to oscillate around different
frequencies. It’s not the pulse width feature that is used to change the frequency. Only the
volume of the sound will be changed by alerting the pulse width. The buzzer can be
disconnected by removing jumper JP1, and this is also the default position for this jumper
since the buzzer sound can be quite annoying if always left on.
In intelligent tag buzzer plays a major role in many cases like when the power goes down,
communication failure between tags and mobile, tampering occurs, for locating the tag from
remote host.
j) GPIO
Features
Every physical GPIO port is accessible via either the group of registers providing an enhanced features and accelerated port access or the legacy group of registers
Accelerated GPIO functions:
GPIO registers are relocated to the ARM local bus so that the fastest possible I/O timing can be achieved, mask registers allow treating sets of port bits as a group, leaving other bits unchanged, all registers are byte and half-word addressable, Entire port value can be written in one instruction
Bit-level set and clear registers allow a single instruction set or clear of any number of bits in one port
Direction control of individual bits
All I/O default to inputs after reset
k) Fast GPIO
Device pins that are not connected to a specific peripheral function are controlled by the
GPIO registers. Pins may be dynamically configured as inputs or outputs. Separate registers
allow setting or clearing any number of outputs simultaneously. The value of the output
register may be read back, as well as the current state of the port pins.
Features
Bit-level set and clear registers allow a single instruction set or clear of any number of bits in one port.
Direction control of individual bits.
Separate control of output set and clear.
All I/O default to inputs after reset.
l) Advanced High Performance Bus (AHB)
A simple transaction on the AHB consists of an address phase and a subsequent data
phase (without wait states: only two bus-cycles). Access to the target device is controlled
through a multiplexer (non-tristate), thereby admitting bus-access to one bus-master at a time.
Features
Single edge clock protocol
Split transactions
Several bus masters
Burst transfers
Pipelined operations
Single-cycle bus master handover
Non-tristate implementation
Large bus-widths (64/128 bit).
m) Power Supply
The external power can be Ac or DC, with a voltage between (9V/12V, 1A output) at
230V AC input. The ARM board produces +5V using an LM7805 voltage regulator, which
provides supply to the peripherals. LM1117 fixed +3.3V positive regulator used for processor
and processor related peripherals. USB socket meant for power supply and USB
communication, user can select either USB or Ext power supply through JP14. Separate
on/off switch (SW24) for controlling power to the board. Figure 6.23 shows Power supply
circuit.
Figure 6.39: Power Supply Circuit
n) Power on Reset
A power on reset (PoR) generator is a microcontroller or microprocessor peripheral that
generates a reset signal when power is applied to the device. It ensures that the device starts
operating in a known state.
C. Design of the peripheral devices connected to ARM 7 controller
Many of the peripheral devices are connected to the ARM7 main Controller to realize the
functional requirements related to the Intelligent Identification management system.
Following are the design details of the peripheral devices connected to the ARM7 controller.
i. Bluetooth (Promi ESD-02 )
Parani-ESD Series is OEM Bluetooth-Serial Module type product line based on Bluetooth
technology. Parani-ESD Series is designed for integration into user devices by on-board
installation. They are connected to the device via built-in UART interface and communicate
with other Bluetooth device. Parani-ESD Series enables RS232-based serial devices to
communicate wirelessly throughout the range of 30m~300m(Parani-ESD210-Class 2) or
100m~1000m(Parani-ESD110-Class 1).
Parani-ESD100/200 has a built-in on-board antenna. Users may configure the Parani-ESD
Series by using easy-to-use Windows-based utility software or by using standard AT
command set. Promi-ESD-02 is a board type of Promi-SD™, Class 2 OEM version, which
can be embedded in your applications such as mobile terminals or any kinds of machines for
Wireless serial communications of long range, easy-to-install, and low-cost. Provided is
point-to-point wireless connection without standard RS232 cables. Figure 6.24 shows
Bluetooth module interfaced with UART. Figure 6.25 shows Bluetooth module interfaced
with LPC2148.
Bluetooth Diagram
Bluetooth Features
Figure 6.40: Bluetooth Module UART Interfaced
Output Interface UART, Compliant Bluetooth stack v1.2-improved AFH (Adaptive
Frequency Hopping), Fast connection Transmit Power, ESD100/110: Max. +18dBm,
ESD200/210: Max. +4dBm Receiving Sensitivity, ESD100/110: -88dBm (0.1%BER),
ESD200/210: -80dBm (0.1%BER)
Antenna gain Chip : 0dBi, Stub : +2dBi, Dipole : +3dBi, Patch : +9dBi
Provides transparent RS232 serial cable replacement.
Supports Bluetooth Serial Port Profile.
Interoperability with PDA, laptops etc.
Built-in chip antenna included
Supports firmware upgrade via windows-based software (Parani Updater)
Working distance(In an open field)
Parani-ESD100 : Class 1, Nom. 100 meters
Parani-ESD200 : Class 2, Nom. 30meters
Figure 6.41: Bluetooth Module Interfaced With LPC2148
ii. XBEE WI-FI Module
The XBee/XBee-PRO ZNet 2.5 OEM (formerly known as Series 2 and Series 2 PRO) RF
Modules were engineered to operate within the ZigBee protocol and support the unique needs
of low-cost, low-power wireless sensor networks. The modules require minimal power and
provide reliable delivery of data between remote devices. The modules operate within the
ISM 2.4 GHz frequency band and are compatible with the following. Figure 6.26 shows
XBEE Wi-Fi module.
Figure 6.42: Xbee Wi-Fi Module
Features
Bluetooth Ver. 2.0+ EDR certification
Transmit Power up to +18dBm (class1)
Low current consumption:
Hold, Sniff, Park, Deep sleep mode
3.0V to 3.6V operation
Full Bluetooth Data rate over UART and USB
Support up to 7 ACL links and 3 SCO links
Enhanced Data Rate (EDR) compliant
For both 2Mbps and 3Mbps modulation modes
Interface: USB, UART&PCM (for voice codec)
SPP pro_le comes as standard,
HSP/HFP, HID, DUN pro_les are available
Support for 802.11 Co - Existence
RoHS Compliant
Small outline: 30mm x 27mmX 2.8 mm.
6.2 Software Design
6.2.1 Objects Modeling
The business objects identified at the analysis stage have further been designed by
flushing the attributes and behavior of the objects through member functions. Figure 6.27
shows the interaction between the software objects. The functions of the objects have been
realized based on the responsibilities that the objects must meet. The analysis of use cases
also revealed the necessity of the objects and the functions that must be supported by them.
Main Logic Controller
main()memory management()interrupt handling()
communication management
bluetooth transmit()bluetooth receive()wi-fi transmit()wi-fi receive()
Bluetooth (HOST)
Activate()receive()transmit()deactivate()
Wi-Fi (HOST)
Turn ON()search()connect()transmit()receive()Turn OFF()
Attack Detector
OBEX sensor()variable frequency sensor()MITM attack sensor()replay attack sensor()
Bluetooth (TAG)
Power ON()Power OFF()Reset()receive message()transmit message()
Wi-Fi (TAG)
reset()Turn ON()intialize transmit()transmit()receive()Turn OFF()
Attack Persistent Checker
Senses occurance of attack()
Counter-measure selector
authentication()RF signatures()encryption/decryption()session tokens()
detected
Peripheral communication manager
bluetooth communication through USB()wi-fi comunication through UART()
not detected
Counter Attack Implementor
invoke counter attacking mechanism()
Figure 6.43 Software Objects Interaction on the TAG Side
6.2.2 Integration design
The Hardware objects and software objects interact with each other for realizing the use
cases. The interaction between the HW objects and SW objects on the TAG side is shown in
Figure 6.29. The functions recognized for HW objects are the internal processing undertaken
within the projects. All the software components are resident within the micro controller and
some of the components of the software have been built with all the processing required to
drive the hardware devices connected to the micro controller. Some of the software
components have been identified for processing self triggered events.
Bluetooth (Mobile)Mobile_ID
Activate()Search()Read Message()Write Message()Accept()
EEPROM Process
Select Data()Process Data()
LCD ProcessRSRWEnable
LCD_data()LCD_cmd()
Wi-Fi (Mobile)AddressNameSignal Strength
Active()Search()Connect()Transmit()Receive()
Counter-measure Selector
Authentication()RF signature()Encryption/Decryption()Session Tokens()
Attack Detector
OBEX sensor()Replay sensor()Variable frequency sensor()MITM sensor()
Attack Detected
Counter-measure Implementer
Invoke Counter-attacking mechanism()
Main Logic ControllernameOperating frequency
Main()Interrupt Handling()Memory Management()Alerting System()
LCDEnableRegister SelectWrite
Data()Command()
EEPROM
Store Data()
BluetoothTag_ID
Power ON()Reset()Transmit()Receive()Initialize Transmit()
Tag Side Communication Manager
Establish Communication with Mobile()
no attack
Wi-FiAddressname
Activate()Transmit()Receive()
ARM7nameOperating Frequency
Power management()Interrupt Handling()Memory Management()
Figure 6.44 Interaction between the HW Objects and SW Objects on the TAG Side
7. Implementation7.1 Client side code
The code used for the implementation on tag side is written in Embedded C. The code is
as follows:
#include <LPC214x.H>
#define RS 0x10000
#define RW 0x20000s
#define EN 0x40000
#define CR 0x0D
unsigned char msg[] = {"requesting data "}; //msg
//unsigned char msg2[];
unsigned char msg1[]= {"requesting data x "};
void Serial_Init(void);
unsigned int Receive(void);
void LCD_init4(void);
void LCD_cmd4(unsigned long int);
void LCD_dat4(unsigned char);
void LCD_puts(unsigned char *);
void DelayMs(unsigned int);
int putchar(int);
unsigned long int DATA;
unsigned char Chr,i=0;
void main()
{
DelayMs(10);
Serial_Init();
LCD_init4();
DelayMs(100);
LCD_cmd4(0x80);
LCD_puts(msg);
LCD_cmd4(0xc0);
LCD_puts(msg);
While (1)
{
Chr=Receive();
Switch (Chr)
{
case 0x33: IOSET0 |= 0x0080; break;/* buzzer on-from mobile press 3*/
case 0x34: IOCLR0 |= 0x0080; break; /* buzzer off-from mobile press 4*/
}
i=0;
Chr = msg1[i];
While (Chr != 'x')
{
putchar (Chr);
i++;
Chr = msg1[i];
}
i=0;
Chr = msg1[i];
While (Chr != 'x')
{
putchar (Chr);
i++;
Chr = msg1[i];
}
i=0;
Chr = msg1[i];
while(Chr != 'x')
{
putchar (Chr);
i++;
Chr = msg1[i];
}
i=0;
Chr = msg1[i];
while(Chr != 'x')
{
putchar (Chr);
i++;
Chr = msg1[i];
}
i=0;
Chr = msg1[i];
while(Chr != 'x')
{
putchar (Chr);
i++;
Chr = msg1[i];
}
i=0;
Chr = msg1[i];
while(Chr != 'x')
{
putchar (Chr);
i++;
Chr = msg1[i];
}
i=0;
Chr = msg1[i];
while(Chr != 'x')
{
putchar (Chr);
i++;
Chr = msg1[i];
}
/* i=0;
Chr = msg3[i];
while(Chr != 'x')
{
putchar (Chr);
i++;
Chr = msg3[i];
}*/
}
}
void Serial_Init(void)
{
PINSEL0 | = 0X00000005; //Enable Txd0 and Rxd0
U0LCR = 0x00000083; //8-bit data, no parity, 1-stop bit
U0DLL = 0x00000061; // for Baud rate=9600,DLL=82
U0LCR = 0x00000003; //DLAB = 0;
}
unsigned int Receive(void) /* Read character from Serial Port */
{
while (!(U0LSR & 0x01));
return (U0RBR);
}
void LCD_init4(void)
{
IO0DIR = 0xFFFFFFFF;
LCD_cmd4(0x33);
LCD_cmd4(0x22);
LCD_cmd4(0x22);
LCD_cmd4(0x22);
LCD_cmd4(0x28);
LCD_cmd4(0x06);
LCD_cmd4(0x0c);
LCD_cmd4(0x01);
}
void LCD_cmd4(unsigned long int cmd)
{
DATA = ((cmd<<15) & 0x00780000);
IOCLR0 = ((DATA^0xFFFFFFFF)& 0x00780000) | RS | RW;
IOSET0 = DATA | EN;
IOCLR0 | = EN;
DATA = ((cmd<<19) & 0x00780000);
IOCLR0 = ((DATA^0xFFFFFFFF)& 0x00780000) | RS | RW;
IOSET0 = DATA | EN;
IOCLR0 | = EN;
DelayMs(3);
}
void LCD_dat4(unsigned char byte)
{
DATA = ((byte<<15) & 0x00780000);
IOCLR0 = ((DATA^0xFFFFFFFF)& 0x00780000) | RW;
IOSET0 = DATA | RS | EN;
IOCLR0 | = EN;
DATA = ((byte<<19) & 0x00780000);
IOCLR0 = ((DATA^0xFFFFFFFF)& 0x00780000) | RW;
IOSET0 = DATA | RS | EN;
IOCLR0 | = EN;
DelayMs(3);
}
void LCD_puts(unsigned char *string)
{
while(*string)
LCD_dat4(*string++);
}
void DelayMs(unsigned int Ms)
{
int delay_cnst;
while(Ms>0)
{
Ms--;
for(delay_cnst = 0;delay_cnst <220;delay_cnst++);
}
}
int putchar (int ch) /* Write character to Serial Port */
{
if (ch == 'x')
{
while (!(U0LSR & 0x20));
U0THR = CR; /* output CR */
}
while (!(U0LSR & 0x20));
return (U0THR = ch);
}
7.2 Mobile side Code
The code used for the implementation on mobile side is written in Java. The code is as
follows:
Bluetooth Share
package com.ram.tag;
import android.provider.BaseColumns;
import android.net.Uri;
/** Exposes constants used to interact with the Bluetooth Share manager's content provider.
*/
public final class BluetoothShare implements BaseColumns{
private BluetoothShare(){
}
/** The permission to access the Bluetooth Share Manager */
public static final String PERMISSION_ACCESS =
"android.permission.ACCESS_BLUETOOTH_SHARE";
/** The content:// URI for the data table in the provider */
public static final Uri CONTENT_URI =
Uri.parse("content://com.android.bluetooth.opp/btopp");
/** Broadcast Action: this is sent by the Bluetooth Share component to transfer complete.
The request detail could be retrieved by app as _ID is specified in the intent's data. */
public static final String TRANSFER_COMPLETED_ACTION =
"android.btopp.intent.action.TRANSFER_COMPLETE";
/** This is sent by the Bluetooth Share component to indicate there is an incoming file need
user to confirm. */
public static final String
INCOMING_FILE_CONFIRMATION_REQUEST_ACTION =
"android.btopp.intent.action.INCOMING_FILE_NOTIFICATION";
/** This is sent by the Bluetooth Share component to indicate there is an incoming file
request timeout and need update UI. */
public static final String USER_CONFIRMATION_TIMEOUT_ACTION =
"android.btopp.intent.action.USER_CONFIRMATION_TIMEOUT";
/** The name of the column containing the URI of the file being sent/received. */
public static final String URI = "uri";
/** The name of the column containing the filename that the incoming file request
recommends. When possible, the Bluetooth Share manager will attempt to use this filename,
or a variation, as the actual name for the file. */
public static final String FILENAME_HINT = "hint";
/** The name of the column containing the filename where the shared file was actually
stored. */
public static final String _DATA = "_data";
/** The name of the column containing the MIME type of the shared file. */
public static final String MIMETYPE = "mimetype";
/** The name of the column containing the direction (Inbound/Outbound) of the transfer. See
the DIRECTION_* constants for a list of legal values. */
public static final String DIRECTION = "direction";
/** The name of the column containing Bluetooth Device Address that the transfer is
associated with. */
public static final String DESTINATION = "destination";
/** The name of the column containing the flags that controls whether the transfer is
displayed by the UI. See the VISIBILITY_* constants for a list of legal values. */
public static final String VISIBILITY = "visibility";
/** The name of the column containing the current user confirmation state of the transfer.
Applications can write to this to confirm the transfer. The USER_CONFIRMATION_*
constants for a list of legal values. */
public static final String USER_CONFIRMATION = "confirm";
/** The name of the column containing the current status of the transfer. Applications can
read this to follow the progress of each download. See * the STATUS_* constants for a list of
legal values. */
public static final String STATUS = "status";
/** The name of the column containing the total size of the file being transferred. */
public static final String TOTAL_BYTES = "total_bytes";
/** The name of the column containing the size of the part of the file that has been transferred
so far.*/
public static final String CURRENT_BYTES = "current_bytes";
/** The name of the column containing the timestamp when the transfer is initialized. */
public static final String TIMESTAMP = "timestamp";
/** This transfer is outbound, e.g. share file to other device. */
public static final int DIRECTION_OUTBOUND = 0;
/** This transfer is inbound, e.g. receive file from other device. */
public static final int DIRECTION_INBOUND = 1;
/** This transfer is waiting for user confirmation. */
public static final int USER_CONFIRMATION_PENDING = 0;
/** This transfer is confirmed by user. */
public static final int USER_CONFIRMATION_CONFIRMED = 1;
/** This transfer is auto-confirmed per previous user confirmation. */
public static final int USER_CONFIRMATION_AUTO_CONFIRMED = 2;
/** This transfer is denied by user. */
public static final int USER_CONFIRMATION_DENIED = 3;
/** This transfer is timeout before user action. */
public static final int USER_CONFIRMATION_TIMEOUT = 4;
/**This transfer is visible and shows in the notifications while in progress and after
completion */
public static final int VISIBILITY_VISIBLE = 0;
/** This transfer doesn't show in the notifications. */
public static final int VISIBILITY_HIDDEN = 1;
/** Returns whether the status is informational (i.e. 1xx). */
public static boolean isStatusInformational(int status) {
return (status >= 100 && status < 200);
}
/**Returns whether the transfer is suspended. (i.e. whether the transfer won't complete
without some action from outside the transfer manager). */
public static boolean isStatusSuspended(int status) {
return (status == STATUS_PENDING);
}
/**Returns whether the status is a success (i.e. 2xx). */
public static boolean isStatusSuccess(int status) {
return (status >= 200 && status < 300);
}
/**Returns whether the status is an error (i.e. 4xx or 5xx). */
public static boolean isStatusError(int status) {
return (status >= 400 && status < 600);
}
/**Returns whether the status is a client error (i.e. 4xx). */
public static boolean isStatusClientError(int status) {
return (status >= 400 && status < 500);
}
/**Returns whether the status is a server error (i.e. 5xx). */
public static boolean isStatusServerError(int status) {
return (status >= 500 && status < 600);
}
/**Returns whether the transfer has completed (either with success or error). */
public static boolean isStatusCompleted(int status) {
return (status >= 200 && status < 300) || (status >= 400 && status < 600);
}
/**This transfer hasn't stated yet */
public static final int STATUS_PENDING = 190;
/**This transfer has started */
public static final int STATUS_RUNNING = 192;
/**This transfer has successfully completed. Warning: there might be other status values that
indicate success in the future. Use isSucccess() to capture the entire category. */
public static final int STATUS_SUCCESS = 200;
/**This request couldn't be parsed. This is also used when processing requests with
unknown /unsupported URI schemes. */
public static final int STATUS_BAD_REQUEST = 400;
/**This transfer is forbidden by target device. */
public static final int STATUS_FORBIDDEN = 403;
/**This transfer can't be performed because the content cannot be handled. */
public static final int STATUS_NOT_ACCEPTABLE = 406;
/**This transfer cannot be performed because the length cannot be determined accurately.
This is the code for the HTTP error "Length Required", which is typically used when making
requests that require a content length but don't have one, and it is also used in the client when
a response is received whose length cannot be determined accurately (therefore making it
impossible to know when a transfer completes). */
public static final int STATUS_LENGTH_REQUIRED = 411;
/**This transfer was interrupted and cannot be resumed. This is the code for the OBEX error
"Precondition Failed", and it is also used in situations where the client doesn't have an ETag
at all. */
public static final int STATUS_PRECONDITION_FAILED = 412;
/**This transfer was canceled */
public static final int STATUS_CANCELED = 490;
/**This transfer has completed with an error. Warning: there will be other status values that
indicate errors in the future. Use isStatusError() to capture the entire category. */
public static final int STATUS_UNKNOWN_ERROR = 491;
/**This transfer couldn't be completed because of a storage issue. Typically, that's because
the file system is missing or full. */
public static final int STATUS_FILE_ERROR = 492;
/**This transfer couldn't be completed because of no sd card. */
public static final int STATUS_ERROR_NO_SDCARD = 493;
/**This transfer couldn't be completed because of sdcard full. */
public static final int STATUS_ERROR_SDCARD_FULL = 494;
/**This transfer couldn't be completed because of an unspecified un-handled OBEX code. */
public static final int STATUS_UNHANDLED_OBEX_CODE = 495;
/**This transfer couldn't be completed because of an error receiving or processing data at the
OBEX level. */
public static final int STATUS_OBEX_DATA_ERROR = 496;
/**This transfer couldn't be completed because of an error when establishing connection */
public static final int STATUS_CONNECTION_ERROR = 497;
}
Intelligent tag activity code
package com.ram.tag;
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.util.ArrayList;
import java.util.Set;
import java.util.UUID;
import android.app.Activity;
import android.bluetooth.BluetoothAdapter;
import android.bluetooth.BluetoothDevice;
import android.bluetooth.BluetoothSocket;
import android.content.BroadcastReceiver;
import android.content.Context;
import android.content.Intent;
import android.content.IntentFilter;
import android.os.Bundle;
import android.provider.Settings.Secure;
import android.telephony.TelephonyManager;
import android.view.ContextMenu;
import android.view.ContextMenu.ContextMenuInfo;
import android.view.MenuItem;
import android.view.View;
import android.view.View.OnClickListener;
import android.view.Window;
import android.widget.Button;
import android.widget.EditText;
import android.widget.TextView;
import android.widget.Toast;
public class IntelligentTagActivity extends Activity {
public static final int REQUEST_ENABLE_BT = 1;
BluetoothAdapter mBluetoothAdapter;
TextView mTitle;
private ConnectThread mConnectThread;
private ConnectedThread mConnectedThread;
EditText tag;
TelephonyManager tManager;
/** Called when the activity is first created. */
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
getWindow().setFeatureInt(Window.FEATURE_CUSTOM_TITLE,R.layout.custom_ti
tle);
// Set up the custom title
mTitle = (TextView) findViewById(R.id.title_left_text);
// mTitle.setText(R.string.app_name);
tag = (EditText) findViewById(R.id.tagname);
Button btn = (Button) findViewById(R.id.button1);
btn.setOnClickListener(new OnClickListener() {
@Override
public void onClick(View v) {
// TODO Auto-generated method stub
registerForContextMenu(v);
}
});
tManager = (TelephonyManager)
getSystemService(Context.TELEPHONY_SERVICE);
// Register the BroadcastReceiver
IntentFilter filter = new IntentFilter(BluetoothDevice.ACTION_FOUND);
registerReceiver(mReceiver, filter); // Don't forget to unregister
// during onDestroy
}
public void onCreateContextMenu(ContextMenu menu, View v, ContextMenuInfo
menuInfo) {
menu.add(0, 1, 0, "Via Bluetooth");
menu.add(0, 2, 0, "Via Wifi");
super.onCreateContextMenu(menu, v, menuInfo);
}
@Override
public boolean onContextItemSelected(MenuItem item) {
switch (item.getItemId()) {
case 1:
checkstatus();
return true;
case 2:
return true;
default:
return super.onContextItemSelected(item);
}
}
private void checkstatus() {
// TODO Auto-generated method stub
mBluetoothAdapter = BluetoothAdapter.getDefaultAdapter();
if (mBluetoothAdapter == null) {
// Device does not support Bluetooth
Toast.makeText(getApplicationContext(),
"Device does not support Bluetooth", Toast.LENGTH_SHORT).show();
}
else if (!mBluetoothAdapter.isEnabled()) {
Intent enableBtIntent = new Intent(
BluetoothAdapter.ACTION_REQUEST_ENABLE);
startActivityForResult(enableBtIntent, REQUEST_ENABLE_BT);
/*Intent discoverableIntent = new // to make device discoverable
* Intent(BluetoothAdapter.ACTION_REQUEST_DISCOVERABLE);
* discoverableIntent
* .putExtra(BluetoothAdapter.EXTRA_DISCOVERABLE_DURATION, 300);
* startActivity(discoverableIntent); */
}
else if (mBluetoothAdapter.isEnabled()) {
Set<BluetoothDevice> pairedDevices = mBluetoothAdapter
.getBondedDevices();
ArrayList<String> mArrayAdapter = new ArrayList<String>();
// If there are paired devices
if (pairedDevices.size() > 0) {
// Loop through paired devices
for (BluetoothDevice device : pairedDevices) {
// Add the name and address to an array adapter to show in a List View
mArrayAdapter.add(device.getName() + "\n"+ device.getAddress());
System.out.println("list :" + device.getName() + "\n"+ device.getAddress());
}
// if(!mArrayAdapter.contains("Wave525"))
mBluetoothAdapter.startDiscovery();
/* else { System.out.println("discovered....."); }*/
}
}
}
@Override
protected void onDestroy() {
// TODO Auto-generated method stub
if(mBluetoothAdapter != null)
mBluetoothAdapter.disable();
unregisterReceiver(mReceiver);
super.onDestroy();
}
// Create a BroadcastReceiver for ACTION_FOUND
private final BroadcastReceiver mReceiver = new BroadcastReceiver() {
public void onReceive(Context context, Intent intent) {
String action = intent.getAction();
// When discovery finds a device
if (BluetoothDevice.ACTION_FOUND.equals(action)) {
// Get the BluetoothDevice object from the Intent
BluetoothDevice device =
intent .getParcelableExtra(BluetoothDevice.EXTRA_DEVICE);
System.out.println("discovering.. :" + device.getName() + "\n"+ device.getAddress());
if (device.getName().contains(tag.getEditableText().toString())) {
System.out.println("discovered.....");
if (mBluetoothAdapter != null)
// mBluetoothAdapter.cancelDiscovery();
mConnectThread = new ConnectThread(device);
mConnectThread.start();
}
}
}
};
private void sendMessage(String message) {
// Create temporary object
ConnectedThread r;
// Synchronize a copy of the ConnectedThread
synchronized (this) {
r = mConnectedThread;
}
// Perform the write unsynchronized
//if(r!= null)
System.out.println("writing...");
r.write(message.getBytes());
}
private class ConnectThread extends Thread {
private final BluetoothSocket mmSocket;
private final BluetoothDevice mmDevice;
public ConnectThread(BluetoothDevice device) {
mmDevice = device;
BluetoothSocket tmp = null;
// Get a BluetoothSocket for a connection with the
// given BluetoothDevice
try {
final String androidId = Secure.getString(
getApplicationContext().getContentResolver(),
Secure.ANDROID_ID);
UUID MY_UUID = UUID.nameUUIDFromBytes(androidId.getBytes("utf8"));
String uuid = tManager.getDeviceId();
// UUID MY_UUID = UUID.fromString(uuid);
UUID.nameUUIDFromBytes(uuid.getBytes("utf8"));
MY_UUID = UUID.randomUUID();
tmp = device.createRfcommSocketToServiceRecord(MY_UUID);
}
catch (IOException e) {
e.printStackTrace();
// Log.e(TAG, "create() failed", e);
}
mmSocket = tmp;
}
public void run() {
System.out.println("BEGIN mConnectThread");
setName("ConnectThread");
// Always cancel discovery because it will slow down a connection
mBluetoothAdapter.cancelDiscovery();
// Make a connection to the BluetoothSocket
try {
// This is a blocking call and will only return on a
// successful connection or an exception
mmSocket.connect();
}
catch (IOException e) {
System.out.println("connection failed");
// connectionFailed();
// Close the socket
try {
mmSocket.close();
}
catch (IOException e2) {
}
return;
}
// Start the connected thread
connected(mmSocket, mmDevice);
}
public void cancel() {
try {
mmSocket.close();
}
catch (IOException e) {
// Log.e(TAG, "close() of connect socket failed", e);
}
}
}
private class ConnectedThread extends Thread {
private final BluetoothSocket mmSocket;
private final InputStream mmInStream;
private final OutputStream mmOutStream;
public ConnectedThread(BluetoothSocket socket) {
// Log.d(TAG, "create ConnectedThread");
mmSocket = socket;
InputStream tmpIn = null;
OutputStream tmpOut = null;
// Get the BluetoothSocket input and output streams
try {
tmpIn = socket.getInputStream();
tmpOut = socket.getOutputStream();
} catch (IOException e) {
// Log.e(TAG, "temp sockets not created", e);
}
mmInStream = tmpIn;
mmOutStream = tmpOut;
}
public void run() {
// Log.i(TAG, "BEGIN mConnectedThread");
byte[] buffer = new byte[1024];
int bytes;
while (true) {
try {
// Read from the InputStream
bytes = mmInStream.read(buffer);
} catch (IOException e) {
// Log.e(TAG, "disconnected", e);
// connectionLost();
break;
}
}
}
/* * Write to the connected OutStream.
* @param buffer
* The bytes to write */
public void write(byte[] buffer) {
try {
mmOutStream.write(buffer);
} catch (IOException e) {
// Log.e(TAG, "Exception during write", e);
}
}
public void cancel() {
try {
mmSocket.close();
}
catch (IOException e) {
// Log.e(TAG, "close() of connect socket failed", e);
}
}
}
public synchronized void connected(BluetoothSocket socket,
BluetoothDevice device) {
// Cancel the thread that completed the connection
if (mConnectThread != null) {
mConnectThread.cancel();
mConnectThread = null;
}
// Cancel any thread currently running a connection
if (mConnectedThread != null) {
mConnectedThread.cancel();
mConnectedThread = null;
}
// Cancel the accept thread because we only want to connect to one device
// Start the thread to manage the connection and perform transmissions
mConnectedThread = new ConnectedThread(socket);
mConnectedThread.start();
sendMessage("hi");
}
}
8. EXPERIMENTATION RESULTS
A software component has been installed on the TAG side to simulate the occurrence of
a particular type of attack so that the software developed using the architecture proposed is
tested thoroughly. Communication is effected through different combinations of the
communication protocols. The kind of attack that is affected is displayed on the Tag side
LCD and Mobile Side display system. Messages indicating the attack are sent from TAG side
to mobile side. The messages are also displayed on the Tag side LCD and the mobile side
display system. The output displayed on the TAG and mobile side are tabulated and shown in
the table 8.1. It could be seen from the table 8.1 that under the conductions, the date and time
of transmission and reception are also displayed on the LCD and Display system and then
same are also recorded in the table 8.1. It could be seen from the table that the response time
achieved is still within the limits even though more amount of code has to be executed due to
implementation of counter attacking method.
The proposed method of security mechanism is implemented through Embedded-C under
Integrated KEIL development tool kit. The Tag searches for the available devices within its
vicinity. With the developed security mechanism, if there is no sign of attack on the
communication link between a Tag and the mobile device, the system will perform the
communication without any overhead of enabling the counter-measure mechanisms. If the
system detects any attack being performed, then the appropriate counter-attacking mechanism
will be enabled and secures the communication link between them. This can be demonstrated
by providing the experimental results as shown below.
The intelligence module on the Tag side and Mobile side has sensed an attack which
sends continuous requests to each device to suspend its communication with each other. This
can be known to the user by using the user interface on either side as shown in figure 8.1 and
figure 8.2. By enabling the counter-measure selector to choose the appropriate counter
attacking mechanisms, the processing time of the communication link and the transmission
time and reception time of data on either side are as depicted in the table 8.1.
Figure 8.45 Attack on the Tag Side
Figure 8.46 Attack on the Mobile side
Table 8-11 Experimental results for counter attacking methods
Attack Initiated
Counter Attack Initiated
Port Selected on the Tag side
Message sent from Tag side
Transmission Port Selected on the Mobile side
Message Received on the Mobile Side
Reception
Wi-Fi Bluetooth Date Time of Transmission
Wi-Fi Bluetooth
Date Time Response in secs
1 - - √ POWS 10/06
10.00 √ POWS
10/06
10.01 0.01
2 Blue Snarfing attack
Authentication using PINs or Passwords
√ BSAT 10/06
10.05 √ BSAT
10/06
10.07 0.02
3 Blue Bugging attack
RF Signatures √ BBAT 10/06
10.10 √ BBAT
10/06
10.12 0.02
4 Man-in-the-Middle attack
Encryption / Decryption with Time-out Mechanism
√ MMAT 10/06
10.20 √ MMAT
10/06
10.22 0.02
5 Denial of Service attack
Intrusion Detection System
√ DSAT 10/06
10.25 √ DSAT
10/06
10.27 0.02
6 Evil Twin Access Point attack
Avoid SSID broadcasting
√ ACAT 10/06
10.30 √ ACAT
10/06
10.32 0.02
7 Replay attack
Assignment of Session Tokens
√ RAAT 10/06
10.35 √ RAAT
10/06
10.37 0.02
9. Summary and Conclusions
The devices used in the intelligent TAG systems are limited in the resources. The peer to
peer communication between the TAG and the Mobile device is quite vulnerable. Adding the
entire required infrastructure to the TAG and the mobile device requires many resources and
providing such kind of resources is impracticable. Adding any software load for
implementing the permanent counter attacking measures drastically effects the response time
and throughput of transacting between the mobile device and the TAG. Intelligence has been
added for sensing any attack and the counter attacking measure only come into force when
any of the attacks are initiated.
The software architecture has been presented for building intelligence to the system for
securing the communication between Host and a Tag. This architecture is well suited to
implement intelligence into the embedded systems with security as a major concern. The
software required for the system was designed using the architecture presented in this thesis
and the same has been implemented within the separately designed embedded system.
10. FUTURE WORK
REFERENCES:
1. Dieter Hutter, Günter Müller, Werner Stephan, and Markus Ullmann, March 2003,
“Security and privacy aspects of low-cost radio frequency identification systems,” in
Int. Conf. on Security in Pervasive Computing, volume 2802 of Lecture Notes in
Comput. Science, pages 454–469.
2. Miyako Ohkubo, Koutarou Suzuki, and Shingo Kinoshita, November
2003,“Cryptographic approach to “privacy-friendly” tags,” in RFID Privacy
Workshop, MIT, MA, USA,.
3. Dirk Henrici and Paul Müller, March 2004,“Hash-based enhancement of location
privacy for radio-frequency identification devices using varying identifiers,” in Int.
Workshop on Pervasive Computing and Communication Security – PerSec pages
149–153.
4. Tassos Dimitriou, September 2005, “A lightweight RFID protocol to protect against
traceability and cloning attacks,” in International Conference on Security and Privacy
for Emerging Areas in Communication Networks, IEEE, pages 59-66.
5. Su-Mi Lee, Young Ju Hwang, Dong Hoon Lee, and Jong In Lim Lim, 2005,
“Efficient authentication for low-cost RFID systems,” in Int. Conf. on Computational
Science and its Applications - ICCSA.
6. David Molnar and David Wagner, October 2004, “Privacy and security in library
RFID: Issues, practices, and architectures,” in Conf. on Comput. and Commun.
Security – ACM CCS, pages 210–219, Washington, DC, USA.
7. Xingxin (Grace) Gao, Zhe (Alex) Xiang, Hao Wang, Jun Shen, Jian Huang, and Song
Song, September 2005, “An approach to security and privacy of RFID system for
supply chain,” in International Conference on E-Commerce Technology for Dynamic
E-Business – CEC-East’04, pages 164–168, Beijing, China.
8. Dominic Spill and Andrea Bittau, “Blue Sniff: Eve meets Alice and Bluetooth”,
University College London.
9. Dr JKR Sastry, N. Venkatram, Y. Pavan Kumar, N. Rajesh Babu, May 2012, “On
building intelligence for securing communication between the Tags and the Mobile
Devices” in International Journal Of Mobile and Adhoc Network - IFRSA, Volume 2,
Issue 2.
10. Dr JKR Sastry, N. Venkatram, Y. Pavan Kumar, N. Rajesh Babu, June 2012,
“Development of Software Architecture for Building Intelligence to Secure the
Communication between the Tags and Mobile Devices” in IJVES – Technical
Journals, Volume 3, Issue 2.
11. www.arm.com
12. LPC2148 Manual
13. http://en.wikipedia.org/wiki/EEPROM
14. M. A. Mazidi, J. C. Mazidi, R. D. Mckinaly, “The 8051 Microcontroller and
Embedded Systems”, Pearson Education, 2011.
15. www.quectel.com
16. www.sena.com/download/certification/Bluetooth_SIG_Guide-V1.pdf
17. www.digi.com/pdf/ds_xbeewifi.pdf
18. http://www.keil.com/uvision/db_sim.asp
APPENDIX