Bluetooth v4.2: что же действительно нового и как это работает?
Здравствуйте.
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» указан результат запроса на соединение. Значение 0×0000 говорит об успехе, остальные значения указывают на ошибку. В частности, значение 0×0004 указывает на отказ в соединении из-за отсутствия ресурсов.
Таким образом уже в версии 4.1 появилась возможность передачи большого кол-ва данных на уровне L2CAP.И вот, практически одновременно с выходом версии 4.2, публикуется:
Главным требованием профиля для уровня 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, потом будут обновления мобильных платформ и все это позволит добавлять новые возможности в мир интернет вещей.Спасибо за внимание.
