ANMIAN

Security Mode 4

 the Bluetooth specification specifies four levels of security for Bluetooth 

services for use during Secure Simple Pairing (SSP): 

Service Level 3 

requires man-in-the-middle (MITM) protection and encryption; user interaction is acceptable. 

Service Level 2 

requires encryption only; MITM protection is not necessary. 

Service Level 1 

does not require MITM protection and encryption; user interaction is minimal. 

Service Level 0 

does not require MITM protection, encryption, or user interaction. 

5.2.1.1 Security mode 1 (non-secure)

When a remote Bluetooth device is in security mode 1 it will never initiate any

security procedure (i.e., it will never send LMP_au_rand, LMP_in_rand or

LMP_encryption_mode_req).

5.2.1.2 Security mode 2 (service level enforced security)

When a remote Bluetooth device is in security mode 2 it will not initiate any

security procedure before a channel establishment request

(L2CAP_ConnectReq) has been received or a channel establishment procedure

has been initiated by itself. (The behavior of a device in security mode 2 is

further described in [11].) Whether a security procedure is initiated or not

depends on the security requirements of the requested channel or service.

A Bluetooth device in security mode 2 should classify the security requirements

of its services using at least the following attributes:

• Authorization required

• Authentication required

• Encryption required

Note: Security mode 1 can be considered (at least from a remote device point

of view) as a special case of security mode 2 where no service has registered

any security requirements.

5.2.1.3 Security modes 3 (link level enforced security)

When a remote Bluetooth device is in security mode 3 it will initiate security

procedures before it sends LMP_setup_complete. (The behavior of a device in

security mode 3 is as described in [3].)

A Bluetooth device in security mode 3 may reject the host connection request

(respond with LMP_not_accepted to the LMP_host_connection_req) based on

settings in the host (e.g. only communication with pre-paired devices allowed).

5.2.2 Security mode 4 (service level enforced security)

A Bluetooth device in security mode 4 shall classify the security requirements

of its services using at least the following attributes (in order of decreasing

security):

• Authenticated link key required

• Unauthenticated link key required

• No security required

An authenticated link key is a link key where either the numeric comparison,

out-of-band or passkey entry simple pairing association models were used. An

authenticated link key has protection against man-in-the-middle (MITM)

attacks. To ensure that an authenticated link key is created during the Simple

Pairing procedure, the Authentication_Requirements parameter should be set

to one of the MITM Protection Required options. An unauthenticated link key is

a link key where the just works Secure Simple Pairing association model was

used. An unauthenticated link key does not have protection against MITM

attacks.

When both devices support Secure Simple Pairing, GAP shall default to requiring

an unauthenticated link key and enabling encryption. A profile or protocol

may define services that require more security (e.g. an authenticated link key).

or no security. To allow an unauthenticated link key to be created during the

Simple Pairing procedure, the Authentication_Requirements parameter may be

set to one of the MITM Protection Not Required options.

When the device is in Bondable Mode, it shall enable Secure Simple Pairing

mode prior to entering Connectable Mode or establishing a link.

Device rejected?

LMP_not_accepted LMP_accepted

yes no

Authentication /

Pairing

Encrypt

26 July 2007 Security Aspects

BLUETOOTH SPECIFICATION Version 2.1 + EDR [vol 3] page 198 of 268

Generic Access Profile

A Bluetooth device in security mode 4 shall respond to authentication requests

during link establishment when the remote device is in security mode 3 for

backwards compatibility reasons.

A Bluetooth device in security mode 4 enforces its security requirements before

it attempts to access services offered by a remote device and before it grants

access to services it offers to remote devices. Service access may occur via

L2CAP channels or via channels established by protocols above L2CAP such

as RFCOMM.

증상 : Vega series에서 HID를 연결하면 Phone state가 connecting에서 머물러 있음

원인 : device가 master role을 가져가려고 하면 host(phone)가 정상적으로 처리하지 못함

해결 : device를 slave role로 설정

SCO (Synchronized connection oriented) Packet

1. HV1 Packet

HV는 High-quality Voice의 약어로 이것은 10바이트의 데이터를 송신하는 패킷이다.

데이터는 1/3 FEC로 에러 보정을 하고 있다.

PAYLOAD의 길이는 240 bit로 PAYLOAD 내의 Header는 없다.

이 패킷을 사용하여 64Kbps의 음성데이터를 송신하는 경우 1.25ms 주기로 송신이 가능하다.

2. HV2 Packet

20바이트의 데이터를 송신하는 패킷이다.

데이터는 2/3 FEC로 에러 보정을 하고 있다.

PAYLOAD의 길이는 240 bit로 PAYLOAD 내의 Header는 없다.

이 패킷을 사용하여 64Kbps의 음성데이터를 송신하는 경우 2.5ms 주기의 송신이 가능하다.

3. HV3 Packet

30바이트의 데이터를 송신하는 패킷이다.

데이터는 FEC로 에러보정이 되지 않는다.

PAYLOAD의 길이는 240bit로 PAYLOAD 내의 Header는 없다.

이 패킷을 사용하여 64Kbps의 음성데이터을 송신하는 경우 3.75ms 주기의 송신이 가능히다.

4. DV Packet

DV는 Data Voice의 약자로 이것은 음성정보와 비음성정보를 동시에 전송하는 패킷이다.

HV1 packet을 대신할 때만 사용된다. 

PAYLOAD의 부분은 80bit 음성 field, 150bit의 데이터 필드가 구성되어 있다.

음성field는 FEC에 의한 에러 보정이 되어 있지 않다.

ACL (Asynchronous Connectionless Link) Packet

1. DM1 Packet

DM은 Data-Medium rate의 약어로, 18바이트의 데이터와 16bit의 CRC를 전송한다.

데이터는 2/3 FEC로 에러 보정되고 있다.

DM1은 1slot/packet 송신을 한다.

2. DH1 Packet

DH는 Data-High rate의 약어로, 28바이트의 데이터와 16bit의 CRC를 전송한다.

데이터는 FEC 에러보정은 하지 않느다.

DH1은 1slot/packet 송신을 한다.

3. DM3 Packet

DM3 패킷은 DM1 패킷의 PAYLOAD를 확장한 것으로 3slot/packet 송신을 한다.

2~123바이트의 데이터와 16비트의 CRC를 전송한다.

데이터는 2/3 FEC에 의한 에러보정을 하고 있다.

3slot을 송신하는 중간에는 주파수 변환을 실시하지 않는다.

4. DH3 Packet

DH3 패킷은 FEC를 하지 않는것 이외에는 DM3와 동일하다.

FEC를 하지 않으므로 2~185바이트의 데이터 전송이 가능하다.

5. DM5 Packet

DM5 패킷은 DM1 패킷의 PAYLOAD를 확장한 것으로 5slot/packet 송신을 한다.

2~226바이트의 데이터와 16비트의 CRC를 전송한다.

데이터는 2/3 FEC로 에로보정을 한다.

5slot을 송신하는 중간에는 주파수 변환을 하지 않는다.

6. DH5 Packet

DH5 Packet은 FEC를 하지 않는 것 이외에는 DM5 패킷과 동일하다.

FEC를 하지 않기 때문에 2~341바이트의 데이터 전송이 가능하다.

7. AUX1 Packet

AUX1 패킷은 CRC 에러 체크가 없는 것 이외에는 DH1 패킷과 동일하다.

CRC가 없으므로 1~30바이트의 데이터 전송이 가능하다. AUX1은 ACL-U, ACL-C logical links를 사용하지 않는다.

2-DH1 : DH1과 비슷, π/4-DQPSK 사용. 2~56bytes

2-DH3 : DH3과 비슷. π/4-DQPSK 사용. 2~369bytes. 3 time slots

2-DH5 : DH5와 비슷. π/4-DQPSK 사용. 2~681bytes. 5 time slots

3-DH1 : DH1과 비슷. 8DPSK 사용. 2~85bytes

3-DH3 : DH3과 비슷. 8DPSK 사용. 2~554 bytes. 3 time slots

3-DH5 : DH5와 비슷. 8DPSK 사용. 2~1023 bytes. 5 time slots

eSCO packets

* eSCO links were added in version 1.2 of the Bluetooth specification.

Following a request from either the master or slave device, the master may establish an eSCO link to that device.

* eSCO packets are always transmitted in predetermined time slots: the regular interval between eSCO packets is specified when the link is established.

* eSCO packets can be 1 or 3 slots in length.

* eSCO packets to/from a specific slave are acknowledged, and may be retransmitted if not acknowledged.

The packet type is determined by the TYPE code in the header:

NULL No payload. Used for acknowledgements or flow control.

POLL No payload. Used by the master to poll slaves. Requires acknowledgement.

8. EV3 Extended Voice (no error correction), 1 slot: maximum 30 data bytes plus a 16-bit CRC. 1~30bytes

9. EV4 Extended Voice (2/3 rate FEC), 3 slots: maximum 120 data bytes plus a 16-bit CRC. 1~120bytes

10. EV5 Extended Voice (no error correction), 3 slots: maximum 180 data bytes plus a 16-bit CRC. 1~180bytes

11. 2-EV3 : EV3과 비슷하며 π/4-DQPSK 사용. 1~60bytes

12. 2-EV5 : EV5와 비슷하며  π/4-DQPSK 사용. 1~360bytes.

13. 3-EV3 : EV3과 비슷하며 8DPSK 사용. 1~90bytes.

14. 3-EV5 : EV5와 비슷하며 8DPSK 사용. 1~540bytes