Здравствуйте.
3 декабря 2014 года Bluetooth SIG официально анонсировала спецификацию bluetooth версии 4.2.
В пресс-релизе указаны 3 главных нововведения:
- увеличение скорости приема-передачи данных;
- возможность подключения к интернету;
- улучшение конфиденциальности и безопасности.
Главный тезис пресс-релиза: версия 4.2 — идеальна для интернета вещей (IoT).
В этой статье я хочу рассказать, как реализованы эти 3 пункта. Кому интересно добро пожаловать.
Все, что описано ниже, относится только к BLE, поехали…
1. Увеличение скорости приема-передачи пользовательских данных.
Самым главным недостатком у BLE была малая скорость передачи данных. Хотя с какой стороны посмотреть, ведь изначально BLE придумывали ради сохранения энергии источника, питающего устройство. А чтобы беречь энергию, надо с перерывами выходить на связь и передавать немного данных. Однако, все равно, весь интернет заполнен возмущениями о малой скорости и вопросами о возможности ее увеличения, а также увеличения размера передаваемых данных.
И вот с появлением версии 4.2, Bluetooth SIG заявил об увеличении скорости передачи в 2,5 раза и размера передаваемого пакета в 10 раз. Как же они этого добились?
Сражу скажу, что эти 2 цифры связаны друг с другом, а именно: скорость увеличилась потому, что увеличился размер передаваемого пакета.
Посмотрим на PDU (protocol data unit) канала данных:
Каждый PDU содержит 16-ти битный заголовок (header). Так вот, этот заголовок в версии 4.2 отличается от заголовка в версии 4.1.
Вот заголовок версии 4.1:
А вот заголовок версии 4.2:
Примечание: RFU (Reserved for Future Use) — поле, обозначенное этой аббревиатурой зарезервировано для будущего использования и заполняется нулями.
Как мы видим, последние 8 бит заголовка отличаются. Поле «Lenght» — это сумма длин полезных данных и поля MIC (Message Integrity Check), находящегося в PDU (если последнее включено).
Если в версии 4.1 поле «Lenght» имеет размер 5 бит, то в версии 4.2 это поле размером 8 бит.
Отсюда несложно вычислить, что поле «Lenght» в версии 4.1 может содержать значения в промежутке от 0 до 31, а в версии 4.2 в промежутке от 0 до 255. Если из максимальных значений вычесть длину поля MIC (4 октета), то получим, что полезных данных может быть 27 и 251 октет для версии 4.1 и 4.2 соответственно. На самом деле максимальное кол-во данных еще меньше, т.к. в полезной нагрузке находятся еще и служебные данные L2CAP (4 октета) и ATT (3 октета), но это мы рассматривать не будем.
Таким образом размер передаваемых пользовательских данных увеличился приблизительно в 10 раз. Что же касается скорости, которая, почему-то, увеличилась на в 10 раз, а всего в 2.5 раза, то тут нельзя говорить о пропорциональном увеличении, потому, что все упирается еще и в гарантированность доставки данных, ведь гарантировать доставку 200 байт немного сложнее чем 20-ти.
2. Возможность подключения к интернету.
Пожалуй, самое интересное нововведение, из-за которого Bluetooth SIG и объявила, что версия 4.2 делает интернет вещей (IoT) лучше именно благодаря этой возможности.
Еще в версии 4.1 в L2CAP появился режим «LE Credit Based Flow Control Mode». Этот режим позволяет управлять потоком данных, используя т.н. схему, основанную на кредите. Особенность схемы в том, что она не использует сигнальные пакеты, для обозначения кол-ва передаваемых данных, а запрашивает у другого устройства кредит на определенный объем данных для передачи, тем самым ускоряя процесс передачи. При этом, принимающая сторона каждый раз при получении фрейма, уменьшает счетчик фреймов, и при достижении последнего фрейма может разорвать соединение.
В списке команд L2CAP появилось 3 новых кода:
— LE Credit Based Connection request – запрос на соединение по схеме кредита;
— LE Credit Based Connection response – ответ на соединение по схеме кредита;
— LE Flow Control Credit – сообщение о возможности получить дополнительные LE-кадры.
В пакете «LE Credit Based Connection request»
есть поле «Initial Credits» длиной в 2 октета, указывающее на кол-во LE-фреймов, которое устройство может отправить на уровне L2CAP.
В ответном пакете «LE Credit Based Connection response»
в том же поле указано кол-во LE-фреймов, которое может отправить другое устройство, а также в поле «Result» указан результат запроса на соединение. Значение 0x0000 говорит об успехе, остальные значения указывают на ошибку. В частности, значение 0x0004 указывает на отказ в соединении из-за отсутствия ресурсов.
Таким образом уже в версии 4.1 появилась возможность передачи большого кол-ва данных на уровне L2CAP.
И вот, практически одновременно с выходом версии 4.2, публикуется:
- сервис: «IP Support Service» (IPSS).
- профиль IPSP (Internet Protocol Support Profile), который определяет поддержку передачи пакетов IPv6 между устройствами, имеющими BLE.
Главным требованием профиля для уровня L2CAP является «LE Credit Based Connection» появившееся в версии 4.1, которое, в свою очередь позволяет передавать пакеты с MTU >= 1280 октетов (надеюсь намек на цифру понятен).
Профиль определяет следующие роли:
— роль маршрутизатора (Router) – используется для устройств, которые могут маршрутизировать IPv6 пакеты;
— роль узла (Node) – используется для устройств, которые могу только принимать или отправлять пакеты IPv6; имеют функцию обнаружения сервисов и имеют сервис IPSS, позволяющий маршрутизаторам обнаруживать данное устройство;
Устройства с ролью маршрутизатора, которым необходимо подключение к другому маршрутизатору могут иметь роль узла.
Как ни странно, но передача пакетов IPv6 не является частью спецификации профиля, и указывается в IETF RFC «Transmission of IPv6 packets over Bluetooth Low Energy». В этом документе опредлен еще один интересный момент, а именно то, что при передаче пакетов IPv6 используется стандарт 6LoWPAN — это стандарт взаимодействия по протоколу IPv6 поверх маломощных беспроводных персональных сетей стандарта IEE 802.15.4.
Посмотрите на рисунок:
В профиле определено, что IPSS, GATT и ATT используются только для обнаружения сервиса, а GAP используется только для обнаружения устройства и установки соединения.
А вот выделенное красным, как раз говорит о том, что передача пакетов не входит в спецификацию профиля. Это позволяет программисту написать свою реализацию передачи пакетов.
3. Улучшение конфиденциальности и безопасности.
Одной из обязанностей менеджера безопасности (Sequrity manager) (SM) является сопряжение двух устройств. В процессе сопряжения создаются ключи, которые затем используются для шифрования связи. Процесс сопряжения состоит из 3-х фаз:
- обмен информацией о способах сопряжения;
- генерация краткосрочных ключей (Short Term Key (STK));
- обмен ключами.
В версии 4.2 2-я фаза разделилась на 2 части:
- генерация краткосрочных ключей (Short Term Key (STK)) под названием «LE legacy pairing»
- генерация долговременных ключей (Long Term Key (LTK)) под названием «LE Secure Connections»
А 1-я фаза добавилась еще одним способом сопряжения: «Numeric Comparison» который работает только со вторым вариантом 2-й фазы: «LE Secure Connections».
В связи с этим в криптографическом тулбоксе менеджера безопасности помимо 3-х существующих функций, появилось еще 5 и эти 5 используются только для обслуживания нового процесса сопряжения «LE Secure Connections». Эти функции генерируют:
- LTK и MacKey;
- подтверждающие переменные;
- переменные проверки аутентификации;
- 6-ти значные числа, используемые для отображения на связываемых устройствах.
Все функции используют алгоритм шифрования AES-CMAC с 128-ми битным ключом.
Так вот, если при сопряжении во 2-й фазе по методу «LE legacy pairing» генерировалось 2 ключа:
- Temporary Key (TK): 128-ми битный временный ключ, используемый для генерации STK;
- Short Term Key (STK): 128-ми битный временный ключ, используемый для шифрования соединениЯ
то по методу «LE Secure Connections» генерируется 1 ключ:
- Long Term Key (LTK): 128-ми битный ключ, используемый для шифрования последующих соединениЙ.
Результатом этого нововведения мы получили:
- предотвращение отслеживания, т.к. теперь за счет «Numeric Comparison» есть возможность контролировать возможность подключения к Вашему устройству.
- улучшение энерго-эффективности, т.к. теперь не требуется дополнительная энергия для повторных генераций ключей при каждом соединении.
- отраслевой стандарт шифрования для обеспечения конфиденциальных данных.
Как это ни странно звучит, но за счет улучшения безопасности мы получили улучшение энерго-эффективности.
4. Есть ли уже возможность пощупать?
Да, есть.
NORDIC Semiconductor выпустил «nRF51 IoT SDK» который включает в себя стек, библиотеки, примеры и API для устройств серии nRF51. Сюда входят:
- чипы nRF51822 и nRF51422;
- nRF51 DK;
- nRF51 Dongle;
- nRF51822 EK.
По ссылке можно загрузить:
- краткое описание;
- архив с описанным SDK;
- архив ядра для Raspberry Pi, включая его исходники.
5. Заключение.
Самым ожидаемым лично для меня конечно было увеличение скорости передачи и размера пакета передаваемых данных.
В первом квартале 2015 года должны появиться первые чипы, поддерживающие версию 4.2, потом будут обновления мобильных платформ и все это позволит добавлять новые возможности в мир интернет вещей.
Спасибо за внимание.
Автор: Lebets_VI
