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» вказаний результат запиту на з'єднання. Значення 0x0000 говорить про успіх, інші значення вказують на помилку. Зокрема, значення 0x0004 вказує на відмову в з'єднанні через відсутність ресурсів.

Таким чином вже у версії 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, потім будуть оновлення мобільних платформ і все це дозволить додавати нові можливості інтернет світ речей.

Дякую за увагу.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.