Certyfikaty na Symbiana

Jednym z najbardziej kontrowersyjnych tematów wśród posiadaczy komórek jest podpisywanie aplikacji na Symbiana. Inżynierowie tworzący Symbiana spodziewając się problemów z masowym tworzeniem niebezpiecznego oprogramowania na komórki, postanowili zabezpieczyć się przed tym. Pierwsze zabezpieczenie to wprowadzenie mechanizmu wymogu podpisywania paczek instalacyjnych certyfikatami. A drugie zabezpieczenie to mechanizm uprawnień dostępu do plików w komórce i do pewnych bibliotek poprzez programistyczne API.

Warto przypomnieć z artykułów Symbian Foundation Security Blog kilka faktów: tworzenie infrastruktury opartej na certyfikatach nie było prostym zadaniem dla firmy tworzącej system operacyjny Symbian. W tej sytuacji postanowiono przekazać te zadania do zewnętrznych podmiotów. W 2004 roku postanowiono, że certyfikatami będzie zarządzać Verisign, testowaniem Capgemini, a Symbian będzie tylko zarządzał portalem do rejestracji oprogramowania i certyfikatów. Potem doszedł w 2007 roku TC TrustCenter, który faktycznie przejął główną rolę dostarczyciela certyfikatów dla twórców oprogramowania na Symbiana. Skutkiem takiego podejscia oznaczało że developerzy musieli sami się obsłużyć i generowało dodatkowe koszty tworzenia oprogramowania. A producentom komórek taki model był bardziej na rękę bo przenosił odpowiedzialność za oprogramowanie do komórek na programistów i organizacje testujące. Wkrótce okazało się, że zaczęły się pojawiać zagrożenia, ze strony niebezpiecznego oprogramowania. W tej sytuacji postanowiono jakoś zabezpieczyć się na poziomie systemu operacyjnego. Więc inżynierowie z Symbiana postanowili tak zaprojektować system, żeby wymuszał instalację tylko podpisanego i zaufanego oprogramowania z certyfikatem. Tak więc od 2006 roku mamy pierwsze komórki oparte na Symbianie 9.x, które posiadały mechanizm zarządzania uprawnieniami dostępu do programistycznego API.

Uprawnienia dostępu do API oznacza tylko tyle co wolno robić danemu programowi użytkownika. Zanim program zostanie uruchomiony zawiera informacje o tym jakie uprawnienia dostępu do API potrzebuje. Podczas instalacji najpierw jest sprawdzany czy paczka ma poprawny certyfikat, następnie sprawdzany jest rodzaj certyfikatu. Certyfikat może być wygenerowany na konkretna komórkę według posiadanego numeru IMEI, albo wg informacji o właścicielu certyfikatu (tzw z Publisher ID). Można też wyróżnić certyfikaty po kątem sposobu w jaki mogą zostały wygenerowane: własny (self-signed), developerski (devcert), z uprawnieniami (cert with manufactured capabilities).

Do nauki programowania Symbiana wystarczy w większości przypadków certyfikat własny (selfsigned). Instrukcja zrobienia takiego podpisu z linii poleceń wymaga zainstalowania SDK i przerobienia tej instrukcji. Natomiast, żeby wygenerować podpis developerski trzeba wcześniej mieć wykupiony certyfikat typu Publisher ID z firmy TC TrustCenter. Ten certyfikat kosztuje 200$ na rok czasu. Następnie trzeba zarejestrować się na stronie Symbian Signed. Pobrać program Developer Certificate Request i na bazie certyfikatu z Publisher ID wygenerować plik certyfikatu developerskiego w programie Open Signed Offline na konkretny numer IMEI.

Dla kogoś komu zależy na nauce programowania na Symbiana może też sobie używać do woli programu Open Signed Online, dzięki któremu będzie mógł wysłać swoją paczkę sis do podpisania przez nich certyfikatem dla IMEI danej komórki. Trzeba tylko pamiętać żeby UID3 był w zakresie 0xE0000000...0xEFFFFFFF. Podpisując w innym zakresie UID3 trzeba pamiętać o tym że inni nie będą mogli podpisywać poza Tobą danej aplikacji, bo dany UID3 będzie przypisany do danego adresu email osoby, która zażyczyła sobie dany UID3.

W takiej sytuacji dużą popularnością cieszą się chińskie usługi on-line do tworzenia developerskich certyfikatów. Są to: iMobile czy Opda.

Natomiast jak zależy na wprowadzeniu oprogramowania do masowej dystrybucji to czeka jeszcze sporo wydatków i pracy. Pierwszym to jest zakup certyfikatu PublisherID. Następnie zarejestrowanie się w programie Express Signed gdzie można kupować identyfikatory dla zawartości. Jeżeli zależy na tym, żeby twoja paczka sis z zawartością miała chroniony identyfikator UID3 to trzeba kupić PayPalem tak zwany ContentID. Następnie trzeba podpisać aplikację z certyfikatem i kluczem z TC TrustCenter. kolejną rzeczą jest wysłanie tego pliku sis do podpisania certyfikatem Symbiana (Root B). W programie Express Signed można podpisywać zawartość pasywną (multimedia, motywy) i jak aplikacje. Z tym, że trzeba wcześniej samemu sprawdzić czy aplikacja spełnia warunki testów. Po wysłaniu trzeba odczekać jakiś czas, a po wstępnej weryfikacji na koncie będzie podpisana przez Symbiana aplikacja. Czasami losowo występuje audyt twoich aplikacji. Jeżeli aplikacja nie będzie spełniać testów to konto zostanie zablokowane aż do momentu wysłania aplikacji spełniającej wymogi testów.

Natomiast w programie Certified Signed warto uzyskać podpisanie aplikacji pod kątem bezpieczeństwa i dostępu do zastrzeżonych uprawień API. Jest to dość kosztowny audyt, ale dzięki temu że zewnętrzni audytorzy sprawdzą działanie programu sprawi też że można uzyskać pewność że aplikacja jest bezpieczna dla użytkowników.

Nokia w programie dla firm Forum Nokia Launchpad wymaga, żeby firma biorąca udział w tym programie już posiadała Publisher ID. Natomiast dla własnych potrzeb mają dział który zajmuje się przygotowywaniem aplikacji do przetestowania wg dodatkowych kryteriów testów przez zewnętrzne firmy posiadające uprawnienia do testowania aplikacji. Dodatkowe kryteria są opisane w dokumencie Nokia Test Criteria for Symbian C++ Applications v2.1. Firmy, które zajmują się testowaniem aplikacji na Symbiana przed przyznaniem im zaufanych certyfikatów ną nazywane "Test Houses" Są to: Digia, Flander, Mphasis, NSTL, Sogeti.

Dla programistów midletów w technologii MIDP2.0 sytuacja też nie jest klarowna. Twórcy Java Mobile w sytuacji gdy inżynierowie Symbiana tworzą zręby pod zabezpieczenia ich systemu operacyjnego postanowili przejąc model wymagania podpisu w sytuacji dostępu do określonego API. Gdy liczba pakietów dostarczanych dla Java Mobile zacząła lawinowo rosnąć do ciała standaryzujacego, wymusiło to na producentach komórek wdrożenie mechanizmów bezpieczeństwa. W praktyce to polega na tym że każdy niepodpisany midlet w komórce nie może wykonywać potencjalnie niebezpiecznego API. W praktyce każdy producent urządzeń definiował to jakie API będzie wymagał podpisania.W praktyce wyszło że firma Verisign wdrożyła program Java Verified, któy miał podpisywac midlety Javy aby były one zaufane. Aby aplikacja Javy Mobile stała się zaufana to trzeba dokonać zakupu certyfikatu do podpisywania midletów typu PublisherID. Ten certyfikat jest inny niż ten który jest używany do podpisywania aplikacji Symbiana. Następnie trzeba zarejstrować się w programie Java Verified i wysłać podpisanym zakupionym certyfikatem w celu uzyskania podpisanej wersji zaufanej w celach testowych. W praktyce to oznacza że możesz w ciągu tygodnia czasu przetestowac aplikację w komórce majac dostęp do trusted API. Aby aplikacja Java Mobile mogła być uruchomiona w każdej komórce to jest potrzebne wysłanie midletu do organizacji testującej. Po opłaceniu testów otrzymujesz wynik testów i pliki midletu podpisane podpisem organizacji testujacej. I potem znowu z witryny w programie Java Verified otrzymujesz midlet podpisany który możesz już dystrybować aplikację.

Wkrótce sytuacja stała się taka, że wysokie koszta zaczęły generować ośrodki testujące aplikacje przed dopuszczeniem aplikacje Javy Mobile do oficjalnego podpisywania. Wystawiały one testy w zależności od ilości modeli komórek do przetestowania. Testy odpowiadały na pytanie czy aplikacja Java Mobile spełnia testy opisane w dokumencie Unified Testing Criteria (PDF). W tym przypadku głównym problemem okazał się dla większosci hobbystów i zaawansowanych użytkowników komórek fakt posiadania Publisher ID. Pośrednio to przyczyniło się do spadku zainteresowania technologiami Java Mobile przez programistów i zaawansowanych uzytkowników, w szczególności w Stanach Zjednoczonych co pokazują takie wpisy na blogach: Ivana Kuznietsova, czy J2MESecrets ( trochę nie bez powodu w Stanach Zjednoczonych komórki Nokii są mało popularne).

Z perspektywy czasu patrząc na rynek oprogramowania na Symbiana sytuacja jest dość dziwna. Restrykcyjne zasady tworzenia oprogramowania na Symbiana sprawiają że wiele osób chciałoby coś zaprogramować i udostępnić światu, muszą liczyć się z tym że mało ludzi umie podpisać aplikacje na Symbiana, czy wyrobić certyfikaty na własną komórkę. Obecnie w dobie popularności zaawansowanych komórek rośnie rola tych którzy łamią i obchodzą zabezpieczenia (dla Apple iPhone są to jailbreaki), natomiast w przypadku Symbiana oprogramowanie które dodaje dostęp do ukrytych folderów i jak wyłącza sprawdzanie uprawnień API podczas instalacji (np: HeliOX).

W komórce jest repozytorium certyfikatów są tam certyfikaty rożnych firm które otrzymały możliwość dodawania swojego certyfikatu jako zaufanego. Ale i tak hakerom czasami udaje się wgrać odpowiednie własne certyfikaty. Dodanie własnego certyfikatu sprawia że można podpisywać aplikacje własnym developerskim certyfikatem. Inną możliwością jest patchowanie pliku swpolicy,ini w plikach ROM (tak zwanej pamięci gdzie są przechowywane pliki potrzebne do uruchomienia podczas restartu). Głównie łamaniem komórek interesują Ci ludzie, którzy chcą mieć pełną kontrolą nad tym jak działa Symbian w ich komórkach.

Czasami korzystam z narzędzi które mają sprawdzić poprawność i integralność certyfikatów:
devcertlist - który sprawdza numery IMEI w certyfikacie i uprawnienia do API w danym certyfikacie

Ponieważ Fundacja Symbiana widzi coraz większe zapotrzebowanie na rozwój ich aplikacji, pozostaje przed dylematem jak rozwiązać mechanizmy dystrybucji aplikacji. Obecny model miałby sens gdyby nie było certyfikatów deweloperskich. Sytuacja przypomniałaby sytuację twórców aplikacji na iPhone. Zakup certyfikatu PublisherId, a potem zakup hurtowej ilości ContentID jest nie do przyjęcia dla większości programistów którzy robią i piszą aplikacje dla własnych potrzeb.. W tej sytuacji korzystniejszym modelem byłoby "fundowanie" opensourcowych aplikacji poprzez PublisherId w zamian za to, że autor aplikacji może rozwijać się w tworzeniu aplikacji na Symbiana. Wystarczy jakiś system podobny do tego jak Git, gdzie system podczas rejestracji proponował podanie IMEI komórki użytkownika. W zamian za to że ktoś tam opublikuje kod źródłowy to otrzyma UID3. Jak użytkownik zamieści tam swoją niepodpisaną paczkę sis, to system wygeneruje certyfikat na IMEI komórki użytkownika. Inni użytkownicy, będą mogli sobie pobrać kod źródłowy i skompilować go u siebie a następnie odesłać razem z kodem na serwer w celu uzyskania podpisu. Opcjonalnie byłaby kompilacja kodu na serwerach (za opłatą oczywiście). W ten sposób może to się rozwijać w stronę IDE on line dla programistów. Wiadomo że ten model raczej będzie cieszył się uznaniem tych którzy będą mieli dostęp do podpisanych sisów rożnych wersji tego samego programiku. Z jednej strony taki otwarty model trzymania kodu źródłowego może zachęcić programistów do robienia swojej wersji programiku "Witaj Świecie" na komórki jak zobaczą jak wielu innych też dzieli się swoim kodem. Nokia dala już dostęp ludziom do kodów biblioteki Qt i fajnie jest jak potencjalni uzytkownicy mogą obserwować zmiany w kodzie źródłowym bibliotek Qt. Im więcej darmowego oprogramowania na Symbiana i tym więcej kodów źródłowych będzie korzystnie wpływać na wizerunek Symbiana i producentów komórek z Symbianem. Im więcej stron dla początkujących jak nauczyć się programowania na Symbiana C++ pisanych przez uczących się to tym lepiej dla wszystkich.