[attachment=15048]

BLUE TOOTH SECURITY IMPLEMENTED USING VHDL


ABSTRACT:
Blue tooth is a short-range radio page 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:
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 page link control unit, and a support unit for page link management and host terminal interface functions. This paper describes the specifications of the Blue tooth page link controller which carries out the base band protocols and lower level page 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) page link and Asynchronous Connection-Less (ACL) link.
The SCO page link is a point-to-point page link between a master and a single slave in the Pico net. The ACL page link is a point-to-multipoint page 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.
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 page 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 page link type associated with the packet. First, it shall be determined whether the packet is sent on an SCO page 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
This bit is used for flow control of packets over the ACL link. When the RX buffer for the ACL page link in the recipient is full and is not emptied by the page 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
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 page 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 page 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
TX payload generation

T
RF interface


Rx payload
PALOAD BIT PROCESS
2.4.2.3. CRC code generation
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.
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 page link layer. These measures shall be appropriate for a peer environment. Four different entities are used for maintaining security at the page 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 A 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.
b) Decrypt by computing P= C A 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