Krav til kommunikasjonssikkerhet

Transkript

1 Krav til kommunikasjonssikkerhet for EDI-løsninger Versjon januar 2002 KITH Rapport 04/02 ISBN

2 KITH-rapport Tittel Krav til kommunikasjonssikkerhet for EDI-løsninger Forfatter(e) Arnstein Vestad Oppdragsgiver(e) SHD Rapportnummer R 04/02 ISBN Godkjent av URL Dato Antall sider Kvalitetssikret av 30. januar Tor Olav Grøtan Kompetansesenter for IT i helsevesenet AS Postadresse Sukkerhuset 7489 Trondheim Besøksadresse Sverresgt 15, inng G Telefon Telefaks e-post firmapost@kith.no Foretaksnummer Prosjektkode S-SV-SDO Gradering Jacob Hygen Adm. direktør Sammendrag Rapporten beskriver krav til kommunikasjonssikkerhet for EDI-løsninger i helsevesenet. Det stilles krav til valg av krypteringsløsninger, digitale signaturer og algoritmevalg for disse. Videre gis det anbefalinger knyttet til bl.a. kvitteringer, loggføring og nøkkelhåndtering.

3 Innhold INNLEDNING... 1 KRAV TIL KOMMUNIKASJONSSIKKERHET... 3 Konfidensialitet 3 Opphavsautentisering 3 Ikke benekting av opphav og mottak 3 Kvitteringer 3 Kvitteringer for X Kvitteringer for SMTP...4 Nøkkeladministrasjon 4 Meldingsoverføring 5 Utvekslings- og overføringslogg 5 Utvekslingslogg (Juridisk logg)...5 Overføringslogg...6 Bruk av logg i tvister...6 Forholdet til avtaler...6 Adgangskontroll 7 Programpakker 7

4 KRAV TIL KOMMUNIKASJONSSIKKERHET FOR EDI- LØSNINGER Kapittel Innledning Retningslinjene som er definert i dette dokumentet er et minimum av mekanismer for kommunikasjonssikkerhet. Retningslinjene er fremkommet som et resultat av Sosial - og helsedepartementets Standardiseringsprogram for elektronisk informasjonsutveksling i helsevesenet, og er ment å erstatte retningslinjene gitt i Meldingshåndboken for elektronisk informasjonsutveksling i helse og trygdesektoren, KITH R4-94, versjon 2.1 fra mars Retningslinjene tilfredsstiller: a) Den europeiske standarden ENV : Secure Data Object b) De krav som er framkommet gjennom Standardiseringsprogrammet og konsensus i arbeidsgruppe 3. Retningslinjene som beskrives i det følgende bør benyttes som krav for hvilke sikkerhetsfunksjoner som en leverandør av kommunikasjonsløsninger for helsevesenet må kunne levere. Ved definering av disse retningslinjene er det ikke gjort forutsetninger om meldingsformat eller overføringsprotokoll. Standarden som refereres er ment å være format- og protokolluavhengig, og skal kunne sikre alle typer binære data. Sikringsmekanismene som skal benyttes er beskrevet i ENV Dette innebærer at meldingen skal pakkes inn vha. S/MIME versjon 3 CMS (Cryptographic Message Service). Algoritmene som skal benyttes er RSA signaturer og RSA nøkkelutveksling, SHA-1 for meldings-hash og 3DES for kryptering av meldingsinnholdet. Figuren på neste side viser hvordan standarden er tenkt benyttet for å sikre et objekt. En applikasjon genererer data som skal sikres samt eventuell headerinformasjon som kan benyttes av mottaker for å tolke dataene, f.eks. for å indikere hvilken applikasjon som har generert dataene. Sikkerhetstjenestene kalles så for å sikre dataene og headerinformasjonen. Sikkerhetstjenestene behandler dataene som skal krypteres (evt. signeres), og generer en chiffertekst. Eventuelle data for valg av applikasjon som skal behandle de krypterte dataene legges så til det sikrede objektet. De to informasjonselementene (data for valg av applikasjon og 1

5 INNLEDNING Helseapplikasjon sikkerhetstjenester 1: generer applikasjonsdata 2: evt. legge til applikasjonsheader 3: usikret data 4:sikre data 5: sikret data 6: evt. legge til data for applikasjonsvalg Figur 1 - Prosessen for å sikre applikasjonsdata chifferteksten) regnes sammen som objektet klargjort for overføring, og kan overføres på valgfri måte til mottakeren. 2

6 KRAV TIL KOMMUNIKASJONSSIKKERHET FOR EDI- LØSNINGER Krav til kommunikasjonssikkerhet Kapittel Dette kapittelet beskriver de konkrete krav og anbefalinger som gis for meldingssikkerhet for EDI-kommunikasjon i helsevesenet. Kravene er rettet mot konfidensialitet, autentisering og meldingsintegritet. I tillegg gis bl.a. anbefalinger om kvitteringer, loggføring og nøkkelhåndtering. Konfidensialitet Metoder for konfidensialitet gir mottakeren av en melding mulighet til å være sikker på at meldingen kom frem fra avsender uten at noen hadde mulighet til å lese og forstå den. For å oppnå konfidensialitet krypteres dataene for å gjøre det umulig å tolke dem. For kryptering av meldingsinnholdet skal krypteringsalgoritmen 3DES benyttes sammen med RSA for nøkkelutveksling. Opphavsautentisering Autentisering er en metode som gir mottakeren av en melding mulighet til å sjekke at meldingen virkelig kom fra den oppgitte avsender. Som for integritet sikres opphavsautentisering vha. digital signatur. Ikke benekting av opphav og mottak Benekting betyr at en part som har deltatt i en kommunikasjon med en annen part på et senere tidspunkt nekter for å ha deltatt i kommunikasjonen eller å ha sendt en påstått utveksling, evt. påstår at den er endret av mottaker. Ikke-benekting av opphav sikres vha. digitale signaturer. I tillegg vil logging av utvekslinger hos avsender og mottaker bidra til å skape sporbarhet i meldingsutvekslingen. Mekanismer for ikke-benekting av mottak spesifiseres ikke i denne omgang. Kvitteringer Kvitteringer kan bidra til å lette feilsøking og til å avdekke problemer med meldingsoverføringen. Mekanismene for kvitteringer på overføringsnivå (f.eks. X.400, SMTP, HTTP) varierer med protokoll, og det 3

7 KRAV TIL KOMMUNIKASJONSSIKKERHET stilles derfor ikke absolutte krav til kvitteringsløsninger. Det følgende kan derfor anses som anbefalinger for henholdsvis X.400 og SMTP. I tillegg kan kvitteringsmekanismer på applikasjonsnivå benyttes. Kvitteringer for X.400 For X.400 bør følgende X.400-tjenester tas i bruk og håndteres av applikasjonene: Avleveringskvittering ("delivery report/notification"). Ikke-avleveringskvittering ("non-delivery report/notification"). Kvitteringer for SMTP SMTP opererer i større grad enn X.400 med direkte kommunikasjon mellom avsender og mottakers e-postserver, og behovet for kvitteringer blir derfor mindre. Det er likevel definert to kvitteringstyper som bør vurderes brukt: Delivery Status Notification som definert i RFC 1894 (kvittering gis av MTA) Message Disposition Notification som definert i RFC 2298 (kvittering gis av UA) Nøkkeladministrasjon For offentlig nøkkel kryptering må alle kommunikasjonspartene kjenne hverandres offentlige nøkler. Siden de offentlige nøklene ikke skal være hemmelige kan de overføres i klartekst sammen med annen kommunikasjon eller kommuniseres via andre mekanismer. Dette forutsetter at nøklenes integritet beskyttes, noe som normalt sikres ved at nøklene signeres av en tiltrodd tredjepart (TTP), som dermed genererer et digitalt sertifikat. Partene må derfor være enige om en eller flere TTP er som de velger å ha tillit til, og rotsertifikatene fra disse TTP ene må installeres hos alle parter. En mulighet er også at en virksomhet selv velger å opptre som TTP og utstede sertifikater til eget bruk. Alle aktuelle samarbeidspartnere må da ha dette rotsertifikatet installert. For å erstatte eksisterende bilaterale utvekslinger hvor DES-nøkler har vært avtalt mellom to kommunikasjonsparter kan overnevnte løsning hvor en av partene påtar seg TTPfunksjonen benyttes, evt. kan selvsignerte sertifikater utveksles. Hver part må beskytte sin private nøkkel på en måte som både avsender, mottaker (og eventuelt TTP) finner tilfredsstillende, og kravene bør inkluderes i utvekslingsavtalen. For mer automatiserte løsninger kan nøkler lagres på harddisk mens for løsninger som krever en mer direkte knytting mellom konkrete individer og meldinger (f.eks. for å fylle lovbestemte krav om signaturer), bør den private nøkkelen lagres på et smartkort. 4

8 KRAV TIL KOMMUNIKASJONSSIKKERHET Det bør benyttes separate nøkkelpar for kryptering og for digital signatur. Videre bør revokeringslister eller online-protokoller for kontroll av sertifikatstatus som OCSP benyttes. Meldingsoverføring Sikkerhetskravene som defineres her legger ingen føringer for valg av overføringsprotokoll o.l. Hvis SMTP benyttes skal S/MIME versjon 3 benyttes for å kode det beskyttede objektet. Hvis X.400 benyttes skal de følgende regler følges, som definert i RFC 2157 Mapping between X.400 and RFC-822/MIME Message Bodies : 1. Hele CMS meldingen skal sendes som en IA5 body part. 2. De første bytes av innholdet skal være MIME-version: 1.0 Content-type: application/pkcs7-mime Content-transfer-encoding: <7bit, quoted-printable or base 64> <Possibly other Content headings here, terminated by \r\n> \r\n <Here follows the bytes of the content, encoded in the proper encoding> 3. Hele innholdet følger og skal kodes i henhold til CMS. Hvis dataene kun er signert skal innholdet settes til application/pkcs7- signature Dette gjør det mulig for en mixer-gateway mellom X.400 og SMTPsystemer å konvertere til en S/MIME-melding og omvendt. Andre e-postsystemer skal benytte samme tilnærming som X.400. Utvekslings- og overføringslogg Avsender og mottaker må bli enig om nødvendig loggføring. Som minstekrav bør det genereres en juridisk logg, i tillegg kan det genereres en overføringslogg, f.eks X.400-logg eller logg av SMTPoverføringer. Utvekslingslogg (Juridisk logg) Denne inneholder en fullstendig og kronologisk journal (juridisk logg) for lagring av alle meldinger og evt. kvitteringsmeldinger (f.eks. CONTRL-meldinger). For hver utveksling skal loggen minimum inneholde følgende dataelementer: Avsender Mottaker Komplett melding. Unik meldingsidentifikator. Tid for sending/mottak (dato og tid). 5

9 KRAV TIL KOMMUNIKASJONSSIKKERHET Utvekslingene forutsettes lagret dekryptert. Overføringslogg Overføringsloggen inneholder data om hendelser i forbindelse med overføring av utvekslingen. For hver hendelse kan loggen inneholde: Avsender Mottaker Unik meldingsidentifikator Tidspunkt meldingen ble sendt Tidspunkt hendelsen ble ført på loggen Status, f.eks: Innkommende melding (mottak). Utgående avleveringskvittering ("delivery report/notification"). Utgående ikke-avleveringskvittering ("non-delivery report/notification"). Innkommende avleveringskvittering ("delivery report/notification"). Innkommende ikke-avleveringskvittering ("non-delivery report/notification"). Bruk av logg i tvister Loggenes beviskraft vil avhenge av muligheten til i ettertid å endre de lagrede data og dermed vil sikkerheten rundt loggene ha juridisk betydning ved eventuelle tvister. Avsender og mottaker skal sikre seg at utvekslingene lagres på en slik måte at lagrede data sikres mot bevisst eller ubevisst sletting eller endring. Endringer bør derfor kun skje gjennom spesielt sikrede transaksjoner og funksjoner som logges av operativsystemet. For meldinger som er sikret med personidentifiserende, kvalifiserte sertifikater vil lov om elektronisk signatur m.v., gjeldende fra 1. juli 2001, være av betydning. Forholdet til avtaler Det forutsettes at kommunikasjonspartene har inngått en utvekslingsavtale som sier om det er avsenders eller mottakers logg som gjelder i hvilke tilfeller osv. I utvekslingsavtalen vil det også være mulig å fravike kravet om at begge parter skal føre logg. I så fall vil begge parter måtte stole på den part som fører logg. Det forutsettes også inngått en dokumentavtale for hver type elektronisk melding der lagringstid for juridisk logg og for evt. overføringslogg avtales. 6

10 KRAV TIL KOMMUNIKASJONSSIKKERHET Adgangskontroll EDI-systemet må ha rutiner for adgangskontroll som forhindrer at uautorisert brukere får tilgang til systemet eller lagrede data. Programpakker Sikkerhetsfunksjonene som er beskrevet i standarden er tilgjengelig i en rekke programmeringsbiblioteker, både fritt tilgjengelige og kommersielle. Noen utgaver er: S/MIME Freeware Library (SFL) et fritt tilgjengelig programvarebibliotek som implementerer IETF S/MIME v3 RFC 2630 Cryptographic Message Syntax (CMS) and RFC 2634 Enhanced Security Services (ESS) spesifikasjonene. Det implementerer også deler av RFC 2633 Message Specification and RFC 2632 Certificate Handling dokumentet. Tilgjengelig fra: OpenSSL-biblioteket Tilgjengelig fra: RSA B-SAFE programvarebibliotek tilgjengelig i C og Java. Tilgjengelig fra: Cryptlib c-bibliotek også tilgjengelig som ActiveX komponent. Tilgjengelig fra: Mozilla S/MIME toolkit c-bibliotek som skal inngå i nettleseren Mozilla open source versjonen av Netscape Communicator. Noe uferdig ennå, men tilgjengelig fra: Dette er et lite utvalg av mulige programbibliotek, og er ikke ment å signalisere preferanse for et spesielt bibliotek eller type bibliotek. Bibliotekenes egnethet og kvalitet garanteres heller ikke. For å sikre at de ulike løsningene fungerer sammen bør det utføres interoperabilitetstesting. Mer informasjon om dette finnes på web-siden til RSA s S/MIME Interoperability Center som finnes på url: 7