Bezpieczne aplikacje mobilne - oksymoron?

Opublikowano: 9 stycznia 2008

Zawartość strony

	Wstęp
	Tworzenie Bezpiecznych Aplikacji Mobilnych
	Względy Specyficzne dla Rozwiązań Mobilnych
	Aspekty związane z wprowadzaniem danych
	Kryptografia
	Zarządzanie kluczami
	Przepełnienia bufora
	Zabezpieczanie Windows Mobile
	Podsumowanie

Wstęp

„Bezpieczeństwo” i „rozwój aplikacji mobilnych” rzadko pojawiają się razem w jednym zdaniu. Ostatnio spotykałem się z wieloma środowiskami programistów w całej Wielkiej Brytanii i rozmawiałem o rozwoju aplikacji mobilnych. Kiedy pytałem, ilu spośród nich jest zainteresowanych tym czy innym aspektem bezpieczeństwa, to okazało się, że jedynie 2 proc. spośród nich, czyli na 140 osób jedynie 3 osoby!

Jeżeli należysz do tych 2 proc., to wykonuj dalej swoją robotę. Ale dlaczego większość specjalistów technologii mobilnych ma tak obojętny stosunek do bezpieczeństwa? Czy naprawę „bezpieczne aplikacje mobilne” to oksymoron?

Na niektóre przyczyny tej obojętności można natrafić, przyglądając się sposobowi tworzenia aplikacji mobilnych przez zespoły programistów; zdecydowana większość aplikacji pochodzi od małych zespołów, złożonych z dwóch lub trzech osób, które często, dysponując niewielkimi środkami, rozpoczynają działalność gospodarczą i wypuszczają na rynek produkt z zamiarem zagospodarowania niszy rynkowej. Zdarza się, że rozwój aplikacji mobilnych jest jedynie produktem ubocznym większego projektu z zakresu aplikacji biurowych realizowanego przez odział IT, który pragnie jedynie poszerzyć możliwości aplikacji biurowych, tak, aby móc sobie odhaczyć ptaszkiem wybór „opcje mobilne”.

W obydwu wypadkach nie starcza często ani pieniędzy, ani czasu, by dodatkowo zajmować się jeszcze niezwracającymi niczyjej uwagi, bezbarwnymi i drętwymi aspektami bezpieczeństwa. Te aspekty bezpieczeństwa zaczaiły się gdzieś w cieniu, na zapleczu zwracających uwagę użytkowników funkcji i „ekscytujących” interfejsów użytkownika, które wywołują okrzyki zachwytu ze strony dyrektorów ds. technicznych, zachęcając ich jednocześnie do sięgnięcia po długopis i książeczkę czekową.

W innych sytuacjach bezpieczeństwo jest odbierane jako bariera dla łatwości używania; użytkownicy wiedzą, że urządzenia i oprogramowanie mobilne służą głównie temu, aby dane były zawsze w zasięgu ręki, uwzględnianie aspektów bezpieczeństwa powoduje zalew skarg użytkowników, narzekających na konieczność wprowadzenia hasła jednie po to, aby móc sprawdzić stan zamówienia.

To jedynie dwa zarzuty z długiej listy i nie można odmówić zasadniczej prawdziwości tym argumentom: przeznaczając więcej czasu na kwestie bezpieczeństwa, prawdopodobnie tracimy więcej zalet niż ich dodajemy; prawdopodobne jest również przedłużenie czasu wstępnej fazy projektu oraz wzrost szacunkowych kosztów; a między poufnością i łatwością używania zawsze trzeba szukać punktu równowagi.

Czy jest to więc coś nowego? Przez wiele lat taka sama batalia toczyła się na polu komputerów osobistych i serwerów, i ciągle jeszcze się toczy. Wynieśliśmy mnóstwo doświadczeń, doznaliśmy wielu niepowodzeń, a także odnieśliśmy wiele sukcesów, które mogą nam służyć pomocą na wyłaniającym się polu technologii mobilnych. Nie musimy znowu popełniać tych samych błędów tylko z tego powodu, że zmieniliśmy platformę z komputera biurowego na coś, co mieści się w kieszeni koszuli - bądź co bądź jedno i drugie to tylko komputer, prawda? Zasady Wiarygodnych Technik Komputerowych (Trustworthy Computing): Bezpieczeństwo, Poufność, Niezawodność oraz Praktyki Biznesowe ciągle mają zastosowanie.

 Do początku strony

Tworzenie Bezpiecznych Aplikacji Mobilnych

A gdyby tak postawić pytanie odwrotne: Dlaczego każdy deweloper technologii mobilnych powinien zajmować się kwestiami bezpieczeństwa?

Wiarygodne Techniki Komputerowe mają zastosowanie niezależne od sprzętu: użytkownicy ciągle oczekują pojawienia się solidnych rozwiązań; informacja poufna ma pozostać poufna po dotarciu do odbiorcy, a pracownik mobilny nie chce, aby jego/jej telefon komórkowy stał się bramą, przez którą do sieci korporacyjnej przedostaje się niepożądany kod.

Jeśli chodzi o bezpieczeństwo, to deweloperzy aplikacji mobilnych powinni koordynować swoje działania z projektantami aplikacji biurowych. Aby pomóc ujawnić czynniki ryzyka i ich potencjalne ujemne skutki, na wczesnym etapie procesu projektowego ważne jest, aby mieć jasny obraz zalet stojących po stronie danego rozwiązania, a także rozumieć zagrożenia i możliwe słabe punkty.

Należy zintegrować bezpieczeństwo z cyklem rozwojowym oprogramowania, korzystając z technik takich, jak modelowanie zagrożeń, np. przechodząc przez wszystkie etapy modelu STRIDE: Spoofing (podszywanie sie pod inną osobę przy pomocy nieautoryzowanego dostępu do jej danych identyfikacyjnych), Tampering (złośliwa modyfikacja danych), Repudiation (wyparcie się przeprowadzenia określonej akcji przez jej autora), Information Disclose (dotarcie do informacji przez osobę niemającą odpowiednich uprawnień), Denial of Service (uniemożliwienie skorzystania z usługi bądź systemu przez uprawnionego użytkownika) i Elevation of Privilege (nieautoryzowane zwiększenie przywilejów użytkownika).

Mając tak poszerzoną wiedzę i nowe zrozumienie tematu, możliwe już jest dokonywanie wyborów projektowych i takie skierowanie uwagi deweloperów, aby ograniczyć lub całkowicie wyeliminować ryzyko ujawnione poprzez powyżej wymienione procedury.

Istnieje pewna liczba technik i ogromny zasób dostępnych informacji, odnoszących się do sposobów włączania bezpieczeństwa do cyklu projektowania, a modelowanie zagrożeń jest tylko jedną z częściej wykorzystywanych procedur. To, którą procedurę lub założenia ramowe zastosować zależy w dużym stopniu od tego, co odpowiada specyficznej dynamice twojego zespołu rozwojowego. Jednakże to, co najważniejsze to dokonanie samego wyboru i zdecydowanie się na jakąś strategię. Jeżeli szukasz punktu startowego, weź pod uwagę artykuł: patterns & practices Security Engineering paper lub książkę: The Security Development Lifecycle, autorzy: Michael Howard i Steve Lipner.

 Do początku strony

Względy Specyficzne dla Rozwiązań Mobilnych

Choć prawdą jest, że podstawowe zasady bezpieczeństwa platform mobilnych i komputerów biurowych są takie same, to czynniki ryzyka dotyczące bezpieczeństwa i aspekty bezpieczeństwa są nieco odmienne – ze względu na naturę użytkowników i sprzętu mobilnego. Na przykład, prawdopodobieństwo pozostawienia telefonu komórkowego włączonego i odblokowanego na tylnym siedzeniu taksówki jest znacząco wyższe niż pozostawienie w takim samym stanie laptopa. Dlatego ważne jest zrozumienie zalet używanych aplikacji oraz negatywnych skutków utraty lub kradzieży urządzenia.

Oto parę czynników związanych z aplikacjami mobilnymi (patrz: Application Security, Deployment and Management, artykuł z bazy MSDN - dodatkowe informacje na temat bezpieczeństwa rozwiązań mobilnych).

 Do początku strony

Aspekty związane z wprowadzaniem danych

Projektowanie interfejsu użytkownika to zadanie bardzo trudne ze względu na niewielką powierzchnię wyświetlacza oraz małe możliwości klawiatury numerycznej przy wprowadzaniu danych. Ważne jest odnalezienie odpowiedniego punktu równowagi pomiędzy wyświetlaną informacją i liczbą kluczowych procesów potrzebnych do uzyskiwania danych. Hasła są integralną częścią tego zadania.

Wymaganie od użytkownika wprowadzania dziesięciocyfrowego hasła alfanumerycznego co każde 30 sekund może oznaczać, że firmowy inspektor zabezpieczeń będzie miał spokojną głowę, ale najpewniej użytkownicy po prostu zrezygnują z korzystania z urządzenia na rzecz kartki papieru i długopisu. Dodatkowo zawsze istnieje ryzyko, że użytkownicy przykleją sobie hasło do tylnej strony urządzenia (widziałem na własne oczy!).

W tych okolicznościach, kompromis polega na usunięciu z aplikacji mobilnych niektórych zastrzeżonych danych tak, aby umożliwić zastosowanie krótszych haseł. Można też rozważyć dwustopniową blokadę, kiedy od użytkownika wymaga się wprowadzania pełnego hasła w dłuższych odstępach czasu, a dla potwierdzenia jego tożsamości, w krótszych odstępach czasu, wprowadzania krótszego numeru PIN. Dla niektórych urządzeń dostępne są statystyki biometryczne. Dwoma innymi elementami rozwiązania są, do wyboru, karta procesorowa lub karta magnetyczna, które mogą również przyczynić się do uproszczenia wprowadzania danych przez użytkownika.

 Do początku strony

Kryptografia

System operacyjny Windows Mobile obejmuje implementację interfejsu CryptoAPI, czyli interfejsu programowania aplikacji kryptograficznych (Cryptography Application Programming Interface). Windows Mobile obsługuje także szeroki zakres funkcji, w tym symetryczne i niesymetryczne algorytmy kryptograficzne. Dodatkowo, platforma Microsoft .NET Compact Framework 2.0 posiada klasy zarządzające, które odpowiadają klasom platformy przeznaczonej na komputery biurowe oraz zapewnia prosty dostęp do biblioteki kryptograficznej - crypto library. Wszystko to razem jest dobrą informacją, a odpowiednie korzystanie ze wspomnianych wyżej funkcji, w celu zapewnienia poufności danych, jest jak najbardziej pożądane. Mimo to należy zachować pewną ostrożność względem rozwiązań mobilnych.

Na ogół moc przetwarzania urządzeń mobilnych jest taka sama, jak moc przetwarzania sprzętu biurowego starszego o około dwa do trzech lat, a więc projektując rozwiązania mobilne, należy czasami brać pod uwagę obciążenie CPU. Algorytmy asymetryczne mogą pochłaniać znaczną część mocy obliczeniowej CPU i dlatego mogą zdecydowanie spowalniać pracę urządzenia.

Używając kodowania symetrycznego, rozsądnie jest ograniczyć zabezpieczane dane do elementów krytycznych i odszyfrowywać jedynie wtedy, kiedy jest to wymagane w celu ich wyświetlenia lub używania programu - dla większości danych często wystarczy użyć klucza symetrycznego, a następnie zaszyfrować klucz symetryczny przez szyfrowanie asymetryczne, w ten sposób odciąża się CPU i jednocześnie przedłuża życie baterii urządzenia.

 Do początku strony

Zarządzanie kluczami

W kryptografii zawsze mamy do czynienia z jakiegoś rodzaju kluczem głównym i od tego punktu zaczyna się zarządzanie kluczami. Zarządzanie kluczami, niezależnie od platformy, związane jest ze specyficznymi problemami, ale zarządzanie kluczami w urządzeniach mobilnych może stanowić poważny problem.

Windows Mobile dla zarządzania kluczami nie oferuje chronionego magazynu maszyny lub użytkownika – tak, jak jest to w systemach operacyjnych Windows XP i Windows Vista. Stąd magazynowanie kluczy na urządzeniach z systemem operacyjnym Windows Mobile jest zadaniem trudnym. Ponieważ Windows Mobile nie implementuje funkcji object level security, to magazynowanie klucza głównego w kodzie albo w pliku w magazynie jest rzadko stosowanym rozwiązaniem; zatem nie można indywidualnie ograniczyć dostępu z zewnątrz do plików przez inne procesy lub przez technologie (takie, jak Active Sync).

Zdecydowanie najłatwiejszym i najbezpieczniejszym sposobem radzenia sobie z kluczem głównym jest wydanie go użytkownikowi i zdjęcie w ten sposób problemu z urządzenia. Oznacza to, że klucz główny wyprowadzany jest z hasła użytkownika na granicy urządzenia lub na granicy twojej aplikacji.

Innym rozwiązaniem, które może być satysfakcjonujące w niektórych wypadkach, jest używanie jednego z unikalnych numerów identyfikacyjnych urządzenia mobilnego, takich, jak numer IMSI dla urządzeń wykorzystujących telefon lub unikalnego numeru identyfikacyjnego, który przypisany jest do każdego urządzenia z systemem operacyjnym Windows Mobile. Niemniej, należy zachować ostrożność podczas używania tego rodzaju danych, ponieważ jeżeli dane klucza są dostępne dla twojej aplikacji, to są one dostępne dla innych aplikacji lub w przypadku numeru identyfikacyjnego IMSI możliwe jest pobranie interaktywne poprzez klawiaturę odblokowanego urządzenia.

Windows Mobile oferuje również funkcje DPAPI (Data Protection API), takie, jak funkcja CryptProtectData, która w celu zabezpieczenia danych przed atakiem pochodzącym spoza urządzenia korzysta z klucza dla konkretnego urządzenia.

Używając tych interfejsów API łącznie z zestawem bezpieczeństwa aplikacji urządzenia – tak, aby uruchamianie ograniczyć jedynie do podpisanych i zaufanych aplikacji, aplikacja może tworzyć pliki lub magazyny danych tylko na tym urządzeniu. Pliki te mogą być jedynie odczytane przez urządzenie, na którym utworzono magazyn. Więcej informacji o konfiguracji zasad bezpieczeństwa urządzenia: configuring device security policy - kliknij tutaj. Informacje na temat interfejsu DAPI - kliknij tutaj.

 Do początku strony

Przepełnienia bufora

Typowe przepełnienie bufora, które zmienia adres zwrotny funkcji poprzez przepełnianie lokalnej zmiennej stosu w komputerach z procesorem Intel X86, stwarzało bardzo wiele problemów, ale było to związane z architekturą stosu rosnącego w dół od adresu pamięci wysokiej ze wskaźnikiem powrotu zapisywanym powyżej zmiennych lokalnych. Urządzenia mobilne używają innej architektury CPU oraz innego zestawu instrukcji – co sprawia, że tego typu ataki są zdecydowanie trudniejsze do przeprowadzenia, a wirusy, które wykorzystują tego typu techniki, są obecnie w urządzeniach mobilnych w dużo mniejszym stopniu rozpowszechnione.

Oprócz tego adres IP urządzenia zmienia się od stacji bazowej do stacji bazowej, a liczba aplikacji oczekujących połączeń przychodzących jest niewielka. W rzeczywistości mniejsza liczba funkcji w urządzeniu oznacza, że jest mniej dostępnego kodu do zaatakowania.

Nie ma żadnych usprawiedliwień dla samozadowolenia! Stałe połączone urządzeń z siecią jest celem, do którego dąży przemysł, często urządzenia te są używane do przeglądania Internetu i do połączeń w sieci korporacyjnej. Mając w ciągłym obiegu pewną liczbę urządzeń, jest tylko kwestią czasu, kiedy pojawi się skuteczny sposób ataku, który zostanie potwierdzony i rozpowszechni się wśród wielu użytkowników.

Przepełnienia bufora są potencjalnie szkodliwe z wielu względów i nie ograniczają się jedynie do atakowania adresu zwrotnego funkcji. Aplikacje mobilne, bez względu na architekturę CPU, są w takim samym stopniu narażone na tego typu ataki. Korzystanie z kodu zarządzanego dla aplikacji, takiego, jak: C# lub VB.NET, jako uzupełnienie sensownych procedur rozwojowych a także przeglądanie kodu i analiza bezpieczeństwa, prowadzą do minimalizacji tego typu czynników ryzyka.

 Do początku strony

Zabezpieczanie Windows Mobile

Windows Mobile oferuje wiele funkcji infrastrukturalnych i narzędzi dla deweloperów, które mogą być używane do tworzenia strategii bezpieczeństwa dla zabezpieczania urządzenia i zabezpieczania aplikacji które się na nim znajdują.

Po pierwsze, strategia ochrony w strefie bezpieczeństwa może być ustalona przez użytkownika tak, aby wymagane było podanie numeru PIN lub hasła i w ten sposób zapewniony jest pierwszy poziom zabezpieczenia w dostępie do urządzenia.

Mechanizm ten jest zaimplementowany poprzez uwierzytelnianie LASS (Local Authentication Sub System) i może być wzmocniony przez mechanizmy LAP (Local Authentication Plug-ins) – sposób zapewniania dostosowywanego interfejsu użytkownika i uwierzytelniania. Dla korporacyjnej aplikacji mobilnej może to być bardzo użyteczne narzędzie do przechwytywania klucza głównego od użytkownika i przenoszenia go na aplikacje działające na urządzeniu. Aby uzyskać więcej informacji na temat architektury LASS i LAP kliknij tutaj.

Inny mechanizm podstawowej ochrony jest implementowany dzięki podpisywaniu kodu. W celu potwierdzenia tego czy kod jest podpisany, czy sygnatura jest ważna i zgadza się z autoryzowanym certyfikatem zainstalowanym na urządzeniu, Windows Mobile sprawdza każdy moduł wykonywalny, taki, jak biblioteki dołączane dynamicznie (.dll), i pliki wykonywalne (.exe), w momencie kiedy są one ładowane.

Windows Mobile może być tak skonfigurowany, aby blokować wykonywanie kodu, który nie spełnia wyżej wymienionych kryteriów, w ten sposób urządzenie jest zabezpieczane przed złośliwym kodem. Instalowanie oprogramowania poprzez pliki CAB jest również chronione przez ten proces z własną bazą certyfikatów, a w urządzeniu dostępny jest magazyn odwołań w celu blokowania wykonywania i instalacji podstępnych aplikacji. Obok podpisywania kodu, w celu ograniczania dostępu do plików, kluczy rejestrów i innych zasobów w obrębie systemu, Windows Mobile korzysta z ról bezpieczeństwa skojarzonych z certyfikatami w magazynie. Aby uzyskać więcej informacji na temat podpisywania kodu, jako funkcji zabezpieczającej w Windows Mobile kliknij tutaj.

Dla danych relacyjnych istnieje pewna liczba rozwiązań problemu magazynowania danych w urządzeniach mobilnych. Silnik bazy danych Microsoft SQL Compact zapewnia nie tylko bogaty i wszechstronny magazyn relacyjny, ale zawiera również opcje dla szyfrowania danych i zabezpieczenie hasłem. Aby uzyskać więcej informacji na temat Microsoft SQL Compact kliknij tutaj.

Jest wiele innych obszarów, których tutaj nie poruszyłem, np.: bezpieczna komunikacja, uwierzytelnianie serwera, zarządzanie urządzeniem (funkcja remote wipe- zdalne czyszczenie) oraz sprawdzanie wirusów. Aby uzyskać więcej informacji na ten temat, a także o innych aspektach bezpieczeństwa dla urządzeń mobilnych przejdź na strony bezpieczeństwo, wdrażanie i zarządzanie (Security, Deployment and Management) Centrum Rozwoju Windows Mobile (Windows Mobile Development Center).

 Do początku strony

Podsumowanie

Zadanie bezpieczeństwa nie jest zadaniem niewykonalnym i jest to prawda również dla aplikacji mobilnych. Istnieją narzędzia i zasoby, które służą pomocą w stworzeniu solidnych aplikacji mobilnych. Nierobienie niczego może wydawać się najłatwiejszą i najtańszą opcją, ale tylko na krótką metę.

Jeśli chcesz zyskać zaufanie użytkowników, niezależnie od tego czy są oni użytkownikami wewnątrz korporacji, czy zwykłych użytkowników poza nią, musisz stworzyć takie oprogramowanie, które działa zgodnie z intencją twórcy: zabezpiecza dane, na których zależy użytkownikowi i nie stanowi bramy, przez którą może przedostać się do urządzenia złośliwe oprogramowanie. Jeśli nie myślałeś jeszcze o bezpieczeństwie twojego projektu mobilnego, to teraz jest czas, aby zacząć o tym myśleć.

„Bezpieczna aplikacja mobilna” to nie oksymoron, choć od każdego indywidualnego projektanta zależy, czy podejmie on wyzwanie i uwzględni kwestie bezpieczeństwa w całym cyklu rozwojowym aplikacji.

Do początku strony