Univerza v Ljubljani
Fakulteta za raˇ
cunalniˇ
stvo in informatiko
Klemen Staniˇc
Varnostna razˇ
siritev vtiˇ
cnika za
ogrodje Ionic
DIPLOMSKO DELO
VISOKOˇSOLSKI STROKOVNI ˇSTUDIJSKI PROGRAM PRVE STOPNJE
RA ˇCUNALNIˇSTVO IN INFORMATIKA
Mentor
: izr. prof. dr. Mojca Ciglariˇ
c
Somentor
: dr. Duˇsan Gabrijelˇ
ciˇ
c
koriˇsˇcenje rezultatov diplomske naloge je potrebno pisno privoljenje avtorja, Fakultete za raˇcunalniˇstvo in informatiko ter mentorja.
Fakulteta za raˇcunalniˇstvo in informatiko izdaja naslednjo nalogo:
Tematika naloge:
Pripravite pregled ogrodij za razvoj hibridnih mobilnih aplikacij. Preverite moˇznosti overjanja uporabnika in nato na izbranem ogrodju poiˇsˇcite najboljˇsi naˇcin za izvedbo overjanja uporabnika z digitalnimi potrdili. Overjanje tudi implementirajte in testirajte najprej z namensko testno aplikacijo, nato pa tudi z realno mobilno aplikacijo.
Zahvaljujem se somentorju dr. Duˇsanu Gabrijelˇciˇc skupaj z odsekom E5 -Laboratorij za odprte sisteme in mreˇze na Inˇstitutu Joˇzef Stefan ter mentorici izr. prof. dr. Mojci Ciglariˇc za strokovno pomoˇc pri izdelavi diplomske naloge. Prijateljem in druˇzini se zahvaljujem za vso podporo ob ˇstudiju.
Kazalo
Povzetek Abstract 1 Uvod 1 2 Pregled 3 2.1 Mobilne platforme . . . 3 2.2 Ogrodja za razvoj hibridnih aplikacij . . . 5 2.3 TLS . . . 10 2.4 Vtiˇcnik”cordova-plugin-advanced-http“ . . . 16
3 Naˇcrt izdelave 25
3.1 Zahteve in naˇcrt dela . . . 25 3.2 Naˇcrt ovrednotenja . . . 27
4 Izvedba 29
4.1 Postopek delovanja vtiˇcnika ob overjanju uporabnika z upo-rabnikovim digitalnim potrdilom . . . 31 4.2 Razhroˇsˇcevanje . . . 36
5 Ovrednotenje 37
5.1 Testiranje na testni mobilni aplikaciji . . . 37 5.2 Testiranje z uporabo vtiˇcnika v mobilni aplikaciji za pregled
Seznam uporabljenih kratic
kratica angleˇsko slovensko API Application Programming
In-terface
Aplikacijski programski vme-snik
CA Certificate Authority Certifikatska agencija
CLI Command Line Interface Vmesnik ukazne vrstice
HTTP Hypertext Transfer Protocol Protokol za prenos hiperbese-dila
HTTPS HTTP Secure Varni HTTP
IDE Integrated Development Envi-ornment
Integrirano razvojno okolje
IoT Internet Of Things Internet stvari
JSON JavaScript Object Notation JavaScript zapis objektov
MAC Message Authentication Code Koda za overjanje sporoˇcila
MITM Man In The Middle attack Napad z vmesnim ˇclenom
NPM Node Packet Manager Upravljalnik NodeJS paketov
REST Representational State Trans-fer
Predstavitveni prenos stanja
SDK Software Development Kit Orodje za razvoj programske opreme
SSL Secure Sockets Layer Varna povezovalna plast
TLS Transport Layer Security Varnost na transportni plasti
URL Uniform Resource Locator Enoliˇcni naslov vira
Povzetek
Naslov: Varnostna razˇsiritev vtiˇcnika za ogrodje Ionic
Avtor: Klemen Staniˇc
Uporaba ogrodij za razvoj hibridnih mobilnih aplikacij zaradi preprostosti ter hitrosti razvoja hitro naraˇsˇca. Problem se pojavi, ko ogrodje, ki smo ga izbrali za razvoj aplikacije, ne omogoˇca vseh potrebnih funkcionalno-sti. Ogrodje Ionic tako ne omogoˇca vzpostavitve HTTPS povezave, kjer bi streˇznik overil uporabnika z uporabo uporabnikovega digitalnega potrdila. Na tak naˇcin bi lahko streˇznik uporabniku dodelil doloˇcene pravice dostopa. V okviru diplomskega dela to funkcionalnost dodamo ˇze obstojeˇcemu vtiˇcniku za ogrodje Ionic. Vtiˇcnik nato ovrednotimo z uporabo v testni mobilni apli-kaciji ter mobilni apliapli-kaciji, namenjeni prikazu porabe elektriˇcne energije v gospodinjstvu.
Kljuˇcne besede: Ionic, hibriden razvoj aplikacij, pametni telefon, mobilna aplikacija, vtiˇcnik, TLS, uporabnikovo digitalno potrdilo, overjanje.
Abstract
Title: Ionic Plugin Security Extension
Author: Klemen Staniˇc
Hybrid mobile application frameworks are becoming more and more popu-lar, due to how simple and fast it is to develop a mobile application that will work on multiple platforms. Sometimes, these frameworks don’t provide all the functionality that native application development does. Ionic framework doesn’t provide a way to establish an HTTPS connection with client authen-tication. In this thesis, we add an option to use client authentication to an Ionic plugin. We evaluate the plugin by using it in a test application. We also use the plugin in a real-life smart mobile application, that is used for presenting the electric consumption of a specific household, and evaluate it that way also.
Keywords: Ionic, hybrid app development, smartphone, mobile app, plug-in, TLS, client certificate, authentication.
Poglavje 1
Uvod
ˇ
Zivljenje brez pametnih telefonov si dandanes teˇzko predstavljamo. V zaˇcetku so bili mobilni telefoni namenjeni le klicanju ter pisanju sporoˇcil, vendar so s ˇcasom postali pravi mali prenosni raˇcunalniki. Uporabljamo jih lahko kot fotoaparat oziroma kamera, na njih lahko brskamo po spletu, igramo igre, nameˇsˇcamo in uporabljamo aplikacije, gledamo veˇcpredstavnostne vsebine ter podobno. Z vedno veˇcjim ˇstevilom uporabnikov mobilnih telefonov se veˇca tudi potreba po novih aplikacijah. Trg aplikacij je ogromen, veliko pro-gramerjev ˇzivi le od izdelovanja in vzdrˇzevanja aplikacij. Tako je za Android mobilno platformo na Google Play trgovini na voljo veˇc kot 3.3 milijone apli-kacij, za platformo iOS pa veˇc kot 2.2 milijona aplikacij [38]. Poleg Android in iOS platform so na trgu prisotne ˇse ostale platforme, kot so Windows Phone, Windows 10, Blackberry, vendar imajo v primerjavi z vodilnima platformama veliko manjˇse ˇstevilo aktivnih uporabnikov. Tako razvijalci mobilnih aplika-cij veˇcinoma razvijajo za Android in iOS platformi.
Poleg platformno-specifiˇcnih orodij za razvoj aplikacij obstajajo tudi ogrodja za izdelavo hibridnih aplikacij. Najpopularnejˇsa so React Native, Ionic, Framework 7, PhoneGap, Onsen UI ter ostala [1]. Ta so veliko-krat uporabljena tudi pri razvoju aplikacij, namenjenih le eni platformi, saj omogoˇcajo hitrejˇsi razvoj kot platformno-specifiˇcna orodja (Android Studio, Xcode, itd). Predvsem aplikacije, ki imajo velik poudarek na uporabniˇski
izkuˇsnji, lahko hitreje razvijemo z uporabo hibridnih ogrodij. Doloˇceni gra-dniki uporabniˇskega vmesnika so ˇze vnaprej definirani, in jih tako samo vsta-vimo v naˇso aplikacijo.
S poveˇcevanjem ˇstevila pametnih naprav se poveˇcuje tudi potreba po varni in zaupni povezavi med razliˇcnimi napravami ter storitvami. Informa-cije, ki se prenaˇsajo med napravami, so namreˇc velikokrat zaupne narave ter lahko vsebujejo uporabnikove osebne podatke. Tako moramo kot naˇcrtovalci programske opreme zagotoviti doloˇceno stopnjo varnosti in zaupnosti. Da je povezava med dvema ˇclenoma v IoT sistemu ˇsifrirana in zaupna, upo-rabljamo protokole, ki zagotavljajo varen prenos podatkov. Tako naprimer namesto navadne povezave HTTP uporabimo povezavo HTTPS, ki temelji na protokolu SSL/TLS.
Ob razvoju aplikacije, ki je namenjena pregledu elektriˇcne porabe gospo-dinjstva smo naleteli na teˇzavo. Namreˇc ogrodje Ionic, ki smo ga upora-bljali pri razvoju, ne omogoˇca vzpostavitve povezave HTTPS z uporabo od-jemalˇcevega digitalnega potrdila (ang. client certificate). Ta funkcionalnost je bila za delovanje obvezna. Namreˇc streˇznik s podatki o porabi elektriˇcne energije od uporabnika zahteva, da se predstavi s svojim digitalnim potrdi-lom. Tako streˇznik overi odjemalca in mu priredi doloˇcene pravice dostopa ter mu omogoˇci vzpostavitev varne povezave.
Zato smo sklenili, da v okviru diplomskega dela manjkajoˇco funkcional-nost ogrodju Ionic dodamo sami. Funkcionalfunkcional-nost smo dodali obstojeˇcemu vtiˇcniku (ang. plugin), ki je namenjen ogrodju Apache Cordova [9], ter po-slediˇcno tudi ogrodju Ionic [13]. Da smo lahko delovanje vtiˇcnika testirali, smo morali postaviti ˇse testni spletni streˇznik, ki omogoˇca veˇc naˇcinov pove-zovanja. Vtiˇcnik smo ovrednotili z uporabo na testni mobilni aplikaciji ter na mobilni aplikaciji, namenjeni prikazu elektriˇcne porabe gospodinjstva.
Poglavje 2
Pregled
Za boljˇse razumevanje, kaj smo v sklopu diplomske naloge naredili, bomo naj-prej opisali vsa orodja, protokole, ogrodja ter storitve, ki smo jih pri razvoju uporabljali. Najprej bomo opisali mobilni platformi, nato pa ˇse ogrodja za razvoj hibridnih mobilnih aplikacij. Opisali bomo tudi povezavo SSL/TLS, kako se le-ta vzpostavi ter predstavili nekaj terminologije iz tega podroˇcja. Na koncu poglavja bomo opisali ˇse Ionic vtiˇcnik
” cordova-plugin-advanced-http“, ki smo ga v sklopu te diplomske naloge razˇsirili.
2.1
Mobilne platforme
Razvijalci mobilnih aplikacij veˇcinoma razvijajo aplikacije za platformi An-droid in iOS. Aplikacije morajo biti zanimive, uporabne, hitre, privlaˇcne ter varne. Vsaka izmed platform mora omogoˇcati hiter, preprost ter poceni razvoj aplikacij. ˇCe ˇzelimo aplikacijo narediti dostopno tako Android kot iOS platformi, moramo bodisi razviti dve aplikaciji, torej za vsako platformo napiˇsemo celotno aplikacijo, ali pa uporabimo eno izmed ogrodij za izdelova-nje hibridnih aplikacij.
2.1.1
Android
Android [Slika 2.1] je mobilni operacijski sistem, ki ga je razvil Android Inc. Kasneje, leta 2005 ga je odkupil Google. Prva komercialno dostopna Android naprava je na trg priˇsla leta 2005. Osnovan je na Linux jedru [33] ter ostali odprtokodni programski opremi. Namenjen je predvsem mobilnim napravam z zaslonom na dotik, kot so pametni telefoni in tablice. Prav tako je nameˇsˇcen na velikem ˇstevilu igralnih konzol, digitalnih kamerah, televizijah ter pametnih urah. Je najbolj popularen mobilni operacijski sistem, saj ima trenutno 70% uporabnikov mobilnih naprav Android operacijski sistem, kar predstavlja veˇc kot 2 milijardi meseˇcno aktivnih uporabnikov [2, 38].
Za razvoj Android aplikacij programerji najpogosteje uporabljajo pro-stodostopno orodje Android Studio [6] oziroma Eclipse [10]. Uporabniˇske vmesnike definiramo z uporabo XML shem [3], samo logiko aplikacije pa piˇsemo v programskem jeziku Java [14]. Od oktobra 2017 pa je poleg Jave uradno podprt tudi programski jezik Kotlin [32].
Diplomska naloga 5
2.1.2
iOS
IOS [Slika 2.2] je mobilni operacijski system, ki ga je zasnoval in razvil Apple Inc. [8]. Prva naprava s tem operacijskim sistemom je bil iPhone, ki je s prodajo zaˇcel leta 2007. Je namenjen le mobilnim napravam, ki jih proizvaja Apple in je trenutno drugi najbolj popularen mobilni operacijski sistem, takoj za Android platformo. Aplikacije za iOS so na voljo na App Store, kjer je trenutno veˇc kot 2.2 milijona aplikacij [38, 31].
Za razvoj iOS aplikacij razvijalci veˇcinoma uporabljajo IDE XCode [23], ki ga je razvil Apple in je uradno okolje. Aplikacije so napisane v program-skem jeziku Swift [46] ali pa Objective-C [39]. Za definicijo uporabniˇskih vmesnikov se prav tako kot pri Androidu uporabljajo sheme XML [3].
Slika 2.2: Ikona operacijskega sistema iOS
2.2
Ogrodja za razvoj hibridnih aplikacij
ˇ
Ce razvijamo aplikacijo, namenjeno veˇcim platformam, oziroma je pri naˇsi aplikaciji poudarek bolj na uporabniˇski izkuˇsnji, lahko uporabimo eno izmed ogrodij za razvoj hibridnih aplikacij. Te omogoˇcajo hkratni razvoj aplikacij, ki bodo delovale na veˇc platformah. Tako nam uporabniˇskih vmesnikov ter delovanja aplikacije ni potrebno implementirati za vsako platformo posebej. Aplikacijo napiˇsemo bodisi s spletnimi tehnologijami, bodisi z enim za to namenjenim programskim jezikom. Taka aplikacija se nato v okviru ogrodja
prevede v platformno-specifiˇcne aplikacije.
Pri izbiri ustreznega ogrodja za razvoj hibridnih aplikacij imamo veliko izbire. Pri sprejemanju odloˇcitve moramo upoˇstevati kakˇsne vrste aplikacijo ˇzelimo razviti ter kaj nam je pri razvoju najbolj pomembno.
Ob pregledu, katere naˇcine vzpostavitve povezave HTTPS razliˇcna ogrodja omogoˇcajo, smo ugotovili, da trenutno nobeno ogrodje ne omogoˇca uporabe uporabnikovega digitalnega potrdila pri vzpostavitvi seje TLS. Pri veˇcini je dodajanje te funkcionalnosti v planu oziroma moˇzno le na nivoju domoro-dnega (ang. native) razvoja, vendar tega nihˇce ˇse ni implementiral. Med spo-dnje naˇstetimi ogrodji je Ionic najbolj popularna izbira, zato smo se odloˇcili, da to funkcionalnost dodamo temu ogrodju.
Trenutno so najbolj priljubljena in v uporabi naslednja ogrodja [1]:
2.2.1
React Native [20]
Ogrodje omogoˇca razvoj hibridnih aplikacij z uporabo JavaScript program-skega jezika ter React.js [21] knjiˇznice. Razvil ga je Facebook, je odprtokoden ter omogoˇca hiter razvoj aplikacij, ki so istega izgleda kot domorodne (ang.
native) aplikacije. Ponuja veliko vtiˇcnikov, aplikacije narejene s tem ogrod-jem so hitre in zelo odzivne. Ponuja veliko ˇstevilo ˇze narejenih komponent, kar pospeˇsi razvoj aplikacij.
2.2.2
PhoneGap [17]
Je odprtokodno ogrodje, ki omogoˇca preprost razvoj hibridnih aplikacij s pomoˇcjo spletnih tehnologij (CSS, HTML, JavaScript). Ponuja storitev ime-novano
”Build“, ki razvijalcu omogoˇca testiranje aplikacije na veˇcih platfor-mah, brez namestitve SDK-jev za vse platforme. ˇZal aplikacije razvite s tem ogrodjem niso najbolj hitre ter odzivne, vendar je ogrodje ˇse vedno primerno za razvoj preprostih mobilnih aplikacij.
Diplomska naloga 7
2.2.3
Framework 7 [12]
Prednost ogrodja Framework 7 je, da za razliko od drugih hibridnih ogro-dij ne uporablja nobenih zunanjih storitev, kot sta Angular.js [7] in React.js [21]. Aplikacije razvijamo s pomoˇcjo spletnih tehnologij (CSS, HTML, Ja-vaScript), kar predstavlja relativno laˇzji razvoj aplikacije. Je odprtokoden, aplikacije razvite s tem ogrodjem pa so odzivne ter hitre. Ima veliko ˇstevilo ˇze narejenih komponent uporabniˇskega vmesnika, ki jih lahko kar vstavimo v naˇso aplikacijo in tako hitro razvijemo moderno ter elegantno aplikacijo.
2.2.4
Xamarin [22]
Ogrodje je izˇslo leta 2011 ter je podprto s strani ene najveˇcjih tehnoloˇskih podjetij na svetu, t.j. Microsoft. Mobilne aplikacije, ki so razvite z ogrodjem Xamarin so po izgledu, zmogljivosti ter uˇcinkovitosti podobne domorodnim (ang. native) aplikacijam. Delovanje aplikacije definiramo z Microsoftovim programskim jezikom .NET [24]. Razvijamo lahko aplikacije namenjene An-droid, iOS ter Windows platformi.
Diplomska naloga 9
Slika 2.4: Shema delovanja Ionic in Cordova ogrodij
ske sisteme. Poleg mobilnih aplikacij pa lahko aplikacijo naredimo tudi za sodobne spletne brskalnike.
Trenutna verzija Ionic ogrodja je
”Ionic Framework 3“. Omogoˇca izdelo-vanje aplikacij za Android naprave z operacijskim sistemom razliˇcice 4.1 ter viˇsjimi, iOS 7 oziroma viˇsje in naprave z Windows 10 operacijskim sistemom ter tudi za BlackBerry 10 telefone.
2.3
TLS
TLS [48] je kriptografski protokol, ki omogoˇca komunikacijsko varnost v omreˇzju. Pred TLS-jem je bil v uporabi SSL, ki pa je sedaj zastarel in se ga ne uporablja veˇc. Protokol TLS je uporabljen za komunikacijo v odjemalec-streˇznik aplikacijah kot je brskanje po spletu, elektronska poˇsta, telefonija prek IP ter v ostalih aplikacijah, kjer morajo podatki, ki se prenaˇsajo po omreˇzju ostati zaupni ter nespremenjeni. Prepreˇcuje prisluˇskovanje ter spre-minjanje podatkov. Deluje nad protokolom TCP in ustvari varen kanal za prenos podatkov [42].
TLS protokol stremi k zagotavljanju zasebnosti in celovitost podatkov, ki se prenaˇsajo med dvema ˇclenoma v omreˇzju. ˇCe je komunikacija zaˇsˇcitena z uporabo TLS, velja [48]:
• Povezava je varna/zasebna, saj je za ˇsifriranje podatkov uporabljena si-metriˇcna kriptografija [47]. Kljuˇc, ki je potreben za vzpostavitev take povezave je za vsako povezavo unikaten in temeljij na skupni skrivno-sti, za katero se dogovorita obe strani komunikacije ob zaˇcetku seje. Odjemalec ter streˇznik se odloˇcita kakˇsen ˇsifrirni algoritem ter kljuˇc bo uporabljen, preden pride do prenosa podatkov,
• ker TLS uporablja ˇsifriranje z javnim kljuˇcem (ang. public key cryp-tography [44]), lahko overimo obe strani komunikacije, tako odjemalca kot streˇznik. Overjanje ni obvezno, vendar je v sploˇsnem potrebno vsaj s strani odjemalca. Odjemalec se mora prepriˇcati, da je streˇznik res ti-sti, za katerega se izdaja. Tako prepreˇcimo napade MITM [34], kjer odjemalec podatke poˇsilja napadalcu, namesto streˇzniku,
• povezava je zanesljiva, saj se ob vsakem poslanem sporoˇcilu preveri tudi celovitost sporoˇcila (ang. message integrity check) z uporabo MAC [36]. To zagotavlja, da podatki med prenosom niso bili spremenjeni ter da ni priˇslo do izgube podatkov.
Diplomska naloga 11
Povezava TLS se vzpostavi z naslednjim zaporedjem sporoˇcil, prikazanih na diagramu [Slika 2.5]. Temu postopku pravimo rokovanje (ang. handshake). Diagram prikazuje zaporedje akcij pri zaˇcetnem delu vzpostavitve povezave TLS, t.j. v postopku rokovanja, kot je opisan v [43]. Znak * je zapisan ob sporoˇcilih/razˇsiritvah, ki ob TLS rokovanju niso nujno potrebni, ampak jih uporabljamo pri naprednejˇsih naˇcinih vzpostavitve TLS povezave.
V sploˇsnem se faza rokovanja opravi v treh fazah:
1. Izmenjava kljuˇcev (ang. key exchange): Odjemalec in streˇznik si iz-menjata kljuˇc in izbereta kriptografske parametre. Po tej fazi je ves promet ˇsifriran,
2. streˇzniˇski parametri (ang. server parameters): Obe strani povezave si izmenjata ˇse ostale parametre rokovanja (ali je odjemalec overjen, podpora protokolov aplikacijske plasti, itd.),
3. overjanje (ang. authentication): Pride do overjanja streˇznika (ter odje-malca, ˇce je to zahtevano) ter potrdi se ustreznost kljuˇca in celovitost rokovanja.
Za generiranje kljuˇcev seje za varno povezavo odjemalec izbira med dvema moˇznostima:
• S pomoˇcjo streˇzniˇskega javnega kljuˇca ˇsifrira nakljuˇcno ˇstevilo, ter re-zultat poˇslje streˇzniku, ki lahko rezultat deˇsifrira s pomoˇcjo svojega zasebnega kljuˇca. Obe strani povezave uporabita to nakljuˇcno ˇstevilo za ˇsifriranje in deˇsifriranje vseh nadaljnih podatkov,
• uporabi Diffie-Hellman [25] izmenjavo kljuˇcev za varno generiranje na-kljuˇcnega in unikatnega kljuˇca seje za ˇsifriranje ter deˇsifriranje podakov v nadaljnji izmenjavi podatkov. Taka povezava ima ˇse dodatno la-stnost, t.j. vnaprejˇsnja tajnost (ang. forward secracy) [40]. ˇCetudi bi bil streˇznikov zasebni kljuˇc kdaj razkrit, kljuˇcev prejˇsnjih sej ni mogoˇce razkriti in tako podatki, preneseni v prejˇsnjih sejah ostanejo varni. To
doseˇzemo tako, da za vsako novo sejo generiramo nov unikatni kljuˇc seje. Client Server Key ^ ClientHello Exch | + key_share* | + signature_algorithms* | + psk_key_exchange_modes* v + pre_shared_key* ---> ServerHello ^ Key + key_share* | Exch + pre_shared_key* v {EncryptedExtensions} ^ Server {CertificateRequest*} v Params =================== {Certificate*} ^ {CertificateVerify*} | Auth {Finished} v <--- [Application Data*] +=======================+ ^ | {Certificate*} | Auth | | {CertificateVerify*} | | +=======================+ v {Finished} --->
[Application Data] <---> [Application Data]
Diplomska naloga 13
2.3.1
Digitalna potrdila
Za overjanje obeh ˇclenov povezave, tako streˇznika kot odjemalca, upora-bljamo digitalna potrdila. Digitalno potrdilo [29] ali potrdilo javnega kljuˇca je elektronski dokument, ki ga uporabljamo za dokazovanje lastnika javnega kljuˇca. Vsebuje informacije o kljuˇcu, informacije o lastniku kljuˇca ter digi-talni podpis izdajatelja, ki jamˇci legitimnost vsebine digitalnega potrdila. ˇCe je podpis veljaven, ter program, ki preverja digitalno potrdilo, zaupa izdaja-telju, ki je izdal potrdilo, se lahko digitalno potrdilo uporabi pri vzpostavlja-nju varne povezave TLS. Obiˇcajno je izdajalec digitalnih potrdil certifikatska agencija – CA, ki svojim strankam podpisuje potrdila v zameno za plaˇcilo.
Brskalniki hranijo seznam globalnih korenskih potrdil, ki jim zaupajo. Ob dostopu do spletne strani, ki ima omogoˇcen HTTPS protokol, zahtevajo njeno digitalno potrdilo. Ko le-to prejmejo, preverijo, ali je bilo podpisano s strani katerega korenskega CA oziroma enega od vmesnih CA na poti overjanja. Pot overjanja je sestavljena iz ene korenske CA, ter niˇc ali veˇc nivojev CA-jev [42].
2.3.2
Overjanje uporabnika z uporabo uporabnikovega
digitalnega potrdila
Obiˇcajno je pri rokovanju ob vzpostavitvi povezave TLS zahtevano le over-janje streˇznika. Protokol TLS pa omogoˇca tudi overjanje odjemalca. V primeru, ko recimo ˇzelimo doloˇcenim odjemalcem na strani streˇznika omejiti pravice dostopa, ˇzelimo uporabnika overiti. ˇCe nam uporabniˇsko ime in ge-slo ne zadoˇsˇcata, uporabimo overjanje z uporabo uporabnikovega digitalnega potrdila. TLS rokovanje se izvede po postopku, prikazanemu na shemi [Slika 2.5]. Sporoˇcila, pomembna za overitev uporabnika so podˇcrtana oziroma obkroˇzena.
Streˇznik poˇslje sporoˇcilo
”CertificateRequest“ odjemalcu. Odjemalec od-govori s sporoˇcilom
”CertificateVerify“. Le-to je niz, podpisan z zasebnim kljuˇcem odjemalca, povezan z digitalnim potrdilom, ki ga odjemalec poˇslje
streˇzniku. Streˇznik preveri legitimnost digitalnega potrdila ter skladnost sporoˇcila
”CertificateVerify“, ter v primeru, da je vse v redu, odjemalcu omogoˇci vzpostavitev varne povezave.
Overjanje odjemalca vedno zahteva streˇznik. Mehanizma v okviru pro-tokola TLS, ki bi odjemalcu omogoˇcal, da streˇzniku ponudi svoje digitalno potrdilo, ni [42].
2.3.3
SSL pripenjanje digitalnih potrdil
Da se povezava TLS lahko vzpostavi, je potrebno zaupanje. Ob TLS rokova-nju streˇznik odjemalcu poˇslje svoje digitalno potrdilo. Odjemalec preveri, ali je digitalno potrdilo izdala certifikatska agencija, ki ji operacijski sistem na napravi odjemalca zaupa (je v seznamu korenskih CA). Pri razvoju aplikacij (najveˇckrat mobilnih) kot dodatno varnostno zagotovilo uporabljamo SSL pripenjanje. Aplikaciji priloˇzimo streˇzniˇsko digitalno potrdilo (ali veˇc). Ob vsaki vzpostavitvi nove povezave TLS aplikacije s streˇznikom dodatno preve-rimo, da je digitalno potrdilo, ki ga je poslal streˇznik identiˇcno digitalnemu potrdilu, ki je bilo
”pripeto“ aplikaciji. S tem povezavo ˇse dodatno zaˇsˇcitimo pred napadi MITM [34], kjer napadelec prestrega (ter mogoˇce spreminja) sporoˇcila med dvema ˇclenoma povezave.
SSL pripenjanja [28] sicer ne moremo uporabiti v vsaki aplikaciji, vendar je uporaba priporoˇcjiva, kjer je to moˇzno. Poskrbeti moramo tudi za peri-odiˇcno posodabljanje
”pripetega“ digitalnega potrdila, saj le-temu s ˇcasom preteˇce veljavnost.
2.3.4
Veriga overjanja oz. pot overjanja (ang.
certifi-cate chain
/
certification path
)
Naprava (odjemalec), ki preverja veljavnost digitalnega potrdila ima shranjen seznam korenskih CA, ki jim zaupa. Vsa digitalna potrdila niso podpisana s strani korenskih CA, ampak so jih podpisala druge vmesne CA. Vmesne CA imajo pooblastilo, da lahko podpisujejo digitalna potrdila ostalim entitetam,
Diplomska naloga 15
ter njihovo istovetnost in legitimnost jamˇci CA nad njo. Pot overjanja je tako seznam vseh vmesnih CA, od konˇcne CA do korenske CA. Na sliki [Slika 2.6] je prikazano kako izgleda hiearhija digitalnih potrdil z globino 2. Pot overjanja bi tako vsebovala konˇcno digitalno potrdilo, vmesno digitalno potrdilo ter korensko digitalno potrdilo.
Slika 2.6: Primer hiearhije poti overjanja
Primer: na spletnem streˇzniku, ki uporablja HTTPS protokol in ima di-gitalno potrdilo podpisano s strani enega izmed vmesnih CA moramo pri konfiguraciji streˇznika dodati ˇse pot overjanja. Ta vsebuje konˇcno digitalno potrdilo streˇznika, digitalno potrdilo vmesne CA ter korensko digitalno potr-dilo. V primeru, da poti overjanja na streˇzniku ne dodamo, je pot zaupanja prekinjena in naˇsemu streˇzniku uporabnik ne bo zaupal [42].
2.3.5
Samo-podpisana digitalna potrdila
Digitalna potrdila niso vedno nujno podpisana s strani zaupanja vredne CA. Digitalno potrdilo lahko podpiˇsemo tudi sami, vendar takega potrdila ni priporoˇcljivo uporabljati v omreˇzju, ki je dostopno tudi drugim. Takˇsna po-trdila veˇcinoma uporabljamo le pri razvoju ter testiranju novih aplikacij, da nam ni potrebno plaˇcati certifikatski agenciji za podpis digitalnega potrdila. Naprave takim digitalnim potrdilom ne zaupajo (saj v cerifikatski poti ne zaupajo nobenemu), zato moramo za vzpostavitev zaupanja poskrbeti sami [45].
2.4
Vtiˇ
cnik
”
cordova-plugin-advanced-http“
Vtiˇcnik [30] je namenjen ogrodju Cordova ter poslediˇcno tudi ogrodju Ionic. Doda moˇznost vzpostavitve povezave HTTP ter HTTPS za platformi An-droid ter iOS. Na voljo je na Github platformi [26] ter v NPM upravljalniku paketov [37].
Ionic/Cordova vtiˇcnik deluje kot vmesnik med operacijskim sistemom ter aplikacijo. Z Ionic aplikacije ne moremo neposredno dostopati do funkcio-nalnosti, kot so kamera, internetni dostop, senzorji ter ostalo. Zato moramo naˇsi Ionic aplikaciji dodati vtiˇcnik. V sploˇsnem je vtiˇcnik je sestavljen iz veˇc delov:
• Programske kode v programskem jeziku JavaScript, ki definira vmesnik med vtiˇcnikom ter ogrodjem. Tukaj so definirane metode, ki jih lahko kliˇcemo iz ogrodja Ionic/Cordova, vtiˇcnik pa bo nato klical ustrezno kodo glede na platformo, za katero izdelujemo aplikacijo,
• programske kode v programskem jeziku Java, ki sluˇzi implementaciji funkcionalnosti na platformi Android,
• programske kode v programskem jeziku Objective-C, ki sluˇzi imple-mentaciji funkcionalnosti na platformi iOS,
• raznih konfiguracijskih datotek, ki definirajo delovanje vtiˇcnika (npr. plugin.xml, kjer definiramo platformno-specifiˇcno konfiguracijo, kakˇsne pravice potrebuje vtiˇcnik za delovanje itd.).
Vtiˇcnik omogoˇca naslednje metode, ki jih lahko kliˇcemo iz ogrodja Ionic, ter tako upravljamo z delovanjem vtiˇcnika:
• getBasicAuthHeader(username, password): vrne glavo HTTP/HTTPS pri uporabi overjanja z uporabniˇskim imenom in geslom (ang. header), • useBasicAuth(username, password): omogoˇci overjanje z uporabniˇskim
Diplomska naloga 17
• getHeaders(host): vrne HTTP/HTTPS glavo za doloˇceno ime gostitelja (ang. hostname),
• setHeader(host, header, value): nastavi glavo (ang. header) za vse nadaljne zahtevke HTTP/HTTPS,
• getDataSerializer(): vrne ime serializatorja za pretvorbo podatkov, • setDataSerializer(serializer): nastavi, v kakˇsnem formatu bodo podatki
v telesu zahtevka pri vseh nadaljnih POST in PUT zahtevkih,
• setCookie(url, cookie): nastavi piˇskotke, • clearCookies(): zbriˇse vse piˇskotke,
• removeCookies(url, cb): zbriˇse piˇskotke za doloˇcen URL, • getCookieString(url): vrne niz za piˇskotke za doloˇcen URL,
• getRequestTimeout(): vrne, koliko ˇcasa vtiˇcnik ˇcaka na povezavo, pre-den je le-ta terminirana,
• setRequestTimeout(timeout): nastavi koliko ˇcasa vtiˇcnik ˇcaka na po-vezavo, preden je le-ta terminirana,
• setSSLCertMode(mode): spremeni nastavitve povezave SSL/TLS. Na voljo imamo veˇc naˇcinov:
– default: privzeto upravljanje povezave SSL/TLS, z uporabo sis-temskih CA,
– nocheck: onemogoˇcimo preverjanje digitalnih potrdil, namenjeno le za namene testiranja,
– pinned: naprava zaupa pripetim digitalnim potrdilom.
• disableRedirect(disable): onemogoˇci avtomatsko preusmerjanje sple-tnih strani,
• post(url, body, headers): vrne rezultat zahtevka POST na doloˇcen url,
• get(url, parameters, headers) : vrne rezultat zahtevka GET na doloˇcen url,
• put(url, body, headers) : vrne rezultat zahtevka PUT na doloˇcen url,
• patch(url, body, headers) : vrne rezultat zahtevka PATCH na doloˇcen url,
• delete(url, parameters, headers) : vrne rezultat zahtevka DELETE na doloˇcen url,
• head(url, parameters, headers) : vrne rezultat zahtevka HEAD na doloˇcen url,
• uploadFile(url, body, headers, filePath, name) : vrne rezultat zahtevka UPLOADFILE na doloˇcen url,
• downloadFile(url, body, headers, filePath) : vrne rezultat zahtevka DOWNLOADFILE na doloˇcen url.
Diplomska naloga 19
Vtiˇcnik lahko naˇsemu projektu dodamo na dva naˇcina, glede na to, ali je vtiˇcnik na voljo v upravljalniku paketov NPM ali ne:
• Ce je vtiˇˇ cnik na voljo prek NPMja, lahko uporabimo naslednji ukaz kjerkoli v datoteˇcni strukturi naˇsega Ionic projekta:
ionic cordova plugin add << ime vtiˇcnika >>
Ko je vtiˇcnik enkrat nameˇsˇcen, ga iz ogrodja Ionic uporabljamo na naslednji naˇcin:
1 import{ HTTP} from ’@ionic−native/http’; 2 constructor(private http: HTTP){} 3 4 ... 5 6 this.http.get(’http://ionic.io’,{}, {}) 7 .then(data =>{ 8 console.log(data.status);
9 console.log(data.data); // data received by server 10 console.log(data.headers);
11 })
12 .catch(error =>{
13 console.log(error.status);
14 console.log(error.error); // error message as string 15 console.log(error.headers);
16 });
• V nasprotnem primeru, ko recimo uporabljamo svoj vtiˇcnik, oziroma smo sami spremenili ˇze obstojeˇc vtiˇcnik, le tega Ionic projektu dodamo s spodnjim ukazom:
ionic cordova plugin add << pot do vtiˇcnika na disku >> Iz Ionic ogrodja ga uporabljamo na nekoliko drugaˇcen naˇcin, in sicer:
1 cordova.plugin.http.get(”http://ionic.io”,{},{}, function(ret){
2 console.log(”returned data: ”, ret); 3 }, function(err){
4 console.log(”error: ”, err); 5 });
V obeh zgornjih primerih naredimo GET zahtevek na spletno stran
”http://ionic.io“, ter rezultat zahtevka zapiˇsemo v konzolo. V primeru, da je spletna stran vrnila odgovor s kodo 200, se v konzolo izpiˇse vsebina spletne strani, v nasprotnem primeru pa sporoˇcilo napake.
V prvem primeru uporabljamo obljube (ang. promises), kjer odgovor pridobimo s pomoˇcjo metod then, oziroma v primeru napake pa uporabimo metodo catch. V drugem primeru pa uporabljamo povratne klice (ang. call-back), ki so v JavaScript svetu uporabljeni pri asinhronih klicih1.
Vtiˇcnik
”cordova-plugin-advanced-http“ je precej obseˇzen, saj je ˇze samo za platform Android veˇc kot 15 datotek z kodo, ter pribliˇzno 4500 vrstic kode. Zato bom strukturo vtiˇcnika ter zaporedje akcij poenostavljeno prikazal kar na primeru.
ˇ
Zelimo izvesti HTTP GET zahtevek na doloˇceno spletno stran na plat-formi Android. Pri tem ne ˇzelimo, da bi nas spletna stran preusmerila na kakˇsno drugo [Slika 2.7]:
1. Vtiˇcnik dodamo naˇsemu Ionic projektu (opisano zgoraj),
2. Iz Ionic projekta kliˇcemo metodo disableRedirect(true). Vtiˇcnik pre-veri katero metodo ˇzelimo uporabiti, ter glede na navodila v datoteki
”advanced-http.js“ izvede del kode, glede na to, za katero platformo izdelujemo aplikacijo. V naˇsem primeru kliˇce Javin razred CordovaHt-tpPlugin ter na njem metodo disableRedirect(true),
1 // datoteka advanced−http.js
2 disableRedirect: function (disable, success, failure){
3 return exec(success, failure, ’CordovaHttpPlugin’, ’disableRedirect’, [ !!disable ]); 4 },
3. CordovaHttpPlugin je Javin razred, ki deluje kot vmesnik med Java-Script ter Java kodo. V naˇsem primeru na razredu CordovaHttp kliˇce
1Asinhroni klic (ang. asynchronous call je klic metode, ki za izvedbo potrebuje veˇc
ˇ
casa. Asinhroni klic se izvede v ozadju, ter tako ne blokira glavnega programa ter vrne rezultat, ko dokonˇca z delom. Npr. asinhroni klici se uporabljajo pri prenaˇsanju podatkov s streˇznika.
Diplomska naloga 21
metodo disableRedirect(true). Ta metoda na razredu CordovaHttp na-stavi statiˇcno spremenljivkodisableRedirect natrue. Ker je ta spremen-ljivka po tipu statiˇcna, pomeni da bodo isto vrednost te spremenljivke imeli tudi vsi objekti, ki bodo generirani iz tega razreda. Nastavitev, da ne sledimo avtomatskim preusmeritvam spletnih strani je sedaj na-stavljena.
1 // datoteka CordovaHttp.java
2 public static void disableRedirect(boolean disable){
3 disableRedirect.set(disable);
4 }
4. Iz Ionic ogrodja kliˇcemo ˇse metodoget, na enak naˇcin kot je prikazano zgoraj. Znova vtiˇcnik uporabi datoteko advanced-http.js ter izvede klic na metodo razreda CordovaHttpPlugin, ki ustvari nov objekt Cor-dovaHttpGet.
1 //datoteka CordovaHttpPlugin.java 2 }else if (action.equals(”get”)) {
3 String urlString = args.getString(0); 4 Object params = args.get(1);
5 JSONObject headers = args.getJSONObject(2); 6 int timeoutInMilliseconds = args.getInt(3)∗1000;
7 CordovaHttpGet get = new CordovaHttpGet(urlString, params, headers, 8 timeoutInMilliseconds, callbackContext); 9
10 cordova.getThreadPool().execute(get); 11 }
CordovaHttpGet razˇsirja razred CordovaHttp, na katerem smo prej na-stavili spremenljivko disableRedirect na true. Tako ima ta spremen-ljivka isto vrednost tudi v novo generiranem objektu razreda Cordo-vaHttpGet. Ob nastanku tega objekta se ustvari ˇse nov objekt Ht-tpRequest, v katerem konˇcno pride do HTTP klica na URL. Pri tem se upoˇstevajo vse nastavitve, ki smo jih nastavili na razreduCordovaHttp, saj so se podedovale vsem nadaljnjim objektom. Odgovor streˇznika se
vrne po isti poti nazaj do ogrodja Ionic s pomoˇcjo povratnih klicev (ang. callback).
Tak modularen naˇcin implementacije omogoˇca boljˇso preglednost kode. Vtiˇcnik je narejen tako, da na osrednjem razredu CordovaHttp nastavljamo statiˇcne spremenljivke, ki so potem podedovane vseh objektom razreda. Do-bra stran tega je, da lahko npr. nastavimo uporabo svojih piˇskotkov, ter bodo ti uporabljeni pri vseh nadalnjih spletnih zahtevkih. Slaba stran pa je, da se mora za vsak nov zahtevek ustvariti nov objekt, kar pa je lahko zamudno. Pri klicih z HTTP protokolom to ne predstavlja velikega problema.
ˇ
Ce pa ˇzelimo uporabiti varnejˇso povezavo HTTPS, se ob vsakem novem zahtevku HTTPS vzpostavi nov SSL kontekst1. ˇCe bi moral operacijski
sis-tem naprave za vsak nov zahtevek HTTPS vzpostaviti novo povezavo TLS s streˇznikom, bi to za to porabilo (pre)veliko ˇcasa. Operacijski sistem sam predvidi, da bo ista povezava TLS ˇse uporabljena v prihodnosti, zato po-vezave ne zapre takoj po prejetem odgovoru streˇznika. Tako se kljub temu, da se z vsakim novim klicem ustvari nov SSL kontekst1, znova uporabi
po-vezava TLS. Tako se zaporedni zahtevki HTTPS na isti streˇznik opravijo v sprejemljivem ˇcasu.
1SSL kontekst (ang. SSL Context) je razred programskega jezika Java, ki hrani vse
Diplomska naloga 23
Poglavje 3
Naˇ
crt izdelave
3.1
Zahteve in naˇ
crt dela
Cilj diplomske naloge je, da vtiˇcniku dodamo moˇznost povezovanja tudi s streˇzniki, ki zahtevajo, da se uporabnik overi z uporabo uporabnikovega di-gitalnega potrdila (ang. client certificate authentication). Ne osredotoˇcamo se na to, kako uporabnik pridobi digitalno potrdilo. Predpostavljamo, da ima le tega shranjenega v notranjem pomnilniku svoje naprave. Prav tako moramo originalni vtiˇcnik ohraniti karseda sploˇsen, da ga tako lahko uporabi ˇcimveˇcje ˇstevilo razvijalcev in omogoˇca preprosto dodajanje funkcionalnosti. Vtiˇcnik ˇze ima moˇznost uporabe SSL pripenjanja (ang. SSL pinning). Tak naˇcin delovanja iz Ionic projekta omogoˇcimo z klicem metode setSSL-CertMode(”pinned”). Vtiˇcnik nato ta digitalna potrdila (lahko jih je veˇc) prebere iz specifiˇcne mape www/certificates v Ionic projektu, kamor jih po-stavi razvijalec aplikacije. Da bi ohranil sploˇsnost ter dal razvijalcu veˇc moˇznosti pri uporabi vtiˇcnika, smo se odloˇcili, da za vklop uporabe uporab-nikovega digitalnega potrdila (ang. client certificate), ne uporabimo metode
setSSLCertMode. Dodali bomo svojo metodo z imenomenableClientCert, ki kot argumente dobi:
• 1. argument: boolean spremenljivka enable. ˇCe ima vrednost true, se omogoˇci uporaba uporabnikovega digitalnega potrdila, v nasprotnem
pa se ta funkcionalnost onemogoˇci,
• 2. argument: boolean spremenljivka selfSigned. V primeru da upora-bljamo samo-podpisano digitalno potrdilo, ki mu naprava ne zaupa, ob klicu metode drugi argument postavimo natrue. Do enakega delovanja pridemo, ˇce poleg metode setSSLCertMode kliˇcemo tudi metodo setS-SLCertMode z argumentom nocheck. Tak naˇcin je v primeru uporabe v produkciji slab, saj napravi omogoˇcimo, da zaupa vsem digitalnim potrdilom, kar pa ni varno. To opcijo uporabljamo samo v namene testiranja aplikacije,
• 3. argument: niz
”password“. Vtiˇcnik pri omogoˇceni uporabi upo-rabnikovega digitalnega potrdila priˇcakuje, da sta v mapi www/asset-s/clientCertificate v Ionic projektu dve datoteki. Prva je uporabnikovo digitalno potrdilo, shranjeno kot shramba kljuˇcev (ang. keystore) s konˇcnico .p12. Druga datoteka je pot overjanja, shranjena v formatu .pem. Uporabnikovo digitalno potrdilo, v formatu .p12, je mnogokrat zavarovano z geslom, zato sem razvijalcu aplikacije omogoˇcil vpis tega gesla. V primeru da uporabnikovo digitalno potrdilo ni zavarovano z geslom, lahko kot 3. argument vpiˇse kar prazen niz.
Metodo enableClientCert lahko kliˇcemo neodvisno od metode setSSL-CertMode. Tako se lahko razvijalec sam odloˇci kaj bo uporabljal pri dostopu do streˇznika. Omogoˇci lahko bodisi le SSL pripenjanje, bodisi le uporabo uporabnikovega digitalnega potrdila, lahko pa tudi uporablja oboje, ter tako ˇse dodatno ojaˇca varnost in zaupnost povezave med napravo in streˇznikom. Seveda mora v takem primeru tudi streˇznik omogoˇcati takˇsno vrsto povezave.
Diplomska naloga 27
V primeru, da bo ˇzelel razvijalec uporabiti overjanje uporabnika z digi-talnim potrdilom, bo iz Ionic ogrodja to moˇznost vklopil na naslednji naˇcin:
1 cordova.plugin.http.enableClientCert(true, true, ”niz z geslom”, function(ret){
2 console.log(”success”, ret); 3 }, function(fail){
4 console.log(”fail”, fail); 5 });
Vsi nadaljni zahtevki bodo tako uporabljali tudi overjanje uporabnika, ˇce pri vklopu te funkcionalnosti ne bo priˇslo do nobene napake. Vzpostaviti bomo morali tudi testni streˇznik. Ta bo moral omogoˇcati povezavi HTTP ter HT-TPS. Prav tako bo moral imeti moˇznost overjanja uporabnika z uporabni-kovim digitalnim potrdilom. Streˇznik bomo uporabili za testiranje delovanja vtiˇcnika.
3.2
Naˇ
crt ovrednotenja
Delovanje vtiˇcnika bomo preverili z razvojem testne aplikacije, kjer bomo merili ˇcas, ki ga vtiˇcnik potrebuje pri zahtevkih HTTP ter HTTPS. Hitrost vtiˇcnika bomo primerjali z Pythonovo knjiˇznico Requests [19]. Podali bomo ugotovitve ter se poskuˇsali opredeliti ali je takˇsna hitrost ustrezna za uporabo v pravi aplikaciji. Uporabnost vtiˇcnika bomo testirali z uporabo vtiˇcnika v pravi mobilni aplikaciji, namenjeni prikazu podatkov o elektriˇcni porabi gospodinjstva uporabnika.
Poglavje 4
Izvedba
Najprej smo vzpostavili testni streˇznik. Pri tem smo uporabili Pythonovo knjiˇznico Flask [11]. Streˇznik ima 3 naˇcine delovanja:
• kot navaden HTTP streˇznik • kot HTTPS streˇznik
• kot HTTPS streˇznik, ki uporabnika overi z uporabo uporabnikovega digitalnega potrdila
Za generiranje digitalnih potrdil smo uporabili odprtokodno knjiˇznico OpenSSL [16]. Vsa digitalna potrdila so samo-podpisana, zato smo morali za upravljanje zaupanja poskrbeti sami.
Ko smo vzpostavili streˇznik, smo zaˇceli z delom na vtiˇcniku. Vtiˇcnik je precej obseˇzen in ponuja veliko funkcionalnosti. Preden smo mu lahko karkoli dodajali, smo se morali najprej spoznati s tem, kako je vtiˇcnik zasnovan, kaj ponuja ter kako se ga uporablja. Z Ionic ogrodjem smo naredili preprosto testno aplikacijo, ter vanjo vstavili vtiˇcnik. Poskuˇsali smo dostopati do po-datkov na testnem streˇzniku, uporabiti tako HTTP kot HTTPS povezavo, preveriti hitrost delovanja ter omogoˇciti SSL pripenjanje. Preizkusili smo tudi veˇc vrst zahtevkov (get, post, download, itd.) ter se najbolj osredotoˇcil na dele vtiˇcnika, povezane z vzpostavljanjem povezave HTTPS. Testirali smo na fiziˇcni Android napravi.
Ko smo dobro razumeli, kaj vtiˇcnik ponuja, smo zaˇceli z dopolnjevanjem vtiˇcnika, da bo omogoˇcal tudi uporabo povezave HTTPS, ki poleg prever-janja streˇznika s strani naprave, preveri tudi napravo na strani streˇznika z uporabo uporabnikovega digitalnega potrdila. Ker je bilo kode v vtiˇcniku enostavno preveˇc, ter je bila preveˇc razkropljena, veliko izkuˇsenj s takˇsnim delom pa nismo imeli, smo uporabo uporabnikovega digitalnega potrdila naj-prej testirali v testni aplikaciji. Tako smo z integriranim razvojnim okoljem Android Studio razvili aplikacijo, kjer smo se z uporabo uporabnikovega di-gitalnega potrdila poskuˇsali povezati s testnim streˇznikom. Tako smo dobil nekoliko obˇcutka, kako se takˇsna povezava vzpostavi in kaj je potrebno, da naprava streˇzniku zaupa ter mu poˇslje svoje digitalno potrdilo.
ˇ
Se vedno nismo uspeli funkcionalnosti vstaviti neposredno v vtiˇcnik, zato smo razvili svoj testni Ionic vtiˇcnik, ki je omogoˇcal samo dostop do streˇznika z zahtevkom GET z uporabo uporabnikovega digitalnega potrdila. Tako smo se spoznali s strukturo Ionic/Cordova vtiˇcnika, kako se ga naˇcrtuje ter kakˇsen je tok podatkov in klicev v vtiˇcniku. Kljub mnogim problemov s kon-sistentnostjo delovanja samega Ionic ogrodja nam je vtiˇcnik uspelo narediti, vendar je omogoˇcal samo osnovno funkcionalnost. Torej, moˇzni so bili le zah-tevki GET, upravljanja s piˇskotki ni bilo, overjanja z uporabniˇskim imenom in geslom tudi ne. Osredotoˇcili smo se samo na poˇsiljanje uporabnikovega digitalnega potrdila streˇzniku pri vzpostavitvi seje TLS.
Nato smo zaˇceli z implementacijo funkcionalnosti v vtiˇcnik
” cordova-plugin-advanced-http“, za platformo Android. Pregledali smo celotno kodo in poskuˇsali ugotoviti kje vse bomo morali kodo dodati oziroma spremeniti. Najprej smo moˇznost uporabe uporabnikovega digitalnega potrdila ˇzeleli do-dati ˇze obstojeˇci metodi setSSLCertMode, vendar smo se po tehtnem raz-misleku odloˇcili za implementacijo nove metode enableClientCert. Tako je razvijalcu aplikacije omogoˇcena hkratna uporaba tako SSL pripenjanja kot overjanje z uporabo uporabnikovega digitalnega potrdila. ˇCe bi uporabili kar metodo setSSLCertMode, bi na tak naˇcin nekoliko zakomplicirali upo-rabo veˇcih naˇcinov vzpostavitve povezave TLS hkratu.
Diplomska naloga 31
4.1
Postopek delovanja vtiˇ
cnika ob overjanju
uporabnika z uporabnikovim digitalnim
potrdilom
Vtiˇcnik v primeru uporabe overjanja z uporabnikovim digitalnim potrdilom deluje po naslednjem postopku:
1. Razvijalec iz Ionic ogrodja kliˇce metodo enableClientCert s prvim ar-gumentom true. V primeru da uporabljamo digitalno potrdilo, ki je podpisano s strani certifikatske agencije, je drugi argument nastavljen na false. ˇCe uporabljamo samo-podpisano digitalno potrdilo, je drugi argument true. Tretji argument je niz z geslom, ki je uporabljeno za odklepanje uporabnikovega digitalnega potrdila.
2. Vtiˇcnik v datoteki advanced-http.js preveri katero metodo kliˇcemo, ter kliˇce metodoenableClientCert na Java razredu
”CordovaHttpPlugin“. Ob klicu poda ˇse argumente.
1 // Ogrodje Ionic
2 cordova.plugin.http.enableClientCert(true, true, ”niz z geslom”, function(ret){
3 console.log(”success”, ret); 4 }, function(fail){
5 console.log(”fail”, fail); 6 });
3. Vtiˇcnik v datoteki advanced-http.js preveri katero metodo kliˇcemo, ter kliˇce metodoenableClientCert na Java razreduCordovaHttpPlugin. Ob klicu poda ˇse argumente.
1 // Datoteka advanced−http.js
2 disableRedirect: function (disable, success, failure){
3 return exec(success, failure, ’CordovaHttpPlugin’, ’disableRedirect’, [ !!disable ]); 4 },
4. V razredu CordovaHttpPlugin se najprej kliˇce metoda loadClientCert
ki iz datoteˇcnega sistema naprave prebere uporabnikovo digitalno po-trdilo ter pot overjanja. Vtiˇcnik priˇcakuje, da sta obe datoteki v mapi
www/assets/clientCertificate v Ionic projektu. Uporabnikovo digitalno potrdilo mora v imenu datoteke imeti niz
”client“, pot overjanja pa niz ”chain“. Za branje je uporabljen Java razred BufferedInputStream. V primeru, da pride pri inicializaciji BufferInputStream do napake (di-gitalnega potrdila oz. poti overjanja ni na napravi, je v napaˇcnem formatu, itd.), vtiˇcnik vrne informacije o napaki nazaj v Ionic ogrodje s pomoˇcjo povratnih klicev. V nasprotnem primeru oba vhodna tokova shrani kot statiˇcno spremenljivko na razredu HttpRequest.
1 // Datoteka CordovaHttpPlugin.java
2 //Add client certificate file, if the name contains string ”client” 3 //Add certificate chain file, if the name contains string ”chain”
4 private void loadClientCert() throws GeneralSecurityException, IOException{
5 AssetManager assetManager = cordova.getActivity().getAssets(); 6 String[] tempFiles = assetManager.list(”www/assets”);
7
8 String[] files = assetManager.list(”www/assets/clientCertificate”); 9 String clientCertFile = ””;
10 String certChainFile = ””;
11 for (int i = 0; i<files.length; i++){
12 if (files[i].toLowerCase().contains(”client”)){
13 clientCertFile = ”www/assets/clientCertificate/” + files[i]; 14 } else if (files[i].toLowerCase().contains(”chain”)){
15 certChainFile = ”www/assets/clientCertificate/” + files[i];
16 }
17 }
18
19 InputStream in = cordova.getActivity().getAssets().open(clientCertFile); 20 InputStream buffIn = new BufferedInputStream(in);
21 HttpRequest.addClientCert(buffIn); 22
23 in = cordova.getActivity().getAssets().open(certChainFile); 24 buffIn = new BufferedInputStream(in);
Diplomska naloga 33
25 HttpRequest.addChainCert(buffIn); 26 }
Po tem se iz razredaCordovaHttpPlugin kliˇce ˇse metoda setClientCer-tEnabled na razredu HttpRequest. Ob klicu se prenesejo tudi vsi trije argumenti, ki jih je razvijalec aplikacije dal ob klicu iz Ionic ogrodja.
1 // Datoteka CordovaHttpPlugin.java
2 }else if (action.equals(”enableClientCert”)){
3 boolean enable = args.getBoolean(0); 4 boolean selfSigned = args.getBoolean(1); 5 String clientCertPassword = args.getString(2);
6 try{
7 this.loadClientCert();
8 HttpRequest.setClientCertEnabled(enable, selfSigned, clientCertPassword); 9 callbackContext.success();
10 } catch (Exception e){
11 e.printStackTrace();
12 callbackContext.error(”There was an error setting up client certificate 13 setting. Make sure you have client 14 and chain certificates in the folder
15 www/assets/clientCertificate/”);
16 }
17 }
5. V razreduHttpRequest se v statiˇcni spremenljivkiCLIENT KEY MA-NAGERS ter CLIENT TRUST MANAGERS shranijo podatki o upo-rabnikovem digitalnem potrdilu ter poti overjanja. Podatki o kljuˇcih se shranijo v seznam upravljalcev s kljuˇci (ang. key managers), pot overjanja pa v seznam upravljalcev zaupanja (ang. trust managers). V primeru, da razvijalec na vtiˇcniku omogoˇci tudi SSL pripenjanje, se poleg poti overjanja v seznamu upravljalcev zaupanja (ang. trust ma-nagers) shranijo tudi digitalna potrdila iz datoteˇcnega sistema v mapi www/certificates.
1 // Datoteka HttpRequest.java
3 private static void getClientTrustAndKeyManagers() throws IOException{
4 try{
5
6 CertificateFactory certificateFactory = CertificateFactory.getInstance(”X.509”); 7 X509Certificate chainCert = (X509Certificate) certificateFactory
8 .generateCertificate(CHAIN CERT IS); 9 String alias = chainCert.getSubjectX500Principal().getName();
10
11 KeyStore trustStore = KeyStore.getInstance(KeyStore.getDefaultType()); 12 trustStore.load(null);
13 trustStore.setCertificateEntry(alias, chainCert); 14
15 KeyStore keyStore = KeyStore.getInstance(”PKCS12”);
16 keyStore.load(CLIENT CERT IS, CLIENT CERT PASSWORD.toCharArray()); 17
18 KeyManagerFactory kmf = KeyManagerFactory.getInstance(”X509”); 19 kmf.init(keyStore, CLIENT CERT PASSWORD.toCharArray()); 20 KeyManager[] keyManagers = kmf.getKeyManagers();
21
22 TrustManagerFactory tmf = TrustManagerFactory.getInstance(”X509”); 23 tmf.init(trustStore);
24 TrustManager[] trustManagers = tmf.getTrustManagers(); 25
26 CLIENT KEY MANAGERS = keyManagers; 27 CLIENT TRUST MANAGERS = trustManagers; 28
29 }catch (GeneralSecurityException e){
30 IOException ioException = new IOException(”Security exception configuring
31 SSL trust managers”);
32 ioException.initCause(e); 33 e.printStackTrace();
34 throw new HttpRequestException(ioException); 35 }
Diplomska naloga 35
6. Naslednji korak je inicializacija SSL konteksta1, ki je kasneje
upora-bljen pri vzpostavitvi same povezave HTTPS. Pri inicializaciji so upo-rabljeni upravljalci kljuˇcev ter upravljalci zaupanja, ki so bili ustvarjeni v koraku 4. Ko je SSL kontekst1 inicializiran, iz njega pridobimo
po-datkovno strukturoSOCKET FACTORY. Le-ta je shranjena v statiˇcno spremenljivko na razreduHttpRequest, imenovanoSOCKET FACTORY.
1 // Datoteka HttpRequest.java
2 SSLContext context = SSLContext.getInstance(”TLS”);
3 context.init(CLIENT KEY MANAGERS, CLIENT TRUST MANAGERS, 4 new SecureRandom());
5 return context.getSocketFactory();
7. Sedaj ima vtiˇcnik vse, kar je potrebno za vzpostavitev varne povezave HTTPS z uporabo uporabnikovega digitalnega potrdila. Ob vseh nasle-dnjih zahtevkih GET, ki imajo v URLju niz
”https“, se pri vzpostavitvi povezave uporabiSOCKET FACTORY, ki je bil ravnokar inicializiran.
1 // Datoteka HttpRequest.java
2 HttpsURLConnection.setDefaultSSLSocketFactory(SOCKET FACTORY); 3 ((HttpsURLConnection) connection).setSSLSocketFactory(SOCKET FACTORY);
V primeru, da pride pri konfiguraciji delovanja vtiˇcnika, oziroma pri zah-tevkih HTTPS/HTTP do napake, moramo o tem obvestiti razvijalca. Vsa sporoˇcila o napaki se s pomoˇcjo povratnih klicev (ang. callback) poˇsljejo v ogrodje Ionic, prav tako pa se v podrobno poroˇcilo o napaki izpiˇse v dnevniˇski izhod (ang. log output) Android naprave. Ta sporoˇcila lahko ob testiranju aplikacije pregledujemo s pomoˇcjo konzole programa Android Studio.
Prav tako smo poskrbeli, da razvijalec ob uporabi napaˇcnih uporabni-kovih digitalnih potrdil, ali pa da le-teh ni v predvideni mapi, o tem dobi sporoˇcilo v ogrodje Ionic.
1SSL kontekst (ang. SSL Context) je razred programskega jezika Java, ki hrani vse
4.2
Razhroˇ
sˇ
cevanje
Pri razvoju smo uporabljal programsko opremo Android Studio [6], predvsem funkcionalnost, ki omogoˇca pregled dnevniˇskih datotek (ang. log). Tako smo za razhroˇsˇcevanje lahko spremljali zapise v dnevniˇske datoteke ter preverili kje je priˇslo do napake pri delovanju. Android Studio smo uporabljali za pregled stanja vtiˇcnika, za delovanje same testne aplikacije pa smo uporabljali orodje za razvijalce v brskalniku Google Chrome. Ker za implementacijo aplikacije piˇsemo kodo, namenjeno za prikaz na spletnem pogledu (ang.web view), lahko podobno kot pri razvoju spletne aplikacije razne informacije izpisujemo v konzolo brskalnika. Naprava, na kateri teˇce aplikacija mora biti fiziˇcno prikljuˇcena na raˇcunalnik. Na URL naslovu
”chrome://inspect“ v brskalniku Google Chrome lahko tako pregledujemo kaj se z naˇso aplikacijo dogaja v realnem ˇcasu.
Poglavje 5
Ovrednotenje
5.1
Testiranje na testni mobilni aplikaciji
Za preverjanje uporabnosti ter delovanja vtiˇcnika smo razvili preprosto apli-kacijo za platformo Android, ki uporablja vtiˇcnik za povezovanje s testnim streˇznikom. Preveril smo uporabo razliˇcnih vrst zahtevkov (GET, POST, PUSH, PATCH, itd.) na testni streˇznik z uporabo protokola HTTP. Kot smo priˇcakovali, tukaj ni bilo nobenih teˇzav, saj dela kode vtiˇcnika, ki skrbi za povezavo HTTP nismo veliko spreminjali. Pomembno je, da vtiˇcnik de-luje hitro in zanesljivo. Za boljˇso predstavo o tem, kako hiter je naˇs vtiˇcnik, smo za primerjavo uporabili Python [18] knjiˇznicoRequests [19]. Za uporabo te knjiˇznice smo se odloˇcili, ker jo uporablja veliko razvijalcev, ter velja kot dobra in hitra implementacija funkcionalnosti za delo s povezavo HTTP/HT-TPS.
Razvili smo Python [18] skripto, s katero smo poˇsiljali razne zahtevke na testni streˇznik in merili potreben ˇcas za prejem odgovora. Raˇcunalnik, na katerem je bila skripta pognana je bil v istem omreˇzju Wi-Fi kot testni streˇznik ter Android naprava, na kateri smo testirali vtiˇcnik. Tako smo omejil morebitna nihanja v internetni povezavi, ter so tako izmerjeni podatki bolj zanesljivi. Potreben ˇcas za prejem odgovora smo merili tudi na Android napravi in ˇcasa nato primerjali.
5.1.1
Rezultati testiranja
Navadni HTTP GET zahtevki
Slika 5.1: Meritve hitrosti pri navadnih HTTP GET zahtevkih
Povpreˇcen ˇcas – vtiˇcnik: 41ms
Povpreˇcen ˇcas – Python knjiˇznica Requests: 2ms
Najprej smo merili ˇcas za odgovor samo z uporabo navadnega GET zah-tevka, prek protokola HTTP [Slika 5.2]. Torej brez kakrˇsnekoli varnosti. Tako iz Android naprave in raˇcunalnika smo poslali 100 GET zahtevkov, ter merili ˇcas, ki je pretekel od trenutka, ko je bil zahtevek poslan, do prejetega odgovora streˇznika. Zahtevke smo izvajali zaporedno, torej naslednji zah-tevek je bil poslan ˇsele, ko je naprava dobila odgovor prejˇsnjega zahtevka. Tako smo onemogoˇcil morebitne napake pri merjenjih, ˇce bi naprava
zah-Diplomska naloga 39
tevke poˇsiljala vzporedno. Pomembna je tudi koliˇcina podatkov, ki jih vrne streˇznik. V naˇsem primeru je streˇznik vrnil samo kratek niz z nekaj HTML kode.
Iz grafa je razvidno, da je vtiˇcnik precej poˇcasnejˇsi od knjiˇzniceRequests, tako v zaˇcetni fazi kot v nadaljnem delovanju. Vtiˇcnik je pri prvem zahtevku potreboval obˇcutno veˇc ˇcasa, saj mora aplikacija na mobilni napravi opraviti ˇse veliko klicev na nivo operacijskega sistema. Menimo, da je vtiˇcnik kljub temu nalogo opravil v sprejemljivem ˇcasu, in bi ga lahko uporabil pri aplika-ciji, ki opravlja veliko klicev HTTP. Poskuˇsali smo ˇse ostale tipe zahtevkov (POST, DELETE, itd.), pri katerih smo dobil podobne rezultate.
HTTPS brez uporabe uporabnikovega digitalnega potrdila
Povpreˇcen ˇcas – vtiˇcnik: 133ms
Povpreˇcen ˇcas – Python knjiˇznica Requests: 9ms
Isti postopek testiranja smo uporabili tudi za testiranje hitrosti povezave HTTPS [Slika 5.3]. Na svojem testnem streˇzniku smo omogoˇcili povezavo HTTPS, ter iz mobilne naprave in raˇcunalnika poslali 100 zahtevkov GET z uporabo protokola HTTPS.
Rezultati so precej podobni prejˇsnjim. Vtiˇcnik je precej poˇcasnejˇsi od knjiˇznice Requests, vendar menimo, da 133ms ˇse vedno ni preveˇc za uporabo v aplikaciji.
HTTPS z uporabo uporabnikovega digitalnega potrdila
Slika 5.3: Meritve hitrosti pri HTTPS zahtevkih, z uporabo uporabnikovega digitalnega potrdila
Diplomska naloga 41
Povpreˇcen ˇcas – vtiˇcnik : 155ms
Povpreˇcen ˇcas – Python knjiˇznica Requests: 130ms
Preverili smo ˇse uporabo uporabnikovega digitalnega potrdila [Slika 5.1]. Aplikaciji smo priloˇzili uporabnikovo digitalno potrdilo ter pot overjanja. Ker knjiˇznica Requests ne omogoˇca uporabe digitalnih potrdil, ki so zaˇsˇciteni z geslom, smo morali uporabnikovo digitalno potrdilo najprej pretvoriti v drugi format. Tako smo iz ene .p12 datoteke dobil dve. Prva je vsebovala zasebni kljuˇc, druga pa digitalno potrdilo, obe pa sta bili v formatu .pem. Pot overjanja je ˇze bila v formatu .pem. Hitrost vtiˇcnika in knjiˇznice Requests je tukaj precej bolj primerljiva. V sploˇsnem je vtiˇcnik poˇcasnejˇsi le za pribliˇzno 10ms pri vsakem zahtevku.
Pri prvem zahtevku, ki potrebuje nekaj veˇc ˇcasa tudi pri uporabi knjiˇznice
Requests, se vzpostavi povezava TLS, ki je nato uporabljena za vse nadalnje zahtevke, in se ne na novo ustvari za vsak zahtevek posebej. V kodi vtiˇcnika se sicer za vsak nov zahtevek ustvari nov SSL kontekst1, vendar operacijski
sistem Android naprave sam prepozna, da gre za isto povezavo, ki jo lahko znova uporabi.
5.2
Testiranje z uporabo vtiˇ
cnika v mobilni
aplikaciji za pregled porabe elekriˇ
cne
ener-gije v gospodinjstvu
Uporabnost vtiˇcnika smo testirali tudi tako, da smo ga uporabili v aplikaciji, ki smo jo razvijali v okviru projekta Flex4Grid [41] na Inˇstitutu Joˇzef Ste-fan. Aplikacija [Slika 13] je namenjena napravam Android, ter je narejena z ogrodjem Ionic.
Na zalednem streˇzniku se zbirajo podatki o elektriˇcni porabi uporabnikov.
1SSL kontekst (ang. SSL Context) je razred programskega jezika Java, ki hrani vse
Uporabnik ima v svojem gospodinjstvu nameˇsˇcene senzorje, ki merijo porabo elektriˇcne energije ter podatke poˇsiljajo streˇzniku prek protokola MQTT [15]. Streˇznik podatke shranjuje v bazo podatkov. Do podatkov lahko dostopamo prek protokola HTTPS prek vmesnika REST [35] [Tabela 5.1]. Vmesnik je bolj podrobno opisan v [5]. Parametri so opisani v tabeli [Tabela 5.2].
# METODA Konˇcna toˇcka (ang. Endpoint)
1 GET /HOUSEHOLD ID/aggregate/year/YEAR NUM/day/VALUE 2 GET /HOUSEHOLD ID/aggregate/year/YEAR NUM/week/VALUE 3 GET /HOUSEHOLD ID/aggregate/year/YEAR NUM/month/VALUE
Tabela 5.1: REST vmesnik
TIP OPIS
HOUSEHOLD ID niz Enoliˇcni identifikator gospodinjstva YEAR NUM ˇstevilo Leto, iz katerega ˇzelimo pridobiti podatke
VALUE ˇstevilo Dan/teden/mesec v letu, iz katerega ˇzelimo pridobiti podatke
Tabela 5.2: Opis parametrov
Streˇznik vrne niz v notaciji JSON, ki vsebuje podatke doloˇcenega gospo-dinjstva. V odgovoru je v primeru, da smo zahtevali dnevne podatke, 24 vrednosti (poraba po urah). ˇCe smo zahtevali tedenske podatke, streˇznik vrne 7 vrednosti (poraba po dnevih v tednu), ˇce pa smo zahtevali meseˇcne podatke, streˇznik vrne 28/30/31 vrednosti (poraba po dnevih v mesecu). Po-leg vrednosti elektriˇcne porabe streˇznik vrne ˇse nekaj ostalih podatkov, kot so ˇcasovna znaˇcka, merska enota, interval podatkov, itd. Odgovor streˇznika za tedensko porabo izgleda tako:
Diplomska naloga 43
{"name": "energy", "start": "2018-03-04T23:00:00Z", "interval_unit": "second", "unit": "kWh",
"interval": 86400, "samples": 7,
"data": [6.0, 4.4, 4.4, 6.1, 6.6, 4.1, 5.9]}
Uporabnik aplikacije za dostop do podatkov na zalednem streˇzniku po-trebuje digitalno potrdilo, ki ga pridobi ob postopku registracije na to sto-ritev. Veˇc informacij o celotnem postopku pridobitve digitalnega potrdila je na voljo na [4]. V polju common name digitalnega potrdila je vpisan enoliˇcni identifikator gospodinjstva – HOUSEHOLD ID. Ob zahtevku, ko odjemalec (aplikacija) ob vzpostavitvi povezave TLS poˇslje svoje digitalno potrdilo streˇzniku, streˇznik preveri ali se polje common name digitalnega potrdila ujema z HOUSEHOLD ID v URL nizu zahtevka. ˇCe je temu tako, odjemalcu vrne podatke, v nasprotnem primeru pa vrne sporoˇcilo z napako. Tako lahko uporabnik aplikacije dostopa le do podatkov o elektriˇcni porabi svojega gospodinjstva in do podatkov ostalih uporabnikov nima dostopa.
Podatki so v aplikaciji prikazani z grafom. Elektriˇcno porabo v naˇsem gospodinjstvu lahko pregledujemo v treh ˇcasovnih oknih. Prikaˇzemo lahko dnevno porabo po urah, tedensko porabo po dnevih ter meseˇcno porabo po dnevih. Med razliˇcnimi ˇcasovnimi okni se premikamo s potegom (ang. swipe) po zaslonu gor ali dol. V doloˇcenem ˇcasovnem oknu pa se po ˇcasovnici premi-kamo s potegom po zaslonu levo ali desno. Kako prehajamo med razliˇcnimi ˇcasovnimi okni je prikazano na [Slika 5.4], sam uporabniˇski vmesnik pa je bolj podrobno prikazan na [Slika 5.5].
Podatki se na napravo s streˇznika prenaˇsajo sproti. Ko se s potegom premaknemo po ˇcasovnici oziroma spremenimo ˇcasovno okno se mora izvesti nov zahtevek HTTPS. Vtiˇcnik ob hitri internetni povezavi podatke prenese brez vidne zakasnitve. Podatki, preneseni s streˇznika se poleg prikaza ˇse shranijo v notranji pomnilnik mobilne naprave. Tako se podatki za isto ˇcasovno obdobje s streˇznika ne prenaˇsajo veˇckrat.
Vtiˇcnik v aplikaciji deluje po priˇcakovanjih ter dovolj hitro prenaˇsa po-datke s streˇznika.
Poglavje 6
Zakljuˇ
cek
V okviru diplomske naloge smo vtiˇcnik za ogrodje Ionic razˇsirili in nadgradili. Uporabnikom vtiˇcnika smo dodali moˇznost overjanja uporabnika s pomoˇcjo uporabnikovega digitalnega potrdila. Spoznali smo se z delovanjem in upo-rabo protokola TLS ter kako poleg overjanja streˇznika overimo tudi odje-malca. Delali smo z ogrodjem za izdelavo hibridnih aplikacij Ionic in se nauˇcili, kako funkcionalnost operacijskega sistema prenesti v ogrodje Ionic v okviru vtiˇcnika. Uporabnost in hitrost vtiˇcnika smo ovrednotili z uporabo v testni in pravi aplikaciji.
Z uporabo ogrodij za razvoj hibridnih aplikacij lahko zmanjˇsamo ˇcas, potreben za izdelavo aplikacije. Problem se pojavi, ko ogrodje ne omogoˇca doloˇcene funkcionalnosti, v naˇsem primeru je to bilo overjanje uporabnika. V okviru diplomskega dela nam je funkcionalnost uspelo dodati za platformo Android. Da bo overjanje uporabnika delovalo tudi za platformo iOS je potrebnega ˇse precej dela. Namreˇc del vtiˇcnika, ki skrbi za iOS platformo je nekoliko teˇzje razumljiv in bolj razkropljen, veliko izkuˇsenj z programskim jezikom Objective-C pa nimamo.
Kljub temu menimo, da smo odprtokodnemu ogrodju dodali pomemben del funkcionalnosti ter tako marsikateremu razvijalcu olajˇsali delo. Vtiˇcnik je dostopen na Github platformi na naslovu [27].
Literatura
[1] 12 frameworks for mobile hybrid apps. Dosegljivo: https://blog. jscrambler.com/10-frameworks-for-mobile-hybrid-apps/, [Do-stopano: 24. 8. 2018], author=Jscrambler, year=2017.
[2] Android - wikipedia. Dosegljivo: https://en.wikipedia.org/wiki/ Android_(operating_system), [Dostopano: 10. 7. 2018], 2018.
[3] Tim Bray, Jean Paoli, C Michael Sperberg-McQueen, Eve Maler, and Fran¸cois Yergeau. Extensible markup language (xml). World Wide Web Journal, 2(4):27–66, 1997.
[4] D2.1 initial security and privacy module. Dosegljivo: https: //www.flex4grid.eu/wp-content/uploads/646428-Flex4Grid_-_D2.1_Initial_Security_and_Privacy_Module.pdf, [Dostopano: 28. 8. 2018], 2015.
[5] D2.4 final cloud-based data management module. Dosegljivo: https: //www.flex4grid.eu/wp-content/uploads/646428-Flex4Grid-D2.4_Final_Cloud-based_Data_Management_module.pdf, [Dosto-pano: 28. 8. 2018], 2015.
[6] Domaˇca stran android studio. Dosegljivo: https://developer. android.com/studio/, [Dostopano: 10. 7. 2018].
[7] Domaˇca stran angularjs. Dosegljivo: https://angularjs.org/, [Do-stopano: 16. 7. 2018].
[8] Domaˇca stran apple. Dosegljivo: https://www.apple.com/si/, [Do-stopano: 24. 6. 2018].
[9] Domaˇca stran cordova. Dosegljivo: https://cordova.apache.org/, [Dostopano: 15. 8. 2018].
[10] Domaˇca stran eclipse. Dosegljivo: https://www.eclipse.org/, [Do-stopano: 10. 7. 2018].
[11] Domaˇca stran flask. Dosegljivo: http://flask.pocoo.org/, [Dosto-pano: 5. 8. 2018].
[12] Domaˇca stran framework7. Dosegljivo: https://framework7.io/, [Do-stopano: 24. 8. 2018].
[13] Domaˇca stran ionic. Dosegljivo: https://ionicframework.com/, [Do-stopano: 3. 7. 2018].
[14] Domaˇca stran java. Dosegljivo: https://www.java.com/en/, [Dosto-pano: 12. 7. 2018].
[15] Domaˇca stran mqtt. Dosegljivo: http://mqtt.org/, [Dostopano: 25. 8. 2018].
[16] Domaˇca stran openssl. Dosegljivo: https://www.openssl.org/, [Do-stopano: 19. 6. 2018].
[17] Domaˇca stran phonegap. Dosegljivo: https://phonegap.com/, [Dosto-pano: 24. 8. 2018].
[18] Domaˇca stran python. Dosegljivo: https://www.python.org/, [Dosto-pano: 19. 8. 2018].
[19] Domaˇca stran python knjiˇznice requests. Dosegljivo: http://docs. python-requests.org/en/master/, [Dostopano: 5. 6. 2018].
[20] Domaˇca stran react native. Dosegljivo: https://facebook.github. io/react-native/, [Dostopano: 24. 8. 2018].
Diplomska naloga 51
[21] Domaˇca stran react.js. Dosegljivo: https://reactjs.org/, [Dosto-pano: 25. 8. 2018].
[22] Domaˇca stran xamarin. Dosegljivo: https://visualstudio. microsoft.com/xamarin/, [Dostopano: 24. 8. 2018].
[23] Domaˇca stran xcode. Dosegljivo: https://developer.apple.com/ xcode/, [Dostopano: 15. 8. 2018].
[24] Dot net programski jezik. Dosegljivo: https://www.microsoft.com/ net, [Dostopano: 25. 8. 2018].
[25] Rupa Ganjewar. Diffie hellman key exchange. 2010.
[26] Github vtiˇcnika cordova-plugin-advanced-http. Dosegljivo: https:// github.com/silkimen/cordova-plugin-advanced-http, [Dostopano: 30. 6. 2018].
[27] Github vtiˇcnika cordova-plugin-advanced-http-with-client-cert. Do-segljivo: https://github.com/klemenStanic/cordova-plugin-advanced-http-with-client-cert, [Dostopano: 25. 6. 2018].
[28] Jay Graves. Ssl pinning for increased app security. Do-segljivo: https://possiblemobile.com/2013/03/ssl-pinning-for-increased-app-security/, [Dostopano: 5. 6. 2018], 2013.
[29] Russell Housley, Warwick Ford, William Polk, and David Solo. Internet x. 509 public key infrastructure certificate and crl profile. Technical report, 1998.
[30] Ionic http vtiˇcnik - dokumentacija. Dosegljivo: https:// ionicframework.com/docs/native/http/, [Dostopano: 3. 8. 2018], 2018.
[31] ios - wikipedia. Dosegljivo: https://en.wikipedia.org/wiki/IOS, [Dostopano: 15. 8. 2018], 2018.
[32] Kotlin programski jezik. Dosegljivo: https://kotlinlang.org/, [Do-stopano: 12. 7. 2018].
[33] Linux kernel. Dosegljivo: https://www.kernel.org/, [Dostopano: 30. 7. 2018].
[34] Man in the middle (mitm) attack. Dosegljivo: https: //www.incapsula.com/web-application-security/man-in-the-middle-mitm.html, [Dostopano: 5. 6. 2018], 2018.
[35] Mark Masse.REST API Design Rulebook: Designing Consistent REST-ful Web Service Interfaces. ”O’Reilly Media, Inc.”, 2011.
[36] Message authentication code - wikipedia. Dosegljivo: https: //en.wikipedia.org/wiki/Message_authentication_code, [Dosto-pano: 12. 7. 2018], 2018.
[37] Npm cordova-plugin-advanced-http. Dosegljivo: https://www.npmjs. com/package/cordova-plugin-advanced-http, [Dostopano: 29. 6. 2018].
[38] Number of apps available in leading app stores as of 1st quarter 2018. Dosegljivo: https://www.statista.com/statistics/276623/ number-of-apps-available-in-leading-app-stores/, [Dostopano: 10. 8. 2018], 2018.
[39] Objective c - wikipedia. Dosegljivo: https://en.wikipedia.org/ wiki/Objective-C, [Dostopano: 1. 8. 2018], 2018.
[40] DongGook Park, Colin Boyd, and Sang-Jae Moon. Forward secrecy and its application to future mobile communications security. In Internati-onal Workshop on Public Key Cryptography, pages 433–445. Springer, 2000.
[41] Projekt flex4grid. Dosegljivo: https://www.flex4grid.eu/, [Dosto-pano: 5. 8. 2018].
Diplomska naloga 53
[42] Eric Rescola. SSL and TLS, Designing and Building Secure Systems. Addison-Wesley, 2000.
[43] E. Rescorla. The transport layer security (tls) protocol version 1.3. RFC 8446, RFC Editor, August 2018.
[44] Arto Salomaa. Public-key cryptography. Springer Science & Business Media, 2013.
[45] Self-signed certificate. Dosegljivo: https://en.wikipedia.org/wiki/ Self-signed_certificate, [Dostopano: 13. 6. 2018], 2018.
[46] Swift programski jezik. Dosegljivo: https://developer.apple.com/ swift/, [Dostopano: 12. 7. 2018].
[47] Symmetric-key algorithm - wikipedia. Dosegljivo: https://en. wikipedia.org/wiki/Symmetric-key_algorithm, [Dostopano: 12. 7. 2018], 2018.
[48] Transport layer security - wikipedia. Dosegljivo: https://en. wikipedia.org/wiki/Transport_Layer_Security, [Dostopano: 12. 7. 2018], 2018.
