Del 3
Elementer i en PKI-politikk for forvaltningen
7 Krav til digitale sertifikater som forvaltningen vil benytte
I dette kapitlet omtales ulike typer sertifikater som forvaltningen kan ha behov for. Innholdet i slike sertifikater drøftes med særlig vekt på unik identifisering av eiere av sertifikater.
7.1 Innledning
Et sertifikat er den digitale «legitimasjon» som eieren får utstedt for å garantere at den offentlige nøkkelen som vedkommende har fått, virkelig er hennes. Sertifikater kan utstedes for fysiske personer, virksomheter og roller, men også for PC-er, servere, nettverkskomponenter og programvare. PKI kan, med andre ord, brukes til å autentisere hvem som helst og hva som helst, når de er elementer i elektronisk samhandling over nett.
De mest aktuelle sertifikattypene er sertifikater for personer generelt, for ansatte i en organisasjon og for en virksomhet. Som regel utstedes slike sertifikater som identitetssertifikater, dvs. sertifikater som inneholder informasjon som entydig identifiserer eieren av sertifikatet.
Sertifikater for enkeltpersoner kan knyttes til, og gi informasjon om, eierens rolle i en virksomhet, eierens profesjon, autorisasjon eller andre egenskaper ved eieren. Personlige sertifikater kan utstedes med et pseudonym eller på en slik måte at eieren forblir anonym.
Virksomhetssertifikater kan brukes ved autentisering av forvaltningens web-anvendelser. Slik autentisering vil foregå automatisk og gi brukeren sikkerhet for at hun kommuniserer med den rette serveren og det rette systemet. Virksomhetssertifikater kan også benyttes der det f.eks. er aktuelt å signere som virksomhet, og ikke som enkeltperson ansatt i virksomheten.
Rollesertifikater er sertifikater for roller og autorisasjoner. Rollesertifikater kan utstedes på ulike måter: enten som et personlig sertifikat der det finnes spesielle informasjonselementer som beskriver hvilken rolle personen har i en gitt sammenheng (f.eks. styreformann i et selskap eller ordfører i en kommune) eller som et såkalt sekundærsertifikat, som knyttes til eierens personlige identitetssertifikat og som inneholder den samme offentlige nøkkelen som identitetssertifikatet. Et slikt sekundærsertifikat vil kunne inneholde referanse til identitetssertifikatet og beskrivelser av roller/autorisasjoner for eieren av identitetssertifikatet. Mangel på standardiserte løsninger for rollesertifikater gjør det vanskelig å ta slike sertifikater i bruk på kort sikt. Det mangler også standarder for å representere autorisasjoner og roller slik at brukere av sertifikatet (f.eks. innenfor hele EØS-området) vil kunne forstå hva som menes. I tillegg kan den praktiske håndteringen av rollesertifikater medføre vedlikeholdsproblemer, siden roller kan endre seg forholdsvis raskt.
7.2 Teknologiske begrensninger
7.2.1 Standarder
Sertifikater må være standardisert for å kunne brukes mellom kommunikasjonspartnere som ikke kjenner hverandre fra før. Den mest anvendte standarden er X.509 v3 (dvs. versjon 3 av ITU-standarden X.509).
X.509 v3 [ 37] er en omfattende standard med mange valgmuligheter. Standarden omhandler bare i begrenset grad innholdet i de forskjellige felter og attributter som kan inngå i et sertifikat. Sertifikater fra ulike tjenester kan se svært forskjellige ut.
Denne typen sertifikater kan ha utvidelser, som gir mer informasjon, bl.a. informasjon om hvordan sertifikatet kan brukes. Enhver utvidelse som ikke implementeres hos aktuelle motparter, vil kunne begrense bruken. Ved automatisert bruk av sertifikater må reglene for fortolkning av de enkelte feltene være helt entydige og like, f.eks. tolkningen av feltet som forteller hva den offentlige nøkkelen kan brukes til.
En spesifikasjon av hvordan en standard brukes i et bestemt tilfelle, f.eks. hvilke felt som tas med i et sertifikat og hvordan dette kodes, kalles en profil . En profil er en presisering av en standard tilpasset et konkret anvendelsesområde. Det finnes internasjonale standardprofiler for X.509-sertifikater. Internettstandarden RFC 2459 [ 37] beskriver en profil av X.509 v3 som skal kunne brukes innen PKI-basert kommunikasjon på Internett. Denne profilen er imidlertid ganske omfattende og trenger ytterligere presisering dersom man skal bruke den til konkrete formål.
På internasjonalt nivå er man avhengig av internasjonale standarder for profiler. Men det mangler mye på internasjonal koordinering av profiler, og nasjonale profiler i forskjellige land varierer en god del.
Programvare som benyttes for å signere, autentisere, kryptere samt verifisere signatur og dekryptere dokumenter, kan også sette begrensninger for bruk av sertifikater. Senders system og mottakers system må behandle sertifikater likt. Er systemenes behandlingsmåte meget forskjellig, kan dette skape hindringer, selv om man legger standardiserte sertifikater til grunn.
7.2.2 Kvalifiserte sertifikater
I lov om elektronisk signatur [ 52] defineres kvalifiserte sertifikater på grunnlag av EU-direktivets definisjon. Kvalifiserte sertifikater skal kunne benyttes for å framstille kvalifiserte elektroniske signaturer som ifølge loven skal gis eksplisitte rettsvirkninger. Betegnelsen kvalifisert sertifikat skal kunne brukes om sertifikater som oppfyller krav til bestemt innhold (definert i § 4 i loven) og utstedes for en bestemt periode av en sertifikatutsteder som oppfyller bestemte krav i lovens §§ 10–15, som f.eks. krav til at opplysninger om sertifikateier kontrolleres gjennom sikre rutiner og at relevante opplysninger lagres.
Informasjonsinnholdet i kvalifiserte sertifikater har flere tilleggskrav i forhold til Internett-profilen RFC 2459. Et kvalifisert sertifikat skal bl.a. ha felter som indikerer at det er et kvalifisert sertifikat, mulighet for avgrensing av bruksområdet for sertifikatet og eventuelt en grense for hvilken verdi en transaksjon kan ha.
Gjennom arbeidet utført av EESSI (jf. punkt 5.1.1) har Europakommisjonen sørget for at det ble utarbeidet en profil for kvalifiserte sertifikater. Denne er også blitt til en Internett-standard 1. Det kan være naturlig for forvaltninger i EØS-land, som implementerte EU-direktivet om elektroniske signaturer, å ta utgangspunkt i denne profilen når man skal anbefale nasjonale standarder for sertifikater.
7.2.3 Profiler for sertifikater som kan anvendes av den norske forvaltningen og av brukere av forvaltningens tjenester
I vedlegg 2 er det beskrevet sertifikatprofiler som utvalget anbefaler at man legger til grunn for utstedelse av sertifikater til bruk for forvaltningen og forvaltningens brukere. Disse profilene baserer seg på internasjonale standarder og profiler beskrevet ovenfor.
7.3 Ulike typer sertifikater
Forvaltningsnettsamarbeidet har, i forbindelse med inngåelse av rammeavtaler om digitale signaturer med tilhørende tjenester, gjennomført en utredning av behovet for standardisering av innholdet i sertifikater som forvaltningen kan bruke. Dette arbeidet ble oppsummert i en rapport [ 28] som ble lagt til grunn for anskaffelsen av løsninger på avtalen. I rapporten er det beskrevet fire typer sertifikater: medarbeidersertifikater, virksomhetssertifikater, rollesertifikater og profesjonssertifikater. Rapporten beskriver ikke sertifikater for servere eller anvendelser internt i forvaltningen, heller ikke sertifikater for privatpersoner og private virksomheter.
Utvalget har gjennomgått dette tidligere arbeidet samtidig som man har vurdert ulike behov for sertifikater i forbindelse med elektronisk samhandling innad i forvaltningen og med forvaltningens brukere. På grunnlag av dette, og på grunnlag av en vurdering av status i det internasjonale standardiseringsarbeidet og eksisterende teknologibegrensninger, har utvalget kommet fram til forslag til ulike typer sertifikater som det kan være behov for i forvaltningen.
7.3.1 Ansattsertifikat
Et ansattsertifikat er et personlig sertifikat for personer som er ansatt i en offentlig eller en privat virksomhet. Ansattsertifikat er et identitetssertifikat.
Formålet med et slikt sertifikat er entydig å kunne identifisere en person som ansatt i en virksomhet. Dette innebærer at sertifikatet bør inneholde opplysninger om selve virksomheten (navn, organisasjonsnummer) og om den ansatte (navn og ev. informasjon som unikt identifiserer den ansatte i virksomheten). Det kan i tillegg være hensiktsmessig å inkludere en e-postadresse til den ansatte og eventuelt navnet på den organisasjonsenheten den ansatte vil tilhøre.
Utvalget anbefaler at ansattsertifikater utstedes iht. profilen som er beskrevet i vedlegg 2.
Bruk av ansattsertifikater
Ansattsertifikater kan brukes til manuelle og halvautomatiserte forsendelser ut fra virksomheten. Arbeidsgivers organisasjonsnummer sikrer at mottaker med sikkerhet kan slå fast hvor forsendelsen kommer fra. Dette gjelder enten en saksbehandler eller en arkivar signerer og eventuelt krypterer forsendelsen. Autorisasjon til å utføre ekspederingen vil være en intern sak i virksomheten. En privatperson som mottar et digitalt signert brev med et ansattsertifikat, vil kunne verifisere både at dokumentet ble signert av den angjeldende offentlige ansatte og at dokumentet faktisk kommer fra en offentlig virksomhet.
Behovet for personlige digitale signaturer i forvaltningen kan diskuteres, særlig i lys av personvernet for de ansatte. Utsendelse av meldinger fra virksomheten kan imidlertid gjøres uten at det er nødvendig med personlig digital signatur. Se omtalen av virksomhetssertifikater nedenfor og forslag til regler i kapittel 11. Den ansattes navn vil uansett framgå av selve saksdokumentet som oversendes.
7.3.2 Virksomhetssertifikat
Et virksomhetssertifikat skal sikre kommunikasjon til og fra virksomheter og organisasjonsenheter. Det er ikke knyttet personinformasjon eller personidentifikasjon til virksomhetssertifikater.
Et virksomhetssertifikat bør inneholde informasjon om virksomhetens navn og organisasjonsnummer. Det er nærliggende at informasjon som skal ligge i slike sertifikater, hentes fra Enhetsregisteret i Brønnøysund. I tillegg til virksomhetens navn slik det er registrert i Enhetsregisteret, bør det også inkludere det navnet virksomheten til vanlig er kjent under. Virksomhetens felles e-postadresse (postmottaket) kan også tas med.
Utvalget anbefaler at virksomhetssertifikater utstedes iht. profilen som er beskrevet i vedlegg 2.
Bruk av virksomhetssertifikater
Virksomhetssertifikater kan benyttes av personer som er autorisert til å signere ekspedisjoner med slikt sertifikat. Det er nærliggende å tro at dette vil være personer knyttet til arkiv og/eller postekspedisjon. Men det kan også være saksbehandlere og ev. ledere som vil kunne bruke slike sertifikater. Det vil måtte utarbeides klare rutiner for tilgang til og bruk av virksomhetssertifikater i en offentlig virksomhet.
Den mest vanlige bruken av virksomhetssertifikater vil trolig være automatisert. Ved automatisert behandling av forsendelser fra en virksomhet, vil det ikke være en fysisk person som utfører signeringen av en forsendelse, men det vil være en fysisk person som starter prosessen som fører til slik signering.
Bruken av virksomhetssertifikater gir mulighet for å få vite avsender og integritetsbeskytte forsendelsen. Dette skjer ved å bruke nøkler og sertifikater, men det diskuteres om det er passende å kalle det signering. Slik signering kan på mange måter sammenliknes med bruk av brevhodet ved papirkorrespondanse.
Virksomhetssertifikater kan brukes til å dekke behovene innen elektronisk datautveksling, nemlig meldinger til og fra en tjeneste på en server.
Offentlige virksomheter har behov for å motta elektronisk post til seg eller til en avdeling på samme måte som de mottar fysisk post. Postmottaket eller et annet mottakende system vil måtte være i stand til å dekryptere e-post. Kryptering ved hjelp av nøkler knyttet til virksomhetssertifikater vil ikke være koplet til personer, men det vil måtte finnes rutiner og autorisasjoner for tilgang til virksomhetens private nøkkel for dekryptering.
Det kan være aktuelt å utstede sertifikater med nøkler for dekryptering til enheter i en virksomhet, f.eks. avdelinger.
For at enkeltpersoner og næringsliv skal kunne sikre konfidensielle forsendelser til forvaltningen, trengs det en mekanisme for spredning av virksomhetssertifikater med den offentlige krypteringsnøkkelen.
7.3.3 Profesjonssertifikat
Et profesjonssertifikat er et personlig sertifikat som bekrefter at personen har et bestemt yrke eller en utdanning og eventuelt autorisasjon/godkjenning fra en myndighet eller en organisasjon som godkjenner profesjonsrettigheter. Profesjonssertifikat kan betraktes som en kombinasjon av identitetssertifikat og rollesertifikat. Profesjonssertifikater kan f.eks. angi at man er lege, advokat eller skipsfører.
Et profesjonssertifikat vil i informasjonsinnhold likne på et personsertifikat, men den unike identifiseringen av eieren vil være en kode eller et nummer som inngår i et register over innehavere av relevant yrke/utdanning. Videre vil sertifikatet inneholde navnet på den myndighet eller organisasjon som har ansvaret for godkjenningen av yrket/utdanningen og som også administrerer rettigheter knyttet til det/den.
I tillegg kan sertifikatene inneholde et tittelfelt som gir en tekstlig beskrivelse av profesjonen 2. Denne beskrivelsen egner seg ikke for maskinell behandling, men kan brukes av en menneskelig mottaker for å vurdere autorisasjoner. Autorisasjoner må ellers sjekkes ved å sammenholde informasjonen i sertifikatene med informasjon i et register (f.eks. helsepersonellregisteret ).
Profesjonssertifikater kan utstedes av den myndighet/organisasjon som godkjenner profesjonen. Myndigheten/organisasjonen kan kjøpe den fysiske tjenesten for dette i markedet. Et alternativ er at kommersielle sertifikatutstedere sjekker profesjonstilhørighet hos aktuelle organisasjoner og utsteder sertifikater med unik identifikator innen den profesjonen.
Utvalget vil ikke ta stilling til hvilket alternativ som er det beste. Dette bør kunne avgjøres av hver enkelt sektor.
Utvalget anbefaler at profesjonssertifikater utstedes iht. profilen som er beskrevet i vedlegg 2.
Bruk av profesjonssertifikater
Profesjonssertifikater vil særlig være aktuelle i de tilfellene en person ikke tidligere er registrert i et mottakende system eller det ikke er hensiktsmessig med slik registrering. Mottakere av signerte meldinger/dokumenter kan i visse sammenhenger ha behov for å vite ikke bare hvem avsenderen er, men også hva slags rolle vedkommende opptrer i, samt om dette gir vedkommende autorisasjon til å utføre visse handlinger.
Denne problemstillingen kan være aktuell for enkelte selvstendig næringsdrivende, f.eks. advokater, revisorer eller leger. Et eksempel på bruk av et profesjonssertifikat kan være at en privatpraktiserende lege skal sende en digitalt signert resept til et apotek. Mottakersystemet må verifisere at sertifikatet er ekte og gyldig ved å sende en forespørsel til sertifikatutsteder. I tillegg må det sjekke at legen kan foreskrive medikamentet ved å sende en forespørsel til helsepersonellregisteret (dette vil innebære at det gjøres et oppslag i dette registeret på det unike helsepersonellnummeret som står i sertifikatet).
7.3.4 Offentlig personsertifikat
Et offentlig personsertifikat er et sertifikat for privatpersoner til bruk mot forvaltningens tjenester og systemer.
Der forvaltningen ønsker å kommunisere med enkeltpersoner ved hjelp av sertifikater, må sertifikatene ha det informasjonsinnholdet som er nødvendig for at forvaltningen skal kunne forsikre seg om at man har med riktig person å gjøre. Hvis forvaltningen går inn for at et bestemt felles sertifikatinnhold kan brukes mot flere av tjenestene/systemene, vil det lette enkeltpersoners samhandling med forvaltningen.
Kravene til identifisering av personer kan variere med sakstypen og de enkelte datasystemene, jf. Henvendelser som utløser veiledningsplikt, punkt 11.2.3.2. Det vil f.eks. ikke alltid være nødvendig for alle systemene i forvaltningen å kjenne til fødselsnummeret til den personen som signerte en elektronisk henvendelse.
Det vil neppe være hensiktsmessig at kommunikasjon mellom forvaltning og enkeltpersoner foregår med anonyme sertifikater. Hvis henvendelsen ikke er knyttet til et personlig forhold, er det rimelig å anta at det heller ikke er behov for sertifikat.
Et offentlig personsertifikat bør inneholde personens vanlig brukte navn. Utvalget ser det ikke som nødvendig at navnet skal hentes fra folkeregisteret. Det er tilstrekkelig at det ved registrering av personen i forbindelse med sertifikatutstedelse sjekkes mot folkeregisteret (gjennom oppslag på fødselsnummer) at det oppgitte navnet eksisterer og at personen som registrerte seg for å få utstedt et sertifikat, samsvarer med personen som er registrert.
I flere tilfeller vil det være behov for å identifisere personer unikt, og derfor bør sertifikatet inneholde en eller annen form for unik identifikator. Dette spørsmålet behandles i detalj i punkt 7.4.5.
Der det er ønskelig med slik informasjon, kan man i tillegg legge inn personens e-postadresse (dette er foranderlig informasjon og endring her kan føre til at hele sertifikatet må utstedes på nytt) og personens fulle navn slik det er registrert i folkeregisteret.
Utvalget anbefaler at offentlige personsertifikater utstedes iht. profilen som er beskrevet i vedlegg 2.
Bruk av offentlige personsertifikater
Offentlige personsertifikater skal kunne brukes både for autentisering mot forvaltningens tjenester og for signering av henvendelser, det være seg i form av et web-skjema eller elektronisk post. Autentisering vil trolig være den mest hyppige anvendelsen, som kan erstatte bruk av PIN-koder, fødselsnummer, passord osv. for å identifisere seg overfor en offentlig, personalisert tjeneste.
Det er lite sannsynlig at offentlige personsertifikater vil bli brukt til kryptering av forvaltningens kommunikasjon til privatpersoner, selv om slik bruk ikke kan utelukkes. Konfidensialitetssikring av privatpersoners kommunikasjon med forvaltningen vil for det meste skje gjennom bruk av krypterte forbindelser til forvaltningens systemer.
7.3.5 Sertifikater for private bedrifter
Utvalget ser at det i pilotanvendelser legges opp til at forvaltningen selv utsteder nødvendige sertifikater til bedrifter som skal drive elektronisk samhandling med forvaltningen. Dette kan kalles en «bransjemodell» der sertifikater er tilpasset den konkrete anvendelsen som forvaltningen har lagt opp til. I en seinere fase vil bedriftene trolig selv anskaffe sertifikater på markedet, gitt at forvaltningen godtar slike. På dette området kan det tenkes at forvaltningen i framtiden vil kunne godta bruk av sertifikater tilsvarende ansattsertifikater samt virksomhetssertifikater i forvaltningen og bruk av sertifikater tilsvarende offentlige personsertifikater.
7.3.6 Sertifikater fra andre land
Offentlig forvaltning vil kunne trenge å samhandle elektronisk med forvaltninger, organisasjoner, privatpersoner og bedrifter i andre land. De mest aktuelle landene er land i EØS-området, men flere etater, som f.eks. Rikstrygdeverket, vil ha behov for kommunikasjon med land utenom EØS der det finnes mottakere av deres ytelser. Kommunikasjonen vil mest sannsynlig gjelde utveksling av dokumenter/skjemaer. Pengetransaksjoner utføres i dag i stor grad gjennom det verdensomspennende banksystemet SWIFT og på andre avtalte måter. Utbredelsen av globale sertifikattjenester som IDENTRUS 3 vil bidra til at bedrifter vil kunne benytte sertifikater i kommunikasjon over landegrensene.
Forvaltningen vil være avhengig av en felles forståelse når det gjelder bruk av sertifikater fra utlandet. Dette omfatter bl.a. tolkning av innholdet i feltene i sertifikatene. EU-direktivet om rammeverk for elektroniske signaturer gir et rettslig utgangspunkt for aksept av sertifikater fra andre land. Implementeringen av direktivet vil imidlertid variere fra land til land. Dette kan skape utfordringer for de praktiske løsningene på området.
Håndtering av sertifikater fra andre land er et spørsmål som forvaltningen må utrede videre. Den internasjonale situasjonen på dette området er i stadig endring, med ny lovgivning og utvikling av nasjonale politikker for bruk av PKI i mange land.
Utvalget anbefaler at den norske forvaltningen deltar i internasjonale fora der forvaltninger i andre land drøfter bruk av PKI.
Utvalget anbefaler at spørsmålet om håndtering av sertifikater fra utlandet utredes videre, når implementeringen av EU-direktivet er avsluttet i EØS-land.
7.4 Standardisert bruk av navn og unike identifikatorer i sertifikater
7.4.1 Hvorfor trenger man standardiserte navn og unike identifikatorer?
Automatisk behandling av sertifikater krever entydige regler for identifisering av sertifikateier, som gir sikkerhet for at man samhandler med riktig person eller virksomhet/organisasjon. Informasjon som kan hentes ut fra sertifikatet, vil bli brukt til videre behandling av henvendelsen i forvaltningens interne systemer.
I noen systemer vil det være et krav at navnet er i samsvar med det navnet som er registrert i folkeregisteret . Selv om navnet står i folkeregisteret, gir det ikke nødvendigvis en entydig identifikasjon av sertifikatets eier, selv om det også kan finnes andre opplysninger i sertifikatet som kan gi nærmere identifisering, f.eks. fødselsdato. Det kan finnes flere personer med navnet Petter Olsen som er født på samme dag. Derfor trenger man en unik identifikator som entydig identifiserer sertifikateieren innen det domenet (anvendelsesområdet) som brukeren av sertifikatet vil forholde seg til. For ansattsertifikater vil et slikt domene være virksomheten selv, mens det for offentlige personsertifikater vil dreie seg om hele landet, fordi slike sertifikater skal kunne utstedes til enhver registrert innbygger i Norge.
Noen systemer og anvendelser, f.eks. e-post, vil ikke nødvendigvis kreve at sertifikater inneholder navn og identifikator iht. folkeregisteret. Hvorvidt forvaltningen trenger å standardisere navn og unike identifikatorer, vil avhenge av hvordan hvert datasystem skal bruke informasjonen i sertifikatene. Og hvis det oppstår problemer med hvem som har sendt en e-post, kan identiteten sjekkes ytterligere på et seinere tidspunkt. Saksbehandleren bør vurdere behovet for ytterligere autentisering i forhold til den aktuelle saken, jf. punkt 11.2.3.
I forbindelse med tildeling av navn til eiere av sertifikater har man definert en egen funksjon – navngivingsfunksjonen. En slik funksjon må operere innenfor et navnerom eller et navnedomene . Et navnerom er en samling av navn som kan tildeles visse objekter (personer, virksomheter, datamaskiner osv.). Regler som styrer denne tildelingen, kalles navngivingsregler [ 28] og skal sørge for at det ikke utstedes to ulike sertifikater og nøkler med identiske navn for samme formål. En offentlig virksomhet som ønsker å utstede sertifikater til egne ansatte kan ha sitt eget navnerom.
Bruken av navn kan variere avhengig av hva sertifikatet anvendes til. Noen systemer vil ikke lese navnet i sertifikatet i det hele tatt. Enkelte av Rikstrygdeverkets anvendelser der PKI brukes, leser ikke navnet i sertifikatet.
Er det ønskelig, sett fra forvaltningens side, at enkeltpersoner identifiserer seg på samme måte overfor dens systemer? Hvis navnet i offentlige personsertifikater kommer fra folkeregisteret, har alle forvaltningens systemer én måte å forholde seg på. Men navn er uansett ikke unikt, så behovet for, og nytten av, å inkludere slikt navn i sertifikater vil være begrenset.
I lov om elektronisk signatur [ 52] kreves det at kvalifiserte sertifikater skal inneholde undertegnerens navn eller pseudonym, men det stilles ikke ytterligere krav til navnet. Dette kan endre seg når det foreligger ferdig forskriftsverk til loven.
Pseudonyme sertifikater er nok mest anvendelige i forbindelse med handelstransaksjoner, der det for selgeren ikke er viktig hvem som er kjøperen, men om kjøperen er i stand til å betale varen/tjenesten. I forvaltningens transaksjoner med brukere er det derimot svært viktig å vite hvem man har med å gjøre. Korrekt og pålitelig identifisering av personer er en grunnleggende forutsetning for at enkeltpersoner kan utøve sine rettigheter og plikter overfor forvaltningen.
Et system i forvaltningen må ha standardiserte navngivingsregler å forholde seg til for hvert sertifikat det behandler. Jo flere sertifikatutstedere som følger en standard for navngiving, f.eks. en sertifikatprofil, jo enklere kan bruken av PKI bli.
7.4.2 Unik identifisering av ansatte i ansattsertifikater
Et ansattsertifikat bør inneholde minimum følgende opplysninger:
Personens vanlig brukte navn (hentet fra personalregisteret eller tilsvarende),
Ansattnummer eller tilsvarende unik identifikator innenfor virksomheten, f.eks. initialer,
Personens arbeidsgiver (virksomhetens vanlig brukte navn),
Arbeidsgiverens organisasjonsnummer,
Landkode.
Utvalget mener at disse opplysningene til sammen vil kunne identifisere en person som er ansatt i en offentlig virksomhet på en entydig måte. Koding av denne informasjonen skal skje iht. profilen som er beskrevet i vedlegg 2.
7.4.3 Unik identifisering av virksomheter i virksomhetssertifikater
Et virksomhetssertifikat bør inneholde minimum følgende opplysninger:
Virksomhetens vanlig brukte navn (oppgis av virksomheten selv),
Virksomhetens organisasjonsnummer (hentet fra Enhetsregisteret),
Virksomhetens registrerte navn (hentet fra Enhetsregisteret),
Landkode.
Virksomhetssertifikater skal kunne benyttes for å autentisere en virksomhet (juridisk person) og dennes offentlige nøkkel. Det er naturlig å benytte det navnet som virksomheten selv velger å bruke til daglig, samtidig som det er behov for entydig identifisering av den juridiske personen. Enhetsregisteret er navne- og nummerautoriteten på dette området, og det anbefales derfor å ta med både organisasjonsnummer og det fulle virksomhetsnavnet slik det er registrert i dette registeret. Disse opplysningene gir til sammen gode muligheter til å verifisere at det dreier seg om riktig juridisk person.
Koding av opplysninger i virksomhetssertifikatet bør skje iht. den foreslåtte profilen i vedlegg 2.
7.4.4 Unik identifisering av personer i profesjonssertifikater
Et profesjonssertifikat bør inneholde minimum følgende opplysninger:
Personens vanlig brukte navn,
Unik identifikator for denne personen som utøver av et yrke eller innehaver av en utdanning (hentes fra relevant register hos den myndighet eller organisasjon som har i oppgave å godkjenne yrke/utdanning og føre slikt register),
Yrkes- eller utdanningstittel (f.eks. lege spesialist psykiatri),
Organisasjonsnummer til den myndighet/organisasjon som fører registeret,
Vanlig brukt navn til den myndighet/organisasjon som fører registeret,
Landkode.
Profesjonssertifikater vil bli brukt på en annen måte enn ansattsertifikater, fordi det er personen som utøver av et yrke/innehaver av en utdanning som er subjektet her, og ikke personen som ansatt i en virksomhet. Unik identifisering av personen i en slik sammenheng vil kunne skje på grunnlag av den unike identifikatoren og på grunnlag av opplysninger om den myndigheten/organisasjonen som fører registeret der personen er registrert med denne identifikatoren.
For lukkede anvendelser innenfor helsesektoren kan det være aktuelt med rene personsertifikater med bruk av helsepersonellnummer som unik identifikator [ 8]. Dette vil bli nærmere drøftet i sektoren.
Koding av opplysninger i virksomhetssertifikater bør skje iht. den foreslåtte profilen i vedlegg 2.
7.4.5 Unik identifisering av personer i offentlige personsertifikater
Ut fra tidligere argumentasjon framgår det at det er nødvendig å kunne identifisere eiere av offentlige personsertifikater unikt. I praksis betyr det at man via sertifikatet skal kunne få tilgang til innehaverens fødselsnummer. Den enkleste måten å løse dette på, vil være å ha fødselsnummeret i sertifikatene. Det finnes også andre måter å ivareta identifiseringsbehovet på.
Brønnøysundregistrene , Skattedirektoratet og Statistisk sentralbyrå ba i brev av 10.5.2000 utvalget om å ta hensyn til etatenes behov for å kunne identifisere enkeltindivider på en sikker måte. Som mulig løsning foreslår de at det stilles krav til sertifikatutstedere i markedet om at de kopler personlige sertifikater med fødselsnummer, og at alle utstedere skal inngå avtale om kryssertifisering (jf. omtale i kap. 10) for bruk av slike sertifikater.
Forvaltningen må spesifisere hvordan unike identifikatorer (fødselsnummer eller annet) skal brukes i sertifikater som skal benyttes innenfor og mot forvaltningen. Dersom fødselsnummer skal brukes, må betingelsene for dette avklares, spesielt med tanke på personvern og tilgang til kataloger.
Det vil eksistere frykt i opinionen for at fødselsnummer vil kunne spres og brukes/misbrukes i stor grad. Fødselsnummer vil følge med i det tilhørende sertifikatet når man signerer digitalt. Mange mennesker ser på fødselsnummeret sitt som sensitiv informasjon, selv om det ikke er å betrakte som det, ut fra bestemmelser i lov om behandling av personopplysninger. Man trenger programvare for å lese innholdet i sertifikater, og lesing av annen informasjon enn navnet, utsteder og gyldighetsperiode krever spesialtilpasninger i programvaren. Det kan likevel tenkes at de som ønsker å spore en persons aktiviteter ved å lese sertifikater som brukes i ulike transaksjoner på nettet, vil kunne skaffe seg slik tilpasset programvare og tilgang til de aktuelle sporene.
Ut fra hensynet til opinionen kan det være ønskelig å finne alternativer til å bruke fødselsnummer direkte i sertifikater.
Ett alternativ, som er tatt i bruk i Finland i forbindelse med at det finske folkeregisteret utsteder elektroniske ID-kort til befolkningen, er å ta i bruk en ny nummerserie for å tildele unike identifikatorer for bruk i sertifikater. Det nye nummeret – FINUID – blir definert som et unikt nummer for brukere av det elektroniske ID-kortet. Gjennom regulering i lov har finnene sørget for at dette nummeret legges inn i folkeregisteret, i tillegg til det «vanlige» personnummeret.
Dersom bruken av et slikt nummer blir svært utbredt, vil det fort kunne føre til at dette nummeret vil få samme funksjon som fødselsnummeret. Videre kan det være kostbart å vedlikeholde to parallelle nummersystemer.
Et annet alternativ er at fødselsnummeret kjøres gjennom en beregning (en enveis hash-algoritme) som genererer en ny, unik identifikator. Brukere av sertifikatet som har adgang til fødselsnummeret og annen nødvendig informasjon, kan da bruke samme algoritme for å fastslå samsvar. Ved bruk av dette alternativet bør det defineres krav til slik algoritme, både når det gjelder kvalitet og ytelse, dvs. hvor pålitelig algoritmen er, og hvor raskt prosessering av fødselsnummeret kan skje.
Et tredje alternativ går ut på at sertifikatutsteder genererer en identifikator som er unik for hver sertifikateier innen denne utsteders domene. Hvis identifikatoren f.eks. svarer til serienummeret i sertifikatet, vil det endres ved hver nyutstedelse. Det legger til rette for å hindre sporing, men vil bli vanskelig å administrere. Identifikatoren bør derfor være unik for personen over tid, f.eks. personens levetid. Utsteder vil ha en tabell som kopler den unike identifikatoren, fødselsnummer og eventuelt navn, se figur 7.2. En institusjon som har tjenstlig behov for det, vil få tilgang til tabellen, f.eks. ved sjekk av sertifikatet mot en tilbaketrekkingsliste. Institusjonen vil så kunne hente fødselsnummeret ut av tabellen og bruke det i sin videre behandling.
På denne måten unngår man at fødselsnummeret inngår direkte i sertifikatet samtidig som det er forholdsvis lett tilgjengelig for de som har autorisasjon til å bruke nummeret. Det vil heller ikke være slik at den unike identifikatoren, knyttet til én utsteder, vil erstatte fødselsnummeret. Dersom det finnes minst to sertifikattilbydere med hver sin unike identifikatorserie, kan enkeltpersoner velge, og man slipper en landsdekkende unik identifikator.
Et eksempel på hvordan et slikt system vil kunne fungere med flere utstedere vises i figur 7.3. (Navn er tatt med for å lette forståelsen av eksempelet. Implementasjonen kan være en annen.)
En slik løsning brukes i ELEKTRA -prosjektet i Skattedirektoratet . Leverandøren av sertifikattjenester til Skattedirektoratet utsteder sertifikater med en unik identifikator, og har et register som oversetter denne til fødselsnummer, før de innrapporterte opplysningene sendes fra leverandørens formidlingssentral til Skattedirektoratet. ELEKTRA-prosjektet er et eksempel på at sertifikater som behandles maskinelt må inneholde unik identifikator for å utføre de rette operasjoner/behandlinger av den informasjonen som er signert ved bruk av dette sertifikatet. Løsningen i ELEKTRA fungerer godt fordi formidlingssentralen, der signaturen verifiseres, og sertifikatutstederen, som har koplingen mellom unik identifikator og fødselsnummer, er en og samme organisasjon.
Det må likevel pekes på at en slik løsning kan skape problemer ved automatisk behandling av sertifikater der det ikke benyttes såkalte formidlingssentraler, i og med at det må gjøres flere sjekk/oppslag mot sertifikatutsteder enn det som ville vært nødvendig om fødselsnummeret lå direkte i sertifikatet. Dette kan øke kostnadene og skape sårbarhet.
Ved helautomatisk behandling av sertifikater vil innholdet i svært begrenset grad eksponeres for mennesker. Der det tjenstlige behovet tilsier det, bør derfor bruk av fødselsnummeret direkte i sertifikatet være mulig.
Utvalget mener for øvrig at unik identifisering av personer i offentlige personsertifikater vil kunne oppnås ved at sertifikatet inneholder minimum følgende opplysninger:
Personens vanlig brukte navn,
Unik identifikator tildelt av sertifikatutstederen eller fødselsnummer,
Landkode.
Opplysningene i sertifikatet bør kodes iht. den foreslåtte profilen i vedlegg 2.
7.5 Oppsummering av utvalgets anbefalinger
Utvalget anbefaler at det for bruk internt i forvaltningen og i forbindelse med elektroniske tjenester til enkeltpersoner, tas i bruk fire ulike typer sertifikater:
Ansattsertifikater,
Virksomhetssertifikater,
Offentlige personsertifikater,
Profesjonssertifikater.
Utvalget anbefaler at sertifikatene kodes og tolkes iht. respektive sertifikatprofiler, utarbeidet på grunnlag av profil for kvalifiserte sertifikater i EU. Profilene er beskrevet i vedlegg 2.
Utvalget ser ingen enkel og generell løsning for sertifikater for autorisasjoner og roller på det nåværende tidspunkt.
Utvalget anbefaler at spørsmålet om utstedelse av profesjonssertifikater utredes nærmere og avgjøres av de myndigheter og organisasjoner som har ansvaret for føring av relevante registre over yrke/utdanning som gir rettigheter.
Utvalget ser ikke at forvaltningen har behov for anonyme eller pseudonyme sertifikater.
Utvalget ser ikke noe behov for at navn som er registrert i folkeregisteret, skal legges inn i offentlige personsertifikater. Personens vanlig brukte navn bør benyttes. Det forutsettes at sertifikatutstederen foretar sjekk av identiteten gjennom oppslag på fødselsnummer i folkeregisteret.
Utvalget anbefaler at det for unik identifisering av ansatte i ansattsertifikater inkluderes opplysninger som: den ansattes vanlige navn og ansattnummer eller annen entydig kode, f.eks. initialer, arbeidsgiverens vanlig brukte navn og organisasjonsnummer samt landkode.
Utvalget anbefaler at det for unik identifisering av virksomheter i virksomhetssertifikater inkluderes opplysninger som: virksomhetens registrerte navn og organisasjonsnummer fra Enhetsregisteret samt landkode.
Utvalget anbefaler at det for unik identifisering av innehavere av et yrke/en utdanning i profesjonssertifikater inkluderes opplysninger som: personens vanlig brukte navn, unik identifikator i det registeret der personen er registrert, navn og organisasjonsnummer til den myndigheten/organisasjonen som fører registeret, samt landkode.
Utvalget anbefaler at det for unik identifisering av privatpersoner i offentlige personsertifikater inkluderes opplysninger som: personens daglig brukte navn og en identifikator som er unik innen utsteders domene, og som kan koples til fødselsnummer ved tjenstlige behov. Der spesielle behov gjør seg gjeldende, kan fødselsnummer inngå direkte i sertifikatet.
Utvalget anbefaler at forvaltningen går i dialog med næringslivet om bruk av sertifikater. Det vil være ønskelig at næringslivet legger seg nært opp til forvaltningens felleskrav på området.
Utvalget anbefaler at håndtering av sertifikater fra utlandet må utredes nærmere når situasjonen i EØS-land er klarere mht. implementering av EU-direktiv om elektroniske signaturer.
Utvalget anbefaler at forvaltningen deltar i internasjonale fora der bruk av PKI i forvaltningen drøftes.
8 Behov for felles sertifikatpolicy i forvaltningen
Dette kapitlet omhandler krav som forvaltningen bør stille til sikkerhet i forbindelse med utstedelse og behandling av sertifikater som brukes av forvaltningen og sertifikater som skal brukes av enkeltpersoner og næringslivet i samhandling med forvaltningen.
8.1 Sertifikatpolicy
En sertifikatpolicy er et dokument som omhandler regler for hvordan digitale sertifikater utstedes og behandles på et gitt bruksområdet, og hvordan ansvaret for sikkerheten ved dette ivaretas. Sertifikatpolicyen fastsetter sikkerhetsnivået for utstedelse og behandling av sertifikater og derigjennom tillitsnivået sertifikatet representerer.
En utsteder av sertifikater vil alltid måtte være i stand til å framvise den sertifikatpolicyen som han utsteder sertifikater etter.
En sertifikatutsteder kan operere etter flere sertifikatpolicyer. For eksempel spesifiserer policyer om en bruker trenger å møte fram personlig for å få utstedt et sertifikat eller om sertifikatet kan sendes via e-post. Ulike prosedyrer kan gi ulik tillit til sertifikatene.
Det er viktig å merke seg at en sertifikatpolicy er et dokument som er unikt identifisert på global basis. Dette skjer ved at en policy registreres hos den internasjonale standardiseringsorganisasjonen ISO, og der får den tildelt et unikt nummer, såkalt OID (Object IDentifier ), som skiller dette dokumentet fra alle andre dokumenter. Vurdering av tillitsnivå for et sertifikat kan således foregå ved at det i sertifikatet står OID ved den sertifikatpolicy som sertifikatet er utstedt etter. Ved å følge pekeren til dokumentet og ved å lese det kan brukeren få et bilde av sikkerheten ved dette sertifikatet. Dette er selvfølgelig en altfor tungvint metode for å vurdere hvert enkelt sertifikat som man kommer over. Innføringen av kvalifiserte sertifikater gjennom EU-direktivet er ment å skulle forenkle dette, ved at det skal være et standardisert sikkerhetsnivå for slike sertifikater (jf. omtalen under punkt 8.2.5).
En sertifikatpolicy vil blant annet omfatte følgende elementer:
Området policyen virker på (hvordan sertifikatene som utstedes, vil bli brukt),
Organiseringen av sertifikatutsteders virksomhet,
Utstederens generelle forpliktelser,
Hvordan identitetskontroll ved utstedelse av sertifikater foregår,
Operasjonelle krav til driften av utstedersystemet,
Hvordan de fysiske og administrative sikkerhetstiltakene gjennomføres,
Hvilket teknisk sikkerhetsnivå tjenesten opererer på og
Hvilke sertifikatprofilerog profiler for tilbaketrekkingslisten som tjenesten benytter.
Et eksempel på en sertifikatpolicy er Forvaltningsnettsamarbeidets sertifikatpolicy, FSP-1 [ 2]. FSP-1 har OID 216578112111. Denne sertifikatpolicyen har ErgoGroup (tidl. Posten SDS) , Telenor og Strålfors implementert i forbindelse med leveranse av tjenester under rammeavtalen under Forvaltningsnettsamarbeidet.
Private aktører i markedet som utsteder sertifikater, kan definere egne sertifikatpolicyer i tillegg til å implementere policyer som f.eks. forvaltningen ønsker å benytte.
Sertifikatpolicyer utgjør en del av en politikk for bruk av digitale signaturer og PKI. Forvaltningen må derfor klargjøre sine krav til sertifikatpolicy. Kravene må baseres på forutsetninger i regelverket som ligger til grunn for offentlig virksomhet. Dette kan variere fra sektor til sektor og fra virksomhet til virksomhet. Regelverket vil danne utgangspunktet for krav til sikkerhet ved forvaltningens elektroniske tjenester og interne systemer. Krav til sikkerhet må så nedfelles i en sertifikatpolicy.
Ulike elektroniske tjenester, som f.eks. tilgang til byggesaker eller innsyn i egen helseinformasjon, kan ha ulike krav til sikkerheten ved de digitale signaturene (sertifikatene) som man ønsker å benytte i forbindelse med bruk av tjenestene. Hvis flere forvaltningsvirksomheter stiller tilnærmet like sikkerhetskrav til sine tjenester, kan de benytte samme sertifikatpolicy.
8.2 Sikkerhetsnivåer
Sertifikatpolicyer kan tilhøre ulike sikkerhetsnivåer for sertifikatutstedelse. Sikkerhetsnivåer sier noe om hvilken tillit man kan ha til sertifikatene og dermed i hvilke sammenhenger de kan brukes.
Sikkerhetsnivåer vil vanligvis være hierarkiske, i den forstand at sertifikater utstedt på et lavt sikkerhetsnivå f.eks. vil kunne brukes bare for tilgang til bestemte anvendelser. Sertifikater utstedt på et høyere sikkerhetsnivå vil kunne benyttes for andre typer anvendelser, med strengere sikkerhetskrav. De samme sertifikatene vil også kunne brukes for de anvendelsene som sertifikatene med lavere nivå gir tilgang til.
8.2.1 Hva kan skille sikkerhetsnivåer?
Et sikkerhetsnivå for utstedelse av sertifikater hos en sertifikatutsteder vil bestemmes av kravene som beskrives i de ulike delene av en sertifikatpolicy for dette nivået. For de fleste sertifikattyper vil det finnes noen felles krav. De vil finnes i flere policyer for ulike nivåer. Men policyene vil skille seg fra hverandre på bestemte områder avhengig av hva slags sikkerhetsnivå det dreier seg om. Slike områder eller kriterier er:
Hvordan sertifikateieren identifiseres og registreres,
Hvordan utlevering av private nøkler og sertifikater skal foregå,
Algoritmer som kan brukes, og nøkkellengder,
Hvordan nøkler genereres,
Antall nøkkelpar og hvordan nøklene kan brukes,
Hvordan de private nøklene beskyttes,
Hvordan sertifikater trekkes tilbake.
8.2.2 Beskrivelse av kriterier for å bestemme sikkerhetsnivå
Identifisering av sertifikateier
Et sertifikat vil ha større tillit hvis sertifikatutsteder har sjekket opplysninger om sertifikateieren grundig og på grunnlag av tillitvekkende dokumenter. I Norge kan sertifikatutstedere be om personens fødselsnummer, for så å foreta oppslag i folkeregisteret. De må imidlertid være sikre på at det oppgitte fødselsnummeret virkelig tilhører den personen som kom med det. Dette kan gjøres ved å vurdere en tillitvekkende legitimasjon med bilde av personen der nummeret er med. Dette innebærer at personen helst bør møte opp fysisk for helt sikker identifisering. Eksempel på identifiseringsprosedyrer er bankenes prosedyrer for registrering av nye kunder, som reguleres av en egen forskrift. 4 Den internasjonalt kjente sertifikatutstederen VeriSign kan utstede en type sertifikat kun på grunnlag av e-postadressen som oppgis av den som ønsker sertifikatet utstedt.
Utlevering av private nøkler og sertifikater
Prosedyrer for utlevering av private nøkler og sertifikater er avhengig av hvordan og av hvem de private nøklene blir generert. Dersom eieren genererer sine nøkler selv, behøver vedkommende i prinsippet ikke å møte opp personlig. Et sertifikat for eierens offentlige nøkkel vil utstederen legge i en katalog. Et sertifikat som hentes fra en katalog eller som sendes til eieren via e-post, vil oppfattes som mindre sikkert enn der eieren må møte fram, identifisere seg og vise at hun har tilgang til den tilhørende private nøkkelen. Et sertifikat som bare sendes sertifikateieren via e-post, vil alltid være et «mykt» sertifikat, dvs. at sertifikatet og den tilhørende private nøkkelen lagres i en datafil. Dersom den private nøkkelen genereres av sertifikatutstederen, er det en sikrere prosedyre hvis sertifikateieren møter fram og mottar (etter legitimering) en diskett eller et smartkort med nøkkelen enn at den sendes/hentes kryptert over nett. Tilliten til et sertifikat vil også variere med om utstederen kan garantere at den tilhørende private nøkkelen alltid har vært under full kontroll av utsteder eller eier.
Algoritmer som kan brukes, og nøkkellengder
Teknologien som ligger til grunn for digitale signaturer, asymmetrisk kryptografi , innebærer bruk av såkalte asymmetriske krypteringsalgoritmer. Disse algoritmene er i stand til å finne ut om det var den riktige private nøkkelen som ble brukt ved signering eller autentisering. Den samme algoritmen vil også kunne dekryptere den nøkkelen som ble brukt til forvrenging av dokumentinnholdet, slik at innholdet i dokumentet kan dekrypteres også. Ved digital signering brukes i tillegg såkalte hash-algoritmer, og ved kryptering av dokumentinnholdet brukes en symmetrisk krypteringsalgoritme, i tillegg til den asymmetriske. Alle disse algoritmene må være av god kvalitet. For asymmetriske algoritmer betyr det at den private nøkkelen skal være umulig å utlede fra den offentlige, for hash-algoritmer betyr det at sannsynligheten for å generere samme resultat på to ulike dokumenter bør være lik null, og for symmetriske kryptoalgoritmer bør det være umulig å finne nøkkelen ved å analysere den forvrengte teksten. Kvaliteten på kryptoalgoritmer avhenger av hvor lange 5 nøklene er – jo lengre nøkler, jo bedre kvalitet. Men nøkkellengden er ikke det eneste som er viktig – også selve den matematiske oppbyggingen av algoritmen har mye å si.
Tabell 8.1 over nøkkellengder og tiden det tar å bryte en symmetrisk kryptoalgoritme*)
Nøkkellengde | Individuell hacker | Liten gruppe | Akademisk gruppe | Stor virksomhet | Etterretningstjeneste |
---|---|---|---|---|---|
40 bit | Uker | Dager | Timer | Millisek | Mikrosek |
56 bit | > 100 år | > 10 år | År | Timer | Sek |
64 bit | > 1000 år | > 100 år | > 10 år | Dager | Minutter |
80 bit | Ikke praktisk | Ikke praktisk | Ikke praktisk | > 100 år | > 100 år |
128 bit | Ikke praktisk | Ikke praktisk | Ikke praktisk | Ikke praktisk | > 1000 år |
*) Tabellen er hentet fra den danske utredningen Sammenfattende evaluering af Forskningsministeriets pilotprosjekter om digital signatur, publisert i september 2000.
Som tabellen illustrerer, kan kryptosystemer brytes over tid og nøklene bli for korte. Dette skaper sikkerhetsmessige utfordringer og er også årsaken til at nøkler og sertifikater utstedes for begrensede perioder. Kvaliteten på algoritmene har betydning for tilliten til signaturen og for tilliten til konfidensialitetssikringen som bruk av PKI kan gi.
Hvordan nøkler genereres
Nøkler kan genereres på ulike måter. Nøkler kan genereres enten av sertifikatutsteder eller dennes underleverandør. De kan også genereres av eieren selv. Det finnes programvare for PC-er som er lagt til rette for det. Nøkler til VeriSign-sertifikater 6 genereres i PC-en. Da reiser spørsmålet seg om hvor tillitvekkende denne programvaren er, og hvor godt beskyttet en PC er mot ondsinnede angrep.
Nøkler generert av brukeren selv vil alltid være «myke» nøkler, dvs. lagret i en kryptert fil i PC-en. Hos en sertifikatutsteder kan nøkler genereres i et lukket og beskyttet datasystem og deretter bli lagt på en spesialdiskett, på et smartkort eller i en kryptert datafil som utleveres eieren (jf. avsnittet om utlevering). Nøkler kan også genereres direkte på smartkortet (av utstederen eller en kortprodusent), slik at den private nøkkelen aldri forlater dette kortet. Valg av genereringsmetode vil ha betydning for tilliten til nøklene og dermed tilliten til signering mv.
Hvordan nøkler kan brukes
En PKI kan gi støtte for tre ulike funksjoner – signering av dokumenter, kryptering av dokumenters innhold og også identifisering (autentisering) av kommuniserende parter på nettet. Alle disse funksjonene kan i prinsippet utføres ved å bruke ett nøkkelpar, der det i sertifikatet for den offentlige nøkkelen vil stå at denne nøkkelen kan brukes til alle tre. Dette er dog en mindre sikker måte å bruke PKI på. Av grunner omtalt nedenfor bør en bruker ha flere sett av asymmetriske nøkler:
Én nøkkel til autentisering ved f.eks. pålogging til et system,
Én nøkkel til signering for ikke-benekting av et dokument/melding, og
Én nøkkel til kryptering (av symmetriske engangsnøkler).
Dersom man bruker en nøkkel som er merket for både signering og autentisering, kan man ved autentisering overfor et ukjent system risikere å signere et dokument uten å vite det. Sannsynligheten for dette er neppe stor, men det gir en utrygghet. Videre ønsker man i noen situasjoner ikke å signere et dokument digitalt, men man vil sikre at det ikke endres ved oversendelse (integritet ), og at mottakeren vet sikkert hvor det kommer fra. Da kan man bruke en autentiseringsnøkkel, men den må kun være merket for den bruken, ellers vil mottakeren anta at dette dokumentet er signert for ikke-benekting.
Forvaltningen og eventuelt andre arbeidsgivere kan ha behov for å ha kopi av ansattes private nøkler som brukes til kryptering (jf. kapittel 11) . Hvis nøkkelen har flere funksjoner, vil man f.eks. kunne komme til å ta kopi av nøkkelen for signering samtidig. Dette er en svært lite ønskelig praksis.
Dette tilsier at separate nøkkelpar for alle tre funksjoner er ønskelig. Programvare for signering og kryptering som finnes i markedet, gir full støtte til bruk av to ulike nøkkelpar. Men ikke alle produkter kan bruke tre nøkkelpar. På grunn av dette vil det i en overgangsfase være behov for å bruke to nøkkelpar med de tre funksjonene «fordelt» på dem. Det pågår diskusjoner om hvordan slik fordeling skal være. Forvaltningen i enkelte land satser på ett nøkkelpar til både signering og autentisering, mens andre heller vil ha et separat nøkkelpar for signering og det andre for de resterende funksjonene. Behovet for kopi av krypteringsnøkkelen tilsier igjen at dette nøkkelparet bør være separat.
Bruken av nøkkelpar påvirker også tilliten til digitale signaturer og PKI. Tre separate nøkkelpar gir ikke rom for uklarheter og inngir dermed størst tillit.
Hvordan nøklene beskyttes og signaturer framstilles
En privat nøkkel kan lagres kryptert i en datafil, på en spesialdiskett, på et smartkort, på et såkalt PCMCIA-kort 7 eller i spesialelektronikk (f.eks. i en server). Tilgang til å bruke nøkkelen får brukeren ved å taste inn en PIN-kode eller et passord. Man kan også bruke såkalte biometriske metoder istedenfor PIN eller passord for å få tilgang til private nøkler. Et eksempel på en slik metode er lesing av fingeravtrykket. Utbredelsen av utstyr til dette er ennå liten.
PIN-koder og passord bør kunne bestemmes av nøkkeleieren selv. Dette fordrer imidlertid at det finnes adekvat kontrollprogramvare som sørger for at de valgte PIN-kodene og passordene er av tilstrekkelig god kvalitet.
En nøkkel som lagres og brukes i et smartkort og beskyttes med PIN-kode, regnes for å gi høy grad av tillit til at bare eieren kan benytte den. Private nøkler lagret i en PC vil også bli beskyttet med en PIN-kode eller et passord, men det er større risiko for at nøklene kan bli kompromittert, og de gir derfor ikke samme tillit. En potensiell angriper vil bl.a. trenge spesialutstyr for å «bryte seg inn» i et smartkort.
Enkelte programmer for signering/kryptering gir tilgang til nøkler lagret i en PC slik at de er «åpent» tilgjengelige over en gitt tidsperiode, som kan bli lang. Brukeren kan selv bestemme varigheten, men dette åpner for økt sårbarhet.
For å underbygge underskriftens varslingsfunksjon er det viktig å gjøre det å signere digitalt til en eksplisitt handling. I praksis kan dette innebære at man må taste en PIN-kode eller et passord hver gang man skal signere. På grunn av dette, og av sikkerhetsmessige grunner, bør brukeren som har private nøkler lagret i en PC, eller på et smartkort som står i en leser, taste sin PIN-kode eller sitt passord hver gang hun signerer et dokument, autentiserer seg overfor et system eller dekrypterer et mottatt, kryptert dokument.
I hht. lov om elektronisk signatur [ 52] kreves det sikre signaturframstillingssystemer for å kunne framstille kvalifiserte signaturer. På oppdrag fra EESSI (jf. punkt 5.1.1) utarbeider CEN for tiden krav til sikre signaturframstillingssystemer. Det er alminnelig antatt at slike systemer minimum innebærer bruk av smartkort. Situasjonen på dette området er imidlertid uavklart, og det nasjonale arbeidet med forskrifter til loven vil måtte avvente resultater fra EU-prosesser før kravene i den norske loven kan presiseres.
Hvordan sertifikater trekkes tilbake
Tilbaketrekking (sperring) av sertifikater tilsvarer «svartelisting » av betalingskort som er blitt mistet eller stjålet. Et sperret sertifikat indikerer at en ikke kan stole på signaturen som ble laget med dette sertifikatet etter tilbaketrekkingstidspunktet.
Et sertifikat kan trekkes tilbake av mange grunner, noen av dem så uskyldige som at man har endret navn og derfor må få et nytt sertifikat med det nye navnet. Sertifikater som har nådd utløpet av sin gyldighetsperiode, vil også bli trukket tilbake og nye bli utstedt. Sertifikater må straks trekkes tilbake når det er mistanke om at den tilhørende private nøkkelen er kompromittert eller tapt.
Det er sertifikateierens ansvar å varsle utstederen om tap/kompromittering av nøkler eller om endringer i personlige opplysninger som vil påvirke innholdet i sertifikatet.
Det er utstederens ansvar å sperre sertifikatet. Dette gjøres ved å utstede såkalte tilbaketrekkingslister, som er tidsstemplet og signert av sertifikatutstederen. Hvor ofte slike lister utstedes, er svært viktig for tilliten til den digitale signaturen. Utstedes listene en gang om dagen, er tilliten en annen enn om de utstedes hver halvtime.
Prosedyrer for tilbaketrekking har derfor stor betydning for hvor sikre sertifikater og signaturer er. Dersom man ikke har gode tilbaketrekkingsrutiner, blir misbruk av en digital signatur mye vanskeligere å oppdage enn misbruk av en tilsvarende papirbasert signatur.
8.2.3 Andre momenter som påvirker tillit til en sertifikatpolicy
En sertifikatutsteder skal beskrive i et eget dokument hvordan en gitt sertifikatpolicy følges hos ham. Dette dokumentet kalles sertifikatpraksis 8. For at en bruker av sertifikatutstederens tjenester skal ha mulighet til å vurdere om utstederen virkelig følger sertifikatpolicyen, må det gjennomføres en sikkerhetsevaluering av utsteders virksomhet med tanke på om rutiner og tiltak beskrevet i sertifikatpraksis virkelig følges.
En slik evaluering kan gjennomføres av et IT-revisjonsselskap, som også kan være akkreditert for evalueringer etter BS 7799. BS 7799 er en standard for evaluering av sikkerhet i organisasjoner. Den brukes i flere land og er nå også i bruk i Norge. Standarden regnes som fleksibel, men noe uklar. Den kan derfor ikke brukes alene for evaluering av en sertifikatpraksis, men kan være et godt hjelpemiddel.
Det foreligger pr. i dag ingen lovfestede krav til de IT-revisjonsfirmaene som kan gjennomføre revisjon av en sertifikatutsteder. Lov om elektronisk signatur, § 17, fjerde ledd, gir tilsynet anledning til å kreve slik revisjon av utstedere. Det er ikke et krav at revisorer skal ha akkreditering for BS 7799.
Sertifikatpolicyer er ofte tungt tilgjengelige dokumenter som i liten grad er forståelige for brukerne. De kan heller ikke tolkes automatisk av datamaskiner. Dette påvirker brukernes praktiske muligheter til å vurdere hva slags tillit de kan ha til en sertifikatutsteder.
En utsteder av kvalifiserte sertifikater vil måtte dokumentere at han i sin sertifikatpolicy oppfyller visse standardiserte krav, og hans virksomhet vil være underlagt tilsyn. Dette kan gjøre det lettere å forholde seg til tillitsspørsmålet.
Sjekking av sertifikatpolicyer er ikke særegent for forvaltningen. Det vil være utfordrende i alle tilfeller der man ikke har avtaler med sertifikatutsteder. Det kan f.eks. tenkes en instruks for postmottaket om å sjekke sertifikatpolicyer ved manuelt mottak av visse typer e-post som kan utløse saksbehandling, og der det følger med et sertifikat fra en ukjent utsteder. Dette kan f.eks. gjøres mot en separat samtrafikktjeneste, jf. punkt 10.10.7.
8.2.4 Behov for sertifikatpolicy
Trenger forvaltningen egne sertifikatpolicyer? Trenger man én eller flere policyer? Disse spørsmålene kan besvares på flere plan.
For hver elektroniske tjeneste eller annen IT-anvendelse i forvaltningen er det nødvendig å bestemme krav til sikkerhet. Disse kravene vil være forankret i regelverket som ligger til grunn for tjenesten/anvendelsen. Dersom man skal ta i bruk digitale signaturer og PKI som sikkerhetsløsning, må kravene omsettes i en beslutning om hvilket sikkerhetsnivå med tilhørende sertifikatpolicy som skal legges til grunn.
Sikkerhetsbestemmelsene gitt i medhold av personopplysningsloven pålegger den behandlingsansvarlige å iverksette sikkerhetstiltak i forhold til den risikoen behandlingen medfører. Kravet til forholdsmessighet medfører at valg av sikkerhetsnivå og -tiltak må baseres på risikovurdering utført for den enkelte konkrete behandling. Bildet kompliseres ved at personopplysninger skal sikres ut fra forskjellige, ofte avvikende hensyn: konfidensialitet, integritet eller tilgjengelighet. Eksempelvis vil en for sterk konfidensialitetssikring kunne forårsake utilstrekkelig tilgang til opplysningene og dermed medføre et sikkerhetsproblem.
Dette innebærer at evaluering og valg av sikkerhetsnivå må baseres på en forutgående vurdering av risiko knyttet til den enkelte behandling. Slike risikoanalyser bør ta med vurderinger om hvorvidt systemer som har akseptabelt risikonivå for systemeier, gir for høy risiko for den enkelte private bruker.
Hver enkelt etats vurderinger vil kunne føre til at det utvikles mange, nesten like sertifikatpolicyer for ulike anvendelser i forvaltningen. Utvikling av sertifikatpolicyer krever kompetanse og innsikt i PKI-området, noe som ikke vil være tilgjengelig i like stor grad for alle virksomheter. Det er derfor naturlig å vurdere noen felles tiltak som kan lette arbeidet i hver enkelt virksomhet. Ett slikt tiltak er felles rammeavtaler .
Eksisterende tilbud av digital signatur-produkter og -tjenester i forbindelse med Forvaltningsnettsamarbeidets rammeavtaler baserer seg på én sertifikatpolicy med høyt sikkerhetsnivå (FSP-1). Denne policyen dekker hovedsakelig forvaltningsinterne forhold og tar ikke hensyn til kommunikasjon med forvaltningens brukere, f.eks. enkeltpersoner.
Ut fra spennvidden i forvaltningens behov ser utvalget det som hensiktsmessig at det defineres flere felles sikkerhetsnivåer med tilhørende felles sertifikatpolicyer. Slike nivåer kan danne en referanseramme for valg av sikkerhetsnivå for tjenester og anvendelser i forvaltningen og mot forvaltningens brukere.
Felles løsninger på en del områder vil kunne lette innføring av bruk av digitale signaturer og forenkle enkeltpersoners og næringslivets elektroniske kommunikasjon med forvaltningen som helhet.
Utgangspunktet for valg av policy er eksisterende policy hos leverandørene, Forvaltningsnettsamarbeidets sertifikatpolicy FSP-1, som i praksis fungerer som offentlig anbefalt sertifikatpolicy i dag, og de standard sertifikatpolicyer som er utarbeidet av ETSI ( Policy requirements for certification authorities issuing qualified certificates, ETSI TS 101 456) [ 23].
ETSI-standarden kan få betydning for implementeringen av direktivet 1999/93/EC når det gjelder hva som skal legges til grunn for utstedere av kvalifiserte sertifikater. Det vil trolig være naturlig at denne standarden vil danne en mal for de nasjonale tilsynsmyndigheter når det gjelder evaluering av sertifikatpolicy og derigjennom sikkerheten, hos utstedere av kvalifiserte sertifikater.
ETSI-standarden definerer faktisk to sertifikatpolicyer – begge for utstedere av kvalifiserte sertifikater «til offentligheten», et begrep som vil fortolkes ulikt i nasjonale lovgivninger på området. I henhold til norsk lov om elektronisk signatur vil dette gjelde alle utstedere av kvalifiserte sertifikater. De to sertifikatpolicyene som defineres, er identiske i innhold på de fleste punkter, men skiller seg fra hverandre på området krav til sikkert signaturframstillingssystem , og på måten private nøkler skal beskyttes på. Den ene av policyene stipulerer et sikkert signaturframstillingssystem (som pr. i dag stort sett vil bety smartkort), den andre gjør det ikke.
I tillegg til at ETSI-standarden definerer de to konkrete sertifikatpolicyene, åpner man for at enkelte sertifikatutstedere skal kunne utarbeide egne, mer detaljerte policyer på grunnlag av den ene av de to standardpolicyene. På denne måten fungerer standarden som en «rammepolicy» , som kan fylles ut med mer detaljert innhold og tilpasses lokale forhold. En slik ny policy vil måtte registreres og identifiseres separat fra ETSI-policyer.
ETSI's sertifikatpolicy har ikke brukt Internettstandarden RFC 2527 som mal for struktur og disposisjon for policydokumentet. Den inneholder likevel en tabell som sammenholder de ulike avsnittene og kapitlene til strukturen iht. RFC 2527.
FSP-1, utarbeidet med utgangspunkt i den svenske SEIS S10-standarden [ 68], baserer seg på RFC 2527. Innholdsmessig tilsvarer FSP-1 ETSI's policy med sikkert signaturframstillingssystem, selv om FSP-1 er mer detaljert og således representerer en videreutvikling i forhold til ETSI-policy.
8.2.5 Anbefaling om antall sikkerhetsnivåer og tilhørende policyer
Én sertifikatpolicy med høy sikkerhet, som kan dekke de fleste behov, vil kunne forenkle implementeringen av PKI både i forvaltningens interne samhandling og enkeltpersoners elektroniske kontakt med forvaltningen.
Utvalget ser likevel behov for minst ett nivå til, med noe lavere sikkerhet. Grunnen er at løsninger for digitale signaturer og PKI, som kan tilsvare høyt sikkerhetsnivå, ikke er bredt tilgjengelig i markedet ennå. I tillegg vil implementering av sterke sikkerhetsløsninger for elektroniske tjenester som ikke nødvendigvis behøver slike, kunne medføre unødige kostnader og eventuelle forsinkelser ved innføring av tjenestene.
Utvalget anbefaler to nivåer med høye krav til sikkerhet og ett nivå uten spesielle krav til sikkerhet. Nivåene er rangert slik at nivå 3 gir høyest sikkerhet og nivå 1 lavest sikkerhet. Nivå 3 krever sikkert signaturframstillingssystem , mens nivå 2 aksepterer annen lagring av private nøkler. Utvalget mener at digitale signaturer på nivå 3 vil tilfredsstille de kravene til kvalifisert elektronisk signatur som framgår av lov om elektronisk signatur.
Nivå 3
Felles sertifikatpolicy for dette nivået anbefales å være FSP-1 med visse modifikasjoner. Modifikasjonene bør omfatte tilpasning av FSP-1 til strukturen på ETSI’s standard sertifikatpolicy med sikkert signaturframstillingssystem. Videre bør FSP-1 modifiseres for å tilpasses de nye anbefalte sertifikatprofilene for forvaltningen (jf. vedlegg 2).
Noen viktige momenter i policyen vil være:
Tre separate nøkkelpar for henholdsvis signering, kryptering og autentisering,
RSA kryptosystem med 1024 bits nøkler, eller annet asymmetrisk kryptosystem med tilsvarende eller bedre sikkerhet,
SHA-1 hash-algoritme, eller annet hash-system med tilsvarende eller bedre sikkerhet,
3DES eller AES med 128 bits nøkler, eller annet symmetrisk kryptosystem med tilsvarende eller bedre sikkerhet,
Private nøkler lagres på smartkort eller annet utstyr som vil oppfylle kravene til sikkert signaturframstillingssystem iht. lov om elektronisk signatur med forskrifter. Utvalget forutsetter at disse kravene blant annet vil innebære at:
Signaturframstillingssystemet beskytter de private nøklene slik at de ikke kan forlate systemet, bli slettet eller overskrevet,
Tilgang til private nøkler er beskyttet med PIN-kode eller passord med tilstrekkelig styrke,
Signaturframstillingssystemet er evaluert til et tillitsnivå som minimum tilsvarer EAL 4 etter Common Criteria 9 [ 43],
Systemer med automatisk tilgang til private nøkler for virksomheter må sikres mot uautorisert tilgang til nøklene med mekanismer evaluert til et tillitsnivå som minimum tilsvarer EAL 4 etter Common Criteria,
Ved identifisering av sertifikateier skal utsteder sjekke medbrakt legitimasjon mot folkeregisteret. Virksomhetssertifikater krever en tilsvarende mekanisme,
Identifisering av sertifikateier (for offentlige personsertifikater) ved hjelp av en identifikator som er unik innen utsteders domene, ev. fødselsnummer,
Personlig frammøte minst én gang i forbindelse med utstedelse av sertifikat,
Tilbaketrekkingstjeneste tilgjengelig 24 timer i døgnet, 7 dager i uken.
Nivå 2
Her stilles samme krav som til sertifikater på høyeste nivå, bortsett fra at private nøkler ikke behøver å beskyttes ved hjelp av et sikkert signaturframstillingssystem. I praksis kan dette bety at nøklene kan lagres kryptert i PC-en, på en server eller på en diskett. Felles sertifikatpolicy på dette nivået anbefales å være FSP-1 tilpasset ETSI's standard sertifikatpolicy uten krav til sikkert signaturframstillingssystem, og modifisert som omtalt ovenfor.
Nivå 1
Dette nivået er definert av rent praktiske grunner og omfatter alle andre typer sertifikater enn de definert på nivå 3 og 2 (for eksempel sertifikater utstedt av den internasjonalt kjente tjenesten VeriSign ). Likeledes kan andre former for elektroniske signaturer, som PIN-koder, grupperes her. På dette nivået er det ikke hensiktsmessig å kreve bestemte sertifikatpolicyer.
8.3 Obligatorisk eller anbefalt policy
Dersom det er ønskelig å legge til rette på en enkel måte for en PKI for forvaltningen med gjennomgående høy sikkerhet, kan det være hensiktsmessig å pålegge forvaltningsvirksomheter å anskaffe PKI-løsninger med et bestemt høyt sikkerhetsnivå. Slike løsninger kan være tilgjengelige via en rammeavtale som virksomhetene vil være pålagt å bruke. Denne typen sentralt grep vil kunne forhindre at enkelte forvaltningsvirksomheter går utenom rammeavtalen og på egen hånd anskaffer løsninger i markedet med svakere sikkerhet enn den som tilbys i rammeavtalen. Slik tilnærming har imidlertid flere ulemper enn fordeler.
Hvis det sikkerhetsnivået og den sertifikatpolicyen som er knyttet til rammeavtalen, ikke er dekkende for behovet, enten fordi det er for høyt eller for lavt, vil obligatoriske løsninger både ramme virksomhetens handlefrihet med henblikk på å løse oppgavene på en mest effektiv måte og generere unødige kostnader for virksomheten isolert.
Obligatoriske løsninger vil stå i motstrid til virksomhetens plikt og rett til å vurdere behovet for sikkerhet i dennes elektroniske samhandling med andre på grunnlag av egne behov og det regelverket som ligger til grunn for virksomheten, for så å velge en optimal løsning.
På den andre siden er PKI en infrastruktur, som skal tilby de samhandlende partene tjenester til felles bruk. Dersom de samhandlende partene velger ulike sikkerhetsnivåer på hver sin side, vil samhandlingen ikke være sikrere enn tilsvarende det laveste av de aktuelle sikkerhetsnivåene.
Utvalget ser det derfor som hensiktsmessig at det finnes anbefalte sikkerhetsnivåer og tilhørende sertifikatpolicyer. Utvalget ser ingen tungtveiende grunner til å gjøre de foreslåtte felles sikkerhetsnivåene og sertifikatpolicyene obligatoriske for forvaltningen. Utvalget mener at det kan være hensiktsmessig å kreve at de felles anbefalte nivåene vurderes først, før eventuelt andre løsninger velges.
Utvalget mener at de felles anbefalte sertifikatpolicyene vil kunne tas i bruk, på frivillig basis, av forvaltningen slik de er. Utvalget mener at disse sertifikatpolicyene, om ønskelig, også vil kunne fungere som rammepolicyer og benyttes som grunnlag for utvikling av spesifikke, og mer detaljerte, policyer for konkrete anvendelser i konkrete virksomheter.
8.4 Forvaltningsnettsamarbeidets sertifikatpolicy FSP-1
FSP-1 ble utarbeidet i 1999 av Forvaltningsnettsamarbeidet , i forbindelse med rammeavtale om digitale signaturer med tilhørende tjenester. FSP-1 er en høysikkerhetspolicy som høyst sannsynlig oppfyller kravene til kvalifiserte signaturer slik kravene framgår av lov om elektronisk signatur. FSP-1 har godt omdømme både hos sertifikatutstedere og hos forvaltningen. FSP-1 har i praksis fungert som en anbefalt standard for forvaltningen.
Utvalget mener at FSP-1 er et godt utgangspunkt for en ny, anbefalt standard for sertifikatpolicy for forvaltningen. Den nye standarden bør være de to sertifikatpolicyene for henholdsvis sikkerhetsnivå 3 og sikkerhetsnivå 2 som omtales i punkt 8.2.5.
8.5 Oppsummering av anbefalingene
Utvalget anbefaler at det for anvendelse av digitale signaturer og PKI i forvaltningen, og i kommunikasjon med forvaltningens brukere, defineres tre felles sikkerhetsnivåer.
Det høyeste nivået, nivå 3, skal basere seg på en sertifikatpolicy som tar utgangspunk i Forvaltningsnettsamarbeidets sertifikatpolicy FSP-1 og tilsvarer den nylig vedtatte europeiske standarden fra ETSI for sertifikatpolicy for utstedelse av kvalifiserte sertifikater med sikkert signaturframstillingssystem.
Mellomnivået, nivå 2, skal tilsvare nivå 3 i sikkerhet, bortsett fra at det på dette nivået ikke skal kreves sikre signaturframstillingssystemer, iht. lov om elektronisk signatur. Dette nivået skal også ha en tilhørende sertifikatpolicy som skal ta utgangspunkt i FSP-1 og den europeiske ETSI-standarden, uten sikre signaturframstillingssystemer.
Laveste nivå, nivå 1, omfatter alle andre sertifikater med sikkerhet lavere enn nivå 3 og 2. Andre typer sikkerhetsløsninger for autentisering, som PIN-koder eller passord, kan klassifiseres på dette nivået.
Utvalget anbefaler ikke at felles sikkerhetsnivåer og tilhørende sertifikatpolicyer gjøres til obligatoriske standarder for forvaltningen.
Utvalget mener at det bør vurderes om forvaltningen kan pålegges å ta stilling til fellesløsninger for PKI før andre løsninger kan velges.
Utvalget mener at Forvaltningsnettsamarbeidets sertifikatpolicy FSP-1 er et godt utgangspunkt for en ny anbefalt standard for forvaltningen. Den nye standarden bør være de to sertifikatpolicyene som utvalget anbefaler utviklet for sikkerhetsnivå 3 og sikkerhetsnivå 2 på grunnlag av ETSI-standarden TS 101 456.
9 Forvaltningens strategi for bruk av sertifikattjenester
Hensikten med dette kapitlet er å foreta en overordnet vurdering av hvordan forvaltningen skal kunne skaffe seg nødvendig infrastruktur for bruk av digitale signaturer, og å anbefale en strategi framover.
9.1 Rammebetingelser for leveranse av sertifikattjenester til forvaltningens formål
9.1.1 Lover og regelverk
I § 5 i lov om elektronisk signatur slås det fast at Kongen kan fastsette nærmere regler om hvilke krav som skal stilles til kvalifiserte elektroniske signaturer som skal brukes ved kommunikasjon med og i offentlig sektor.
Nærings- og handelsdepartementet utarbeider i samarbeid med Post- og teletilsynet forskrifter til loven. Det ligger an til at leverandører av kvalifiserte sertifikater skal kunne avkreves opplysninger om hvilken sertifikatpolicy og sertifikatpraksis som benyttes ved utstedelse av kvalifiserte sertifikater. Når forskriften er på plass, vil det være grunnlag for å vurdere hvorvidt det er nødvendig med tilleggskrav i offentlig sektor utover det som loven med forskrifter regulerer.
Enkelte offentlige aktører vurderer å stille krav om sikkerhetssertifisering av sertifikatutstedere som skal utstede sertifikater til visse anvendelser. En slik sertifiseringsordning, basert på den britiske standarden BS 7799, er under etablering i Norge. Hvorvidt dette er nødvendig, vil kunne vurderes når leverandørenes sertifikatpolicyer for levering av kvalifiserte sertifikater blir tilgjengelige.
9.1.2 Status blant aktuelle leverandører
Flere av leverandørene av sertifikattjenester har antydet at de vil utstede sertifikater med et innhold som tilsvarer kvalifiserte sertifikater. Det er fremdeles uklart hvor raskt migrasjonen til kvalifiserte sertifikater vil skje. Både tidsplanene og aktørenes vilje til å registrere seg som utsteder av kvalifiserte sertifikater, vil være avhengige av myndighetenes politikk. Det synes som om aktørene avventer forskriften til loven før de fatter beslutninger på området.
Leverandører kan ønske å utstede sertifikater som ikke hører med til kategorien kvalifiserte. Slike sertifikater kan være like sikre eller sikrere enn kvalifiserte sertifikater, men i forhold til lov om elektronisk signatur vil de falle under bestemmelser i § 6 annet ledd, som sier at en elektronisk signatur ikke kan nektes rettsvirkning på grunnlag av at den er elektronisk.
9.2 Leveranse av sertifikater til forvaltningen
9.2.1 Hvor sikre sertifikater skal forvaltningen benytte?
Utvalget har ikke grunnlag for å anbefale hvilket sikkerhetsnivå for sertifikattjenester som bør benyttes for hvilke anvendelser i forvaltningen. Denne vurderingen må foretas av hver offentlig virksomhet individuelt i forbindelse med anskaffelse av PKI-løsninger. Se ellers kapittel 4, som peker på noen grunnleggende anvendelser med behov for digitale signaturer i forvaltningen.
Likevel vil utvalget mene at sertifikater som planlegges brukt av forvaltningen, i hovedsak bør befinne seg på sikkerhetsnivå 3 (jf. kapittel 8) med tilsvarende sertifikatpolicy. Utvalget vil imidlertid ikke anbefale at sertifikater på nivå 2 skal utelukkes. Offentlige virksomheter bør kunne velge sertifikater på nivå 2 der behovet i forhold til en konkret anvendelse tilsier det. Samtidig bør virksomhetene, ut fra et kost-/nytteperspektiv, kunne vurdere om det er hensiktsmessig å investere i PKI-løsninger basert på sikkerhetsnivå 2 hvis man så skal gå over til løsninger på nivå 3, eller der man likevel har behov for løsninger på nivå 3 på visse områder, mens det på andre områder bare er behov for løsninger på nivå 2. Det er kostbart å etablere en infrastruktur flere ganger eller å operere med doble ordninger.
9.2.2 Modeller for leveranse av sertifikater til forvaltningen
Det finnes tre grunnleggende modeller for leveranse av sertifikattjenester til forvaltningen:
En sentral sertifikattjeneste etableres i forvaltningen,
Hver enkelt offentlig virksomhet (med behov for det) etablerer en slik tjeneste som en del av sine interne IT-funksjoner,
Tjenesten kjøpes i markedet, enten direkte, eller via rammeavtaler.
Disse modellene er ikke ekskluderende i forhold til hverandre og kan tenkes brukt i kombinasjon. Mer konkret kan følgende modeller overveies:
Hver enkelt etat kan kjøpe sertifikater fra en aktør i markedet etter anbudskonkurranse. Leverandøren forestår både registreringsfunksjonen og sertifikatutstedelsen. Alternativt kan etaten selv forestå registreringsfunksjonen. Denne modellen kan være egnet for store etater som har tilstrekkelig kompetanse og tyngde til å gjennomføre nødvendige anbudsprosesser. Etater med geografisk distribuerte enheter vil ha en tilleggsutfordring når det gjelder etablering av en effektiv registreringsfunksjon. Der må leverandøren enten sørge for en geografisk distribuert registreringsfunksjon eller etaten må selv finne interne løsninger for dette.
Hver enkelt etat kan kjøpe sertifikater gjennom Forvaltningsnettsamarbeidets rammeavtale. Dagens rammeavtale legger opp til at hver enkelt offentlig virksomhet som kjøper tjenesten, skal forestå registreringsfunksjonen selv. Det er også lagt opp til en mulighet der en tredjepart kan forestå registreringstjenesten for flere virksomheter, etter avtale med én eller flere sertifikatutstedere. Her bør det vurderes om denne ordningen bør suppleres med en mulighet der leverandørene selv forestår registreringsfunksjonen, ev. også geografisk distribuert.
Offentlige etater etablerer sine egne sertifikatutstedelsestjenester. Dette er en modell som er aktuell for noen store statlige etater, ev. store kommuner med mange etater. Egen sertifikattjeneste kan etableres enten ved å anskaffe nødvendig utstyr og programvare og sette opp hele tjenesten selv, eller ved å kjøpe tjenesten i sin helhet i markedet, som en underleveranse til etatens sertifikattjeneste. En slik anskaffelse kan enten skje via utlysning eller kjøp ifølge rammeavtaler, gitt at Forvaltningsnettsamarbeidet tilbyr slike løsninger i tilknytning til sine avtaler.
Det etableres en sentral sertifikatutsteder for hele forvaltningen. Alternativt kan det etableres flere sentrale utstedere, f.eks. en for departementene, en for alle kommuner og en for statsforvaltningen for øvrig. Slike utstedere vil bli drevet i offentlig regi og vil mest sannsynlig være brukerfinansierte tjenester. Etablering av løsningene vil kunne skje som beskrevet for foregående modell, der etater selv etablerer slike tjenester. Man må likevel merke seg at sertifikatutstedelse er en tjeneste som i grunnen ikke trenger å være distribuert i det hele tatt. Det som er viktig, er å ha en rimelig distribuert løsning for registreringstjenester. Slik sett vil mest sannsynlig en variant av denne modellen være en sentral utsteder som har avtaler med flere enheter som kan forestå registrering av sertifikateiere. Slike enheter bør være geografisk (regionalt) distribuert for å kunne dekke hele forvaltningen. Det er nærliggende å tro at det vil være regionale offentlige virksomheter som kan ta på seg slike roller (f.eks. Fylkesmannsembeter eller administrasjonene i fylkeskommunene).
Man må ta stilling til om en slik offentlig sertifikatutsteder skal ha monopol på å utstede sertifikater til forvaltningen, eller om dette skal skje i konkurranse med andre aktører i markedet, slik det f.eks. legges opp til i Finland .
Fordeler med modeller som forutsetter anskaffelse av sertifikattjenester i markedet, er:
Fleksibilitet med tanke på valg av løsning og skifte av leverandør,
Mindre investeringskostnader for forvaltningen,
Bedre mulighet for å følge den teknologiske utviklingen og mulighet for valg av de til enhver tid mest optimale løsninger,
Gjennom konkurranse mellom aktører i markedet som utsteder sertifikater, stimuleres utviklingen av markedet for sertifikattjenester.
Ulempene med disse modellene er:
Begrenset offentlig kontroll over en vital infrastruktur, hvis den f.eks. ikke fungerer etter forutsetningene,
Problemer med samtrafikk og teknisk samvirke mellom løsninger fra ulike leverandører,
Potensielt høye driftskostnader dersom leverandørtilfanget blir begrenset,
Mangel på nødvendig kompetanse for å ta løsningene i bruk.
Fordeler med en modell der forvaltningen selv driver sertifikatutstedelse for egne ansatte kan være:
Bedre kontroll med sikkerhet og kvalitet i infrastrukturen,
Mer homogen infrastruktur, lettere å eliminere samtrafikkproblemer og problemer med teknisk samvirke,
Bedre og rimeligere integrasjon av forvaltningens systemer med digitale signaturer (færre konsepter å ta hensyn til),
Egen kompetanse i forvaltningen, mindre avhengighet av leverandørene.
Ulempene kan være:
Høye investeringskostnader, potensielt høye driftskostnader, usikker inntjening av utgifter,
Mindre fleksible løsninger. Det kan bli vanskeligere å tilpasse seg den teknologiske utviklingen på området,
Modellen kan forstyrre markedsutviklingen, ved at det offentlige kan komme til å konkurrere med utstedere i markedet,
Dersom det blir en monopoltjeneste, vil kvaliteten kunne synke over tid.
Utvalgets drøfting av ulike modeller har avdekket at etablering av en sentral offentlig utsteder av sertifikater er en lite aktuell løsning. Hensynet til markedsutvikling og hensynet til kontroll med offentlige utgifter må veie tungt når man skal vurdere valg av løsning for forvaltningen. Utvalget anser det som lite aktuelt å anbefale en modell der det offentlige skal pådra seg større utgifter, samtidig som man vil kunne forstyrre konkurransen i markedet for sertifikattjenester.
Ved diskusjon av modeller der markedet skal kunne utnyttes til anskaffelse av løsninger, la flere vekt på at det kan være hensiktsmessig å samordne krav og rammebetingelser for slike anskaffelser. Krav kan samordnes dersom man etablerer en sentral samordningsfunksjon (jf. punkt 9.6) for digitale signaturer i forvaltningen, men det kan være en tung oppgave, særlig for mindre virksomheter, selv å gjennomføre anskaffelsesprosessen. Man bør derfor kunne utnytte de felles innkjøpsordningene som finnes i forvaltningen, i dette tilfellet innkjøpsordningen under Forvaltningsnettsamarbeidet, som allerede har etablerte rammeavtaler for digitale signaturer og TTP-tjenester. Bruken av Forvaltningsnettsamarbeidets avtaler er frivillig.
Når det gjelder hva slags løsninger som bør omfattes av en slik rammeavtale, mener utvalget at det bør åpnes for at enkelte store etater eller større kommuner selv skal kunne forestå utstedelse av sertifikater til egne ansatte. Dette fordrer at innholdet i rammeavtalen bør utvides med produkter og/eller tjenester som gjør det mulig.
9.2.3 Hvordan skal forvaltningen anskaffe sertifikater til egne formål?
Utvalget mener at for forvaltningens interne formål, dvs. utstedelse av sertifikater til offentlige virksomheter og deres ansatte, vil det være hensiktsmessig å videreføre ordningen med rammeavtaler under Forvaltningsnettsamarbeidet. Rammeavtaleinnholdet bør utvides slik at det kan omfatte:
Sertifikattjenester (som i dag),
Produkter for digitale signaturer og kryptering (som i dag),
Smartkort og lesere (som i dag),
Produkter for sertifikatutstedelse og produkter som støtter sertifikatkataloger (ny),
Outsourcing av sertifikattjenester (ny).
Rammeavtalen bør baseres på krav utarbeidet av en samordningsfunksjon (jf. punkt 9.6) med utgangspunkt i utvalgets anbefalinger om sikkerhetsnivåer, sertifikatprofiler, unik identifisering og sertifikatpolicy. Til avtalen bør det være tilgjengelige tjenester og produkter som tilfredsstiller både sikkerhetsnivå 3 og 2. Videre bør det juridiske rammeverket for avtalen ta hensyn til nyreguleringen på området (lov om elektronisk signatur med forskrift, kommende endringer i forvaltningsloven og ev. en ny forskrift om elektronisk kommunikasjon med og i forvaltningen).
Bruken av rammeavtalen bør være frivillig, men samtidig bør det være en anbefalt løsning for anskaffelse av sertifikater til forvaltningen. Dersom en offentlig virksomhet skulle velge å gjennomføre en anskaffelsesprosess uten å benytte Forvaltningsnettsamarbeidets innkjøpsordning, anbefaler utvalget at basiskrav og betingelser som legges til grunn for en slik anskaffelse, er de samme som for rammeavtalen.
Når det gjelder spørsmålet om samtrafikk mellom leverandører som skal tilby løsninger til forvaltningen under rammeavtalen, foreslår utvalget at dette løses utenom selve rammeavtalene, og at det vil være en av samordningsfunksjonens oppgaver å finne gode løsninger for dette i samarbeid med leverandørene. Se for øvrig kapittel 10.
9.3 Leveranse av sertifikater til enkeltpersoner
9.3.1 Privatpersoners kommunikasjon med forvaltningen
Privatpersoner ønsker sannsynligvis å benytte færrest mulig sertifikater i sin kommunikasjon mot forvaltningen. Fordelen med PKI er nettopp muligheten til å kunne tilby autentiseringsløsninger som er universelle for flere anvendelser, slik at befolkningen ikke skal behøve å forholde seg til mange PIN-koder, passord og andre elektroniske identifikasjonskoder for hver enkelt tjeneste de skal kunne bruke på Internett. Det kan likevel tenkes at enkeltpersoner kan ende opp med en løsning der privatpersoner vil ha flere nøkkelpar og sertifikater for kommunikasjon med offentlig sektor. Slike løsninger må da tilrettelegges slik at sertifikateieren er klar over hvilket sertifikat og hvilken privatnøkkel som benyttes mot hvilken tjeneste.
Når man tar i bruk PKI og digitale signaturer for tilgang til forvaltningens elektroniske tjenester, kan forvaltningen legge til rette for at ett og samme sertifikat kan benyttes mot flere offentlige tjenester. Det kan også tenkes at hver sektor eller virksomhet krever separate sertifikater for sine formål. Hva disse svært ulike strategiene innebærer for enkeltpersoner, kan vurderes ut fra to perspektiver: forbrukerperspektiv og personvernperspektiv. Ut fra det første vil ønsket om å ha færrest mulig sertifikater å forholde seg til være dominerende. Ut fra det andre perspektivet kan ønsket om å benytte flere ulike sertifikater være aktuelt for personer som ikke nærer slik tillit til forvaltningen at de vil benytte samme identifikasjonsmekanisme mot flere offentlige virksomheter. Det er i denne sammenhengen verdt å merke seg at i dagens løsninger for tilgang til elektroniske tjenester på nettet benyttes fødselsnummer kombinert med en PIN-kode. Dette gir vesentlig dårligere personvern enn bruk av et sertifikat hvor fødselsnummeret ikke inngår.
Valget mellom disse hensynene bør foretas av brukeren selv, men for at valget skal være reelt, må det være noe å «velge imellom». Dette i seg selv tilsier at forvaltningen ikke bør ta et hardt grep og forlange at ett sertifikat skal brukes mot alle offentlige tjenester som tilbys elektronisk.
Samtidig vil mange sertifikateiere se det som en fordel om det sertifikatet som de bruker mot offentlige tjenester, også kan brukes i andre sammenhenger, f.eks. mot banktjenester eller andre private tjenester på Internett. Det skaper utfordringer for forvaltningen dersom man skal velge sektorløsninger framfor felles løsninger. Valg av sektorløsninger kan innebære at de private aktørene (f.eks. bankene) vil måtte tilpasse mange ulike offentlige sertifikater til bruk mot sine egne tjenester, dersom slike ønsker fra enkeltpersoner skal oppfylles.
Utvalget ser det ikke som hensiktsmessig å anbefale ett sikkerhetsnivå for offentlige personsertifikater. Valg av sikkerhetsnivå vil i sterk grad avhenge av behovene de enkelte sektorene eller virksomhetene har og som de konkrete anvendelsene vil ha når det gjelder elektronisk identifisering, signering og kryptering. Videre vil valget avhenge av hva slags modell for leveranse av sertifikater til enkeltpersoner som blir lagt til grunn, og hva markedet har å tilby av løsninger.
Ut fra behovet for et rimelig godt sikkerhetsnivå og ut fra de anbefalingene som utvalget gir når det gjelder typer sertifikater og profiler for offentlige personsertifikater, er det naturlig å anbefale at sertifikater som enkeltpersoner skal benytte mot forvaltningens tjenester, bør utstedes med minimum sikkerhetsnivå 2. Dette vil i praksis bety kvalifiserte sertifikater, men uten krav til beskyttelse av nøkler i et smartkort. Når markedsforhold er lagt til rette for det, bør sertifikater på nivå 3 anbefales.
I en startfase, når bruk av digitale signaturer og PKI skal innføres, er det likevel viktig å påpeke at virksomheter som skal ta i bruk slike løsninger, ikke bør stille for strenge krav der sikkerhetsbehovet ikke tilsier det. For enkelte anvendelser vil sertifikater på nivå 1 fungere utmerket.
Sett fra enkeltpersoners perspektiv må man likevel tenke på spørsmålet om hvor mange sertifikater og hvilke sikkerhetsnivåer en privatperson skal kunne håndtere. Best mulig samordning av sikkerhetskravene mellom sektorene og virksomhetene vil kunne gi bedre og enklere løsninger for brukere av offentlige tjenester. Det er lett å tenke seg at en bruker velger feil sertifikat for en anvendelse, og at sikkerheten ved dette sertifikatet ikke er tilstrekkelig for denne anvendelsen. Bruk av sertifikat med «høyest» sikkerhetsnivå vil avverge slike problemer, fordi et slikt sertifikat vil dekke hele spekteret av mulige anvendelser, fra de helt enkle til de som krever høy sikkerhet.
9.3.2 Modeller for leveranse av sertifikater til enkeltpersoner
Det kan finnes ulike modeller for å forsyne enkeltpersoner med sertifikater/digitale signaturer:
Publikum kjøper sertifikater fritt i markedet og må selv finne ut hvilke sertifikater de kan bruke mot offentlig forvaltning. Dette er en modell som gir få fordeler for enkeltpersoner, som får en stor belastning med å finne ut hva de må kjøpe, og hva sertifikatene kan brukes til. Modellen påfører forvaltningen merarbeid, fordi den blir nødt til å yte veiledning til enkeltpersoner i stor skala, samtidig som hver offentlig virksomhet som tilbyr elektroniske tjenester, vil måtte lage tilpasninger av disse mot alle tilbud på sertifikattjenester i markedet som enkeltpersoner kan tenkes å benytte.
Hver sektor eller offentlig virksomhet utsteder sertifikater som skal brukes mot deres tjenester til enkeltpersoner. De etatene som har egne sertifikatutstedelsestjenester, kan tenkes å benytte disse for å utstede offentlige personsertifikater i tillegg til sertifikater til sine egne ansatte. Andre etater vil benytte en underleverandør. Her er det flere muligheter – enten at underleverandøren leverer hele den elektroniske tjenesten, med sertifikatbruk integrert, eller at underleverandøren leverer en sertifikattjeneste som etaten selv integrerer. I det siste tilfellet kan etaten enten selv påta seg sertifikatutstederansvaret, eller underleverandøren gjør det. I denne modellen kan enten etaten eller underleverandøren (om en slik benyttes) forestå registreringstjenesten for enkeltpersoner.
Offentlige virksomheter utleverer sertifikater til sine kunder. Etatene kjøper sertifikatene via en sentral rammeavtale, f.eks. under Forvaltningsnettsamarbeidet. Sertifikatene vil bli utstedt av en leverandør i tilknytning til avtalen som etatene kan bestille. Denne varianten fordrer at etatene selv etablerer løsninger for registrering av enkeltpersoner og utlevering av sertifikater.
Det etableres en sentral offentlig tjeneste (f.eks. under sentralkontoret for folkeregistrering i Skattedirektoratet) som utsteder offentlige personsertifikater. Dette vil i praksis tilsvare etablering av en ordning med elektroniske ID-kort, selv om man kan tenke seg at en slik sentral tjeneste også kan utstede offentlige personsertifikater som ikke forutsetter beskyttelse av private nøkler i et smartkort (nivå 2-sertifikater). Mange av argumentene for og imot, som for en tilsvarende løsning for ansatte i staten, gjør seg her gjeldende.
Forvaltningen inngår sentrale samarbeidsavtaler med aktører i markedet som allerede har etablert sertifikattjenester med enkeltpersoner som målgruppe. Slike avtaler vil innebære at markedsaktører (leverandører av sertifikattjenester) utsteder offentlige personsertifikater på minimum nivå 2 og utleverer dem til enkeltpersoner gjennom sitt nettverk av registreringsenheter. Sertifikatene skal kunne brukes mot alle offentlige elektroniske tjenester. For offentlige virksomheter vil det kunne være en forenkling bare å måtte tilpasse sine elektroniske tjenester mot én type sertifikater, selv om de leveres av flere leverandører. Videre slipper forvaltningen å etablere egne registreringsordninger for enkeltpersoner.
Sentrale samarbeidsavtaler inngås med markedsaktører som utsteder egne sertifikater til enkeltpersoner, i forbindelse med elektroniske tjenester som de tilbyr selv, f.eks. bank- eller posttjenester. Avtalene vil gjelde bruken av slike sertifikater mot offentlige tjenester. Avtalen vil i praksis innebære at den konkrete markedsaktøren vil bli offentlig godkjent leverandør av sertifikattjenester som enkeltpersoner kan benytte mot forvaltningen. En avtale behøves ikke for å gi godkjenning, men kan likevel trengs for å regulere ev. deling av utgifter mellom det offentlige og leverandøren dersom sertifikater skal kunne brukes uten ekstra kostnader for enkeltpersoner.
Sannsynligvis vil offentlig sektor i Norge uansett bli nødt til å godta elementer av den første modellen, i hvert fall så lenge det leveres kvalifiserte sertifikater og kvalifiserte signaturer. Det er likevel mulig at gjennom forskrifter hjemlet i lov om elektronisk signatur, § 5 og/eller eventuelle nye forskrifter til forvaltningsloven, kan forvaltningen stille tilleggskrav som i praksis ikke vil tillate at et «hvilket som helst» kvalifisert sertifikat vil godtas til bruk mot forvaltningen. Dette kan være krav på teknisk/administrativt nivå som ikke nødvendigvis står i motstrid til eller går utover kravene i lov om elektronisk signatur, men som i praksis kan begrense enkeltpersoners valgfrihet med hensyn til kjøp av (kvalifiserte) sertifikater.
Modellen der hver forvaltningsenhet utsteder egne sertifikater til brukerne, krever en utstrakt kryssertifisering mellom forvaltningsenhetene for ikke å komme opp i en situasjon med stadig behov for registrering av sertifikateieren og utstedelse av nye dedikerte sertifikater. Det må sannsynligvis tillates at en bruker kan få utstedt nytt sertifikat ved å presentere et sertifikat som er utstedt av en annen forvaltningsenhet.
Anbefaling av modell er vanskelig, bl.a. på grunn av mangel på praksis på området (utenom enkelte banker). Det første tilfellet av bruk av sertifikater i forbindelse med en offentlig elektronisk tjeneste vil være Skattedirektoratets planlagte levering av selvangivelser på Internett i 2001, der det legges opp til å kunne bruke Postens EID for sterk autentisering. Her vil leveransen av sertifikater være integrert i den elektroniske tjenesten som skal benyttes for levering av selvangivelsen.
Ut fra hensynet til brukeren og behovet for samordning av autentiseringsløsninger for elektroniske tjenester fra forvaltningen (for å unngå store kostnader forbundet med tilrettelegging for ulike typer sertifikater i hver sektor/virksomhet), kan det være mest hensiktsmessig å konsentrere seg om de modellene som legger opp til en type offentlig personsertifikat som kan brukes mot flere ulike offentlige tjenester. Dette behovet ble sterkt poengtert av deltakere på et seminar om elektroniske signaturer som Statens dataforum arrangerte i november 2000. Et annet viktig element er hensynet til det norske markedet for sertifikattjenester, som er i ferd med å etablere seg. Tunge offentlige løsninger som retter seg mot alle voksne personer i landet, vil kunne ødelegge dette gryende markedet. Etablering av en mulig fellesordning for offentlige personsertifikater i offentlig regi bør derfor sees i sammenheng med behov for et elektronisk ID-kort. Se også kapittel 12.
Det tredje hensynet er behov for et visst garantert sikkerhetsnivå i de løsningene (sertifikatene) som enkeltpersoner vil bruke mot offentlige elektroniske tjenester. Dette behovet må igjen veies opp mot hva markedet kan/vil tilby på kort og lengre sikt, og hvor enkelt det er for enkeltpersoner å ta løsningene i bruk. Krav om sertifikater på nivå 3 er på kort sikt svært vanskelige å imøtekomme, mest av hensyn til manglende standardisering av kortlesere og deres integrasjon i standard PC-utrustning, og pga. kostnader og andre belastninger som dette kan påføre enkeltpersoner.
9.3.3 Hvordan skal enkeltpersoner få sertifikater til bruk mot forvaltningen?
Etter å ha vurdert de ulike hensynene og den markedssituasjonen som eksisterer i Norge pr. i dag, anbefaler utvalget at forvaltningen inngår avtaler med utvalgte markedsaktører om bruk av deres sertifikater for elektronisk samhandling med offentlig sektor. I praksis betyr det valg av modell e) og/eller f) i punkt 9.3.2. Slike avtaler bør forutsette at:
Aktuelle sertifikatutstedere er villige til å tilpasse sine løsninger til kravene fra offentlig sektor (mht. sikkerhetsnivå, sertifikatpolicy og sertifikatprofiler),
De utstederne som det inngås avtale med, skal kunne tilby en løsning for samtrafikk med de sertifikatutstederne som forvaltningen vil benytte for sine interne formål,
Tjenester fra de aktuelle utstedere er enkle å bruke for enkeltpersoner,
Prisen for bruk av tjenestene er akseptabel (det er mest sannsynlig tale om avgift pr. oppslag i sperrelister og sertifikatkataloger),
Kostnader for bruk av sertifikater mot offentlige tjenester bør ikke belastes brukerne (det offentlige bør betale dem) i startfasen; dette må revurderes når løsningene er etablert hos enkeltpersoner og hos forvaltningen,
Det må utarbeides systemer hos sertifikatutstederen som gjør det mulig å avregne påløpte kostnader riktig (ved bruk av sertifikater) og å fakturere riktig offentlig virksomhet; for store offentlige etater eller for konkrete anvendelser der bruksvolumet kan estimeres nokså presist, kan volumprising være aktuelt,
Det bør være inngått avtale med minst to sertifikatutstedere (av konkurransehensyn).
Konkrete markedsaktører kan f.eks. være bankene med BankID, ErgoGroup (tidligere Posten SDS) med Postens EID og Telenor med mobil ZebSign. I forbindelse med avtaler med bankene kan det diskuteres om det offentlige skal inngå avtale med hver enkelt bank som utsteder BankID-sertifikater, eller om det skal inngås avtaler med bankenes interesseorganisasjoner for å favne alle relevante bankinstitusjoner.
Et argument som taler mot rene «markedsmodeller», er at Norge representerer et forholdsvis lite marked når det gjelder digitale signaturer og PKI. Den totale størrelsen på markedet kan gjøre det vanskelig å styre leverandørene i den retning det offentlige ønsker. Enkelte store utenlandske underleverandører vil neppe gjøre store tilpasninger i sin maskin- og programvare for å tilfredsstille den norske forvaltningens særkrav. Samtidig er forvaltningen en såpass stor bruker i forhold til det norske markedet at man burde kunne påvirke aktørene tilstrekkelig for å ivareta offentlige interesser.
9.4 Samhandling med private virksomheter
Når det gjelder leveranse av sertifikater til private virksomheter som ønsker eller skal samhandle elektronisk med forvaltningen, er situasjonen uklar pga. manglende praksis. Et eksempel vi kan se i dag, er skatteetatens SLN-prosjekt . Der skjer innlevering av selvangivelser fra private virksomheter ved bruk av sertifikater med privatnøkler lagret på smartkort. Sertifikatene utstedes av underleverandøren til skatteetaten til revisjons- og regnskapsbyråer og til firmaer. Et annet eksempel vil være Patentstyrets TAKISAI -prosjekt, der sertifikater til patentbyråer skal utstedes av en underleverandør til Patentstyret.
Næringslivet generelt (unntatt finansnæringen og delvis forsikringsbransjen) er kommet forholdsvis kort når det gjelder å ta i bruk sertifikater for egne interne formål. Norsk Hydro og Statoil er i en tidlig fase av etablering av intern PKI, og man kan anta at mindre bedrifter har enda lenger fram. Norsk Hydros representanter har uttalt at de på nåværende tidspunkt ikke kan se at deres interne sertifikater vil kunne benyttes mot offentlig sektor.
Disse betraktningene tyder på at utstedelse av sertifikater til private virksomheter, på kort sikt vil være en «bransjemodell», dvs. at relevante etater sørger for at sertifikatene utstedes til egen bransje (dvs. de private virksomhetene de vil samhandle med). Ved en slik modell vil det være viktig at etatene klarer å samordne sine tekniske og operasjonelle krav til sertifikater og deres bruk i den grad slik samordning er hensiktsmessig og mulig. Denne modellen er nok ikke å anbefale på lengre sikt, fordi den i sin ytterste konsekvens kan føre til at private virksomheter blir pålagt av forvaltningen å få utstedt sertifikater (og også vil måtte installere tekniske løsninger) fra mange ulike leverandører, hvert sertifikat til sitt formål. Spørsmålet må også sees i sammenheng med behovet for samordning av offentlige innrapporteringsordninger. På sikt kan man derfor tenke seg at private virksomheter benytter offentlige personsertifikater som deres ansatte har skaffet seg, samt virksomhetssertifikater og ansattsertifikater (tilsvarende dem for offentlig sektor) som de kjøper i et åpent marked eller utsteder selv med egen underleverandør.
Utvalget vil ikke anbefale noen umiddelbare tiltak når det gjelder sertifikater til næringslivet. Man trenger å vinne flere erfaringer med pågående pilotprosjekter. Utvalget ser behov for at det føres en dialog med næringslivet og leverandørene om behov for samordning av PKI-løsninger mellom forvaltningen og næringslivet. En slik dialog kan f.eks. føres i et eget forum for erfaringsutveksling, med deltakelse fra de tre partene.
Utvalget anbefaler at forvaltningen, ved samordningsfunksjonen, og i samarbeid med norske standardiseringsorganer, tar initiativ til etablering av et Forum for digitale signaturer der felles, standard løsninger for forvaltningen og næringslivet kan diskuteres med leverandører av sertifikattjenester.
9.5 Behov for stimuleringsmidler for å ta digital signatur i bruk i forvaltningen
Erfaringer fra noen prøveprosjekter med bruk av digitale signaturer og PKI i forvaltningen (f.eks. SESAM i helsevesenet eller SLN i skatteetaten) viser at denne teknologien ennå er forholdsvis umoden.
Det ble bl.a. avdekket problemer med integrasjon av systemer for digitale signaturer med systemer for ulike anvendelser i forvaltningen. På grunn av bl.a. dette er flere forsøksprosjekter med digitale signaturer blitt utsatt eller ikke satt i gang i det hele tatt.
Man må regne med at innføring av digitale signaturer og PKI i forvaltningen vil ta tid. Det er derfor viktig å komme i gang med utprøving, pilotering og utvikling av standarder og felles grensesnitt.
Leverandørforumet etablert under Programmet for elektronisk saksbehandling i Statskonsult drøftet forslaget til felles spesifikasjoner for et kommunikasjonsgrensesnitt mellom programmer for signering/kryptering og systemer for elektronisk arkivering og saksbehandling. Dersom man kan enes om felles utvikling og implementering av et grensesnitt, vil flere leverandører kunne begrense sine utviklingskostnader samtidig med at viktige brukerkrav blir realisert.
Bred innføring av digitale signaturer i forvaltningen vil kreve tilpasninger til mange forskjellige anvendelsessystemer. Bare i helsesektoren finnes det tre leverandører av ulike pasientjournalsystemer til sykehus og to leverandører av slike systemer til primærhelsetjenesten. I tillegg finnes det en rekke fagsystemer hvor integrasjon kan være aktuelt.
Forvaltningen mangler erfaringer med innføring av digitale signaturer og PKI i stor skala. Slike erfaringer er nødvendige for å kunne utvikle fornuftige fellespolicyer, rutiner og standarder.
Brukererfaringer med denne teknologien er også en viktig faktor ved framtidig innføring av masseløsninger for digitale signaturer blant publikum og i næringslivet. Skatteetaten er i ferd med å starte opp slike utprøvinger i stor skala. Man trenger imidlertid flere prosjekter i flere sektorer.
Utvalget mener derfor at det er behov for å avsette stimuleringsmidler for offentlige virksomheter som har planer om, eller er i ferd å komme i gang med, pilotprosjekter med bruk av digitale signaturer og PKI. Midlene kan tenkes disponert av den felles samordningsfunksjonen (jf. punkt 9.6) og tildelt etter gitte kriterier til prosjekter der digitale signaturer blir tatt i bruk for å understøtte tilbudet av elektroniske tjenester til forvaltningens brukere eller i forvaltningens interne samhandling.
Utvalget mener at ett av flere mulige kriterier for tildeling av midlene bør kunne være hvorvidt løsningene som skal utprøves, følger felles anbefalte standarder og/eller benytter felles etablerte ordninger for forvaltningen, f.eks. felles rammeavtaler.
Utvalget mener at det for budsjettåret 2002 bør kunne avsettes 9 mill. kr til en slik stimuleringsordning.
9.6 Behovet for en samordningsfunksjon for bruk av digitale signaturer og PKI i forvaltningen
Etablering av en PKI i forvaltningen og for forvaltningens brukere krever at det tas stilling til mange ulike spørsmål av teknisk, organisatorisk, juridisk og til dels politisk art. Det er viktig at infrastrukturen kan brukes mellom og mot de ulike forvaltningsenhetene. Det er også viktig at infrastrukturen fungerer på en mest mulig enhetlig måte overfor forvaltningens brukere. Samordning blir derfor et viktig virkemiddel. Slike spørsmål kan ikke behandles fullt ut gjennom rene anskaffelsesprosesser eller enkeltvirksomheters IT-strategier. Bredden i utvalgets mandat indikerer i seg selv kompleksiteten av problemstillinger knyttet til hensiktsmessig bruk av slik infrastruktur. Utvalget ser derfor et behov for en permanent samordningsfunksjon i forvaltningen som kan ivareta strategiske spørsmål ved utvikling, implementering og bruk av PKI for sikker kommunikasjon innad i offentlig sektor og med dens brukere.
9.6.1 Innholdet i en samordningsfunksjon for digitale signaturer og PKI
En slik samordningsfunksjon bør dekke både statlig og kommunal forvaltning, fordi en infrastruktur av denne art vil være felles for begge. Tilrettelegging av funksjonen bør ta hensyn til dette.
En samordningsfunksjon kan tenkes å omfatte bl.a. følgende oppgaver:
Utvikle, i samarbeid med sektorer og ulike forvaltningsnivåer, detaljerte krav til PKI-løsninger for offentlig sektor, herunder utvikle og forvalte de offentlige sertifikatpolicyene basert på PKI-utvalgets anbefalinger,
Være premissgiver og samarbeide med f.eks. Forvaltningsnettsamarbeidets innkjøpsordning i Statskjøp mht. gjennomføring av anbudsprosesser og inngåelse av relevante rammeavtaler,
Inngå felles samarbeidsavtaler på vegne av forvaltningen,
Utvikle et nødvendig standard avtaleverk for bruk av digitale signaturer og PKI i forvaltningen,
Vedlikeholde felles krav som offentlig sektor ønsker å stille til eksterne leverandører av sertifikater mht. bruk mot offentlig sektor, og foreta vurderinger og prekvalifiseringer av slike leverandører,
Føre oversikter over godkjente leverandører og krav som stilles til dem,
Koordinere aktiviteter innenfor anvendelse av digitale signaturer og PKI i forvaltningen, herunder håndtering av samtrafikkspørsmålet,
Utrede og håndtere problematikken knyttet til sertifikater fra utlandet,
Spre informasjon og holde kontakt med andre aktører i samfunnet (f.eks. gjennom et Forum for digitale signaturer) når det gjelder digitale signaturer og PKI.
Kommentarer til de enkelte oppgavene:
Utvikling av felles krav innebærer at det i regi av samordningsfunksjonen foregår en prosess med utarbeidelse av relevante dokumenter. Dokumentene bør så sendes på høring i forvaltningen før felleskravene fastsettes endelig. Det kan i denne sammenheng være hensiktsmessig å basere seg på prinsipper for utvikling av forvaltningsstandarder som er nedfelt i AAD-heftet fra 1995.
Grunnlaget for anbudsmaterialet for nye rammeavtaler bør ha en grundig forankring i forvaltningens felleskrav på området. Slikt grunnlag kan ikke utarbeides av konsulentmiljøer, som ellers er gode samarbeidspartnere når det gjelder standardiserte IT-produkter og -tjenester, som PC-er, kontorprogramvare osv. Det er derfor naturlig at samordningsfunksjonen, med forankring i prosesser beskrevet ovenfor, er den som leverer et slikt anbudsgrunnlag.
Samordningsfunksjonen vil kunne representere forvaltningen (staten og kommunene) i forhandlinger med markedsaktører som tilbyr sertifikater til enkeltpersoner (jf. valg av modell i punkt 9.3.3). Det er åpenbart at gunstigere vilkår kan oppnås hos slike markedsaktører dersom forvaltningen kan opptre samlet og inngå fellesavtaler, framfor at hver sektor eller etat fører forhandlinger selv og inngår avtaler på egen hånd. Videre er sjansene større for at markedsaktørene lettere vil kunne godta forvaltningens krav til tjenester (policy, sikkerhetsnivå) dersom forvaltningen bruker sin tyngde som storbruker.
Bruk av PKI medfører til dels komplekse ansvarsforhold mellom leverandører og brukere av sertifikattjenester. Det er krevende og vanskelig å utvikle godt avtaleverk som sikrer forvaltningens interesser. Det er derfor nærliggende å prøve å få fram standardavtaler på området, som forvaltningen kan få tilbud om å bruke, bl.a. for ikke å bli henvist til leverandørenes juridiske løsninger.
På lengre sikt, når markedet for sertifikattjenester er godt utviklet i Norge, kan samordningsfunksjonen, istedenfor å inngå felles samarbeidsavtaler med aktører i markedet, heller utøve rollen som den som prekvalifiserer (dvs. evaluerer og «godkjenner») leverandører av sertifikattjenester i forhold til felleskrav som forvaltningen vil stille (jf. punkt a). Slik prekvalifisering vil være et tilbud til offentlige virksomheter som blir møtt med krav om å kunne bruke ulike typer sertifikater i markedet.
Forutsetningen for at slik prekvalifisering skal kunne fungere, er at både kravene, evalueringsmetodene og resultatene er bredt tilgjengelige for alle involverte parter.
Samordningsfunksjonen bør kunne holde seg orientert om relevante kompetansemiljøer, prosjekter og andre aktiviteter når det gjelder digitale signaturer og PKI, bl.a. for å kunne legge til rette for erfaringsutveksling, knytting av kontakter, kompetanseutvikling m.m. I samarbeid med Forum for digitale signaturer samt Post- og teletilsynet bør man også ta initiativ til, og følge opp, arbeidet med samtrafikkløsninger for sertifikattjenester.
Spørsmålet om håndtering av sertifikater fra utlandet er et viktig og komplekst problemområde, som må utredes ytterligere, både i forhold til forvaltningens behov for sertifikatbruk og behovet for samtrafikk. Et nært samarbeid med Forum for digitale signaturer bør være naturlig. Kontakt med relevante internasjonale samarbeidspartnere og -miljøer vil være viktig.
Mange utredninger om digitale signaturer har pekt på behovet for økt kompetanse og kunnskap om området, både i forvaltningen og ellers i samfunnet. Samordningsfunksjonen bør derfor spille en viktig rolle. Dette kan innebære kontakt med samarbeidspartnere innen forskning og utvikling samt kontakt med andre kompetente miljøer i forvaltningen og utenfor. Det vil også være naturlig at samordningsfunksjonen har tett kontakt og godt samarbeid med Post- og teletilsynet og Datatilsynet, som blir tilsyn for leverandører av sertifikater i medhold av lov om elektronisk signatur.
Utvalget vil presisere at etablering av en slik samordningsfunksjon ikke skal gripe inn i offentlige virksomheters rett og plikt til selv å vurdere de sikkerhetsløsninger som man vil ha behov for i elektronisk samhandling i henhold til eget regelverk. Fellesordninger (som f.eks. rammeavtaler) for digitale signaturer som samordningsfunksjonen vil kunne etablere for forvaltningen, må betraktes som et tilbud som bør vurderes på linje med andre tilbud i markedet. Det kan likevel vurderes om offentlige virksomheter som skal gå i gang med digitale signaturer og PKI, skal pålegges å vurdere fellestilbudene først før man ev. velger andre løsninger.
9.6.2 Organisering og plassering av samordningsfunksjonen
Utvalget foreslår at samordningsfunksjonen organiseres som et fast samordningsutvalg bestående av representanter fra ulike sektorer og nivåer av forvaltningen (statlig og kommunal) og et sekretariat med fast bemanning.
Størrelse, sammensetning og mandat for samordningsutvalget bør vurderes konkret i forbindelse med etableringen. Utvalget mener likevel at alle store/tidlige brukere av digital signatur bør kunne inkluderes, at forvaltningsnivåer (særlig kommunene) bør ha tilstrekkelig representasjon, og at representanter fra de organer som arbeider med IT-samordning nasjonalt og i forvaltningen, bør delta. Samordningsutvalget bør ledes av et av samordningsdepartementene på IT-området, enten AAD eller NHD.
I etableringsfasen bør det avklares hvilke fullmakter sekretariatet skal ha i forhold til samordningsutvalget, og hvordan forholdet mellom dem skal fungere i praksis.
Utvalget estimerer ressursbehovet for denne funksjonen i en startfase som 1 årsverk til sekretariatsoppgaver og ca. 1–2 månedsverk pr. år fra hvert medlem i utvalget (noe større innsats, ca. 4 månedsverk, vil måtte forventes fra den som leder et slikt samordningsutvalg). Innsatsen fra medlemmene forutsettes dekket av de respektive forvaltningsorganene ut fra organenes egeninteresse i arbeidet.
Sekretariatet må få et driftsbudsjett, som gjør det mulig eventuelt å engasjere noe ekstern bistand. Størrelsen på budsjettet er vanskelig å estimere uten å vite hva slags oppgaver sekretariatet faktisk vil ivareta, men ut fra tidligere erfaringer med Forvaltningsnettsamarbeidet kan det stipuleres til ca. 6 mill. kroner det første driftsåret.
Midlene vil kunne benyttes til utredninger (av f.eks. håndtering av sertifikater fra utlandet), utarbeidelse av grunnlaget for rammeavtaler, utvikling av felles sikkerhetskrav og policy, evaluering av løsninger i markedet og finansiering av deltakelse i felles erfaringsforum med næringslivet og leverandørene, samt ev. bidrag til etableringen av en felles samtrafikktjeneste (jf. punkt 10.10.7).
Ved etablering av sekretariatet bør man ta i betraktning at den virksomheten som får denne funksjonen, bør ha tilstrekkelig nærhet til, eller kunnskap om, den praktiske implementeringen av PKI som pågår i forvaltningen.
Utvalget har drøftet ulike modeller for plassering av sekretariatet:
Forankring i AAD, NHD eller en underliggende virksomhet til disse,
Hos en «største bruker» av sertifikattjenester,
I et annet relevant fagmiljø/eksisterende myndighet, f.eks. Post- og teletilsynet eller Datatilsynet.
Plassering av samordningsfunksjonen bør kunne gjøres ut fra visse kriterier, f.eks.:
Nødvendig kompetanse,
Nærhet til sannsynlige brukere,
Evne til å kunne forene ulike interesser i forvaltningen og få fram felles krav,
Ingen fare for rollekonflikter eller habilitetsproblemer overfor forvaltningen og markedet,
Hvor enkelt det er å etablere sekretariatsfunksjonen og komme i gang.
Andre kriterier bør også vurderes.
Utvalget ser det som lite aktuelt å etablere et sekretariat med operative funksjoner internt i et departement. Det strider mot moderne prinsipper for organisering av departementsvirksomhet. En mulig plassering kunne i stedet være i et underliggende organ til AAD, som Statskonsult eller Statens forvaltningstjeneste. Begge disse organene har samordningsoppgaver. Plassering under et departementet med samordningsansvar på området og ev. ansvar for å lede utvalget, ville gi en «ryddig» styringsstruktur.
Statskonsult ønsker i sin rolle som kompetanseorgan innen forvaltningsutvikling ikke å miste sin uavhengighet og habilitet som evaluatør av statsforvaltningens IT-bruk. Operative, driftspregede funksjoner er det derfor ikke ønskelig at Statskonsult skal ivareta, ifølge etaten selv. Kommunesektoren er heller ikke noe naturlig nedslagsfelt for Statskonsult. Statskonsult er likevel en viktig aktør som bør kunne delta i samordningsutvalget, bl.a. i kraft av sin oppgave som ivaretaker (på vegne av AAD) av rollen som IT-standardiseringssekretariat for forvaltningen.
Statens forvaltningstjeneste (Ft) gjennomfører nå en strategiprosess med tanke på omorganisering og fokusering av virksomheten. Et bærende prinsipp i den nye strategien er at Ft skal fokusere på departementsfellesskapet som målgruppe for sine tjenester. Ressurser skal konsentreres om oppgaver knyttet til departementenes behov for fellestjenester, også på IT-området. Dette kan gjøre det vanskelig å plassere et sekretariat som skal utøve samordning for hele forvaltningen, inklusive kommunene.
Forvaltningsnettsamarbeidets innkjøpsordning, plassert i Ft’s avdeling Statskjøp, disponerer svært begrensede ressurser, samtidig som disse ressursene har kompetanse med hovedtyngde på innkjøpssiden. Øvrige strukturer i Forvaltningsnettsamarbeidet (utenom styringsgruppen som i praksis administrerer innkjøpsordningen) er såpass uavklarte at det ikke er naturlig å plassere en samordningsfunksjon der, slik situasjonen er nå. Det pågår også diskusjoner om framtidig organisering av felles innkjøpsfunksjoner for staten og ev. kommunene som kan innvirke på fremtidig organisering av Statskjøp.
I den andre gruppen er Skattedirektoratet og Rikstrygdeverket kandidater som peker seg ut på grunn av sin erfaring med bruk av digital signatur. Begge har noen års erfaring med bruk av digital signatur og PKI, særlig fra elektronisk samhandling med publikum og andre brukere av forvaltningen. Begge etatene besitter kompetanse på området. I tillegg kan både Patentstyret og Brønnøysundregistrene være aktuelle kandidater, på noe sikt.
Etablert forvaltningspraksis taler kanskje imot en løsning der en etat i en bestemt sektor tillegges samordningsfunksjoner der ulike behov og hensyn skal ivaretas på vegne av flere virksomheter og forvaltningsnivåer. Samtidig finnes det positive eksempler på at slike virksomheter tillegges fellesfunksjoner for forvaltningen (og resten av samfunnet), f.eks. det sentrale folkeregisteret og arbeidsgiver-/arbeidstaker-registeret.
Et annet moment som taler mot plassering av et sekretariat for en samordningsfunksjon i en sektor, kan være behovet for klare styrings- og ansvarslinjer for sekretariatet. Dette behovet kan være vanskelig å forene med forankring av samordningsutvalget i et IT-koordineringsdepartement.
Videre kan plassering av et sekretariat for samordningsfunksjonen i en stor statlig etat føre til bekymring om hvorvidt kommunesektorens interesser vil kunne ivaretas på en tilfredsstillende måte.
Den svenske regjeringen har i sin beslutning av 21.12.2000 lagt forvaltningens samordningssfunksjon for PKI til Riksskatteverket. Begrunnelsen for dette lød:
... inom Riksskatteverket sedan länge finns en omfattande kompetens när det gäller registerhållning för både individer och företag. Genom folkbokföringen är verket huvudansvarigt för de grundläggande individuppgifter som används i samhället. Verket tillhör också de myndigheter som har mest näraliggande planer på omfattande interaktion med medborgare och företag över Internet. Inom verket finns bl.a. av det skälet också den typ av IT-kompetens som krävs. De i utredningen deltagende myndigheterna har också funnit denna lösning lämplig, inte minst därför att det för närvarande synes vara den som snabbast kan genomföras.
Plassering av en samordningsfunksjon hos en tilsynsmyndighet som Post- og teletilsynet eller Datatilsynet, vil føre til habilitets- og rollekonflikter. Å ivareta tilsyn av aktører i markedet samtidig som man representerer interessene til noen av de største brukerne av digital signatur (forvaltningen), vil innebære en uheldig blanding av roller. I tillegg er en operativ samordningsrolle ikke naturlig for slike virksomheter.
Utvalget mener at det haster med etablering av samordningsfunksjonen, og anbefaler derfor at sekretariatet og utvalget etableres som et prosjekt i startfasen. Midler til dette bør kunne omprioriteres innenfor rammen av budsjettet for inneværende år (2001). Det bør drøftes av de relevante departementer hvordan en slik omprioritering konkret kan skje. De relevante departementene er Finansdepartementet, Nærings- og handelsdepartementet, Arbeids- og administrasjonsdepartementet, Sosial- og helsedepartementet og Forsvarsdepartementet. I tillegg må kommunal sektor delta i drøftingene.
En av årsakene til at funksjonen bør komme på plass umiddelbart, er hensynet til brukerne av rammeavtalen om digital signatur under Forvaltningsnettsamarbeidet, som utløper 1.6.2001. Inngåelse av en ny avtale tar tid, og man bør derfor søke å unngå at «gapet» mellom avtalene blir for stort. En annen grunn er behovet for dialog med markedsaktørene med hensyn til å etablere felles standarder på PKI-området.
Organisering og plassering av samordningsfunksjonene bør som nevnt drøftes av berørte departementer, berørte underliggende etater (som nevnes her, ev. andre i tillegg) og representanter fra kommunesektoren før det endelige valget tas. Utvalget mener at en slik drøftingsprosess bør kunne komme i gang straks.
Utvalget mener at den ordningen man til slutt lander på, bør evalueres etter to år, med tanke på eventuell alternativ organisering.
9.7 Oppsummering av anbefalinger
Utvalget anbefaler at forvaltningen får et tilbud om sertifikater til sine ansatte gjennom etablering av en ny, utvidet rammeavtale om digitale signaturer og sertifikattjenester under Forvaltningsnettsamarbeidets innkjøpsordning. Rammeavtalen skal også tilby produkter og/eller tjenester som gjør det mulig for en offentlig virksomhet selv å kunne utstede sertifikater til sine ansatte. Sertifikater for offentlig forvaltning bør i hovedsak være nivå 3-sertifikater, men nivå 2-sertifikater kan ikke utelukkes der behovet tilsier det.
Utvalget anbefaler at det for sertifikater til enkeltpersoner inngås samarbeidsavtaler med minst to aktører i markedet som utsteder, eller vil utstede, sertifikater til enkeltpersoner i forbindelse med egen bruk av digitale signaturer og PKI. Kostnader ved bruk av slike sertifikater mot offentlig sektor bør ikke belastes enkeltpersoner i startfasen. Sertifikatene bør være minst nivå 2-sertifikater, med overgang til nivå 3 når tilsvarende løsninger foreligger i markedet og er bredt tilgjengelige.
Utvalget anser at det bør vinnes flere praktiske erfaringer med bruk av sertifikater i forbindelse med elektronisk samhandling mellom næringslivet og forvaltningen før man foreslår fellestiltak fra forvaltningens side. Utvalget anbefaler at det etableres et eget Forum for digitale signaturer med representanter fra forvaltningen, næringslivet og leverandørene, for å drøfte felles standarder for digitale signaturer og PKI.
Utvalget anbefaler at det etableres en permanent samordningsfunksjon for bruk av digitale signaturer i og mot forvaltningen. Funksjonen organiseres som et permanent utvalg ledet av et IT-samordningsdepartement, enten AAD eller NHD, med et sekretariat med eget driftsbudsjett. Organisering og plassering av samordningsfunksjonen bør drøftes snarest av relevante departementer, etater og representanter fra kommunesektoren. Utvalget anbefaler at samordningsfunksjonen bør komme på plass allerede i 2001. Denne løsningen bør evalueres etter to år med tanke på en ev. alternativ organisering og plassering.
10 Forvaltningens krav til samtrafikk mellom leverandører av sertifikattjenester
Det eksisterer allerede en rekke sertifikattjenester, både i Norge og i et internasjonalt marked. Tjenestene er til dels forskjellige både med hensyn til kvalitetsnivå og bruksaspekter (nedfelt i sertifikatpolicyer), og når det gjelder innhold og format av selve sertifikatene. Mangel på samtrafikk (evnen som et produkt eller et system har til å samarbeide med andre produkter eller systemer) er en av hovedhindringene for å ta i bruk PKI. Utfordringene for forvaltningen er:
Sørge for avtaleverk og tekniske løsninger som sikrer samtrafikk med henblikk på sertifikattjenester som forvaltningen selv er kunde av eller selv driver,
Stille krav til og bestemme hvilke typer sertifikater, og fra hvilke utstedere, som skal kunne aksepteres fra privat sektor (enkeltpersoner og næringsliv) ved korrespondanse med forvaltningen,
Vurdere tiltak for å oppnå samtrafikk generelt, og ikke bare med hensyn til forvaltningens egne kommunikasjonsbehov,
Ta høyde for internasjonal samtrafikk,
Sørge for tekniske løsninger som kan håndtere forskjellige sertifikatformater og sertifikatutstedere.
10.1 Hva er samtrafikk?
10.1.1 Hva skal samvirke og hvorfor?
Samtrafikk har elementer av både teknologi og tillit. Den teknologiske siden kan deles i tre aspekter:
Man må kunne behandle sertifikater fra i prinsippet vilkårlige utstedere på en meningsfull måte, dvs. gjennomgå sertifikatinnholdet og sjekke utsteders signatur m.m.
Man må ha sikker kunnskap om utsteders offentlige nøkkel tilsvarende den private som ble brukt til å signere sertifikatet med. Dette er ikke trivielt når utstederen er en annen enn den man selv har fått sertifikater fra.
Samspill mellom produkter fra ulike leverandører må være mulig. Det er et faktum at to løsninger begge kan være i henhold til en standard, men likevel ikke virke sammen.
I tillegg må sertifikatbrukeren kunne bestemme hvor stor tillit det er mulig å ha til sertifikatet, det vil si om det er brukbart for det gitte formålet eller ikke.
Samtrafikk er et område som har betydning for alle aktører, og der løsninger må finnes ved en kombinasjon og vektlegging langs forskjellige akser:
Gjennom samarbeid mellom tjenesteleverandører kan man oppnå løsninger som i hvert fall et stykke på vei skjuler samtrafikkproblemer for brukerne.
I den grad samtrafikk mellom tjenesteleverandører ikke er på plass, må man tilrettelegge for at brukerne skal kunne løse samtrafikkproblemene selv.
Dette kan involvere egne tjenestetilbydere som tar seg av (deler av) behandlingen av sertifikater på vegne av brukerne.
Tiltak fra myndigheter – nasjonalt og internasjonalt – kan være nødvendig for å muliggjøre samtrafikk, enten som regulerende tiltak eller i form av tilrettelegging, og økonomiske og andre incentiver. Standardiseringsarbeid er også et viktig bidrag.
10.1.2 Status for samtrafikk
Status i dag er at samtrafikkavtaler mellom sertifikatutstedere er lite utbredt, men at man ser enkelte slike samarbeidsstrukturer. Eksempler i Norge er kryssertifiseringsavtalen for Forvaltningsnettsamarbeidet og arbeidet med et felles system, BankID, for sertifikattjenester for norske banker.
Internasjonal samtrafikk er lite utbredt, men noen eksempler finnes. Postverkene i Norge, Sverige, Finland og Irland har samarbeidet om sine tjenester med tanke på kryssertifisering. Det danner grunnlag for arbeid i Den internasjonale postunionen med tanke på et mer eller mindre verdensomspennende system for sertifikattjenester. Innen banksektoren er IDENTRUS 10 et meget viktig initiativ.
Samtrafikk på leverandørnivå oppnås gjennom tillitsstrukturer (se punkt 10.2) og felles spesifikasjoner. Men i dag, og i hvert fall en del år framover, vil samtrafikk i hovedsak være overlatt til brukerne. Egne tjenester for samtrafikk finnes ikke i dag, men er likevel også på relativt kort sikt et mulig alternativ.
Myndighetsrollen er i støpeskjeen, gjennom utredningsarbeid som denne NOU-en, og annet arbeid som oppsummert i kapittel 4.
Standarder for sertifikattjenester er i hovedsak på plass, men standardene inneholder ofte alternativer, og må presiseres ytterligere gjennom profiler. Spesielt gjelder dette selve sertifikatene. Disse er standardisert gjennom X.509 v3-spesifikasjonen [ 37], men sertifikater fra forskjellige utstedere bruker til dels vidt forskjellige profiler. Forskjeller i tekniske løsninger er relatert både til sertifikatutstedere og til leverandører av utstyr og programvare til utstedere og til brukere.
De juridiske aspektene ved samtrafikk er meget komplekse. Samtrafikk over landegrensene vil i tillegg kreve forståelse for og hensyn til særegenheter i andre lands lover og rettspraksis.
10.1.3 Behandling av sertifikater
Behandling av sertifikater består av:
Gjennomgang av sertifikatinnholdet 11 for å sjekke at det har korrekt format. Her skal det ikke være noen problemer med hensyn til samtrafikk dersom: 1) alle sertifikater som utstedes, følger samme standard (X.509 v3), og 2) programvaren hos sertifikatbruker kan lese alle mulige elementer i et X.509 v3-sertifikat. Disse kravene bør være oppfylt av alle utstedere og all vanlig programvare. Men praktisk erfaring viser at det kan finnes forbehold spesielt knyttet til private utvidelser, som X.509 v3 gir muligheter for, og som brukes av enkelte spesifikasjoner. Siden X.509 v3 er en omfattende standard med mange valgmuligheter, er det også en viss risiko for at produkter har feil, mangler eller unøyaktigheter.
Sjekk av utsteders signatur på sertifikatet. Dette betinger sikker tilgang på utsteders offentlige nøkkel.
Sjekk av gyldighetsperiode for sertifikatet. Dette skal ikke medføre problemer med hensyn til samtrafikk så lenge tidsangivelser er angitt på en måte som kan tolkes av sertifikatbrukerens programvare, og dette skal normalt være oppfylt. Det forutsettes også at aktørene har noenlunde korrekte klokker (det er ingen strenge krav til klokkesynkronisering).
En del andre tester av sertifikatinnholdet, bl.a. om bruken er i samsvar med det som er angitt i sertifikatet. Dette skal normalt håndteres riktig av alle implementasjoner. Merk at man også trenger støtte for de kryptoalgoritmene som brukes for sertifikatet, både signeringsalgoritmen for utsteder og den algoritmen som offentlig nøkkel i sertifikatet tilhører.
Sjekk av tilbaketrukket sertifikat – dette betinger tilgang på utsteders tilbaketrekkingsliste eller tilgang til andre tjenester for å sjekke sertifikatets status. En tilbaketrekkingsliste vil ha en veldefinert struktur som skal kunne behandles hos enhver sertifikatbruker. Dersom man er i stand til å sjekke utsteders signatur på et sertifikat, er man også i stand til å sjekke dennes signatur på tilbaketrekkingslisten.
Tolkning av innholdet i sertifikatet (felter, attributter og utvidelser) med tanke på videre behandling av informasjonen.
Dagens løsninger forutsetter at sertifikatbrukerens programvare er i stand til å ta seg av denne prosesseringen, eventuelt med assistanse fra brukeren selv. Kompleksiteten i dette øker sterkt med antallet forskjellige sertifikatprofiler og utstedere som man må forholde seg til. Det må være et mål å unngå at brukerne blir eksponert for disse problemstillingene.
Spesielle krav er knyttet til tolkning av informasjonen i sertifikatene i de tilfellene der brukeren er en tjeneste, dvs. at sertifikater må behandles helt automatisk og uten menneskelig medvirkning. Her må programvaren være i stand til å trekke ut den nødvendige informasjonen fra (forskjellige) sertifikatformater, og eventuelt avlede annen informasjon fra dette. Enten må programvaren ta hånd om dette selv, eller det må finnes egne tjenester som kan brukes.
10.2 Tillitsstrukturer og samtrafikk mellom utstedere
10.2.1 Tillitsstrukturer
Samtrafikk mellom sertifikatutstedere innebærer at tillit til en sertifikatutsteder (i figur 10.1 kalt SA) medfører at man også kan ha tillit til andre utstedere. Dette oppnås ved at utstederne inngår avtaler som regulerer forholdet dem imellom, og formaliserer dette ved å danne en tillitsstruktur.
Tillitsstrukturer kan kategoriseres slik:
Tillitsliste. Det dreier seg om helt separate utstedere, og sertifikatbrukere må vedlikeholde en egen liste over utstedere brukeren stoler på.
Hierarki, der utstedere har sertifikater utstedt av PKI-tjenester på høyere nivå, opp til en felles rot. Hierarkier kan i prinsippet være «dype», men det vanlige i dag er to-nivå (grunne)-hierarkier med bare ett nivå under roten.
Tillitsnettverk (web of trust), som realiseres ved kryssertifisering mellom PKI-tjenestene. Kryssertifisering gjøres ved at utstederne gjensidig utsteder sertifikater for hverandres offentlige nøkler (enveis kryssertifisering er mulig, men svært uvanlig). Dette er vanlige X.509 v3-sertifikater, men de skal være merket som kryssertifikater, og kravet til innhold er noe forskjellig fra sertifikater for brukere eller sertifikater utstedt i et hierarki.
Broer , som realiseres ved kryssertifisering mellom utstederne og en felles broutsteder. Tillitsmessig er dette det samme som et grunt hierarki, men implementasjonen er en annen.
Hybride modeller med kryssertifisering kombinert med hierarkier. Dette kan være krysssertifisering mellom utstedere internt i ett hierarki, mellom hierarkier på rot-nivå, eller generelt mellom en utsteder i ett hierarki og en annen tjeneste. Dette er ikke vist i figuren.
Dagens situasjon er i stor grad basert på tillitslister, dvs. at utstederne opererer helt separate tjenester, uten noen form for gjensidig samarbeid eller godkjenning. Man ser allerede nå at dette skaper problemer, fordi antallet utstedere, særlig i internasjonal sammenheng, begynner å bli stort.
Hierarkier og tillitsnettverk tillater at sertifikater utstedt av en eller annen tjeneste i denne strukturen kan gjenkjennes overalt ellers i strukturen (dvs. av sertifikatbrukere som har et tillitsforhold til en eller annen av tjenestene). Man kan konstruere en sertifikatkjede (også kalt tillitskjede ) mellom vilkårlige brukere innen strukturen. Det er ikke nødvendigvis lett å finne riktig sertifikatkjede.
10.2.2 Konsistent kvalitetsnivå for tillitsstrukturer
I utgangspunktet betyr ikke tillitsstrukturer noe mer enn en forenkling når det gjelder å gjenkjenne sertifikater. Det betyr ikke at alle tjenestene er på samme kvalitetsnivå. Sertifikatbrukere må altså definere tillit til hver enkelt tjeneste separat, akkurat som i tilfellet tillitslister.
Det er imidlertid vanlig å legge på ekstra betingelser, som garanterer at tjenestene er på samme kvalitetsnivå. I et hierarki gjøres dette ved at roten setter betingelser som en utsteder må oppfylle, før roten er villig til å utstede et sertifikat. Utstederen må gjøre betingelsene gjeldende for eventuelle underordnede utstedere dersom hierarkiet har mer enn to nivåer. Dette kan gjøres ved at roten setter en sertifikatpolicy som skal følges av alle tjenestene, men det kan også gjøres ved en evaluering av de sertifikatpolicyene som tilbys, opp mot et kvalitetsnivå. Dette er indikert for eksempelet «grunt hierarki» i figur 10.1 ved at roten har fått navnet «Policy-SA» (SertifikatAutoritet). Det er en betegnelse som av og til brukes, og som henspiller på at roten bestemmer sertifikatpolicyer for hele strukturen.
For kryssertifisering bruker man begrepet «policy mapping » for å indikere at tjenestene er på samme kvalitetsnivå. Policy mapping angis i krysssertifikater ved at man lister opp de sertifikatpolicyene som er involvert. Også for kryssertifisering er det mulig å bruke samme sertifikatpolicy for alle utstedere, slik det gjøres i Forvaltningsnettsamarbeidet.
10.2.3 Broer
En brostruktur (anvendt av føderale myndigheter i USA [ 26]) er tillitsmessig det samme som et grunt hierarki, der broutstederen fungerer som rot. Broutstederen definerer et sett av rammepolicyer som angir definerte kvalitetsnivåer. De enkelte utstederne kryssertifiserer så mot broutstederen med «policy mapping» mot den rammepolicyen som tilsvarer utstederens sertifikatpolicy. Man vil da alltid kunne gå til broutstederen og få tak i dennes (kryss-)sertifikat for en gitt utsteder, og man vil også gjennom dette kunne bestemme nivået på utstederens sertifikater gjennom kjennskap til den tilsvarende rammepolicyens nivå.
10.2.4 Dybde av hierarkier
Hierarkier med mange nivåer (dype) anbefales ikke. Det kan medføre lange sertifikatkjeder. Lange kjeder svekker tilliten siden det alltid er en liten mulighet for feil i et ledd i kjeden, og behandling av sertifikatkjedene kan bli meget ressurskrevende siden det kan være mange sertifikater som skal behandles. På nasjonalt nivå (i Norge og i andre land) ser vi at trenden heller er to-nivå-hierarkier, som f.eks. BankID. For internasjonal samtrafikk vil slike nasjonale to-nivå-hierarkier enten trenge ett nivå til over de nasjonale røttene, eller man kan bruke kryssertifisering mellom nasjonale systemer.
10.2.5 Hvor mye bidrar tillitsstrukturer til samtrafikk?
Man vil aldri få en situasjon der en tillitsstruktur omfatter alle aktuelle utstedere. Det offentlige kan stille krav (som i Forvaltningsnettsamarbeidet) til strukturer mellom utstedere som det offentlige selv skal bruke. Men for totalbildet, spesielt med et internasjonalt perspektiv, vil ikke dette kunne dekke alt. Strukturering av tjenester i hierarkier eller ved kryssertifisering forenkler likevel bildet for samtrafikk sterkt.
Eksempler:
Forvaltningsnettsamarbeidets rammeavtaler med kryssertifisering garanterer at sertifikatbrukere innen dette systemet bare trenger å forholde seg til sin egen utsteder,
Det er klart mye enklere å forholde seg til én felles BankID-løsning enn til forskjellige løsninger for forskjellige banker.
Man vil alltid stå igjen med en tillitsliste der man individuelt må bestemme tillit til enkelttjenester eller til hele tillitsstrukturer. Tillitslister forenkler situasjonen i den grad man kan gå fra lange til korte lister som stort sett angir tillit til et fåtall strukturer. Innen visse anvendelsesområder vil man bare trenge å forholde seg til et visst utvalg av alle mulige utstedere (f.eks. alle kommersielle i Norge), og strukturering av dette utvalget vil da kunne ha stor betydning.
10.2.6 Tiltrodde samtrafikktjenester
Som et supplement, eller kanskje som et alternativ, til tillitsstrukturer kan man tenke seg tiltrodde tjenester som behandler sertifikater fra «vilkårlige» utstedere på vegne av sertifikatbrukerne. En sertifikatbruker kan sende et mottatt sertifikat til en slik tjeneste, og som minimum få som svar om sertifikatet er gyldig, suspendert eller tilbaketrukket. Man kan tenke seg at tjenesten kan gi tilleggsinformasjon, f.eks. hvilket kvalitetsnivå et sertifikat har (ut fra sertifikatpolicy), eller informasjon som er avledet av innholdet i sertifikatet, f.eks. fødselsnummer. Slike tjenester kalles samtrafikktjenester.
Samtrafikktjenester kan tilbys:
Som kommersielle tjenester i et åpent marked,
Internt i en virksomhet for å sentralisere (policy for) sertifikathåndtering,
I samarbeid mellom virksomheter, f.eks. felles for flere forvaltningsorganer.
Samtrafikktjenester beskrives nærmere i punkt 10.10.7.
10.3 Sertifikatpolicy og kvalitetsnivåer
10.3.1 Tillit og kvalitet
Selv om de tekniske problemstillingene blir løst, vil det ikke være noen garanti for at et sertifikat er godt nok for det formålet man skal bruke det til. Hva som er godt nok, avgjøres av den sikkerhetspolicyen som gjelder for den aktuelle anvendelsen. Sertifikattjenester har varierende kvalitet når det gjelder prosedyrer for utstedelse og krav til sikkerhetsnivå for sertifikateierens omgivelser (f.eks. smartkort eller ikke). I tillegg kan det være gitt begrensninger på hvilke anvendelser sertifikatet er tillatt brukt for (f.eks. bare for banktjenester – tenkt eksempel), og utstederen kan i større eller mindre grad ha fraskrevet seg ansvaret for feilsituasjoner, spesielt i forhold til andre anvendelser enn tiltenkt.
Tillit til et sertifikat – om det skal aksepteres eller ikke – vil bli bestemt av kombinasjonen av utsteder og sertifikatpolicy. Denne avgjørelsen kan tas fra gang til gang når man mottar et sertifikat, eller regler for slike avgjørelser kan plasseres i sertifikatbrukernes systemer, f.eks. ved at lister av godkjente utstedere og sertifikatpolicyer settes i nettlesere eller e-postsystemer. Det finnes lite støtte for å plassere denne typen godkjenningsinformasjon på organisasjonsnivå utover å sørge for at nettlesere og e-post hos alle sertifikatbrukere får en standardisert og godkjent konfigurasjon. Men man kan anta at støtte for slik organisasjonsmessig konfigurering vil komme relativt snart, implementert i e-posttjenere, web-tjenere, brannmurer og andre komponenter på en virksomhets grensesnitt mot eksterne nettverk. En annen idé, som ikke er realisert foreløpig, er at brukerne kaller en samtrafikktjeneste (internt eller eksternt for organisasjonen), og får returnert et «ja» bare dersom både utsteder og sertifikatpolicy for det aktuelle sertifikatet er akseptable i henhold til virksomhetens sikkerhetspolicy.
Evaluering av sertifikatpolicyer i forhold til kvalitetskrav for et spesifikt formål er vanskelig. Dette bunner bl.a. i at sertifikatpolicyer er kompliserte, tekniske og til dels juridiske dokumenter. Det kan i hvert fall ikke forventes at den enkelte sertifikatbruker kan gjøre de nødvendige vurderinger.
Internasjonalt er en evaluering enda mer komplisert siden sertifikatpolicyer kan være skrevet på et fremmed språk, ha henvisninger til fremmede lands lover og regelverk og ellers være innholdsmessig og «kulturelt» fremmede.
10.3.2 Varemerker for sertifikater
En sertifikatpolicy definerer det kvalitetsnivået utstederen påberoper seg med hensyn til sertifikatene. En sertifikatbruker trenger tillit til at utstederen faktisk arbeider i henhold til sin sertifikatpolicy, altså at utsteder ikke jukser. Tillit til utsteder knyttes bl.a. til utstederens gode navn og rykte. Det man ser, er at utstedere prøver å bygge varemerker, f.eks. «VeriSign» 12, «BankID» 13, «Postens EID» 14 eller «ZebSign» 15. Varemerker har flere formål, men et av de viktigste er å oppnå tillit, ikke bare hos egne kunder, men også hos andre som må forholde seg til merket. Det er imidlertid et langt stykke igjen før varemerker for sertifikater er innarbeidet. Det virker kompliserende at et varemerke ikke behøver å være entydig. Sertifikatbrukere kan godt ha et forhold til VeriSign, men vil kanskje ha vanskeligheter med å skjønne at denne tjenesten har flere nivåer, og at de svakeste nivåene kanskje ikke burde godkjennes for sertifikatbrukerens spesifikke formål.
«Varemerke» kan eksemplifiseres ved en sertifikatbruker som ikke selv har noen BankID, men som velger å stole på BankID-sertifikater fordi sertifikatbrukeren vet hva dette er, og stoler på bankene. Internasjonalt vil dette bety at bare noen få, globale strukturer vil kunne få allmenn aksept. I dagens marked er det etablert noen slike varemerker, hvor det mest kjente er VeriSign.
Begrepet «kvalifisert sertifikat » kan betraktes ut fra samme tankegang. Dette er ikke et varemerke knyttet til en enkelt leverandør, men en annen form for et innarbeidet begrep, som impliserer tillit. Analogier kan være merking som «Godt norsk», eller former for miljømerking av varer.
10.4 Sjekk av sertifikater
Det å sjekke et sertifikat er samme prosess enten man behandler et sertifikat fra egen utsteder eller fra en annen og potensielt ukjent utsteder. Men prosessen kompliseres når man ikke «kjenner» sertifikatformat og utsteder. Da kan man trenge hjelp til prosessen.
10.4.1 Tilbaketrekkingsinformasjon
Sjekking av om et sertifikat er trukket tilbake, er en operasjon som i dagens praksis er anbefalt, men som man ofte hopper over. Strengt tatt løper man, i henhold til de fleste sertifikatpolicyer, en stor risiko ved å la være å sjekke utstederens tilbaketrekkingsinformasjon fordi dette skyver mer ansvar over på sertifikatbrukeren. Innen forvaltningen vil det være et krav at tilbaketrekking skal sjekkes før et sertifikat godtas, og det må legges til rette for at dette kan gjøres på en enkel måte for brukerne. Helst skal denne sjekken være helt usynlig for brukerne.
Tilbaketrekkingsinformasjon for en gitt utsteder kan man finne gjennom en peker i sertifikatet (CRL Distribution Point-utvidelsen) eller på annen måte. «Annen måte» betyr at sted for henting av tilbaketrekkingsinformasjon på forhånd må være satt inn i systemet hos sertifikatbrukeren, eller at en menneskelig bruker eksplisitt utfører operasjonene. Automatisert tolkning av, og bruk av, CRL Distribution Point-utvidelsen i sertifikater støttes av en god del, men ikke all programvare. Man er også avhengig av at utsteder faktisk legger denne informasjonen i sertifikatene, og det er langt fra alltid tilfelle. Et tilleggsproblem for sjekk av tilbaketrekking er at dette ofte er en tidkrevende operasjon, fordi:
Prosessering av sertifikatkjeder er meget ressurskrevende.
Sjekking av tilbaketrekkingslister kan være meget ressurskrevende fordi lengden på listen kan bli svært stor. Disse listene skal som oftest hentes over nettverket og prosesseres lokalt.
Et alternativ til tilbaketrekkingslister er tilgang til en OCSP-tjeneste 16 [ 55]. OCSP kan gi vesentlig raskere svar angående tilbaketrekking fordi det bare er en kort forespørsel online med et kort svar. Men det må være en tiltrodd tjeneste, hvilket medfører noe ekstra kompleksitet.
10.4.2 Tolkning av meningsinnholdet i sertifikater fra forskjellige utstedere
Problemene knyttet til samtrafikk kan oppsummeres slik: Kan sertifikatbrukeren trekke den nødvendige informasjonen ut av sertifikatet i en forståelig form? Dette har to underpunkter: Finnes informasjonen i sertifikatet (dvs. i sertifikatprofilen), og kan sertifikatbrukeren tolke informasjonen i den formen den er kodet i sertifikatet?
Noen deler av informasjonsinnholdet i sertifikater er standardiserte og obligatoriske, slik som algoritmeidentifikasjoner, serienummer og den offentlige nøkkelen selv. Disse skaper ikke problemer, men kryptoalgoritmene som brukes (både for signering av sertifikatet selv og for den offentlige nøkkelen i sertifikatet), må finnes hos sertifikatbrukeren.
Andre elementer i sertifikater er mer eller mindre obligatoriske i den forstand at alle «normale» sertifikatprofiler vil ha dem med, og kodingen er veldefinert. Key Usage og Certificate Policies-utvidelsene er to eksempler her.
Navn finnes alltid i sertifikater, men hva som inngår i navnene, og hvordan denne informasjonen er kodet (f.eks. hvilke attributter), vil variere fra profil til profil. En menneskelig mottaker vil vanligvis kunne gi meningsinnhold til navn, uavhengig av f.eks. om personnavn er kodet i Given Name- og Surname-attributtene eller i Common Name-attributtet. Men når mottaker er en applikasjon som skal trekke ut informasjon og viderebehandle den, er slike forskjeller svært kompliserende. I praksis må alle profiler «kodes inn» i applikasjonen.
Navn som skal være egnet for automatisert viderebehandling, bør inneholde ett unikt element – en unik identifikator – som applikasjonene kan ta tak i. Dette bør være tilstrekkelig til identifikasjon uten at andre deler av navnet behandles. Slike identifikatorer inngår i mange profiler, men hvilke felt de er kodet i, og hva de faktisk betyr, varierer fra tilfelle til tilfelle. Spesielt for internasjonal samtrafikk vil det kunne være vanskelig å forstå hva en identifikator egentlig representerer.
Forskjellige sertifikatformater kan raskt bli et problem spesielt for applikasjoner og systemer. Også for menneskelige sertifikatbrukere som skal bruke sertifikater fra ulike tjenester, kan situasjonen bli forvirrende. I et internasjonalt perspektiv kan man i tillegg få problemer knyttet til hvilket språk som er brukt.
Anbefalte sertifikatprofiler, der man har spesifisert minimumskrav til innhold og koding for sertifikater av forskjellige typer (ansattsertifikat, personsertifikat, virksomhetssertifikat osv.) er et viktig tiltak for samtrafikk. Andre deler av sertifikatinnholdet kan være opp til hver enkelt utsteder.
10.5 Tilgang til utstederes offentlige nøkler
Sjekk av et sertifikat forutsetter at man har sikker tilgang til utstederens offentlige nøkkel. Denne kunnskapen kan man ha ved at utstederens offentlige nøkkel er verifisert og lagt inn i sertifikatbrukerens systemer på forhånd, eller ved at den hentes f.eks. fra utstederens web-sider ved behov. Man kan også få tak i utstederens offentlige nøkkel ved at utstederen har et sertifikat utstedt av en annen utsteder – enten i et hierarki eller ved kryssertifisering. Det siste alternativet fører til et tilbakevendende problem: Man må ha sikker tilgang til denne utstederens offentlige nøkkel osv. I siste instans må man også her stole på en offentlig nøkkel som er lagt inn på forhånd, eller som hentes når behovet oppstår.
Av dette resonnementet følger det at man til slutt må hente og stole på en offentlig nøkkel som ikke er sertifisert av en utenforstående part. Utstedere må derfor publisere sine offentlige nøkler på en måte som gjør at brukere kan ha tillit til dem, og nøklene må beskyttes mot manipulering. Det siste gjøres ved at utstedere (i hvert fall de som ikke har noe sertifikat fra andre utstedere) publiserer sine offentlige nøkler gjennom egensignerte sertifikater. Dette gir ikke ordentlig autentisering av utstederen, men det gir integritetsbeskyttelse av nøklene, og autentisering dersom man stoler på at det egensignerte sertifikatet faktisk er fra utstederen.
Ved utstedelse av sertifikater vil alle utstedere sørge for at deres egne offentlige nøkler blir installert hos sertifikateieren. For smartkort o.l. vil utstederens offentlige nøkkel ligge i smartkortet, mens den for programvareløsninger vil bli installert i sertifikateierens system. Men med tanke på samtrafikk er spørsmålet hvordan man kan få tak i offentlige nøkler for andre utstedere enn dem man selv har et kundeforhold til.
I langt de fleste tilfellene er man avhengig av at alle utstederes offentlige nøkler må være tilgjengelige lokalt hos sertifikatbrukeren. Mange internasjonale sertifikatutstedere har sørget for å få sine offentlige nøkler med i standarddistribusjonen av nettlesere (som Microsoft Internet Explorer og Netscape Navigator) og etter hvert i systemer som Microsofts Windows 2000. Dette utgjør nå ca. 140 offentlige nøkler. Sertifikater fra disse utstederne kan prosesseres uten videre. Ingen norske utstedere er med i denne listen.
For sertifikater utstedt av andre tjenester, f.eks. av de norske aktørene innen området, er man avhengig av at tjenestenes offentlige nøkler eksplisitt installeres hos brukerne. Når dette er på plass, har man sørget for at sertifikater utstedt av disse tjenestene kan behandles og verifiseres.
Tillitsstrukturer forenkler situasjonen ved at offentlig nøkkel for én utsteder (roten i et hierarki eller en som har utstedt kryssertifikater) vil gi tilgang til andre utstederes offentlige nøkler gjennom sertifikater. Hos brukerne trenger man da i prinsippet ikke å installere offentlig nøkkel for mer enn én utsteder innenfor tillitsstrukturen, men av effektivitetshensyn kan det likevel lønne seg å legge inn nøkler for flere utstedere. Da slipper man prosessering av sertifikatkjeder .
Det er også mulig å la utstedere «nedover» i et hierarki (kryss-)sertifisere roten, slik at man kan starte med offentlig nøkkel for en vilkårlig utsteder i systemet (f.eks. den som har utstedt ens egne sertifikater), og få tak i roten gjennom et sertifikat. Dette er en løsning som har begrenset produktstøtte.
Det er ikke uvanlig at en sertifikateier oppgir (f.eks. legger ved en signert melding) alle sertifikater i en kjede fra seg selv og sin egen utsteder opp til roten, men det er mer vanlig at man bare legger ved sitt eget sertifikat, og overlater til sertifikatbrukeren å hente resten av sertifikatene i kjeden. I dette tilfellet må sertifikatbrukeren kunne gjøre katalogoppslag eller på annen måte kunne finne sertifikatene.
I et kryssertifiseringsregime er det ikke hensiktsmessig for sertifikateieren å oppgi mer enn sitt eget sertifikat. Sertifikatbrukeren må da finne et kryssertifikat utstedt av en utsteder som brukeren stoler på. Det enkleste tilfellet er der brukerens egen utsteder har en direkte kryssertifisering. Da kan sertifikatbrukeren greit finne kryssertifikatet fra egen utsteder, som brukeren jo stoler på.
I hybride systemer med kombinasjon av krysssertifisering og hierarki er det generelt meget vanskelig å finne en sertifikatkjede som kan brukes til å etablere tillit. Det er rimelig klart at med et stort antall utstedere vil en hierarkisk struktur være desidert enklest.
En av de største fordelene med samtrafikktjenester er at de er i stand til å håndtere denne kompleksiteten på vegne av brukerne. Offentlige nøkler for et stort antall utstedere kan legges inn i tjenesten på en sikker måte slik at brukerne ikke behøver å forholde seg til sertifikatkjeder og tillitsstrukturer.
10.6 Distribusjonstjenester og kataloger
10.6.1 Behov for kataloger
Alle sertifikatutstedere vedlikeholder kataloger over egne utstedte sertifikater. En katalog kan være «intern», dvs. tilgjengelig bare for utstederen selv og kanskje et antall «kjernebrukere» – som alle banker for BankID. Slike kataloger vil inneholde alle sertifikater fra den spesifikke utstederen.
Andre kataloger kan være åpent tilgjengelige, f.eks. på Internett, eller tilgjengelige bare for en mer eller mindre lukket gruppe, f.eks. gjennom abonnement. Sertifikateiere må som et minimum kunne reservere seg mot innlegging i åpne kataloger. Det kan tenkes at det i enkelte tilfeller vil være nødvendig med et aktivt samtykke. Sertifikater kan også eksporteres til andre kataloger enn dem utstederen selv kontrollerer, f.eks. bedriftsinterne kataloger, der dette ikke hindres av personvernhensyn .
Når det gjelder samtrafikk, ligger problemene i at en sertifikatbruker ikke uten videre kan vite hvilken utsteders katalog som inneholder det sertifikatet brukeren er ute etter, og det er heller ikke sikkert at brukeren har tilgang til den aktuelle katalogen (f.eks. fordi den bare er for abonnenter). Hvis man ikke vet hvem som har utstedt sertifikatet, kan et søk over alle mulige utstedere være svært tidkrevende. Dersom søket skal implementeres i en automatisert prosess, står man overfor en meget vanskelig oppgave.
Betydningen av katalogtjenester for sertifikater skal ikke overvurderes. Ved autentisering og signering vil sertifikateieren vanligvis legge ved sertifikatet (eller hele sertifikatkjeden om ønskelig) slik at sertifikatbrukeren ikke behøver å hente det selv. Sertifikater for en kommunikasjonspartner vil man normalt bare hente dersom man skal kryptere en melding til en mottaker, og ikke har dennes sertifikat for dette formålet. Selv dette trenger ikke å involvere et avansert katalogsystem. Lokale kataloger med sertifikater for dem man vanligvis kommuniserer med, oppslag på web-sider for informasjon om mottakeren eller rett og slett en e-post med spørsmål, er høyst aktuelle metoder.
10.6.2 Kopling av kataloger
Direkte samspill mellom katalogsystemer er meget vanskelig. Forvaltningsnettsamarbeidet stilte krav til leverandørene om et system der sertifikatbrukerne bare trenger å forholde seg til sin egen utsteder. Utsteders katalogsystem skal videreformidle søk til andre utstederes kataloger. Dette viste seg å være en meget kompleks problemstilling, og det var meget tidkrevende å få en løsning på plass. Kompleksiteten tilsier at slik kopling av katalogsystemer ikke vil være noen generell løsning på samtrafikk relatert til kataloger. Direkte kopling mellom kataloger krever i praksis at alle er basert på X.500-standarden.
Et alternativ til kopling er at kataloger ikke videreformidler søk, men returnerer et «hint». Dette kan støttes av LDAP 17 [ 75], som nå er den klart anbefalte protokollen for katalogtilgang, selv for kataloger som er basert på X.500. Dette krever at utstedernes katalogsystemer inneholder mye informasjon om hvordan hint skal gis, og at sertifikatbrukernes programvare (LDAP ) kan behandle hint.
BankID har i praksis en felles katalogstruktur der alle sertifikater legges i samme katalog, som så kan kopieres ut til den enkelte bank etter behov. Man kan tenke seg samme løsning som BankID, altså en felles katalog som inneholder alt, eller i hvert fall det meste, av sertifikater fra norske utstedere. Realismen i dette er kanskje ikke så stor, og gitt at katalogenes betydning ikke skal overvurderes, er det antakelig heller ikke nødvendig med en felles katalog.
10.6.3 Metakatalog
En enklere variant av en felleskatalog er en «metakatalog», som inneholder informasjon om andre kataloger. Sertifikatbrukere kan da søke via metakatalogen som enten kan returnere hint om hvilken katalog som bør prøves, eller som kan utføre søket på vegne av sertifikatbrukeren.
En metakatalog kan gjerne inneholde alle sertifikater for utstedere og alle kryssertifikater, slik at sertifikatbrukere kan gå ett sted for å få fatt i dem.
10.6.4 Hvordan gjøre tilbaketrekkingsinformasjon tilgjengelig?
En sertifikatutsteder må gjøre tilbaketrekkingsinformasjon tilgjengelig. Det trengs ikke noe katalogsystem for dette, men en velkjent Internett-adresse (URL) der informasjonen kan hentes. Det er sterkt anbefalt at denne adressen legges i sertifikatene, i CRL Distribution-Point utvidelsen.
Alle utstedere i dag støtter tilbaketrekkingslister (CRL ), som må hentes og prosesseres av sertifikatbrukeren, og som er «selvbeskyttende», slik at distribusjonstjenesten ikke trenger å være tiltrodd. Dette skyver mye prosessering og mye ansvar over på sertifikatbrukeren.
Utstederen kan også velge å operere en tjeneste basert på OCSP [ 55]. I sin enkleste form gir dette et ja/nei-svar på om et sertifikat er gyldig, basert på et spørsmål fra sertifikatbrukeren. En OCSP-tjeneste må være tiltrodd. Det betyr at tjenesten alltid må autentiseres overfor sertifikatbrukeren. For OCSP gjøres dette ved at svaret er signert, men man kan også tenke seg bruk av en autentisert, sikker kommunikasjonskanal for spørsmål og svar.
En samtrafikktjeneste kan erstatte OCSP-tjenester drevet av utstederne selv. Her kan brukerne tilbys ett punkt for sjekk av gyldighet av sertifikater fra flere utstedere.
10.7 Implementasjon og produktmessige aspekter
10.7.1 Implementasjon av tjenester som skal bruke sertifikater
Mulighetene for å bruke sertifikater fra forskjellige utstedere mot en gitt tjeneste bør prinsipielt bare være begrenset av hva tjenestetilbyderen ønsker å akseptere ut fra et organisatorisk og sikkerhetsmessig synspunkt. Dette forutsetter at tjenesten (applikasjonen) er implementert på en måte som muliggjør samtrafikk.
Samtidig finnes det et uttalt ønske om å slippe individuelle tilpasninger for hver enkelt sertifikattype som skal aksepteres. Dette kan oftest løses ved å isolere sertifikatbehandlingen i egne moduler, eller ved bruk av samtrafikktjenester.
10.7.2 Krav til brukersiden for tjenester som skal bruke sertifikater
En tjeneste som krever digitale signaturer, kan i dag ikke basere seg bare på standard programvare hos brukerne. Funksjonalitet for digitale signaturer støttes ennå ikke på en tilfredsstillende måte f.eks. av standard nettlesere.
Tjenesten kan da stille visse krav til hva brukerne skal ha på plass. De fleste leverandører av sertifikater vil levere tilleggsprogramvare for bruk av sertifikater og nøkler sammen med f.eks. nettlesere. Kravene vil være knyttet til karakteristikker for slik programvare hos brukerne, f.eks. evnen til å kunne produsere visse dokumentformater.
Alternativt kan tjenestetilbyderen selv tilby brukerprogramvare som tar seg av de ønskede funksjonene, men for samtrafikk er man avhengig av at programvaren som tilbys, kan støtte sertifikater fra forskjellige utstedere.
Enda et alternativ er å tilby funksjonaliteten i form av programbiter som overføres integrert med web-sider (script, Java applets, Microsoft ActiveX Controller). Dette er i dag meget vanskelig sett fra et sikkerhetsmessig synspunkt, og kan heller ikke gjøres på en enkel måte hvis man skal ta hensyn til samtrafikk – se [ 30].
Standardiseringsnivået for sertifikatprodukter med smartkort er ennå ikke på et slikt nivå at man kan unngå installering av spesielle komponenter for å kommunisere med smartkortet. Men disse spesialkomponentene kan i hvert fall i stor grad tilby standard programmeringsgrensesnitt. Dette er først og fremst et problem for mobilitet – det er enda et stykke igjen før en sertifikateier kan bruke sitt smartkort i en «vilkårlig» maskin.
10.7.3 Samspill mellom forskjellige produkter
Standarder innen PKI (selve X.509 v3, relaterte PKIX 18-spesifikasjoner og annet) gir, i likhet med svært mange andre standarder, rikelig rom for tilpasninger. Man kan lett havne i en situasjon der produkter fra to leverandører begge tilbyr profiler i overensstemmelse med standardene, men som likevel ikke kan virke sammen.
I prinsippet bør produkter være fleksible med hensyn til profiler, slik at tjenester har størst mulig fleksibilitet innen rammene av standardene. I praksis vil alle produkter ha visse begrensninger. Dette kan dreie seg om kryptoalgoritmer eller programmeringsgrensesnitt som ikke støttes, visse felter, attributter og utvidelser som ikke støttes i sertifikater, osv. Til en viss grad er dette forståelig, og det er rimelig at leverandørene ikke bruker mye ressurser på å støtte relativt «eksotiske» varianter.
I en del tilfeller kan det være at produktene nærmest blir skreddersydde til visse profiler, og dermed kan det oppstå problemer i de tilfellene hvor en tjeneste eller en kunde ønsker å bruke noe annet. Ett eksempel på dette er muligheter for å prosessere kjeder av sertifikater, som bør være et absolutt krav, men som ikke har full støtte i alle produkter.
Et viktigere eksempel er knyttet konkret til Entrust 19, som er verdens største leverandør av PKI-produkter. Entrust har laget egne PKI-profiler, og publisert disse. Entrusts produkter støtter bare disse profilene, med noen variasjoner, og det finnes en rekke tredjepartsleverandører som har lagt opp sine produkter etter de samme spesifikasjonene (Entrust-Ready-produkter). Fordelen med denne tilnærmingen er at man har fått på plass et godt utvalg av produkter, særlig på klientsiden, som virker sammen uten store problemer, ved at man har strammet tilstrekkelig inn på i utgangspunktet underspesifiserte standarder. Ulempen er at der Entrusts profiler ikke helt passer i forhold til kravene, har man valget mellom å tilpasse kravene, eller å stenge Entrust-Ready-produkter ute.
Det første alternativet, å tilpasse seg Entrusts profiler, kan bety dårligere tilpassede løsninger, og det betyr at man lar profiler bestemt av én leverandør være utslagsgivende. Innen forvaltningen er det klart at man ikke bør legge spesifikasjoner fra enkeltprodusenter – selv om spesifikasjonene er åpne – til grunn for kravspesifikasjoner. Selv om de fleste andre leverandører kan tilpasse seg Entrust, er dette klart konkurransevridende .
Med tanke på samtrafikk er det også uheldig å spesifisere en tjeneste på en måte som gjør at klienters sertifikater fra verdens største leverandør (med partnere) ikke kan brukes mot tjenesten.
10.8 Juridiske aspekter ved samtrafikk
10.8.1 Avtaleverk
En sertifikatutsteder vil ha avtaleforhold med flere andre parter:
Egne kunder (sertifikateiere),
Andre utstedere, gjennom kryssertifisering eller i hierarkier,
Registreringsautoriteter (ikke spesielt relevant rolle for samtrafikk, og derfor ikke berørt i dette kapitlet),
Sertifikatprodusent (datasentral med høy sikkerhet) der denne er forskjellig fra utsteder (som er den som er navngitt som utsteder i sertifikatene) – eksempelvis vil BBS 20 produsere sertifikater for BankID, men bankene er utstedere,
Smartkortprodusent, som også kan ha ansvaret for produksjon av nøkler,
Enkelte sertifikatbrukere, spesielt tjenester (private eller offentlige) som ønsker å akseptere sertifikatene for adgang til tjenester,
Andre tiltrodde aktører som enten trengs for sertifikatutstedelse (f.eks. offentlige registre), eller som tilbyr tilleggsfunksjonalitet (f.eks. en samtrafikktjeneste).
Alle tillitsstrukturer forutsetter avtalemessige forhold. Man bør ikke kryssertifisere uten en gjensidig avtale mellom utstederne. I et hierarki kan det avtalemessige løses gjennom en sertifikatpolicy som brukes for å utstede sertifikater for underliggende utstedere, men det er vanlig at man også her inngår eksplisitte avtaler (jf. interbankavtalen for BankID). Avtaler bør regulere ansvarsmessige forhold, men avtaleinnhold kan variere sterkt fra ett tilfelle til et annet.
Med hensyn til samtrafikk er det likevel klart at ikke alle aktører vil ha eksplisitte avtaler med en gitt utsteder. Dette gjelder først og fremst mange sertifikatbrukere, men det vil også gjelde utstedere som ikke deltar i noen felles tillitsstruktur.
Utstederen må gjøre klart sitt ansvar, sine ansvarsbetingelser og ansvarsbegrensninger. Dette kan gå ut på at sertifikateieren er ansvarlig for visse sikkerhetsforanstaltninger, at utstederen bare tar ansvar for bruk for bestemte formål, begrensninger i erstatningsbeløp osv. Lovgivning, rettsvalg og spesifikasjon av tvistemålshåndtering vil også normalt være med. De fleste slike forhold vil være regulert i en sertifikatpolicy. Aktører (særlig sertifikatbrukere) uten egen avtale med utstederen må da studere sertifikatpolicyen for å finne ut noe om den ansvarsmessige risikoen ved å akseptere et sertifikat.
10.8.2 Ansvarsforhold
For tjenester som ikke inngår i noen felles tillitsstruktur, vil det normalt ikke eksistere noe avtaleforhold som regulerer ansvaret mellom utstedere. Med henblikk på ansvarsforhold må man vurdere hver tjeneste for seg.
Ved hierarkier eller kryssertifisering vil det normalt eksistere avtaler som regulerer ansvarsforholdene, og slike forhold kan i tillegg være regulert i sertifikatpolicyer. Slike avtaler bør dekke opp forhold der en sertifikatbruker er kunde hos én utsteder, og der brukeren kan stole på et sertifikat utstedt av en av de andre utstederne i tillitsstrukturen. Som regel vil dette bli gjort ved at en sertifikatbruker bare trenger å forholde seg til sin egen utsteder ved feilsituasjoner. Denne utstederen vil så ta seg av forhold mot den utstederen som faktisk er ansvarlig for feilen (jf. BankID og Forvaltningsnettsamarbeidet).
For hierarkiske strukturer er det knyttet et spesielt problem til hvilket ansvar roten tar på seg, og hvilken aktør som skal ha dette ansvaret. I hvor stor grad er roten ansvarlig for (sine vurderinger av) egnetheten til utstedere lenger nede i hierarkiet? Finnes det noen aktør som naturlig bør ta ansvaret for roten, og har denne aktøren i tilfelle styrke til dette? For BankID tar bransjeforeningene (Sparebankforeningen og Finansnæringens Hovedorganisasjon) ansvaret sammen, og dette betyr i siste instans at deres medlemmer er solidarisk ansvarlige. Men hierarkier som binder sammen utstedere uten noen felles tilknytting gjennom bransjeforeninger eller på annen måte, vil ikke ha noen naturlig rotaktør. I andre tilfeller vil f.eks. en bransjeforening ikke ha tilstrekkelig styrke til å ta på seg reelt ansvar av betydning.
10.9 Oppsummering av problemområder
For samtrafikk kan man oppsummere de viktigste problemområdene relatert til elementene i en PKI slik:
Forskjellige profiler av standardene kan føre til samtrafikkproblemer mellom produkter fra forskjellige leverandører, og enkelte produkter er tett knyttet til bruk av visse profiler (f.eks. Entrust-Ready). På noen områder mangler det standarder.
Tillitsstrukturer løser langt på vei samtrafikk mellom utstedere som har valgt å inngå avtaleforhold og delta i en tillitsstruktur (hierarki eller kryssertifisering). Men man vil aldri få tillitsstrukturer som omfatter alle utstedere, derfor vil en sertifikatbruker uansett være nødt til å forholde seg til «utenforstående» utstedere.
Tillitsstrukturer fordrer prosessering av sertifikatkjeder. Dette er ressurskrevende og kompliserende, og støttes ikke av alle produkter.
Avtaleverk regulerer forholdene mellom aktører (utstedere og sertifikateiere/andre utstedere/enkelte sertifikatbrukere), men man vil alltid kunne få situasjoner der en sertifikatbruker ikke har noen eksplisitt avtale verken med den aktuelle utstederen eller sertifikateieren.
Sertifikatpolicy og sertifikatpraksis angir kvalitetsnivå på tjenestene og regulerer ansvar m.m., men det er vanskelig å sammenlikne tjenester fordi de i dag ikke kategoriseres i nivåer (bortsett fra etter hvert kvalifisert nivå). Sertifikatpolicyer (og -praksiser) er dokumenter som er vanskelig tilgjengelige selv for eksperter. Metoder for karakterisering av tjenester i et begrenset antall diskrete kvalitetsnivåer trengs.
Sertifikatformater fra forskjellige utstedere vil variere, og dette skaper problemer spesielt for automatisk viderebehandling basert på sertifikatinnholdet. Det er behov for basis sertifikatprofiler som kan sikre at viktig informasjon er med i alle sertifikater, og kan finnes på samme sted i sertifikatene.
Distribusjonstjenester for sertifikater er et vanskelig område for samtrafikk fordi samspill mellom flere, uavhengige kataloger er vanskelig, og sertifikatbrukere kan ikke uten videre vite hvilken katalog det er riktig å søke i. Metakataloger, som kan hente informasjon fra andre kataloger eller returnere fornuftige hint om hvor man skal søke, kan være en løsning.
10.10 Forvaltningens behov for samtrafikk
Forvaltningen kan vanskelig rette krav relatert til samtrafikk direkte til sertifikateierne, men kravene kan søkes oppfylt gjennom tiltak i forhold til utstederne.
10.10.1 Behov for tillitsstrukturer
Det er naturlig for forvaltningen å kreve etablering av tillitsstrukturer for de PKI-tjenestene som forvaltningen selv benytter som utstedere. Krysssertifisering – som Forvaltningsnettsamarbeidet – virker som den mest hensiktsmessige løsningen så lenge antallet utstedere forvaltningen har avtale med, er relativt lite. Forvaltningen bør stille krav til innholdet i kryssertifiseringsavtaler, på samme måte som det er gjort for Forvaltningsnettsamarbeidet.
Med tanke på grenseflaten mellom offentlig og privat sektor bør forvaltningen aktivt arbeide for etablering av tillitsstrukturer, f.eks. BankID, men det er vanskelig å se at det finnes noen «maktmidler» som er hensiktsmessige. For rent privat sektor gjelder den samme anbefalingen om aktivt arbeid for å få tillitsstrukturer på plass.
10.10.2 Forvaltningens behov for sertifikatkataloger
Forvaltningen vil ønske seg god tilgang til alle sertifikater for ansatte i offentlig sektor, f.eks. gjennom en videreføring av katalogstrukturen fra Forvaltningsnettsamarbeidet. Det er viktig å lage regelverk som sikrer at alle utstedere sørger for det nødvendige «bokholderiet» knyttet til tjenestene. Men forvaltningen kan vanskelig kreve avanserte katalogtjenester fra alle utstederne, og i hvert fall ikke at kataloger generelt skal kunne virke sammen. Løsninger med metakataloger er mulig, men utvalget anbefaler ikke å sette i gang noen større aktiviteter rundt sertifikatkataloger. Dersom prosjekter rundt generelle kataloger startes, anbefales det å få med sertifikater som ett element i dette arbeidet.
10.10.3 Løsninger for tekniske problemstillinger
Bruk av standardiserte profiler
I Norge vil felles profiler forenkle samtrafikk. Både for offentlig og for privat sektor anbefaler utvalget derfor at det brukes mest mulig felles profiler.
Tilgjengelige produkter
Ettersom man stort sett er prisgitt de store, internasjonale leverandørene når det gjelder hva som er tilgjengelig av produkter, er det begrenset hvor mye påvirkning man kan få til fra Norge. Det er uheldig å stille krav etter en enkelt leverandørs spesifikasjoner, men det er også uheldig, spesielt med tanke på samtrafikk, å lage spesifikasjoner som har lite støtte i produkter. Utover det at man alltid må holde seg innenfor standardene, er det eneste rådet utvalget kan gi i denne omgangen, å stille de kravene man mener bør oppfylles, og så justere dem etter hva det er mulig å få til med dagens produkter. Et nært samarbeid med leverandørene i spesifikasjonsfasen viste seg å være nyttig for Forvaltningsnettsamarbeidet.
Objektive og ikke-diskriminerende krav ved valg av standarder
Det bør stilles krav til at relevante standarder (og profiler) følges ved kommunikasjon med offentlig sektor. Disse skal i størst mulig grad være harmoniserte, offentliggjorte og tilgjengelige. Dersom slike ikke finnes fra internasjonale standardiseringsorganer, kan forvaltningen selv definere krav til standarder og profiler.
Allment tilgjengelige tjenester
Konkurranse i telemarkedet er et virkemiddel for å nå de telepolitiske målene, bl.a. at alle husholdninger og bedrifter over hele landet skal ha tilgang til grunnleggende teletjenester av høy kvalitet til lavest mulig pris. Forvaltningen har behov for å sikre at dette også skal gjelde for sertifikattjenester.
10.10.4 Avtalemessige forhold
De største avtalemessige problemene ved bruk av PKI ligger i håndtering av ansvar når sertifikatbrukeren ikke har noe som helst avtaleforhold med utstederen, og heller ikke med noen annen utsteder innenfor en tillitsstruktur som utstederen er med i.
For forvaltningen er det viktig at avtalemessige forhold er på plass, og det er sannsynlig at offentlige virksomheter vil ønske å inngå eksplisitte avtaler med utstederne de aksepterer sertifikater fra på grenseflaten mot privat sektor – også der utstederen ikke har egen avtale om levering av sertifikater til det offentlige. Subsidiært må offentlige virksomheter sjekke sertifikatpolicy/sertifikatpraksis for å avgjøre om det er f.eks. ansvarsmessige forhold som ikke er akseptable.
For rent privat sektor er det viktig med en viss lovmessig regulering av det ansvaret en utsteder må ta på seg, spesielt med hensyn til forbrukervern.
Dersom man ender opp med en strukturering av sertifikattjenester i et hierarkisk system, kan det tenkes at det er nødvendig for det offentlige å ta ansvar for å unngå at gode intensjoner ikke blir realisert fordi ingen kan eller vil ta ansvaret for roten.
Alle til alle-kommunikasjon
I telemarkedet fokuserer regelverket på at det er de sterke operatørene (som har mer enn 25 % av det relevante markedet) som pålegges å inngå avtale om samtrafikk. I praksis betyr det at Telenor fungerer som navet i et hjul og sikrer at alle telekunder kan kommunisere med hverandre. Også Telenor Mobil og NetCom er pålagt å inngå samtrafikkavtaler med andre når disse etterspør det.
Dette systemet vil ikke direkte kunne overføres til sertifikattjenester i form av pålegg om kryssertifisering eller et felles hierarki. Men et parallelt system kan implementeres ved hjelp av en samtrafikktjeneste. Dersom alle utstedere har en avtale med samtrafikktjenesten, og utleverer nødvendig informasjon f.eks. om tilbaketrekkinger, vil sertifikatbrukere kunne forespørre samtrafikktjenesten om gyldigheten av sertifikater fra «vilkårlige» utstedere. I prinsippet kan en samtrafikktjeneste faktisk også tilby sjekk av sertifikater fra andre utstedere enn de den har eksplisitte avtaler med, men dette vil ansvarsmessig medføre en meget uklar situasjon.
Dersom en samtrafikktjeneste skal ha en så sentral rolle som et «nav» for samtrafikk ved bruk av sertifikater, må det utredes nærmere hvilke krav – og eventuelt hvilket ansvar – forvaltningen skal stille til tjenesten. Dersom man ikke pålegger en samtrafikktjeneste en slik «obligatorisk» rolle, kan samtrafikktjenester tilbys i markedet til aktører som har behov for det.
En samtrafikktjeneste vil likevel ikke fjerne behovet for tillitsstrukturer som kryssertifisering. Tillitsstrukturer regulerer avtalemessige forhold direkte mellom utstederne, og vil på denne måten være tryggere for brukerne. En gjennomgående kryssertifisering eller et hierarki sikrer også alle til alle-kommunikasjon for et gitt sikkerhetsnivå uten at man er avhengig av enten en samtrafikktjeneste eller av å stole på et stort antall utstedere.
For å sikre alle til alle-kommunikasjon hva gjelder kommunikasjon med offentlige virksomheter, kan man tenke seg et system der det overlates til markedet å organisere ordninger for kryssertifisering, men at staten stiller som krav at de som skal utstede sertifikater til aktører innen forvaltningen, skal kryssertifiseres med hverandre, slik det er gjort for Forvaltningsnettsamarbeidet.
Prising
På teleområdet er prisen for samtrafikk den største kilden til konflikt. Operatører med sterk markedsstilling er forpliktet til å ta kostnadsorienterte samtrafikkpriser, men de mindre operatørene er ofte av den oppfatning at prisene gir en avkastning for de store som er høyere enn «rimelig avkastning av anvendt kapital» (det regulatoriske kravet).
For en samtrafikktjeneste for elektroniske sertifikater kan man tenke seg flere løsninger. Den ene ytterligheten er at alle operatører dekker sine egne kostnader, og at det ikke finnes felles katalog eller tjenester. I den andre enden av skalaen kan man se for seg at man oppretter en felles samtrafikktjeneste (database) som drives som et selvstendig selskap, og der operatørene betaler for bruk av den felles ressursen.
Det er på nåværende tidspunkt vanskelig å se om noen av alternativene peker seg ut som mest ønskelige. Valg av løsning kan også overlates til markedet, med mindre det er spesielle forhold knyttet til kommunikasjon med det offentlige som bør ivaretas.
10.10.5 Forvaltningens behov for tilsyn med samtrafikken
Samtrafikk er en del av premissene for å få PKI til å fungere på samfunnsnivå. Hvis forvaltningen stiller krav til at samtrafikk skal være mulig, og eventuelt hvordan den skal foregå, vil det være behov for å påse at kravene blir fulgt. Det kan gjøres på flere måter, og spørsmålet er hva som vil være et fornuftig rettslig virkemiddel. Forvaltningen kan kreve at aktører som forvaltningen vil benytte, forplikter seg til gode samtrafikktjenester. Forvaltningen bør sammen med relevante tilsynsmyndigheter og markedsaktører arbeide for etablering av slike tjenester.
Dersom samtrafikk realiseres (delvis) gjennom en separat samtrafikktjeneste, kan det være nødvendig å stille egne krav til (tilsyn med) denne tjenesten – se nedenfor.
Det er Forsvarets/totalforsvarets og Direktoratet for sivil beredskaps oppgave å sørge for at en PKI fungerer i krise- og krigssituasjoner. Forvaltningen bør selv kunne definere sine behov og hvilke tiltak som må settes i verk i slike situasjoner.
10.10.6 Forvaltningens behov for internasjonal samtrafikk
Det er foreløpig gjort lite for å kartlegge hvilke behov forvaltningen har for elektronisk kommunikasjon over landegrensene. Det er klart at det til en viss grad vil være behov for kommunikasjon med andre lands forvaltninger, og også med organer som EU, FN og andre. Behov for kommunikasjon med utenlandske virksomheter kan oppstå f.eks. i forbindelse med internasjonale anbudsforespørsler, og kommunikasjon med borgere som er bosatt i utlandet, kan oppstå f.eks. ved søknader om arbeids- og oppholdstillatelse og i forbindelse med trygd. I det siste tilfellet har Rikstrygdeverket identifisert et klart behov knyttet til internasjonal samtrafikk med tanke på sine ca. 16 000 utenlandske «kunder».
Det viktigste virkemiddelet i dag er at forvaltningen deltar i internasjonalt arbeid innen relevante områder, og at spesifikasjoner i Norge legges så tett som mulig opp mot det som er vanlig i våre nærmeste samarbeidsland. Oppfølging av arbeid i EU kan ha spesiell betydning.
Merk at krav om tilgang til fødselsnummer kan virke ekskluderende i forhold til utenlandske sertifikattjenester. Sertifikattjenesten må verifisere et oppgitt fødselsnummer mot folkeregisteret før sertifikatutstedelsen for å kunne produsere en korrekt tabell, og det er tvilsomt om slik adgang vil kunne gis til utstedere utenfor Norge.
10.10.7 En separat samtrafikktjeneste
Hva oppnår man med en samtrafikktjeneste?
En samtrafikktjeneste er en separat tjeneste som kan svare på forespørsler om i prinsippet vilkårlige sertifikater. En samtrafikktjeneste kan innhente informasjon om en rekke sertifikatutstedere, og effektivisere sjekking av sertifikater utstedt av disse. Bruk av en samtrafikktjeneste kan være fordelaktig fordi:
Tilbaketrekkingslister kan hentes regelmessig slik at samtrafikktjenesten ikke trenger å gjøre dette for hver enkelt forespørsel. Tjenesten kan bygge en tabell over tilbaketrukkete sertifikater, og bare sjekke mot denne.
Tjenesten kan ta seg av kompleksiteten knyttet til prosessering av forskjellige sertifikatprofiler på vegne av brukerne.
Tjenesten kan holde styr på et stort antall offentlige nøkler for utstedere.
Sertifikatkjeder kan behandles på forhånd slik at sjekk av sertifikater normalt vil kunne gjøres bare i forhold til utstederen uten ekstra prosessering knyttet til hierarkier, kryssertifisering etc.
Samtrafikktjenesten kan gjøre vurderinger av sertifikatpolicy og eventuelt annen informasjon med tanke på å kategorisere tjenester, f.eks. i kvalitetsnivåer.
Samtrafikktjenesten kan trekke ut eller avlede tilleggsinformasjon fra sertifikater, f. eks. «oversette» unik identifikator til fødselsnummer basert på den aktuelle utstederens tabell for dette.
Den viktigste ulempen knyttet til bruk av samtrafikktjenester er at dette er enda en tjeneste som man må stole på, og som må være tilgjengelig. Tjenesten vil kunne «sitte på» mye sensitiv informasjon, både knyttet til sertifikatene selv, og til logging av hvilke forespørsler som kommer fra forskjellige kunder.
Juridiske aspekter for samtrafikktjenester
En samtrafikktjeneste som tilbys store (institusjonelle) brukersteder, vil kunne ha et klart regulert forhold både til eierskap (til informasjon), bruksområder for tjenesten og tjenestetilbudet (kvalitet).
En samtrafikktjeneste som tilbyr policyavklaringer/policymapping, f.eks. gjennom kategorisering i forhold til kvalitetsnivåer, kan ha et stort ansvar i og med at dette vil være en tjeneste utover det som tilbys fra hver enkelt sertifikatutsteder.
Eierskap til sertifikat og tilleggsinformasjon vil være viktig. Hvem eier hvilken informasjon og hvordan kan denne informasjonen brukes? Tilleggsinformasjon vil ofte bare kunne utleveres til autoriserte brukere for autoriserte anvendelser, og med sikkerhetstiltak som oppfyller f.eks. Datatilsynets regler.
En samtrafikktjeneste vil stå ansvarlig for det som sendes ut av svar på henvendelser. Et slikt ansvar vil samtrafikktjenesten kun ønske å påta seg dersom det eksisterer avtaler mot sertifikatutsteder.
Anbefalinger om samtrafikktjeneste
Gitt kompleksiteten i samtrafikkproblemene antar utvalget at samtrafikktjenester på sikt kan være den mest tiltalende løsningen. Men det finnes ikke slike tjenester i Norge i dag, og det finnes få produkter for å realisere slike tjenester.
En samtrafikktjeneste for forvaltningen kan etableres i markedet i samarbeid med andre aktører som trenger en slik tjeneste. Forvaltningen kan da bidra i utviklingen av tjenesten, også økonomisk, for å få en tjeneste som er tilpasset forvaltningens krav.
Det antas at dette er en bedre løsning enn å etablere en sentral samtrafikktjeneste kun for forvaltningen eller separate samtrafikktjenester for hver enkelt offentlig virksomhet som måtte ha behov for det (eksempler kan være Skattedirektoratet, Rikstrygdeverket). Det er vanskelig å tenke seg noe annet enn at samtrafikktjenester for privat sektor blir tilbudt på et markedsmessig grunnlag.
Det vil være naturlig at flere aktører tilbyr samtrafikktjenester i markedet. Tjenestene kan som et utgangspunkt være knyttet opp mot spesielle tillitsstrukturer eller systemer (f.eks. BankID), men må kunne svare for utstedere utenfor disse systemene.
10.11 Anbefalinger for forvaltningens strategi
Dette mandatpunktet viser at det er mye som er uavklart i forbindelse med samtrafikk. Bl.a. er det forskjellige profiler for standardene som brukes, og det mangler en del standarder. Det finnes liten kompetanse på området. Tillitsstrukturer vil bare løse deler av utfordringene knyttet til samtrafikk, og avtaler mellom aktører er bare delvis på plass. Samtrafikk er fortsatt et ferskt felt der få kan vise til praksis.
Utvalget anser det som riktig å stille krav som man mener bør oppfylles, for deretter å justere dem etter hva det er mulig å få til. Utvalget har følgende anbefalinger:
Forvaltningen bør arbeide for etablering av tillitsstrukturer (kryssertifisering eller hierarki). Forvaltningen bør kreve denne typen strukturer for utstedere det offentlige har avtaler med. I øyeblikket antas det at det ikke er nødvendig at det offentlige oppretter en egen rot eller bro, slik man har gjort i en del andre land. Men dersom dette framstår som den naturlige løsningen, bør det offentlige være villig til å ta initiativer, jf. problemene rundt ansvarsavklaringer og tilgjengelighet av en «naturlig aktør» med ansvar for roten av tillitsstrukturer.
Det anbefales ikke å sette i gang initiativer eksplisitt for sertifikatkataloger, bortsett fra at man bør opprettholde kravene fra Forvaltningsnettsamarbeidet om «gode» kataloger, og helst også samspill mellom disse, internt i offentlig sektor. På sikt kan man vurdere etablering av en tjeneste for metakatalog med kopling mot (offentlige) kataloger for forskjellige utstedere.
Utvalget anbefaler at forvaltningen, ved samordningsfunksjonen, tar initiativ til etablering av samtrafikktjenester som kan motta sertifikater fra «vilkårlige» utstedere, og returnere informasjon om sertifikatet og eventuelt utlede informasjon fra innholdet. En samtrafikktjeneste bør implementeres gjennom et samarbeid mellom forvaltningen og private aktører, og tjenesten bør tilbys av kommersielle tilbydere. Det kan være aktuelt for forvaltningen å delfinansiere etableringen av tjenesten, som deretter må kunne operere på kommersielle vilkår.
Det bør utredes om forvaltningen har felles krav til verifikasjonsinformasjon i forbindelse med behandling av sertifikater.
Fotnoter
ftp://ftp.isi.edu/in-notes/rfc3039.txt
F. eks. «Lege, spesialist indremedisin».
http://www.identrus.com/
Alle banker forholder seg til Kredittilsynets forskrift, FOR 1994-02-07 nr. 118: Forskrift om legitimasjonskontroll og tiltak mot hvitvasking av penger, sist endret i 1998.
Lengden for nøkler oppgis vanligvis i antall bits.
http://www.verisign.com/
PCMCIA-kort er et standardisert innstikkskort til PC-er
eng. CPS – Certificate Practice Statement.
Common Criteria er en internasjonal standardmåte å evaluere sikkerhet i IT-produkter og -systemer på.
http://www.identrus.com
Dvs. sjekk av at sertifikatet har korrekt format i henhold til X.509 v3-standarden. Dette innebærer ikke noen vurdering av om verdier av felter, attributter og utvidelser kan tolkes og er fornuftige, bare at de kan leses.
http://www.verisign.com
BankID skal bli et varemerke (à la BankAxept) for en felles sertifikatstruktur for alle norske banker. Bankene skal selv være utstedere av sertifikater, og systemet skal struktureres i et to-nivå-hierarki med en felles rot over bankene.
Se http://peid.sds.no for mer informasjon. Dette er en sertifikattjeneste primært for privatpersoner. Posten er utsteder, og tjenesten drives av ErgoGroup.
ZebSign er Telenors kommende varemerke for sertifikater.
On-line Certificate Status Protocol.
Lightweight Directory Access Protocol er en Internett-standard for aksess til katalogsystemer.
Public Key Infrastructure for X.509 er en arbeidsgruppe under IETF (Internet Engineering Task Force), som er ansvarlig for tekniske spesifikasjoner for Internett.
http://www.entrust.com
Bankenes betalingssentral, http://www.bbsas.no