E-Mail ist eines der am meisten verbreiteten Kommunikationsmedien des Internet. Der Transportweg einer E-Mail geht immer vom Clientrechner des Senders, per SMTP zum entsprechenden Mailserver, von dort ebenfalls per SMTP weiter an beliebig viele weitere Mailserver, bis er am Server der richtigen Domain angekommen ist. Der Empfänger lädt dann vom Server mit den Protokollen POP3 oder IMAP die Nachricht auf seinem Clientrechner herunter.

Das Simple Mail Transfer Protocol (SMTP) ist sehr alt (RFC821, 1982) und verfügt über keinerlei integrierte Authentifizierungsmethoden, um die Herkunft oder den Inhaber einer E-Mail-Adresse zu verifizieren. Hier ein Auszug der Kommunikation mit einem SMTP-Server.

user@localhost:~ > telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 localhost ESMTP Postfix (Debian/GNU)
> mail from: <richtigeemailadresse@spammer.org>
250 Ok
> rcpt to: <empfaenger@gmx.at>
250 Ok
data
354 End data with <CR><LF>.<CR><LF>
> From: <bundeskanzler@bka.at>
> To: <dieseadressegibtesgarnichtgmx.at>
> Subject: Hier steht der Betreff
>
> und hier beginnt der text
>
> .
250 Ok: queued as A530C2E2D94
> quit
221 Bye
Connection closed by foreign host.

Jede mit „>“ markierte Zeile zeigt den Input des Benutzers. Beim Versenden dieser E-Mail sieht man klar die Schwächen des SMTP-Protokolls. Die Angabe mail from enthält eine E-Mail-Adresse, die Fehlermeldungen empfangen soll. Diese ist nicht zwingend echt. Bei rcpt to wird der tatsächliche Empfänger der E-Mail angegeben. Nach der Angabe von data beginnt der eigentliche E-Mail-Teil, der zunächst noch mit dem E-Mail-Header weitergeht. Zuerst wird in der Zeile From: die Absenderadresse angegeben, welche im E-Mail-Programm des Empfängers aufscheinen soll. Danach kann nochmals eine Empfängeradresse angegeben werden, die der Empfänger als Empfängeradresse sieht, die für die eigentliche Zustellung der E-Mail keine Rolle spielt. Danach folgt noch der Betreff der E-Mail bevor der eigentliche Text des E-Mails beginnt.

Dieses Beispiel zeigt, wie einfach es ist, den Header einer E-Mail zu fälschen, weshalb diese Informationen nicht als Beweismittel herangezogen werden sollten.

E-Mail-Header

Bearbeiten

So kommt die E-Mail beim Empfänger an:

Return-Path: <richtigeemailadresse@spammer.org>
Received: from relay.isp.org (EHLO relay.isp.org) [1.2.3.4]
  by mx0.gmx.net (mx067) with SMTP; 25 Nov 2006 18:52:09 +0100
Received: from spam.house.spmmer.org ([1.2.3.4])
	by relay.isp.org (localhost [192.168.15.55])
	with ESMTP id DsCwaIMbp8Fg for <empfaenger@gmx.at>;
	Sat, 25 Nov 2006 18:52:02 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by spamhouse.spamer.org (Postfix) with ESMTP id 7B3FB2E2D8E
	for <empfaenger@gmx.at>; Sat, 25 Nov 2006 18:50:43 +0100 (CET)
Message-Id: <20061125175043.7B3FB2E2D8E@localhost>
Date: Sat, 25 Nov 2006 18:50:43 +0100 (CET)
From: <bundeskanzler@bka.at>
To: <dieseadressegibtesgarnicht@gmx.at>
Subject: Hier steht der Betreff

und hier beginnt der text

Die E-Mail beginnt mit dem Return-Path, welcher die E-Mail-Adresse enthält. Diese wird bei SMTP im Feld mail to: angegeben. Danach beginnen die Received-Zeilen. Jeder Mail-Server, welcher die E-Mail transportiert, trägt hier eine Zeile ein. Die Möglichkeit eines Mailservers den Eintrag gar nicht zu tätigen, Einträge zu löschen oder falsche Einträge anzufügen, lässt die Glaubwürdigkeit dieser Einträge schwinden. Die einzig verlässliche Zeile ist die letzte, da sie vom letzten (= eigenen) Mailserver stammt. Die unterste Received Zeile enthält also in der Regel den Mailserver, der die E-Mail als erster erhalten hat. Danach gibt es noch eine (vermutlich) eindeutige Message-Id, die in der Regel vom Mail-Programm oder vom ersten Mailserver erzeugt wird. Sie wird z.B. dazu verwendet zusammenhängende E-Mails zu erkennen. Danach gibt es noch eine Zeile Date, welche das Datum beinhaltet, das im E-Mail-Programm des Empfängers angezeigt wird. Dies kann ebenfalls durch den Absender gefälscht werden. Im oben gezeigten Fall wurde es durch einen Mailserver hinzugefügt. Danach beginnt der eigentliche Text des E-Mails wie er im SMT-Protokoll angegeben wurde.

Für eine Analyse der Echtheit einer E-Mail muss immer die komplette E-Mail inklusive der Header vorliegen, da nur die Absenderadresse alleine die Echtheit des E-Mails nicht beweist.

Digitale Signatur

Bearbeiten

Es zeigt sich, dass ein einfaches E-Mail keinerlei Möglichkeit bietet, zu verifizieren, von wem eine E-Mail wirklich gesendet wurde. Aus diesem Grund kann der Absender seine E-Mail digital signieren, und dem Empfänger eine Möglichkeit geben, zu überprüfen, dass die E-Mail tatsächlich vom Absender stammt. Bei der Verwendung einer Digitalen Signatur gibt es immer zwei verschiedene Schlüssel:

* privater Schlüssel: Mit Hilfe des privaten Schlüssels wird eine E-Mail signiert. Der private Schlüssel befindet sich im Besitz des Absenders bzw. (hoffentlich) rechtmäßigen Eigentümers einer E-Mail-Adresse.
* öffentlicher Schlüssel: Der öffentliche Schlüssel kann vom Eigentümer des privaten Schlüssels an beliebige Personen verteilt werden, welche seine signierten E-Mail lesen sollen.

Weiter ist wichtig, dass die Signatur als "sicher" gilt. Das bedeutet, dass eine als sicher anerkannte Verschlüsselungsmethode wie z.B. RSA verwendet werden soll, bei der auch der Schlüssel lang genug ist.

„Einfache“ digitale Signatur

Bearbeiten

Bei der „einfachen“ digitalen Signatur wird das so genannte „Web of Trust“ verwendet. Jeder kann einen Schlüssel zu einer beliebigen E-Mail-Adresse erstellen und auf einen Key-Server hinaufladen. Jeder kann den Schlüssel als vertrauenswürdig beglaubigen lassen und verwenden, um digital signierte E-Mails des Besitzers des privaten Schlüssels zu verifizieren. Je mehr Personen einen bestimmten Schlüssel als vertrauenswürdig bezeichnen, desto größer die Chance, dass der Schlüssel auch wirklich zu der angegeben E-Mail-Adresse gehört. Trotzdem sollte man sicherstellen, dass man den Schlüssel auch wirklich vertrauen kann, z.B. bei einem persönlichen Treffen oder auf einer so genannten Key-Signing-Party, auf der die anwesenden Personen gegenseitig ihre Schlüssel beglaubigen.

„Fortgeschrittene“ digitale Signatur

Bearbeiten

Die „fortgeschrittene“ digitale Signatur unterscheidet sich technisch nur unwesentlich von der „einfachen“ digitalen Signatur. Bei einer fortgeschritten digitalen Signatur wird der private Schlüssel in der Regel auf einer Chipkarte abgespeichert und nicht im Computer des Anwenders. Ebenso muss sich der Inhaber des privaten Schlüssels bei einer Zertifizierungsstelle (CA, Certificate Authority) persönlich beglaubigen lassen. In Österreich ist z.B. A-Trust eine öffentlich anerkannte Zertifizierungsstelle.

Lokal gespeicherte E-Mails

Bearbeiten

Lokal am Clientrechner gespeicherte E-Mails befinden sich meist im E-Mail Client eingebunden oder als *.eml oder manchmal auch als *.txt gespeichert am System. Diese E-Mails können jedoch nicht als Beweismittel verwendet werden, da nicht festgestellt werden kann, ob diese E-Mails jemals in dieser Form versandt oder empfangen wurden, da sie sehr einfach verändert werden können.