W jaki sposób rozwiązania kontroli dostępu BLE zapewniają bezpieczeństwo?

Kontrola dostępu BLE staje się coraz popularniejszą alternatywą dla tradycyjnych kluczy i fizycznych identyfikatorów wśród użytkowników indywidualnych i biznesowych. Wygoda korzystania ze smartfona jako bezpiecznego klucza cyfrowego sprawia, że BLE jest atrakcyjnym sposobem kontroli dostępu. Dlatego coraz więcej dostawców włącza rozwiązania kontroli dostępu zbliżeniowego do swoich ofert o wartości dodanej.

Jednak, podobnie jak w przypadku każdej technologii dostępu do obiektów, rosnąca popularność kontroli dostępu BLE rodzi również pytania o bezpieczeństwo. Użytkownicy i firmy naturalnie chcą wiedzieć, w jaki sposób dostawca chroni cyfrowe dane uwierzytelniające. Czy możliwe jest przechwycenie komunikacji i w jaki sposób system zapobiega nieautoryzowanym próbom dostępu.

Urządzenie dostępowe BLE łączy szyfrowane kanały komunikacji, chronione dane uwierzytelniające i mechanizmy weryfikacji na odległość. Gwarantuje użytkownikom wygodę dostępu za pomocą smartfona, przy jednoczesnym zachowaniu wysokiego poziomu ochrony przed nieautoryzowanym użyciem.

W jaki sposób zabezpieczona jest kontrola dostępu BLE?

Tradycyjne klucze fizyczne są podatne na kradzież, utratę lub niewłaściwe użycie. Cyfrowe dane uwierzytelniające wymagają innego podejścia do bezpieczeństwa. Takie podejście chroni zarówno same dane uwierzytelniające, jak i kanał komunikacyjny, który je przesyła.

Dzięki urządzeniu kontroli dostępu BLE opartemu na technologii Aipix, tokeny BLE są przesyłane bezpiecznymi kanałami komunikacyjnymi z wykorzystaniem algorytmów kryptograficznych klasy bankowej. Rozwiązanie szyfruje wszystkie wymieniane dane, pomagając zapobiec przechwyceniu, modyfikacji lub nieautoryzowanemu ponownemu wykorzystaniu cyfrowych danych uwierzytelniających.

Użytkownicy mogą skonfigurować preferowaną odległość automatycznego otwierania drzwi, dostosowując ją do swoich potrzeb. System weryfikuje również rzeczywistą odległość między smartfonem a kontrolerem BLE przed udzieleniem dostępu.

Ta dodatkowa walidacja pomaga zmniejszyć ryzyko nieautoryzowanych prób aktywacji spoza dozwolonego obszaru. Gwarantuje również, że dostęp jest udzielony tylko wtedy, gdy autoryzowane urządzenie znajduje się fizycznie blisko punktu dostępu.

W jaki sposób rozwiązanie oparte na BLE zapewnia ochronę przed nieautoryzowanym dostępem? Uzasadnienie siły kryptograficznej schematu umowy o dostępie BLE

Schemat autoryzacji dostępu między aplikacją mobilną a kontrolerem BLE oparty jest na protokole v3. Został on zbudowany na standardowych prymitywach kryptograficznych (AES-128, SHA-256, HMAC-SHA256) i ich poprawnej kombinacji. Przeprowadzona analiza nie ujawniła żadnych błędów projektowych, które pozwoliłyby atakującemu kontrolującemu kanał radiowy na otwarcie kontrolera bez posiadania ważnego klucza.

System pozostanie bezpieczny dokładnie tak długo, jak bezpieczne będą algorytmy AES-128 i SHA-256. Są to standardy kryptograficzne z wieloletnią historią publicznej analizy, dla których nie są znane żadne ataki praktycznie skuteczniejsze niż dokładne przeszukiwanie.

Kluczowe wskaźniki ilościowe:

Wyróżniające zalety programu:

• proces weryfikacji jest w pełni autonomiczny — kontroler działa bez połączenia z serwerem;
• aplikacja zasadniczo nie jest w stanie modyfikować własnych praw dostępu ani okresu ważności klucza;
• skompromitowanie telefonu nie daje atakującemu żadnych uprawnień poza tymi, które użytkownik już posiadał, i staje się automatycznie nieskuteczne po wygaśnięciu klucza;
• nie ma kryptografii robionej na zamówienie.

Co to jest model zagrożenia dla rozwiązań kontroli dostępu BLE?

Przyjęto następujący model atakującego:

• atakujący ma pełną kontrolę nad kanałem radiowym: może biernie podsłuchiwać, aktywnie zakłócać, przekazywać wiadomości i fałszować pakiety reklamowe BLE;
• może podawać się za kontrolera telefonu i za telefon za kontrolera;
• może wielokrotnie inicjować wymiany, wybierając dowolne wartości żądań (selekcja adaptacyjna);
• dysponuje zasobami obliczeniowymi w granicach uznawanych za realistyczne w praktyce (warunkowo do 2⁸⁰ operacji);
• nie posiada klucza głównego i nie ma fizycznego dostępu do wewnętrznych komponentów kontrolera.

Za cele atakującego uważa się:

• otwarcie kontrolera bez ważnego klucza;
• otwieranie kluczem, którego termin ważności minął lub którego okres ważności jeszcze się nie rozpoczął;
• eskalacja uprawnień;
• przeniesienie ważnego klucza do innego kontrolera;
• odzyskiwanie klucza głównego, klucza klienta lub zawartości tokena.

Co Konsoliduje oświadczenie o sile bezpieczeństwa dostępu BLE?

Atakujący nie może odblokować kontrolera bez uzyskania prawidłowej pary "zaszyfrowany klucz token–klient" dla określonego kontrolera i odpowiedniego okresu. Prawdopodobieństwo sukcesu pozostaje Nie wyższe niż n * 2⁻⁶⁴, gdzie n oznacza liczbę prób wykonanych przez atakującego

Odzyskanie klucza głównego, klucza klienta lub zawartości tokena dostępu z danych wymiany radiowej wymagałoby złamania zabezpieczeń AES-128, SHA-256 lub HMAC-SHA256.

Na czym opiera się siła zabezpieczeń dostępu BLE NA?

Klucz klienta jest etykietą uwierzytelniającą samego tokena

Rozwiązanie architektoniczne, z którego wynika większość właściwości tego schematu, polega na tym, że oblicza on klucz klienta jako znacznik uwierzytelniania (HMAC) zawartości tokena dostępu przy użyciu klucza głównego.

Ta sama wartość służy zarówno jako kod uwierzytelniający, chroniący integralność tokena, jak i jako sekret, za pomocą którego aplikacja potwierdza swoje prawa dostępu. Prowadzi to do następujących właściwości:

Integralność tokena jest weryfikowana bez dodatkowych kosztów. Aplikacja przesyła zaszyfrowany token w postaci jawnej. Zmiana nawet jednego bitu tokena po odszyfrowaniu powoduje zmianę zawartości, a co za tym idzie, zmianę klucza klienta i niezgodność podpisu. Nie wymaga to oddzielnej kontroli integralności tokena, która jest już przeprowadzana w ramach weryfikacji podpisu odpowiedzi. Eliminuje to całą klasę błędów implementacyjnych związanych z kolejnością operacji weryfikacji kodu uwierzytelniającego i deszyfrowania.

Aplikacja nie może modyfikować własnych uprawnień. Zawartość tokena jest nieznana aplikacji; otrzymuje ona jedynie tekst zaszyfrowany i klucz klienta. Aby ustawić flagę administratora lub przedłużyć okres ważności, konieczne byłoby utworzenie nowej zawartości tokena i obliczenie dla niej znacznika uwierzytelniającego przy użyciu klucza głównego, który nie jest dostępny dla aplikacji. Próba siłowego złamania tekstu zaszyfrowanego jest bezużyteczna: odpowiadający mu klucz klienta pozostałby nieznany. Eskalacja uprawnień sprowadza się do złamania HMAC-SHA256.

Niemożność odpowiedzi Fałszerstwo

Atakujący, który nie zna klucza klienta, musi dostarczyć prawidłowy podpis dla żądania wygenerowanego przez kontroler i nieznanego z góry.

Gdyby istniał algorytm, który mógłby wytworzyć takie fałszerstwo z prawdopodobieństwem znacznie wyższym niż 2⁻⁶⁴, Hakerzy mogliby wykorzystać go do skonstruowania albo wyróżnika dla HMAC-SHA256 jako funkcji pseudolosowej, albo algorytmu znajdowania częściowych preobrazów algorytmu SHA-256. W przypadku obu prymitywów badacze nie odkryli, aby ataki były skuteczniejsze niż metoda brute force. Żaden ze znanych ataków na HMAC-SHA256 nie wykorzystuje jego wewnętrznej struktury do odzyskiwania klucza szybciej niż wyszukiwanie wyczerpujące. Algorytm SHA-256 pozostaje również odporny na ataki preobrazowe: istniejące wyniki dotyczą tylko wersji o znacznie zredukowanej liczbie rund i nie mają zastosowania do całego algorytmu.

Ważne jest, aby klucz klienta był wynikiem algorytmu HMAC-SHA256, co oznacza, że składa się z równomiernie rozłożonych 256 bitów, a nie jest hasłem lub wartością z ograniczonego alfabetu. Ataki słownikowe i strukturalne są zatem z założenia niemożliwe.

Ochrona przed powtórzeniem

Sygnatura obejmuje całą odpowiedź wraz z żądaniem, a żądanie zawiera losową 64-bitową wartość generowaną przez kontroler na nowo dla każdej interakcji. Odpowiedź zarejestrowana przez atakującego jest ważna tylko dla pojedynczej wartości tej liczby i dlatego nie może zostać odtworzona.

Wiązanie z określonym kontrolerem

Żądanie zawiera publiczny identyfikator klucza głównego kontrolera, a system uwzględnia ten identyfikator w podpisanych danych. To kryptograficznie wiąże odpowiedź z zamierzonym kluczem: jeśli atakujący przechwyci odpowiedź z jednego kontrolera, inny kontroler z innym identyfikatorem ją odrzuci.

Podpis może zostać zweryfikowany wyłącznie przez stronę posiadającą klucz główny, ponieważ system generuje klucz klienta z zaszyfrowanego tokena przy użyciu tego klucza głównego.

Oddzielenie podpisu i klucza sesji

Podpis oblicza się na podstawie pierwszych 8 bajtów skrótu wartości pośredniej.

Gdyby podpis był prefiksem samej wartości pośredniej, opublikowanie podpisu ujawniłoby 64 bity przyszłego klucza sesji, zmniejszając jego bezpieczeństwo i tworząc połączenie między danymi publicznymi a tajnymi. Hashowanie pośrednie zapewnia kryptograficzną separację domen: odzyskanie tajnego klucza sesji z podpisu jest niemożliwe bez znalezienia częściowego preobrazu algorytmu SHA-256.

W rezultacie na podstawie pojedynczego obliczenia HMAC schemat wyprowadza dwie niezależne pod względem bezpieczeństwa wartości: publiczny dowód własności klucza i pełny 256-bitowy tajny klucz sesji.

Lokalizacja konsekwencji naruszenia bezpieczeństwa aplikacji

Załóżmy, że atakujący wydobył z telefonu parę “zaszyfrowany token – klucz klienta”. Atakujący uzyskuje możliwość otwarcia tego samego kontrolera z tymi samymi uprawnieniami i w tym samym czasie, co prawowity właściciel.

Wyciek danych wpływa wyłącznie na uprawnienia przyznane już użytkownikowi, którego dane dotyczą, a dostęp zostaje automatycznie zakończony po wygaśnięciu klucza.

Odporność na zapytania adaptacyjne

Podczas połączenia odwrotnego telefon odpowiada na żądania z dowolnego podłączonego urządzenia, natomiast podczas połączenia bezpośredniego atakujący może podszyć się pod kontroler. W obu przypadkach atakujący może wysyłać wybrane żądania i zbierać odpowiadające im odpowiedzi.

Nie daje to jednak atakującemu żadnej przewagi. Każda odpowiedź ujawnia 64 bity wyniku funkcji dla wybranego wejścia. Odzyskanie 256-bitowego klucza klienta na podstawie takich obserwacji jest standardowym problemem odzyskiwania klucza dla funkcji pseudolosowej w atakach z wybranym wejściem, a algorytm HMAC-SHA256 nie oferuje lepszego rozwiązania niż wyszukiwanie wyczerpujące.

Nawet dwie obserwacje wystarczają do zidentyfikowania kandydata i są jednoznacznie określone, ale weryfikacja każdego kandydata wymaga obliczeń HMAC, a liczba możliwych kandydatów pozostaje na poziomie 2²⁵⁶.

Brak niestandardowej kryptografii

Schemat ten opiera się wyłącznie na algorytmach AES-128, SHA-256 i HMAC-SHA256 — prymitywach zgodnych ze standardami FIPS 197, FIPS 180-4 i RFC 2104, mających wieloletnią historię publicznej kryptoanalizy i dokładnie przetestowanych implementacji.

To znacząca zaleta, która zasługuje na osobne podkreślenie. Zdecydowana większość praktycznych awarii w systemach kontroli dostępu nie jest spowodowana słabościami prymitywów kryptograficznych, lecz słabymi lub podatnymi na ataki metodami ich łączenia i stosowania.

Oceny ilościowe

Analiza ilościowa pokazuje, że wszystkie krytyczne parametry bezpieczeństwa zapewniają znaczną przewagę nad praktycznymi progami ataku. Klucz główny zapewnia bezpieczeństwo na poziomie około 190 bitów, uzyskany klucz szyfrujący zachowuje około 127 bitów entropii, fałszerstwo online wymaga niewykonalnego nakładu obliczeniowego, a prawdopodobieństwo ponownego użycia liczb losowych pozostaje znikome nawet przy dużej liczbie sesji.

Podsumowanie siły kryptograficznej umowy o dostępie BLE

Kryptograficzne jądro systemu jest prawidłowo zaprojektowane, a jego bezpieczeństwo jest zapewnione dzięki spójnemu połączeniu następujących czynników:

• wyłączne stosowanie standardowych, dobrze przebadanych prymitywów kryptograficznych, bez stosowania niestandardowej kryptografii w krytycznych komponentach;
• połączenie klucza klienta ze znacznikiem uwierzytelniania tokena, co zapewnia integralność tokena “za darmo”, gwarantuje fundamentalną niemożność eskalacji uprawnień i umożliwia w pełni autonomiczną weryfikację bezstanową po stronie kontrolera;
• oddzielenie podpisu i klucza sesji poprzez haszowanie, co pozwala na uzyskanie dwóch niezależnych, bezpiecznych wartości w wyniku jednego obliczenia;
• hierarchia kluczy ograniczająca konsekwencje naruszenia bezpieczeństwa klienta dokładnie do zakresu uprawnień dostępnych dla danego klienta;
• starannie dobrane parametry z uzasadnionym marginesem bezpieczeństwa: ≈ 190 bitów dla klucza głównego, ≈ 127 bitów dla uzyskanego klucza szyfrującego i 2⁻⁶⁴ prawdopodobieństwa fałszerstwa na próbę, gdy atakujący nie ma możliwości przeprowadzenia ataków siłowych offline.

Urządzenie BLE jako podstawa bezkontaktowego, bezpiecznego dostępu i możliwości rynkowe

Nowoczesna kontrola dostępu nie polega już tylko na otwieraniu drzwi. Chodzi o ochronę tożsamości, zabezpieczanie kanałów komunikacji i tworzenie niezawodnej infrastruktury cyfrowej.

Kontrola dostępu BLE oparta na technologii Aipix łączy w sobie szyfrowaną transmisję danych, chronione dane uwierzytelniające, weryfikację bliskości i projektowanie uwzględniające prywatność, zapewniając bezpieczną alternatywę dla tradycyjnych metod dostępu.

Łącząc bezpieczeństwo, wygodę i wymogi regulacyjne, technologia BLE pomaga operatorom telekomunikacyjnym, dostawcom usług i organizacjom budować skalowalne, inteligentne rozwiązania dostępowe bez narażania cyberbezpieczeństwa. Jednocześnie kontroler BLE to tylko jedna z dostępnych opcji sprzętowych do organizacji punktów dostępowych. Decyzja o jego wdrożeniu zależy od wymagań i specyfiki projektu klienta.

Gotowy na otwarcie nowych możliwości dla Twojej firmy telekomunikacyjnej dzięki bezpiecznej, bezdotykowej kontroli dostępu BLE i nie tylko? Skontaktuj się z nami, a wspólnie omówimy rozwiązania inteligentnej kontroli dostępu.