【蓝牙开发】Bluetooth Security 中的Security modes

背景介绍

针对传统蓝牙的产品, 提到安全等级时我们常常会听到mode 4. level 3, 但对于具体什么是mode 4? 什么是level 3却一知半解.
而本文会基于Bluetooth Spec初步关于蓝牙安全的mode和level相关的知识点.

BR/EDR(传统蓝牙) 中的Security modes

如上图所示，在security channel 建立过程会根据Responding device version(对端设备)的蓝牙版本来选择Security Mode, 这点也说明了一个设备为了兼任旧版本的蓝牙可能会存在多个Security mode. 需要注意的是:

security mode 2 for backwards compatibility with remote devices that do not support Secure Simple Pairing(security mode 2是对于不支持SSP的蓝牙设备)
security mode 4 for devices that support Secure Simple Pairing(security mode 4是对于支持SSP的设备)

需要补充一点的是: 有些同学可能会不理解Security mode的意思，关于这一点我们暂时可以将Security mode理解为蓝牙协议中对于安全级别的划分或模式的划分，不同的Secutiy mode会有对应的不同动作.

Legacy security modes(引用于Bluetooth Spec, 也希望大家能通过BT Spec进行蓝牙协议的学习)

Legacy security modes apply to those devices with a Controller or a Host that does not support SSP.
而 Legacy security modes 包含了如下三种:

Security mode 1 (non-secure)
Security mode 2 (service level enforced security)
Security mode 3 (link level enforced security)

Security mode 1 (non-secure)

当对端的设备为Security mode1时，就不需要做任何的加密的行为

Security mode 2 (service level enforced security)

当对端设备为security mode 2，就需要做service level的安全化(也就是加密)，有些同学可能会疑问？什么是service level？在Bluetooth Spec中有如下小段的描述:

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

也就是service level enforced security可以理解为是再L2CAP 之上的安全化(加密)，对于建立L2CAP之前的ACL和LMP是不需要加密的.

Security mode 3 (link level enforced security)

当对端的设备为Security mode3时, 需要在发起LMP_SETUP_COMPLETE之前就需要启动安全流程.

Security mode 4 (service level enforced security)

处于Security mode 4的蓝牙设备应至少使用以下属性对其服务的安全需求进行分类(按安全性降低的顺序)

Authenticated link key required
Unauthenticated link key required
Security optional; limited to specific services
这里需要注意的是:

对于传统蓝牙，Security mode 4 是对于支持 Secure Simple Pairing(SSP)的设备.
SSP对应的association models(交互模型)中，numeric comparison, out-of-band, or passkey entry使用的是“Authenticated link key required”，而“just works Secure Simple Pairing association model“对应的是"Unauthenticated link key required"
An unauthenticated link key does not have protection against MITM attacks.
更详细的说明请看: Bluetooth Core Specification v5.2 -> Host -> Part C: Generic Access Profile -> 5 Security aspects - BR/EDR physical transport -> Securtiy modes

BR/EDR(传统蓝牙)中提到的level

我们在BR/EDR中常常听到的mode 4, level 3中的level是针对security mode 4而言的，在前面的文章中提到了Securtiy mode 4有几种安全等级分类，也就是这里对应的Level * ，可以理解为进一步的规范定义.

Level 4, for services with the following attributes:
MITM protection required
128-bit equivalent strength for link and encryption keys required using FIPS
approved algorithms (E0 not allowed, SAFER+ not allowed, and P-192 not
allowed; encryption key not shortened)
User interaction acceptable
Level 3, for services with the following attributes:
MITM protection required
Encryption required
At least 56-bit equivalent strength for encryption key should be used
User interaction acceptable
Level 2, for services with the following attributes:
MITM protection not required
Encryption required
At least 56-bit equivalent strength for encryption key should be used
Level 1, for services with the following attributes:
MITM protection not required
At least 56-bit equivalent strength for encryption key when encryption is
enabled should be used
Minimal user interaction desired
Level 0: Service requires the following:
MITM protection not required
No encryption required
No user interaction required