Innledning

Alle aktører i e-resept skal via Norsk Helsenett få tilgang til både adresseinformasjon og pekere til virksomhetssertifikater fra Adresseregisteret. Katalogtjenester for sertifikater, revokeringslister og fødselsnummeroppslag skal være tilgjengelige i Norsk Helsenett.

Sertifikater er sentralt i et PKI system. Sertifikater må være tilgjengelig for alle som skal kryptere meldinger eller validere signaturer. Private nøkler tilhørende sertifikatene må håndteres konfidensielt. Det er essensielt i systemet at uvedkommende ikke får tilgang til private nøkler.

Standarden X.509 spesifiserer formatet på sertifikater som brukes for PKI.

Et sertifikat vil også inneholde informasjon om hva nøkkelen i sertifikatet kan brukes til. De tre nøkkeltypene som er mest relevante i denne sammenheng er:

• contentCommitment ( tidligere: nonRepudiation) benyttes til signering (Elektronisk signering) av kjent innhold, og støtter «ikke-benektning» dvs. at man ikke senere kan nekte for å ha signert innholdet.
• keyEncipherment: innholdskryptering gjøres med symmetriske algoritmer, og krypteringsnøkkel krypteres med mottakerens "keyEncipherment" public-nøkkel.
• digitalSignature også kalt “kryptografisk signatur”. Benyttes for autentiseringsformål. Kan benyttes til signering av ukjent innhold (=challenge) og må derfor ikke forveksles med contentCommitment.

De sentrale dokumentene som setter krav til bruk av PKI i offentlig sektor generelt og helsesektoren spesielt er:

• eIDAS
• Kravspesifikasjon for PKI i offentlig sektor
• Rammeverk for autentisering og uavviselighet
• Rammeverk for elektronisk meldingsuveksling i helsevesenet basert på ebXML

«Kravspesifikasjon for PKI» refererer til tre sertifikatnivåer: Virksomhet, Person-Standard og Person-Høyt, mens «Rammeverk for autentisering og uavviselighet» definerer sikkerhetsnivåer.

For personsertifikater er det entydig definert at «Person-høyt» tilfredsstiller sikkerhetsnivå 4. Når det gjelder virksomhetssertifikater er situasjonen litt mindre entydig, og det referes til tiltak og rutiner for å ivareta sikkerheten på et høyt nivå også med disse. 

Ved signering av innholdet i elektronisk resept brukes rekvirentens «Person-Høyt» sertifikat enten direkte eller indirekte via HelseID. Signeringen skjer med enten:

• rekvirentens private nøkkel for ikke-avvisning (Content commitment), eller
• kombinasjon av identitetsbevis fra HelseID ogVirksomhetssertifikatssignatur fra godkjent underleverandør

Reseptformidleren vil sjekke signatur ved mottak og bekrefte denne signaturen med en tidsstemplet godkjenning.

Ved signering av forsendelser skal det i henhold til «Rammeverk for elektronisk meldingsuveksling i helsevesenet basert på ebXML» benyttes virksomhetssertifikater med ikke-avvisning (Content commitment). Disse er rene software-sertifikater som benyttes automatisk ved forsendelse og mottak av meldinger. Ved kryptering av forsendelser skal det benyttes virksomhetssertifikater med «dataEncipherment».

I e-Resept benyttes ebXML for asynkrone forsendelse, mens all synkron kommunikasjon med Reseptformidleren er webservice-basert, med fagmeldinger pakket direkte i SOAP konvolutt. For denne typen kommunikasjon er det akseptert å signere med «digitalSignature» sertifikat/nøkkel.

Signering gjøres med egen privat nøkkel, mens kryptering gjøres med mottakerens offentlige nøkkel.

Signering spesifiseres i e-Resept på to nivåer som er signering av forretningsdokument og signering av forsendelse.

Signering av forretningsdokument

Figuren under illustrerer hvordan et forretningsdokument (for eksempel en resept) signeres:

Figur 8: Signering av et forretningsdokument

Figuren over viser trinnene ved signering av et dokut og kontroll av signaturen.

1: En hash funksjon tar forretningsdokumentet og genererer en (2) message digest. Message digest er en verdi av bestemt lengde.

3: Message digest krypteres med avsenders private nøkkel, og dette danner den digitale signaturen (4). Den digitale signaturen sendes sammen med resepten og som en del av forretningsdokumentet.

Dekryptering av den digitale signaturen skjer ved at mottaker benytter avsenders offentlige nøkkel (5). Mottaker lager også en message digest av forretningsdokumentet (6) som sammenlignes med den dekrypterte signaturen. Det er dette som kontrollerer forretningsdokumentets integritet, da en endring i dokumentet vil gi en annen verdi for message digest.

En viktig forutsetning er at avsender og mottager benytter samme hash funksjon.

En signatur på et forretningsdokument er persistent, dvs. følger med gjennom hele dokumentets livsløp og sikrer at det til enhver tid kan etterprøves at dokumentet ikke er endret.

Ved signering av forretningsdokument skal nøkkel for «contentCommitment» benyttes.

Signering av forsendelse

Ved signering av en forsendelse gjelder samme prinsipper som ved signering av et forretningsdokument, men det er avsenders virksomhetssertifikat som benyttes. Denne kontrolleres av mottager med avsenders offentlige nøkkel.

Sertifikatets offentlige nøkkel legges ved forsendelsen.

Virksomhetssertifikater kan lastes ned dynamisk, men vil ofte foreligge som en del av kommunikasjonsavtalen mellom aktørene (CPA).

Asynkrone forsendelser som er basert på ebXML skal signeres med nøkkel for contentCommitment.

Synkrone webservice meldinger mot Reseptformidleren skal signeres med «digitalSignature». (Merk at det er støtte for kun ett sertifikat for signering av request og kryptering av response. Dersom det ikke benyttes kombinert sertifikat skal «dataEncryption» benyttes).

Kryptering av forsendelse

For å sikre konfidensialitet ved en forsendelse krypteres hele forsendelsen av avsender med den offentlige nøkkelen til mottagers virksomhetssertifikat. Mottagere dekrypterer med den private nøkkel tilhørende eget virksomhetssertifikat.

Kryptering og dekryptering av meldinger skal skje innenfor sikker sone

Figur 9: Signering med avsenders virksomhetssertifikats private nøkkel og kryptering med mottagers virksomhetssertifikats offentlige nøkkel

Behandling ved mottak

Alle aktører som behandler elektroniske resepter må verifisere meldingens integritet. Dette kan gjøres ved å sammenlikne beregnet hash-verdi for mottatt melding med tilsvarende verdi i signaturkontrollobjektet.

Ved behov gjøres oppslag i CRL/OCSP-tjenestene til CA, samt at det skal legges til rette for at virksomhetssertifikater kan lastes ned dynamisk. Av ytelseshensyn kan Reseptformidleren basere seg på revokeringslister (CRL) som lastes ned en gang per døgn og mellomlagres lokalt.

Spesielle forhold i e-resept

E-resept er en ny anvendelse av PKI i helsesektoren der signerte dokumenter ikke bare oversendes direkte til den endelige mottakeren. I e-resept signeres resepter av rekvirent, lagres i Reseptformidleren, hentes ved behov av utleverer og senere legges ved oppgjørskravet til Helfo. I mangel av et tiltrodd signeringstidspunkt valideres signaturen vanligvis i mottaksøyeblikket, ved å benytte mottakstidspunkt som effektivt signeringstidspunkt. I e-resept mottas resepten mange steder så lenge etter faktisk signeringstidspunkt at sertifikatstatus ofte vil ha endret seg siden signeringen. Dette løses ved å ta i bruk avanserte signaturer, XAdES, i henhold til ETSI TS 101 903 v1.3.2 eller nyere.  En XAdES signatur kan utvides over tid ved å legge til valideringsdata som signeres og valideres. Med valideringsdata menes tidsstempler fra tiltrodd tredjepart (TSA – time stamping authority), referanser til eller kopier av elementer i sertifikatkjeden og sertifikatstatus (her: OCSP svaret inklusiv fødselsnummer). Utformingen av konkrete e-resept signaturer og hvordan disse valideres ville da måtte dokumenteres i henhold til ETSI 102 038 v1.1.1 eller nyere.

For å kunne ta i bruk XAdES må det tilbys TSA tjenester. Disse må benytte referanseklokker og sertifikater med utvidet gyldighet, med tilsvarende lange nøkler og algoritmer med tilstrekkelig styrke, samtidig som TSAer i e-resept må være minst like tilgjengelig som Reseptformidleren. Tidsstempler må produseres i henhold til RFC3161.

Da disse forutsetningene er vurdert ikke å være på plass, har e-resept valgt å løse utfordringen med det nye tidsaspektet på en pragmatisk måte som drar nytte av tankene i ETSI TS 101 903 v1.3.2 og anvender aktuelt tilgjengelig PKI.

SignaturKontrollObjekt(SKO)

SKO inneholder reseptens mottakstidspunkt i Reseptformidleren. Dette tidspunktet er definert som effektivt signeringstidspunkt og benyttes her og senere i verdikjeden ved validering av signaturen.

Videre referer SKO til rekvirentens sertifikat og inneholder et entydig sammendrag av reseptens signaturverdi. SKO opprettes og signeres av Reseptformidleren i mottakstidspunktet.

Kombinerte sertifikater

Enkelte utstedere av PKI sertifikater kombinerer flere «keyUsage» typer i ett sertifikat. Den samme nøkkelen er dermed tillatt brukt for flere formål. Typisk gjelder dette kryptering og digitalSignatur (=autentisering). Nøkkel for ikke-avvisning (Content commitment) vil finnes i eget sertifikat kun til dette formål. Det er viktig at implementasjonene støtter valg av sertifikat av rett type under konfigurering.

Noen systemer i e-resept baserer seg på at det eksisterer kombinert sertifikat som kan benyttes både for kryptering, autentisering og signering. I noen systemer som kun signerer synkrone meldinger er det støtte kun for ett sertifikat, basert på at dette støtter begge funksjoner. I sentrale registre (AR) er det støtte for to sertifikat: Kryptering og Signering. For PKI leverandører som leverer separate sertifikat for hver nøkkeltype er det ikke full støtte for all bruk.

Nye versjoner bør støtte automatisk seleksjon av nøkkeltyper, og også ha støtte for både kombinerte og separate sertifikater.