Innhold på denne siden:

Faglig bakgrunn

I e-resept er det besluttet at Reseptformidleren skal gjennomføre en stringent kontroll av rekvirentens autorisasjon i HPR i forhold til sertifikatinformasjonen. Beslutning om dette ble først tatt av styringsrådet i juni 2007 og deretter er dette bekreftet av forskriften. De resepter som ikke oppfyller disse kravene forkastes av Reseptformidleren. Et slikt regime gjør situasjonen oversiktlig og enkel for utleverer; alle resepter i Reseptformidleren er kontrollert og akseptert (innenfor disse gitte rammer) men detaljer rundt rekvisisjonsrett (Kobling vare – rekvisisjonsrett fra HPR) sjekkes av utleverer. Det betyr at resepter blir avvist av Reseptformidleren hvis ikke rekvirentens fødselsnummer ligger korrekt i HPR og at vedkommende har autorisasjon.  Utleverer har fortsatt ansvaret for at utlevering skjer på en forsvarlig måte.

I e-resepts verdikjede formidles den elektroniske resepten gjennom mange ledd, først som M1, deretter som vedlegg i M9.4 og til slutt som vedlegg i M18. For alle ekspederte resepter vil både rekvirent, Reseptformidleren (RF) og en utleverer være involvert. For alle ekspederte blå resepter vil også Helfo være involvert grunnet refusjon

Det er viktig at alle aktørene oppfatter resepten på samme måte og at det ikke er tolkningsrom mellom aktørene. Det er sentralt at alle partene har en felles oppfatning av reseptens gyldighet og varighet.

Formål

Formålet med signaturkontrollobjektet (SKO) er å etablere en tillitskjede mellom partene i e-resept, for å sikre en felles basis for vurdering av en resepts gyldighet. 

SKO vil konkret dokumentere de kontrollene som Reseptformidleren har utført, og resultatene av disse, for å kunne formidle dette til andre aktører, på en persistent måte over tid. Grunnen til å dokumentere resultatet av kontrollene er for å kunne videreformidle at resepten var gyldig på mottakstidspunktet hos Reseptformidleren, ut fra validering av sertifikater og oppslag og validering mot HPR, siden resultatet av kontrollene kan endres over tid, avhengig av endringer i de relevante tilhørende registre.

SKO vil dessuten omfatte en tidsstempling av resepten. Reseptformidlerens tidsstempling innebærer en økt beskyttelse av den opprinnelige signeringen av resepten, og sikrer at denne oppfattes som gyldig i en lenger periode. Tidspunktet for kontrollen er i seg selv viktig, da andre parter kan benytte mottakstidspunktet (tidsstemplingen) som en verifikasjon av tidsangivelse og gyldighet av resepten og SKO.

SKO plasseres som et eget XML-objekt i signaturobjektet på den opprinnelige M1. Dette kan gjøres uten å bryte rekvirentens signatur. Ved å gjøre det på denne måten vil SKO kunne sendes med når resepten formidles videre mellom partene.

Funksjonalitet

SKO opprettes i Reseptformidleren for alle M1 som lagres i Reseptformidleren.  SKO lagres som en del av det opprinnelige signaturobjektet på resepten. På denne måten følger SKO med resepten i den videre behandling. Rekvirentens opprinnelige signering eller integriteten i meldingen ødelegges ikke ved dette.

Når Reseptformidleren mottar en resept vil den validere resepten. Når resepten er validert i henhold vedtatte kontroller blir godkjent resept lagret og resultatet av valideringen blir lagret i SKO. SKO blir lagret i signaturobjektet til den opprinnelige resepten. 

Reseptformidleren vil foreta et nytt OCSP-oppslag av rekvirentens personlige sertifikat for hver resept som behandles. Det er derfor kritisk at dette oppslaget kan utføres raskt.

Reseptformidleren vil benytte OCSP for eget virksomhetssertifikat for signering av HPR-data. Reseptformidleren vil gjøre dette oppslaget en gang per dag, og cache og gjenbruke resultatet for hver SKO. Siden Reseptformidleren vil kjenne til eventuell revokering av eget sertifikat vurderes dette å være en forsvarlig policy.

Reseptformidleren vil benytte OCSP for eget tidsstemplingssertifikat for signering av tidsstemplingen. Reseptformidleren vil gjøre dette oppslaget en gang per dag, og cache og gjenbruke resultatet for hver SKO. Siden Reseptformidleren vil kjenne til eventuell revokering av eget sertifikat vurderes dette å være en forsvarlig policy. Reseptformidleren vil logge tidsstemplingen sammen med en unik ID for tidsstemplingen.

SKO blir videresendt med M1 (resepten) til utleverer i M9.4, men ikke til rekvirenter i M9.6, M6, M8, eller M15 eller til SLV i M14.

Når utleverer laster ned en resept med M9.4 vil SKO mottas som en del av M1. Utleverer kan legge til grunn dokumentasjonen av utførte kontroller samt andre kontrollverdier i SKO ved utførelse av sin ekspedering.

Merk: Ved innføring av SKO forsterkes kravene til håndtering av sertifikater hos utleverer ved at utleverersystemet må kunne motta M9.4 fra Reseptformidleren inneholdende to ulike sertifikater. Eksempelvis kan SKO være signert med et gammelt virksomhetssertifikat, mens M9.4 er signert med ett nytt virksomhetssertifikat.

SKO fra Reseptformidleren blir deretter (for blå resepter) videresendt sammen med resepten i Oppgjørsmeldingen M18 fra utleverer til Helfo. Når Helfo mottar en M18 vil M18 valideres og de vedlagte M1 vil valideres. Ved at SKO fra Reseptformidleren medfølger vil kontrollen hos Helfo muliggjøres.

Innhold i SKO

SKO omfatter informasjon om

• gyldigheten av rekvirentens personlige sertifikat og tilhørende fødselsnummer som Reseptformidleren innhenter fra CA i form av et OCSP-oppslag.
• resultatet av Reseptformidlerens HPR-kontroll sammen med kopi av OCSP-oppslaget for Reseptformidlerens virksomhetssertifikat
• et tidsstempel på resepten, sammen med kopi av OCSP-oppslaget for Reseptformidlerens tidsstemplingssertifikat

I det videre vil hvert av disse elementene bli beskrevet.

Gyldighet til rekvirentens personlige sertifikat

Dokumentasjon av gyldigheten til rekvirentens personlige sertifikat dokumenteres med å bruke resultatet av oppslaget Reseptformidleren gjør mot VA. Ved å benytte signert dataobjekt i henhold til XAdES-standarden (ETSI TS 101 933) er det et behov for å inkludere revokeringsstatus-informasjon på et standard format slik at det er mulig for andre aktører å verifisere disse i etterkant.

Informasjonen i SKO om gyldigheten til rekvirentens personlige sertifikat vil derfor baseres på en standard OCSP-respons fra CA/VA.

SKO vil inneholde rekvirentens fødselsnummer, da dette er innehold i standard OCSP-respons. Det vurderes at denne informasjonen kan tilgjengeliggjøres på denne måten for utleverere og Helfo, da disse har behov for tilgang til denne informasjonen for å kunne utøve sin funksjon.

HPR-oppslag

HPR-oppslaget er ikke en del av PKI-strukturen, men anses å være en sentral del av tillitskjeden knyttet til e-resept. Det er derfor valgt å inkludere resultat av Reseptformidlerens oppslag i HPR inn i SKO.

Tidsstempling

En vanlig resept er gyldig for ekspedering i inntil et år og visse resepter er gyldige i inntil tre år. I perioden mellom reseptens utstedelse og reseptens bruk kan rekvirentens personlige sertifikat utløpe. Dette er et eksempel på at sertifikatstatus for et sertifikat (I dette tilfelle rekvirentens) kan endres over tid fra initiell kontroll og frem til siste kontroll av resepten. Reseptformidleren vil derfor tilføre en langtidsbeskyttelse av SKO som hviler på en annen signatur enn signaturen på OCSP-responsen. 

Ved at Reseptformidleren gjennomfører en egen tidsstempling av resepten i SKO, basert på eget tidsstemplingssertifikat, oppnås to viktige forhold:

1. tidspunktet for beregning av starten av reseptens gyldighet (Utstedelsestidspunktet) fastslås autoritativt
2. reseptens sertifikatmessige gyldighet økes til gyldigheten for Reseptformidlerens tidsstemplingssertifikat.

I påvente av at NHN eller andre etablerer TSA tjenester, er Reseptformidleren akseptert som TSA i e-resept.

Reseptformidleren vil dermed opptre som tiltrodd tidsstemplingsautoritet (TSA), og vil i den forbindelse benytte dedikert sertifikat med extendedKeyUsage utvidelsen id-kp-timeStamping, jf. RFC3161.

Tidsstempling implementeres i Reseptformidleren ved å bruke XAdES-T for tidsangivelsen.

1. Sertifikatet utstedes under CP for Buypass virksomhetssertifikater
2. E-resept/Helfo må produsere en CSR (Certificate Signing Request) som Buypass benytter for å generere det aktuelle sertifikatet
3. Nøkkelen skal være 2048 bits
4. Levetiden på sertifikatet settes lik 3 år

Reseptformidleren vil synkronisere sin klokkefunksjon mot en klokkefunksjon hos Universitetet i Oslo: (ntp.uio.no), kontrollert mot 4 andre autoritative klokkefunksjoner.

Spesielle forhold knyttet til varighet av tidsstempling i 3 år

Som nevnt tidligere vil det finnes resepter som skal være gyldige i opptil 3 år etter utstedelse. Etter tre år kan både rekvirentens personlige sertifikat, Reseptformidlerens virksomhetssertifikat og Reseptformidlerens tidsstemplingssertifikat være utgått. Med bruken av XAdES vil det være gyldigheten av Reseptformidlerens tidsstemplingssertifikat som blir styrende. Det er derfor viktig at dette sertifikatet til enhver tid ikke har for kort gjenværende gyldighet. For å hindre at dette blir et problem vil Reseptformidlerens tidsstemplingssertifikat fornyes hvert år. Det er dermed bare de resepter som har tre års gyldighet i utgangspunktet, hvorav mange er hvite resepter, og som ikke er slettet/utekspedert etter to år, som vil bli berørt av dette problemet. Det forventes at dette vil løse problemet for en dominerende andel av reseptene. For alle resepter som har gyldighet innenfor utløpstiden til Reseptformidlerens tidsstemplingssertifikat vil SKO inneholde all informasjon senere parter trenger for validering av resepten, uten å måtte gjøre oppslag mot eksterne parter.

Dersom det viser seg at årlig fornyelse av Reseptformidlerens tidsstemplingssertifikat skaper problemer, kan det vurderes to tilnærminger:

1. Øke frekvens for oppdatering av Reseptformidlerens tidsstemplingssertifikat til halvårlig kvartalsvis, eller månedlig
2. Reseptformidleren kan utvide sin tidsstempling av de aktuelle reseptene med XAdES-A- signatur

Erfaringer med bruken av XAdES vil vurderes etter hvert og tilnærming velges i tråd med dette.

Det vil også være slik at Helfo vil kunne motta resepter i lang tid etter at resepten er ekspedert (og utgått). En utleverer må fremme sitt krav overfor Helfo innen 6 måneder etter ekspedering, men kan etter initiell avvisning fortsette å fremme kravet i ubestemt tid. Reseptene vil på et slikt tidspunkt være utenfor Reseptformidlerens kontroll og det SKO som er laget av Reseptformidleren vil kunne være utgått. I slike situasjoner vil utleverer kunne utvide reseptens tidsstempling ved å tilføre XAdES-A inn i SKO, før den opprinnelige tidsstemplingen utløper. Dette er ikke forutsatt som et krav nå, men kan bli en aktuell utvidelse senere, dersom dette viser seg å bli et praktisk problem.

Bruk av standardisert format (ETSI XAdES)

[1] http://uri.etsi.org/01903/v1.3.2/ og altså ETSI TS 101 903 V1.3.2 (2006-03

Det har vært et viktig mål for arbeidet med SKO å finne en form på det som gjør gjenbruksverdien av SKO størst mulig for partene. Bruk av aktuelle standarder for slike objekter har derfor vært vurdert. Slike standarder er ikke i bred bruk innenfor helsesektoren i Norge i dag. E-resept vil derfor gjøre nybrottsarbeidet med bruken av slike standarder.  Den standard som legges til grunn er ETSI XAdES. Det antas at vi ved å legge ETSI XAdES v1.3.2 og ETSI TS 101 903 V1.3.2 (2006-03) til grunn, kan oppnå viktige fordeler som:

1. Bruken av avanserte XML-signaturer er transparent og krever ikke at et nytt XML-dokument spesifiseres.
2. Bruken av XAdES vil minske arbeidet med å implementere og bruke SKO.
3. XAdES er en bæredyktig standard som forventes å bringe elektronisk samhandling og dokumenthåndtering i helse- og sosialsektoren videre.

Avanserte XML signaturer kvalifiserer en signatur i henhold til XMLDsig. Ved å utvide signaturen med tidsstempler (XAdES-T), sertifikater og sertifikatstatusinformasjon (XAdES-X-L eller -A) gjøres validering av signaturen etter lang tid mulig.

XAdES signaturer kan også utvides over tid.

Detaljer i bruken av XAdES i SKO er vist i eksemplene til slutt i dette vedlegget.

Policy

Roller

I e-resept er Reseptformidleren akseptert som tiltrodd tidsstemplingsautoritet TSA. Dette forutsetter at Reseptformidleren disponerer en klokke som oppfyller kravene til Kravspesifikasjon for PKI i offentlig sektor, hvilket anses som oppfylt.

Sertifikater

Kravene til sertifikater i e-resept er som følger:

Nøkkelbrukutvidelser

E-resept krever nøkkelbrukutvidelser som følger:

Algoritmer / styrke

E-resept krever algoritmer med styrke som følger:

Konkrete verdier og parametre som skal brukes

Tidsstempelet som legges ved i rekvirentens signatur inneholder et element (<dss:TSA>) som identifiserer utstederen av tidsstempelet, i dette tilfellet er Reseptformidleren. Identiteten til TSA’en bør representeres som DN (Distinguished Name) fra sertifikatet som benyttes til tidsstempling. Denne verdien vil bli beskrevet i Reseptformidlerens grensesnittsdokument.

Regler ved bortfall av katalogtjenester for PKI

RF skal validere virksomhetssertifikater sertifikater opp mot revokeringslister. Revokeringslister lastes ned fra sertifikattilbyder. Følgende prinsipper gjelder for dette:

• RF kan akseptere meldinger opp til 12 timer etter at gyldigheten for siste CRL utløp
• Det etableres en mulighet for å revokere/sperre sertifikater eller på annen måte hindre tilgang lokalt i Reseptformidleren. Dette kan benyttes hvis oppdatering av CRL ikke er tilgjengelig til å sperre utleverere på bakgrunn av manuelt innhentet informasjon.
• Varslingsrutiner mellom Reseptformidleren og sertifikattilbyder etableres for å få overført revokeringsdata ved feilsituasjoner
• Ved utilgjengelig OCSP-oppslag kan Reseptformidleren benytte cashet verdi som beskrevet i Håndtering av nedetid hos CA.

Eksempler

Strukturen for de ulike signaturelementer i SKO fremgår av figuren under:

XMLDsig angir hvordan rekvirentens signatur generelt utvides

XAdES – T vises hvordan tidsstemplingen legges til.

XAdES – CounterSignature vises hvordan HPR-data legges til

XAdES-X-L vises hvordan signeringsinformasjon legges til

XAdES – A vises hvordan ytterligere arkivering av tidsstempling kan foretas

XMLDSig

I henhold til DSIG utformes rekvirentens signatur som enveloped signature, der signaturen blir en del av XML dokumentet som signeres, som vist i eksempelet under:

Eksempel 1: XMLDsig

<ds:Signature> elementet i eksempelet over inneholder en referanse til det omsluttende XML dokumentet, dvs. resepten.

Eksempelet under viser hvordan et slikt <ds:Signature> element typisk kan se ut slik det foreligger i M1 etter rekvirentens signering:

Eksempel 2: XMLDsig med Signature

Rekvirentens signatur vil av Reseptformidleren utvides med ny informasjon i elementene <ds:Signature> , <ds:SignatureValue> og <ds:KeyInfo> , som vist i eksempelet under, slik at det entydig kan refereres til i XAdES.  Attributtene kan tilføyes etter at signaturen er produsert av rekvirenten uten å bryte signature

Eksempel 3: XMLDsig med utvidet signaturinformasjon

XAdES-T

XMLDSIG definerer <ds:Object> elementet for å supplere informasjon i en signatur.

XAdES definerer XAdES-T formatet for å tidsstemple en signatur. Tidsstemplet gjelder som effektivt signeringstidspunkt ved all validering av signaturen.

To standarder definerer tidsstempler: RFC31619 i ASN.1 og OASIS DSS10 i XML syntaks. Uansett gjelder kravene fra RFC3161 når det gjelder hva et tidsstempel inneholder og hvordan slike produseres. OASIS DSS tidsstempler er enkle å produsere med standardbiblioteker, siden de egentlig bare er XMLDSIG enveloping signaturer. Derfor vurderes OASIS DSS som enklest å implementere i e-resept, og legges til grunn.

Eksempel 4: XAdES-T – plassering av SignatureTimeStamp

Eksempel 5: XAdES-T – innhold i XMLTimeStamp

XAdES CounterSignature

Elementet <xades:CounterSignature> refererer til rekvirentens signatur samt HPR-data.

Elementet er en signatur av Reseptformidleren og inneholder således Reseptformidlerens sertifikat.

Eksempel 6: XAdES-CounterSignature

HPR data

Eksempel på skjema for HPR data er vist under:

Eksempel 7: HPR-data

Fra 2019/2020 vil bli tatt i bruk ny versjon av feltet "RfHprData". Ny versjon av RfHprData gir støtte for flere autorisasjoner, og rekvireringskode(r) og spesialitet(er).

Ny og gammel form vil eksistere i Reseptformidleren avhengig av tidspunkt for mottak i RF.

Nye eksempler vil publiseres når dette er klart i reseptformidleren.

RfHprData basert på xmlns:rfhpr="http://www.ehelse.no/xmlstds/eresept/rf-hpr-data/2019-01-01"

XAdES-X-L

Her utvides elementet <UnsignedSignatureProperties> med alle sertifikater og all statusinformasjon.

Under <xades:CertificateValues>  legges det ved

• hele sertifikatkjeden for rekvirenten, dvs. rekvirentens sertifikat og CA sertifikatet for dette.

Hvis nødvendig legges det også ved

• hele sertifikatkjeden for statusinformasjon (OCSP eller CRL), dersom det benyttes delegerte OCSP signeringssertifikater uten utvidelsen id-pkix-ocsp-nocheck. Sertifikater som forekommer i flere av sertifikatkjedene legges bare ved én gang.

Figur 11: Illustrasjon av sertifikatkjeden

Under <xades:RevocationValues> legges det ved

• OCSP svaret for rekvirentens signeringssertifikat, inkludert fødselsnummer
• OCSP svaret for TSA tidsstemplingssertifikat

Eksempel 8: XAdES Revocation values

XAdES-A

Formålet med XAdES-A er å kunne holde X-L formen gyldig utover gyldighetsperioden til sertifikatene og valideringsdata i den. Bruken av XAdES-A er ikke forutsatt ved initiell implementering av SKO mellom partene i e-resept, men kan være aktuelt som en utvidelse senere. 

• Arkivtidstempelet signerer all XAdES-data og binder disse dermed uforanderlig til den opprinnelige signaturen.
• En XAdES-A signatur rommer vilkårlig mange arkivtidsstempel. Et nytt tidsstempel forlenger dermed gyldigheten til hele signaturen.

Arkivtidstempelet produserer ved hjelp av en TSA, jf. XAdES-T. NB Dette trenger ikke være samme TSA eller samme TS sertifikat som ble benyttet i SignatureTimestamp i XAdES-T.

I e-resept kan dette anvendes for å presentere en gyldig signatur til utleverer og Helfo selv i de tilfellene der

• både rekvirentens og TSAens (Reseptformidleren) sertifikater har enten gått ut på dato eller endret status.
• RF skifter virksomhetssertifikat.
• TSAens (Reseptformidleren) sertifikat som benyttes til SignatureTimestamp er gyldig i mindre enn ett år til.

Alle aktører kan legge til nye arkivtidsstempler ved behov over tid.

Eksempelet på neste side viser bruken av XAdES-A i XML.

Eksempel 9: XAdES-A