E-postiljon UNIVERSITAIRE ZIEKENHUIZEN LEUVEN. Informatiesystemen

Transcriptie

1 UNIVERSITAIRE ZIEKENHUIZEN LEUVEN Informatiesystemen E-postiljon Uitwisselen informatie via versleutelde en getekende elektronische post Versie 1.0 Maart 2005 Geert Touquet

2 1 Algemeen Een vlotte, en meestal volautomatische, gegevensuitwisseling tussen de UZLeuven en derde partijen, zoals lab s, andere ziekenhuizen en firma s, is onontbeerlijk. Het gebruik van het internet ligt hier voor de hand. Aangezien elektronische post ( ) een wijdverspreid medium is dat zijn degelijkheid ruimschoots bewezen heeft, is er geopteerd om dit als transportmiddel te gebruiken. Deze gegevensuitwisseling moet echter voldoen aan een aantal kwaliteitseisen, die de klassieke e- mail standaard niet biedt. Een klassieke moet beschouwd worden als een postkaart. Postkaarten kunnen, op hun weg tussen afzender en bestemmeling, door anderen gelezen worden, gewijzigd worden of vernietigd worden. De volgorde waarin de kaarten afgeleverd worden is niet noodzakelijk de volgorde waarin ze verstuurd worden. Gezien de gegevens die UZLeuven met derden uitwisselt, over het algemeen medisch van aard zijn, moet er voor gezorgd worden dat enkel de bestemmeling de berichten kan lezen. Bovendien moet de authenticiteit van de uitgewisselde gegevens gegarandeerd worden, zodat de inhoud niet betwistbaar is. Daarnaast moet ook de aflevering van de berichten, eventueel zelfs in een bepaalde volgorde, gegarandeerd worden. In dit document wordt beschreven hoe dit, door gebruik te maken van klassieke , gecombineerd met bestaande technieken, gerealiseerd wordt: er wordt gebruikt gemaakt van versleuteling, digitale handtekeningen, en genummerde en getekende bevestigingen van ontvangst. 1.1 Versleuteling: beveiliging tegen ongeoorloofd lezen van de gegevens Voor het versturen van geëncrypteerde (= versleutelde) s, maken we gebruik van S/MIME. S/MIME (Secure/Multipurpose Internet Mail Extensions) is een protocol dat digitale handtekeningen en encryptie toevoegt aan Internet MIME boodschappen. MIME is de officiële standaard voor het verzenden van niet-ascii-documenten via elektronische post. We gebruiken dan ook de S/MIME standaard voor het versturen van geëncrypteerde berichten. In de praktijk worden de bestanden als bijlage (attachment) verstuurd. Elke bestemmeling van een bericht creëert een private en een publieke sleutel. De private sleutel houdt hij geheim, en bewaart hij op een beveiligde plaats. De publieke sleutel wordt verspreid naar alle mogelijke afzenders van een bericht. De afzender encrypteert het bericht met de publieke sleutel van de bestemmeling. Decryptie kan alleen gebeuren door de afzender, met zijn publieke sleutel. Op deze manier is men er zeker van dat enkel de bestemmeling van het bericht, de boodschap kan lezen. Men moet er wel rekening mee houden dat enkel de inhoud en de bijlagen van het bericht ge-encrypteerd worden. Het onderwerp van de wordt niet mee geëncrypteerd. Aangezien zowat elke -client tegenwoordig S/MIME-berichten kan verwerken, kan dergelijk bericht door elke bestemmeling zonder problemen gelezen worden, als hij zijn -client toegang geeft tot zijn private sleutel. Iedereen kan met zijn -client dergelijke berichten versturen, mits hij over de publieke sleutel van de bestemmeling beschikt. 1.2 Digitale handtekening: beveiliging tegen wijziging van de originele gegevens S/MIME wordt ook gebruikt voor het plaatsen van een digitale handtekening op een bericht. Een digitale handtekening garandeert dat het bericht onderweg niet gewijzigd is. Hierdoor kan de ontvanger bewijzen dat hij bepaalde gegevens gekregen heeft van de afzender van het bericht. Deze bewijskracht is, gezien de gevoeligheid van de gegevens, noodzakelijk. Om berichten met een digitale handtekening te kunnen ontvangen, moet de ontvanger geen speciale actie ondernemen. De -client van de ontvanger zal de digitale handtekening automatisch verifiëren, en een foutmelding geven als de handtekening niet klopt. Normaal gezien wordt, bij het versturen van een digitaal gehandtekend bericht, automatisch de publieke sleutel van de verzender 4/10/2006 E-postiljon 1.1.doc 2/7

3 meegestuurd. De -client zal deze opslaan. Deze publieke sleutel kan dan later door de client gebruikt worden als er geëncrypteerde reply s verstuurd moeten worden. Het verzenden van een bericht met een digitale handtekening, vereist dat de -client toegang heeft tot de private sleutel van de zender. Bijna elke -client kan digitale handtekeningen plaatsen. 1.3 Genummerde berichten en bevestiging van ontvangst -servers doen hun uiterste best om -berichten af te leveren bij de bestemmeling. Als dat echter, na een aantal vergeefse pogingen niet lukt, worden de berichten verwijderd. Het is dus mogelijk dat door onvoorziene omstandigheden berichten verloren gaan. Om dit probleem op te lossen, wordt er verondersteld dat elk bericht in het onderwerp een uniek, oplopend nummer bevat. De nummering van de berichten laat toe om opeenvolgende berichten in de juiste volgorde te plaatsen, en het ontbreken van berichten te detecteren. Bij elk getekend bericht dat verstuurd wordt, wordt er een getekende bevestiging van ontvangst gevraagd. (zie RFC 2634) Deze getekende bevestigingen van ontvangst worden door elke recente e- mail-client automatisch gevraagd of gegenereerd. Speciale software hiervoor installeren is dus niet noodzakelijk. In de header van de ontvangstbevestiging wordt het onderwerp herhaald, zodat de oorspronkelijke zender van het bericht precies weet welk bericht ontvangen is. Indien de afzender binnen een bepaalde tijd geen ontvangstbevestiging krijgt, moet het oorspronkelijke bericht opnieuw verzonden worden, totdat uiteindelijk een ontvangstbevestiging ontvangen wordt. Het ontbreken van een ontvangstbericht kan veroorzaakt worden door 2 problemen: ofwel is het oorspronkelijke bericht niet ontvangen, zodat er geen ontvangstbericht verstuurd is, ofwel is het ontvangstbericht zelf verloren gegaan. Aan de ontvangende kant moet er dus mee rekening gehouden worden dat berichten meerdere keren kunnen ontvangen worden. De afzender van een bericht blijft dit bericht immers uitzenden, totdat hij een ontvangstbevestiging krijgt. Als de ontvanger met een gewone -client werkt, zal hij bij het openen van het bericht, van zijn -client de vraag krijgen of er een automatische ontvangstbevestiging gestuurd moet worden. Hierop bevestigend antwoorden, is voldoende om de ontvangstbevestiging naar de afzender van het bericht te sturen. Als de ontvangende kant detecteert dat er een bericht ontbreekt, moet deze geen actie ondernemen. Door het ontbreken van de ontvangstbevestiging, zal de zendende kant automatisch dit bericht na enige tijd opnieuw sturen. 1.4 Bijlagen De eigenlijke over te brengen gegevens zullen meegestuurd worden als bijlage. Per zending kunnen er zonodig meerdere bijlagen verstuurd worden. 2 Formaat van de berichten Hierbij onderscheiden we 2 soorten berichten: Het eigenlijke informatiebericht De ontvangsbevestiging 2.1 Informatie bericht Het informatie bericht is een opgesteld volgend de relevante RFC s Header De header van het informatiebericht is opgebouwd volgens RFC2821, waarbij we een paar extra specificaties hanteren. De header moet een Disposition-Notification-To header bevatten volgens RFC /10/2006 E-postiljon 1.1.doc 3/7

4 Het subject veld de informatie moet bevatten om dubbel aankomende berichten te elimineren, berichten die niet aankomen te detecteren en de volgorde van de berichten te kunnen herstellen. We gebruiken hierbij volgende afspraken: o Bij het eerste bericht is de header: Huidig:Nr<getal>_<datum>Vorig:null o Bij de voldende beirchten: Huidig: Nr<getal>_<datum>Vorig: Nr<getal>_<datum> waarbij <Datumuur> = DD-MM-YYYY HH:MM:SS.mmm Enkele voorbeelden: Subject: Huidig:Nr1_ :00: Vorig:null Subject: Huidig:Nr2_ :00: Vorig:Nr1_ :00: Subject: Huidig:Nr3_ :00: Vorig:Nr2_ :00: Body Het eigenlijke bericht (de Body ) is opgebouwd volgens de S/mime standaard met triple wrapping, zie RFC Het eigenlijke bericht is mime type multipart/mixed, waarbij Het eerste deel, de body van het bericht, van het type text/plain is. De inhoud van deze body is irrelevant voor de verwerking, maar het is toch aangewezen hier een zinvolle tekst in te plaatsen voor de situaties waarbij de correspondent een standaard software als interface gebruikt. Daarna volgen een of meerdere attachments, waarvan het mime type functie is van het type bericht. 2.2 De ontvangsbevestiging Hier worden 2 formaten voorzien: Een message disposition notification zoals voorzien in RFC 2298 Een gewone met als Subject veld [Re Gelezen] het onderwerp van het informatie bericht. De implementatie moet zodanig gemaakt zijn dat voor iedere communicatie tussen 2 partijen één van beide bevestigingsvormen gekozen wordt. 3 Voorbeeldimplementatie De UZLeuven ontwikkelen een java-programma dat kan gebruikt worden om berichten die verstuurd moeten worden automatisch te nummeren, te encrypteren, te handtekenen, af te leveren bij een smpt-server en opnieuw te versturen als geen ontvangstbevestiging gekregen wordt. Dit programma haalt ook ontvangen berichten op uit de mailbox, decrypteert ze, controleert de handtekening, verstuurt automatisch getekende ontvangstbevestigingen naar de afzender van het bericht, en plaatst de berichten in de juiste volgorde, indien nodig. Getekende berichten worden bijgehouden in een archief, zodat achteraf, met behulp van de handtekening, ontvangst en inhoud van de mail bewezen kan worden. De schijfruimte die ter beschikking gesteld moet worden van dit programma, is afhankelijk van de hoeveelheid gegevens die verstuurd, ontvangen, en gearchiveerd worden. Dit programma kan gebruikt worden als er een intensieve uitwisseling van berichten met UZLeuven is, die manuele verwerking met een gewone -client onpraktisch maakt. 3.1 Algemene beschrijving van de werking van het programma Dit programma is zodanig opgebouwd dat het verschillende toepassingen kan ondersteunen die, los van elkaar, deze manier van communiceren gebruiken. Er wordt verondersteld dat er, per 4/10/2006 E-postiljon 1.1.doc 4/7

5 applicatie, een -adres is dat als verzend-adres gebruikt wordt, en waar de ontvangstbevestigingen naar gestuurd worden. Indien er voor een applicatie data-berichten in 2 richtingen uitgewisseld worden, wordt dit -adres ook gebruikt voor ontvangst van databerichten, en als afzender van de ontvangstbevestigingen. Aan dit -adres moet een private sleutel en een certificaat verbonden worden. Dit certificaat kan verkregen worden bij een Certification Authority naar keuze. De gebruiker plaatst de te verzenden bestanden op de juiste plaats. Als de volgorde van belang is, wordt er verondersteld dat de alfabetische volgorde (bestanden met enkel getallen als bestandsnaam, worden opvolgend gesorteerd) de te versturen volgorde is. Het programma regelt de nummering van de berichten, de digitale handtekening, de encryptie en het versturen van de via het SMTP protocol. Het haalt, uit de mailbox van het -adres dat bij de applicatie hoort, automatisch de ontvangen bestanden op via het POP protocol. Indien het om ontvangstbevestigingen gaat, wordt het verstuurde bericht gearchiveerd. Indien het om een databericht gaat, wordt het gedecrypteerd en wordt de handtekening gecontroleerd. Indien er geen fouten opgetreden zijn, wordt het ontvangen bericht en zijn handtekening gearchiveerd, het ontvangen bericht in een mapje gezet waar de gebruiker het kan gaan ophalen, en wordt er automatisch een ontvangstbevestiging naar de afzender gestuurd. Als er ontvangen berichten ontbreken, worden volgende berichten die reeds ontvangen zijn, even apart gehouden zodat de verwerking in de correcte volgorde kan gebeuren. Als er verstuurde berichten zijn, waarvan binnen een te configureren termijn geen ontvangstbevestiging binnengekomen is, worden deze automatisch opnieuw verstuurd. Het programma controleert ook de geldigheid van de certificaten waarmee gewerkt werd, door regelmatig certificate revocation lists op te vragen bij de betrokken Certification Authorities. Indien berichten ontvangen worden die niet voldoen aan de specificaties, bijvoorbeeld spam-berichten of virussen, dan worden deze in een mapje apart geplaatst, waar de gebruiker ze kan gaan raadplegen. Het programma wordt zodanig ontwikkeld dat een bericht een gewoon bestand kan zijn, hetzij een directory met een aantal bestanden. In het laatste geval horen al deze bestanden samen en worden zij in 1 verstuurd. 3.2 Wat het programma niet doet Het programma verstuurt en ontvangt s. Het onderneemt echter geen enkele actie met betrekking tot de inhoud van de . Er wordt verondersteld dat de gebruiker de te versturen bestanden in het correcte formaat ter beschikking stelt van het programma door ze in de juiste map te plaatsen, en dat de gebruiker de ontvangen bestanden manueel of automatisch verwerkt. 3.3 Technische beschrijving van het gebruik en de werking van het programma Directory-structuur Hieronder volgt de directory-structuur, die het programma veronderstelt. <installatie-directory> <certificaten> <revokelists> <public_keys> <private_keys> <logging> <applicatienaam1> <INBOX_ERROR> <configuration> <data> < -adres1> INBOX OUTBOX RECEIVED 4/10/2006 E-postiljon 1.1.doc 5/7

6 SENT <yyyymm>.. <yyyymm>.. SENTNOACK SYSTEM INBOX_NOSEQUENCE < -adres2> <applicatienaam2> Het versturen van bestanden Foreach bestand in (alfabetisch gesorteerde bestanden in OUTBOX) { Bepaal nummer van het bestand Move bestand of directory naar SENT_NOACK while (bestand in SENT_NOACK waarvan ACK te laat is of nog niet verzonden) { Teken bestand encrypteer (getekend) bestand. Verstuur getekend en geëncrypteerd bestand naar smtp-host. De toepassing plaatst de bestanden in de outbox-directory van de bestemmeling(en). (<applicatienaam>\data\< -adresx>/outbox ) De toepassing plaatst de bestanden in alfabetische volgorde, als de volgorde van belang is. De toepassing bepaalt het volgend nummer. De toepassing verplaatst deze bestanden naar <applicatienaam>\data\< adres>\system\sentnoack\<nummer><vorignummer>. Het java-programma tekent, en encrypteert deze bestanden, en verstuurt deze als bijlage bij een . In het bericht wordt ook gevraagd om een getekende ontvangstbevestiging terug te sturen. Het getekend bericht wordt bewaard. Als de ontvangstbevestiging ontvangen wordt, wordt de data verplaatst naar<applicatienaam>\data\< -adres>\sent\yyyymm. Als binnen een geconfigureerde tijd geen ontvangstbevestiging ontvangen wordt, worden de bestanden in SENTNOACK opnieuw getekend en ge-encrypteerd- verstuurd naar de bestemmeling Het ontvangen van bestanden While (bestanden in mailbox) { If (bestand is ACK) { If (origineel bestand in SENT_NOACK gevonden) { Verplaats origineel bericht van SENT_NOACK naar SENT Bewaar ACK in SENT else { Bewaar ACK in INBOX_ERROR if (bestand is DATA-bericht) { if (DATA-bericht kan gedecrypteerd worden, en handtekening klopt) { plaats (klaartekst) DATA in INBOX_NOSEQUENCE plaats (getekende) DATA in RECEIVED stuur ACK naar afzender van het DATA-bericht else { bewaar DATA in INBOX_ERROR 4/10/2006 E-postiljon 1.1.doc 6/7

7 if (bestand is geen ACK en bestand is geen DATA-bericht) { verplaats bestand naar INBOX_ERROR while (bestanden in INBOX_NOSEQUENCE) { if (bestand met te_verwachten_nummer aanwezig) { verplaats bestand naar INBOX Het java-programma controleert voor elke applicatie de binnenkomende berichten. De gegevens van de pop-account (per applicatie) die hiervoor gebruikt moet, staan beschreven in de configuratiebestanden die zich bevinden in <applicatienaam>\<configuration>. Als er een databericht ontvangen wordt, wordt dit gedecrypteerd, wordt de handtekening geverifieerd en tijdelijk opgeslagen in de <applicatienaam>\data\< -adres>\system\inbox_nosequence directory, met als bestandsnaam het nummer dat aan het bericht is toegekend. Hierbij is adres het adres van diegene die het bericht verstuurd heeft! Een copie van het ontvangen bestand wordt, inclusief de ontvangen handtekening, archiveerd in <application>\data\< adres>\received, in een subdirectory per maand. Vervolgens wordt er door het programma een getekende ontvangstbevestiging teruggestuurd naar de afzender van het bericht. De bestanden die in INBOX_NOSEQUENCE staan, worden verplaatst naar <application>\data\< adres>\inbox zodra ze in goede volgorde staan. Als de volgorde van ontvangst niet van belang is, wordt dit aangeduid, per applicatie in het configuratie-bestand in de configuration-directory. Als er een ontvangstbevestiging ontvangen wordt, wordt het oorspronkelijke bericht uit <applicatienaam>\data\< -adres>\system\sentnoack gehaald, en gearchiveerd in <applicatienaam>\data\< -adres>\sent, in een subdirectory per maand, samen met de ontvangstbevestiging. De ontvangstbevestiging krijgt hetzelfde nummer als het oorspronkelijke bericht met _ACK toegevoegd. Bestanden die in de mailbox van de pop-account ontvangen worden, en die niet voldoen aan de specificaties (onderwerp niet in gepaste formaat, decryptie niet mogelijk, handtekening voldoet niet, onbekende afzender ) worden in <applicatienaam>\inbox_error geplaatst. 4/10/2006 E-postiljon 1.1.doc 7/7