BLUE TOOTH SECURITY IMPLEMENTED

USING VHDL

http://www.eforu.page.tl/
ABSTRACT:
Blue tooth is a short-range radio link intended to be a cable replacement between
portable and/or fixed electronic devices. A frequency hop transceiver is applied to
combat interference and fading. It also has a built-in security at the physical layer. Blue
tooth employs several layers of data encryption and user authentication measures. This
paper deals with the base band layer of Blue tooth and its security. The general format of
packet transmission is access code followed by the payload and the header. The datas
transmitted in this technology may be corrupted or accessed by the public users.
Although there are some security measures in Bluetooth, they is a need for improved
security of datas. Hence the Bluetooth is modified with additional security measures by
employing the RSA algorithm. This RSA algorithm is applied in the payload of the
packet. We implement this by the method of cryptography where the payload is
encrypted at the transmitter and decrypted at the recevier using RSA cryptography.
When compared to the builtin security this additional security allows secure exchange of
datas. This was simulated in VHDL software.

INTRODUCTION:

http://www.eforu.page.tl/
 Blue tooth operates in the unlicensed ISM band at 2.4 GHz. The key features are
robustness, low complexity, low power, and low cost. On the channel, information is
exchanged through packets. Each packet is transmitted on a different hop frequency. A
packet nominally covers a single slot, but can be extended to cover up to five slots. The
Blue tooth protocol uses a combination of circuit and packet switching. Slots can be
reserved for synchronous packets. The Blue tooth system consists of a radio unit, a link
control unit, and a support unit for link management and host terminal interface
functions. This paper describes the specifications of the Blue tooth link controller which
carries out the base band protocols and lower level link routines. The Blue tooth system
provides a point-to-point connection or a point-to-multipoint connection. Two or more
units sharing the same channel form a Pico net. One Blue tooth unit acts as the master of
the Pico net, whereas the other units acts as slaves. Multiple Pico nets with overlapping
coverage areas forms a scatter net. Each Pico net can only have a single master. The Pico
nets shall not be time or frequency synchronized. Each Pico net has its own hopping
channel. The channel is represented by a pseudo-random hopping sequence hopping
through the 79 or 23 RF channels. The channel is divided into time slots each 625 ms in
length. A TDD scheme is used where master and slave transmit alternatively. The data
transmitted has a symbol rate of 1 Ms/s. Two different types of links that can be
established between master and slaves are Synchronous Connection-Oriented (SCO) link
and Asynchronous Connection-Less (ACL) link.

http://www.eforu.page.tl/
 The SCO link is a point-to-point link between a master and a single slave in the
Pico net. The ACL link is a point-to-multipoint link between the master and all the slaves
participating on the Pico net. There are many different packet types, which can be
transmitted. In the packet the payload can have either data field or voice field or even
both. The 2/3 rates FEC scheme is used for error correction. Before transmission, both
the header and the payload are scrambled with a data whitening word in order to
randomize the data from highly redundant patterns and to minimize DC bias in the
packet. Before the user information is sent over the air interface, several bit
manipulations are performed in the transmitter to increase reliability and security. Low
power operations are ensured in blue tooth. After implementing a blue tooth packet with
base band specifications we employ RSA cryptography for secure data transmissions.
2. PACKETS

LSB MSB
ACCESS CODE HEADER PAYLAOD

72 54 0-2745

The above figure shows the standard packet format.

http://www.eforu.page.tl/
2.1. ACCESS CODE
Each packet, with the exception of the FHS packet starts with a 72-bit access
code. This access code is used for synchronization DC offset compensation and
identification. The access code identifies all packets exchanged on the channel of the Pico
net. All packets sent in the same Pico net are preceded by the same channel access
code. The access code is also used in paging and inquiry procedures. In this case, the
access code itself is used as a signaling message and neither a header nor a payload is
present. The access code consists of a preamble, a sync word, and possibly a trailer.
There are three different types of access codes defined. They are the Channel Access
Code (CAC), the Device Access Code (DAC) and the Inquiry Access Code (IAC).
2.2. PACKET HEADER
The header contains link control (LC) information and consists of 6 fields. They
are the AM_ADDR(3- bit active member address), TYPE(4-bit type code), FLOW(1-bit
flow control), ARQN(1-bit acknowledge indication), SEQN(1-bit sequence number),
HEC (8-bit header error check).
2.2.1. AM_ADDR
The AM_ADDR represents a member address and is used to distinguish between
the active members participating on the Pico net. In a Pico net, one or more slaves are
connected to a single master. To identify each slave separately, each slave is assigned a
temporary 3-bit address to be used when it is active. The all-zero address is reserved for
broadcasting packets from the master to the slaves.
2.2.2. TYPE
Sixteen different types of packets can be distinguished. The 4-bit TYPE code
specifies which packet type is used. The interpretation of the TYPE code depends on the
physical link type associated with the packet. First, it shall be determined whether the
packet is sent on an SCO link or an ACL link. Then it can be determined which type of
SCO packet or ACL packet has been received. The TYPE code also reveals how many
slots the current packet will occupy.
2.2.3. FLOW

http://www.eforu.page.tl/
 This bit is used for flow control of packets over the ACL link. When the RX
buffer for the ACL link in the recipient is full and is not emptied by the link support unit,
a STOP indication (FLOW=0) is returned to stop the transmission of data temporarily.
When the RX buffer is empty, a GO indication (FLOW=1) is returned. When no packet is
received or the received header is in error, a GO is assumed implicitly.
2.2.4. ARQN
The 1-bit acknowledgment indication ARQN is used to inform the source of a
successful transfer of payload data with CRC and can be positive acknowledge ACK or
negative acknowledge NAK. If the reception was successful, an ACK (ARQN=1) is
returned, otherwise a NAK (ARQN=0) is returned. When no return message regarding
acknowledge is received, a NAK is assumed implicitly. NAK is also the default return
information.
2.2.5. SEQN
The SEQN bit provides a sequential numbering scheme to order the data packet
stream. For each new transmitted packet that contains data with CRC, the SEQN bit is
inverted. This is required to filter out retransmissions in the destination. If a
retransmission occurs due to a failing ACK, the destination receives the same packet
twice. By comparing the SEQN of consecutive packets, correctly received
retransmissions can be discarded. The SEQN has to be added due to a lack of packet
numbering in the unnumbered ARQ scheme.
2.2.6. HEC
Each header has a header-error-check to check the header integrity. The HEC
consists of an 8-bit word generated by the polynomial 647 (octal representation). Before
generating the HEC, the HEC generator is initialized with an 8-bit value. After the
initialization, a HEC is calculated for the 10 header bits. Before checking the HEC, the
receiver must initialize the HEC check circuitry with the proper 8-bit UAP (or DCI). If
the HEC does not check, the entire packet is disregarded.
2.3. PACKET TYPES

http://www.eforu.page.tl/
 The packets used on the Pico net are related to the physical links they are used in.
There are two physical links defined. They are the SCO link and the ACL link. For each
of these links, 12 different packet types can be defined. Four control packets will be
common to all link types.
To indicate the different packets on a link, the 4-bit TYPE code is used. The
common packet types are ID, NULL, POLL, FHS and DM1. The SCO packets defined so
far are HV1, HV2, HV3 and DV. The ACL packets are DM1, DH1, DM3, DH3, DM5,
DH5 and AUX1.
2.4. PAYLOAD
The two fields in the payload are the (synchronous) voice field and the
(asynchronous) data field. The ACL packets only have the data field and the SCO packets
only have the voice field with the exception of the DV packets, which has both.
2.4.1. Voice field
The voice field has a fixed length. For the HV packets, the voice field length is
240 bits and for the DV packet the voice field length is 80 bits. No payload header is
present.
2.4.2. Data field
The data field consists of three segments. They are the payload header, the
payload body and the CRC code.
2.4.2.1. Payload header
Only data fields have a payload header. The payload header is one or two bytes
long. The payload header specifies the logical channel (2-bit L_CH indication), controls
the flow on the logical channels (1-bit FLOW indication), and has a payload length
indicator (5 bits and 9 bits for 1-byte and 2-bytes payload header, respectively).
2.4.2.2. Payload body
The payload body includes the user host information and determines the effective
user throughput. The length of the payload body is indicated in the length field of the
payload header. The optional processes are indicated in dashed boxes.

CRC Encryption Whitening Encoding

generation
TX payload

http://www.eforu.page.tl/
 RF interface

CRC checking Decryption De-Whitening Decoding

Rx payload

PALOAD BIT PROCESS

2.4.2.3. CRC code generation

http://www.eforu.page.tl/
 The 16-bit cyclic redundancy check code in the payload is generated by
the CRC-CCITT polynomial 210041 (octal representation). It is generated in a similar
fashion as the HEC. Before determining the CRC code, an 8-bit value is used to initialize
the CRC generator. The 8 bits are loaded into the 8 least significant (left-most) positions
of the LFSR circuit. The other 8 bits are at the same time reset to zero. Subsequently, the
CRC code is calculated over the information. Then the CRC code is appended to the
information. At the receiver side, the CRC circuitry is in the same way initialized with
the 8-bit UAP (DCI) before the received information is checked.

3. ERROR CORRECTION
There are three error correction schemes defined for Blue tooth to reduce the
number of retransmissions. They are 1/3 rate FEC, 2/3 rates FEC, and ARQ scheme for
the data. The scheme followed in this paper is 2/3 rates FEC. The purpose of the FEC
scheme on the data payload is to reduce the number of retransmissions.

4. ERROR CHECKING
The packets can be checked for errors or wrong delivery using the channel access
code, the HEC in the header, and the CRC in the payload. At packet reception, first the
access code is checked. Since the 64-bit sync word in the channel access code is derived
from the 24-bit master LAP, this checks if the LAP is correct, and prevents the receiver
from accepting a packet of another Pico net. The HEC and CRC are used to check both
on errors and on a wrong address.

5. DATA WHITENING
Before transmission, both the header and the payload are scrambled with a data
whitening word in order to randomize the data from highly redundant patterns and to
minimize DC bias in the packet. The scrambling is performed prior to the FEC encoding.
At the receiver, the received data is described using the same whitening word generated
in the recipient. The describing is performed after FEC decoding.

http://www.eforu.page.tl/
6. BLUETOOTH SECURITY
The Blue tooth technology provides peer-to-peer communications over short
distances. In order to provide usage protection and information confidentiality, the
system has to provide security measures both at the application layer and the link layer.
These measures shall be appropriate for a peer environment. Four different entities are
used for maintaining security at the link layer: a public address which is unique for each
user, two secret keys, and a random number, which is different for each new transaction.

7. RSA ALGORITHM
RSA cryptosystem is followed here protecting sensitive information. The RSA
encryption is used in the transmission of payload and the RSA decryption is used in
reception of payload. The RSA cipher is a public key cryptosystem. The knowledge of
the encoding key does not reveal the knowledge of the decoding key. The public key is
open to the public and the private key is kept as a secret.
The steps involved in the RSA cipher are as follows
1.Preparation
a) Choose two primes p and q so that their product n=p*q is greater than the used
alphabet length M.
b) Compute p (n)= (p-1)*(q-1).
2. Encryption
a) Choose a public encoding key e that has to be relatively prime to p (n).
b) Encrypt each plain letter P by computing C= p ^ e MOD n. Here the public key is
(n, e).
3. Decryption
a) The private decoding key d is chosen as the inverse of e MOD p (n): e*d=1 MOD
p(n).
Mathematically, find integers d and k that fulfill: e*d=1+k*p (n) via the extended
Euclidean Algorithm.

http://www.eforu.page.tl/
b) Decrypt by computing P= C ^ d MOD n. Here the private key is (d, n).

8. CONCLUSION
Blue tooth employs frequency hopping (1600 hops/sec), which adds some
protection against eavesdropping. The datas transmitted in this technology may be
corrupted or accessed by the public users. Although there are some security measures in
Bluetooth, we require full security of datas. Hence additional security measures is
included in this project by implementing the RSA algorithm. The current status of
security is limited for the higher capacity of data’s. When the capacity of data’s increase
the division of hopping will not be satisfactory. The Blue tooth’s security seemed to be
adequate only for small ad hoc networks. It seems that the security of Blue tooth is still
inadequate for any serious, security sensitive work. So there is a possibility of leakage of
data’s to the public. By implementing the RSA algorithm in the Blue tooth base band
controller the message will be more secure. This has been tested and implemented with
the front end of FPGA kit and the back end of WARP.

References

1. R. L. Rivest, A. Shamir, and L. Adleman, “ A method for obtaining digital

signatures and public key cryptosystems,” Communication, ACM. Vol. 21, pp.
120- 126, 1978
2. J. Bhasker, A VHDL synthesis primer, Star Galaxy Publishing, New York, 1996
3. Zoran Salcic, Asim Smailagic, Digital System Design and Prototyping using Field
Programmabel Logic, Kluwer Academic Publishers, 1997
4. Peter J. Ashenden, The Designers’ guide to VHDL, Morgan Kaufmann
Publishers, Inc. pp. 351, Netherlands, 1996

http://www.eforu.page.tl/