Poker na komórki - analiza bezpieczeństwa

Transkrypt

1 Poker na komórki - analiza bezpieczeństwa Pisanie Bezpiecznych Programów w Javie 08/09 Łukasz Rekucki Krzysztof Płocharz Alan Pilawa Magdalena Michalska Wstęp Aplikacja PokerX w swoim zamyśle dostarcza platformę do gry w pokera posiadaczom telefonów komórkowych. Przeznaczona jest dla osób, które lubią grać w pokera dla rozrywki. Nie jest przeznaczona do hazardu lub użycia w zawodowych turniejach. Twórcy przyszłej aplikacji podzielają przekonanie, że równie ważna jak realizacja podstawowych funkcjonalności jest troska o bezpieczeństwo użytkownika. Charakter aplikacji nasuwa bowiem zasadnicze problemy dotyczące bezpieczeństwa w zakresie: danych związanych z samą rozgrywką (karty własne i przeciwnika, obiekty objęte licytacją) danych niezależnych od rozgrywki, przechowywanych po stronie użytkownika O ile w pierwszym wypadku brak określonych zabezpieczeń może wpłynąć ujemnie na jakość i atrakcyjność rozgrywki, o tyle w drugim wypadku konieczność zachowania tajności informacji jest krytyczna. Na kwestie bezpieczeństwa wpływ ma również wybór modelu aplikacji (rozproszony/scentralizowany) oraz technologii wykorzystanej do transmisji danych (BlueTooth, Wi-Fi, 3G). Każda z podjętych w tym obszarze decyzji rodzi różne pytania związane z bezpieczeństwem, dlatego zasadne jest przeprowadzanie poglądowej analizy każdej z możliwości. Zagadnienia ogólne W czasie gry wymieniane będą dane wprowadzane przez samych użytkowników z klawiatury bądź z pamięci telefonu. Należy nałożyć na takie dane ścisłe warunki uniemożliwiające ataki typu SQLinjection:

2 Nazwa użytkownika - każdy z graczy powinien mieć możliwość podania nazwy która będzie go identyfikować w grze. Nazwa ta będzie przechowywana w bazie przez całą grę lub dłużej w zależności od wybranego modelu, oraz będzie wyświetlana u innych użytkowników. Należy zapewnić aby nie zawierała niedozwolonych znaków, które mogą zmienić informacje wyświetlane na ekranie lub dane w bazie. Licytowane dane prywatne - gra umożliwia wygranie prywatnych danych znajdujących się na telefonie gracza. Gracz wybiera dane które chce wystawić do gry. Pod koniec gry, gracz który wygrał powinien otrzymać wystawione dane. Należy zapewnić, aby dane te nie zostały przekazane niepowołanej osobie (innemu graczowi, bądź osobie spoza gry). Przykładem ataku może być podszycie się pod gracza wygrywającego. Należy też zapewnić bezpieczny sposób rozprowadzania aplikacji (np odpowiednią metodę certyfikacji, podpisywania) tak by nie narażać potencjalnych użytkowników na ryzyko pobrania fałszywej aplikacji, która mogłaby nawet przejąć kontrolę nad ich telefonem i narazić na utratę danych bądź koszty. Model rozproszony Model rozproszony umożliwi przeprowadzenie rozgrywki miedzy użytkownikami bez pośrednictwa centralnego serwera Brak centralnej jednostki przechowującej dane wszystkich odbywających się aktualnie rozgrywek, która byłaby w oczywisty sposób atrakcyjnym celem ataków, to zasadnicza korzyść płynąca z tej decyzji projektowej. Pozwoli to silniejszą granulację danych oraz odizolowanie od siebie pojedynczych rozgrywek. Brak centralnego arbitra zwiększa jednak możliwości "oszustwa" między pojedynczymi użytkownikami biorącymi udział w rozgrywce. Poszczególni gracze nie mogą ufać danym otrzymywanym bezpośrednio od innych graczy, którzy mogą je dowolnie spreparować na swoją korzyść. Należy zatem zapewnić ograniczenie tych możliwości do minimum, co zostało opisane w kolejnych paragrafach, poruszających teoretyczne zagrożenia na kolejnych etapach rozgrywki oraz sposoby przeciwdziałania. Rozdawanie kart Najprostszy nasuwający się algorytm rozdania kart, polegający na tym, że jeden z graczy przyjmuje rolę krupiera i rozdaje innym graczom karty za pomocą serii szyfrowanych transmisji, nie spełnia warunków bezpieczeństwa. Algorytm musi umożliwiać przetasowanie i rozdanie kart w taki sposób, by każdy użytkownik znał tylko swoje karty i nie znał kart swoich przeciwników. Krupier ma jednak potencjalny wgląd w karty wszystkich innych użytkowników. Cykliczna zmiana krupiera poprzez wprowadzenie specjalnego "żetonu" tylko nieznacznie poprawia tę sytuację. Wyraźna staje się potrzeba zaprojektowania nietrywialnego algorytmu, który na równi angażowałby wszystkich graczy w proces mieszania i rozdania kart przy jednoczesnym wykorzystaniu odpowiedniego szyfrowania. Przykład dla dwóch graczy:

3 1. Jaś i Małgosia akceptują pewną wspólna talię kart. 2. Małgosia wybiera klucz szyfrujący M i wykorzystuje go do zaszyfrowania każdej karty w talii. 3. Małgosia tasuje karty. 4. Małgosia przekazuje zaszyfrowaną i przetasowaną talię Jasiowi, który teraz nie wie, która karta jest która. 5. Jaś wybiera klucz szyfrujący J i wykorzystuje go do zaszyfrowania każdej karty w talii, którą otrzymał od Małgosi 6. Jaś tasuje karty 7. Jaś zwraca podwójnie przetasowaną i zaszyfrowaną talię Małgosi 8. Małgosia odszyfrowuje karty za pomocą swojego klucza M, co pozostawia nadal szyfrowanie J i Małgosia nie może znać wartości kart 9. Małgosia wybiera klucz szyfrujący dla każdej karty (M1, M2,..) i szyfruje je jedna po drugiej 10. Małgosia przekazuje talię Jasiowi 11. Jaś odszyfrowuje karty za pomocą swojego klucza J, co pozostawia nadal szyfrowanie (M1, M2,...) i Jaś nie może znać wartości kart 12. Jaś wybiera klucz szyfrujący dla każdej karty (J1, J2,..) i szyfruje je jedna po drugiej 13. Jaś zwraca talię Małgosi 14. Małgosia przekazuje kopię talii pozostałym graczom (w tym wypadku tylko Jasiowi) Algorytm naturalnie rozszerza się dla dowolnej ilości graczy (talię przekazuje się rotacyjnie). W wyniku jego działania każdy gracz ma lokalnie zapisaną potasowaną kopię talii, gdzie każda karta zaszyfrowana jest indywidualnymi kluczami wszystkich innych graczy. Gracze uzgadniają, która część talii przeznaczona jest dla którego gracza, np. w naszym przypadku niech karty 1-2 to karty Małgosi, 3-4 to karty Jasia, 5-9 to flop, turn i river. Małgosia, która chce zobaczyć swoje karty, zgłasza prośbę do Jasia o klucze J1 i J2. Jaś sprawdza, czy Małgosia rzeczywiście ma prawo zobaczyć karty 1-2 i następnie przekazuje jej oba klucze. Małgosia odszyfrowuje karty za pomocą własnych kluczy M1 i M2 oraz kluczy J1 i J2 otrzymanych od Jasia. Zakłada się, że każde przekazanie kluczy szyfrujących oraz innych danych między dwoma graczami samo w sobie jest szyfrowane za pomocą bezpiecznego połączenia SSL/TLS. Pozwoli to na zasadnicze

4 ograniczenie zagrożeń związanych z możliwością "podsłuchu" poufnych danych oraz podszycia się pod drugiego gracza. W celu zachowania losowości kart, oprócz posiłkowania się systemowymi generatorami liczb pseudo-losowych (w przypadku urządzeń przenośnych siła generatora może być ograniczona), można zastosować konwencję spod znaku human computation: w myśl zasady, że człowiek jest o wiele silniejszym generatorem niepewnych zdarzeń niż maszyna, możemy wymusić na użytkowniku, któremu przekazano bieżącą talię, aby np. przełożył tą talię. Szyfrowanie kumulacyjne Aby powyższy algorytm działał poprawnie potrzebna jest funkcja szyfrująca E K (M) spełniająca następujące warunki: 1. E K (E J (M)) = E J (E K (M)) 2. Znając M oraz E K (M) jest obliczeniowo trudne znalezienie K 3. Znając M oraz N jest obliczeniowo trudne znalezienie L oraz K takie, że E L (N) = E K (M) Warunki 2 oraz 3 oznaczają tyle, że funkcja ta jest dobrą funkcją szyfrującą. Warunek 1 oznacza, że wiadomości szyfrowane wielokrotnie można odszyfrować w dowolnej kolejności. Przykładem takiej funkcji jest: E(M) = M K (mod n) D(C) = C L (mod n) nwd(k, φ(n)) = 1 L*K = 1 (mod φ(n)) Gdzie: φ(n) to liczba liczb względnie pierwszych z n i mniejszych od n. E(M) - funkcja szyfrująca D(C) - funkcja deszyfrująca n - uzgodniona duża liczba pierwsza Metoda ta oczywiście spełnia warunek 1. Liczba n-1 nie może mieć małych (< od około ) dzielników, gdyż istnieją algorytmy pozwalające na złamanie szyfru w czasie O(log n + sqr(q)), gdzie q to mały dzielnik n. W szczególności losując liczbę n w sposób jednorodny mamy dużą szansę na trafienie na liczbę nie spełniającą tego warunku. Wylosowanie liczby n postaci n = 2q+1 zmniejsza podatność na atak. Algorytm ten wymaga także dobrego algorytmu losującego zarówno liczby pierwsze, jak i kolejność zaszyfrowanych kart. Do zwiększenia entropii systemu można wykorzystać dane związane z aktywnością użytkownika jak np. odstępy czasu pomiędzy wciśnięciami klawiszy. Wyznaczanie zwycięzcy Gracze przekazują sobie nawzajem klucze, dzięki czemu wszyscy mogą odszyfrować karty i ustalić kto jest zwycięzcą. W razie nieścisłości pomiędzy graczami co do wygranej uznaje się, że ktoś oszukuje i zgłoszone zostaje naruszenie zasad. Licytacja. Przekazanie obiektów licytacji Na tym etapie wchodzą w grę dwie możliwości: Licytowane obiekty krążą po zwycięzcach kolejnych rund w postaci zaszyfrowanej. Klucz szyfrujący posiada pierwotny właściciel obiektu. W momencie odejścia z gry nowy właściciel obiektu wysyła do poprzedniego właściciela prośbę o klucz szyfrujący. Ten stwierdza, czy obiekt faktycznie należy się graczowi i odsyła klucz (transmisja szyfrowana). Zwycięzca

5 obiektu za pomocą klucza odszyfrowuje obiekt i tym samym bierze go w posiadanie. Jeśli gracz twierdzi, że klucz mu się należy, a go nie otrzymał, zgłasza wszystkim naruszenie zasad. Kolejni zwycięzcy przechowują jedynie nagłówki obiektów, bez ich wartości (np. informacja, kogo dotyczy licytowany numer telefonu, ale nie sam numer). Wartości te do momentu zamknięcia rozgrywki, kiedy przegrany jest zobowiązany je wprowadzić, nie istnieją fizycznie po stronie aplikacji właściciela. Wartość zostaje przekazana zwycięzcy za pomocą transmisji szyfrowanej (np. obiekt zaszyfrowany kluczem publicznym zwycięzcy). Ta opcja ma ewidentną przewagę nad poprzednią: nie zostaje lokalny ślad po obiekcie na maszynach tymczasowych graczy, nie trzeba sprawdzać, czy gracz, który odszedł, chce się podłączyć ponownie itp. Model z centralnym arbitrem Model ten zasadniczo różni się od opisanego w poprzednim rozdziale. Przede wszystkim zakłada on istnieje centralnego serwera, który pośredniczy w komunikacji z klientami, steruje rozgrywką i dba o przestrzeganie zasad gry. W związku z powyższym, podstawowym wymaganiem wobec serwera jest możliwość uwierzytelnienia go wobec graczy jako strony zaufanej. Choć podejście takie upraszcza bezpieczne wykonanie wielu czynności tj. tasowanie kart, licytacja, wyznaczenie zwycięzcy czy przekazanie fantów, to jednocześnie staje się ono słabym ogniwem. W szczególności, jeśli arbiter będzie celowo działał na szkodę graczy, to nie istnieje sposób zabezpieczenia się przed tym. Wynika to z faktu, iż jako pośrednik informacji od samego początku komunikacji, jest on w stanie np. podszyć się pod dowolnego innego gracza. Możliwe jest natomiast przynajmniej częściowe zabezpieczenie się przed przypadkowym wyciekiem informacji, podsłuchem czy też atakiem ze strony administratora systemu (przy założeniu braku ingerencji w kod wykonywalny serwera). Zagrożenia związane z komunikacją Istotnym elementem systemu jest zapewnienie poufności przekazywanych między klientami fantów, tj. kontakty, numery kart kredytowych, etc. Dostęp do tych informacji powinien mieć jedynie ich oryginalny właściciel oraz osoba, która wygrała daną informacje podczas rozgrywki. Nie powinni widzieć jej ani inni gracze, ani arbiter. Możliwe sposoby ataku: 1. podsłuchanie komunikacji przez stronę trzecią i odczytanie poufnej informacji, 2. podszycie się pod arbitra (man-in-the-middle), 3. oszukanie arbitra co do tożsamości gracza, 4. złamanie zasad gry i przekonanie arbitra do nieuzasadnionego przekazania wygranej, 5. odczytanie i/lub zapisanie informacji poufnej przez arbitra. Naturalnym sposobem rozwiązania kwestii 1 i 2 jest użycie szyfrowanego połączenia typu SSL/TLS i weryfikacja certyfikatu serwera. Powinno to również utrudnić wykonanie ataku typu 3, gdyż TLS posiada mechanizmy zabezpieczające przed atakami na sam protokół komunikacji (np. TCP). W celu zabezpieczenia się przed atakami typu 4, można rozważyć wprowadzenie oddzielnych certyfikatów dla aplikacji klienckich i umożliwić łącznie się tylko klientom posiadający odpowiedni certyfikat wydany dla konkretnego użytkownika i urządzenia. Utrudniłoby to znacznie dokonanie modyfikacji w kliencie, a więc i próby oszukiwania przez jednego z graczy. Oczywiście sam arbiter powinien być zaimplementowany, tak aby złamanie zasad przez jednego z graczy nie było możliwe. W odróżnieniu od poprzednio wymienionych, ataki ze strony arbitra są nie do wykrycia przez klientów, więc i obrona przed nimi jest utrudniona. Jak już wcześniej wspomnieliśmy, nie da się zabezpieczyć przed celowym działaniem na szkodę użytkownika. Można jedynie zapobiegać niepożądanym działaniom np. ze strony nieuczciwego administratora. W tym celu spełnione powinny być następujące wymagania dotyczące informacji poufnych przekazywanych pomiędzy graczami:

6 informacje nie powinny być dostępne dla arbitra w postaci niezaszyfrowanej, informacje nie powinny być zapisywane lokalnie przez arbitra w jakiejkolwiek postaci, arbiter nie powinien przetwarzać przesyłanych informacji w sposób wykraczający poza operacje konieczne do wysłania do klienta docelowego, natychmiast po przekazaniu informacji powinna ona zostać usunięta z wszelkich źródeł dostępnych dla arbitra, w tym z pamięci operacyjnej, buforów gniazd sieciowych, itp. Jednym ze sposobów realizacji powyższych założeń może być użycie algorytmu szyfrowania z kluczem publicznym. Każdy gracz podczas instalacji swojej aplikacji generowałby klucz prywatny i klucz publiczny (może to być połączone z procesem uwierzytelniania klientów wobec serwera). Na początku rozgrywki wszyscy gracze wymieniają się swoimi kluczami publicznymi. Gdy zajdzie konieczność przesłania poufnej informacji do zwycięzcy, przegrany szyfruję ją używając swojego klucza prywatnego i klucza publicznego zwycięzcy. W ten sposób jedynie zwycięzca jest w stanie odczytać przesłaną informację. Słabym punktem tego podejścia jest atak typu 2 - arbiter może okłamać gracza na temat kluczy publicznych pozostałych graczy. Gracze mogą zwiększyć swoje bezpieczeństwo korzystając z niezależnego, bezpiecznego kanału komunikacji do wcześniejszej wymiany kluczy publicznych. Zagrożenia związane z logiką gry Głównymi wymaganiami w zakresie bezpieczeństwa w takiej grze jak poker są "poufność" i "losowość". W rozdziale tym opisane zostaną zagrożenia związane z tymi wymaganiami oraz możliwe sposoby zabezpieczenia się przed nimi w modelu z centralnym arbitrem. Dla ustalenia uwagi, zakładamy reguły gry odpowiadające wariantowi pokera o nazwie "Texas Hold'em". Poufność Przez poufność rozumiemy, że każdy gracz dzieli z innymi daną informacje tylko jeśli jest to wymagane przez zasady gry lub gracz sam wyraził chęć podzielenia się nią. W wariancie "Texas Hold'em" każdy gracz na początku rozdania otrzymuje dwie unikalne karty z talii pięćdziesięciu dwóch. Są one niewidoczne dla pozostałych graczy. Arbiter powinien gwarantować, iż żadna z aplikacji klienckich nie otrzyma informacji o kartach pozostałych graczy (w postaci zaszyfrowanej lub nie). Informacja o tym, które karty zostały przydzielone graczowi powinna być możliwa do odczytania tylko przez niego samego. Użyty algorytm szyfrowania powinien być wystarczająco silny, aby nie dało się odczytać podsłuchanej informacji co najmniej do czasu zakończenia partii (ok min.). Bardzo często nieujawnienie zawartości swoich kart innym, jest ważnym elementem strategii gracza, więc pożądany jest dłuższy okres ochrony. Dodatkowym elementem w naszej aplikacji, jest możliwość użycia poufnych danych zapisanych na urządzeniu gracza, do licytacji. Wobec tego, naturalnym wymaganiem jest aby aplikacja miała dostęp jedynie do danych explicite wskazanych przez użytkownika. Aplikacja kliencka nie powinna odczytywać innych danych. Nie powinna też udostępniać wskazanej informacji innym graczom lub arbitrowi wcześniej, niż wymagają tego reguły gry. W szczególności samo wstawienie informacji jako fantu w licytacji nie powinno powodować jego odczytania jej treści lub przesłania przez sieć. Losowość Wymaganie losowości można sformułować w następujący sposób: jeśli zasady gry wymagają aby wykonać pewną operację w sposób losowy (tj. ustalić daną wartość w oparciu o rozkład prawdopodobieństwa wynikający z reguł gry), to wszyscy gracze posiadają podobną wiedzę na temat wyniku tej operacji wynikającą tylko i wyłącznie z reguł gry. Większość systemów operacyjnych udostępnia możliwość bezpiecznego generowania ciągów pseudolosowych. Stopień losowości takiego generatora zależy głównie od poziomu entropii w systemie. Częstym sposobem dostarczania entropii jest zbieranie danych z otoczenia o wydarzeniach, które

7 zachodzą w sposób losowy lub trudny do przewidzenia. W przypadku dużych serwerów, gdzie istnieje potrzeba generowania dużej ilości losowych danych, dobrym rozwiązaniem jest użycie sprzętowych generatorów entropii (np. mierzących ilość atomów mało stabilnego pierwiastka, które uległy połowicznemu rozpadowi w przeciągu ostatnich 10ms). W przypadku urządzeń mobilnych, trudno jest zagwarantować jakikolwiek poziom bezpieczeństwa związanego z losowością, głownie ze względu na różnorodność i/lub brak informacji nt. konkretnych implementacji generatorów liczb pseudo-losowych. Przeniesienie funkcjonalności wymagających losowości na poziom arbitra daje większą kontrolę nad poziomem bezpieczeństwa. Nie oznacza to oczywiście eliminacji zagrożeń związanych z wyczerpaniem entropii systemu przez aplikacje. Przechowywanie danych W wersji z centralnym arbitrem na serwerze mogą być przechowywane dane na temat graczy w czasie rozgrywki, ale także pomiędzy rozgrywkami. W przypadku danych przechowywanych pomiędzy rozgrywkami, należy udostępnić sposób identyfikacji gracza np. za pomocą nazwy użytkownika oraz hasła. W takiej sytuacji należy także sprawdzać poprawność danych wprowadzonych przez użytkownika i przekazywanych do bazy danych. W takiej sytuacji serwer może być także narażony na ataki typu brute-force. Aby zapobiec tym atakom można ustalić minimalny czas pomiędzy kolejnymi próbami zalogowania oraz nałożyć wymaganie podania dodatkowych informacji w przypadku zbyt dużej liczby nieudanych logowań. Poufne dane (jak np. hasło) przechowywane na urządzeniu gracza powinny być pamiętane nie dłużej niż jest to konieczne. Gdy nie będą już potrzebne pamięć w której były przechowywane powinna być wyzerowana. W szczególności hasło nie powinno być przechowywane w pamięci urządzenia pomiędzy sesjami gry. Na serwerze będą przechowywane także prywatne dane użytkowników. Można rozważyć dwa scenariusze: 1. dane są zaszyfrowane kluczem gracza - zwiększa to znacząco bezpieczeństwo danych w przypadku ewentualnego włamania do bazy danych, uniemożliwia jednak odzyskanie lub zmianę hasła w przypadku gdy gracz zapomni starego hasła 2. dane są przechowywane w niezaszyfrowanej postaci - umożliwia to zmianę hasła gracza, lecz wymaga dobrego zabezpieczenia dostępu do serwera. Technologie Wi-Fi Ze względu na rosnącą dostępność publicznych hot-spotów i wysoką przepustowość, dostęp do Internetu z urządzeń mobilnych staję się poważną alternatywą wobec takich technologii jak GPRS/ EDGE i UMTS. Poważnym problemem jest jednak bezpieczeństwo przesyłanych danych w sieciach publicznych. Większość istniejących sieci Wi-Fi oparta jest na przestarzałym już standarcie WEP. Główną słabością WEP jest długość klucza (40 lub 104 bitów) oraz zastosowany algorytm szyfrowania strumieniowego RC4. W roku 2001, Flahir-Mantin-Shamir wykazali, że możliwy jest pasywny atak na sieć zabezpieczoną WEP z oczekiwanym czasem sukcesu kilku minut. W przeciągu następnych lat znacznie udoskonalono tą metodę ataku - głównie poprzez znalezienie kolejnych korelacji pomiędzy kluczem, a zaszyfrowanymi danymi. Aby poprawić bezpieczeństwo sieci bezprzewodowych, stworzono standardy WPA i WPA2. Przeznaczone jest głównie dla starego sprzętu obsługującego WEP. Używa on dalej tego samego szyfrowania RC4, ale lepiej chroni meta-dane związane z pakietem takie jak sumy kontrolne, co znacznie utrudnia odgadnięcie klucza. W roku 2008 udało się wykazać, iż WPA jest podatny na ten

8 sam typ ataku ("chop-chop") co WEP, polegający na wstrzykiwaniu pakietów ARP ze zmienionymi sumami kontrolnymi w celu ustalenia aktualnego stanu RC4. Jedynym aktualnie bezpiecznym standardem jest WPA2 - głównie ze względu na zastąpienie szyfru RC4 znacznie lepszym szyfrem AES. Jednakże standard ten nie jest powszechny. Ze względu na powyższe, wymagane staje się użycie dodatkowych zabezpieczeń w komunikacji, tj. tunelowanie IPSec czy TLS. Bluetooth Opis działania i stosowane mechanizmy bezpieczeństwa Zaletami bluetooth pod względem bezpieczeństwa, wynikającymi bezpośrednio z uwarunkowań technologicznych jest mały zasięg(w najczęstszym przypadku około 10m, w ogólności do 100m) - konieczna jest przez to bliskość potencjalnego napastnika. Dodatkowo atak utrudniają częste przeskoki między kanałami i możliwość ukrycia urządzenia. Mechanizmem mającym zwiększyć bezpieczeństwo korzystania z bluetooth jest parowanie urządzeń oparte o kod PIN(4-16 cyfr). Składa się z trzech podstawowych kroków: 1. Utworzenie klucza inicjującego (K init ). 2. Utworzenie klucza połączenia (K ab ). 3. Autentykacja Przy tworzeniu kluczy sa wykorzystywane algorytmy E21, E22, E1 wszystkie oparte o SAFER+, uzależnione od postaci i długości kodu PIN. Tworzenie klucza połączenia Urządzenia z ograniczoną ilością pamięci i bez możliwości wprowadzenia kodu PIN (niektóre urządzenia z bluetooth, jak słuchawka bluetooth maja zafixowany kod PIN) Urządzenia z możliwością wprowadzenia kodu PIN

9 Słabe strony bezpieczeństwa Bluetooth Mały zasięg może być przezwyciężony przez atakującego przy użyciu np anteny panelowej, i możliwe stają się ataki z odległości ponad 1 km (przykładowy eksperyment: trifinite_stuff_lds.html). Użytkownicy często zostawiają standardowy PIN, lub wybierają prosty("1111", "1234"), co skutkuje słabą jakością klucza połączenia. Już w 2005 roku opracowano mechanizm łamania PINu wykorzystujący cechy algorytmu SAFER+ (4 cyfrowy PIN w 0,063 sekundy, a 7 cyfrowy w 76 sekund). Odzyskano również klucz z E0 przy 238 operacjach znając pierwsze 24 bity i posiadając ramek ruchu. Podstawowe ataki i metody obrony BlueJack wysyłanie wiadomości do widocznych urządzeń będących w zasięgu, rozsyłanie SPAMu, wirusów - najskuteczniejsza obrona to nieakceptowanie połączeń. BlueSnarf atak wykorzystuje brak uwierzytelniania przy przesyłaniu obiektów przez profil OPP na niektórych telefonach. Umożliwia uzyskanie książki adresowej, zdjęć czy wpisów z terminarza telefonu ofiary BlueBug umożliwia wykonywanie połączeń, wysyłanie SMSów i korzystanie z Internetu z telefonu ofiary bez jej wiedzy. Bazuje na połączeniu szeregowym profilu SPP obsługującym komendy standardu Hayes (tzw. komendy AT ) BlueSmack atak typu DoS bazujący na wysyłaniu wiadomości protokołu L2CAP z żądaniem odpowiedzi (echo request) BlueBump umożliwia połączenie z telefonem ofiary bez jej wiedzy jeśli wcześniej istniało uwierzytelnione połączenie. Jego działanie polega na manipulacji przechowywaniem klucza połączenia (link key). aplikacja typu Car Whisperer umożliwia korzystanie z bezprzewodowego samochodowego zestawu głośnomówiącego ofiary (odbieranie danych dźwiękowych z mikrofonów, wysyłanie dźwięku do głośników). Bazuje na standardowych kodach PIN ( 0000 ) i zestawach, które nie są sparowane. Wykaz urządzeń podatnych na ataki:

10 (wg. Vulnerability Matrix (* = NOT Vulnerable) Make Model Firmware Rev BACKDOOR Ericsson T68 20R1B 20R2A013 20R2B013 20R2F004 20R5C001 SNARF when Visible SNARF when NOT Visible BUG? Yes No No Sony Ericsson R520m 20R2G? Yes No? Sony Ericsson T68i 20R1B 20R2A013 20R2B013 20R2F004 20R5C001? Yes?? Sony Ericsson T610 20R1A081 20R1L013 20R3C002 20R4C003 20R4D001? Yes No? Sony Ericsson T610 20R1A081??? Yes Sony Ericsson Z1010?? Yes?? Sony Ericsson Z600 20R2C007 20R2F002 20R5B001? Yes?? Nokia 6310 Nokia 6310i ? Yes Yes? No Yes Yes Yes Nokia 7650? Yes No (+)? No Nokia 8910?? Yes Yes? Nokia 8910i?? Yes Yes? * Siemens S55? No No No No * Siemens SX1? No No No No Motorola V600 (++)? No No No Yes Motorola V80 (++)? No No No Yes