OpenHarmony藍牙自動配對流程分析
前言
大家在實際使用藍牙時會發現，有些藍牙設備配對需要輸入配對碼，有些藍牙設備則會自動配對；那這些設備有什么區別，OpenHarmony的藍牙協議棧又是怎么實現的呢？本文對此進行分析和解讀。
藍牙協議分析
SSP(SECURE SIMPLE PAIRING)時當前藍牙協議中最推薦采用的認證配對方案；在SSP配對模式下，認證配對總體分為兩步：IO Capability信息交換和用戶確認。
IO Capability
藍牙設備按照輸入輸出能力分為四類，以設備A作Initiator組合后認證配置方式如下表：
設備B\設備A | DisplayOnly | DisplayYesNo | KeyboardOnly | NoInputNoOutput |
DisplayOnly | 自動配對 | A用戶確認，B自動配對 | B顯示數字，A輸入 | 自動配對 |
DisplayYesNo | A自動配對，B用戶確認 | 用戶確認 | B顯示數字，A輸入 | A自動配對，B用戶確認 |
KeyboardOnly | A顯示數字，B輸入 | A顯示數字，B輸入 | 輸入passkey | 自動配對 |
NoInputNoOutput | 自動配對 | B自動配對，A用戶確認 | 自動配對 | 自動配對 |
交換設備IO Capability信息流程如下圖：
MITM Protection
參考藍牙core specification Version 5.4 | Vol 4, Part E, 7.1.29，可以發現IO Capability消息中除了IO_Capability字段還包括Authentication_Requirements字段，該字段同樣影響設備配對流程。
man-in-the-middle(MITM) ，中間人攻擊是一種常見的攻擊手法，藍牙SSP機制在用戶確認模式時可以有效防止中間人攻擊。
協議規定：如果兩臺設備都明確指定不需要進行MITM攻擊保護，設備應該按照自動匹配流程處理。
用戶確認
host收到User_Confirmation_Request消息后需要按照上表中的IO Capability要求用戶確認或自動回復確認信息。
OpenHarmony實現流程
IO Capability信息交換
void GapOnIOCapabilityResponseEvent(const HciIoCapabilityResponseEventParam *eventParam)
{
LOG_DEBUG("%{public}s:" BT_ADDR_FMT "", __FUNCTION__, BT_ADDR_FMT_OUTPUT(eventParam->bdAddr.raw));
BtAddr addr = BT_ADDR_NULL;
GapChangeHCIAddr(&addr, &eventParam->bdAddr, BT_PUBLIC_DEVICE_ADDRESS);
DeviceInfo *devInfo = NULL;
devInfo = ListForEachData(GapGetConnectionInfoBlock()->devicelist, GapFindConnectionDeviceByAddr, (void *)&addr);
if (devInfo != NULL) {
devInfo->remoteAuthReq = eventParam->authenticationRequirements;
}
if (g_authenticationCallback.callback.IOCapabilityRsp) {
g_authenticationCallback.callback.IOCapabilityRsp(
&addr, eventParam->IOCapability, g_authenticationCallback.context);
}
}GapOnIOCapabilityResponseEvent函數處理對端設備的IOCapability信息，remoteAuthReq保存對端設備的認證要求；同時在ClassicAdapter模塊保存對端設備IOCapability能力；這里比較奇怪的是IOCapability和remoteAuthReq分在兩個模塊保存。
void ClassicAdapter::SaveRemoteIoCapability(const BtAddr &addr, uint8_t ioCapability)
{
HILOGI("enter");
RawAddress device = RawAddress::ConvertToString(addr.addr);
std::shared_ptr<ClassicRemoteDevice> remoteDevice = FindRemoteDevice(device);
remoteDevice->SetIoCapability(ioCapability);
}確認處理
void GapOnUserConfirmationRequestEvent(const HciUserConfirmationRequestEventParam *eventParam)
{
/* ... */
int localMitmRequired = GAP_MITM_REQUIRED;
int remoteMitmRequired = GAP_MITM_REQUIRED;
DeviceInfo *devInfo =
ListForEachData(GapGetConnectionInfoBlock()->devicelist, GapFindConnectionDeviceByAddr, (void*)&addr);
if (devInfo != NULL) {
remoteMitmRequired = devInfo->remoteAuthReq & GAP_MITM_REQUIRED;
if (devInfo->actionReq != NULL) {
if (!devInfo->actionReq->needAuthentication && devInfo->actionReq->needUnauthentication) {
localMitmRequired = GAP_MITM_NOT_REQUIRED;
}
} else {
localMitmRequired = remoteMitmRequired;
}
}
if (g_authenticationCallback.callback.userConfirmReq) {
g_authenticationCallback.callback.userConfirmReq(
&addr, eventParam->numericValue,localMitmRequired, remoteMitmRequired, g_authenticationCallback.context);
} else {
GapUserConfirmationRequestNegativeReply(&addr);
}
}GapOnUserConfirmationRequestEvent函數獲取到IO Capability交換流程中保存認證要求，并獲取本設備最近一次連接的認證設置，作為參數傳遞到ClassicAdapter::SSPConfirmReq函數進行處理。
void ClassicAdapter::SSPConfirmReq(const BtAddr &addr, int reqType, int number,
int localMitmRequired, int remoteMitmRequired)
{
HILOGI("reqTyep: %{public}d", reqType);
RawAddress device = RawAddress::ConvertToString(addr.addr);
std::shared_ptr<ClassicRemoteDevice> remoteDevice = FindRemoteDevice(device);
remoteDevice->SetPairConfirmState(PAIR_CONFIRM_STATE_USER_CONFIRM);
remoteDevice->SetPairConfirmType(reqType);
int remoteIo = remoteDevice->GetIoCapability();
if (remoteDevice->GetPairedStatus() == PAIR_CANCELING) {
UserConfirmAutoReply(device, reqType, false);
} else if (CheckAutoReply(remoteIo, localMitmRequired, remoteMitmRequired) == true) {
UserConfirmAutoReply(device, reqType, true);
} else {
reqType = CheckSspConfirmType(remoteIo, reqType);
SendPairConfirmed(device, reqType, number);
}
}ClassicAdapter::SSPConfirmReq函數取出本設備及對端設備的IOCapability，調用CheckAutoReply函數結合認證信息進行最終的綜合判斷：如果是自動配對，則由ClassicAdapter::SSPConfirmReq調用UserConfirmAutoReply直接確認；否則向用戶顯示確認信息，要求用戶確認。
bool ClassicAdapter::CheckAutoReply(int remoteIo, int localMitmRequired, int remoteMitmRequired) const
{
HILOGI("enter");
bool autoReply = false;
int localIo = adapterProperties_.GetIoCapability();
HILOGI("local io capability = %{public}d <==> remote io capability = %{public}d"
"local mitm = %{public}d <==> remote mitm = %{public}d", localIo, remoteIo,
localMitmRequired, remoteMitmRequired);
if (localMitmRequired == GAP_MITM_NOT_REQUIRED && remoteMitmRequired == GAP_MITM_NOT_REQUIRED) {
return true;
}
switch (localIo) {
case GAP_IO_DISPLAYONLY:
autoReply = (remoteIo != GAP_IO_KEYBOARDONLY) ? true : false;
break;
case GAP_IO_KEYBOARDONLY:
autoReply = (remoteIo == GAP_IO_NOINPUTNOOUTPUT) ? true : false;
break;
case GAP_IO_NOINPUTNOOUTPUT:
autoReply = true;
break;
default:
break;
}
return autoReply;
}總結
本文介紹了藍牙協議中SSP認證配對過程及OpenHarmony中相關實現流程，藍牙配對時是否會出現用戶確認提示信息依賴兩端設備能力，同時也依賴業務對安全性的要求；如果業務本身有其它傳輸加密能力，可以指定不認證方式進行連接，避免用戶多次認證導致降低使用體驗，如OpenHarmony軟總線就是采用這種方式建立藍牙連接。
