Beim Stöbern im Internet bin ich über mehrere Artikel gestolpert, die von Googles Plänen berichten, eine Ende-zu-Ende-Verschlüsselung für den Chrome Browser zu entwickeln.
So bin ich auch auf einen Artikel in Googles Security Blog gestoßen. Google schildert in diesem Blog die Absicht, eine „End-to-End“ Erweiterung für den Chrome Browser zu entwickeln, um die Benutzung von sicherer Ende-zu-Ende-Verschlüsselung für den Anwender zu vereinfachen.[1. Making end-to-end encryption easier to use (englisch)]
Die Chrome Erweiterung ist jedoch noch nicht erhältlich. Google hat in einem ersten Schritt den Quellcode der Erweiterung veröffentlicht, um ein Code-Review durch die Internet Community zu ermöglichen. Mit dieser Maßnahme möchte Google das Risiko von Fehlern und Schwachstellen im Quellcode minimieren und das Vertrauen in die Erweiterung stärken.
Auf jeden Fall ist dies ein Schritt in die richtige Richtung. Sind die heute verfügbaren Tools wie PGP oder GnuPG doch den meisten Anwendern zu kompliziert in der Anwendung.[2. Der steinige Weg zu Verschlüsselter Kommunikation]
Doch wird Google wohl auch noch einige Zweifel ausräumen müssen. Als US-Konzern unterliegt Google auch der US-Gerichtsbarkeit. Ich frage mich, ob die US-Behörden nicht etwas dagegen haben, wenn Google seinen Kunden eine sichere Kommunikationsverschlüsselung anbietet, welche den Inhalt von E-Mails auch vor den Augen neugieriger NSA-Agenten schützt.
Musste doch im vergangenen Jahr der E-Mail Anbieter Lavabit seinen Betrieb einstellen, da ihn US-Behörden mutmaßlich zur Entschlüsselung und Herausgabe von Kundendaten aufforderten. Warum sollte Google nicht ähnlicher Druck drohen, wenn sie nicht eine Hintertür für die Behörden offen lassen?[3. Heise Artikel zum Ende von Lavabit]
Google hat neben dem Blogpost auch eine Projektseite geschaltet, welche neben dem Quellcode auch einige FAQs bereit hält.[4. Google End-to-End (englisch)] Diesen ist zu entnehmen, dass die Erweiterung auf OpenPGP basiert, welches einen offenen und sicheren Standard darstellt. Nur ein einziger Abschnitt trübt die aufkommende optimistische Stimmung:
Are the private key(s) kept in memory, are they always purged after every operation, or is there a passphrase cache?
The private keys are kept in memory unencrypted. We recommend making sure your keyring has a passphrase so that private keys are stored encrypted in localStorage.
How safe are private keys in memory?
In memory, the private key is sandboxed by Chrome from other things. When private keys are in localStorage they’re not protected by Chrome’s sandbox, which is why we encrypt them there.
Please note that enabling Chrome’s „Automatically send usage statistics and crash reports to Google“ means that, in the event of a crash, parts of memory containing private key material might be sent to Google.
Auf Deutsch, öffnet man den Schlüsselbund durch Eingabe seiner Passphrase, wird der private Schlüssel in den Arbeitsspeicher geladen. Hat man in seinem Chrome Browser die Funktion aktiviert, automatisch Nutzungsstatistiken und Fehlerberichte an Google zu senden, könnte im Falle eines Browserabsturzes der private Schlüssel mit an Google übertragen werden. Wenn das passiert, bleibt nur das genutzte Schlüsselpaar zu sperren und sich ein Neues zu erstellen. Oder man schaltet von vornherein die Funktion zur Übermittlung von Nutzungsstatistiken und Fehlerberichten an Google ab.
Ob im Quellcode der End-to-End Erweiterung eine Funktion versteckt ist, um den privaten Schlüssel an Google oder einen dritten zu übermitteln, kann ein Code-Review durch die Community zeigen. Ob eine entsprechende Version im Chrome Browser selbst versteckt ist, wird hingegen nicht so schnell festzustellen sein, da der Quelltext nicht komplett offen liegt.
Ehrlich gesagt würde ich mich sicherer fühlen, wenn eine solche Funktion von einem Unternehmen entwickelt würde, das an deutsche Gesetze gebunden ist. Darum bin ich umso mehr gespannt, was die Community und Security-Experten zur neuen Erweiterung sagen. Ich bleib auf jeden Fall dran und halte euch auf dem Laufenden.