Informasjonssikkerhet i AutoPASS-brikker

Transkript

1 - Åpen Rapport Informasjonssikkerhet i AutoPASS-brikker Sikkerhet i dagens AutoPASS-brikker sett i relasjon til AutoPASS brikker basert på EN 5509 EFC Interoperability Application Profile for DSRC Forfatter Trond Foss SINTEF Teknologi og samfunn Transportforskning

2 SINTEF Teknologi og samfunn Postadresse: Postboks 4760 Sluppen 7465 Trondheim Sentralbord: Telefaks: 0 ts@sintef.no Foretaksregister: NO MVA av 24

3

4 Historikk DATO SBESKRIVELSE Versjon Omarbeidelse av arbeidsnotat til Rapport. 3 av 24

5 Innholdsfortegnelse Innledning Metodikk Hvorfor sikkerhet i EFC systemer? Roller og sikkerhetsrelaterte ansvarsområder Trusler i EFC systemer AutoPASS EasyGo Sikkerhet i AutoPASS-brikken Sikkerhetsnøkler Meldingsautentiseringskodene Tilgang på data i AutoPASS-brikken Sikkerhet i en brikke (OBE) med EFC applikasjon basert på EN To sikkerhetsnivå Sikkerhetsnøkler i EN Nøkler for beregning av MAC Nøkler for adgangskontroll Sammenligning av sikkerheten i AutoPASS og brikker med EN 5509 EFC applikasjon Meldingsautentiseringskoder (MACs) Adgang til data på brikken Transaksjonsteller Kvalitet på meldingsutveksling mellom brikke og vegkantutstyr Sikkerhet i hele verdikjeden Europeiske løsninger... 2 Konklusjon Referanser av 24

6 Summary in English The report describes the information security in the Norwegian AutoPASS On-Board Equipment (OBE) based on the AutoPASS EFC specifications in comparison with the security mechanisms in EFC systems based on the EN 5509 EFC profile standard. The report starts with a description of the roles and responsibilities in the Norwegian EFC system based on the role model in the international EFC system architecture standard. Each of the roles are described and their security related responsibilities are given. In addition to the 4 roles in the system architecture the Trusted Third Party and the professional Operator supporting the Norwegian Toll Companies are also described. The threats as defined in the original AutoPASS specification from are described. Concerning the AutoPASS OBE the main threats were impersonation, tampering and denial of received service ("I was not there"). All these threats are met with security mechanisms implemented in the AutoPASS OBE. The EasyGo threat analysis is also described. The main potential attackers found here were the Hacker, the Activist, The User, the Organisations and the Operator. The crucial assets were Privacy, the Toll Charger reputation and the objects On-Board Equipment (OBE), Roadside Equipment (RSE) and Central System (CS). The information security in AutoPASS OBEs are based on the calculation of two different Message Authentication Codes (MAC) using two different sets of security keys stored in the OBE. The data stored on the OBE are not protected by access control (Access credentials) enabling the OBE to be used for other purposes than tolling, e.g. parking payment and traffic data collection. The information security in EN 5509 are also based on the calculation of MACs and the use of two sets of keys as defined in the European EFC security framework standard. In addition to this the security mechanisms may also include access control to the OBE by the use of access credential enabling the roadside equipment to read and write information from and to the OBE. In principal the AutoPASS and the EN 5509 based OBEs can calculate MACs on the same data stored in the OBE. The main difference is that the AutoPASS OBE uses a session specific security key while the 5509 based OBE uses a random number including the RSE timestamp for the MAC calculation. Finally the report describes how the assets are protected in the whole value chain securing confidentiality, integrity and availability from the OBE is being initialised until the EFC transaction is sent to the Toll Service Provider from the Toll Charger. This report focuses on the OBE and the report does not consider privacy issues as these are relying on security mechanisms and measures in the whole value chain. 5 av 24

7 Innledning Denne rapporten er utarbeidet etter oppdrag fra Statens vegvesen Vegdirektoratet og inngår som en del av bakgrunnsmaterialet for utarbeidelsen av ny kravspesifikasjon for AutoPASS-brikker anvendt for elektronisk avgiftsinnkreving (EFC) i Norge. Med informasjonssikkerhet (kortform i denne rapporten: sikkerhet) menes beskyttelse av informasjon som er lagret og/eller behandlet av personell og IKT systemer som inngår som en del av leveringen av AutoPASS betalingstjeneste. Rapporten beskriver først litt om hva som ligger i begrepet (informasjons)sikkerhet og hvorfor det er nødvendig å ha et visst nivå på sikkerheten i AutoPASS. Videre beskriver rapporten hvilke roller og ansvarsområder som er knyttet til sikkerhet med utgangspunkt i den internasjonale standarden ISO 7573 EFC System architecture for vehicle related transport services []. Rapporten beskriver også litt om de viktigste truslene slik de ble vurdert da AutoPASS-spesifikasjonen ble utarbeidet [2] og litt om trusselanalysen gjennomført i EasyGo som igjen er basert på CEN/TS 6439 EFC Security framework [3] som er et viktig dokument mht. risiko og sikkerhetstiltak i europeiske EFC systemer. Rapporten beskriver deretter hvordan sikkerheten i AutoPASS er bygget opp og tilsvarende hvordan den europeiske EFC standarden EN 5509 Electronic fee collection - Interoperability application profile for DSRC [8] beskriver ulike sikkerhetsmekanismer som skal implementeres i interoperable EFC systemer. Avslutningsvis sammenlignes viktige sikkerhetselementer i AutoPASS og EN 5509 og det omtales kort hvilke løsninger man ser for seg på europeisk nivå. Mht. terminologi brukes begrepet brikke om det objektet som i alle standarder omtales som OBE eller On- Board Equipment (kjøretøyenhet). 2 Metodikk Metodikken som er anvendt er en gjennomgang av AutoPASS spesifikasjoner og europeiske og internasjonale standarder for elektronisk avgiftsinnkreving. En spesielt viktig standard har vært EN 5509 Electronic Fee Collection - Interoperability Application Profile for DSRC som er en av standardene som danner grunnlaget for europeisk samordning av bompengesystemer. Med bakgrunn i gjennomganger av spesifikasjoner, standarder og trusselanalyser er det sett på hvilke trusler et innkrevingssystem kan bli utsatt for og på hvilke måter ulike sikkerhetsmekanismer kan møte disse truslene slik at risikonivået reduseres til et akseptabelt nivå. Arbeidet har fokusert på selve brikken i og med at rapporten inngår som en del av arbeidet med utarbeidelse av spesifikasjoner for neste generasjon AutoPASS-brikker. Sikkerhetsmessig sammenligning av nåværende AutoPASS-brikke med en fremtidig EN 5509 basert AutoPASS-brikke har vært en viktig del av det utførte arbeidet. Rapporten ser ikke på hvordan personvernet er ivaretatt i AutoPASS eller i EFC systemer basert på EN 5509, men fokuserer på å beskrive de ulike sikkerhetsmekanismene og sammenligne bruken av disse for å sikre nødvendig konfidensialitet, integritet og tilgjengelighet. 3 Hvorfor sikkerhet i EFC systemer? Informasjon (data), støttefunksjoner, systemer og nettverk er meget viktige aktiva i EFC systemer. Hele forretningsmodellen for EFC er basert på innsamling av informasjon, bearbeiding av innsamlet informasjon og innkreving av betaling fra brukerne (kundene) av EFC systemet hvor betalingen er basert på innsamlet informasjon og påfølgende informasjonsbehandling. Sikkerhet er essensielt med tanke på nøyaktighet, tillit, pålitelighet og tilgjengelighet til EFC systemene. 6 av 24

8 EFC systemene blir mer og mer integrerte slik at brukerne opplever sømløse betalingssystemer for kjøretøyrelaterte transporttjenester som f.eks. bruk av avgiftsbelagte vegstrekninger eller vegsystem. Sannsynligheten for at en ikke ønsket sikkerhetsrelatert hendelse skal skje og konsekvensen av denne vil ofte øke for hvert EFC system som blir tilknyttet allerede samordnede EFC systemer. Truslene kan være både interne (på innsiden av de samordnede EFC systemene) eller den kan være ekstern. Eksempler på slike trusler er bedrageri, sabotasje, hærverk og benektelse av mottatte tjenester som er gjort mulig ved ikkeautorisert tilgang til EFC systemene, hacking eller feil i programvare. Brann i sentralsystemer er også en trussel mot informasjonssikkerheten i EFC systemer fordi verdifull informasjon kan gå tapt og påføre enten brukerne eller eierne av EFC systemene skader og/eller økonomiske tap. Sikkerhetstruslene kan forårsake ulike typer skader for de ulike interessentene i EFC systemene. Disse skadene kan grovt sett deles inn i fire kategorier: Tap av anseelse og personlig integritet for brukerne (kundene) Økonomiske tap for brukerne (kundene) Tap av omdømme og troverdighet for eierne/operatørene av EFC systemene Økonomiske tap for eierne/operatørene Sikkerheten i EFC systemer skal først og fremst avverge hendelser som kan medføre noen av de skadekategoriene som er nevnt ovenfor. Deretter skal sikkerheten minimalisere skaden ned til et akseptabelt nivå dersom en uventet og/eller uønsket hendelse inntreffer. 4 Roller og sikkerhetsrelaterte ansvarsområder Det norske systemet for innkreving av bompenger er basert på en rollemodell som er beskrevet i den internasjonale standarden []. Den standardiserte rollemodellen bygger på 4 roller: Utsteder (Toll Service Provider): ansvarlig for å levere en betalingstjeneste til brukerne Operatør (Toll Charger): ansvarlig for å drive selve innkrevingssystemet (bompengesystemet) Samordningsorgan (Interoperability Manager): ansvarlig for å samordne Utstedere og Operatører både mht avtaleverk og funksjonelle og tekniske krav Bruker (User): den som benytter en transporttjeneste og som må betale for denne tjenesten ved hjelp av det betalingssystemet som Utstederen tilbyr. Driftsoperatøren inngår ikke i denne modellen, men er i norske EFC systemer beskrevet som en underleverandør til Utsteder og Operatør og utfører nærmere avtalte arbeidsoppgaver som tilligger Utsteder og Operatør. Tiltrodd Tredjepart (TTP) er heller ikke en rolle som er definert i standarden siden den ikke er en generell rolle som finnes i alle EFC systemer. Iht. til ISO/IEC [9] er en TTP definert som: A security authority, or its agent, trusted by other entities with respect to security related activities. 7 av 24

9 Figur : Roller i AutoPASS-systemene Utsteder og Operatør Utstederrollen er relatert til alt som har å gjøre med å levere en betalingstjeneste til brukerne (kundene). I det norske AutoPASS-systemet deles denne rollen per i dag av to aktører: ) Statens vegvesen som eier alle AutoPASS-brikker og 2) det bompengeselskapet som har retten til og ansvaret for å kreve inn bompenger iht. avtaler med Statens vegvesen. Operatørrollen omfatter alle aktører som er involvert i å drive betalingssystemet. Gjennomføring av innkrevingen og håndtering av avvik, f.eks. passering av innkrevingspunktet uten betaling, hører også til denne rollen. I det norske AutoPASS-systemet deles denne rollen per i dag av to aktører: ) Statens vegvesen som er eier av alt innkrevingsutstyr på innkrevingspunktet (ev. punktene) og 2) det bompengeselskapet som har retten til å kreve inn bompenger iht. avtaler med Statens vegvesen. Mht. sikkerhet er følgende ansvarsområder sentrale for begge disse to rollene: Implementere og oppfylle alle de sikkerhetskravene som gjelder for AutoPASS inkludert personvern Kommunisere på en sikker måte med aktører som er involvert i bompengesystemet, f.eks. Utsteder eller Operatør og Tiltrodd Tredjepart. Bruker Brukeren er knyttet til bruken av en transporttjeneste, f.eks. bruken av en avgiftsbelagt bru, og til bruken av betalingssystemet, dvs. AutoPASS-systemet. Brukerrollen er gjerne delt mellom to aktører: ) eieren av kjøretøyet og 2) føreren av kjøretøyet. Mht. sikkerhet kan brukeren, som ihendehaver av AutoPASSbrikken, være en kritisk rolle. Brukeren har tilgang til brikken og kan eventuelt kopiere eller manipulere informasjon som ligger lagret på brikken. Brikken betraktes derfor av mange som det mest sårbare aktivum i et EFC system selv om bruker gjennom sin avtale med Utstederen forplikter seg til å ikke prøve på å skaffe seg tilgang på informasjon lagret på brikken. Samordningsorgan Denne rollen er knyttet til alt som har med samordningen av alle AutoPASS-systemene. Denne rollen omfatter følgende ansvarsområder i relasjon til sikkerhet: Definere sikkerhetspolicy inkludert personvern for AutoPASS-systemene og opptre som sikkerhetsansvarlig for alle AutoPASS-systemer 8 av 24

10 Definere og vedlikeholde register over aktører og utstyr som er involvert i AutoPASS-systemene (f.eks. nummerregister for AutoPASS-brikker og Utstedere) og tildeling av unike ID-er for aktører og utstyr som trenger slik ID. Definere kravene til teknisk og funksjonell samordning av AutoPASS-utstyr (AutoPASSspesifikasjonene) inkludert krav til sikkerhet Kontrollere og godkjenne aktører og utstyr som skal være involvert i AutoPASS-systemene inkludert definere kravene til godkjenning I Norge har Statens vegvesen rollen som Samordningsorgan. Driftsoperatør En Driftsoperatør utfører noen av Utsteders og Operatørens oppgaver iht. inngått avtale. Mht. sikkerhet gjelder selvfølgelig de samme kravene for Driftsoperatørene som for hhv. Utsteder og Operatør. Bro- og Tunnelselskapet i Bergen og Vegamot i Trondheim er eksempler på norske Driftsoperatører. Tiltrodd Tredjepart (TTP) En TTP i samordnede EFC systemer vil vanligvis være sterkt knyttet til håndtering av sikkerhetsnøkler. Med (sikkerhets)nøkkel menes en sekvens av symboler som kontrollerer utførelsen av en kryptografisk transformasjon, for eksempel kryptering eller dekryptering (ISO ). Nøkkelhåndtering er i ISO/IEC 770- Information technology - Security techniques - Key management - Part : Framework definert som: The administration and use of the generation, registration, certification, deregistration, distribution, installation, storage, archiving, revocation, derivation and destruction of keying material in accordance with a security policy. Av de aktivitetene som er definert til å være aktiviteter innenfor nøkkelhåndtering, er det 3 som er viktigere enn andre: Generering av nøkler. Nøkkelens sikkerhet er essensiell. Kryptografiske nøkler skal være tilfeldig (eller pseudo-tilfeldig) generert eller kryptografisk utledet fra andre nøkler. Distribusjon og installering av nøkler. Nøkkeldistribusjon og installering av nøkler er den prosessen hvor en nøkkel manuelt eller elektronisk er overført til en sikker kryptografisk enhet, for eksempel utstyr for å initialisere en AutoPASS-brikke. Lagring av nøkler. Alle kryptografiske nøkler skal være beskyttet under lagring. De tre aktivitetene som er listet opp ovenfor er i tillegg til utstedelse av unike ID-er til alle typer aktører og aktiva i norske AutoPASS-systemer tjenester som utføres av en norsk leverandør av sikkerhetstjenester. I AutoPASS har hver Utsteder to sett med unike Masterkeys. Disse Masterkeys brukes til å utlede unike nøkler til hver enkelt AutoPASS-brikke som igjen brukes til å utlede unike sesjonsnøkler. Det siste vil si at hver gang en brikke gjennomfører en kommunikasjon med vegkantutstyret i en bomstasjon utledes det et sett med nøkler som er unike for denne kommunikasjonen. Dette er en forutsetning for en av de viktigste sikkerhetsmekanismene i AutoPASS som er generering av Message Authentication Codes (MAC). Dette er beskrevet senere i denne rapporten. 9 av 24

11 5 Trusler i EFC systemer 5. AutoPASS Da AutoPASS-spesifikasjonene ble utarbeidet i ble det gjennomført en trusselanalyse. Baksystemene ble ansett som relativt sikre aktiva og trusselanalysen fokuserte derfor mest på selve AutoPASS-brikken og grensesnittet mellom brikke og vegkantutstyr. Følgende trusler ble den gangen sett på som vesentlige: AutoPASS-brikken Etterligning (engelsk: impersonation) som betyr at en brikke opptrer som en annen brikke enten ved å bruke identiteten til en annen brikke eller ved å bruke en falsk identitet. Tukling (engelsk: tampering) som betyr at den som har en brikke skaffer seg adgang til brikkens innhold og manipulerer informasjonen som er lagret på brikken, for eksempel brikkens identitet eller sikkerhetsnøkler. Fornektelse (engelsk: denial) betyr at brukeren hevder at han aldri har benyttet en transporttjeneste; Jeg har aldri passert i den bomstasjonen. Kommunikasjon mellom brikke og vegkant avlytting, dvs. innsamling av informasjon som utveksles mellom brikke og vegkantutstyr for senere bruk av informasjonen, f.eks. til etterligning manipulering av data, dvs. forsøk på å endre data som sendes til eller fra brikken replay av data, dvs. man sender data fra en tidligere transaksjon. forstyrring av kommunikasjonen, dvs. handlinger som kan karakteriseres som sabotasje Vegkantutstyr endring av utstyr og programvare i den hensikt å sabotere funksjonaliteten avdekking av følsom informasjon, for eksempel passeringsdata modifisering av data enten ut i fra ønske om å sabotere eller å oppnå en økonomisk gevinst, eksempelvis generere falske passeringer sabotasje, vandalisme og tyveri Personvern innsamling og behandling av personlige data, f.eks. passeringsdata 5.2 EasyGo I [3] er det gjennomført trusselanalyser for EFC systemer ved hjelp av to metodikker: en såkalt 'Attack-tree' analyse og en aktiva basert analyse. Disse to metodikkene ble anvendt i EasyGo (20) for en trusselanalyse av de EFC systemene som inngår i EasyGo samarbeidet [4]. Av de 9 ulike typene angripere som ble beskrevet i [3] ble følgende 5 sett som potensielle angripere i EasyGo systemer (i prioritert rekkefølge): Hacker En hacker er definert som en angriper som forsøker å trenge inn i EFC systemet uten å ha noen Transaksjon er i EN ISO 4906 definert som: whole of the exchange of information between roadside equipment and the on-board equipment and the user/vehicle. 0 av 24

12 økonomisk motivasjon. En hacker beskrives gjennom god intellekt, iherdighet og et ønske om å demonstrere og publisere sine forsøk og oppnådde inntrenginger. En hacker vil kunne oppleve at hackerens resultater benyttes av andre typer angripere som har andre motiver for sine angrep, for eksempel økonomiske eller politiske. For hackeren ble det definert 7 trusler. Disse truslene omfattet hackerens ønske om å vise EFC systemet sine sårbarheter, oppnå respekt i hackermiljøet, øke sin kunnskap om systemet og å fremstille falske brikker. Aktivist En aktivist er definert som en spesielt aktiv forkjemper for en sak, for eksempel en politisk sak og som eventuelt vil benytte vold, sivil ulydighet eller kriminelle handlinger for å nå sine mål. Terrorister hører til denne typen angripere. En aktivist kan være interessert i å misbruke eller manipulere EFC systemet til sette søkelyset på eller å realisere sine politiske mål selv om det politiske målet ikke har noe med EFC systemet å gjøre. For aktivisten er gjerne publisitet et viktig mål og store aktivistskapte forstyrrelser i et system kan være en måte å skaffe seg publisitet. En aktivist eller en gruppe aktivister som er i mot vegavgiftssystemer kan for eksempel angripe slike systemer for å vise funksjonelle og personvernmessige svakheter. Aktivisten er sjelden interessert i å skjule sin identitet. For aktivisten ble det definert 5 trusler som i hovedsak omfattet aktivistens motivasjon om å redusere systemets troverdighet. Brukeren Brukeren er definert som en person som er forpliktet til å betale en avgift for en transporttjeneste, for eksempel en bomavgift. Brukeren kan være en person, et selskap eller annen juridisk enhet. Brukeren inkluderer også føreren av kjøretøyet (selv om det er noen andre som betaler avgiften) og enhver annen person som måtte ha tilgang til brikken. For brukeren ble det definert 6 trusler som i hovedsak omfattet brukerens ønske om å manipulere systemet til ikke å registrere bruken av transporttjenesten, oppgi falske kjøretøyparametere og manipulere systemet til å miste informasjon om bruken av transporttjenesten. Virksomheter Virksomheter omfatter alle typer organisasjoner med gitte finansielle, tekniske og personellmessige resurser. Denne gruppen omfatter generelle kommersielle virksomheter av både lovlig og ulovlig natur som bruker sine ressurser til å oppnå spesielle fordeler gjennom sitt angrep på EFC systemet. For virksomheter ble det definert 9 trusler. Disse omfattet i hovedsak å fremstille og distribuere/selge klonede brikker, stjele utstyr, registrere reisemønster for enkeltindivider, sette ut av spill/gjøre offentlig kjent krypteringsalgoritmer og nøkler og å drive utpressing basert på innsamlet informasjon. Operatør Operatøren (toll charger) er den juridiske enheten som er ansvarlig for å kreve inn avgiften for en transporttjeneste. Motivasjonen for en Operatør til å angripe EFC systemet kan være å forenkle driften av systemet eller generere falske transaksjoner eller beregne en avgift som er høyere enn det brukeren formelt sett skulle betalt. De kan også bruke innsamlet informasjon til andre formål enn det som er den egentlige hensikten, for eksempel selge informasjon videre til en tredje part som kan bruke informasjonen til markedsføring eller til mer tvilsomme eller uærlige formål. For Operatøren ble det definert 8 trusler knyttet til det å øke sin egen inntekt. Med hensyn til den aktivabaserte trusselanalysen ble følgende aktiva funnet å være relevante for trusler i EasyGo systemet: Personvern (4 definerte trusler) Operatørens omdømme og ansikt utad (7 definerte trusler) Fysiske enheter o Kjøretøyenhet (20 definerte trusler) o Vegkantutstyr ( definerte trusler) o Sentralsystem av 24

13 Operatørens sentralsystem (3 trusler definert) Utsteders sentralsystem (2 definerte trusler) Risiko beregnes som sannsynligheten for at en sikkerhetsmessig uønsket hendelse skal inntreffe multiplisert med konsekvensene som følger av en slik hendelse. Det ble gjennomført en risikoanalyse for alle de definerte truslene i EasyGo (totalt 38 trusler) basert på metodikken i Datatilsynet sin veileder for slike analyser [5]. Av de 38 truslene medførte 28 trusler et risikonivå som var over det nivået som ble funnet som akseptabelt risikonivå for uønskede sikkerhetsmessige hendelser i EasyGo systemet. For å redusere risikonivået for disse 28 truslene ned til et akseptabelt nivå ble det utarbeidet et felles sett med 48 sikkerhetskrav som representerte et minimumsnivå som alle EasyGo systemer skulle oppfylle. For å evaluere de ulike EasyGo systemene opp mot disse sikkerhetskravene ble det gjennomført en gap analyse, dvs. det ble vurdert om det var noen gap mellom disse sikkerhetskravene og de sikkerhetstiltakene og sikkerhetsmekanismene som var implementert i de ulike EasyGo systemene. For AutoPASS-systemet gjennomførte Statens vegvesen en slik gapanalyse og denne ble i ettertid kvalitetssikret av ekspertise innenfor norske bompengeselskaper. Gap analysen viste at AutoPASS med noen meget få og mindre vesentlige unntak oppfylte alle sikkerhetskravene som var definert i EasyGo. 6 Sikkerhet i AutoPASS-brikken 6. Sikkerhetsnøkler Den viktigste sikkerhetsmekanismen i AutoPASS-systemet er AutoPASS-brikkens beregning av meldingsautentiseringskoder (Message Authentication Code (MAC)). Disse kodene brukes til å autentisere AutoPASS-brikken og å sikre integritet på data fra Utsteder via Operatør tilbake til Utsteder. Beregningen av MAC bruker sikkerhetsnøkler som er lagret i AutoPASS brikken. Det beregnes to ulike MAC-er ved en hver gjennomført AutoPASS-transaksjon i et innkrevingssted (for eksempel en bomstasjon) og det brukes to ulike nøkler til dette. Det må derfor lagres to sett med nøkler i brikken til disse beregningene. Hver Utsteder har to sett med såkalte Masterkeys (MKEY) og hvert sett består av 5 unike nøkler. Hensikten med 5 nøkler er at nøklene skal kunne skiftes ut, enten ved periodisk utskifting eller dersom en nøkkel skulle kompromitteres. Det ene settet med nøkler brukes bare i Utsteders eget system og kalles derfor for Native nøkler. Det andre settet brukes for å sende Masterkeys til andre Operatører og kalles derfor for Foreign nøkler. Utsteder vil aldri sende mer enn en MKEY-F til andre Operatører for å redusere risikoen for kompromittering av hele nøkkelsettet. Utsteder bruker de to settene med MKEYs når en AutoPASS-brikke initialiseres (i praksis gjøres dette gjerne av leverandøren av brikke, men det er Utsteders ansvar at det blir gjort riktig). De to settene med MKEYS brukes for å utlede (triple-des) brikkespesifikke nøkler som lagres på en sikker måte i brikken. Disse nøklene kalles OBUKEY-N og OBUKEY-F og det er altså fem nøkler av hver type i AutoPASS-brikken. For å utlede OBUKEY brukes brikkens unike ID som inngangsparameter og dette betyr at alle brikker har ulike sett med nøkler. Algoritmen som brukes for å beregne OBUKEY (triple-des) sikrer at det ikke er mulig å regne baklengs slik at selv om man har klart å lese ut brikke ID og OBUKEY (som skal være lagret på en meget sikker måte) er det ikke mulig å regne ut MKEY. Når brikken skal beregne de to MAC-ene bruker den OBUKEY-N og OBUKEY-F til å utlede en tredje type nøkkel som brukes kun en gang, nemlig i den aktuelle transaksjonen mellom brikke og vegkantutstyr. Denne nøkkelen kalles Session key (SSKEY) og ved utledningen av denne nøkkelen brukes et tilfeldig tall sent av vegkantutstyret (RND-) og tiden for transaksjonsøyeblikket (med /00 dels sekunds oppløsning). Det betyr at SSKEY er unik og er tidsstemplet. På samme måte som for OBUKEY kan det ikke regnes baklengs slik at 2 av 24

14 selv om SSKEY, det tilfeldige tallet og tiden er kjent er det ikke mulig å beregne OBUKEY. Se forøvrig Figur 2. Figur 2: Nøkkelhierarkiet i AutoPASS-systemene 6.2 Meldingsautentiseringskodene Meldingsautentiseringskodene (MAC) er de mest sentrale sikkerhetsmekanismene i AutoPASS. Ved alle gjennomførte AutoPASS-transaksjoner mellom brikke og vegkantutstyr beregner og overfører brikken 2 ulike MAC til vegkantutstyret, - MAC som er beregnet med bruk av SSKEY-N og MAC2 som er beregnet med bruk av SSKEY-F. Begge MAC-ene har brukt brikkens unike identitet, brikkens status, verdien på brikkens interne transaksjonsteller og et tilfeldig tall generert av brikken (RND-2) som inngangsdata for beregning av hhv. MAC og MAC2. MAC-ene gjør det mulig å kontrollere følgende forhold: Brikkens unike identitet er den som Utsteder opprinnelig har gitt den og at den ikke er endret siden utstedelsen, verken av brukeren eller Operatøren eller av noen andre som måtte kunne ha tilgang til brikken. Falske brikker vil generere en MAC og MAC2 som ikke vil stemme overens med de MAC og MAC2 som Operatører og Utsteder vil beregne (gitt at den som har produsert den falske brikken ikke har hatt tilgang til begge MKEY). Slike brikker vil derfor utløse avvikshåndtering med lagring av et bilde av kjøretøyets nummerskilt. Brukeren kan ikke benekte at brikken har vært brukt på et bestemt tidspunkt siden tidsstempelet inngår som en del beregningen av SSKEY og dermed MAC og 2. Et gitt tidspunkt vil gi en helt bestemt og unik MAC og ingen andre tidspunkt vil kunne gi den samme MAC for den samme brikken. Figur 3 viser på en veldig forenklet måte hovedprosessene i en standard AutoPASS-transaksjon mellom vegkantutstyret og AutoPASS-brikken. Vegkantutstyret sender en kommando (GET_SECURE.request) til AutoPASS-brikken. I denne kommandoen ligger det inkludert noen data som AutoPASS-brikken skal bruke når den returnerer de data (GET_SECURE.response) som skal brukes for belaste brukeren for en avgift og de data som inngår som en del av sikkerhetstiltakene og sikkerhetsmekanismene i AutoPASS. 3 av 24

15 Figur 3: 'Hovedprosesser' i en normal AutoPASS transaksjon 6.3 Tilgang på data i AutoPASS-brikken AutoPASS er en offentlig kjent spesifikasjon og teoretisk sett kan hvem som helst bygge sitt eget vegkantutstyr og kommunisere med passerende AutoPASS-brikker. I praksis er det bare store leverandører av slikt utstyr som har ressurser til å utvikle og produsere vegkantutstyr. Tilgjengeligheten til data på brikken er ikke begrenset (selvfølgelig med unntak av sikkerhetsnøklene som er godt sikret). Dette valget ble gjort da AutoPASS-spesifikasjonene ble utviklet for at brikken skulle kunne brukes til andre applikasjoner, for eksempel parkering og reisetidsmålinger, uten at dette krevde et adgangskontrollsystem i brikken med et tilhørende system for nøkkelhåndtering. De data som er kritiske mht. data integritet og beregning av avgift, eksempelvis brikkens unike identitet, kan bare leses og ikke endres uten at hele brikken initialiseres på nytt. Tanken bak AutoPASS sitt sikkerhetsregime var også at deler av sikkerhetstiltakene ikke nødvendigvis var nødvendig å innføre ved oppstarten av AutoPASS. Kontrollen av MAC2 som gjøres av Operatør og som betinger at MKEY-F er lagret i vegkantutstyret, var ett av de tiltakene som kunne innføres gradvis. Falske brikker vil uansett bli fanget opp av Utsteder gjennom kontroll av MAC slik at den falske brikken (egen id eller klonet id) kunne bli svartelistet og merket med flagg om lagring av bilde fra de innkrevingspunktene hvor den falske brikken ble forsøkt brukt. 4 av 24

16 7 Sikkerhet i en brikke (OBE) med EFC applikasjon basert på EN To sikkerhetsnivå Den europeiske standarden EN 5509 Electronic fee collection Interoperability application profile for DSRC [8] beskriver to ulike sikkerhetsnivåer kalt Nivå 0 og Nivå. Nivå 0 krever at brikken skal kunne beregne en meldingsautentiseringskode for en melding som er satt sammen av utvalgte dataelementer lagret i brikken. Denne koden skal beregnes iht. [6]. I EN 5509 er det vist hvordan en beregner denne MAC-en med dataelementet Payment Means, som eksempelvis kan være en kredittkortkonto eller en konto hos en Utsteder, og et tilfeldig tall sendt fra vegkantutstyret til brikken. Nivå krever at brikken skal kunne gjennomføre en autentisering av vegkantutstyret før den lar vegkantutstyret få tilgang til data på brikken og gjøre operasjoner med disse. Dette skjer ved at brikken sender et tilfeldig tall og en nøkkelreferanse til vegkantutstyret som bruker disse dataene til å beregne en såkalt Access Credentials (AC_CR). Vegkantutstyret bruker nøkkelreferansen til en Masterkey for adgangskontroll lagret i vegkantutstyret til å beregne AC_CR. Vegkantutstyret sender deretter AC_CR som 'vedlegg' til en kommando til brikken om å få returnert nødvendige data som er lagret i brikken. Brikken har i mellomtiden beregnet AC_CR og sammenligner sin egen AC_CR med den som vegkantutstyret har beregnet og sendt til brikken. Dersom vegkantutstyret ikke har implementert Nivå, ikke har riktig Masterkey for adgangskontroll eller har brukt en feil generasjon av nøkkelen vil de to AC_CR ikke stemme overens og brikken vil ikke tillate vegkantutstyret å lese ut data eller å skrive nye data til brikken. Hensikten med denne sikkerhetsmekanismen er å hindre ikke-autorisert lesing av data som er beskyttet på brikken og/eller å hindre at brikken brukes i andre kommersielle sammenhenger som ikke er i henhold til avtale med Utstederen av brikken. 7.2 Sikkerhetsnøkler i EN Nøkler for beregning av MAC Iht. [8] ligger det 8 sikkerhetsnøkler lagret på sikker måte i brikken. Disse skal brukes til å beregne MAC over ønsket informasjon som leses av vegkantutstyret fra brikken. Utstederen bestemmer hvilke av disse 8 nøklene som skal gjøres kjent for andre Operatører. På samme måte som i AutoPASS kan det derfor defineres Utstedernøkler og Operatørnøkler. Tabellen nedenfor viser en sammenligning av de nøklene som er lagret i brikken iht. AutoPASS-spesifikasjonene og EN AutoPASS EN 5509 Navn på nøkkel Antall Navn på Navn på nøkkel for Antall Navn på MAC for beregning av MAC nøkler i OBE MAC beregning av MAC nøkler i OBE Utsteder OBUKEY-N 5 MAC AuthenticationKey-8 8 AttributeAuthenticator Operatør OBUKEY-F 5 MAC2 I utkastet til [3] er det gått litt lenger mht å definere bruk av AuthenticationKey 8. For det første krever standarden at for å oppnå en tilfredsstillende sikkerhet i samordnede EFC systemer skal både OBE (kjøretøyenhet) og RSE (vegkantutstyr) oppfylle kravene til Nivå. Videre har standarden krav om at RSE skal be om MAC-TSP som tilsvarer MAC i AutoPASS og om MAC-TC som tilsvarer MAC2 i AutoPASS. Begge MAC-ene skal beregnes over minimum den attributten som kalles PaymentMeans. RSE skal bruke en av de fire første AuthenticationKey til å beregne MAC-TSP og en av de fire siste til MAC-TC. Dette var 5 av 24

17 opprinnelig ikke beskrevet i EN 5509 så her kan det se ut som om AutoPASS har vært førende mht. sikkerhetsmekanismer som muliggjør et skille mellom Utsteder og Operatør. Dersom en tar inn de kravene som ligger i [3] vil den ovenstående tabellen se slik ut: AutoPASS EN ny standard Security Framework Navn på nøkkel for beregning av MAC Antall nøkler Navn på MAC Navn på nøkkel for beregning av MAC Antall nøkler Navn på MAC Utsteder OBUKEY-N 5 MAC AuthenticationKey-4 4 MAC-TSP Operatør OBUKEY-F 5 MAC2 AuthenticationKey5-8 4 MAC-TC AuthenticationKey (AuK) utledes fra en Master Authentication Key (MAuK) som Utsteder har. Ved å bruke en spesiell algoritme som er definert i EN 5509 beregnes en såkalt Compact_PersonalAccountNumber med utgangspunkt i dataelementet PaymentMeans som kan være en bankkonto, kredittkortkonto eller en Utstederrelatert sentral konto som brikken er knyttet til. Den kan derfor sammenlignes med AutoPASSbrikkens unike identitet som er en peker til en sentral konto hos en Utsteder. En sentral konto kan teoretisk være den samme hos to Utstedere og for å unngå å få samme AuthenticationKey hos to ulike Utstedere brukes også Utstederens unike identitet for å utlede AuthenticationKey ved hjelp av en Trippel-DES algoritme Nøkler for adgangskontroll Nivå betinger adgangskontroll til brikken. I brikken ligger det derfor en nøkkel kalt AccessKey (AcK). Denne er utledet fra en Master Access Key (MAcK) av en gitt nøkkelreferanse hvor nøkkelreferansen består av referansen til en gitt generasjon av Masterkey og data (diversifier) som skal brukes ved utleding av adgangskontrollnøkkelen (Trippel-DES). I starten av kommunikasjonen mellom brikke og vegkant sender brikken nøkkelreferansen til vegkantutstyret sammen med et tilfeldig tall. Vegkantutstyret har lagret en eller flere Master Access Keys og velger den samme nøkkelen som er brukt ved initialisering av brikken og beregner så den AccessKey som ligger i brikken. Deretter beregner vegkantutstyret en kode (Access Credentials) ved hjelp av det tilfeldige tallet som brikken sendte til vegkantutstyret. Denne koden sendes tilbake sammen med forespørsel om å lese ut data fra brikken. Dersom koden er den samme som brikken i mellomtiden har regnet ut vil vegkantutstyret få adgang til de etterspurte data på brikken. Figur 4: Nøkkelhierarkiet i EFC systemer basert på EN av 24

18 Figur 5 viser på samme måte som Figur 3 de viktigste prosessene i en EN 5509 basert transaksjon. Figur 5: Adgangskontroll og henting av data fra en brikke med EN 5509 applikasjon 7 av 24

19 8 Sammenligning av sikkerheten i AutoPASS og brikker med EN 5509 EFC applikasjon 8. Meldingsautentiseringskoder (MACs) Både AutoPASS-brikken og en brikke med EN 5509 applikasjonen kan generere MAC-er som er en meget viktig sikkerhetsmekanisme mht. autentisering av brikken og mht. dataintegritet i hele kjeden fra Utsteder til bruker (brikken), videre til Operatør og til slutt tilbake til Utsteder. I AutoPASS genereres det to MAC over fire dataelementer som er lagret/generert i brikken: obuid (unik brikke id) efcstatus (indikasjon på flyttet brikke eller lavt batteri) TC (Transaction Counter) (intern transaksjonsteller i brikken) RND-2 (Random Number 2) (tilfeldig tall generert av brikken) De to MAC-ene er beregnet med en Utstederspesifikk sikkerhetsnøkkel som bare Utsteder kjenner og en Operatørnøkkel som Utsteder har distribuert til Operatørene slik at de kan kontrollere om brikken er ekte eller ikke i det øyeblikket brikken brukes i Operatørens innkrevingssystem. Ved hjelp av en kommando (GET_SECURE.request) leverer brikken en melding som inneholder de fire dataelementene listet opp ovenfor og de to MAC-ene (pluss noen andre data). For å beregne MAC-ene brukes en sesjonsnøkkel hvor tidspunktet for transaksjonen og et tilfeldig tall sendt fra vegkantutstyret inngår som inngangsdata for beregningen av nøkkelen. En brikke med EN 5509 applikasjon kan også generere MAC-er over ett eller flere dataelementer. I dette tilfellet brukes kommandoen GET_STAMPED.request som inneholder en liste over de dataelementene som brikken skal bruke som inngangsdata i beregningen av en MAC. For å få to MAC-er beregnet med en Utstedernøkkel (AuthenticationKey 4) og en Operatør nøkkel (AuthenticationKey 5 8) må vegkantutstyret sende samme kommandoen to ganger, men med ulik nøkkelreferanse (hhv. ref. til Utstedernøkkel og ref. til Operatørnøkkel). I prinsippet kan altså en brikke med en EN 5509 applikasjon generere en MAC over de samme data som AutoPASS-brikken gjør med unntak av det tilfeldige tallet som en AutoPASS-brikke generer for hver transaksjon. Ved å be om EqupmentOBUId og EquipmentStatus (inkludert transaksjonsteller) og en MAC beregnet enten med Utstedernøkkel eller Operatør nøkkel kan en få EN 5509 MAC-er som tilsvarer de MAC-ene som beregnes i AutoPASS. En viktig forskjell mellom de to MAC-ene er at en AutoPASS MAC er beregnet med en sesjonsnøkkel som utledes i transaksjonsøyeblikket, mens en EN 5509 AuthenticationKey ligger lagret i brikken og er således mer utsatt mht. kompromittering. Dette kompenseres delvis ved at vegkantutstyret med EN 5509 applikasjon sender transaksjonsøyeblikket til brikken slik at dette skal inngå i den MAC-en som beregnes. I AutoPASS inngår altså transaksjonsøyeblikket i utledningen av sesjonsnøkkelen som brukes til å beregne MAC, mens i EN 5509 baserte EFC systemer inngår transaksjonsøyeblikket som en del av de data det skal beregnes en MAC over. I hvilken grad denne forskjellen utgjør vesentlige forskjeller mht. risiko ligger utenfor denne rapportens omfang. 8 av 24

20 8.2 Adgang til data på brikken I AutoPASS er det ikke adgangskontroll til data som ligger lagret på brikken av årsaker som er forklart tidligere. I EN 5509 baserte systemer kan det opereres med og uten adgangskontroll, men i [3] er det et krav til europeiske interoperable EFC systemer at både OBE (kjøretøyenhet) og RSE (vegkantutstyr) skal oppfylle kravene til Nivå i EN 5509, dvs. adgangskontroll. I AutoPASS kan følgende sentrale data leses fra brikken uten adgangskontroll: obuid (unik brikke id) efcstatus (indikasjon på flyttet brikke eller lavt batteri) TC (Transaction Counter) (intern transaksjonsteller i brikken) I EN 5509 baserte EFC systemer kan vegkantutstyret lese ut følgende sentrale data (som iht. EN 5509 skal ligge lagret på brikken): PaymentMeans som inkluderer Personal Account Number (PAN), utløpsdato for PAN og hvordan PaymentMeans skal brukes. PAN kodes iht. til []. PaymentMeans kan også brukes til å lagre informasjon om Utsteders sentrale konto, men vil i så fall ikke være 00 % iht. [0]. Kjøretøyets registreringsnummer Kjøretøyklasse Kjøretøyets dimensjoner Antall akslinger Vektbegrensninger for kjøretøyet EquipmentOBUId som er en unik kode for brikken EquipmentStatus inkludert transaksjonsteller Kvittering (transaksjonsdata fra passering av siste innkrevingspunkt) Kvittering 2 (transaksjonsdata fra passering av nest siste innkrevingspunkt) I tillegg kan flere data leses ut fra både en AutoPASS-brikke og en EN 5509 brikke i initialiseringsfasen mellom brikke og vegkantutstyr, men de er ikke tatt med her (kan alltid leses ut uten adgangskontroll for alle EFC systemer). Det er relativt opplagt at PAN med utløpsdato kan være mer sensitiv informasjon enn den brikkeidentiteten som alle kan lese ut fra AutoPASS-brikken. Det er derfor forståelig at det på europeisk nivå er satt krav til adgangskontroll på slike data lagret i EN 5509 kompatible brikker. I noen systemer brukes PAN, for eksempel i Spania og Portugal, og da gjerne knyttet til den som har inngått avtale med Utsteder om bruk av brikken. PAN kan i slike tilfeller være brukerens personlige bankkonto eller kredittkortkonto og det er forståelig at slik informasjon bør beskyttes av hensyn til å sikre brukerens økonomiske integritet. Data om siste passeringer kan også kunne betraktes som informasjon som ikke skal kunne leses av hvem som helst selv om dette er data som kan krypteres av en Operatør som for eksempel leser ut fra brikken når kjøretøyet med brikke kjørte inn i et lukket bompengesystem, jfr. det italienske nasjonalt samordnede bompengesystemet. Data om siste passeringer kunne tidligere leses ut fra AutoPASS-brikken, men Datatilsynet mente at fri lesing av slike data ikke var iht. Personopplysningsloven. 8.3 Transaksjonsteller Transaksjonstelleren er en viktig sikkerhetsmekanisme mht. å detektere hull i brikkens gjennomførte transaksjoner eller eventuelt å oppdage transaksjoner med samme verdi på transaksjonsteller. Iht. AutoPASS-spesifikasjonen er det AutoPASS-brikken selv som skal oppdatere verdien på transaksjonstelleren, mens det i EN 5509 baserte systemer er vegkantutstyret som skal oppdatere verdien på denne telleren. Det åpner muligheten for at en Operatør kan manipulere transaksjonstelleren hvilket ikke er 9 av 24

21 mulig i AutoPASS-systemer. I AutoPASS-systemet inngår verdien på transaksjonstelleren i de data som sikres med en MAC, mens i EN 5509 baserte systemer må vegkantutstyret inkludere dataelementet EquipmentStatus i listen over data som skal sikres med autentisering (MAC). 8.4 Kvalitet på meldingsutveksling mellom brikke og vegkantutstyr En AutoPASS-transaksjon er meget rask og består av fire meldingsutvekslinger mellom vegkantutstyr og brikke: Beacon Service Table (BST), Vehicle Service Table (VST), Get_SECURE.request og GET_SECURE.respons. En meldingsutveksling iht. EN 5509 er vesentlig lengre dersom de samme dataene skal oversendes. Dersom det skal hentes to MAC-er vil dette kreve følgende meldingsutveksling: BST, VST, GET_STAMPED.request med Utstedernøkkel, GET_STAMPED.respons med Utstedernøkkel, GET_STAMPED.request med Operatørnøkkel, GET_STAMPED.respons med Operatørnøkkel, SET.request for å sette ny brikkestatus og ny verdi på transaksjonstelleren og SET.response. Jo flere meldinger som skal utvikles og kommuniseres innenfor en meget knapp tidsramme i et innkrevingspunkt med høy trafikkhastighet, jo større sannsynlighet er det for at det skal kunne skje feil i meldingsutvekslingen eller at den ikke blir avsluttet på riktig måte. Dette var en av årsakene til at en i AutoPASS valgte å komprimere hele meldingsutvekslingen mest mulig gjennom kommandoen GET_SECURE. Dette satte høyere krav til prosessorkapasitet og hastighet i brikken, men det ble vurdert som en bedre og sikrere løsning å ha en litt 'kraftig' brikke for å redusere kommunikasjonsbehovet mellom vegkant og brikke. Så vidt vi kjenner til er AutoPASS den eneste EFC applikasjonen i verden som bruker GET_SECURE kommandoen. 9 Sikkerhet i hele verdikjeden Figur 6 viser en oversikt over de viktigste sikkerhetstiltakene i AutoPASS. Utsteder (eventuelt leverandør og TTP i samarbeid) initialiserer en AutoPASS-brikke med en unik identitet som ikke kan endres, unike brikkenøkler (OBUKEYs) som er utledet fra Utsteders masternøkler for seg selv og tilsluttede Operatører. I tillegg initialiseres også transaksjonstelleren. Ved bruk av brikken i et AutoPASS innkrevingssystem drevet av en Operatør vil brikkene utlede sesjonsnøkler hvor transaksjonsøyeblikket inngår som en del av data som skal brukes ved utleding av sesjonsnøkkelen. Sesjonsnøkkelen brukes til å beregne MAC som kan kontrolleres av Utsteder (og kun Utsteder) og MAC som kan kontrolleres av Operatør. Brikken sender deretter over sentrale data og de to MAC-ene (se Figur 6) til Operatørens vegkantutstyr. Operatøren kan ved hjelp av data som er sendt over og sin egen Masterkey for Operatører kontrollere den MAC-en som brikken har sendt fra seg. Dersom denne MAC-en ikke stemmer overens med den Operatør MAC-en som brikken har sendt fra seg, blir ikke brikkens identitet godtatt og passeringen blir gjenstand for en avvikshåndtering. Operatøren sender et krav til Utsteder med beregnet avgift som skal betales sammen med de data som Utsteder trenger for å beregne MAC-er for Utsteder. Ved å beregne sin egen MAC og sammenlikne denne med den MAC-en som Operatøren har sendt til Utsteder, vil Utsteder kunne kontrollere at brikkens identitet er riktig, dvs. en av Utsteders egne brikker. Det vil også si at det transaksjonsøyeblikket som er sendt som en del av kravet til Utsteder er verifisert slik at en bruker ikke kan benekte at brikken har passert et innkrevingspunkt på et bestemt tidspunkt. Utsteders MAC sikrer også dataintegritet gjennom hele verdikjeden fra og med transaksjonsøyeblikket til transaksjonen er kontrollert i Utsteders sentralsystem. Operatøren kan ikke endre på vesentlige data i kravet sitt uten at dette vil bli avslørt av Utsteder og Operatøren kan heller ikke generere sine egne transaksjoner siden Operatøren ikke har tilgang til Utsteders sikkerhetsnøkler. 20 av 24

22 Utsteder vil utstede statuslister til Operatøren som legger disse ut i vegkantutstyret slik at vegkantutstyret kan gjøre oppslag i statuslisten når en AutoPASS-brikke passerer. Statuslisten vil inneholde informasjon om brikker som ikke har vist normal funksjonalitet eller mistanke om brudd på sikkerhetsmekanismer og vil være en viktig del av hele sikkerhetsregime for AutoPASS. Figur 6: Prinsipp for gjennomgående sikkerhet i AutoPASS 0 Europeiske løsninger Det har ikke så mye hensikt å se på hva andre europeiske systemer har innført av sikkerhetsløsninger fordi det varierer mye fra nasjon til nasjon og system til system mht. hva som er satt som akseptable risikonivå. Med noen få unntak av nyere systemer, for eksempel det tyske Toll Collect systemet, er det et inntrykk at det akseptable risikonivået er relativt høyt. Sånn sett har Norge og AutoPASS systemet vært et foregangsland mht. sikkerhet i EFC systemer og sine lave akseptable risikonivå og det er lett å se hvordan noe av de viktige prinsippene i AutoPASS også har funnet sin form i EN 5509 standarden. Det som kan være viktig å se på er imidlertid de kravene som er beskrevet i [3]. Standarden har bl.a. spesifikke sikkerhetskrav til kommunikasjon mellom Utsteder og Operatør og spesifikke sikkerhetskrav til kommunikasjonen mellom vegkantutstyr og brikke. Kravene til kommunikasjon mellom Operatør og Utsteder er meget omfattende og krever spesiell kompetanse innenfor informasjonssikkerhet for å kunne forstå og det vises derfor til [3] for mer detaljert informasjon. Kravene til kommunikasjonen mellom vegkantutstyr og brikke er imidlertid lettere å forstå og er gjengitt i sin helhet nedenfor. EFC direktivet med tilhørende beslutning foreskriver EN 5509 som den standarden som skal benyttes for DSRC baserte systemer i EETS og kravene til sikkerhet for DSRC tar derfor utgangspunkt i de mulige sikkerhetsmekanismene som er beskrevet i EN av 24

23 Security specifications for DSRC-EFC OBE The OBE shall comply with the security measures of EN 5509 Security Level. RSE The RSE shall comply with the security measures of EN 5509 Security Level. The RSE may additionally support OBEs complying to EN 5509 Security Level 0. NOTE Security level 0 will provide compatibility with legacy OBE not supporting this Technical Specification. The RSE shall request MAC_TC and MAC_TSP by addressing at least the PaymentMeans attribute. The RSE shall use one of the values of KeyRef corresponding to AuthenticationKey to 4 to obtain the MAC_TC. The RSE shall use one of the values of KeyRef corresponding to AuthenticationKey 5 to 8 to obtain the MAC_TSP. The exact values of KeyRef to be used shall be subject of agreement between Toll Charger and Toll Service Provider. Standarden støtter både bilaterale avtaler mellom alle Utstedere og Operatører mht. utveksling og håndtering av sikkerhetsnøkler og samarbeidsformer hvor Utstedere og Operatører blir enig om å overlate utstedelse av sikkerhetssertifikater og nøkkelhåndtering til en Tiltrodd Tredjepart. I forslaget til sikkerhetspolicy for EETS er det foreslått et europeisk organ (TTP) for å håndtere sikkerhetssertifikater og nøkkelhåndtering. Basert på dette forslaget til EETS sikkerhetspolicy og andre beskrivelser i standarden er det vårt inntrykk at forfatterne av denne standarden var i favør av bruk av TTP for nøkkelhåndtering. Konklusjon Følgende punkter utgjør en oppsummering av sikkerheten i dagens AutoPASS-brikker sett i relasjon til neste generasjon AutoPASS-brikker basert på EN 5509 standarden: Mht MAC-er i AutoPASS og EN 5509 baserte EFC systemer kan begge systemer levere MAC som sikrer autentisering og dataintegritet. Begge bruker variable verdier i MAC-ene som beregnes og begge bruker krypteringsmekanismene Trippel-DES. Begge MAC-ene har tidsstempling, - AutoPASS gjennom sesjonsnøkkelen og EN 5509 baserte EFC systemer gjennom det tilfeldige tallet som sendes til brikken inkludert transaksjonsøyeblikket. Begge applikasjonene beregner MAC-er basert på den internasjonale standarden ISO AutoPASS bygger på en litt eldre versjon av standarden [7] enn EN 5509 [6] så det kan ligge noen forskjeller her selv om metodikken og mekanismene er de samme. Det ligger imidlertid utenfor området til denne rapporten å gå inn i detaljene omkring eventuelle forskjeller. Nøklene som brukes til beregning av MAC i AutoPASS-brikker er triple-des nøkler (6 bytes), mens nøklene som brukes i EN 5509 brikker er DES-nøkler (8 bytes). Brute force angrep mot EN 5509 MAC nøkler er derfor vesentlig enklere og mindre ressurskrevende å gjennomføre enn angrep mot AutoPASS-nøklene i dagens AutoPASS-brikker. En brikke basert på Sikkerhetsnivå i EN 5509 krever autentisering av vegkantutstyret før det tillater lesing av data fra brikken, mens det ikke kreves tilsvarende i AutoPASS. Omfanget på data og sensitiviteten på data som kan leses ut er imidlertid meget forskjellig for de to systemene. I AutoPASS er det stort sett brikkens identitet som leses, mens i EN 5509 baserte EFC systemer kan 22 av 24