PrENV : Sikkerhet for kommunikasjon i helsevesenet. Del 2 : Sikre dataobjekter. Oversatt ved Kompetansesenter for IT i Helsevesenet

Transkript

1 PrENV : Sikkerhet for kommunikasjon i helsevesenet Del 2 : Sikre dataobjekter Oversatt ved Kompetansesenter for IT i Helsevesenet

2 Forord Denne Europeiske Prestandard ble forberedt av CEN/TC251 Helseinformatikk under et mandat gitt til CEN av EU-kommisjonen og den europeiske frihandelsorganisasjonen (EFTA). Denne flerdels standarden består av de følgende delene, under den generelle tittelen Sikkerhet for Kommunikasjon i Helsevesenet (SEC-COM): - prenv : Begreper og Terminologi - prenv : Sikre Dataobjekter - prenv : Sikre Datakanaler Denne standarden er designet er utført etter kravene fra Teknisk Rapport CEN/TC251/N Helseinformatikk Rammeverk for sikkerhetsbeskyttelse av kommunikasjon i helsesektoren. Denne standarden ble utformet i henhold til konvensjonene i ISO/IEC direktivet Del 3. Annexer A og B er normative, alle andre annexer er informative. MERK Annexer A og B er kopier av IETF standarder som forventes å bli ratifisert under høringsperioden for dette dokumentet. Introduksjon Bruk av dataprosessering og telekommunikasjon i helsesektoren må oppfølges med adekvate sikkerhetstiltak for å sikre datas konfidensialitet og integritet i overensstemmelse med det juridiske rammeverk for å beskytte pasienter så vel som profesjonell ansvarlighet og organisasjonelle verdier. I tillegg er det viktig å ta hensyn til tilgjengelighetsaspekter i flere systemer. Til dette formål har den tredelte Standarden som utgjør SEC-COM-serien (prenv : Konsepter og Terminologi; prenv : Sikre Dataobjekter; prenv : Sikre Datakanaler) til hensikt å forklare og detaljere for sluttbrukere i helsesektoren hvilke alternativer de må håndtere i form av sikkerhetstiltak som kan implementeres for å oppfylle deres sikkerhetsbehov og forpliktelser. Innbefattet i dette er standardiseringen av noen elementer relatert til prosessen med kommunikasjon av informasjon, når de faller innenfor sikkerhetsdomenet. I fortsettelsen av Rammeverk for Sikkerhetsbeskyttelse av kommunikasjon i helsesektoren (CEN/TC251/N98-110), heretter benevnt som Rammeverket, hvis CEN-rapport siktet mot å bidra til en bedre forståelse av sikkerhetsaspekter knyttet til IT-kommunikasjon i helsesektoren, skal denne Europeiske Prestandard hjelpe til å produsere systemer som tillater ansatte og applikasjoner i helsesektoren å kommunisere og samhandle sikkert, og derfor trygt, legitimt, lovlig og presist. SEC-COM-serien av standarder er nøkkelstandarder innen sikker kommunikasjon som kan benyttes generisk på en lang rekke kommunikasjonsprotokoller og informasjonssystemer relevant for helsesektoren, uten å være verken komplette eller uttømmende i denne forstand. Disse standardene må defineres innen sammenhengen og scenariene definert av arbeidsprogrammet til TC251, hvor meldingsparadigmet for samhandling mellom informasjonssystemer er en av de essensielle komponentene, som reflektert av Rammeverket. Denne del 2 av den europeiske Pre-standard for Sikkerhet for Kommunikasjon i Helsesektoren beskriver hvordan å sikre vilkårlige oktettstrenger som kan benyttes i europeisk helsesektor. En vilkårlig oktettstreng kan f.eks. være en EDIFACT-melding, en pasientjournal osv. Sikring innen begrepene inneholdt i denne europeiske prestandarden inkluderer bevaring av dataintegritet, bevaring av konfidensialitet og ansvarlighet i for av autentifisering av begge kommuniserende parter. Denne standarden spesifiserer ikke metoder relatert til tilgjengelighet, lagring eller transportering av data, nøkkelsertifikater eller andre infrastrukturelle aspekter som brukerautentifisering. MERK Denne standarden definerer en metodologi for å sikre oktettstrengen slik at den kan transporteres sikkert over usikre nettverk, uavhengig av det underliggende transportsystemet, f.eks. epost eller EDIsystem. Standarden omfatter mekanismer for kryptering og digital signatur, og vil tillate at disse mekanismene benyttes uavhengig. 1 Omfang Denne europeiske Prestandard definerer en standard for å sikre objekter i helsesektoren. Objektene sikres på en slik måte at de kan transporteres over åpne, usikrede nettverk eller lagres i åpne usikre oppbevaringssteder. En applikasjon er i stand til å avgjøre hvorvidt enhver kombinasjon av kryptering og digital signatur skal benyttes på et objekt Copyright reserved to CEN members 2 Ref. No. prenv

3 Generelt befatter denne europeisk prestandard seg ikke med objektenes innhold, men den kan benyttes på vilkårlige oktettstrenger. Denne europeiske prestandard baserer seg på eksisterende standarder. Denne europeiske prestandard befatter seg ikke med hvordan sikkerheten blir benyttet på objektene. En infrastruktur for sikkerhet antas å være til stede og kunne benyttes til å utføre sikkerhetsoperasjonene. 2 Normative referanser ISO 8824 Information technology - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1) (Version ) IETF S/MIME-CMS Cryptographic Message Syntax, INTERNET DRAFT draft-ietf-smime-cms-*.txt IETF S/MIME-MSG S/MIME version 3 Message Specification draft-ietf-msg-*.txt ISO Information Technology - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1) - Part 1: Specification of the base notation PKCS#7 Cryptographic Message Syntax Version 1.5, RFC 2315 MIXER-BPT Mapping between CCIT X.400 and RFC-822/MIME Message Bodies, RFC-2157 CCIT X.400 ITU Data Communication Networks: Message Handling Systems X Definisjoner 4 Symboler og forkortninger ASN.1 Abstract Syntax Notation version 1 DES Data Encryption Standard 3DES Triple DES EDI Electronic Data Interchange IETF Internet Engineering Task Force MIME Multimedia Internet Message Extensions MTA Mail Transport Agent PKCS#7 Public Key Cryptography Standard #7 RSA Rivest-Shamir-Adleman S/MIME Secure MIME SMTP Simple Mail Transfer Protocol UML Unified Modeling Language X.509 ITU OSI directory authentication framework 5 Krav til sikre dataobjekter 5.1 Oversikt data opphav overføring av sikkert dataobjekt data mottaker Figur 1 - Sikker kommunikasjon i helsesektoren Figur 1, et UML use case diagram [OMG ], er en representasjon av et opphav til data som sikrer og sørger for transport av et dataobjekt til en datamottaker og kan benytte enhver metode for transport av informasjonen fra sender til mottaker. En applikasjon (medisinsk system osv.) i overensstemmelse med denne europeiske Pre-standard skal benytte metodologien definert i seksjon 5 og 6 for å generere et sikret objekt. Formatet produsert med denne metodologien vil da være transportuavhengig, og kan overføres til mottakeren på ethvert konvensjonelt vis. Dette betyr at fra et epostperspektiv vil det sikrede dataobjektet regnes som en del av meldingskroppen. Epostsystemet kan inkludere kontrollinformasjon om dataobjektet, så som filnavn, filtype, beskrivelse osv. Videre kan en gateway eventuelt konvertere kontrollinformasjonen om dataobjektet. Hvis SMTP benyttes skal [MSG] benyttes til å kode dataene Copyright reserved to CEN members 3 Ref. No. prenv

4 Hvis X.400 benyttes skal den sikrede meldingskroppen kodes i henhold til [MIXER-BPT] Hvis andre epostsystemer benyttes skal samme tilnærming som for X.400 benyttes. 5.2 Sikkerhetsfunksjoner som tilbys Sikkerhetsfunksjonene som tilbys av Sikrede Data Objekter er: 1. Konfidensialitet: Forebygging av uautorisert avsløring av informasjon 2. Autentisering: (entitet/data opphav): Bekreftelse på at (en entitet/kilden til data) er som hevdet. Dette gjelder for både opphav og mottaker. 3. Integritet (data/meldingsinnhold): Den egenskap at data eller meldingsinnhold ikke har blitt endret eller ødelagt på en uatorisert måte. Et av de primære målene med denne prestandarden er å være i stand til å overføre sikker informasjon over heterogene nettverk, dvs. mellom parter som benytter ulike epostimplementasjoner og standarder. 5.3 Sikring av data helsevesen applikasjon sikkerhetstjenester 1: generere applikasjonsdata 2: valgfritt legge til applikasjonsheader 3: usikret data 4: sikring av dat 5: sikret data 6: valgfritt legge til applikasjonsseleksjonsheader Figur 2 - Prosessen med å sikre applikasjonsdata Figur 2, et UML sekvensdiagram, viser hvordan et objekt skapt av en applikasjon blir sikret (dvs. signert og/eller kryptert) ved bruk av denne prestandard. En applikasjon generer dataene som skal sikres. I tillegg kan headerinformasjon (som vil bli sikret) genereres. Denne headerinformasjonen er til bruk hos mottakersiden for å tolke dataene. Dette kan f.eks. benyttes for å avgjøre hvilket subsystem som har generert dataene, og dermed hvor den skal leveres. Hvordan disse headerene legges til ligger utenfor rammen til denne prestandaren. Sikkerhetsfunksjonen utføres, som behandler applikasjonsdata og applikasjonsheader som en ugjennomsiktig oktettstreng for kryptering (og/eller signering). Applikasjondataene blir så kryptert (og/eller signert), og chifferteksten genereres. Applikasjonsvalgheaderen legges så valgfritt til chifferteksten slik at mottakersystemet kan benytte denne til å avgjøre hvilken applikasjon som skal kalles for behandle de krypterte dataene. Internt genererer sikkerhetsfunksjonen nødvendige sikkerhetsheadere for å være i stand til å dekryptere på mottakersiden. Disse består av algoritmer, sertifikater osv., som definert av sikkerhetsimplementasjonen. Sikkerhetsfunksjonsheaderene regnes som en del av chifferteksten Copyright reserved to CEN members 4 Ref. No. prenv

5 De to separate informasjonselementene (applikasjonsvalgheader og chiffertekst) regnes sammen som dataelementet klart for transport, og kan transporteres til mottakeren på vilkårlig vis. 5.4 Avsikring av data Figur 3 viser hvordan et dataobjekt sikret av denne europeisk prestandard dekrypteres (og eller får sin signatur verifisert). Dette sekvensdiagrammet innbefatter elementer av EDI for å illustrere mekanismen som benyttes hvis denne muligheten velges. Først prosesserer mottakersystemet applikasjonsvalgsheaderen (hvis en er til stede) for å avgjøre hvilken applikasjon som skal kalles for å prosessere meldingen. Applikasjonen sender så de sikrede dataene til komponenten som håndterer sikkerhetstjenesten for dekryptering (og/eller signaturverifikasjon). Komponenten sender så klarteksten og resultatet av signaturverifikasjonen tilbake til applikasjonen. Applikasjonen prosesserer så klarteksten, som kan inkludere en applikasjonsheader. 5.5 Tilnærming til levering av sikkerhetsfunksjonalitet S/MIME versjon 3 CMS (Cryptographic Message Service) [CMS] er en revisjon av PKCS #7, en generisk ASN.1 [ISO 8824] spesifikasjon for metoder for kryptering og digitale signaturer. Denne europeiske prestandard spesifiserer bruk av CMS som distinkt fra bruk av S/MIME versjon 3 metodologien fordi denne prestandarden skal tillate meldingslevering over andre transportmekanismer enn SMTP, og over transportagenter som ikke støtter MIME. Det skal også være mulig å sende meldinger mellom SMTP epostsystemer og andre epostsystemer. 5.6 SMTP For SMTP og transportagenter som støtter MIME, skal S/MIME versjon 3 som definert i [MSG] benyttes for å kode det beskyttede dataobjektet. 5.7 X.400 Når X.400 [CCIT X.400] benyttes skal de følgende reglene benyttes, som definert i [MIXER-BPT]: 1. Hele CMS-meldingen skal sendes som en IA5 meldingskroppdel. 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 base64> <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 skal følge, og skal kodes i henhold til [CMS]. MERK En gateway som opptrer i overenstemmelse med MIXER (se [MIXER]) vil så være i stand til å konvertere innholdet til en S/MIME melding og omvendt. Hvis dataene kun er signert skal innholdstypen (Content-type) settes til application/pkcs7-signature. 5.8 Andre epostsystemer Andre epostsystemer skal benytte samme tilnærming som for X Kryptografiske algoritmer for bruk med S/MIME CMS For formålet til denne europeiske prestandard skal de følgende algoritmene benyttes i forbindelse med de sikkerhetstjenester som er definert i spesifikasjonen av IETF Crypto Message Syntax [CMS]. RSA signaturer og RSA algoritmen for nøkkelutveksling skal være de offentlig nøkkel-algoritmene som brukes med CMS. Algoritmen for meldingssammendrag (message digest algorithm) skal være SHA-1, og algoritmen for innholdskryptering skal være 3DES. 6.1 SammendragsAlgoritmeIdentifikator Sendende og mottagende agenter skal støtte SHA-1 [SHA1] Copyright reserved to CEN members 5 Ref. No. prenv

6 6.2 SignaturAlgoritmeIdentifikator Mottagende agenter skal støtte rsaencryption, definert i [PKCS-1]. Mottagende agenter skal støtte verifisering av signaturer vha. RSA. Sendende agenter skal støtte rsaencryption. Utgående meldinger er signert med en brukers private nøkkel. 6.3 NøkkelKrypteringsAlgoritmeIdentifikator Mottagende agenter skal støtte rsaencryption. Innkommende krypterte meldinger inneholder symmetriske nøkler som skal dekrypteres med en brukers private nøkkel. Sendende agenter skal støtte rsaencryption 6.4 Atributt SignerInfo Type Sendende agenter skal være i stand til å generere en instans av hver av de signerte attributtene signeringstid ( signing time ) og SMIME egenskaper ( SMIME capabilities ) i hver signerte melding sendt. 6.5 ISO objektidentifikatorer De følgende underparagrafer gir ISO objektidentifikatorer som skal benyttes for unikt å identifisere de nødvendige algoritmeidentifikatorene for å kode algoritmevalg innen chifferteksten produsert i henhold til denne europeiske prestandard. MERK De følgende ISO-identifikatorene er definert i ASN Krypteringsalgoritmer for innhold DES-EDE3-CBC OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) encryptionalgorithm(3) 7} For DES-CBC og DES-EDE3-CBC, skal parameteren kodes som: CBCParameter :: IV hvor IV ::= OCTET STRING -- 8 octets. 6.7 Algoritme for sammendrag sha-1 OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 26} 6.8 Algoritme for asymmetrisk kryptering rsaencryption OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1} 6.9 Algoritme for signatur sha-1withrsaencryption OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) Copyright reserved to CEN members 6 Ref. No. prenv