BoringSSL und die FIPS 140-2 Zertifizierung

Vor inzwischen mehr als 3 Jahren verkündete Adam Langley in seinem Blog den Beginn der Arbeiten an BoringSSL, einem Fork von OpenSSL, der speziell auf die Anforderungen von Google zugeschnitten ist. Anlass waren die verschiedenen Probleme in SSL/TLS Implementierungen, insbesondere der Heartbleed Bug in OpenSSL, der damals für viel Aufsehen sorgte. Mit BoringSSL schuf Google sich eine bereinigte SSL/TLS Implementierung, die schon knapp ein Jahr später in die großen Google Produkte Chrome & Android einging und zum Betrieb der Google Services im Netz verwendet wurde. Für Google ist das Projekt offenbar ein Erfolg, da sie damit endlich eine einheitliche Basis für diesen sicherheitsrelevanten Code schaffen konnten, die sie nach eigenem Gutdünken weiterentwickeln können.

Ist BoringSSL eine Alternative?

Wer OpenSSL einsetzt, oder LibreSSL, den anderen damals entstandenen Fork, kann sich die Frage stellen ob ein Library, welches von Google entwickelt wird, vielleicht die bessere Alternative ist? ‘Besser‘ ist dabei ein Adjektiv mit mehreren Aspekten, darunter Rückwärtskompatibilität (mit OpenSSL), Stabilität, Sicherheit, Codereife, Funktionsumfang und Lizenzierung. Google stellt auf der BoringSSL Seite dazu diese Hinweise direkt an den Anfang:

“BoringSSL is a fork of OpenSSL that is designed to meet Google’s needs.

Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don’t recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.

Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.”

Das kann man nicht gerade als aktives Werben um neue NutzerInnen verstehen. In jedem Fall muss man damit rechnen einen gewissen ’Preis’ für die Nutzung eines leistungsfähigen, von einem hochkompetenten Entwicklerteam weiterentwickelten Pakets zu bezahlen, und zwar in Form vorzuhaltender eigener Entwicklerkapazitäten, damit man im Fall von Änderungen an BoringSSL in den eigenen Produkten entsprechend nachsteuern kann. Auf der anderen Seite ist heute das Risiko eines kompletten Refactorings von BoringSSL wohl eher gering, dazu ist selbst Google nicht mehr so ohne weiteres in der Lage angesichts von Millionen – oder gar Milliarden – von Android Geräten, die sich nur schwer aktualisieren lassen.

Seit ein paar Tagen gibt es eine neue Seite im BoringSSL Repository, die das Thema der FIPS Validierung behandelt. Dabei geht es nicht um das komplette Projekt, sondern um einen Teilbereich, genannt BoringCrypto. Dies könnte für Unternehmen, die nur entsprechend zertifizierte Produkte einsetzen dürfen (Finanzbereich, etc.), noch einmal einen Stolperstein bei der Nutzung beseitigen. Aber was ist FIPS 140-2 eigentlich und verbessert es wirklich die Sicherheit von BoringSSL?

Was ist FIPS 140-2 und was macht es ‘sicher’

Der ‘Federal Information Processing Standard (FIPS) Publication 140-2’ ist ein Standard der US Regierung, der – ausgeführt vom NIST – Anforderungen an kryptographische Module sowohl in Hardware wie auch Software definiert. Er legt damit verbindlich fest welche Anforderungen an entsprechende Module gestellt werden (z. B. in Form einer Liste der notwendigen/zulässigen kryptographischen Algorithmen) und auch das Verfahren, über das Anbieter entsprechender Produkte diese Zertifizierung erhalten können. Dabei wird in 4 Level unterschieden, die jeweils immer höhere Anforderungen stellen, z. B. in Bezug auf die Verhinderung bzw. Feststellung von Manipulationsversuchen.

Dieser Standard ist neben den Common Criteria wohl der wichtigste IT Sicherheitsstand weltweit. Eine FIPS Zertifizierung erhöht damit die Sicherheit eines Produkts in jedem Fall. Oder?

Die Snowden Enthüllungen

Eine Anforderung im FIPS Zertifizierungsprozess ist die Garantie, dass eine zertifizierte Software sich selbst auf Konsistenz prüfen kann. Siehe dazu im letzten Abschnitt mehr. Dies kann nur auf eine Weise erreicht werden, die man aus heutiger Sicht nicht mehr unbedingt als letzten Stand der sicherheitsbewussten Programmierung sehen muss. In der BoringSSL Seite zu FIPS findet sich daher an einer Stelle der Satz

‘This might make building ROP chains easier for an attacker, but so it goes.’

Ein weiterer Kritikpunkt – der z. B. in der entsprechenden OpenSSL Seite vorgebracht wird – ist die Langsamkeit des Zertifizierungsprozesses. Nun braucht eine sorgfältige Zertifizierung ihre Zeit, aber auf der anderen Seite ist es heute wichtiger denn je bei gefundenen Fehlern schnell Bugfixes verbreiten zu können. Denn selbst nach einer Zertifizierung ist es unwahrscheinlich, dass jeder einzelne Fehler gefunden wurde. Wenn aber eine Fehlerkorrektur dann eine erneute Zertifizierung erforderlich macht vergehen schnell mal einige Monate. In dieser Zeit haben Angreifer dann ausgerechnet in den Industrien mit besonderen Sicherheitsanforderungen, die zur Nutzung FIPS-zertifizierter Lösungen gezwungen sind, ggf. leichtes Spiel.

Ein letzter, massiver Kritikpunkt entsteht allerdings aus dem mit den Snowden Enthüllungen massiv gewachsenen Misstrauen gegen die US-Geheimdienste und ihre Verquickungen mit den Standardisierungsbehörden. Insbesondere betraf dieses Misstrauen damals einen in den Standard gebrachten Algorithmus zur Generierung von Zufallszahlen, der immer schon von Kryptographen misstrauisch beäugt worden war, sich nun aber als sehr wahrscheinlich mit einer bewusst konstruierten Hintertür versehen erwies. Durch die langsamen Standardisierungsprozesse war es dann ein sehr zeitaufwändiger Prozess diesen Algorithmus aus Produkten zu entfernen, bis dahin schlummerte er als potentielles Einfallstor in den als ‘sicher’ zertifizierten Produkten.

Insgesamt ist die Sache also ein zweischneidiges Schwert, und für EntwicklerInnen eines Libraries wie BoringSSL immer mit der Frage verbunden was ihnen wichtiger ist: Ein Produkt zu entwickeln, welches nach den bekannten Maßstäben der IT Sicherheit ganz vorne ist, oder zusätzlichen, teilweise bürokratischen Aufwand auf sich nehmen um am Ende bei einem möglicherweise in Teilaspekten weniger sicheren Produkt zu landen, welches dafür dann aber in besonders sicherheitsbedürftigen Bereichen eingesetzt werden – und dort vielleicht andere, weniger gut gepflegte Lösungen verdrängen – kann. Oder den Aufwand noch weiter zu erhöhen und parallele Stränge des eigenen Produkts zu pflegen, die beiden Anforderungen gerecht werden.

Wie macht man Software FIPS kompatibel

Aber nun wieder zurück zu der Frage welche Anforderungen eigentlich entstehen, wenn man eine C/C++ Programmierung mit den FIPS Vorgaben in Einklang bringen will?

‘FIPS-140 mandates that a module calculate an HMAC of its own code in a constructor function and compare the result to a known-good value. Typical code produced by a C compiler includes large numbers of relocations’

Wie man diesen Spagat löst, darüber geht der größere Teil der BoringSSL Seite und er erklärt auch recht gut wie ein C/C++ Compiler im Detail vorgeht und welche Dinge man ihm abgewöhnen muss, damit dieses Ziel erreichbar wird. Möglicherweise haben die Google Leute hier nur damit begonnen die Erfahrungen nachzuhalten, die sie entweder selbst gemacht haben oder große Android Nutzer wie Samsung (PDF), die auf BoringSSL basierende Komponenten bereits in den FIPS Prozess eingebracht haben.

Zwei Jahre Android Security Rewards – Was hat sich verändert?

Vor nun zwei Jahren hat Google mit den Android Security Rewards sein spezielles Bug-Bounty-Programm für Android gestartet. Kurz bevor mit den ersten Stagefright Sicherheitslücken die Kritik an der damaligen, desolaten Sicherheitslage Androids ein Allzeithoch erreichte. Im Android Entwicklerblog hat Google nun ein Fazit dazu gezogen, wie sich die Situation seit damals entwickelt hat. Der Post ist recht kurz, aber trotzdem in seinen Details interessant:

Android Update - Rot

Ein steter Strom von Bugreports

Man kann wohl sagen, dass dieses Bug-Bounty-Programm heute funktioniert: Im letzten Jahr sind mehr als 450 Reports eingegangen. Es vergeht damit wohl kaum ein Tag bei Google, an dem nicht eine Fehlermeldung eintrifft. Das ist zunächst einmal ein echter Erfolg, auch wenn daraus natürlich Schlagzeilen entstehen wie z. B. diese hier: „Android Was 2016’s Most Vulnerable Product.

Da Google den Android Quellcode im Android Open Source Project (AOSP) veröffentlicht kann sich hier faktisch jedeR an der Fehlersuche beteiligen und damit Geld und Anerkennung verdienen. Und tatsächlich tut dies eine große Zahl von Leuten.

In gewisser Weise bestätigt Android damit das von Open Source Verfechtern gern ins Feld geführte Argument, wonach die Offenheit auch gleichzeitig für eine bessere Sicherheit sorge, weil eben viele Menschen ohne große Hürden nach Fehlern suchen können. Auf der anderen Seite zeigt aber der Erfolg des Bug-Bounty-Programms auch was für ein wichtiger Faktor der finanzielle Anreiz sein kann. Dieser Anreiz fehlt bei vielen Open Source Projekten.

Mehr Geld, mehr Bugreports?

1,1 Millionen Dollar hat Google laut dem Bericht in den letzten 12 Monaten ausgeschüttet, was einer durchschnittlichen Summe von mehr als 10.000$ pro Sicherheitsforscher entspräche. Natürlich gibt es Personen / Gruppen, die durch besonders viele Meldungen herausstechen, Google selbst hebt hier das C0RE Team hervor, welches allein 118 Reports eingereicht und dafür 300.000$ erhalten hat.

Die höchsten Belohungsstufen wurden dabei aber bisher nicht erreicht, Google hebt diese Belohnungen nun auf das 4- bzw. 5-fache der bisherigen Werte. Damit könnte man nun 6-stellige Summen allein für einen einzigen Bugreport erhalten.

Google steht hier – wie heute alle großen IT Unternehmen – in starker Konkurrenz zu staatlichen Stellen aus aller Welt, die für ihre Geheimdienste nach ‚Cyberwaffen‘ Ausschau halten und sich dazu privater Dienstleister bedienen, für die die Suche nach Einbruchsmöglichkeiten in populäre Software zu einem profitablem Geschäft geworden ist. Hier kann man mit einem funktionierenden Exploit in das weltweit meistgenutzte Betriebssystem vermutlich noch weitaus höhere Gewinne erzielen.

Das ein hoher Belohnungspreis ein Bug-Bounty-Programm nicht automatisch erfolgreich machen muss hat der gescheiterte Versuch von Googles Project Zero gezeigt: Dieses wollte mit dem Project Zero Price ein eigenes Programm auf die Beine zu stellen, welches ebenfalls 6-stellige Summen für hochwertige Angriffe auf Android in Aussicht stellte. Es erhielt aber keine einzige relevante Einreichung und wurde wieder eingestellt.

Ein breiter aufgestelltes Programm wie die Android Security Rewards kann da durchaus erfolgreicher sein, auch wenn bzw. gerade weil seine Belohnungsstaffelung bei deutlich kleineren Summen beginnt: Dadurch erhöht sich die Zahl der beitragenden ForscherInnen und der Versuch einzelne Fehler zu horten, bis sie sich zu einem leistungsfähigeren Exploit kombinieren lassen, ist dann mit dem großen Risiko verbunden, dass jemand anderes einen der Fehler findet, die Belohnung erhält und Google die Lücke schließt.

Welche Geräte sind für sicherheitsbewusste Android NutzerInnen kaufbar?

Im Oktober 2015 – gezwungen durch das Stagefright Debakel – entschied sich Google einen lange überfälligen Schritt zu machen: Damals begann das Programm der monatlichen Android Sicherheitsupdates. Bis dahin gab es den absurden Zustand, in dem Google Meldungen über Sicherheitslücken zwar einsammelte, aber faktisch niemand zeitnah davon profitieren konnte. Durch die neuen Updates waren zuerst nur die direkt von Google kontrollierten Android Geräte wieder auf einem akzeptablen Sicherheitslevel, aber allmählich auch die Produkte einiger anderer Hersteller.

Android Upate

Und auch darüber gibt der aktuelle Blogpost Auskunft: Bei welchen Herstellern von Android Geräten ist meine Chance groß, dass diese zeitnah Sicherheitsupdates bekommen? Google sagt dabei zum einen dies:

Over 100 device models have a majority of their deployed devices running a security update from the last 90 days

Die dann gezeigte Tabelle mit konkreten Geräten lässt trotz ihrer etwas anderen Semantik (‚This table shows the models with a majority of deployed devices running a security update from the last two months‘) eigentlich nur einen Schluss zu: Wer keines der wenigen direkt von Google kommenden Gerät kaufen kann oder will, der sollte zu einem Samsung Gerät greifen. Samsung hat mit Abstand die größte Zahl von Geräten in dieser Liste und kann damit wohl als Vorbild bei der Updatepolitik gelten (wobei es hier wohlgemerkt nicht um Updates der Android Version geht, dass ist noch mal ein ganz anderes Thema).

Fazit: Auf dem richtigen Weg (aber der Weg ist noch weit)

Google ist es augenscheinlich gelungen ein lebendiges Umfeld von Sicherheitsforschern zu schaffen, die zur Android Sicherheit beitragen. Die ausgeschütteten Summen – auch wenn es sich dabei inzwischen um einen Millionenbetrag handelt – sind dabei vermutlich immer noch ‚günstig‘. Muss man das Fazit ziehen, dass Android angesichts der weiterhin hohen Zahl von monatlichen Fehlerkorrekturen besonders unsicher ist?

Das finde ich schwer zu beurteilen, auch andere (Betriebs-)Systeme haben durchaus ansehnliche Zahlen an korrigierten Fehlern vorzuweisen und faktisch ist jeder korrigierte Fehler einer weniger, den jemand anderes schon im Geheimen gefunden und ausgenutzt haben könnte. Nur falls auch in den kommenden Jahren die Zahl der in Android gefundenen Fehler so hoch bleibt wäre das ein sicheres Zeichen, dass mit der Codebasis bzw. der Weiterentwicklung etwas grundsätzlich nicht in Ordnung ist.

Weiterhin das größte Problem des Android Ökosystems ist aber das Fehlen von Updates für die Masse der inzwischen mehr als 2 Milliarden Geräte. Auch wenn Google die ‚mehr als 100 Modelle‘ nicht genau benennt, bei denen die Mehrheit der NutzerInnen wenigstens ein maximal 3 Monate altes Sicherheitslevel erreicht hat, kann man auf Grund der Vielzahl von Android Geräten – siehe die immer wieder gern zitierte Auswertung von OpenSignal aus dem Jahr 2015 – davon ausgehen, das dies nur ein Bruchteil der in aktiver Nutzung befindlichen Geräte ist.

Auch hier muss es die Zeit erst zeigen, ob die Seamless Updates, die mit Android N eingeführt wurden, und die in Android O mit dem Project Treble geplante stärkere Separierung von Betriebssystemteilen in der Lage sein werden eine signifikante Verbesserung zu bringen. Angesichts der gewohnt langsamen Ausbreitung neuer Android Versionen kann man von diesen Verbesserungen aber bestenfalls in einigen Jahren einen sichtbaren Effekt erwarten.

Bis dahin wird es wohl insbesondere den im Hintergrund von Google durchgeführten Prüfungen im Play Store und auf den Endgeräten überlassen bleiben Angriffe zu verhindert.

Google baut eine eigene Root-CA auf

Vor ein paar Tagen hat Google in seinem Security Blog bekannt gegeben selbst zu einer Zertifizierungsstelle (Certificate Authority / CA) zu werden. Diese kann man unter der Adresse https://pki.goog/ erreichen. CAs sind heute entscheidende Stellen in der Public Key Infrastructure (PKI) des Webs, die erst die sichere Kommunikation z. B. zwischen Webbrowser und Webserver ermöglichen.

Welches Problem will Google damit für sich lösen?

Google ist zum einen ein Unternehmen, welches einen enormen Bedarf an Zertifikaten hat, der durch zwei Faktoren bedingt wird:

  1. Die schiere Anzahl der zu sichernden Onlinedienste
  2. Googles schnelle Zertifikatsrotation, die Zertifikate heute nach 3 Monaten auslaufen lässt

Dann hat Google das Thema der IT Sicherheit wie kaum ein zweites Unternehmen im Blick und treibt es an allen Ecken voran, auch im Bereich der Zertifizierungsstellen. Gleichzeitig sind Google Zertifikate oft das Ziel bei Kompromittierungen von Zertifizierungsstellen, da Googles Dienste nun mal von vielen Nutzern besucht und damit für Angreifer besonders wichtig sind.

Google hat hier  in den letzten Jahren über seine Marktmacht mit Chrome als dominierendem Webbrowser und Android als dominierendem Mobilbetriebssystem immer mal wieder kräftig an den Zügeln gezogen, wenn eine CA Mist gebaut hat.

Was stimmt nicht mit mit dem heutigen System der Zertifizierungsstellen?

Das heute existierende System der Zertifizierungsstellen ist in der Lage unsere Webbrowser-Webserver-Kommunikation gegen massenhaftes Abhören zu sichern, wenigstens seit es Initiativen wie Let’s encrypt gibt, die Serverbetreibern die dazu notwendigen Zertifikate kostenfrei und mit geringem Aufwand automatisiert zur Verfügung stellen können. Die Verschlüsselung ist aber nur der eine Aspekt bei einer PKI: Der andere ist die Sicherstellung der Authentizität meines Kommunikationspartners. Damit ist gemeint, dass ich – wenn ich z. B. auf ‘https://www.google.com’ gehe – auch tatsächlich direkt auf einer zu Google gehörenden Webseite lande, und nicht auf einer gefälschten Seite bzw. über einen mithörenden Mittelsmann kommuniziere.

Hier kommen die CAs ins Spiel, die mir garantieren sollen, dass das Zertifikat, welches mir beim Besuch von google.com präsentiert wird, auch tatsächlich Google gehört. Eine CA kann dabei ihre Aufgabe nur erfüllen, wenn sie es schafft mit ihren Wurzelzertifikaten in die gängigen Webbrowser und Betriebssysteme aufgenommen zu werden. Damit ihr das gelingt muss sie ihre Sorgfalt bei der Vergabe von Zertifikaten beweisen.

So weit, so gut. Ein grundlegendes Problem ist dabei allerdings, dass mein Webbrowser danach zunächst jeder der mitgelieferten CAs uneingeschränkt vertraut. Dies sind im Firefox heute mehr als 150 Zertifikate von mehr als 50 Herausgebern und jedes Zertifikat – und sogar davon abgeleitete Unterzertifizierungsstellen – ist in der Lage ein ‘gültiges’ Zertifikat für google.com zu unterzeichnen. Natürlich muss so etwas immer mal wieder schief gehen, Beispiele siehe oben.

Google hat hier in den letzten Jahren in mehreren Schritten versucht diese Probleme zumindest teilweise in den Griff zu bekommen:

  • Certificate Pinning in Chrome: In Chrome ist ein kleines Set von CAs fest einkodiert, die prinzipiell für Google Zertifikate ausstellen könn(t)en. Dadurch hat sich Chrome in den vergangenen Jahren immer wieder als Melder von Verstößen gegen die Sicherheit oder die Regelungen von CAs erwiesen.
  • Dieser Ansatz ließ sich natürlich nicht auf das komplette Web skalieren, von Google kommt daher das inzwischen in einem RFC definierte HPKP, welcher aber noch nicht alle Browser unterstützen. Auch schützt es Benutzer nicht beim ersten Besuch einer Webseite.
  • Abkehr von SHA-1: Die Ablösung von SHA-1 als Signaturalgorithmus für Zertifikate wurde von Google besonders aggressiv vorangetrieben.
  • Certificate Transparency (CT): Dieses Projekt beschreibt wie ein endloses Logbuch aller jemals von CAs ausgegebenen Zertifikate effizient geführt und online zugreifbar gemacht werden kann. Es gibt eine Implementierung von Google, aber inzwischen auch von CAs. Certificate Transparency ermöglicht es Webseitenbetreibern gezielt zu prüfen ob für ihre Webseiten illegitime Zertifikate ausgestellt wurden.
  • Chrome und CT: Google hat für den Herbst 2017 angekündigt, dass Chrome beginnen wird bestimmte Zertifikate nur noch dann zu honorieren, wenn die Certificate Transparency verfügbar ist.

Google hat die CAs hier in den letzten Jahren teilweise vor sich hergetrieben und sich damit durchaus einiges an Kritik eingefangen. Für Google selbst ist der Aufbau einer eigenen CA vermutlich nur ein letzter Baustein in einem System, dass sie bereits mit einem Browser (Chrome), Betriebssystemen (Android, ChromeOS), Protokollen (SPDY und QUIC) und einigen der wichtigsten Internetdienste der Welt nahezu vollständig im Griff haben und weiterentwickeln möchten. Google schafft sich damit nun auch an dieser Stelle ein eigenes Experimentierfeld, in dem sie beweisen können, dass sich ihre Ideen für die Zukunft des Netzes in großem Maßstab umsetzen lassen.

Wird Google Zertifikate frei anbieten bzw. verkaufen?

Abgesehen vom Vorantreiben der Internetsicherheit wird Google seine PKI sicher in Zukunft mit anderen Diensten wie der Domänenregistrierung verknüpfen. Unklar ist allerdings ob sie tatsächlich zu einer CA werden wollen, die jedem Zertifikate anbietet.

Aus dem Policy Dokument der Google PKI kann man nach meinem Verständnis entnehmen, dass Google zumindest zur Zeit nicht mit kostenfreien Angeboten wie Let’s encrypt konkurrieren will. Ich lese das aus der Beschreibung des Verfahrens zur Überprüfung der Identität von Antragsstellern bei der Zertifikatsbeantragung. Hier gibt es u. a. einen Aspekt, der eine Überprüfung der postalischen Adresse fordert. Das ist ein über die Domänenvalidierung der Gratisdienste hinausgehender Schritt, der sich nicht voll automatisieren lässt.

Meine Vermutung ist daher, dass Google zumindest mittelfristig nicht mit den existierenden CAs in direkte Konkurrenz treten, sondern seine CA nur für die eigenen Dienste nutzen wird. Auch damit wird diese CA allerdings schnell zu einer der CAs werden, deren Zertifikate den größten Teil des Internetverkehrs sichern.

Wann werden die Google Root Zertifikate in Webbrowsern auftauchen?

Google selbst weist in seinem Blogpost darauf hin, dass es einige Zeit dauert die Wurzelzertifikate für eine neue CA zu verbreiten. Hier müssen zunächst die großen Browseranbieter überzeugt werden die Zertifikate aufzunehmen. Gleiches gilt für die Betriebssystemhersteller (praktischerweise in einigen Fällen die gleichen Unternehmen). Und es müssen noch viele andere Dinge wie die Updategeschwindigkeiten der jeweiligen Produkte bedacht werden. Vermutlich wird man die Zertifikate zuerst in den Google-eigenen Produkten wie Chrome, ChromeOS und Android finden können, auch wenn Google bei Mozilla den entsprechenden Prozess schon im letzten Dezember angestoßen hat.

Google ist allerdings nicht dafür bekannt Dinge, die sie unbedingt wollen, von den Zeitplänen anderer abhängig zu machen. Daher hat man zwei bereits in Browsern und Betriebssystemen vorhandene Wurzelzertifikate gekauft und kann mit diesen schon jetzt nach eigenem Gutdünken verfahren. Faktisch ist damit Google bereits zur Root CA geworden. Der vorherige Screenshot zeigt eines dieser Zertifikate in Chrome.

Was soll man von der ganzen Sache halten?

“You can now have a website secured by a certificate issued by a Google CA, hosted on Google web infrastructure, with a domain registered using Google Domains, resolved using Google Public DNS, going over Google Fiber, in Google Chrome on a Google Chromebook. Google has officially vertically integrated the Internet.” – aduffy, 27.01.2017 auf ycombinator

Auf ycombinator findet man eine sehr ausführliche und meist gute Diskussion zu der Frage welche Auswirkungen dieser Schritt hat. Natürlich gibt es viele, die das zitierte Szenario eines über alle Ebenen des Internets integrierten Konzerns für bedrohlich / monopolistisch halten. Andere stellen die Frage warum man Google eigentlich so viel Vertrauen entgegen bringen sollte um nun auch noch ihrer CA zu trauen?

Die zweite Frage ist dabei für mich die einfachere: Wenn ich von meinem Android Smartphone über eine Google Suche eine Seite im Chrome Browser öffne vertraue ich Google sowieso schon sehr, sehr weitgehend. Wenn Google dann auch noch die Zertifikate verantwortet, die wenigstens die Google Dienste schützen, fällt für mich eine Stelle weg, der ich bisher auch noch vertrauen musste (die zuvor verwendete CA). Das ist eine Verbesserung.

Die Frage der Machtkonzentration bzw. des Monopols ist da wohl eher eine Gefühlsfrage: Aus meiner Sicht hat Google das Thema der Internetsicherheit in den letzten Jahren sehr vorangebracht und ist dabei in schwierigen Fragen wie z. B. der Bestrafung von versagenden CAs mehr oder weniger auf der richtigen Seite geblieben. Mit einer eigenen CA kann Google im besten Fall demonstrieren wie eine leistungsfähige und sichere PKI aussehen kann. Ich sehe das Ganze also positiv.

Eine andere Frage ist vielleicht die, ob dadurch CAs verschwinden werden? Heute sehen sich die existierenden Zertifizierungsstellen am unteren Ende durch Let’s encrypt bedrängt, welches für viele Webdienste Zertifikate in vollkommen ausreichender Qualität bereitstellt. Am oberen Ende mag es in Zukunft eine Konkurrenz durch die Google CA geben, aber nicht ohne Grund haben viele Länder eigene CAs gegründet und werden die ganz unabhängig von einem Google Angebot betreiben. Wenn dafür einige der kleineren CAs, die möglicherweise Probleme damit haben einen seriösen Betrieb zu leisten, am Ende verschwinden, so ist das für die Sicherheit des Internets dann eher gut.

Die Stagefright Bugs: Das Beste, was der Android Sicherheit passieren konnte

Vor wenigen Tagen wurde ‘Stagefright 2.0’ bekannt, also die nächste Iteration der gefährlichen Fehler in Stagefright, der zentralen Mediaplayer Komponente des Android Betriebssystems. Warum soll das gut sein für die Sicherheit des weltweit meistgenutzten Betriebssystems?

Eine kurze Geschichte der Stagefright Bugs

Wir erinnern uns kurz: In den Wochen vor der Blackhat Konferenz Ende Juli begannen Gerüchte über einen schweren Fehler in Android zu kursieren. Der besondere mediale Reiz dieses Bugs war die Möglichkeit ihn über eine zugeschickte MMS auslösen zu können. Kombiniert mit dem damaligen Verhalten der Standard MMS Apps solche Inhalte ohne Zutun des Benutzers auszuführen hatte man ein mögliches Horrorszenario und Schlagzeilen wie ‘Eine Milliarde Android Geräte per MMS hackbar!’ waren die unvermeidliche Folge. Und der Name ‘Stagefright’ der betroffene Komponente lieferte auch gleich einen eingängigen Namen für das Problem.

Android Security

Unter dem hohen öffentlichen Druck zeigte sich—wieder einmal—das größte Problem des gigantisch gewordenen Android Ökosystems: Nur ein Teil der mehr als eine Milliarde aktiver Android Geräte bekommt Updates. In diesem Fall standen selbst die Besitzer der direkt von Google mit Updates versorgten Nexus Geräte genauso dumm da, denn obwohl Google den Fehler seit Monaten kannte war noch kein Patch offiziell verfügbar.

Wie konnte es so weit kommen?

Wie konnte ausgerechnet Google in diese Misere geraten? Hat Google mit dem Chrome Browser die automatischen, ohne Benutzerintervention stattfindenden Updates doch erst zum heutigen Standard gemacht und auch in fast allen späteren Produkten durchgesetzt: ChromeBooks, Android Wear Uhren, Chromecasts, OnHub Router, Android TVs, sie alle bekommen ihre Updates unmodifiziert direkt von Google und sind trotz Nutzerzahlen, die ebenfalls im Millionenbereich liegen, immer auf dem aktuellsten Stand. Selbst auf Android Geräten hat Google mit den Play Services einen Systemteil, der regelmäßig Updates erhält, sich selbst ohne Benutzerinteraktion aktuell hält und heute ein wesentliches Element von Googles Android Sicherheitsmanagement ist.

Das Problem beim Android Betriebssystem ist durch das komplizierte Verhältnis zwischen Google, dem Herrscher über die Android Weiterentwicklung, seinen Partnern wie Samsung, die die eigentlichen Geräte bauen und Android dafür modifizieren, und den Telekomanbietern, die noch einmal eigene Anpassungen von den Geräteherstellern verlangen, entstanden. Vermutlich hatte Google bisher die — berechtigte — Sorge, dass Veröffentlichungen von Fehlerkorrekturen im Android Open Source Projekt (AOSP) schnell von Angreifern untersucht und zum Bau von Angriffscode genutzt werden. Schneller, als die Gerätehersteller in der Lage oder Willens sind ihren Kunden Updates zu liefern.

In der Konsequenz konnten nicht einmal die Nexus Geräte Updates erhalten, da auch hier ein Reverse Engineering möglich wäre. Und so ist die Situation entstanden, die am Ende die ganze Android Welt ohne ein einziges Gerät mit einer wirklich nach aktuellem Wissenstand fehlerfreien Version dastehen lies.

Der Befreiungsschlag

Der durch die ersten Stagefright Fehler aufgebaute Druck hat Google schließlich dazu gebracht seine Strategie komplett zu ändern: Der auf der Blackhat Konferenz vortragende Google Sicherheitsmann Adrian Ludwig kündigte in seinem lesenswerten Vortrag an, dass es ab sofort monatliche Sicherheitsupdates für die Nexus Geräte geben werde, gefolgt von einer raschen Veröffentlichung der Fehlerkorrekturen im AOSP.

Ob Google dabei nun vom Druck getrieben wurde, oder ob man den Druck nutzte um auch bei Android eine Entwicklungsgeschwindigkeit zu erreichen, wie man sie in allen anderen Google Produkten kennt, wird man von außen vermutlich nie abschließend beurteilen können. In jedem Fall gibt Google den Druck damit an seine Partner weiter: Der Angriffsdruck auf alle Android Geräte, die keine aktuellen Patches erhalten, wird durch diese neue Linie mit Sicherheit steigen.

Mindestes den großen Herstellern, die auf Markenbildung, nachhaltige Kundenbeziehungen und den Einsatz ihrer Produkte in Unternehmen und Behörden setzen, kann so ein permanenter Kritikpunkt nicht gefallen.

Den Druck noch weiter erhöhen

Interessanterweise hat Google den Druck in den letzten Wochen noch einmal erhöht. Google selbst hatte mit seinem Project Zero angefangen andere Softwarehersteller mit einer 90 Tage Frist bis zur Veröffentlichung von Fehlern unter Druck zu setzen. Und musste sich prompt in Bezug auf Stagefright den Vorwurf gefallen lassen, bei seinen eigenen Produkten offensichtlich mit zweierlei Maß zu messen.

Nach der Strategieänderung hat das Project Zero nun auch Android Lücken öffentlich aufs Korn genommen und in einem Blogpost demonstriert, wie die zunächst dank Schutzmechanismen wie ASLR eher theoretisch erscheinende Ausnutzbarkeit eines bestimmten Stagefright Fehlers in einer Weise aufgerüstet werden kann, die sie in unmittelbare Nähe eines verlässlichen Exploits bringt.

Die Updates von Google kommen

Inzwischen ist das dritte Sicherheitsupdate an die Nexus Geräte ausgerollt werden, kurz bevor Android 6.0 ausgeliefert wird. Google hat hier also sein Versprechen gehalten. Wenn man sich die Liste der behobenen Fehler samt ihrer Kritikalität ansieht und weis, dass sie bald allgemein bekannt sein werden, kann man sich schon die Frage stellen ob man — trotz der zusätzlichen Schutzmaßnahmen, die Google im Play Store und den Play Services implementiert — jemandem ernsthaft dazu raten kann sich ein Nicht-Nexus-Gerät zuzulegen.

Den ersten Gewinn für die Android Sicherheit aus dem Stagefright Desaster haben wir damit: Es gibt nun mit den Nexus Geräten — die bald zwei schöne Hardwareupdates erhalten — eine Android Linie, bei der man von Google garantiert häufige Updates für alle bekanntgewordenen Sicherheitsprobleme bekommt.

Aber auch Custom ROM Anbieter wie Cyanogen haben nun die Chance über die schnelle Integration der AOSP Korrekturen ihre eigenen Versionen von Android aktuell zu halten. Damit haben wir den zweiten Gewinn: Wer kein Nexus Gerät hat oder haben will, aber ein Gerät, für das ein Custom ROM verfügbar ist, kann nun ebenfalls auf ein schnelles Schließen von Sicherheitslücken hoffen.

Wann kommen die Updates von den Geräteherstellern?

Trotzdem hatte die Masse der Android Nutzer bisher noch keinen unmittelbaren Vorteil von diesen Entwicklungen, auch wenn einige Gerätehersteller nach den ersten Stagefright Lücken schon Updates ausgerollt hatten. Hier kann man aber hoffen, dass das nun durch die Nexus Updates monatlich aufflackernde Sicherheitsthema dafür sorgt, dass der Druck auf die Hersteller und Telekomunternehmen nicht nachlässt. Am Ende kann hier eigentlich nur die Einsicht stehen, dass die Möglichkeit schnell und häufig Updates an die Geräte der Kunden zu geben ein eigenes Qualitätsmerkmal ist, mit dem sich werben lässt.

Wenn dieser Status — wenigstens für die Flaggschiffgeräte der großen Hersteller — erreicht worden ist, dann haben wir den dritten und entscheidenden Gewinn aus den Stagefright Lücken gezogen. Ein Gewinn, der sich im verwickelten Android Ökosystem offenbar erst mit dem enormen Druck, den die Stagefright Probleme ausgelöst haben, realisieren liess.

Und falls dies auch dazu führt, dass die im Zeitalter des Material Design oft klobig und unelegant wirkenden ‘Verbesserungen’ der Gerätehersteller am Android System zurückgefahren werden, so kann man dies nur begrüßen.

Notizen zur Google I/O 2015

Gestern begann die Entwicklerkonferenz von Google und wie in jedem Jahr ist die Keynote der Auftakt und in gewisser Weise auch der Höhepunkt der Veranstaltung, jedenfalls von außen gesehen. Hier präsentiert eines der wichtigsten Technologieunternehmen der Welt seinen Stand, seine Produkte und seine Visionen für die nahe und ferne Zukunft. Das sind meine Notizen, ohne Anspruch jedes Detail abzudecken:

Google I/O 2015

Google als KI Unternehmen

Am Anfang der Keynote sprach Sundar Pichai eine kurze Zeit von den Fortschritten beim maschinellen Lernen, die Google im vergangenen Jahr gemacht hat. Ein Schlüsselkonzept sind dabei tiefgestaffelte, neuronale Netze, bei denen die verschiedenen Ebenen unterschiedliche Aspekte der gestellten Aufgabe lernen. Auch wenn das Thema nur vergleichsweise kurz und zeitlich deutlich getrennt von der heute am besten sichtbaren Anwendung (Google Photos) präsentiert wurde: Das ist das Thema, welches heute — oder immer schon — im Kern von Google steckt und mit dem offenbar schnelle und überraschende Fortschritte möglich sind. Beispiel die Spracheingabe bei der Google Suche, deren Fehlerrate innerhalb des letzten Jahres auf diese Weise deutlich verringert werden konnte.

Android M

Das Rechtemodell geht mehr in Richtung iOS: Rechte werden in größeren Gruppen gebündelt; Rechte werden (zumindest teilweise) erst bei der ersten Verwendung abgefragt; Können später wieder entzogen werden und lassen sich sowohl per App wie auch per Recht betrachten und bearbeiten. Sicher die größte Änderung am Rechtemodell, die es in Android jemals gab. Die Entwickler wurde damit geködert, dass Nutzer Apps dann schneller installieren (da keine vorherige Rechteabfrage mehr erfolgt) und auch bei Updates, in denen mehr Rechte verlangt werden, nicht mehr zögern.

Viel Herumreiten darauf, dass man sich in M auf Qualitätsverbesserung konzentriert habe. Vermutlich ein Eingeständnis, dass Lillipop ziemlicher Müll war, was die Softwarequalität angeht.

Google Now wird immer schlauer (und übergreifender)

Google baut seine bisher ziemlich einzigartige Now Funktion noch stärker aus und zwar nicht nur in der schon bekannten Weise, in der einem Informationen proaktiv angeboten werden. Mit Now on Tap kann man die Funktion in Android M dazu veranlassen, die von der gerade offenen App gezeigten Inhalte zu interpretieren und einem geeignete Funktionen und Informationen anzubieten. Hier legt Google also ein eigenes Layer über potentiell alle Apps. Ob die App Anbieter etwas dazu tun müssen ist nicht ganz klar geworden (vermutlich nicht), dagegen wehren können sich aber bestimmt nicht. Wenn das so funktioniert, wie sich Google das vorstellt, bekommt die Google Suche über Now wieder eine ganz neue Funktion und Wichtigkeit und kann das händische Hin- und Herspringen zwischen Apps weitgehend beenden.

Chrome custom tabs

Google arbeitet weiter an der möglichst nahtlosen Verschmelzung von Apps und Webinhalten. Ein neuer Weg sind die custom tabs, die Apps in Chrome öffnen können. Dabei wird ein Webinhalt zwar außerhalb der aufrufenden App in Chrome geöffnet, aber die App ist in der Lage einen Teil ihres Brandings und auch ihrer Funktionen an Chrome zu übermitteln. Damit entsteht für Entwickler ein dritter Weg neben der einfachen Verlinkung und dem Aufbau eines eigenen, internen Browsers über eine Webview. Frage ist für mich aber, in wie weit das andere Browser wie Firefox ausschließt?

Android Pay

Das Google Wallet wird zu Android Pay und wird sich dann auch in den eigenen Apps verwenden lassen. Zusammen mit der neuen Fingerabdrucksensor API, die Android M bringt, macht dies den Eindruck, dass Google hier stark Apple Pay nacheifert. Aber hier in Europa wird davon wohl auf absehbare Zeit nicht viel ankommen.

Brillo und Weave: Googles Lösung für das Internet der Dinge

IoT ist gerade wieder aktuell und tatsächlich kommen ja auch jede Menge Produkte auf den Markt, die irgendwie ‘intelligent’ sind, die sich aber in jedem Fall vernetzen wollen. Und deren komplexe Funktionen von außen gesteuert werden wollen.

Google bietet mit Brillo nun ein abgespecktes Betriebssystem, welches von Android abgeleitet ist und daher bestimmte Funktionen wie Netzwerkstacks erben kann. Interessanter ist aber vielleicht aus Nutzersicht Weave, welches ein Protokoll ist, über das sich IoT Devices und die sie steuernden Geräte wie Smartphones austauschen können. So soll man offenbar mit einer einzigen Weave App auf seinem Smartphone alle entsprechenden Geräte steuern können, die dort ihre Fähigkeiten darstellen.

Wird Google hier etwas schaffen, was quasi schon jeder große Softwarehersteller in den letzten Jahren irgendwie mal versucht hat, aber bisher noch nie so richtig geklappt hat?

Google Photos

Für mich der interessanteste Punkt dieser Keynote: Die Kernideen, die ich an einem Fotodienst in der Cloud am meisten benötige, werden umgesetzt. Google bietet sich als verlässlicher Speicherdienst für ‘lebenslange’ Fotoarchivierungen an. Nun weis niemand, ob es Google in 20 oder 30 Jahren noch gibt und wenn ja, welche Ziele das Unternehmen dann verfolgt. Trotzdem ist das die Zusage, die man von seinem Cloud Anbieter hören will und sie muss sich glaubwürdig anhören. Ich fand sie glaubwürdig, vor allem, da sie von einer weitgehenden Aufhebung der bisherigen Beschränkungen / Grenzen beim gratis zur Verfügung gestellten Speichervolumen begleitet wurde.

Natürlich will man die Bilder immer auf allen Geräten verfügbar haben. Hier gibt es sowohl in der neuen App wie auch in der Webdarstellung einige coole Interfaceideen und neue Gesten, die einem den Umgang mit seinen Bildmassen deutlich zu vereinfachen scheinen. Und schließlich die Suche und Gruppierung: Hier treten die Verbesserungen in der Bilderkennung durch das maschinelle Lernen klar zutage, Google kann inzwischen ein weites Feld von Begriffen / Dingen in Bildern erkennen und kategorisieren.

Das klappt nicht zu 100%, aber das ist auch nicht entscheidend: Zum einen wird sich dies weiter verbessern, zum anderen reicht es mir wenn die Suche nach ‘Pferd’ mir Bilder von Pferden zeigt, ein paar falsch klassifizierte Hundebilder sind da egal. Auf diese Weise kann man in den Datenhalden, die man in den vergangenen Jahren angehäuft hat, endlich wieder schnell die Bilder finden, die man gerade sucht, und das ohne aufwändige Verschlagwortung oder manuelle Einsortierung in irgendwelche Ordner.

Die neue App kam unmittelbar nach der Keynote an, so dass man gleich damit herumspielen konnte.

Cardboard und Jump

Die Papp-3D-Brille von der letzten Google I/O nahm einen überraschend großen Teil der I/O in Anspruch: Google nimmt die Sache, die zuerst wie ein Gimmick erschien, offenbar weiterhin sehr ernst. So gibt es nun eine Neuauflage, die auch große Smartphones aufnehmen kann und mit dem iPhone zusammenarbeitet, und ein merkwürdiges, ergänzendes Produkt: Jump.

Jump ist ein Weg um mit Hilfe von Google 360 Grad Videos erstellen, verarbeiten und veröffentlichen zu können und damit ein Lieferant für Inhalte, die Cardboard oder andere VR Lösungen erst interessant machen. Jump hat drei Bestandteile: Das erste ist im Grunde nur ein Bauplan, den Google zur Verfügung stellt, und der beschreibt wie man 16 Kameras anzuordnen hat, damit deren gleichzeitige Aufnahmen ein 360 Grad Bild ergeben und die spätere Verarbeitung möglich wird. GoPro wird schon ein fertiges Gerät anbieten, aber offenbar könnte sich im Prinzip jeder so etwas zusammenbauen. Google wird z. B. Steuerungsdateien für 3D Drucker veröffentlichen, die den Halter für die Kameras erzeugen.

Danach kommt die Verarbeitung: Aus den 16 Kamerafeeds muss eine 360 Grad Aufnahme samt Tiefeninformation und allen möglichen Blickpunkten synthetisiert werden. Hier bringt Google seine riesigen Rechenzentren ein, die diese Arbeit übernehmen sollen, und die Algorithmen, die all die komplizierten Transformationen durchführen. Schließlich muss das Endprodukt irgendwo abrufbar werden. Dazu dient natürlich YouTube und die entsprechenden Apps, die man dann in Cardboard nutzen kann.

In der Keynote wurde als denkbares Einsatzszenario der Schulbereich genannt, so könnte eine Klasse auf diese Weise tatsächlich zwischen den Gletschern in Grönland umherwandern, an statt sich nur eine flache Projektion anzusehen (aber wer bezahlt die teuren Smartphones?).

Zahlen, Zahlen, Zahlen

Viele Produkte wurde nur gestreift, dafür dann aber mit Zahlen um sich geworfen: 17 Millionen Chromecasts verkauft, für die 1,5 Milliarden Mal der Cast Button angeworfen wurde; eine Milliarde täglicher Android Nutzer; 1 Million Cardboards; so und so viele Android Wear Watches und Watchfaces; so und so viele Autohersteller, die bei Android Auto mitmachen; 50 Milliarden App Downloads im vergangenen Jahr (aber keine Zahl zu den generierten Umsätzen im Play Store).

Die nächste Milliarde Internetbenutzer

Ein wiederkehrendes Thema war die Frage, wie die Reichweite des Internets erhöht wird. Sei es durch Loom, die Ballone, die nicht verkabelten Regionen ein Funknetz bringen sollen; seien es günstige Android Smartphones, die für viele Menschen der erste (und vielleicht einzige) Computer sein werden, mit dem sie ins Netz gehen.

Hardware

Abgesehen von der neuen Cardboard Version und dem skurilen Kameraarray gab es da nichts. Weder ein Chromecast II noch neue Chromebooks und erst recht keine Nexus Geräte.

Programmierung

Konkrete Themen für die anwesenden EntwicklerInnen wurden hier nur gestreift, die Vertiefung kommt dann später in den Sessions. Da gab es Dinge wie die nächste Version von Android Studio, die nun auch sehr umfangreiche Unterstützung für C/C++ Entwicklung mitbringt; Polymer 1.0 ist da; Android M natürlich.

Fazit

Keine ganz so atemlose, überladene Veranstaltungen wie in früheren Jahren, aber trotzdem schön und anregend.

Wiederholt Google mit Chrome die Geschichte von Microsoft und dem Internet Explorer?

“Cynics surely look at this [the web version of Inbox is Chrome-only] as the second coming of Microsoft’s IE-only web technologies from the late ’90s, but my guess is that support for additional browsers iscoming .. and they shipped Chrome-first only because it was the fastest way they could ship.” — John Gruber | Montag, 3. XI 2014

Eine alte Darstellung des Pflügens (Quelle: Internet Archive): So wie der Bauer das Land bestellt, bereitet Google mit Chrome den Acker für zukünftige Webtechnologien.
Eine alte Darstellung des Pflügens (Quelle: Internet Archive): So wie der Bauer das Land bestellt, bereitet Google mit Chrome den Acker für zukünftige Webtechnologien.

Ist das eine merkwürdige Frage? Dieser Vergleich von Googles bisher unendlichem Fortschrittsdrang bei der Weiterentwicklung der Webtechnologien in seinem Chrome Browser, und der bleischweren Zeit eines Internet Explorers 6, der Microsoft nach dem Sieg über Netscape und dem Erringen der uneingeschränkten Hegemonie über das Web dazu diente, dieses technologisch quasi einzufrieren? Ich glaube schon. Aber warum eigentlich?

John Gruber kommt auf dieses Thema am Rande einer interessanten Betrachtung zu Google’s neuem ‘Material Design’, der Gestaltungssprache, die sich gerade über alle Google Dienste, Betriebssysteme und Apps ausbreitet. Er kann dabei nicht umhin auf zwei Punkte hinzuweisen:

Google, das Unternehmen, welches am längsten für den Triumph des Websals übergreifender Entwicklungsplattform über die nativen Apps gekämpft hat, setzt zum einen inzwischen intensiver als je zuvor auf solche Apps, jedenfalls für Android und iOS. Zum anderen zeigt er am Beispiel der brandneuen INBOX auf, dass die hier verfügbare Webversion zur Zeit einzig und allein unter Chrome funktioniert.

Ist das nicht genauso schlimm wie die proprietären Funktionen, die Microsoft damals in seinen Internet Explorer einbaute, und die anderen Browserherstellern das Leben schwer machten?

Es gibt dabei einen entscheidenden Unterschied: Google unterstützt andere Browser (in einigen Fällen) nicht, weil diese noch nicht die Funktionen bieten, die Chrome bereits enthält. Mit Chrome hat sich Google ein Mittel geschaffen das Web insgesamt im 6-Wochen-Takt voran zu bringen und hat hier als einzigen ‘Konkurrenten’, der dieses hohe Tempo mitmacht, die Mozilla Foundation. Alle anderen relevanten Hersteller — also Apple und Microsoft — nehmen ggf. die von den beiden Vorreitern entwickelten, getesteten, und schon im Einsatz befindlichen Standards dann später auf, wenn sie in ihren viel langsameren Releasezyklen mal wieder eine neue Version von Safari oder dem Internet Explorer veröffentlichen.

Im Gegensatz zur Versteinerung des Zeitalters der Microsoft Hegemonie befinden wir uns nun also in einem rasanten Zeitalter der unterschiedlichen Entwicklungsgeschwindigkeiten, bei dem es immer Beispiele wie INBOX geben wird, die so nahe an der ‘bleeding edge’ der Webtechnologie sind, dass sie schon aus Prinzip nicht von allen Browsern unterstützt werden können.

Es gibt daher keinen Grund eine erneute Versteinerung des Webs zu befürchten, solange Google von Mozilla, Microsoft und Apple ein Mindestmaß an Konkurrenz erfährt.