Abo
  • IT-Karriere:

End-to-End: Google will mit Javascript verschlüsseln

Mit der Erweiterung End-to-End für Chrome will Google die Verschlüsselung per PGP erleichtern. Dazu wurde eine Kryptobibliothek für Javascript umgesetzt. Jetzt soll End-to-End rigoros getestet werden.

Artikel veröffentlicht am ,
Google entwicklet eine PGP-Erweiterung für Chrome samt Javascript-Bibliothek.
Google entwicklet eine PGP-Erweiterung für Chrome samt Javascript-Bibliothek. (Bild: Google/Screenshot: Golem.de)

Mit der Erweiterung End-to-End für den Browser Chrome will Google die Verschlüsselung per OpenPGP erleichtern. Damit soll sich künftig beispielsweise der Inhalt von E-Mails in Googles Gmail verschlüsseln lassen. End-to-End verlässt sich dabei auf eine eigens erstellte Javascript-Bibliothek, die ebenfalls von Google entwickelt wurde. Bislang warnen Experten jedoch vor einer Javascript-Krypto-Lösung. Jetzt hat Google End-to-End zum Testen freigegeben. Vor dem Einsatz der Erweiterung in Produktivumgebungen raten die Google-Entwickler zunächst jedoch vehement ab.

Stellenmarkt
  1. FLYERALARM Industrial Print GmbH, Dresden
  2. PSI AG Produkte und Systeme der Informationstechnologie, Berlin, Wil (Schweiz)

End-to-End soll in einer eigenen Sandbox im Chrome-Browser laufen. Erstellte private und öffentliche Schlüssel werden in einem eigenen Schlüsselbund gespeichert. Nur dieser ist mit dem Passwort abgesichert. Bereits vorhandene Schlüssel können importiert werden, sie werden nach einer einmaligen Passwortabfrage im Schlüsselbund gespeichert.

Mit elliptischen Kurven

Die Google-Entwickler hätten sich für ECC (Elliptic Curve Cryptography) entschieden, denn damit ließen sich Schlüsselpaare schneller generieren als mit dem RSA-Kryptosystem, heißt es in dem Blogeintrag. Da End-to-End selbst Schlüssel auf Basis von elliptischen Kurven erstellt, werden sie außerhalb von End-to-End nur von GnuPG ab Version 2.1 beta und Symantecs PGP-Software unterstützt. Der Import bereits vorhandener RSA-Schlüssel funktioniere aber uneingeschränkt.

Während der Browser läuft, werden private Schlüssel unverschlüsselt im Speicher gehalten. Da die Erweiterung aber in einer Sandbox laufe, seien sie dort sicher. Auf der Festplatte würden sie im Schlüsselbund verschlüsselt, daher sei es unabdingbar, den Schlüsselbund mit einer ausreichend starken Passphrase zu versehen, schreiben die Entwickler.

Eigene Javascript-Bibliothek

Bislang gilt Javascript als völlig ungeeignet, um ausreichend sicher zu verschlüsseln. Auf diese Einwände gehen die Entwickler in ihrem Blogposting ein. End-to-End benutze eine eigens von Google erstellte Javascript-Bibliothek, die ebenfalls zum Testen freigegeben wurde und später auch in anderen Projekten genutzt werden kann. Teile davon seien intern bereits seit längerem im Einsatz. Die Bibliothek unterstütze Ganzzahlen von beliebiger Größe (BigInteger), Kongruenz, elliptische Kurven sowie die Verschlüsselung symmetrischer und öffentlicher Schlüssel.

Auch auf mögliche Schwachstellen gehen die Entwickler ein: Das Risiko von Seitenkanalangriffen würde weitgehend minimiert, da End-to-End meist Eingaben vom Benutzer verlange. Die nur ganz wenigen automatischen Operationen würden zeitlich begrenzt. Außerdem würden die Kryptooperationen von End-to-End und dessen Javascript-Bibliothek in einem anderen Prozess ausgeführt als die Web-App, mit der sie interagieren.

Mögliche Angriffsszenarien berücksichtigt

Auch das Auslesen des Speichers sei durch die Sicherheitsfunktionen des Chrome-Browsers weitgehend unmöglich. Wer physischen Zugang zu einem Rechners des Opfers habe, dem stünden zahlreiche andere Möglichkeiten zur Verfügung, deshalb werde dieses Angriffsszenario nicht berücksichtigt, schreiben die Entwickler.

In Hinsicht auf mögliche Cross-Site-Scripting-Angriffe hätten die Entwickler beispielsweise Content Security Policy und strikte Closure Templates implementiert. End-to-End würde keinen unverschlüsselten DOMs von Webseiten vertrauen. Ohnehin sei die Interaktion zwischen der Erweiterung und Webseiten minimal.

Mit der Veröffentlichung der Javascript-Bibliothek und der Erweiterung leiten die Google-Entwickler jetzt eine öffentliche Prüfungsphase ein. Externe Entwickler würden für gefundene Bugs nach Googles Vulnerability Rewards Program entlohnt. Ihnen sei klar, dass eine neue OpenPGP-Lösung erst reifen müsse. Sie raten unbedingt davon ab, den existierenden Code bereits in eigenen Erweiterungen einzusetzen und im Chrome Web Store anzubieten. Damit würden nicht versierte Anwender wie Journalisten oder Aktivisten einer unnötigen Gefahr ausgesetzt.



Anzeige
Spiele-Angebote
  1. (-60%) 23,99€
  2. 2,99€
  3. 4,99€
  4. (u. a. FIFA 19, Battlefield V, Space Huilk Tactics, Rainbow Six Siege)

itbane 06. Jun 2014

Das ist einfach nur um openpgp platt zu machen - das kann nämlich keine ECs. Folglich...

zwergberg 04. Jun 2014

Da Javascript soll doch ausschlieich von lokal kommen, z.B. als Erweiterung, so...

luckyiam 04. Jun 2014

Ich bin bei der ganzen Diskussion immer noch der Meinung, dass die Bösen allein beim...

bluesummerz4 04. Jun 2014

AES 128bit, DH 1024bit und Whirlpool-Hash 512bit alles per javascript und kostenlos...

gehtDichNichtsAn 04. Jun 2014

ja im gegensatz zu trotteln, die nur scheiße labern, ist das extrem professionel. Es...


Folgen Sie uns
       


Snapdragon 850 - ARM64 vs Win32

Wir vergleichen native ARM64-Anwendungen mit ihren emulierten x86-Win32-Pendants unter Windows 10 on ARM.

Snapdragon 850 - ARM64 vs Win32 Video aufrufen
Probefahrt mit Mercedes EQC: Ein SUV mit viel Wumms und wenig Bodenfreiheit
Probefahrt mit Mercedes EQC
Ein SUV mit viel Wumms und wenig Bodenfreiheit

Mit dem EQC bietet nun auch Mercedes ein vollelektrisch angetriebenes SUV an. Golem.de hat auf einer Probefahrt getestet, ob das Elektroauto mit Audis E-Tron mithalten kann.
Ein Erfahrungsbericht von Friedhelm Greis

  1. Freightliner eCascadia Daimler bringt Elektro-Lkw mit 400 km Reichweite
  2. Mercedes-Sicherheitsstudie Mit der Lichtdusche gegen den Sekundenschlaf
  3. Elektro-SUV Produktion des Mercedes-Benz EQC beginnt

Google Maps: Karten brauchen Menschen statt Maschinen
Google Maps
Karten brauchen Menschen statt Maschinen

Wenn Karten nicht mehr von Menschen, sondern allein von Maschinen erstellt werden, erfinden diese U-Bahn-Linien, Hochhäuser im Nationalpark und unmögliche Routen. Ein kurze Liste zu den Grenzen der Automatisierung.
Von Sebastian Grüner

  1. Kartendienst Google bringt AR-Navigation und Reiseinformationen in Maps
  2. Maps Duckduckgo mit Kartendienst von Apple
  3. Google Maps zeigt Bikesharing in Berlin, Hamburg, Wien und Zürich

Arbeit: Hilfe für frustrierte ITler
Arbeit
Hilfe für frustrierte ITler

Viele ITler sind frustriert, weil ihre Führungskraft nichts vom Fach versteht und sie mit Ideen gegen Wände laufen. Doch nicht immer ist an der Situation nur die Führungskraft schuld. Denn oft verkaufen die ITler ihre Ideen einfach nicht gut genug.
Von Robert Meyer

  1. IT-Standorte Wie kann Leipzig Hypezig bleiben?
  2. IT-Fachkräftemangel Arbeit ohne Ende
  3. IT-Forensikerin Beweise sichern im Faradayschen Käfig

    •  /