Forum użytkowników automatyki budynkowej
Inne => Inne => Wątek zaczęty przez: Pawel2420 w Styczeń 21, 2016, 08:45:08 am
-
Do automatycznego otwierania bram, furtek itp. wygodniejsze jest coś innego. W smartfonach z systemem Win 10 i chyba Android 5 można włączyć w tle tryb rozgłaszania BLE. W praktyce nie wpływa to na szybsze zużycie baterii. Mając telefon w kieszeni wystarczy zbliżyć się np. do furtki na określoną odległość i zamek się automatycznie otwiera.
Odwrotny tryb czyli skanowanie w tle też jest możliwe ale to już powoduje trochę szybsze rozładowywanie baterii.
-
Jak wygląda kwestia bezpieczeństwa w BLE? Czy można łatwo podszyć się pod telefon?
Pewne rzeczy można tym zautomatyzować i będzie to bardzo wygodne, ale tak usługi jak dostęp plus np. obsługa centrali alarmowej są zbyt krytyczne i mam obawy co do upraszczania ich w tą stronę.
-
Stosuje się 4 rozwiązania rozwiązania.
1. Telefon wysyła stały identyfikator UUID. Podszycie się pod telefon jest stosunkowo proste. W przypadku np. otwierania furtki na osiedlu wyższy poziom zabezpieczeń nie jest potrzebny.
2. Telefon nadaje unikalny identyfikator, czas i podpis cyfrowy. Rolę tego zmieniającego się czasu może pełnić też adres MAC. W przypadku BLE może być tzw. random. Jest to mniej więcej taki poziom zabezpieczeń jak w pilotach do samochodu ze zmiennym kodem.
3. Pełna dwukierunkowa autoryzacja. Jedno z urządzeń wysyła losowy kod. Drugie szyfruje go algorytmem AES128 i odsyła. Jeśli odpowiedź jest poprawna to zamek jest otwierany. Jest to już bardzo wysoki stopień bezpieczeństwa.
4. Jak w p.4 ale w zamiast telefonu stosowany jest mały tag ze specjalnym układem kryptograficznym. Zabezpiecza to przed odczytaniem kodu nawet w przypadku fizycznego dostępu do urządzenia i zaangażowania "bardzo dużych środków".
-
Czyli od 3 w górę jest ok. Możesz podać jakieś przykłady takiej implementacji?
Znalazłem analizę BLE pod kątem bezpieczeństwa - https://www.usenix.org/conference/woot13/workshop-program/presentation/ryan
Pytanie czy od 2013 coś się zmieniło? Bo z tej prezentacji wynika, że bez dodania warstwy bezpieczeństwa na poziomie aplikacji BLE jest generalnie słabe - gdyż w sposób pasywny (podsłuch) można złamać transmisję.
-
Możesz podać jakieś przykłady takiej implementacji?
Te dwa urządzenia działają dokładnie tak jak opisałem to w p.3:
https://inode.pl/iNode-Control-ID-RFID-System-p31
https://inode.pl/iNode-Control-Point-p30
W przypadku p.4 różnica polega jedynie użyciu układu kryptograficznego zamiast programowej implementacji AES. Taki układ jest specjalne tak zrobiony aby żadną znaną metodą (szlifowanie, trawienie, naświetlanie itp.) nie udało się z niego wyciągnąć wpisanego klucza.
sposób pasywny (podsłuch) można złamać transmisję
Przyjmuje się, że na podstawie zaszyfrowanych danych przy pomocy AES128 znalezienie klucza wymaga zaangażowania bardzo znacznych środków (na poziomie państwa).
Pytanie czy od 2013 coś się zmieniło?
Standard BLE przewiduje szyfrowanie połączenia na najniższym poziomie i operację podobną do parowania. Wydaje mi się jednak, że żaden smartfon lub tablet nie potrafi skorzystać z tej możliwości. Producenci urządzeń i twórcy apliakacji realizują więc to we własnym zakresie. Tak więc rozpatrując sprawy bezpieczeństwa wyłącznie na najniższym poziomie to należy uznać BLE jest rzeczywiście dość łatwy do podsłuchania.
-
Przyjmuje się, że na podstawie zaszyfrowanych danych przy pomocy AES128 znalezienie klucza wymaga zaangażowania bardzo znacznych środków (na poziomie państwa).
Ze slajdów wynika że atak nie jest prowadzony na zaszyfrowaną już transmisję, tylko na wymianę kluczy przed rozpoczęciem właściwej transmisji. Z kolei negocjację klucza w prosty sposób wymusza się przez proste zagłuszanie transmisji. Mając klucze sesyjne nie trzeba atakować AES-a - transmisję odszyfrowujemy w czasie rzeczywistym bo mamy klucze sesyjne.
W projekcie zastosowano:
- https://github.com/greatscottgadgets/ubertooth/ - Ubertooth ships with a capable BLE (Bluetooth Smart)
- http://lacklustre.net/projects/crackle/ - crackle cracks Bluetooth Smart (BLE) encryption
I najważniejsza uwaga - Some vendors implement their own security on top of GATT
Pytanie czy w iNode przeprowadzana jest wymiana dodatkowych kluczy (parowanie) urządzeń przed codziennym użycie i to tym kluczem na warstwie aplikacji wykonywane jest szyfrowanie losowej wiadomości? Szyfrowanie sesji BLE pomijam jako niewiarygodne.
-
Pytanie czy w iNode przeprowadzana jest wymiana dodatkowych kluczy (parowanie) urządzeń przed codziennym użycie i to tym kluczem na warstwie aplikacji wykonywane jest szyfrowanie losowej wiadomości? Szyfrowanie sesji BLE pomijam jako niewiarygodne.
To są dość proste urządzenia a nie zaawansowany system dostępu do skarbca w banku. Autoryzacja przebiega dokładnie tak jak opisałem w p.3. Klucz jest stały więc w czasie normalnej pracy nie jest przesyłany . Jedynie w momencie wpisywania ustawień do każdego z urządzeń potencjalnie można go podsłuchać. Jak ktoś ma obawy o bezpieczeństwo to tą operację trzeba zrobić w jakimś odludnym miejscu.
Tak jak już napisałem wyższy stopień zabezpieczeń uzyskuje się w rozwiązaniu z p.4. BLE zapewnia jedynie bezprzewodową komunikację z układem kryptograficznym. Sposób jego wykorzystania pozostawia się programiście aplikacji w smartfonie/tablecie/PC. Te układy mają dość wyrafinowane metody przesyłania/wpisywania klucza. Moim zdaniem trzeba mieć sporą wiedzę aby zrozumieć jak to działa w praktyce.
-
Jak ktoś ma obawy o bezpieczeństwo to tą operację trzeba zrobić w jakimś odludnym miejscu.
Wystarczy w klatce Faradaya :)
Natomiast na podstawie tego opisu wnioskuję że spełnia wymóg osobnej wymiany kluczy - czyli nawet do furtki wystarczy i można potraktować je jako tożsame z kluczem do drzwi - nie można go pasywnie podsłuchać lub skopiować, można go podrobić ale trzeba oryginał mieć w swoich rękach.
-
Natomiast na podstawie tego opisu wnioskuję że spełnia wymóg osobnej wymiany kluczy - czyli nawet do furtki wystarczy i można potraktować je jako tożsame z kluczem do drzwi - nie można go pasywnie podsłuchać lub skopiować, można go podrobić ale trzeba oryginał mieć w swoich rękach.
Dokładnie tak.
Do furtki lepsze będzie rozwiązanie z p.2. Nie wymaga ono nawiązywania połączenia. Czasami może się nie udać tego zrobić za pierwszym razem. Ktoś może np. się na chwilę odwrócić i zasłonić ciałem smartfon/identyfikator. Przedłuża to całą procedurę. Idąc szybko dojdzie się do furtki zanim się ona otworzy. Rozwiązanie z p.2 jest co prawda mniej bezpieczne ale moim zdaniem będzie działało z większej odległości, pewniej i szybciej.
-
Warto przeczytać jeśli stosuje się BLE:
https://zaufanatrzeciastrona.pl/post/wdrozenia-bluetooth-low-energy-jako-kopalnia-ciekawych-podatnosci/
-
Wygląda, że to kolejna faza rozwoju BLE/Bluetooth - Web Bluetooth
https://webbluetoothcg.github.io/web-bluetooth/
http://hackaday.com/2016/09/23/web-bluetooth-the-new-hotness-and-its-dangers/
W dużym uproszczeniu strony WWW (póki co w Chrome) będą mogły sięgać do urządzeń bluetooth.
-
Ta funkcjonalność dostępna jest już od pewnego czasu. Niestety domyślnie jest wyłączona. Użytkownik musi wejść w ustawienia i ją włączyć.
Obecnie pisanie aplikacji multisystemowych uruchamianych w przeglądarce staje się coraz bardziej popularne. Google dodając takie możliwości do Chrome wchodzi tylnymi drzwiami na rynek programów dla iOS i Windows. Nie trzeba mieć płatnego konta developera i specjalnych narzędzi a aplikacje mogą być w bardzo prosty sposób dystrybuowane z pominięciem oficjalnych kanałów.