HØGSKOLEN I OSLO OG AKERSHUS Gruppe 25 Forprosjektrapport Forfattere: Simon B. J ONSSON Hans Christian N ENSETH Erlend S ANDVED Veiledere: Frank T. J OHNSEN Federico M ANCINI Ismail H ASSAN 18. Januar 2017
1 Presentasjon 3 1.1 Oppdragsgiver 4 1.2 Oppgave 4 2 Sammendrag 4 3 Dagens situasjon 6 4 Mål og rammebetingelser 6 4.1 Mål 6 4.2 Teknologi 7 4.3 Rammebetingelser 7 5 Løsninger 7 5.1 JavaCard 8 5.2 DESFire EV1 8 5.3 Gradle/Android Studio 8 5.4 Produktet 8 5.5 RESTful Web Services/OAuth 2.0 8 6 Analyse av virkninger 9 6.1 DESFire EV1 9 6.2 Java Card 9 7 Appendiks 10 7.1 Arbeidsplan 10 7.2 Fremdriftsplan 10 7.3 Milepæler 11 7.4 Risikoanalyse 11 2
1 Presentasjon Oppdragsgiver Prosjekttittel Oppgave FFI - Forsvaret Forsknings Institutt www.ffi.no Gutta på skauen - Server og klient sikkerhet Sikker autentisering av personell gjennom en app på en smarttelefon mot en lokal server for å supplere eksisterende samband. Dette for å gi enkeltmann korrekt situasjonsoversikt i felt. Periode 02.01.2017-31.05.2017 Gruppenummer 25 Gruppemedlemmer Erlend Sandved s929556 Dataingeniør Simon Broman Jonsson s929516 Dataingeniør Hans Christian Nenseth s236334 Dataingeniør Talsmann Simon B. Jonsson Intern veileder Ismail Hassan ismail.hassan@hioa.no Veiledere Frank Trethan Johnsen frank-trethan.johnsen@ffi.no +47 63 80 79 60 Federico Mancini Federico.Mancini@ffi.no +47 63 80 79 53 3
1.1 Oppdragsgiver FFI er et tverrfaglig institutt som representerer fagene matematikk, fysikk, informasjonsteknologi, kjemi, biologi, medisin, psykologi, statsvitenskap og økonomi. Instituttet er i aktivt samarbeid med ledende institusjoner i inn- og utland. I tillegg til å gjøre en innsats innen moderne høyteknologi, yter FFI et betydelig bidrag til Forsvarets langtidsplanlegging. Instituttet gjennomfører hovedsakelig analyser og utviklingsprosjekter for Forsvarets behov, men har også sivilt rettede prosjekter. 1.2 Oppgave På FFI holder vi på med en aktivitet der vi skal forstå om vi kan øke sikkerheten av en Android app i form av sikker autentisering av brukere ved bruk av forskjellige typer smartkort. Telefonene som skal brukes vil ha et oppsett av flere apper i form av chat, lysdisiplin, vpn og appen utviklet av FFI, som tar for seg plotting i kart og visualisering av situasjonen. Vår oppgave vil være rettet mot å autentisere brukere som skal bruke FFI sin app. Idéen er at vi vil gjøre det enklere og sikrere for brukerne å konfigurere appene og autentisere seg mot appen og mot serveren, og hindre datatap tilfelle mobiltelefonen eller kortet blir stjålet eller mistet. NFC smartkort kan da brukes til å lagre all informasjonen man trenger til å konfigurere appen første gang, generere og lagre kryptonøklene som skal brukes av appen, og til å kommunisere sikkert direkte med serveren. 2 Sammendrag I det gitte scenarioet, vil et smartkort øke sikkerheten ved å gjøre det enklere for brukere å logge seg på og autentisere seg både mot appen og serveren, og ved å beskytte de nødvendige hemmelige nøklene på en bedre måte enn om bare mobilenheten hadde blitt brukt. En viktig forutsetning er at mobilen ikke har blitt kompromittert. Hvis en målrettet ondsinnet programvare er installert på mobilen, vil all dataen i appens minne uansett være tilgjengelig for en angriper. Kortet vil fortsatt kunne beskytte nøklene og nekte adgang til dem hvis kompromittering blir detektert, men sensitive data som går gjennom appen vil bli tapt. De spesifikke truslene vi prøver å beskytte oss mot ved å ta i bruk et smartkort er beskrevet i de følgende scenarioene: 1. Brukeren mister eller blir frastjålet telefonen: Da skal det ikke være mulig å låse opp appen, koble seg til serveren eller hente ut sensitive data uten kortet og kortets tilgangskode. 2. Brukeren mister eller blir frastjålet kortet: Ingen sensitiv informasjon vil kunne tas ut av kortet uten kortets tilgangskode eller/og telefonen, og det skal ikke heller være mulig å utgi seg for å være den legitime brukeren. 4
3. Brukeren mister eller blir frastjålet telefonen og kortet: Det skal ikke være mulig å gjette seg fram til PIN koden. 4. Appen blir lastet ned og installert av en uautorisert bruker: Det skal ikke være mulig å få informasjon som kan brukes til å kompromittere andre enheter, brukere eller serveren fra appen. 5. Nettverket er avlyttet eller under kontroll av en fiendtlig part: Det skal ikke være mulig å få sensitive data fra trafikken mellom appen og serveren eller villede appen til å kommunisere med en falsk server. 6. Serveren eller brukeren detekterer at enheten og appen er kompromittert: Det skal være mulig å sperre adgang til kortet og nekte appen tilgang til serveren. Hvilke sikkerhetstiltak kan implementeres for å beskytte mot disse truslene, er avhengig av forskjellige variabler: eierskapsmodellen til telefonen, smartkort egenskaper og operasjonelle og funksjonelle krav. Disse vil påvirke hvordan vi kan etablere tillit mellom serveren, appen/enheten, brukeren og kortet, og hvordan vi kan sikre det hele operasjonelt. Her vurderer vi to eierskapsmodeller: BYOD: en privat enhet blir brukt. Appen må lastes ned og konfigureres «on-the-fly». MDM: enheten er pre-konfigurert og under kontrollen av «IT-avdelingen». To typer smartkort: DESFire: et smartkort som kan bare lagre filer og beskytte dem gjennom en prekonfigurert autentiseringsprotokoll som bruker sterke kryptografiske nøkler. JavaCard: et smartkort som kan programmeres for å utføre tilpasset kryptografiske operasjoner og kan beskyttes med en PIN kode. Operasjonelle krav knyttet til tre faser: Distribusjon av appen og brukerens akkreditiver: brukere må ha alt de trenger for å begynne å bruke appen før de laster den ned. Registrering og aktivering av appen: det skal være enkelt å installere og aktivere appen uten ekstern hjelp (gitt at serveren kan nås), og mulig å lett bytte telefon om nødvendig. Bruk av appen: Bruk av kortet skal ikke være en hindring og appen skal kunne trygt brukes både online og offline. Hovedproblemene som må løses for å dekke de scenarioene er derfor: 1. Appen må trygt og enkelt lastes ned på enhver enhet eller være pre-installert. 2. Bare en legitim bruker med kortet kan aktivere appen. 3. Bare den legitime serveren kan fullføre aktiveringsprosessen. 4. Etter aktiveringen skal kortet og enheten være bundet sammen slik at de ikke kan brukes hver for seg eller med andre enheter/kort. 5
5. Etter aktiveringen skal appen kunne fungere også offline ved å bruke kortet som autentiseringstoken. 6. Hvis appen lastes ned og aktiveres av brukeren på en ny enhet, må den gamle installasjonen deaktiveres. Hvordan de kan løses på teknisk nivå varierer for forskjellige typer kort og eierskapsmodeller. 3 Dagens situasjon I en tid hvor teknologien i konsumermarkedet har hatt en enorm vekst når det kommer til mobile enheter, så har eldre mer avanserte kommunikasjonsverktøy havnet på sidelinjen. FFI har for tiden prosjekter hvor de ser på smarttelefonens nytteverdi for personell ute i felt. I samarbeid med HV kom det frem at enkeltmann benyttet seg ofte av egen medbrakt smarttelefon for kommunikasjon i stedet for sambandet som var tilgjengelig. I denne sammenheng har FFI utviklet en app for Android hvor det vil være mulig for enkeltmann å rapportere og innhente informasjon relevant til oppdraget. Denne delingen av informasjon, samt informasjonen i seg selv er ønskelig å sikre på best mulig måte. FFI ønsker her å implementere et sikkerhetskonsept de selv har skissert. Dette baserer seg på bruken av smarttelefonens NFC-leser og et smartkort for lokal og sentral autentisering. Vår jobb blir å sette dette konseptet ut i liv, samt se videre på utvidet funksjonalitet som kan oppnås med andre typer smartkort. 4 Mål og rammebetingelser 4.1 Mål Hovedmålet med vårt arbeid er å tilby FFI en sikkerhetsmodul til deres server/klient-system som tilbyr autentisering mot en app de har utviklet for personell i felt. Sikker autentisering lokalt på smarttelefonen og sentralt mot server ved bruk av smartkort og NFC i smarttelefon. Se på utvidet funksjonalitet knyttet til andre typer smartkort. Attributtstyrt tilgang Kryptering/Sertifisering 6
4.2 Teknologi JavaSE Java Card MIFARE DESFire EV1 Android Studio IntelliJ PostgreSQL Java EE - RESTful Web Services/OAuth 2.0 Kryptering/Sertifikater Latex GitLab JIRA & Confluence 4.3 Rammebetingelser FFI har gitt oss en oppgave der en del besluttninger allerede har blitt tatt i forhold til hva som har blitt benyttet tidligere i prosjektet. Det er likevel noen rammebetingelser som må møtes slik at vi kan implementere vår sikkerhetsmodul. RESTful Web Services/OAuth 2.0 VMWare (virtuelle maskiner) tilgang til back-end-server Linux Ubuntu Server 14.04LTS/16.04LTS Smarttelefoner med NFC-funksjonalitet Smartkort MIFARE DESFire EV1/JavaCard 5 Løsninger Siden vår oppgave vil gå ut på å utvikle en sikkerhetsmodul til de allerede eksisterende systemene med server/klient, så er de fleste valg allerede tatt for oss når det kommer til hvilke teknologier som skal benyttes. I denne seksjonen tar vi for oss teknologiene som skal benyttes i vår del av prosjektet. 7
5.1 JavaCard Den opprinnelige planen var å bruke JavaCard, men på grunn av en feil med kortene de hadde fått til testing gikk de vekk fra disse kortene, og utviklet et konsept rundt DESFire-kort i stedet. Siden de oppdaget feilen for sent, men fortsatt har et utarbeidet konsept også for disse kortene er det ønskelig å se videre på Java Card etter at DESFire-løsningen er på plass. 5.2 DESFire EV1 Under omstendighetene som ble beskrevet over ble det utviklet et konsept rundt MiFare DESFire-kort, som er en enklere type av smartkort, men likevel gir oss muligheten til å sette opp en autentiseringsløsning med komplekse kryptonøkler. Denne typen kort er også betydelig billigere enn Java Card. 5.3 Gradle/Android Studio Som byggsystem vil vi benytte oss av Gradle. Dette kommer godt integrert i Android studio som er vårt valg av IDE for Android-programmeringen. Gradle gir oss et godt verktøy til å håndtere det nokså komplekse Android prosjektet som allerede eksisterer. Sammen med Git-integrasjon i Android studio vil alt være tilrettelagt for at vi skal kunne samarbeide godt med masterstudenten som ser på andre deler av Android-prosjektet. 5.4 Produktet Vi vil bli nødt til å implementere nye elementer i både back-end og front-end for å få et fungerende system. Vi vil jobbe mot å få sikkerhetsmodulen til å bli så modulær som mulig og enkel å gjøre endringer i senere for å åpne for bruk av annet smartkort. Back-end vil vi i hovedsak måtte se på Java og SQL mot serveren og databasen for å få vår del opp å gå. I Front-end vil implementasjonen ha hovedfokus rundt Android-programmering. 5.5 RESTful Web Services/OAuth 2.0 For å få programvaren på NATO best practices skal vi implementere OAuth 2.0 Based Rest Security Framework. OAuth 2.0 er lagt på HTTP for å gi autoriserte brukere sikkerhetstoken som skal brukes for å 8
få tilgang til beskyttet ressurser. OAuth 2.0 komplementerer REST sikkerhetsrammeverket ved å introdusere klient, autentisasjonsserver og ressursserver komponenter. 6 Analyse av virkninger Prosjektet vi skal jobbe med skal ta over en midlertidig løsning FFI laget mellom en app på en smarttelefon og en lokalt stående server for bruk av HV i felt. Som et supplement til arbeidet de driver i dag, skal vi gjøre det lettere for soldater å holde kontakt gjennom en samband, gi ut sin egen posisjon og vite andres posisjoner. Dette er et stort prosjekt som inneholder flere elementer som vi behersker godt i Java og Android, men også store deler der vi har mulighet til å lære og utvikle oss innenfor bruk av NFC og sikring av informasjon i sammensatte systemer. Utfordringen blir å jobbe kontinuerlig for å legge ned tilstrekkelig antall timer for å skape et produkt vi er tilfreds med og stolt kan gi fra oss. 6.1 DESFire EV1 Ved å bruke DESFire-kort i stedet for JavaCard får man noen ekstra utfordringer på grunn av kortets enkelhet. DESFire-kortene fungerer i teorien som et minnekort med en enkel mappestruktur og sterk tilgangskontroll. Disse kortene gir oss muligheten til å benytte en kombinasjon av kryptonøkler fra server, smarttelefon og kort for å få en fungerende autentiseringsløsning. Det er helt klart en ulempe at disse kortene ikke kan kjøre kode med tanke på videre utvikling hvor det er ønskelig med attributstyrte tilganger. Samtidig er disse kortene svært billige med en pris på ca $4US pr stk. noe som er en stor fordel for HV som har begrenset med midler. 6.2 Java Card Java Card gir oss større mulighet til å ha flere funksjoner knyttet til selve kortet ved autorisering. Siden kortene kan kjøre enkel kode er det kanskje ønskelig å flytte noe av krypteringen/sertifiseringen over på selve kortet. Det er i tillegg for eksempel ønskelig å ha differensiert tilgang til informasjon fra server og muligheten til å ha differensiert distribusjon av denne. Vi vil se på muligheten til å gi flere nivåer av tilgang og rettigheter. Prisen på disse kortene er omtrent $40US pr stk så vi vil se på muligheten for en begrenset distribusjon av kortene. 9
7 Appendiks 7.1 Arbeidsplan Planlegging I planleggingsfasen skal kravsspesifikasjonen utarbeides, det skal avtales hvor arbeidssted blir, gi tilganger til prosjektfiler, fordele arbeidsmengde blant gruppemedlemmer. Programmering I programmering delen inngår all generell koding. Her skal det implementeres funksjoner til appen og backend. Testing Testingen skal vi sjekke at alle funksjoner fungerer som de skal. Vi skal forhåpentligvis ha en test med HV rundt april for å teste det vi har utviklet. Brukertester på sikkerhetsvakta ved FFI. Dokumentasjon Det skrives prosjektdagbok som regel etter hver økt eller ved sentrale avgjørelser som påvirker prosjektet. Alle brukerundersøkelser og tester vil loggføres og dokumenteres. 7.2 Fremdriftsplan Uke 2 4 6 8 10 12 14 16 18 20 Planlegging Forprosjekt Kompetanse Utvikling Implementering Testing Dokumentering Sluttrapport 10
7.3 Milepæler 20.01.2017 - Innlevering forprosjektrapport. 31.01.2017 - Smartkort funksjonen oppe i drift.??.04.2017 - System test på øvelse med HV. 25.05.2017 - Innlevering sluttrapport. 06-09.05.2017 - Muntlig presentasjon av prosjektoppgaven. 7.4 Risikoanalyse Risiko Sannsynlighet Alvorlighet Løsning Sykdom internt i gruppen. Intern uenighet om oppgaven som fører til stopp i framdrift på prosjektet. Gruppe medlemmer ikke blir sikkerhetsklarert. Prosjektet blir for omfattende og tidkrevende. Prosjektet blir ikke ferdig før deadline Middels Lav Resten av gruppen må ta på seg ekstra arbeid under sykdomsperioden. Lav Middels Prøve å megle internt for å finne gode løsninger alle er tilfredsstilt med. Middels Middels Andre i gruppen som er sikkerhetsklarert må ta med seg gruppemedlemmer rundt. Lav Lav Konsentrere seg om DESFire og utelukke JavaCard. Lav Høy Sette en intern deadline innen gruppen som er før prosjektet sin deadline, kommer det noe uventet har vi litt bedre tid. 11