Patroon voor secure email: verschil tussen versies

Versie van 17 feb 2014 14:49

Deze pagina is een concept. Reacties via nora@ictu.nl of tekstvoorstellen in de wiki zijn welkom.

Onderdeel van: Thema's
Contact: Guus van den Berg; Guus.vandenberg@cip-overheid.nl
Status: Dit thema wordt momenteel opnieuw bekeken door de Expertgroep Beveiliging

Criteria

Vertrouwelijkheid, Integriteit

Context

Men wisselt e-mailberichten uit tussen verschillende organisaties of natuurlijke personen. Daarbij kan niet worden uitgegaan van een vertrouwd (toegangs)pad. Toch vraagt de inhoud van het bericht om een bepaald niveau van vertrouwelijkheid. Ook wil de zender dikwijls meer zekerheid hebben over het tijdig en goed afleveren van het bericht aan de juiste ontvanger.

Uitwisseling van elektronische berichten

Probleem

Tijdens transport van de e-mail tussen de verzender en de ontvanger vormen ongewenst inzien en aanpassingen van het e-mailbericht door een buitenstaander risico’s. De betrokkenen (zowel zender als ontvanger(s)) hebben geen enkele garantie dat een e mailbericht onderweg niet wordt ingezien door andere partijen (vertrouwelijkheid). Ook is er geen garantie dat het bericht door een buitenstaander niet gewijzigd is (integriteit). Een derde probleem is dat de afzender niet eenduidig kan bewijzen dat het bericht verstuurd is en wanneer het bericht de geadresseerde heeft bereikt. De onweerlegbaarheid van de verzending en van de aankomst van het bericht en de tijdstippen daarvan is normaliter niet geregeld.

Oplossing

De oplossing is het beveiligen van het bericht voordat het de vertrouwde omgeving verlaat. Hiervoor zijn drie standaard oplossingsrichtingen bekend:

Host-to-Host via het reguliere e-mailkanaal. Bij deze oplossing wordt een beveiligde verbinding opgezet tussen de mailservers van ketenpartners die beveiligde e-mail met elkaar willen uitwisselen. Daarvoor wordt TLS (Transport Layer Security) op de met elkaar communicerende mailservers geactiveerd, zodat een versleutelde verbinding door de mailserver kan worden opgezet met een andere host. De communicatie tussen mailserver en werkstation is echter niet versleuteld. Voor de beveiliging daarvan wordt vertrouwd op de genomen maatregelen voor beveiliging van het interne netwerk.
End-to-end via het reguliere e-mailkanaal. Bij deze oplossing blijft de e-mail over het hele traject tussen zender en ontvanger versleuteld. De afzender versleutelt het bericht. Het versleutelde bericht wordt naar de bestemming verstuurd. De geadresseerde ontsleutelt het bericht en heeft deze dan beschikbaar voor verwerking. Voordat men op deze manier mail kan uitwisselen met een communicatiepartner, moet er afstemming hebben plaatsgevonden over het uitwisselen van encryptiesleutels met elkaar.
End-to-end via een ‘secure host’. De communicatie vindt plaats via een vaste vertrouwde tussenpersoon (een computer). De verbinding tussen de afzender en de host wordt beveiligd evenals de verbinding tussen de geadresseerde(n) en de host. De dienstverlener houdt meestal een administratie bij over de aankomst van het bericht en wanneer welke geadresseerde het bericht heeft opgehaald, voor de afzender is informatie over zijn berichten veelal inzichtelijk.

Uitwerking Host-to-Host via het reguliere e-mailkanaal

Bij deze methode wordt het bericht versleuteld in de Mailhost zoals hieronder is geschetst. Het is de eenvoudigste oplossing, die kan worden benut door op zowel de zendende als ontvangende mailhost TLS te activeren. Dit blijft meestal beperkt door ‘een vinkje aan te zetten’.

Host-to-host e-mailbeveiliging met TLS

Het versturen van e-mail gaat voor de gebruiker op precies dezelfde manier als voor onversleutelde e-mail. De stappen zijn:

Zender stelt mail op.
De mailhost van afzender zet een TLS-sessie op met de mailhost van de ontvanger en verstuurt een versleuteld bericht.
Aan de ontvangstkant ontsleutelt de mailhost het bericht en stuurt het naar de Ontvanger.

Uitwerking End-to-End via het reguliere e-mailkanaal

Hiervoor is een versleutelde verbinding opgezet tussen werkstations en mailhost én tussen de mailhosts onderling. Daarbij kan gebruik worden gemaakt van een Public Key Infrastructure (PKI) of van clientspecifieke oplossingen, zolang de hele keten maar is versleuteld.

Het versturen van de e-mail gaat in de volgende stappen:

De afzender stelt met zijn standaard e-mailpakket het bericht op en selecteert de optie voor beveiligde verzending. Bij het versturen wordt het bericht voorzien van de noodzakelijke en/of gewenste bewerkingen (zoals ondertekening en/of versleuteling). #Het bericht wordt verwerkt op de interne e-mail server en gerouteerd naar de ontvanger. Wanneer het bericht is ontvangen op de mailserver van de ontvanger, wordt de beveiligde e-mail afgeleverd in de mailbox van de ontvanger.
De ontvanger opent het bericht, net als elk ander bericht, waarop het bericht wordt (al dan niet automatisch) ontsleuteld. De ontvanger ziet meestal duidelijk dat het hier gaat om een extra beveiligd bericht.

End-to-end e-mailbeveiliging

Uitwerking End-to-end via een externe ‘secure host’

Deze methode maakt gebruik van een serviceprovider ‘in the middle’. Het zenden en ontvangen van e-mail verloopt altijd via deze serviceprovider met de volgende processtappen:

De afzender zet een (beveiligde) verbinding op met de host. Hij deponeert het bericht inclusief de lijst van geadresseerden. Het bericht wordt beveiligd opgeslagen op een server van de host.
De host verstuurt een attentiebericht (reguliere e-mail) aan iedere geadresseerde met daarin de informatie dat er een bericht klaar staat.
De geadresseerde zet een (beveiligde) verbinding op met de host en krijgt het bericht beschikbaar voor lezen en verdere verwerking.
Het hostsysteem registreert de handelingen. Hij registreert de binnenkomst van de e-mail alsook welke geadresseerde het bericht wanneer heeft opgehaald.
De afzender vraagt de registratie op en ontvangt de registratie Hij weet nu wanneer welke geadresserden het bericht hebben opgehaald.

End-to-end e-mailbeveiliging via een secure host

Gebruikers van deze mailservice kunnen een automatische bevestiging krijgen, of de geadresseerde het bericht heeft opgehaald en wanneer dat gebeurde. De communicatie moet lopen via een vertrouwd toegangspad naar de host. Het authenticatiemechanisme moet van een zodanig niveau zijn, dat past bij de gewenste vertrouwelijkheid van de te versturen informatie. De host-based oplossing kan ook in eigen beheer uitgevoerd worden. Een organisatie beheert daarbij een server, waarbij de relaties van de organisatie de berichten kunnen ophalen.

Afwegingen

Voor alle methoden van beveiligde berichtenuitwisseling geldt dat de grensbeschermingen in de berichtenketen versleutelde berichten onverkort moeten kunnen doorlaten. Dit heeft als consequentie dat contentscanning op malware en virussen etc. niet centraal kan worden geregeld. Dit risico moet worden afgewogen tegen de voordelen van beveiligde mail. Per gekozen methode zijn verder de volgende punten van belang:

Via het reguliere e-mailkanaal

End-to-end. Voordeel van End-to-end is dat de mail beveiligd is tegen kwaadwillenden op het interne netwerk. Het nadeel is dat de mail versleuteld door de grensbescherming van een organisatie moet en er geen centrale screening op malware plaats kan vinden van het inkomende en het uitgaande verkeer.
Controle over het hele proces inclusief het verzenden en het bereiken van de geadresseerde kan via elektronische handtekening, die uitsluitsel geeft over de authenticiteit van het ontvangen bericht.

Host-to-host. Nadeel van TLS host-to-host oplossing is dat de gebruiker er niets van merkt wanneer onverhoopt een ontvangende mailhost niet voor TLS is geconfigureerd. De gebruiker heeft vanuit zijn perspectief dus geen zekerheid over de beveiliging van het transportkanaal voor zijn bericht.

Host-Based met service provider Voordeel van de Host-based oplossing is dat het e-mailproces volledig geregistreerd wordt. Men kan laten vastleggen door de host wanneer de mail verzonden is. Nadeel is het vertrouwen dat nodig is in de serviceprovider met bijkomende kosten voor audits etc. De kosten van de serviceprovider moeten worden afgewogen t.o.v. kosten van PKI-oplossingen.

Voorbeelden

Host-based e-mail komt voor bij verschillende banken. Banken hebben al een authenticatiemechanisme uitgerold voor hun cliënten voor elektronisch bankieren. Hetzelfde authenticatiemechanisme kan gebruikt worden voor secure e-mail. Er zijn Amerikaanse bedrijven die diensten aanbieden voor host-based e-mail.

Implicaties

De End-to-end methode via het reguliere e-mail kanaal vereist, dat de zender en de ontvanger over elkaars encryptiesleutels kunnen beschikken. Dit kan op meerdere manieren gebeuren, waaronder het onderling uitwisselen van sleutels via een beveiligd kanaal. Het uitwisselen van sleutels en het beheer ervan is arbeidsintensief en kostbaar bij grote aantallen communicatiepartners. Hierbij kan gebruik gemaakt worden van een PKI-infrastructuur, waarbij de afzender een publieke sleutel van de geadresseerde ophaalt en deze gebruikt om het bericht te versleutelen. Een andere oplossing is de sleutels rechtstreeks met de geadresseerde uit te wisselen. Dit moet via een ander vertrouwd kanaal gebeuren, bijvoorbeeld fysieke post met een tamper-proof enveloppe. De TLS host-host oplossing vereist dat alle mailservers die in de keten beveiligde berichten moeten uitwisselen zijn geconfigureerd voor TLS. Deze methode vereist aanvullende maatregelen om te zorgen dat gebruikers geen fouten maken met het mailen van gevoelige informatie via onbeschermd kanalen. De Host-Host met serviceprovider oplossing impliceert dat de serviceprovider vertrouwd wordt. Dit gaat zowel om het vertrouwen in de kwaliteit van het bewaren van de berichten, als in de kwaliteit van de authenticatieprocedures en –hulpmiddelen. De serviceprovider rekent een bedrag per verstuurd bericht. Met de serviceprovider moeten contractuele afspraken gemaakt worden over het beveiligingsniveau en het uitvoeren van interne en externe audits. Er moet ook een besluit genomen worden over de delen van het bericht die moet worden versleuteld: alleen de berichtbody, of ook de header met het subject. Voor TLS moet minimaal de versie 1.2 worden gebruikt in verband met zwakheden in vorige versies. NIST heeft een standaard uitgegeven die alle beveiligingsaspecten rond dit onderwerp bespreekt.

Gerelateerde patronen

Patroon voor public key infrastructure, te gebruiken voor het uitwisselen van encryptiesleutels en digitale ondertekening.
Patroon voor vertrouwd toegangspad, voor het maken van de verbinding met de host bij host-based secure e-mail.
Patroon voor elektronische handtekening voor ondertekening van e-mail via het reguliere kanaal.
Patroon voor logging, vastlegging van alle relevante gebeurtenissen in het systeem.

@@ Regel 1: / Regel 1: @@
 {{concept|}}
 {{Beveiligingspatronen
-|Realiseert=Berichtuitwisseling onweerlegbaar}}
+|Realiseert=Categorie:normen voor transactiefuncties}}
 ==Criteria==