BLE

  • 11 Odpowiedzi
  • 2820 Wyświetleń

0 użytkowników i 1 Gość przegląda ten wątek.

BLE
« dnia: 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.
« Ostatnia zmiana: Styczeń 21, 2016, 08:50:00 am wysłana przez Pawel2420 »
*

Offline Enc

  • ** 93
  • 3
    • Zobacz profil
  • Nazwa i wersja ID: OpenHab
Odp: BLE
« Odpowiedź #1 dnia: Styczeń 21, 2016, 09:02:15 am »
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ę.
... vendor agnostic ...
Odp: BLE
« Odpowiedź #2 dnia: Styczeń 21, 2016, 10:25:48 am »
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".
« Ostatnia zmiana: Styczeń 21, 2016, 10:28:43 am wysłana przez Pawel2420 »
*

Offline Enc

  • ** 93
  • 3
    • Zobacz profil
  • Nazwa i wersja ID: OpenHab
Odp: BLE
« Odpowiedź #3 dnia: Styczeń 21, 2016, 01:15:42 pm »
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ę.
« Ostatnia zmiana: Styczeń 21, 2016, 01:43:05 pm wysłana przez homelogic »
... vendor agnostic ...
Odp: BLE
« Odpowiedź #4 dnia: Styczeń 21, 2016, 06:47:31 pm »
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.
« Ostatnia zmiana: Styczeń 21, 2016, 07:08:35 pm wysłana przez Pawel2420 »
*

Offline Enc

  • ** 93
  • 3
    • Zobacz profil
  • Nazwa i wersja ID: OpenHab
Odp: BLE
« Odpowiedź #5 dnia: Styczeń 21, 2016, 07:27:08 pm »
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:
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.
« Ostatnia zmiana: Styczeń 21, 2016, 07:33:05 pm wysłana przez Enc »
... vendor agnostic ...
Odp: BLE
« Odpowiedź #6 dnia: Styczeń 21, 2016, 08:13:00 pm »
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.
*

Offline Enc

  • ** 93
  • 3
    • Zobacz profil
  • Nazwa i wersja ID: OpenHab
Odp: BLE
« Odpowiedź #7 dnia: Styczeń 21, 2016, 08:32:46 pm »
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.
... vendor agnostic ...
Odp: BLE
« Odpowiedź #8 dnia: Styczeń 21, 2016, 09:16:14 pm »
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.
*

Offline Enc

  • ** 93
  • 3
    • Zobacz profil
  • Nazwa i wersja ID: OpenHab
Odp: BLE
« Odpowiedź #9 dnia: Sierpień 03, 2016, 11:23:45 pm »
... vendor agnostic ...
*

Offline Enc

  • ** 93
  • 3
    • Zobacz profil
  • Nazwa i wersja ID: OpenHab
Odp: BLE
« Odpowiedź #10 dnia: Wrzesień 23, 2016, 09:42:57 pm »
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.
... vendor agnostic ...
Odp: BLE
« Odpowiedź #11 dnia: Wrzesień 24, 2016, 06:19:41 am »
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.
« Ostatnia zmiana: Wrzesień 24, 2016, 06:28:15 am wysłana przez Pawel2420 »