Как формируется LTK в соединениях Bluetooth с низким энергопотреблением?

Question

Я работаю над тестированием BLE-соединения между Android и датчиком, и у меня возникают проблемы при расшифровке файлов Wireshark .pcap, потому что я не очень уверен, как формируется LTK.

Есть скриншот с пакетами [Encryption_Req] и [Encryption_Rsp] о том, что я получаю, используя Texas Instrument Dongle со сниффером.

Encryption_Req & Encryption_Rsp

Я думаю, что LTK формируется в соответствии с [SKDm & SKDs] или [SKDs & SKDm].

Это означает: BE952D3D760331A834CC6A4274417E48 (SKDm -> SKDs)

Или: A834CC6A4274417E48BE952D3D760331 (SKDs -> SKDm)

Я не уверен, что это правильно, или я что-то упустил.

Answer 1

LTK - это долгосрочный ключ, хранящийся в устройстве, который обменивается после соединения. При сопряжении Legacy подчиненное устройство просто выбирает случайный LTK и отправляет его мастеру. В LE Безопасных Соединениях LTK получен из обмена Дифи Хеллмана.

Пакеты LL_ENC_REQ и LL_ENC_RSP содержат "диверсификаторы сеансовых ключей", а не LTK (так как это может привести к разрушению защиты, если ключ был отправлен открытым текстом до включения шифрования). Чтобы сделать каждое новое соединение безопасным, новый ключ сеанса используется для каждого соединения. Чтобы создать этот ключ сеанса, каждое устройство генерирует случайные данные размером 8+4 байта. Значения SKDm и SKD объединяются в 16-байтовый SKD. Ключ сеанса генерируется AES-шифрованием LTK в качестве значения и SKD в качестве ключа. Обратите внимание, что после объединения SKDm и SKD полностью измените все целые 16 байтов, прежде чем вводить их в стандартную функцию AES, поскольку в Bluetooth используется порядок с прямым порядком байтов, а в стандарте AES используется порядок с прямым порядком байтов.

Так что 487E4174426ACC34A83103763D2D95BE - это ваш SKD в формате, ожидаемом всеми библиотеками AES.

Поля Rand и EDIV в LL_ENC_REQ отправляются ведомому устройству в качестве идентификатора ключа, чтобы он мог искать LTK в своей базе данных.

Значение IVm и IV следует объединить, чтобы получить IV (не обратное). Этот IV используется как часть одноразового номера в шифровании AES-CCM. См. Спецификацию ядра Bluetooth 5.0, том 6, часть E, глава 2.1.