- збільшення швидкості прийому-передачі даних;
- можливість підключення до інтернету;
- поліпшення конфіденційності та безпеки.
Головна теза прес-релізу: версія 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. Висновок.
Дякуємо за увагу.