Bluetooth Low Energy 4.2 przynosi większe bezpieczeństwo komunikacji
| Prezentacje firmowe KomunikacjaOchrona transmitowanych informacji i danych jest ważna w przypadku każdego urządzenia bezprzewodowego, od akcesoriów sportowych, przez urządzenia medyczne, po terminale płatnicze. Mechanizmy prywatności uniemożliwiają korzystanie z urządzeń niezaufanych, a bezpieczna komunikacja zapewnia integralność transmisji, bezpieczne przechowywanie danych oraz uniemożliwia podsłuchiwanie przekazywanych informacji. W wersji 4.2 standardu Bluetooth Low Energy (BLE) pojawiły się nowe funkcje zwiększające prywatność i bezpieczeństwo w potencjalnie zagrożonych obszarach istniejących we wcześniejszych wersjach BLE, a także nastąpiła dalsza poprawa efektywności energetycznej.
Prywatność
Zapewnienie prywatności urządzeń wykorzystujących BLE oparte jest na procesie wymiany między uczestnikami komunikacji tajnego kodu o nazwie Identity Resolving Key (IRK) na podstawie którego generowany i dekodowany jest przypadkowy adres znany jako Resolvable Private Address (RPA). Jedynie, gdy urządzenie dysponuje IRK może wyszukiwać urządzenia BLE znajdujące się w pobliżu i komunikować się z drugim urządzeniem BLE poprzez kanał advertising.
IRK dzielone pomiędzy urządzeniami w czasie parowania, są przechowywane w pamięci wewnętrznej urządzenia podczas łączenia na liście zwanej Resolving List. Zatem tylko urządzenia, które zostały połączone wcześniej w pary mogą zdekodować prywatny adres urządzenia po drugiej stronie łącza (peer).
W Bluetooth 4.1 lista Resolving List jest obsługiwana przez hosta, który też zajmuje się dekodowaniem adresów. Działanie to wymaga jego aktywności za każdym razem, gdy zostanie odebrany pakiet rozgłoszeniowy z RPA. W Bluetooth 4.2 Resolving List jest obsługiwana przez kontroler, który dekoduje prywatne adresy urządzeń i nie ma potrzeby wybudzania hosta ze stanu uśpienia do obsługi tego zadania.
Obniża to pobór mocy, nawet jeśli funkcjonalności sterownika i hosta są zrealizowane na bazie jednego i tego samego procesora. Wynika to z tego, że narzut na komunikację między poszczególnymi warstwami protokołu jest w tym przypadku mniejszy i procesor realizuje zadanie dekodowania adresów przy takim podziale w krótszym czasie.
Adres RPA może być także zmieniany w trakcie działania, co jeszcze bardziej utrudnia śledzenie urządzeń. W Bluetooth 4.1 zmiana adresu następowała co 15 minut, niemniej w pewnym stopniu ograniczało to użyteczność komunikacji poprzez wpływ na czas nawiązywania łączności i tym samym też zwiększało to pobór mocy. Co więcej funkcje takie jak Directed Connectable Advertisement (DCA) odpowiadające za filtrowanie urządzeń nie mogły być wykorzystane w tej wersji standardu.
Bluetooth 4.2 pozwala na ustawienie okresu zmiany RPA od 1 s do 11,5 h, obsługuje DCA i realizuje dekodowanie adresów w warstwie Link Layer, co przyspiesza nawiązywanie łączności i sprzyja niskiemu poborowi mocy.
Pasywne podsłuchiwanie
Aby chronić komunikację przed nieuprawnionym dostępem, systemy komunikacji bezprzewodowej muszą zawierać mechanizmy obrony przez pasywnym podsłuchiwaniem przez trzecie urządzenie (rys. 1) oraz atakiem typu MITM (man-in-the-middle).
Podstawową metodą ochrony danych przed podsłuchiwaniem jest ich szyfrowanie za pomocą klucza. W Bluetooth Low Energy 4.2, pojawił się mechanizm o nazwie LE Secure Connections zapewniający szyfrowanie zgodne z wymogami FIPS (Federal Information Processing Standard) za pomocą bazującego na krzywych eliptycznych algorytmu ECDH - Diffiego-Hellmana (Diffie-Hellman Key - DHKey).
Klucz ten jest wykorzystywany w kolejnych krokach do tworzenia dalszych zabezpieczeń i kluczy jak Long Term Keys (LTK), ale co ważne nigdy nie jest on przesyłany drogą radiową. W ten sposób ograniczono znacznie możliwość jego podsłuchania.
Starsze wersje (4.1 i niższe) wykorzystywały łatwe do odgadnięcia tymczasowe klucze po to, aby zaszyfrować pierwszy przesyłany komunikat. Tak zaszyfrowanym łączem były przesyłane dalsze klucze jak Long Term Keys (LTK), ale jasne jest, że potencjalnie były one bardziej narażone na podsłuchanie.
Atak Man-in-the-Middle to rodzaj nadużycia w którym na drodze komunikacji dwóch urządzeń pojawia się trzecie które udaje (emuluje) oba urządzenia także nadawca i odbiorca komunikatów komunikują się z atakującym uważając, że jest on właściwym adresatem (rys. 2). Przed tym atakiem chroni autentykacja, która daje pewność, że urządzenie jest tym, za które się podaje.
W Bluetooth autentykacja polega na parowaniu urządzeń poprzez wymianę klucza. Niemniej zanim dojdzie do wymiany konieczna jest wymiana parametrów parowania wymaganych do autentykacji, np. związanych z możliwością wyświetlenia kodu 6-cyfrowego dla użytkownika potwierdzającego cały proces lub czy możliwe jest wykorzystanie NFC do sparowania i wymiany kluczy. To samo dotyczy przesłania wyniku, a więc czy wpisany kod jest poprawny i na obu urządzeniach wpisano ten sam numer.
W BLE 4.2 mechanizmy te zostały rozszerzone do czterech pozycji:
- porównanie numeryczne - w ramach którego oba urządzenia wyświetlają 6-cyfrowy numer i wymagają jego potwierdzenia na drugim urządzeniu (w 4.1 niedostępne),
- wprowadzenie hasła - użytkownik wprowadza jednakowe hasło na obu urządzeniach lub wpisuje hasło wyświetlone na jednym do drugiego,
- Out of Band (OOB) - w tej wersji do wymiany danych kryptograficznych wykorzystywana jest komunikacja poza kanałem radiowym interfejsu, np. przez NFC.
Parowanie
Parowanie urządzeń to proces w ramach którego następuje wymiana kluczy i następuje autentykacja. W wersji 4.1 proces ten odbywa się dwiema metodami: jako LE Secure Connection (nowość) i LE Legacy Pairing (było już w 4.0). Ta pierwsza opcja przynosi znaczą poprawę bezpieczeństwa komunikacji.
Ogólnie proces parowania podzielony jest na trzy fazy. Podczas pierwszej urządzenia wymieniają parametry parowania, a więc opis jakie informacje mogą być pobierane i wyświetlane oraz jaką drogą jest to realizowane. Lista parametrów została pokazana na rysunku 3.
Jak wspomniano wcześniej LE Secure Connection bazuje na algorytmie ECDH typu P-256, co oznacza, że klucze prywatne mają długość 256 bitów. Generowane są dwa takiej długości klucze z których pierwszy jest prywatny i jest on wysyłany drogą radiową, drugi publiczny generuje urządzenie za pomocą swojego generatora.
Po tym każde z dwu urządzeń wysyła swój wygenerowany klucz publiczny do drugiego. Za pomocą odebranego klucza publicznego i własnego prywatnego tworzony jest kolejny klucz wspólny (shared key). Oznacza to, że podsłuchiwacz może podsłuchać jedynie publiczne klucze wymieniane między urządzeniami. A bez znajomości kluczy prywatnych nie jest w stanie stworzyć klucza wspólnego niezbędnego do odszyfrowania transmisji. Na rysunku 4 pokazano proces, w jaki sposób tworzony jest bezpieczny kanał komunikacyjny w sytuacji, gdy jest on podsłuchiwany.
W fazie drugiej algorytm ECDH generuje parę kluczy z których publiczny jest wymieniany do celów autentykacji urządzeń i ustalenia szyfrowanego połączenia. Autentykacja polega na tym, że urządzenie generuje klucz Long Term Key (LTK) z wykorzystaniem klucza wspólnego (shared key) za pomocą algorytmu ECDH i sprawdza DHKey.
Potem w fazie 3 LTK jest wykorzystywany do zaszyfrowania linku, a następnie wymieniane są klucze zgodnie z ustawieniami flag Initiator Key Distribution/Responder Key Distribution w parametrach parowania.
Podpisywanie danych
Mechanizm podpisywania danych dostępny w BLE jest dodatkową funkcjonalnością poprawiającą bezpieczeństwo. BLE można wykorzystać Connection Signature Resolving Key (CSRK) do podpisywania danych w sytuacji, gdy nie jest wykorzystywane szyfrowanie i tym samym zwiększyć bezpieczeństwo. W takim przypadku generowana jest sygnatura (podpis) i wraz z licznikiem kolejnych podpisów jest ona dołączana do każdego PDU (ramki danych). Nie zabezpiecza to przed podsłuchiwaniem, ale pozwala na autentykację nadajnika i odbiornika.
Jak widać z powyższego opisu Bluetooth Low Energy 4.2 zawiera znacznie więcej funkcji zapewniających bezpieczeństwo zarówno w zakresie zwykłego podsłuchiwania i monitorowania transmisji jak i ataku MITM. Warte odnotowania jest także to, że do szyfrowania jest wykorzystany algorytm oparty na 256-bitowych kluczach.
Sachin Gupta, Richa Dham
Cypress Semiconductor
GLYN Poland
www.glyn.pl