iOS | |||||
| POPIS: |
iOS
Platformě iOS je věnována célá druhá kapitola. Za účelem omezení redundance
informací zde proto budou uvedeny pouze základní aspekty této platformy. Operační systém
iOS můžeme nalézt na mobilních zařízeních Apple iPhone, iPad a iPod Touch.
Historie iOS
Operační systém iOS byl světu poprvé představen ve verzi 1.0 spolu s prvním
komerčně úspěšným „dotykovým“ mobilním telefonem iPhone 29. června 2007. Za oběma
stojí společnost Apple, která sídlí v Cupertinu (Kalifornie, USA). Dne 11. července 2008
uvádí Apple iPhone 3G a iOS 2.0. Verze 2.0 přináší aplikaci App Store, která umožňuje ze
stejnojmeného obchodu stahovat aplikace třetích stran. O rok později přichází Apple
s iPhonem 3GS, který obsahuje novou verzi iOS 3. V červnu 2010 je uveden iOS 4, jenž je
v říjnu 2011 nahrazen novým iOS 5.
Dne 12. září 2012 představuje Apple iPhone 5 spolu s iOS 6. Zanedlouho, 18. září
2013, byly představeny mobilní telefony iPhone 5C a iPhone 5S, na kterých běžel iOS7.
Zatím poslední hlavní verze iOS byla vydána spolu s telefony iPhone 6 a iPhone 6 Plus. Této
verzi, která nese označení iOS 8, je věnována celá druhá kapitola této práce.
Systémové aplikace iOS
Součástí iOS jsou také předinstalované systémové aplikace. Uvedu zde ty, které jsou
obecně považovány za nejdůležitější:
Aplikace Telefon – slouží k přijímání a vykonávání telefonátů.
Aplikace Kontakty – udržuje veškeré kontakty telefonu.
Aplikace Zprávy – umožňuje přijímání a odesílání zpráv SMS a MMS.
Aplikace Mail – umožňuje příjem a odesílání e-mailů. V současné době podporuje pro
příchozí poštu protokoly IMAP i POP3 a pro odchozí poštu protokol SMTP.
Aplikace Safari – prohlížeč webových stránek.
Aplikace App Store – umožňuje stažení aplikací z App Store.
Aplikace Fotoaparát – slouží k pořizování fotografií a videa prostřednictvím
vestavěného fotoaparátu.
Popis platformy iOS
Platforma iOS obdobně jako jakékoli jiné operační systémy tvoří vrstvu mezi
hardwarem zařízení a uživatelskými aplikacemi. Aplikace tedy nekomunikují přímo
s hardwarovou vrstvou zařízení, ale s předem definovanými rozhraními iOS. To zajišťuje
konzistentní prostředí pro běh aplikací a snadnou přenositelnost těchto aplikací napříč
různými iOS zařízeními.
Tato kapitola bude pojednávat o aktuální verzi iOS, která nese označení iOS 8.
Detailům, jimiž se jednotlivé verze iOS 8 od sebe odlišují nebude věnována pozornost,
protože jsou pro potřeby této práce naprosto bezvýznamné.
Architektura iOS je založena na 4 základních vrstvách, přičemž každá vyšší vrstva
využívá prostředky nižší vrstvy, na které závisí. Jedná se o následující vrstvy, které jsou
seřazeny od nejvyšší po nejnižší:
Cocoa Touch
Media
Core Services
Core OS
Vrstva Cocoa Touch
Vrstva Cocoa Touch obsahuje klíčové frameworky pro tvorbu iOS aplikací. Tyto
frameworky definují nejen, jak aplikace vypadají, ale také zajišťují podporu multitaskingu,
dotykového rozhraní, push notifikací a dalších vysokoúrovňových systémových funkcí.
Nejdůležitější technologie, které poskytuje Cocoa Touch, jsou uvedeny
v následujících odstavcích.
App Extensions
App Extension se poprvé objevily v iOS 8 a jako takové umožňují rozšířit vybrané
části sytému. Platforma iOS podporuje App Extensions pro následující části systému,
označované rovněž jako body rozšíření:
Share
◦ Sdílení obsahu (například na sociálních sítích).
Action
◦ Provedení nějaké jednoduché akce nad obsahem.
Widget
◦ Umožňuje vykonání jednoduchého úkolu z prostředí notifikačního centra nebo z
přehledu „Dnes“.
Photo editing
◦ Provedení úprav fotografie v aplikaci „Obrázky“.
Document provider
◦ Poskytuje úložiště dokumentů, které může být přístupné i pro jinou aplikaci.
App Extensions
App Extension se poprvé objevily v iOS 8 a jako takové umožňují rozšířit vybrané
části sytému. Platforma iOS podporuje App Extensions pro následující části systému,
označované rovněž jako body rozšíření:
Share
◦ Sdílení obsahu (například na sociálních sítích).
Action
◦ Provedení nějaké jednoduché akce nad obsahem.
Widget
◦ Umožňuje vykonání jednoduchého úkolu z prostředí notifikačního centra nebo z
přehledu „Dnes“.
Photo editing
◦ Provedení úprav fotografie v aplikaci „Obrázky“.
Document provider
◦ Poskytuje úložiště dokumentů, které může být přístupné i pro jinou aplikaci.
Handoff
Jedná se o funkci poprvé představenou v iOS 8 a OS X 10.10. Handoff umožňuje začít
vykonávat nějakou činnost v konkrétní aplikaci na jednom zařízení a poté ji dokončit
na zařízení jiném. Handoff tedy uchovává aktuální stav rozdělané práce a tento stav, je-li to
možné, synchronizuje s dalšími zařízeními.
Document Picker
Document picker umožňuje sdílení dokumentů mezi aplikacemi, které tento
UIDocumentPickerViewController implementují. Dovoluje tím tedy „obejít“ omezení
sandboxu, kdy každá aplikace má přístup pouze ke své oblasti file systému.
AirDrop
Funkce AirDrop umožňuje uživatelům sdílet fotografie, dokumenty a další druhy dat
mezi blízkými zařízeními. Podpora odesílání souborů na jiné zařízení s iOS pomocí Airdrop
je implementována ve třídě UIActivityViewController.
TextKit
TextKit je bohatě vybavená množina tříd, které mají na starosti práci s textem
a precizní typografii. Použitím TextKit je možné různými způsoby stylovat text do odstavců,
sloupců nebo stránek. Umožňuje také rozličné obtékání textu kolem jednotlivých grafických
prvků. implementují protokol UIDynamicItem. UIKit Dynamics podporuje následujících 5 druhů
chování:
UIAttachmentBehavior
◦ Specifikuje spojení mezi dvěma dynamickými položkami nebo mezi jednou
dynamickou položkou a konkrétním bodem. Pokud se pohne jedna položka nebo
bod, pohne se současně i druhá položka.
UICollisionBehavior
◦ Umožňuje specifikovat „srážky“ mezi jednotlivými dynamickými položkami.
UIGravityBehavior
◦ Specifikuje vektor gravitačního zrychlení, v jehož směru dynamická položka
zrychluje do doby, než dojde k její kolizi s jinou dynamickou položkou nebo s
hranicí rozsahu pohybu.
UIPushBehavior
◦ Specifikuje vektor kontinuální síly nebo pouze impulzu síly, která působí na
dynamickou položku.
UISnapBehavior
◦ Specifikuje rovnovážný bod dynamické položky. Do tohoto bodu se dynamická
položka po svém vychýlení vrací s předem nakonfigurovaným efektem.
Multitasking
Z důvodu optimalizace spotřeby jsou aplikace po stisku tlačítka „Home“ uspány. Jsou
tedy sice stále nahrány v operační paměti zařízení, ale nevykonávají žádný kód. To může být
za některých situací problém, proto je pro konkrétní důvody možné z aplikace požádat iOS
o čas potřebný k dokončení úkolu nebo nechat vykonávání tohoto úkolu na iOS samotném.
Mezi možné způsoby řešení běhu aplikace na pozadí patří:
Aplikace může iOS požádat o přidělení nezbytně krátkého času na dokončení
důležitého úkolu. Během tohoto času aplikace skutečně běží na pozadí. V okamžiku,
kdy aplikace úkol dokončí, musí dát vědět operačnímu systému, že ji již může uspat.
Pokud vykonávání úkolu trvá příliš dlouho, oznámí iOS aplikaci, že ji za nějaký
krátký čas uspí. Po uplynutí tohoto času iOS aplikaci bez dalšího varování uspí.
Aplikace, která má specifikováno, že umí přehrávat audio, může běžet na pozadí bez
omezení.
Aplikace, která potřebuje na pozadí stáhnout nějaká data, by pro to měla používat
objekt třídy NSURLSession. V tomto případě aplikace na pozadí ve skutečnosti neběží.
Data totiž pro aplikaci stahuje sám iOS, přičemž aplikace je mezitím uspána.
Pro aplikace, které požadují po iOS polohu, existují 3 možné způsoby, jak toho docílit:
◦ Significant-change – aplikace je vyrozuměna, pokud dojde k výrazné změně
polohy. Velikost této změny je možné programově nastavit.
◦ Foreground-only – aplikace získává aktuální polohu pouze pokud je v popředí.
Toto není možné považovat za případ multitaskingu.
◦ Background – aplikace smí získávat data a tedy i běžet na pozadí kontinuálně.
Auto Layout
Auto Layout umožňuje rychlé a efektivní vytváření dynamických uživatelských
rozhraní s využitím relativně malého množství kódu. Nahrazuje původně používaný model
springs&struts.
Storyboards
Storyboard je doporučený model vytváření uživatelského rozhraní, včetně kompletní
hierarchie jednotlivých UIView. Storyboards také definuje přechody mezi jednotlivými
zástupci objektů typu UIViewController.
UI State Preservation
UI State Preservation zajišťuje uchování stavu všech aktuálních objektů typu UIView
a UIViewController v případě, že aplikace je umístěna do pozadí. Toto zajistí, že v případě
nedostatku operační paměti, kdy iOS ukončí naši aplikaci běžící na pozadí, se při dalším startu tato aplikace spustí se stejným rozložením objektů UIView a UIViewController,
s jakým ji iOS ukončil.
Apple Push Notification Service
Apple Push Notification Service umožňuje informovat uživatele o jakýchkoli nových
informacích a to i v případě, že odpovídající aplikace neběží. Tyto notifikace mimo jiné
upozorňují uživatele, že má otevřít danou aplikaci. Pro zasílání push notifikací je potřeba mít
vlastní server, který bude komunikovat jak aplikací v zařízení, tak s Apple Push Notification
Serverem.
Local Notifications
Jedná se o obdobu push notifikací. Rozdílem je to, že pro zaslání lokální notifikace
není potřeba externí server. Jak je z názvu patrné, lokální notifikace může aplikace zaslat jen
a pouze na zařízení, na kterém je nainstalována.
Gesture Recognizers
Gesture Recognizers jsou množinou všech tříd odvozených od základní třídy
UIGestureRecognizer. Úkolem Gesture Recognizers je detekce a vyhodnocování různých
druhů dotyků a dotykových gest.
Standard System View Controllers
Standard System View Controllers je množina systémových „dialogů“, které je možné
v aplikaci použít pro některé často používané funkce. Příkladem takových dialogů jsou
například zástupci následujících:
Dialog vytvoření e-mailu nebo SMS
Dialog pro zobrazení nebo úpravu kontaktu
Dialog pro pořízení fotografie
Výběr obrázku z galerie obrázků
Dialog pro natočení videoklipu
Otevření nebo náhled souboru
Níže jsou uvedeny Cocoa Touch Frameworky:
Address Book UI Framework
EventKit UI Framework
GameKit Framework
iAd Framework
MapKit Framework
Message UI Framework
Notification Center Framework
PushKit Framework
Twitter Framework
UIKit Framework
Vrstva Media
Vrstva Media obsahuje důležité funkce pro práci s grafickými, audio a video
technologiemi.
Grafické technologie
Grafické technologie z vrstvy Media jsou navrženy tak, aby bez problému
spolupracovaly s architekturou UIKit view. To dává vývojáři na výběr ze dvou možností. Buď
použít standardní view, nebo uživatelsky vytvořené view, obojí pomocí jakékoli z níže
uvedených technologií:
UIKit Graphic
◦ Definuje tzv. high-level podporu pro kreslení obrázků, Bézierových křivek
a animování obsahu jednotlivých view. Zajišťuje rychlé a efektivní vykreslování
obrázků a textového obsahu.
Core Graphic Framework
◦ Core Graphic je nativním vykreslovacím enginem pro iOS aplikace. Umožňuje
vykreslovat 2D vektorovou a bitmapovou grafiku. Renderování však není tak
rychlé jako v případě OpenGL ES.
Core Animation
◦ Jedná se o základní technologii, která optimalizuje vykreslování animací v aplikaci.
UIKit view používá tuto technologii při animování defaultně.
Core Image
◦ Core image poskytuje množinu filtrů pro zpracování videa i statických obrázků.
Jedná se o nedestruktivní filtry, které zachovávají originální předlohu nezměněnu.
OpenGL ES a GLKit
◦ OpenGL ES je výkonný 2D a 3D vykreslovací engine, který pro vykreslení
využívá hardwarovou akceleraci. Pro svou rychlost je využíván především herními
vývojáři a aplikacemi, které obsahují renderově náročnou grafiku.
Metal
◦ Metal je rozhraní, které na A7 GPU a všech novějších vyžaduje velice malou režii
pro svůj běh. Je proto velice výkonným jak renderovacím tak výpočetním
rozhraním.
TextKit a Core Text
◦ TextKit je využíván pro vytváření precizní typografie a správu vykreslování textu
obecně.
Image I/O
◦ Image I/O nabízí rozhraní pro čtení a zápis obrázků různých formátů.
Photos Library
◦ Photos Library zajišťuje přístup do uživatelovy galerie obrázků a videí.
Audio technologie
Audio technologie iOS z vrstvy Media pracují s hardwarovými zvukovými prostředky
mobilního zařízení a umožňují aplikacím přehrávat a nahrávat audio ve vysoké kvalitě,
zpracovávat formát MIDI a v neposlední řadě také zařizují přístup k systémovým zvukům.
Tyto audio technologie dokáží pracovat s různými formáty pro uchování zvukových nahrávek, a to nejen formátů specifických pro platformu Apple, ale také pro běžně používané
„standardní“ formáty. Podporované jsou následující:
AAC
Apple Lossless (ALAC)
A-law
IMA/ADPCM (IMA4)
Linear PCM
μ-law
DVI/Intel IMA ADPCM
Microsoft GSM 6.10
AES3-2003
Stejně jako grafické technologie mají i audio technologie několik zástupců:
Media Player Framework
◦ Umožňuje přístup do uživatelovy knihovny iTunes a přehrávání jak jednotlivých
skladeb, tak celých playlistů. Nenabízí však žádnou větší kontrolu nad
přehráváním.
AV Foundation
◦ AV Foundation slouží k pořizování nahrávek a přehrávání audia i videa.
Umožňuje velice dobrou kontrolu přehrávání média.
OpenAL
◦ OpenAl je multiplatformní průmyslový standard pro 3D audio rozhraní. Pro svou
vysokou efektivitu bývá používán převážně herními vývojáři.
Core Audio
◦ Core Audio je soubor frameworků, který nabízí sofistikovaná rozhraní pro
nahrávání a přehrávání různých audio formátů a MIDI. Core Audio je doporučeno
zkušeným vývojářům, kteří vyžadují vysoký stupeň kontroly nad nahráváním
a přehráváním audia.
Video technologie
Video technologie z vrstvy Media zajišťují podporu pro přehrávání jak lokálně
umístěných video dat, tak dat, která jsou streamovaná ze sítě internet. U zařízení, obsahujících
odpovídající hardware, umožňují tyto technologie též pořizování videonahrávek a jejich
případné začlenění do aplikace. Následující seznam uvádí zástupce video technologií z vrstvy
Media:
UIImagePickerController
◦ Tato třída má na starosti interakci s uživatelem v případě, kdy od něj požadujeme
získání obrázku nebo videa z jeho knihovny v zařízení, nebo když po něm
vyžadujeme pořízení fotografie či videa.
AVKit Framework
◦ AVKit Framework nabízí jednoduché rozhraní pro přehrávání videa. Podporuje
jak přehrávání na celou obrazovku, tak také v režimu okna. Umožňuje pouze
základní ovládání přehrávaného videa.
AV Foundation Framework
◦ AV Foundation Framework nabízí pokročilé rozhraní pro nahrávání a přehrávání
videa. Umožňuje s videem vykonávat mimo jiné i velice sofistikované činnosti
typu „obraz v obraze“.
Core Media Framework
◦ Definuje tzv. low-level interface a datové typy. Většina aplikací nepotřebuje
využívat tento framework přímo.
Platforma iOS podporuje mimo jiné tyto formáty video dat:
H.264 video do velikosti datového toku 1.5 Mbps, 640x480 pixelů, 30 snímků
za sekundu, s audio stopou AAC-LC do velikosti datového toku 160Kbps.
MPEG-4 video do velikosti datového toku 2.5 Mbps, 640x480 pixelů, 30 snímků
za sekundu, s audio stopou AAC-LC do velikosti datového toku 160Kbps.
Frameworky vrstvy Media
Assets Library Framework
AV Foundation Framework
AVKit Framework
Core Audio
◦ CoreAudio Framework
◦ AudioToolbox Framework
◦ AudioUnit Framework
◦ CoreMIDI Framework
◦ MediaToolbox Framework
CoreAudioKit Framework
Core Graphic Framework
Core Image Framework
Core Text Framework
Core Video Framework
Game Controller Framework
GLKit Framework
Image I/O Framework
Media Accessibility Framework
Media Player Framework
Metal Framework
OpenAL Framework
OpenGL ES Framework
Photos Framework
Photos UI Framework
Quartz Core Framework
SceneKit Framework
SpriteKit Framework
Vrstva Core Services
Vrstva Core Services poskytuje aplikacím kromě esenciálních systémových služeb
(definice základních datových kontejnerů, práce s řetězci, práce s časem a daty, podpora
vláken atd.) také podporu lokace, senzorů pohybu a náklonu, informací o operátorovi,
přístupu k událostem v kalendáři, iCloud, sociálních médií a připojení k síti. Níže budou
popsány některé zajímavé funkce Core Services.
2.3.1 Peer-to-Peer služby
Peer-to-Peer slouží k navázání připojení k blízkému zařízení pomocí Bluetooth nebo
společné Wi-Fi sítě. Většinou se této služby využívá v multiplayerových hrách.
2.3.2 Úložiště iCloud
Úložiště iCloud umožňuje ukládat uživatelovy dokumenty a data na centrální server
provozovaný společností Apple. Uživatel k nim poté může přistupovat a editovat je ze všech
svých zařízení a to bez nutnosti data explicitně synchronizovat nebo je znovu uploadovat.
Výhodou je také dostupnost okamžité zálohy v případě ztráty zařízení.
Existuje několik způsobů, jak využívat iCloud:
iCloud document storage
◦ Používá se pro ukládání uživatelových dokumentů a dat do uživatelova iCloud
účtu.
iCloud key-value data storage
◦ Používá se pro ukládání malého objemu dat, který sdílí všechny instance jedné
aplikace. Využitelné například jako záloha nastavení aplikace.
2.3.3 Blokové objekty
Blok je speciální druh konstrukce kódu, která má několik nejčastějších použití:
Jako náhrada za callback.
Jako náhrada z delegátů a delegátských metod.
K vykonávání asynchronních úloh.
Pro implementaci tzv. completion handleru
2.3.4 Ochrana dat
Ochrana dat umožňuje aplikaci označit některé vybrané soubory jako „chráněné“.
Tyto soubory poté iOS ukládá zašifrované. Pokud je zařízení uzamčeno, nemá k takto
ochráněným souborům přístup jak potenciální útočník, tak ani samotná aplikace. V okamžiku
odemknutí zařízení je vytvořen klíč pro dešifrování souborů a aplikace může chráněný soubor
opět bez problémů číst.
2.3.5 Sdílení souborů
Funkce sdílení souborů dovoluje přistupovat k uživatelským souborům, které ukládá
daná aplikace, prostřednictvím aplikace iTunes ve verzi 9.1 nebo vyšší. Uživatel poté může
přesouvat soubory ze/do složky dokumentů aplikace na zařízení. Tato funkce však
neumožňuje jakékoli sdílení souborů mezi dvěma aplikacemi jednoho zařízení.
2.3.6 Grand Central Dispatch (GCD)
Grand Central Dispatch je technologie sloužící pro optimalizaci chodu aplikací na
víceprocesorových zařízeních. Na platformě iOS se poprvé představila v jeho verzi 4.0.
2.3.7 In-App nákupy
In-App nákupy otevírají cestu k nákupům různého prémiového obsahu. Tímto
prémiovým obsahem může být například bonusový doplněk ve hře nebo předplatné novin.
In-App nákupy podporují následující modely pořizování prémiového obsahu:
Consumable products
◦ Jedná se o prémiový obsah, který se průběžně spotřebovává. Například nákup
hnojiva na virtuální farmu.
Non-consumable products
◦ Jedná se o prémiový obsah, který se nespotřebovává. Příkladem může být
například nová postava do hry.
Auto-renewable subscriptions
◦ Jedná se o předplatné prémiového obsahu, které je automaticky obnovováno.
Podobný model předplatného může mít třeba elektronická verze novin.
Non-renewable subscriptions
◦ Jedná se o podobný typ jako předchozí příklad. Rozdílem je, že předplatné není
automaticky obnovováno.
Free subscriptions
◦ Jedná se o předplatné prémiového obsahu, které je však zcela zdarma. Tento typ
předplatného, na rozdíl od předchozích dvou příkladů, nikdy nevyprší.
2.3.8 SQLite
Integrované SQLite dovoluje aplikacím využívat možností databáze bez toho, že by
bylo potřeba externího serveru. V iOS aplikaci je možné vytvořit lokální databázový soubor,
který bude touto aplikací možné také plně spravovat.
Databáze je navržena pro obecné použití, ale je stále velice dobře optimalizována pro
rychlé vyhledávání na výkonově omezeném mobilním zařízení.
2.3.9 Podpora XML
Foundation framework v sobě zahrnuje také třídu NSXMLParser, která pracuje jako
regulérní XML parser. Náročnější operace s XML daty je možné provádět pomocí knihovny
libxml2, která je také součástí iOS.
2.4. Vrstva Core OS
Vrstva Core OS zahrnuje nízkoúrovňové funkce, na kterých je vystaveno mnoho
dalších technologií a frameworků. Významné součásti této vrstvy jsou popsány
v následujících kapitolách.
2.4.1 Accelerate Framework
Accelerate Framework poskytuje rozličná rozhraní pro výpočty při zpracování
digitálních signálů, dále pro výpočty lineární algebry a pro výpočty při transformaci obrázků.
Oproti implementaci podobných funkcí vlastními silami má použití Accelerate Framework
výhodu v tom, že stejný kód může být velice efektivně vykonáván na různých zařízeních i se
zcela odlišnou hardwarovou konfigurací.
2.4.2 Core Bluetooth Framework
Core Blouetooth Framework obsahuje množinu rozhraní, která mohou být využita
převážně pro interakci s Bluetooth LE příslušenstvím. Tento framework umožňuje mimo jiné
následující činnosti:
Vyhledávání dostupných Bluetooth zařízení v dosahu a připojení k jednomu
vybranému.
Vytvoření periferie z iOS zařízení schopnou ovládat jiné Bluetooth zařízení.
Zasílání iBeacon z iOS zařízení.
Uchování stavu Bluetooth připojení tak, že muže být automaticky obnoveno v případě
nového spuštění aplikace.
Možnost automatické notifikace, která oznámí aplikaci, že je v dosahu Bluetooth
nějaké příslušenství.
2.4.3 External Accessory Framework
External Accessory Framewor poskytuje rozhraní pro komunikaci s příslušenstvím,
které je připojeno k iOS zařízení. Tento framework umožňuje získat informace o připojeném
příslušenství a případně s ním navázat komunikaci. Poté je již možné v aplikaci využívat
všechny funkce, které dané příslušenství nabízí.
2.4.4 Generic Security Services Framework
Generic Security Services Framework nabízí množinu rozhraní týkající se bezpečnosti.
Základní rozhraní jsou definována v RFC 2743 a RFC 4401. GSS Framework zahrnuje také
správu uživatelských přihlašovacích údajů, které sice nejsou zmíněnými standardy
specifikovány, ale jsou potřebné pro mnoho druhů aplikací.
2.4.5 Local Authentication Framework
Local Authentication framevork nabízí rozhraní, které umožňuje na podporovaných
zařízeních požádat o autentizaci uživatele prostřednictvím Touch ID, tedy za pomoci čtečky
otisků prstů integrované do zařízení. Tento framework neumožňuje získat samotný otisk prstu,
výsledkem autentizace je pouze pravdivostní hodnota, která vyjadřuje, zda se autentizace
zdařila nebo ne.
2.4.6 Network Extension Framework
Network Extensions Framework poskytuje rozhraní pro konfiguraci a kontrolu
připojení do tzv. Virtual Private Network (VPN).
2.4.7 Security Framework
Security Framework nabízí jako doplněk ke GGS Frameworku množinu rozhraní
týkající se zabezpečení dat, s nimiž aplikace pracuje. Tato rozhraní mají na starosti správu
certifikátů, veřejných a privátních klíčů a ověřování důvěryhodnosti. Dále nabízí podporu
generování kryptograficky bezpečných pseudonáhodných čísel, úložiště pro certifikáty,
privátní klíče a jiná citlivá data, které se v prostředí Apple označuje jako keychain. Security
Framework také poskytuje prostředky pro symetrické šifrování, autentizační zprávy typu
HMAC a tvorbu hashů.
2.4.8 System
System v sobě zahrnuje kernel, ovladače a nízkoúrovňová UNIX rozhraní. Kernel,
který je odvozen od mikrojádra Mach, je zodpovědný za všechny funkce požadované po operačním systému. Jedná se hlavně o následující:
Správa virtuální paměti
Správa vláken
Správa file systému
Správa síťových připojení
Správa a zajištění meziprocesové komunikace
Ovladače v této vrstvě zajišťují komunikaci mezi hardwarem a systémovými frameworky.
Z bezpečnostních důvodů je přístup k prostředkům kernelu a ovladačů povolen pouze
některým systémovým frameworkům a aplikacím.
iOS poskytuje mnoho rozhraní pro přístup k nízkoúrovňovým funkcím operačního
systému. Aplikace mohou tyto funkce využívat prostřednictvím knihovny LibSystem.
Zmiňovaná rozhraní jsou založena na jazyku C a přináší podporu pro následující:
POSIX vlákna a Grand Central Dispatch (GCD)
BSD sokety
Standardní I/O
Bonjour a DNS služby
Alokace paměti
Jazyková lokalizace a informace o ní
Matematické výpočty
2.4.9 Podpora 64 bitové HW architektury
Platforma iOS byl původně navrhován tak, aby podporoval binární soubory běžící
na zařízeních využívajících 32 bitovou architekturu. S příchodem iOS 7 byla představena
64 bitová architektura. Všechny systémové knihovny jsou tedy uzpůsobeny pro chod na 64
i 32 bitových architekturách. V případě kompilace kódu aplikace jako 64 bitového je možné
v některých aplikacích a pouze na některých zařízeních lépe využít hardwarové prostředky.
iOS používá model LP64, který umožňuje jednodušší portovatelnost kódu než ostatní modely
jako ILP64 nebo LLP64.
Návrh a implementace aplikace pro iOS
Tato kapitola bude pojednávat o iOS aplikaci FormApps Mobile, která slouží primárně
pro podporu elektronického podepisování webových formulářů společnosti Software602 a.s.,
přičemž obecně do těchto formulářů přináší další funkce a rozšiřuje tak možnosti použití
těchto formulářů.
Analýza problému
Formuláře Software602 jsou webové formuláře založené na moderních variantách
technologií HTML 5 a AJAX, které dále komunikují se serverovou stranou, později v textu
označovanou jako backend, případně pouze jako „server“, pokud to bude z kontextu
pochopitelné. Tyto webové formuláře mají převážně za úkol napomáhat v řízení
vnitrofiremních procesů, dále při opatřování dokumentů elektronickým podpisem a jejich
následné dlouhodobé archivaci.
Vzhledem k povaze formuláře je ve velké části případů možné jej vyplnit přímo
v jakémkoliv internetovém prohlížeči, a to dokonce i v jeho „mobilních“ ekvivalentech.
Přestože je již většina webových technologií velice sofistikovaná, jsou zde stále určité
činnosti, které se pomocí samostatného webového formuláře nedají vykonávat na všech
platformách bez problémů (nejvíce postižené jsou v tomto smyslu právě platformy mobilní).
Těmito činnostmi je myšleno například právě připojení elektronického podpisu, odeslaní dat
z backendu na jiný server (zvláště pokud je pro tento jiný server nutná autentizace, ať již
základní basic, nebo pomocí klientského certifikátu, NTLM) a konkrétně na platformě iOS je
to pro absenci uživatelsky přístupného file systému zrovna vkládání příloh do webových
formulářů. Tato chybějící funkčnost, která je pro celkový chod Software602 ekosystému
naprosto esenciální, byla hlavní motivací pro vytvoření mobilní aplikace, jež by měla tyto
nedostatky řešit.
Popis aplikace
Aplikace Software602 FormApps Mobile je mobilní aplikace pro platformy iOS,
Android a Windows Phone (zde budeme vždy uvažovat pouze aplikaci pro iOS), která dokáže
zcela plnohodnotně pracovat s výše zmíněnými webovými formuláři Software602. Doplňuje tedy standardní funkce webového prohlížeče o následující možnosti: podepsání (i vizuální)
lokálního PDF dokumentu, podepsání vzdáleného dokumentu na serveru, podepsání
vyplněného formuláře, časové razítkování lokálních PDF dokumentů, časové razítkování
vzdálených dokumentů na serveru, připojení vlastnoručního podpisu k lokálnímu PDF
dokumentu, přeposlání dat z backendu na jakýkoli jiný vzdálený server, který může
vyžadovat autentizaci (basic, klientským certifikátem, NTLM), vložení vyfocené fotografie
do formuláře, načtení dat z čárkového nebo QR kódu do formuláře, vkládání příloh
do formuláře, úložiště dokumentů včetně podpory Google Drive, generování certifikátu
s využitím SecuStamp CA, generování komerčních a kvalifikovaných (osobních
i systémových) certifikátů PostSignum.
V následujících kapitolách bude stručně vysvětleno, jak jsou vlastně jednotlivé funkce
implementovány. A to jak z pohledu koncového uživatele, tak z technologického pohledu.
Popis architektury aplikace FormApps Mobile pro iOS
Aplikace je z velké části napsaná v programovacím jazyce Objective-C++. Kód
aplikace, který přímo pracuje s knihovnami třetích stran, napsanými v čistém jazyce C, je také
psán v jazyce C, případně v jazyce C++. To je případ zejména práce s knihovnou OpenSSL,
jež zajišťuje kryptografické funkce a dále práce s knihovnou libjpeg, která má na starosti
transformaci JPEG obrázku při převodu obrázku do formátu PDF.
Základem celé aplikace je webový prohlížeč, který slouží k práci s webovými
formuláři. Toto „jádro“ je postaveno na systémové komponentě UIWebView. Ta má na
starosti vykreslování veškerých html stránek. Pro komunikaci ve směru webový formulář ->
aplikace je využita implementace vlastní metody:
- webView:shouldStartLoadWithRequest:navigationType:
definované protokolem UIWebViewDelegate. Veškeré požadavky na stažení elementu
webové stránky tedy procházejí touto funkcí. Pokud chce webový formulář nějakou
součinnost od aplikace, vytvoří požadavek na stažení elementu, který obsahuje přesně
definovaný řetězec. Tento řetězec se skládá z kontrolního řetězce oznamujícího aplikaci, že si
má ze serveru stáhnout požadavek k vykonání, a ze samotné URL, na které se nachází PKCS7
specifikující požadavek, který je potřeba vykonat. Tímto požadavkem se myslí například
podepsání formuláře, vložení přílohy do formuláře, vzdálené podepsání na serveru atd.
U každého staženého PKCS7 požadavku je před jeho případným vykonáním ověřeno, zda u něj nedošlo k porušení integrity a zda je podepsán správným certifikátem. Tím je významně
omezena míra potenciálního zneužití.
Výsledek vykonání požadavku je poté vrácen na server a webový formulář je o tom
obeznámen voláním jeho konkrétní javascriptové funkce. Toto volání se provádí pomocí
metody
- stringByEvaluatingJavaScriptFromString:
objektu třídy UIWebView, který zobrazuje právě zpracovávaný webový formulář.
Popis základních funkcí aplikace FormApps Mobile
FormApps Mobile nabízí veliké množství funkcí. Ze všech si však pro potřeby této
práce vyberu ty nejdůležitější a popíši je jak z pohledu běžného uživatele, tak technologicky.
Podepsání lokálního dokumentu
Aplikace FormApps Mobile je schopna v současné chvíli lokálně podepsat pouze
dokumenty typu PDF (pro podepisování ostatních dokumentů jako například *.docx, *.xlsx,
*pptx, *.odt je určena aplikace Software602 Signer). Podepsáním lokálního dokumentu je
myšleno připojení elektronického podpisu k PDF dokumentu, který se nachází v úložišti
aplikace FormApps Mobile, nebo který se nachází v úložišti Google Drive, asociované
s aplikací FormApps Mobile.
Vizuální podpis v dokumentu graficky znázorňuje, kdy a kdo daný dokument podepsal.
Uživatel je před samotným podpisem vyzván k vybrání obdélníkové části v dokumentu, kam
bude následně vizuální podpis umístěn.
Z technologického hlediska je využitím privátního klíče a jemu odpovídajícího
certifikátu vytvořen podepsaný dokument splňující normu PDF/A. Tento dokument může být
během podepsání opatřen také časovým razítkem. Vytvoření časového razítka je popsáno
v samostatném odstavci týkajícím se časových razítek.
Proces podepsání je z uživatelského hlediska krok za krokem znázorněn níže.
Obrázek 2: Dialog "Menu" s vybranou volbou "Podpis PDF", zdroj: Autor
Obrázek 3: Dialog výběru dokumentu, zdroj: Autor
Obrázek 4: Zobrazený UIImagePickerController po vybrání možnosti "Vyfotit
obrázek", zdroj: Autor
Obrázek 5: UIImagePickerController po pořízení fotografie, zdroj: Autor
Obrázek 6: Dialog pro nastavení kvality obrázku pro konverzi do formátu PDF,
zdroj: Autor
Obrázek 7: Náhled vytvořeného PDF dokumentu s možnostmi "Info", "Podpis" a "Vizuální
podpis", zdroj: Autor
Obrázek 8: Informace o výběru obdélníkové oblasti pro umístění vizuálního podpisu
zobrazená po zvolení volby "Vizuální podpis", zdroj: Autor
Obrázek 9: Po výběru oblasti pro umístění vizuálního podpisu, zdroj: Autor
Obrázek 10: Dialog pro vizuální podpis včetně již provedeného vlastnoručního
podpisu, zdroj: Autor
Obrázek 11: Výzva na zadání hesla pro přístup k privátnímu klíči, zdroj: Autor
Obrázek 12: Podepsání proběhlo úspěšně, zdroj: Autor
Obrázek 13: Detail vlastnoručního podpisu, zdroj: Autor
Obrázek 14: Informace o elektronickém podpisu, na který je navázán vizuální (v tomto
případě dokonce vlastnoruční) podpis, zdroj: Autor
Obrázek 15: Znázornění možností sdílení dokumentu, zdroj: Autor
Obrázek 16: Odeslání podepsaného dokumentu e-mailem, zdroj: Autor
Podepsání vzdáleného dokumentu
Aplikace FormApps Mobile dokáže vzdáleně podepsat jakýkoliv elektronický
dokument, který má pro to podporu na serveru. Toto vzdálené podepsání je možné vykonat
pouze ve spolupráci s webovým formulářem (který je napojen na backend). Webový formulář
si v reakci na uživatelovu akci, jako je například kliknutí na tlačítko, vyžádá po aplikaci
elektronický podpis určitých dat. Tato data mohou mít dva možné tvary:
První možností je, že data pro podepsání jsou již přímo hashem dané části dokumentu
(obecně je možné podepsat třeba pouze některé konkrétní části dokumentu, ne úplně celý).
Tento hash je v drtivé většině SHA1 nebo nějaký zástupce rodiny SHA2, tedy obvykle
SHA256. V případě, že data pro podepsání jsou již přímo hashem, dále se z nich hash nedělá
a jsou pouze pomocí šifrovacích algoritmů RSA nebo DSA podepsána. Jedná se tedy pouze
o „surový“ podpis, který není zabalen do žádné obálky typu PKCS7. Je však převeden do
formátu base64, zabalen do SOAP obálky a takto poslán webové službě na backendu.
Druhou možností je, že ze serveru přijde nějaký fragment dat. Z těchto dat je poté
potřeba vytvořit hash. Podporované hashovací funkce jsou SHA1 a všichni zástupci z rodiny SHA2. Vytvořený hash se poté podepíše buď pomocí RSA nebo DSA a opět jako
„surový“ podpis je převeden do formátu base64, zabalen do SOAP obálky a poslán webové
službě na backendu. Na serveru se poté „surový“ podpis připojí k dokumentu podle normy,
která je pro daný typ dokumentu specifická (PDF/A, XAdES, PAdES, CAdES, BES/EPES).
Podepsání se provádí uživatelovým privátním klíčem, který je spolu s odpovídajícím
certifikátem uložen v keychainu aplikace.
Podepsání vyplněného formuláře
Webový formulář jako takový podepsat nelze, protože se jedná o kombinaci HTML 5,
AJAXu a dalších elementů jako třeba obrázků. Lze však úspěšně podepsat xml, které vzniklo
transformací dat tohoto formuláře. Toto xml může být nejen elektronicky podepsáno tak, jak
je specifikováno normou XMLDSig, ale může být také dlouhodobě věrohodné, pokud se pro
podpis zvolí nějaká vyšší forma specifikace XAdES, například XAdES-A. Podepsání
webového formuláře probíhá tedy následovně: V prvním kroku převede backend data
z formuláře do odpovídajícího XML. Toto XML může být poté kdykoli backendem
převedeno zpět do webového formuláře. V druhém kroku je aplikaci FormApps Mobile
odeslána série hashu, které mají být podepsány. Ve třetím kroku jsou podepsané hashe (popis
podepsání hashů byl zmíněn výše) zaslány zpět na server. V posledním čtvrtém kroku jsou
podepsané hashe backendem vloženy do xml a je vytvořen dokument podle podle normy
XAdES. Její stupeň záleží na nastavení serveru a na jeho propojení s certifikační autoritou.
Časové razítkování lokálních dokumentů
Časové razítko je zjednodušeně řečeno elektronický podpis časového údaje
a samotného dokumentu. Tento elektronický podpis, včetně zmíněného časového údaje,
poskytuje konkrétní certifikační autorita. Časové razítko slouží jako důkaz toho, že daný
dokument v daném čase v dané podobě existoval. Důvěryhodnost časového razítka závisí
převážně na důvěryhodnosti zvolené certifikační autority a na samotném algoritmu
elektronického podpisu.
Časové razítko je v aplikaci FormApps Mobile možné lokálně připojit pouze
k dokumentům typu PDF. Technicky je připojení časového razítka prováděno následovně:
Pomocí OpenSSL je vytvořena žádost o časové razítko. Ta je poté převedena do formátu
base64, vložena do SOAP obálky a následně odeslána webové službě SecuStamp, která zde plní funkci certifikační autority. Po provedení basic autentizace, která může získat
přihlašovací údaje z nastavení v aplikaci, je žádost zpracována a do aplikace je vráceno
časové razítko. Toto časové razítko je poté spolu s elektronickým podpisem (časové razítko je
vázáno na podepsání dokumentu uživatelovým certifikátem) vloženo do PDF dokumentu.
Časové razítkování vzdálených dokumentů na serveru
Vzdálené připojení časového razítka je v aplikaci možné pro všechny typy dokumentů,
které na to mají podporu na straně serveru. Samotné časové razítkování probíhá následovně:
V prvním kroku si server vyžádá časové razítko pro hash, který předá aplikaci. V druhém
kroku aplikace získá časové razítko přesně tak, jak je uvedeno v předchozím odstavci.
Ve třetím kroku zasílá aplikace časové razítko zpět na server. V posledním kroku server
připojí časové razítko k dokumentu tak, jak je specifikováno v normě pro daný typ
dokumentu (PDF/A, XAdES-T, aj.).
Připojení vlastnoručního podpisu k lokálnímu dokumentu
Připojení vlastnoručního podpisu je možné opět pouze pro dokument typu PDF, a to
jen v případě, že je zvolen vizuální podpis. Vlastnoruční podpis je implementován pomocí
OpenGL a systémových prostředků detekujících polohu doteku prstu na zobrazovacím
zařízení. Vlastnoruční podpis je poté spolu s regulérním elektronickým podpisem umístěn
do dokumentu jako vizuální podpis. Z uživatelského pohledu je postup podepsání analogický
s podepsáním lokálního dokumentu PDF. Proces podepsání je graficky znázorněn v kapitole
„Podepsání lokálního dokumentu“.
Přeposlání dat z backendu na jakýkoli jiný vzdálený server
Přeposlání dat z backendu na jakýkoli jiný vzdálený server se využívá například při
potřebě odeslat data z formuláře do datové schránky. Technologicky není problém tato data
poslat z backendu přímo na daný server (v tomto případě do datové schránky), ale uživatel by
musel backendu svěřit své přístupové údaje, nebo dokonce svůj certifikát, který pro přístup do
datové schránky využívá. To by samozřejmě mohlo být bráno jako potenciální riziko zneužití.
Z tohoto důvodu jsou data z webového formuláře nejprve zasílána do aplikace FormApps
Mobile a poté jsou bez jakéhokoli čtení nebo uložení přeposílána na cílový server. Cílový server může vyžadovat autentizaci. V tuto chvíli jsou v aplikaci podporovány tři druhy
autentizace: basic, klientským certifikátem a NTLM. Veškerá komunikace probíhá
prostřednictvím zabezpečeného protokolu https.
Aplikace FormApps Mobile má možnost uložit až dvě kombinace přihlašovacího
jména a odpovídajícího hesla pro přístup do datové schránky. Pokud je má uživatel uloženy,
nemusí je již při posílání webového formuláře zadávat. Přihlašovací údaje jsou uchovávány v
keychainu aplikace.
Vyfocení fotografie do formuláře
Webový formulář si může jako přílohu vynutit mimo jiné i pořízení fotografie
fotoaparátem zařízení. Princip je analogický jako v případě vložení regulérní přílohy
z lokálního úložiště nebo z Google Drive. Vyfocenou fotografii je však také možné převést do
formátu PDF. Při této konverzi lze nastavit několik parametrů ovlivňujících výslednou kvalitu
a velikost jak samotného obrázku, tak samozřejmě i výsledného PDF. Jsou to: výsledná
velikost obrázku, výsledná kvalita obrázku, možnost převedení barevného obrázku do stupňů
šedi. Tyto transformace (tedy transformace nad obrázkem, ne samotnou transformaci obrázku
do PDF) provádí v aplikaci knihovna libjpeg.
Načtení 1D nebo 2D kódu do formuláře
Formulář může také požádat aplikaci o data, která jsou zakódována v 1D nebo
2D kódu. Načtení se provádí fotoaparátem zařízení. Aplikace v současné době plně podporuje
1D kódy ve specifikaci EAN-13 a 2D kódy ve specifikaci ISO/IEC 18004:2006.
Tato funkce je samozřejmě dostupná pouze na zařízeních, která mají k dispozici
fotoaparát (toto omezení se dotýká například zařízení iPad 1, které není vybaveno
fotoaparátem).
Vkládání příloh a úložiště dokumentů
Vzhledem k tomu, že iOS z principu nepodporuje „standardní“ filesystem, a tedy ani
práci se soubory ve svém mobilním prohlížeči Safari, bylo potřeba tuto funkčnost
implementovat ve FormApps Mobile. FormApps Mobile proto obsahuje prohlížeč souborů
a umožňuje jakýkoli soubor, ke kterému má přístup, vložit do webového formuláře, který tuto funkci podporuje. Lokální soubory jsou ukládány do lokálního úložiště aplikace, ke kterému
je přístup z aplikace iTunes.
Soubory v úložišti Google Drive jsou viditelné až po povolení a přihlášení do Google
Drive v nastavení aplikace. Autentizace ke Google Drive je prováděna pomocí OAuth2.
Vkládání příloh z technologického hlediska probíhá následovně: Nejprve si webový
formulář vyžádá vložení přílohy. V reakci na to se uživateli zobrazí dialog, umožňující vybrat
konkrétní soubor. Tento soubor je poté převeden do formátu base64, zabalen do SOAP obálky
a zaslán zpět na backend.
Prohlížeč souborů navíc také podporuje tzv. „long tap“ na jednotlivé soubory.
Po provedení „long tapu“ jsou uživateli k dispozici další možnosti práce s dokumenty, jako
například odeslání vybraného dokumentu pomocí e-mailu nebo jeho smazání.
Generování certifikátu s využitím SecuStamp CA
Aplikace FormApps Mobile umožňuje generování certifikátů prostřednictvím
certifikační autority SecuStamp CA. Technologicky je celý proces následovný: v prvním
kroku je pomocí OpenSSL vygenerována dvojice privátní-veřejný klíč. Ve druhém kroku je
vytvořena PKCS10 žádost o certifikát, která je podepsána právě tímto privátním klíčem.
PKCS10 žádost je poté převedena do formátu base64, zabalena do SOAP obálky a poslána
webové službě SecuStamp. Webová služba po zpracování požadavku vystaví certifikát
a pošle jej zpět do aplikace. Aplikace se zeptá na heslo pro uložení privátního klíče. SHA256
hashem z tohoto hesla zašifruje privátní klíč pomocí AES 256 v módu OFB a spolu se
získaným certifikátem jej uloží do keichainu aplikace.
Generování komerčních a kvalifikovaných (osobních i systémových)
certifikátů PostSignum.
Aplikace FormApps Mobile umožňuje také generování certifikátů od certifikační
autority PostSignum. A to nejen komerčních, ale dokonce také kvalifikovaných. Postup
generování certifikátů PostSignum je následovný: V prvním kroku je pomocí OpenSSL
vygenerována dvojice privátní-veřejný klíč. Ve druhém kroku je vytvořena PKCS10 žádost
o certifikát. Tato žádost je převedena do base64 formátu, vložena do SOAP obálky a odeslána
na server PostSignum. Ten v případě úspěchu vrací ID žádosti. Toto ID žádosti se v aplikaci
interně spáruje s privátním klíčem a s SHA1 hashem veřejného klíče (často také nazývaného SKID). S tímto ID žádosti je potřeba se osobně dostavit na pobočku České pošty. Zde po
zkontrolování totožnosti pracovníkem pošty nastaví tento v systému příznak, že certifikát je
možné vydat. Po replikaci záznamů v databázi PostSignum, trvající nejdéle 3 minuty od
schválení požadavku o certifikát, je již možné certifikát pomocí aplikace vyzvednout.
Vyzvednutí samotné probíhá následovně: Aplikace při každém svém spuštění a při
každém zobrazení dialogu „PostSignum“ kontaktuje server PostSignum a zjišťuje, zda je již
připraven ke stažení certifikát, ke kterému je v aplikaci odpovídající SKID. Aplikace tedy
pošle na server PostSignum seznam všech SKID, které má k dispozici. Počet
„čekajících“ certifikátů a tedy celkový seznam SKID není nijak aplikačně omezen. Pokud byl
některý SKID serverem vyhodnocen jako „připravený“, zasílá server zpět aplikaci již přímo
vydaný certifikát. Aplikace se poté uživatele zeptá na heslo pro privátní klíč a poté jej spolu
s přijatým certifikátem uloží naprosto shodným způsobem, jako v případě generování
certifikátu prostřednictvím SecuStamp CA.
Libovolnou „čekající“ žádost může uživatel kdykoliv vymazat pomocí tlačítka
„Editovat“ a následně pomocí „smazat“. To je zobrazeno v následujících obrázcích č. 17 a 18.
Obrázek 17: Dialog "PostSignum" se seznamem žádostí o certifikát, které čekají na
vyřízení, zdroj: Autor
Podepsání vzdáleného dokumentu
Aplikace FormApps Mobile dokáže vzdáleně podepsat jakýkoliv elektronický
dokument, který má pro to podporu na serveru. Toto vzdálené podepsání je možné vykonat
pouze ve spolupráci s webovým formulářem (který je napojen na backend). Webový formulář
si v reakci na uživatelovu akci, jako je například kliknutí na tlačítko, vyžádá po aplikaci
elektronický podpis určitých dat. Tato data mohou mít dva možné tvary:
První možností je, že data pro podepsání jsou již přímo hashem dané části dokumentu
(obecně je možné podepsat třeba pouze některé konkrétní části dokumentu, ne úplně celý).
Tento hash je v drtivé většině SHA1 nebo nějaký zástupce rodiny SHA2, tedy obvykle
SHA256. V případě, že data pro podepsání jsou již přímo hashem, dále se z nich hash nedělá
a jsou pouze pomocí šifrovacích algoritmů RSA nebo DSA podepsána. Jedná se tedy pouze
o „surový“ podpis, který není zabalen do žádné obálky typu PKCS7. Je však převeden do
formátu base64, zabalen do SOAP obálky a takto poslán webové službě na backendu.
Druhou možností je, že ze serveru přijde nějaký fragment dat. Z těchto dat je poté
potřeba vytvořit hash. Podporované hashovací funkce jsou SHA1 a všichni zástupci z rodiny SHA2. Vytvořený hash se poté podepíše buď pomocí RSA nebo DSA a opět jako
„surový“ podpis je převeden do formátu base64, zabalen do SOAP obálky a poslán webové
službě na backendu. Na serveru se poté „surový“ podpis připojí k dokumentu podle normy,
která je pro daný typ dokumentu specifická (PDF/A, XAdES, PAdES, CAdES, BES/EPES).
Podepsání se provádí uživatelovým privátním klíčem, který je spolu s odpovídajícím
certifikátem uložen v keychainu aplikace.
Podepsání vyplněného formuláře
Webový formulář jako takový podepsat nelze, protože se jedná o kombinaci HTML 5,
AJAXu a dalších elementů jako třeba obrázků. Lze však úspěšně podepsat xml, které vzniklo
transformací dat tohoto formuláře. Toto xml může být nejen elektronicky podepsáno tak, jak
je specifikováno normou XMLDSig, ale může být také dlouhodobě věrohodné, pokud se pro
podpis zvolí nějaká vyšší forma specifikace XAdES, například XAdES-A. Podepsání
webového formuláře probíhá tedy následovně: V prvním kroku převede backend data
z formuláře do odpovídajícího XML. Toto XML může být poté kdykoli backendem
převedeno zpět do webového formuláře. V druhém kroku je aplikaci FormApps Mobile
odeslána série hashu, které mají být podepsány. Ve třetím kroku jsou podepsané hashe (popis
podepsání hashů byl zmíněn výše) zaslány zpět na server. V posledním čtvrtém kroku jsou
podepsané hashe backendem vloženy do xml a je vytvořen dokument podle podle normy
XAdES. Její stupeň záleží na nastavení serveru a na jeho propojení s certifikační autoritou.
Časové razítkování lokálních dokumentů
Časové razítko je zjednodušeně řečeno elektronický podpis časového údaje
a samotného dokumentu. Tento elektronický podpis, včetně zmíněného časového údaje,
poskytuje konkrétní certifikační autorita. Časové razítko slouží jako důkaz toho, že daný
dokument v daném čase v dané podobě existoval. Důvěryhodnost časového razítka závisí
převážně na důvěryhodnosti zvolené certifikační autority a na samotném algoritmu
elektronického podpisu.
Časové razítko je v aplikaci FormApps Mobile možné lokálně připojit pouze
k dokumentům typu PDF. Technicky je připojení časového razítka prováděno následovně:
Pomocí OpenSSL je vytvořena žádost o časové razítko. Ta je poté převedena do formátu
base64, vložena do SOAP obálky a následně odeslána webové službě SecuStamp, která zde plní funkci certifikační autority. Po provedení basic autentizace, která může získat
přihlašovací údaje z nastavení v aplikaci, je žádost zpracována a do aplikace je vráceno
časové razítko. Toto časové razítko je poté spolu s elektronickým podpisem (časové razítko je
vázáno na podepsání dokumentu uživatelovým certifikátem) vloženo do PDF dokumentu.
Časové razítkování vzdálených dokumentů na serveru
Vzdálené připojení časového razítka je v aplikaci možné pro všechny typy dokumentů,
které na to mají podporu na straně serveru. Samotné časové razítkování probíhá následovně:
V prvním kroku si server vyžádá časové razítko pro hash, který předá aplikaci. V druhém
kroku aplikace získá časové razítko přesně tak, jak je uvedeno v předchozím odstavci.
Ve třetím kroku zasílá aplikace časové razítko zpět na server. V posledním kroku server
připojí časové razítko k dokumentu tak, jak je specifikováno v normě pro daný typ
dokumentu (PDF/A, XAdES-T, aj.).
Připojení vlastnoručního podpisu k lokálnímu dokumentu
Připojení vlastnoručního podpisu je možné opět pouze pro dokument typu PDF, a to
jen v případě, že je zvolen vizuální podpis. Vlastnoruční podpis je implementován pomocí
OpenGL a systémových prostředků detekujících polohu doteku prstu na zobrazovacím
zařízení. Vlastnoruční podpis je poté spolu s regulérním elektronickým podpisem umístěn
do dokumentu jako vizuální podpis. Z uživatelského pohledu je postup podepsání analogický
s podepsáním lokálního dokumentu PDF. Proces podepsání je graficky znázorněn v kapitole
„Podepsání lokálního dokumentu“.
Přeposlání dat z backendu na jakýkoli jiný vzdálený server
Přeposlání dat z backendu na jakýkoli jiný vzdálený server se využívá například při
potřebě odeslat data z formuláře do datové schránky. Technologicky není problém tato data
poslat z backendu přímo na daný server (v tomto případě do datové schránky), ale uživatel by
musel backendu svěřit své přístupové údaje, nebo dokonce svůj certifikát, který pro přístup do
datové schránky využívá. To by samozřejmě mohlo být bráno jako potenciální riziko zneužití.
Z tohoto důvodu jsou data z webového formuláře nejprve zasílána do aplikace FormApps
Mobile a poté jsou bez jakéhokoli čtení nebo uložení přeposílána na cílový server. Cílový server může vyžadovat autentizaci. V tuto chvíli jsou v aplikaci podporovány tři druhy
autentizace: basic, klientským certifikátem a NTLM. Veškerá komunikace probíhá
prostřednictvím zabezpečeného protokolu https.
Aplikace FormApps Mobile má možnost uložit až dvě kombinace přihlašovacího
jména a odpovídajícího hesla pro přístup do datové schránky. Pokud je má uživatel uloženy,
nemusí je již při posílání webového formuláře zadávat. Přihlašovací údaje jsou uchovávány v
keychainu aplikace.
Vyfocení fotografie do formuláře
Webový formulář si může jako přílohu vynutit mimo jiné i pořízení fotografie
fotoaparátem zařízení. Princip je analogický jako v případě vložení regulérní přílohy
z lokálního úložiště nebo z Google Drive. Vyfocenou fotografii je však také možné převést do
formátu PDF. Při této konverzi lze nastavit několik parametrů ovlivňujících výslednou kvalitu
a velikost jak samotného obrázku, tak samozřejmě i výsledného PDF. Jsou to: výsledná
velikost obrázku, výsledná kvalita obrázku, možnost převedení barevného obrázku do stupňů
šedi. Tyto transformace (tedy transformace nad obrázkem, ne samotnou transformaci obrázku
do PDF) provádí v aplikaci knihovna libjpeg.
Načtení 1D nebo 2D kódu do formuláře
Formulář může také požádat aplikaci o data, která jsou zakódována v 1D nebo
2D kódu. Načtení se provádí fotoaparátem zařízení. Aplikace v současné době plně podporuje
1D kódy ve specifikaci EAN-13 a 2D kódy ve specifikaci ISO/IEC 18004:2006.
Tato funkce je samozřejmě dostupná pouze na zařízeních, která mají k dispozici
fotoaparát (toto omezení se dotýká například zařízení iPad 1, které není vybaveno
fotoaparátem).
Vkládání příloh a úložiště dokumentů
Vzhledem k tomu, že iOS z principu nepodporuje „standardní“ filesystem, a tedy ani
práci se soubory ve svém mobilním prohlížeči Safari, bylo potřeba tuto funkčnost
implementovat ve FormApps Mobile. FormApps Mobile proto obsahuje prohlížeč souborů
a umožňuje jakýkoli soubor, ke kterému má přístup, vložit do webového formuláře, který tuto funkci podporuje. Lokální soubory jsou ukládány do lokálního úložiště aplikace, ke kterému
je přístup z aplikace iTunes.
Soubory v úložišti Google Drive jsou viditelné až po povolení a přihlášení do Google
Drive v nastavení aplikace. Autentizace ke Google Drive je prováděna pomocí OAuth2.
Vkládání příloh z technologického hlediska probíhá následovně: Nejprve si webový
formulář vyžádá vložení přílohy. V reakci na to se uživateli zobrazí dialog, umožňující vybrat
konkrétní soubor. Tento soubor je poté převeden do formátu base64, zabalen do SOAP obálky
a zaslán zpět na backend.
Prohlížeč souborů navíc také podporuje tzv. „long tap“ na jednotlivé soubory.
Po provedení „long tapu“ jsou uživateli k dispozici další možnosti práce s dokumenty, jako
například odeslání vybraného dokumentu pomocí e-mailu nebo jeho smazání.
Generování certifikátu s využitím SecuStamp CA
Aplikace FormApps Mobile umožňuje generování certifikátů prostřednictvím
certifikační autority SecuStamp CA. Technologicky je celý proces následovný: v prvním
kroku je pomocí OpenSSL vygenerována dvojice privátní-veřejný klíč. Ve druhém kroku je
vytvořena PKCS10 žádost o certifikát, která je podepsána právě tímto privátním klíčem.
PKCS10 žádost je poté převedena do formátu base64, zabalena do SOAP obálky a poslána
webové službě SecuStamp. Webová služba po zpracování požadavku vystaví certifikát
a pošle jej zpět do aplikace. Aplikace se zeptá na heslo pro uložení privátního klíče. SHA256
hashem z tohoto hesla zašifruje privátní klíč pomocí AES 256 v módu OFB a spolu se
získaným certifikátem jej uloží do keichainu aplikace.
Generování komerčních a kvalifikovaných (osobních i systémových)
certifikátů PostSignum.
Aplikace FormApps Mobile umožňuje také generování certifikátů od certifikační
autority PostSignum. A to nejen komerčních, ale dokonce také kvalifikovaných. Postup
generování certifikátů PostSignum je následovný: V prvním kroku je pomocí OpenSSL
vygenerována dvojice privátní-veřejný klíč. Ve druhém kroku je vytvořena PKCS10 žádost
o certifikát. Tato žádost je převedena do base64 formátu, vložena do SOAP obálky a odeslána
na server PostSignum. Ten v případě úspěchu vrací ID žádosti. Toto ID žádosti se v aplikaci
interně spáruje s privátním klíčem a s SHA1 hashem veřejného klíče (často také nazývaného SKID). S tímto ID žádosti je potřeba se osobně dostavit na pobočku České pošty. Zde po
zkontrolování totožnosti pracovníkem pošty nastaví tento v systému příznak, že certifikát je
možné vydat. Po replikaci záznamů v databázi PostSignum, trvající nejdéle 3 minuty od
schválení požadavku o certifikát, je již možné certifikát pomocí aplikace vyzvednout.
Vyzvednutí samotné probíhá následovně: Aplikace při každém svém spuštění a při
každém zobrazení dialogu „PostSignum“ kontaktuje server PostSignum a zjišťuje, zda je již
připraven ke stažení certifikát, ke kterému je v aplikaci odpovídající SKID. Aplikace tedy
pošle na server PostSignum seznam všech SKID, které má k dispozici. Počet
„čekajících“ certifikátů a tedy celkový seznam SKID není nijak aplikačně omezen. Pokud byl
některý SKID serverem vyhodnocen jako „připravený“, zasílá server zpět aplikaci již přímo
vydaný certifikát. Aplikace se poté uživatele zeptá na heslo pro privátní klíč a poté jej spolu
s přijatým certifikátem uloží naprosto shodným způsobem, jako v případě generování
certifikátu prostřednictvím SecuStamp CA.
Libovolnou „čekající“ žádost může uživatel kdykoliv vymazat pomocí tlačítka
„Editovat“ a následně pomocí „smazat“. To je zobrazeno v následujících obrázcích č. 17 a 18.
Obrázek 17: Dialog "PostSignum" se seznamem žádostí o certifikát, které čekají na
vyřízení, zdroj: Autor