Informasjonssikkerhet i AutoPASS-brikker

Størrelse: px
Begynne med side:

Download "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 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

Vedlegg til Kvalifiseringsgrunnlag - Prekvalifisering

Vedlegg til Kvalifiseringsgrunnlag - Prekvalifisering Vedlegg til Kvalifiseringsgrunnlag - Prekvalifisering Beskrivelse av samlet omfang av leveranser, tjenester og kontrakter Prosjekt: Prosjekteier: Felles IKT-løsning for bompengebetaling AutoPASS Grindgut

Detaljer

Bruk av AutoPASS-brikker for å kontrollere og redusere ulovlig kabotasje

Bruk av AutoPASS-brikker for å kontrollere og redusere ulovlig kabotasje Transport & Logistikk 2015 Bruk av AutoPASS-brikker for å kontrollere og redusere ulovlig kabotasje Trond Foss Seniorrådgiver SINTEF Transportforskning 1 Kabotasje Kabotasje er nasjonal transport mot vederlag

Detaljer

Svar - Innføring av EETS - høring

Svar - Innføring av EETS - høring Saknr. 14/7655-2 Saksbehandler: Rune Hoff Svar - Innføring av EETS - høring Innstilling til vedtak: Fylkesrådet vedtar følgende som Hedmark fylkeskommunes uttalelse til høringen: Hedmark fylkeskommune

Detaljer

Evaluering av ordningen med bruk av AutoPASS brikker som identifikatorer til parkering og adgangskontroll. SINTEF Teknologi og samfunn

Evaluering av ordningen med bruk av AutoPASS brikker som identifikatorer til parkering og adgangskontroll. SINTEF Teknologi og samfunn SINTEF A8860 Åpen RAPPORT Evaluering av ordningen med bruk av AutoPASS brikker som identifikatorer til parkering og adgangskontroll Liv Øvstedal og Trond Foss SINTEF Teknologi og samfunn Veg- og transportplanlegging

Detaljer

blir enda viktigere en før fordi tjenestene bllir meget tilgjengelige på Internett

blir enda viktigere en før fordi tjenestene bllir meget tilgjengelige på Internett " %$ # " >9 : B D 1. Åpne og lukkede nettverk - Internett og sikkerhet 2. Krav til sikre tjenester på Internett 3. Kryptografi 4. Kommunikasjonssikkerhet og meldingssikkerhet 5. Elektronisk legitimasjon

Detaljer

Public roadmap for information management, governance and exchange. 2015-09-15 SINTEF david.norheim@brreg.no

Public roadmap for information management, governance and exchange. 2015-09-15 SINTEF david.norheim@brreg.no Public roadmap for information management, governance and exchange 2015-09-15 SINTEF david.norheim@brreg.no Skate Skate (governance and coordination of services in egovernment) is a strategic cooperation

Detaljer

Oppgave 1a Definer følgende begreper: Nøkkel, supernøkkel og funksjonell avhengighet.

Oppgave 1a Definer følgende begreper: Nøkkel, supernøkkel og funksjonell avhengighet. TDT445 Øving 4 Oppgave a Definer følgende begreper: Nøkkel, supernøkkel og funksjonell avhengighet. Nøkkel: Supernøkkel: Funksjonell avhengighet: Data i en database som kan unikt identifisere (et sett

Detaljer

Krav til sikkerhet og personvern hos tjenestesteder som skal koble seg opp til en felles elektronisk pasientjournal

Krav til sikkerhet og personvern hos tjenestesteder som skal koble seg opp til en felles elektronisk pasientjournal Krav til sikkerhet og personvern hos tjenestesteder som skal koble seg opp til en felles elektronisk pasientjournal Seniorrådgiver Knut Lindelien, Standard Norge Bakgrunn Stort informasjonsbehov mye informasjon

Detaljer

EXAM TTM4128 SERVICE AND RESOURCE MANAGEMENT EKSAM I TTM4128 TJENESTE- OG RESSURSADMINISTRASJON

EXAM TTM4128 SERVICE AND RESOURCE MANAGEMENT EKSAM I TTM4128 TJENESTE- OG RESSURSADMINISTRASJON Side 1 av 5 NTNU Norges teknisk-naturvitenskapelige universitet Institutt for telematikk EXAM TTM4128 SERVICE AND RESOURCE MANAGEMENT EKSAM I TTM4128 TJENESTE- OG RESSURSADMINISTRASJON Contact person /

Detaljer

Risikoanalysemetodikk

Risikoanalysemetodikk Risikoanalysemetodikk Mars 2012 Eva Henriksen, eva.henriksen@telemed.no Eva Skipenes, eva.skipenes@telemed.no Sikkerhetsrådgivere NST www.telemed.no/sikkerhet Metodikk for Risikoanalyse Risikovurdering

Detaljer

SIKKERHET OG TILLIT FRA ET TVERRFAGLIG PERSPEKTIV

SIKKERHET OG TILLIT FRA ET TVERRFAGLIG PERSPEKTIV SIKKERHET OG TILLIT FRA ET TVERRFAGLIG PERSPEKTIV Abelia Innovasjon Fagnettverk for Informasjonssikkerhet Oslo 17. mars 2005 Sikkerhet og tillit hva er sammenhengen? Ketil Stølen Sjefsforsker/Professor

Detaljer

VEDLEGG 7 SIKKERHET 1. KRAV TIL SIKRING AV DATAFILER VED OVERFØRING TIL/FRA BANKEN

VEDLEGG 7 SIKKERHET 1. KRAV TIL SIKRING AV DATAFILER VED OVERFØRING TIL/FRA BANKEN VEDLEGG 7 SIKKERHET 1. KRAV TIL SIKRING AV DATAFILER VED OVERFØRING TIL/FRA BANKEN 1.1 Sikkerhetskravene bygger på at det til enhver tid skal være et 1 til 1-forhold mellom det som er registrert i Virksomhetens

Detaljer

Lovlig bruk av Cloud Computing. Helge Veum, avdelingsdirektør Difi, Oslo 17.03.2014

Lovlig bruk av Cloud Computing. Helge Veum, avdelingsdirektør Difi, Oslo 17.03.2014 Lovlig bruk av Cloud Computing Helge Veum, avdelingsdirektør Difi, Oslo 17.03.2014 Vårt utgangspunkt Det er Datatilsynets utgangspunkt at det er mulig å oppnå godt personvern også i nettskyen Dette er

Detaljer

Sosiale Medier, e-ider og Personvern

Sosiale Medier, e-ider og Personvern www.nr.no Sosiale Medier, e-ider og Personvern Innføring i begrepene og tema til e-me oppstartmøte Dr. Lothar Fritsch Norsk Regnesentral Oslo 2. September 2010 Lothar Fritsch Forsker innenfor IKT Sikkerhet,

Detaljer

Flexus, HB206 & Interoperabilitet. ITS Norge 28 september 2010

Flexus, HB206 & Interoperabilitet. ITS Norge 28 september 2010 Flexus, HB206 & Interoperabilitet ITS Norge 28 september 2010 Interoperabilitetstjenester AS Postboks 623 Sentrum 0106 Oslo Jørn Hanssen +47 99160427 jorn.hanssen@ioas.no Interoperabilitet i Oslo/Akershus

Detaljer

Nasjonal sikkerhetsmyndighet

Nasjonal sikkerhetsmyndighet Nasjonal sikkerhetsmyndighet IT-veiledning for ugradert nr 2 (U-02) Oppdatert: 2014-02-03 E-post Kryptering av e-postoverføring Beskrivelse av grunnleggende tiltak for sikring av overføring av e-post mellom

Detaljer

1. Krypteringsteknikker

1. Krypteringsteknikker Krypteringsteknikker Olav Skundberg Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget 1. Krypteringsteknikker 1.1. Fire formål med sikker kommunikasjon Aller først, pålitelig

Detaljer

Database security. Kapittel 14 Building Secure Software. Inf329, Høst 2005 Isabel Maldonado st10900@student.uib.no

Database security. Kapittel 14 Building Secure Software. Inf329, Høst 2005 Isabel Maldonado st10900@student.uib.no Database security Kapittel 14 Building Secure Software Inf329, Høst 2005 Isabel Maldonado st10900@student.uib.no Kort introduksjon Database er en organisert samling av data. SQL(Structured Query Language)

Detaljer

ISO 27001 Syscom brukerforum 2013 Jørn Erik Hornseth og Torbjørn Remmen

ISO 27001 Syscom brukerforum 2013 Jørn Erik Hornseth og Torbjørn Remmen ISO 27001 Syscom brukerforum 2013 Jørn Erik Hornseth og Torbjørn Remmen Informasjonssikkerhet Visjon «Organisasjonen anerkjennes som ledende aktør innen informasjonssikkerhet» Oppdrag «Å designe, implementere,

Detaljer

System integration testing. Forelesning Systems Testing UiB Høst 2011, Ina M. Espås,

System integration testing. Forelesning Systems Testing UiB Høst 2011, Ina M. Espås, System integration testing Forelesning Systems Testing UiB Høst 2011, Ina M. Espås, Innhold Presentasjon Hva er integration testing (pensum) Pros og cons med integrasjonstesting Når bruker vi integration

Detaljer

buildingsmart Norge seminar Gardermoen 2. september 2010 IFD sett i sammenheng med BIM og varedata

buildingsmart Norge seminar Gardermoen 2. september 2010 IFD sett i sammenheng med BIM og varedata buildingsmart Norge seminar Gardermoen 2. september 2010 IFD sett i sammenheng med BIM og varedata IFD International Framework for Dictionaries Hvordan bygges en BIM? Hva kan hentes ut av BIM? Hvordan

Detaljer

Symmetrisk En hemmelig nøkkel ( passord ) som brukes både ved kryptering og dekryptering.

Symmetrisk En hemmelig nøkkel ( passord ) som brukes både ved kryptering og dekryptering. 1 Hva? Hva er informasjonssikkerhet? Information security encompasses the study of the concepts, techniques, technical measures, and administrative measures used to protect information assets from deliberate

Detaljer

Teori om sikkerhetsteknologier

Teori om sikkerhetsteknologier Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Tomas Holt 22.8.2007 Lærestoffet er utviklet for faget LN479D/LV473D Nettverksikkerhet Innhold 1 1 1.1 Introduksjon til faget............................

Detaljer

PrENV 13608 : Sikkerhet for kommunikasjon i helsevesenet. Del 3 : Sikre datakanaler. Oversatt ved Kompetansesenter for IT i Helsevesenet

PrENV 13608 : Sikkerhet for kommunikasjon i helsevesenet. Del 3 : Sikre datakanaler. Oversatt ved Kompetansesenter for IT i Helsevesenet PrENV 13608 : Sikkerhet for kommunikasjon i helsevesenet Del 3 : Sikre datakanaler Oversatt ved Kompetansesenter for IT i Helsevesenet Forord Denne Europeiske Prestandard ble forberedt av CEN/TC251 Helseinformatikk

Detaljer

Internkontroll og informasjonssikkerhet lover og standarder

Internkontroll og informasjonssikkerhet lover og standarder Internkontroll og informasjonssikkerhet lover og standarder Renate Thoreid, senioringeniør Side 1 Internkontroll og Informasjonssikkerhet Krav i Personopplysningsloven 13 og 14 Krav i Personopplysningsforskriften

Detaljer

IT-ledelse 25.jan - Dagens

IT-ledelse 25.jan - Dagens IT-ledelse 25.jan - Dagens 1. Virksomheters anvendelse av IT-baserte informasjonssystemer 2. Alle nivåer i bedriftshierarkier støttes av informasjonssystemer Operasjonelt nivå, Mellomleder nivå, Toppledelse

Detaljer

Sikkerhet, risikoanalyse og testing: Begrepsmessig avklaring

Sikkerhet, risikoanalyse og testing: Begrepsmessig avklaring Sikkerhet, risikoanalyse og testing: Begrepsmessig avklaring Seminar om risikoanalyse og testing innen sikkerhet Bjørnar Solhaug SINTEF, 11. juni, 2013 Technology for a better society 1 Oversikt Risikoanalyse

Detaljer

TrioVing dp og dp CLIQ

TrioVing dp og dp CLIQ TrioVing dp og dp CLIQ Avansert låssylinderteknologi ASSA ABLOY, the global leader in door opening solutions Teknologi i system Låssylinderen er låsens hjerne; den utskiftbare komponenten som kontrollerer

Detaljer

Honda Maris Pay & Go. Personvernerklæring og policy for informasjonskapsler

Honda Maris Pay & Go. Personvernerklæring og policy for informasjonskapsler Honda Maris Pay & Go Personvernerklæring og policy for informasjonskapsler Honda anerkjenner viktigheten av ærlig og ansvarlig bruk av dine personlige opplysninger. Personvernerklæringen og policyen for

Detaljer

Tredjeparters tilgang til bankkonti - hva gjør næringen?

Tredjeparters tilgang til bankkonti - hva gjør næringen? Tredjeparters tilgang til bankkonti - hva gjør næringen? Lars Erik Fjørtoft, Daglig leder 18.11.2015 Presiseringer Temaet er potensialet knyttet til digital samhandling med tredjeparter Ikke fokus på PSD

Detaljer

Sammendrag Evaluering

Sammendrag Evaluering Sammendrag Evaluering Utarbeidet av Norconsult Seksjon IKT & Sikkerhet Evaluering av BankID Med fokus på kundens kontroll over privat nøkkel Dato 2010-09-14 Versjon 1.0 Dokument referanse NO-5100770-ETR

Detaljer

Social Media Insight

Social Media Insight Social Media Insight Do you know what they say about you and your company out there? Slik fikk Integrasco fra Grimstad Vodafone og Sony Ericsson som kunder. Innovasjon og internasjonalisering, Agdering

Detaljer

BÆRUM KOMMUNE ANSKAFFELSESENHETEN

BÆRUM KOMMUNE ANSKAFFELSESENHETEN BÆRUM KOMMUNE ANSKAFFELSESENHETEN Spørsmål og svar Navn på anskaffelsen Kjøp av bysykkelordning til Lysaker Fornebu området ArkivsakID 15/120568 Dato 09.06.2015 Oppdragsgiver må få gjøre oppmerksom på

Detaljer

KIS - Ekspertseminar om BankID

KIS - Ekspertseminar om BankID www.nr.no KIS - Ekspertseminar om BankID Dr. Ing. Åsmund Skomedal Forsknings sjef, DART, Norsk Regnesentral asmund.skomedal@nr.no 18. mars 2009 Tema til diskusjon Agenda punkter Kritisk analyse av digitale

Detaljer

Mobilbank kontrollspørsmål apper

Mobilbank kontrollspørsmål apper Egenevalueringsskjema Mobilbank DATO: 31.10.2014 Evalueringsskjema Mobilbank apper Del 1 Del 2 Strategi og sikkerhetspolicy Kost-nytte og ROS-analyser Utvikling og oppdatering Avtaler Driftsrelaterte spørsmål

Detaljer

Håndtering av personlig informasjon

Håndtering av personlig informasjon Håndtering av personlig informasjon Håndtering av personlig informasjon Du kan alltid besøke vår hjemmeside for å få informasjon og lese om våre tilbud og kampanjer uten å oppgi noen personopplysninger.

Detaljer

Fakultet for informasjonsteknologi, Institutt for datateknikk og informasjonsvitenskap AVSLUTTENDE EKSAMEN I. TDT42378 Programvaresikkerhet

Fakultet for informasjonsteknologi, Institutt for datateknikk og informasjonsvitenskap AVSLUTTENDE EKSAMEN I. TDT42378 Programvaresikkerhet Side 1 av 5 NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for informasjonsteknologi, matematikk og elektroteknikk Institutt for datateknikk og informasjonsvitenskap AVSLUTTENDE EKSAMEN

Detaljer

Remote Video Solutions. Kameratjenester fra Securitas

Remote Video Solutions. Kameratjenester fra Securitas Remote Video Solutions Kameratjenester fra Securitas 2 Remote Video Solutions Remote Video Solutions gir deg økt trygghet. Vi kombinerer smart teknologi og vektere i en sikkerhetsløsning som vi vet kan

Detaljer

Ny personvernforordning Hvordan reguleres informasjonssikkerhet

Ny personvernforordning Hvordan reguleres informasjonssikkerhet Ny personvernforordning Hvordan reguleres informasjonssikkerhet Datatilsynet Uavhengig forvaltningsorgan Tilsyn og ombud Forvalter personopplysningsloven og forskrifter 41 medarbeidere Faggruppe 1 (justis,

Detaljer

Avtale om leveranse av IKT-tjenester. Del II - Databehandleravtale

Avtale om leveranse av IKT-tjenester. Del II - Databehandleravtale Avtale om leveranse av IKT-tjenester Tjenesteavtale nr.: SUNHF-2011 Del II - Databehandleravtale Versjon: 0.1 Dato oppdatert : 22.03.11 Databehandleravtale mellom Sunnaas Sykehus HF Organisasjonsnr.:

Detaljer

Hvordan gjennomføres id-tyverier og hva kan gjøres. Tore Larsen Orderløkken Leder NorSIS

Hvordan gjennomføres id-tyverier og hva kan gjøres. Tore Larsen Orderløkken Leder NorSIS Hvordan gjennomføres id-tyverier og hva kan gjøres Tore Larsen Orderløkken Leder NorSIS 1 Noen definisjoner Identitetstyveri Uautorisert innsamling, besittelse, overføring, reproduksjon eller annen manipulering

Detaljer

Kan cyber-risiko forsikres?

Kan cyber-risiko forsikres? Kan cyber-risiko forsikres? Hva er kost-nytte av å overføre sikkerhetsrisiko til en tredjepart? Aida Omerovic SINTEF IKT Sikkerhet og Sårbarhet Mai 2015 Teknologi for et bedre samfunn Informasjonssikkerhet

Detaljer

IKT-reglement for Norges musikkhøgskole

IKT-reglement for Norges musikkhøgskole IKT-reglement for Norges musikkhøgskole Norges musikkhøgskole (NMH) er forpliktet til å kontrollere risiko og håndtere informasjon og tekniske ressurser på en sikker måte. Når du får tilgang til disse

Detaljer

Innholdsstandard (meldinger) ebxml-rammeverk (innpakking, adressering, transportkvittering, kryptering, autentisering, virksomhetssignatur)

Innholdsstandard (meldinger) ebxml-rammeverk (innpakking, adressering, transportkvittering, kryptering, autentisering, virksomhetssignatur) NOTAT Fra KITH v/bjarte Aksnes m.fl. Dato 29.03.06 Samhandlingsarkitektur for helsesektoren En viktig forutsetning for at aktører i helsesektoren skal kunne samhandle elektronisk på en god måte er at alle

Detaljer

VILKÅR FOR BRUK AV PREODAY APP OG E-HANDELSLØSNING

VILKÅR FOR BRUK AV PREODAY APP OG E-HANDELSLØSNING VILKÅR FOR BRUK AV PREODAY APP OG E-HANDELSLØSNING Ved å sette opp og lage en Preoday App og E-handelsløsning for ditt utsalgssted eller restaurant godtar du disse vilkårene. Hvis du ikke godtar vilkårene,

Detaljer

Monitoring water sources.

Monitoring water sources. Monitoring water sources. Generell Informasjon Versjon 2 Url http://com.mercell.com/permalink/38336681.aspx Ekstern anbuds ID 223314-2013 Konkurranse type: Tildeling Dokument type Kontraktstildeling Prosedyre

Detaljer

Hvordan velge en leverandør for cloud backup

Hvordan velge en leverandør for cloud backup Hvordan velge en leverandør for cloud backup WHITEPAPER Hvorfor bør du beskytte dine data? Før eller senere via skade, uhell eller feil er det statistisk sannsynlig at du vil miste verdifull data. Flere

Detaljer

Databehandleravtaler

Databehandleravtaler Databehandleravtaler etter personopplysningsloven og helseregisterloven Veileder 26.05.2009 Innholdsfortegnelse DEL I 5 Veileder - databehandleravtaler...6 Datatilsynet...6 Forutsetninger og avklaringer...7

Detaljer

NORGE. Patentstyret (12) SØKNAD (19) NO (21) 20101728 (13) A1. (51) Int Cl. G06Q 20/00 (2006.01)

NORGE. Patentstyret (12) SØKNAD (19) NO (21) 20101728 (13) A1. (51) Int Cl. G06Q 20/00 (2006.01) (12) SØKNAD (19) NO (21) 1728 (13) A1 NORGE (1) Int Cl. G06Q /00 (06.01) Patentstyret (21) Søknadsnr 1728 (86) Int.inng.dag og søknadsnr (22) Inng.dag.12. (8) Videreføringsdag (24) Løpedag.12. () Prioritet.03.04,

Detaljer

Innføring av domeneregistreringer med elektroniske egenerklæringer

Innføring av domeneregistreringer med elektroniske egenerklæringer 1 (11) Innføring av domeneregistreringer med elektroniske egenerklæringer Dette dokumentet beskriver en løsning for registrering av domenenavn med elektroniske egenerklæringer. 2 (11) Historikk Dato Revisjon

Detaljer

Haraldsplass. Svar på varsel om vedtak - Uautorisert uthenting av helseopplysninger gjennom leverandørenes fjerntilgang.

Haraldsplass. Svar på varsel om vedtak - Uautorisert uthenting av helseopplysninger gjennom leverandørenes fjerntilgang. Haraldsplass DIAKONALE SYKEHUS Bergen Diakon isse k j em Datatilsynet Postboks 8177 Dep 0034 Oslo Deres ref: 12/00302-1 /HVE Vår ref: Bergen, 13.04.2012 Svar på varsel om vedtak - Uautorisert uthenting

Detaljer

Lukkede pasientgrupper på sosiale medier en utfordring for personvernet. Hvor er løsningene?

Lukkede pasientgrupper på sosiale medier en utfordring for personvernet. Hvor er løsningene? Lukkede pasientgrupper på sosiale medier en utfordring for personvernet. Hvor er løsningene? Anbefalt av flere Mange tjenester - ulike konsepter Personvernutfordringene Observasjoner fra bruk Program for

Detaljer

FIRE EFFEKTIVE TILTAK MOT DATAANGREP

FIRE EFFEKTIVE TILTAK MOT DATAANGREP FIRE EFFEKTIVE TILTAK MOT DATAANGREP Olav Ligaarden Nasjonal sikkerhetsmyndighet Offentlig seminar SINTEF, Oslo 2016-01-22 SLIDE 1 Innhold Motivasjon Fire effektive, enkle og viktige tiltak Tre andre enkle

Detaljer

Avtalevilkår for bestilling og bruk av Commfides Virksomhetssertifikat

Avtalevilkår for bestilling og bruk av Commfides Virksomhetssertifikat Avtalevilkår for bestilling og bruk av Commfides Virksomhetssertifikat 1. Kort beskrivelse av sertifikatstjenesten Commfides Virksomhetssertifikat er en elektronisk offentlig godkjent legitimasjon av en

Detaljer

Vår digitale sårbarhet teknologi og åpne spørsmål

Vår digitale sårbarhet teknologi og åpne spørsmål Lysneutvalget 2014-2015 Vår digitale sårbarhet teknologi og åpne spørsmål Professor Olav Lysne Leder for Digitalt Sårbarhehtsutvalg Leder for Robuste Ne? Senteret 1 2 4 Lysneutvalget - Digitale sårbarheter

Detaljer

MARKEDSFØRINGS- PLAN

MARKEDSFØRINGS- PLAN MARKEDSFØRINGS- PLAN Karatbars Program til Affiliate Partnere Du bestemmer selv om hva slags inntekt du ønsker å oppnå. Til sammen har du 7 valgmuligheter. 7 Muligheter for å oppnå inntekt 1. Direkte provisjon

Detaljer

(12) PATENT (19) NO (11) 330271 (13) B1 NORGE. (51) Int Cl. Patentstyret

(12) PATENT (19) NO (11) 330271 (13) B1 NORGE. (51) Int Cl. Patentstyret (12) PATENT (19) NO (11) 3271 (13) B1 NORGE (1) Int Cl. G06Q /00 (06.01) Patentstyret (21) Søknadsnr 08 (86) Int.inng.dag og søknadsnr (22) Inng.dag.03.04 (8) Videreføringsdag (24) Løpedag.03.04 () Prioritet

Detaljer

Disse retningslinjene for personvern beskriver hvordan vi bruker og beskytter informasjon som du oppgir i forbindelse med bruk av nettstedet vårt.

Disse retningslinjene for personvern beskriver hvordan vi bruker og beskytter informasjon som du oppgir i forbindelse med bruk av nettstedet vårt. RETNINGSLINJER FOR PERSONVERN Disse retningslinjene for personvern beskriver hvordan vi bruker og beskytter informasjon som du oppgir i forbindelse med bruk av nettstedet vårt. Vi er forpliktet til å sikre

Detaljer

UNIK - Academic Forum on Security. Invitert presentasjon: BankID - noen myter og sannheer August 2008

UNIK - Academic Forum on Security. Invitert presentasjon: BankID - noen myter og sannheer August 2008 UNIK - Academic Forum on Security Invitert presentasjon: BankID - noen myter og sannheer August 2008 BankID 2004 2008 Kontekst: BankID og BSK BSK: = Bankenes Standardiseringskontor Etablert 1994 på bakgrunn

Detaljer

Det digitale trusselbildet Sårbarheter og tiltak

Det digitale trusselbildet Sårbarheter og tiltak H a f s l u n d M u l i g h e t s W o r k s h o p TORE LARSEN ORDERLØKKEN Det digitale trusselbildet Sårbarheter og tiltak Agenda Sikkerhetsparadokset Trusler og trender Tall og hendelser Hvordan sikrer

Detaljer

Er du trygg i nettskyen 31. Mai 2011 Advokat Herman Valen

Er du trygg i nettskyen 31. Mai 2011 Advokat Herman Valen Er du trygg i nettskyen 31. Mai 2011 Advokat Herman Valen Innledning Hva er cloud computing? IaaS, PaaS, SaaS osv Skyen er en forretningsmodell som bygger på noen prinsipper: Standardisering (tjenester,

Detaljer

Ifølge Stortingsmelding nr. 17 (2006-2007) «Et informasjonssamfunn for alle» bygger begrepet IKT-sikkerhet på tre basisegenskaper:

Ifølge Stortingsmelding nr. 17 (2006-2007) «Et informasjonssamfunn for alle» bygger begrepet IKT-sikkerhet på tre basisegenskaper: Geir Martin Pilskog og Mona I.A. Engedal 8. Økende bruk av informasjons- og kommunikasjonsteknologi (IKT) medfører flere utfordringer når det gjelder sikkerhet ved bruken av IKT-system, nettverk og tilknyttede

Detaljer

Prosjektnotat. Tidevannsanalyse. 1 av 5. Sammenligning av harmoniske konstanter fra modell mot observasjoner

Prosjektnotat. Tidevannsanalyse. 1 av 5. Sammenligning av harmoniske konstanter fra modell mot observasjoner SINTEF Fiskeri og havbruk AS Postadresse: Postboks 4762 Sluppen 7465 Trondheim Sentralbord: 40005350 Telefaks: 93270701 fish@sintef.no www.sintef.no/fisk Foretaksregister: NO 980 478 270 MVA Prosjektnotat

Detaljer

Bransjenorm. for personvern og informasjonssikkerhet i elektronisk billettering. Vedlegg 4: Veiledning for internkontroll - informasjonssikkerhet

Bransjenorm. for personvern og informasjonssikkerhet i elektronisk billettering. Vedlegg 4: Veiledning for internkontroll - informasjonssikkerhet Bransjenorm for personvern og informasjonssikkerhet i elektronisk billettering Vedlegg 4: Veiledning for internkontroll - informasjonssikkerhet Innhold 1 Innledning 1 1.1 Informasjonssikkerhet i elektronisk

Detaljer

Kompetansemål fra Kunnskapsløftet

Kompetansemål fra Kunnskapsløftet Datasikkerhet 2ISFA Kompetansemål fra Kunnskapsløftet yte service gjennom brukerstøtte og kommunikasjon med brukere yte service gjennom driftsstøtte og kommunikasjon med leverandører og fagpersonell på

Detaljer

NSMs kryptoaktiviteter

NSMs kryptoaktiviteter NSMs kryptoaktiviteter Norsk kryptoseminar 2007 Terje Jensen Seksjon for kryptoteknologi terje.jensen@nsm.stat.no www.nsm.stat.no Norwegian National Security Authority Making Society Secure 20. november,

Detaljer

Jernbaneverkets erfaringer med implementering av RAMS

Jernbaneverkets erfaringer med implementering av RAMS Jernbaneverkets erfaringer med implementering av RAMS Terje Sivertsen, seksjonsleder signal Infrastruktur Teknikk, Premiss og utvikling Jernbaneverket RAMS-seminar, NJS, Oslo, 18. april 2007 1 Innhold

Detaljer

Rettslige krav til styring av informasjonssikkerhet. Karin Kristiansen og Amund Eriksen

Rettslige krav til styring av informasjonssikkerhet. Karin Kristiansen og Amund Eriksen Rettslige krav til styring av informasjonssikkerhet Karin Kristiansen og Amund Eriksen Hva får dere IKKE? Informasjonssikkerhet? Informasjonssikkerhet dreier seg om å håndtere risiko relatert til virksomhetens

Detaljer

Korrupsjon og misligheter i kommunal sektor revisors rolle

Korrupsjon og misligheter i kommunal sektor revisors rolle Rica Nidelven, 11. juni 2013 14.00 15.00 Korrupsjon og misligheter i kommunal sektor revisors rolle Anders Berg Olsen 2013, Anders Berg Olsen, HiST Handelshøyskolen i Trondheim. Dette materialet er beskyttet

Detaljer

OVERSIKT SIKKERHETSARBEIDET I UDI

OVERSIKT SIKKERHETSARBEIDET I UDI OVERSIKT SIKKERHETSARBEIDET I UDI Toppdokument Felles toppdokument Sikkerhetsloven Grunnlagsdokument for sikkerhet Håndtering av brukerhenvendelser Personopplysningsloven Styringsdokument Policydokument

Detaljer

Hvordan kan vi utvikle og etablere sikrere løsninger? Kasus: for mobiltelefoner og nettbrett

Hvordan kan vi utvikle og etablere sikrere løsninger? Kasus: for mobiltelefoner og nettbrett Hvordan kan vi utvikle og etablere sikrere løsninger? Kasus: for mobiltelefoner og nettbrett SpareBank 1 Finanshus Forvaltning 805 mrd. Bank, forsikring, eiendomsmegling, inkasso, etc. ca 6500 ansatte

Detaljer

Den mobile arbeidshverdagen

Den mobile arbeidshverdagen Den mobile arbeidshverdagen - Sikkerhetsutfordringer og løsninger Siv Hilde Houmb & Øystein Hermansen Kort om Secure-NOK AS Inkubatorbedrift ipark Stavanger Sikkerhetsspesialister Fokusområder Strategisk

Detaljer

Er veien videre klar?

Er veien videre klar? Er veien videre klar? Norvegkonferansen 2012 Trondheim 18. september 2012 Terje Moe Gustavsen Vegdirektør Tall i mill. 2012 kr Veginvesteringer 2002-2012 30 000 2002 og 2003: Fylke 15 % Stat 85 % 2007,

Detaljer

Elektroniske spor. Innsynsrett, anonymitet. Personvernutfordringer. Innsynsrett. Informasjonsplikt og innsynsrett

Elektroniske spor. Innsynsrett, anonymitet. Personvernutfordringer. Innsynsrett. Informasjonsplikt og innsynsrett Elektroniske spor Innsynsrett, anonymitet Kirsten Ribu Kilde: Identity Management Systems (IMS): Identification and Comparison Study Independent Centre for Privacy Protection and Studio Notarile Genghini

Detaljer

Full kontroll? - Hva er folk bekymret for og har de opplevd å miste kontroll over egne personopplysninger?

Full kontroll? - Hva er folk bekymret for og har de opplevd å miste kontroll over egne personopplysninger? Full kontroll? - Hva er folk bekymret for og har de opplevd å miste kontroll over egne personopplysninger? Delrapport fra personvernundersøkelsen november 2013 Februar 2014 Innhold Hva er du bekymret for?...

Detaljer

Hvordan styre informasjonssikkerhet i et dynamisk trusselbilde? Tommy Molnes Security Manager Digital Sikkerhet AS

Hvordan styre informasjonssikkerhet i et dynamisk trusselbilde? Tommy Molnes Security Manager Digital Sikkerhet AS Hvordan styre informasjonssikkerhet i et dynamisk trusselbilde? Tommy Molnes Security Manager Digital Sikkerhet AS Agenda Hva skal vi beskytte? Hvilke krav stilles? Forskrift om beredskap i kraftforsyningen

Detaljer

6DPRUGQHWHOHNWURQLVNELOOHWWHULQJ

6DPRUGQHWHOHNWURQLVNELOOHWWHULQJ 6DPRUGQHWHOHNWURQLVNELOOHWWHULQJ Statens vegvesen, Vegdirektoratet Kontor for drift og trafikkteknikk Overingeniør Charlotte Vithen,QQOHGQLQJ Dette innlegget tar utgangspunkt i Vegdirektoratets håndbok

Detaljer

Nettfiske og målrettet nettfiske blant de største sikkerhetstruslene. Tradisjonell antispam beskytter ikke mot truslene!

Nettfiske og målrettet nettfiske blant de største sikkerhetstruslene. Tradisjonell antispam beskytter ikke mot truslene! Nettfiske og målrettet nettfiske blant de største sikkerhetstruslene. Tradisjonell antispam beskytter ikke mot truslene! Undersøkelser viser at så mye som 90 % av alle angrep kan starte med nettfiske og

Detaljer

Implementeringen av ROP retningslinjen; er GAP analyser et

Implementeringen av ROP retningslinjen; er GAP analyser et Implementeringen av ROP retningslinjen; er GAP analyser et effek/vt redskap? Lars Lien, leder Nasjonal kompetansetjeneste for sam

Detaljer

BIOMETRI OG IDENTIFISERING BRUK AV BIOMETRI FOR IDENTIFISERING AV PERSON/VERIFISERING AV ID SIKKERHET OG PERSONVERN MARS 2006/MA

BIOMETRI OG IDENTIFISERING BRUK AV BIOMETRI FOR IDENTIFISERING AV PERSON/VERIFISERING AV ID SIKKERHET OG PERSONVERN MARS 2006/MA BIOMETRI OG IDENTIFISERING BRUK AV BIOMETRI FOR IDENTIFISERING AV PERSON/VERIFISERING AV ID SIKKERHET OG PERSONVERN MARS 2006/MA BAKTEPPE STARTEN: 11. September 2001 LØSNING: biometri i pass mv. DAGENS

Detaljer

Behandles av utvalg: Møtedato Utvalgssaksnr. Administrasjonsutvalget 15.03.2011 1/11

Behandles av utvalg: Møtedato Utvalgssaksnr. Administrasjonsutvalget 15.03.2011 1/11 KOMMUNE - RÅDMANNEN Arkivsak Arkivkode Saksbeh. : 200906584 : E: 210 : W. S. Eris m. fl. Behandles av utvalg: Møtedato Utvalgssaksnr. Administrasjonsutvalget 15.03.2011 1/11 INFORMASJONSSIKKERHET I SANDNES

Detaljer

Hvordan kontrollere det ukontrollerte? Et ledelsesperspektiv. Geir Arild Engh-Hellesvik, Leder IPBR / KPMG Advisory 02.

Hvordan kontrollere det ukontrollerte? Et ledelsesperspektiv. Geir Arild Engh-Hellesvik, Leder IPBR / KPMG Advisory 02. Hvordan kontrollere det ukontrollerte? Et ledelsesperspektiv Geir Arild Engh-Hellesvik, Leder IPBR / KPMG Advisory 02. Februar 2011 Innledning 2 KPMG Norge Geir Arild Engh-Hellesvik er leder for informasjonssikkerhetstjenesten

Detaljer

Prosjektnotat 1. Vegprising i Norge. 1 av 17. Internasjonale erfaringer - Tekniske løsninger Personverninteresser 2012-11-19

Prosjektnotat 1. Vegprising i Norge. 1 av 17. Internasjonale erfaringer - Tekniske løsninger Personverninteresser 2012-11-19 SINTEF Teknologi og samfunn Postadresse: Postboks 4760 Sluppen 7465 Trondheim Sentralbord: 73593000 Telefaks: 0 ts@sintef.no www.sintef.no Foretaksregister: NO 94800709 MVA Prosjektnotat 1 Vegprising i

Detaljer

KRISINO 2011 Kriminalitets- og sikkerhetsundersøkelsen i Norge

KRISINO 2011 Kriminalitets- og sikkerhetsundersøkelsen i Norge KRISINO 2011 Kriminalitets- og sikkerhetsundersøkelsen i Norge Justisdepartementet v/embetsmannsutvalget mot økonomisk kriminalitet (EMØK) Erland Løkken Direktør KRISINO 2011 5. gang 2500 virksomheter

Detaljer

Generell avtale og brukervilkår Disse vilkårene skal reguleres av og tolkes i samsvar med lovene i Norge.

Generell avtale og brukervilkår Disse vilkårene skal reguleres av og tolkes i samsvar med lovene i Norge. Generell avtale og brukervilkår Disse vilkårene skal reguleres av og tolkes i samsvar med lovene i Norge. Ved å registrere deg for tjenesten(e), godtar du følgende vilkår, betingelser og retningslinjer.

Detaljer

Vegvesenets oppdaterte ITS-Strategi skaper nye muligheter - mer om NonStop-prosjektet. SINTEF, Terje Moen. 26.04.2013 NonStop, ITS konferansen 2013 1

Vegvesenets oppdaterte ITS-Strategi skaper nye muligheter - mer om NonStop-prosjektet. SINTEF, Terje Moen. 26.04.2013 NonStop, ITS konferansen 2013 1 Vegvesenets oppdaterte ITS-Strategi skaper nye muligheter - mer om NonStop-prosjektet SINTEF, Terje Moen 26.04.2013 NonStop, ITS konferansen 2013 1 ITS, løsningen på mange av dagens utfordringer i transportsystemet

Detaljer

Rocksource ASA «Full gass» i en bransje med bremsene på. Manifestasjon, Grieghallen 14. april 2015 Adm. direktør Terje Arnesen

Rocksource ASA «Full gass» i en bransje med bremsene på. Manifestasjon, Grieghallen 14. april 2015 Adm. direktør Terje Arnesen Rocksource ASA «Full gass» i en bransje med bremsene på Manifestasjon, Grieghallen 14. april 2015 Adm. direktør Terje Arnesen Disclaimer This presentation contains information provided by the management

Detaljer

Veileder for bruk av tynne klienter

Veileder for bruk av tynne klienter Veileder for bruk av tynne klienter Dette dokumentet er en veileder for bruk av terminaltjener/klient (tynne klienter) for å skille samtidige brukerrettigheter i åpne og sikre soner. April 2005 Postadresse:

Detaljer

Deres ref Vår ref (bes oppgitt ved svar) Dato GS/- KONSESJON TIL Å BEHANDLE PERSONOPPLYSNINGER PRIVAT BARNEVERNINSTITUSJON

Deres ref Vår ref (bes oppgitt ved svar) Dato GS/- KONSESJON TIL Å BEHANDLE PERSONOPPLYSNINGER PRIVAT BARNEVERNINSTITUSJON Datatilsynet Deres ref Vår ref (bes oppgitt ved svar) Dato GS/- KONSESJON TIL Å BEHANDLE PERSONOPPLYSNINGER PRIVAT BARNEVERNINSTITUSJON Vi viser til Deres søknad av xx.xx.xxxx om konsesjon til å behandle

Detaljer

Hva er et styringssystem?

Hva er et styringssystem? Hva er et styringssystem? Og forholdet mellom ISO 27001 og 27002 Seminar 12. april 2012 Ingvild Høvik Kiland Riksrevisjonens Dok 1 (2010-2011) Revisjonen var basert på Nasjonale retningslinjer for å styrke

Detaljer

20.01.2012. Brukerkrav og use case diagrammer og -tekst 19. januar 2012. Agenda. Brukerkrav og use case. Diagrammer Tekst.

20.01.2012. Brukerkrav og use case diagrammer og -tekst 19. januar 2012. Agenda. Brukerkrav og use case. Diagrammer Tekst. Brukerkrav og use case diagrammer og -tekst 19. januar 2012 Agenda Brukerkrav og use case Diagrammer Tekst Praktisk eksempel 1 OOAD i livsløpsperspektiv Krav Design Konstruksjon Her er vi i nå Testing

Detaljer

HØRINGSNOTAT. Høring om forslag til forskrift om samvirkningsevnen mellom elektroniske trafikantbetalingssystemer i Europa (EETSforskriften)

HØRINGSNOTAT. Høring om forslag til forskrift om samvirkningsevnen mellom elektroniske trafikantbetalingssystemer i Europa (EETSforskriften) HØRINGSNOTAT Høring om forslag til forskrift om samvirkningsevnen mellom elektroniske trafikantbetalingssystemer i Europa (EETSforskriften) Gjennomføring av Europaparlaments- og rådsdirektiv 2004/52/EF

Detaljer

Som en del av denne prosessen, når verten har startet og nøkkelfilene ikke er å finne, lages et nytt sett automatisk.

Som en del av denne prosessen, når verten har startet og nøkkelfilene ikke er å finne, lages et nytt sett automatisk. De beste sikkerhetsrutiner for Symantec pcanywhere Dette dokumentet inneholder informasjon om forbedrede sikkerhetsendringer i pcanywhere 12.5 SP4 og pcanywhere Solution 12.6.7, hvordan viktige deler av

Detaljer

Spesifikasjoner for norske systemer. 2010-09-27 Kjell-Erik B. Eilertsen Kjell-ErikE@nsb.no

Spesifikasjoner for norske systemer. 2010-09-27 Kjell-Erik B. Eilertsen Kjell-ErikE@nsb.no Spesifikasjoner for norske systemer 2010-09-27 Kjell-Erik B. Eilertsen Kjell-ErikE@nsb.no Mål i ny versjon Lage et nasjonalt regime for produktdefinisjoner Skape bedre konsistens mellom produktdefinisjoner

Detaljer

Filipstad Brygge 1, 8. etg, Oslo. 14. oktober 2005 kl 12:00

Filipstad Brygge 1, 8. etg, Oslo. 14. oktober 2005 kl 12:00 Til aksjeeiere i Norgani Hotels ASA INNKALLING TIL EKSTRAORDINÆR GENERALFORSAMLING Ekstraordinær generalforsamling i Norgani Hotels ASA holdes på: Filipstad Brygge 1, 8. etg, Oslo 14. oktober 2005 kl 12:00

Detaljer

Innovasjonsvennlig anskaffelse

Innovasjonsvennlig anskaffelse UNIVERSITETET I BERGEN Universitetet i Bergen Innovasjonsvennlig anskaffelse Fredrikstad, 20 april 2016 Kjetil Skog 1 Universitetet i Bergen 2 Universitetet i Bergen Driftsinntekter på 4 milliarder kr

Detaljer

Skytjenester. Forside og Databehandleravtale. Telenor Norge

Skytjenester. Forside og Databehandleravtale. Telenor Norge Skytjenester Forside og Databehandleravtale Telenor Norge FORSIDE TIL AVTALE Det bekreftes med dette at det i dag den er inngått avtale mellom Telenor Norge AS, Snarøyveien 30, 1331 Fornebu, orgnr. 976

Detaljer

Løsningsforslag til Case. (Analysen)

Løsningsforslag til Case. (Analysen) Løsningsforslag til Case (Analysen) Dette er en skisse til løsning av Case et med bussinformasjonssystemet. Jeg kaller det en skisse fordi det på den ene siden ikke er noe fasitsvar og fordi løsningen

Detaljer