Leitfaden für Hersteller zur langfristigen Android-Sicherheit

In diesem Leitfaden werden die von Google empfohlenen Best Practices für die Anwendung von Sicherheits-Patches beschrieben, die von der Android Compatibility Test Suite (CTS) bewertet werden. Sie richtet sich an Hersteller von Android-kompatiblen OEM-Geräten (Hersteller), die länger als drei Jahre unterstützt werden, z. B. Fahrzeuge, Fernseher, Set-Top-Boxen und Haushaltsgeräte. Dieser Leitfaden richtet sich nicht an Endnutzer (z. B. Fahrzeughalter).

Danksagungen und Haftungsausschluss

Dieser Leitfaden ist weder rechtlich noch vertraglich bindend für Google oder andere Hersteller und stellt keine Anforderungen dar. Dieser Leitfaden ist vielmehr eine Anleitung, in der empfohlene Praktiken beschrieben werden.

Feedback

Dieser Leitfaden ist nicht vollständig. Weitere Überarbeitungen sind geplant. Senden Sie Feedback an manufacturers-guide-android@googlegroups.com.

Glossar

Begriff Definition
ACC Android-Kompatibilitätsverpflichtung Früher als Android Anti-Fragmentation Agreement (AFA) bezeichnet.
AOSP Open-Source-Projekt von Android
ASB Sicherheitsbulletin für Android
BSP Board Support Package
CDD Compatibility Definition Document
CTS Compatibility Test Suite
FOTA Firmware per WLAN
GPS Global Positioning System
MISRA Motor Industry Software Reliability Association
NIST National Institute of Standards and Technology
OBD On-Board-Diagnose (OBD-II ist sowohl in Bezug auf die Funktionen als auch die Standardisierung eine Verbesserung gegenüber OBD-I.)
OEM Erstausrüster
Betriebssystem Betriebssystem
SEI Software Engineering Institute
SoC System-on-a-Chip
SOP Produktionsbeginn
SPL Stand der Sicherheits-Patches
TPMS Reifendruckkontrollsystem

Android-Betriebssystem

Android ist ein Open-Source-Linux-basierter Softwarestack, der für eine Vielzahl von Geräten und Formfaktoren entwickelt wurde. Seit seiner ersten Veröffentlichung im Jahr 2008 ist Android das beliebteste Betriebssystem und wird auf über 1,4 Milliarden Geräten weltweit (2016) eingesetzt. Etwa 67% dieser Geräte nutzen Stand März 2017 Android 5.0 (Lollipop) oder höher. Aktuellere Zahlen sind im Android-Dashboard verfügbar. Der Großteil der Geräte sind Smartphones und Tablets, aber Android wird auch immer häufiger auf Smartwatches, Fernsehern und Infotainmentsystemen in Autos eingesetzt.

Die Anzahl der im Google Play Store verfügbaren Android-Apps hat über 2,2 Millionen erreicht (2016). Die Entwicklung von Android-Apps wird vom Android-Kompatibilitätsprogramm unterstützt, das eine Reihe von Anforderungen über das Compatibility Definition Document (CDD) definiert und Testtools über die Compatibility Test Suite (CTS) bereitstellt. Mit den Android-Kompatibilitätsprogrammen wird sichergestellt, dass jede Android-App auf jedem Android-kompatiblen Gerät ausgeführt werden kann, das die erforderlichen Funktionen für die App unterstützt.

Google veröffentlicht regelmäßig neue Betriebssystemversionen, Betriebssystemsicherheitsupdates und Informationen zu entdeckten Sicherheitslücken. Die Hersteller sollten den Android-Sicherheitsbulletin prüfen, um festzustellen, ob diese Updates für von Android unterstützte Produkte gelten. Informationen zu Sicherheit, Kompatibilität und Build-Systemen von Android finden Sie unter den folgenden Links:

Verbundene Fahrzeuge (kanonische langlebige Produkte)

Mit der Einführung des AM-Radios in den 1920er-Jahren wurden Fahrzeuge vernetzt. Die Anzahl der externen physischen und drahtlosen Verbindungen nahm zu, da sich Regulierungsbehörden und Automobilhersteller der Elektronik zuwandten, um die Diagnose und Wartung zu vereinfachen (z. B. OBD-II-Port), die Sicherheit zu verbessern (z. B. TPMS) und die Kraftstoffverbrauchsziele zu erreichen. Die nächste Welle der Konnektivität führte Fahrerkomfortfunktionen wie schlüssellosen Zugang, Telematiksysteme und erweiterte Infotainmentfunktionen wie Bluetooth, WLAN und Smartphone-Projektion ein. Heutzutage unterstützen integrierte Sensoren und Konnektivität (z. B. GPS) Sicherheits- und teilautonome Fahrsysteme.

Je mehr Fahrzeugverbindungen es gibt, desto größer ist die Angriffsfläche für Fahrzeuge. Verbindungen bergen ähnliche Sicherheitsrisiken wie bei Unterhaltungselektronik. Während Neustarts, tägliche Patch-Updates und ungeklärte Verhaltensweisen bei Unterhaltungselektronik jedoch die Norm sind, sind sie bei Produkten mit sicherheitskritischen Systemen wie Fahrzeugen inkonsistent.

Hersteller müssen proaktiv vorgehen, um die kontinuierliche Sicherheit und Zuverlässigkeit eines Produkts im Einsatz zu gewährleisten. Kurz gesagt: Hersteller müssen sich über bekannte Sicherheitslücken im Produkt im Klaren sein und diese auf risikobasierte Weise beheben.

Langfristige Sicherheit

Ein vernetztes Fahrzeug hat oft eine oder mehrere elektronische Steuergeräte (ECUs), die mehrere Softwarekomponenten wie Betriebssysteme, Bibliotheken und Dienstprogramme enthalten. Hersteller sollten diese Komponenten im Blick behalten und bekannte veröffentlichte Sicherheitslücken durch proaktive Analysen identifizieren, darunter:

  • Regelmäßige Prüfung des Produkts anhand der CVE-Datenbank (Common Vulnerabilities and Exposures)
  • Erfassen von Informationen zu produktbezogenen Sicherheitslücken.
  • Sicherheitstests
  • Aktive Analyse von Android-Sicherheitsbulletins

Beispiel für Betriebssystem- und Sicherheitspatch-Updates (IVIs mit Android):

Abbildung 1: Beispiel für die Einführung wichtiger Betriebssystem- und Sicherheitsupdates während der Lebensdauer des Fahrzeugs

# Schritt Aktivitäten

①

 Entwicklungszweig Der Hersteller wählt eine Android-Version (Android X) aus. In diesem Beispiel bildet „Android X“ die Grundlage für die Ausstattung des Fahrzeugs, die zwei Jahre vor dem Produktionsstart (SOP) festgelegt wird.
② Erste Phase der Einführung Einige Monate vor der Markteinführung von Android X als erster Betriebssystemversion im Produkt werden Sicherheitsupdates aus Android-Sicherheitsbulletins (ASBs) und möglicherweise aus anderen Quellen übernommen, die vom Hersteller als wertvoll erachtet werden. y2 = das zweite Sicherheitsbulletin für Version X von Android, das vom Hersteller auf Android X angewendet (backported) wird. Dieses Update ist im Produkt enthalten und die Produktionsuhr beginnt mit Android X.y2 bei Null.

In diesem Beispiel hat der Hersteller entschieden, nicht den neueren jährlichen Release Android X+1 ausliefern zu lassen. Gründe für die Veröffentlichung der neuesten Version sind unter anderem die Einführung neuer Funktionen, die Behebung neuer Sicherheitslücken und/oder die Bereitstellung von Google-Diensten oder Diensten von Drittanbietern, für die die neuere Android-Version erforderlich ist. Gründe gegen die Auslieferung mit der neuesten Version sind die begrenzte Zeit, die für die Entwicklung und Markteinführung des Fahrzeugs zur Verfügung steht, um die Änderungen zu integrieren, zu testen und zu validieren, einschließlich der Einhaltung aller behördlichen und Zertifizierungsanforderungen.
③ Vollständiges Betriebssystemupdate Nach der SOP veröffentlicht der Hersteller das Betriebssystemupdate Android X+2, also zwei Android-Releases nach der Version, die für das ursprüngliche Produkt verwendet wurde (Android X0). ASB-Sicherheitsupdates sind für die API-Ebene verfügbar (ab dem Versanddatum). Das Update wird also als X+2.y0 ungefähr 1,25 Jahre nach SOP veröffentlicht. Dieses Betriebssystemupdate ist möglicherweise nicht mit in Betrieb genommenen Produkten kompatibel. Falls ja, kann ein Plan erstellt werden, um die bereitgestellten Fahrzeuge zu aktualisieren.

Sofern keine anderen Geschäftsvereinbarungen bestehen, liegt die Entscheidung für ein vollständiges Betriebssystemupdate ausschließlich im Ermessen des Herstellers.
④ Sicherheitsupdate Zwei Jahre nach Produktionsbeginn des Fahrzeugs veröffentlicht der Hersteller ein Update für das Android X+2-Betriebssystem. Diese Entscheidung basiert auf der Risikobewertung des Herstellers. Der Hersteller wählt das dritte ASB-Sicherheitsupdate für Version X+2 als Grundlage für das Update aus. Die Produkte, für die das Sicherheitsupdate bereitgestellt wird, haben jetzt das Betriebssystem (X+2.y3) und das Android-Sicherheitspatch-Level.

Hersteller können einzelne Sicherheits-Patches aus jedem einzelnen ASB auswählen, müssen jedoch alle erforderlichen Probleme im Bulletin beheben, um die mit dem Bulletin verknüpfte Android-Sicherheits-Patch-Ebene (SPL) zu verwenden (z. B. 2017-02-05). Der Hersteller ist dafür verantwortlich, den Backport und die Sicherheitsveröffentlichung für das unterstützte Produkt durchzuführen.
⑤ Vollständiges Betriebssystemupdate Wiederholung von Schritt 3 (Vollständiges Betriebssystemupdate). Das zweite vollständige Betriebssystemupdate bringt das Produkt drei Jahre nach Produktionsbeginn des Fahrzeugs auf Android X+4. Der Hersteller muss jetzt die neueren Hardwareanforderungen einer aktuellen Android-Version mit der Hardware im Produkt in Einklang bringen. Der Nutzer profitiert von einem aktualisierten Android-Betriebssystem. Der Hersteller veröffentlicht ein Update ohne Sicherheitsupdates. Das Produkt hat jetzt das Betriebssystem- und Android-Sicherheitspatch-Level (X+4.y0).

In diesem Beispiel ist X + 4 aufgrund von Hardwareeinschränkungen die letzte Hauptversion von Android, die für dieses Produkt bereitgestellt wird. Obwohl das Fahrzeug eine Lebensdauer von über 6 Jahren hat, ist weiterhin Sicherheitssupport erforderlich.
⑥ Sicherheitsupdate Wiederholen Sie Schritt 4 (Sicherheitsupdate). Der Hersteller muss ASB-Sicherheitsupdates aus einer viel neueren Android-Version (X + 6) übernehmen und einige oder alle dieser Updates zurück auf Android X + 4 portieren. Es liegt in der Verantwortung des Herstellers, die Updates zusammenzuführen, zu integrieren und auszuführen (oder einen Drittanbieter zu beauftragen). Der Hersteller sollte außerdem wissen, dass Sicherheitsprobleme in nicht mehr unterstützten Android-Versionen nicht durch die ASB abgedeckt sind.
⑦ Sicherheitsupdate Acht Jahre nach Beginn des Produktionszyklus des Fahrzeugs, vier Android-Releases nach dem letzten Betriebssystemupdate in Schritt 5 (Vollständiges Betriebssystemupdate) und zehn Jahre nach der Spezifikation von Android X liegt die Verantwortung für die Zusammenstellung und Backportierung von Sicherheits-Patches für Versionen, die älter als drei Jahre nach der öffentlichen Veröffentlichung auf API-Ebene sind, vollständig beim Hersteller.

Best Practices für Sicherheit

Um Sicherheitsverletzungen zu erschweren, empfiehlt und verwendet Google allgemein anerkannte Best Practices für Sicherheit und Softwareentwicklung, wie unter Implementierung der Sicherheit beschrieben.

Sicherheitsrichtlinien

Empfohlene Best Practices für die Sicherheit:

  • Verwenden Sie die neuesten Versionen externer Bibliotheken und Open-Source-Komponenten.
  • Fügen Sie Release-Versionen des Betriebssystems keine aufdringlichen Debugfunktionen hinzu.
  • Entfernen Sie nicht verwendete Funktionen, um die Angriffsfläche zu reduzieren.
  • Verwenden Sie das Prinzip der geringsten Berechtigung und andere Best Practices für die Entwicklung von Android-Apps.

Richtlinien für die Softwareentwicklung

Zu den empfohlenen Praktiken für die sichere Softwareentwicklung während des gesamten Lebenszyklus des Systems gehören:

  • Führen Sie eine Bedrohungsmodellierung durch, um Assets, Bedrohungen und potenzielle Risikominderungen zu bewerten und zu identifizieren.
  • Führen Sie eine Architektur-/Designüberprüfung durch, um ein sicheres und solides Design zu gewährleisten.
  • Führen Sie regelmäßige Codeüberprüfungen durch, um Anti-Pattern und Fehler so schnell wie möglich zu erkennen.
  • Unit-Tests mit hoher Codeabdeckung entwerfen, implementieren und ausführen, einschließlich:
    • Funktionstests (einschließlich negativer Testfälle)
    • Regelmäßige Regressionstests (um sicherzustellen, dass behobene Fehler nicht wieder auftreten)
    • Fuzz-Tests (als Teil der Unit-Test-Suite)
  • Verwenden Sie statische Quellcodeanalysetools (z. B. scan-build oder lint), um potenzielle Probleme zu identifizieren.
  • Verwenden Sie dynamische Quellcodeanalysetools wie AddressSanitizer, UndefinedBehaviorSanitizer und FORTIFY_SOURCE (für native Komponenten), um potenzielle Probleme während der Systementwicklung zu erkennen und zu beheben.
  • Sie haben eine Verwaltungsstrategie für den Software-Quellcode und die Release-Konfiguration/-Version.
  • Sie haben eine Patch-Management-Strategie für die Erstellung und Bereitstellung von Software-Patches.

Richtlinie für Backports von Sicherheitsupdates

Google bietet derzeit drei (3) Jahre lang nach der Veröffentlichung des API-Levels aktiven Support für Sicherheits-Backports von entdeckten und gemeldeten Sicherheitslücken. Der aktive Support umfasst Folgendes:

  1. Sicherheitslückenberichte erhalten und prüfen
  2. Sicherheitsupdates erstellen, testen und veröffentlichen
  3. Regelmäßige Veröffentlichung von Sicherheitsupdates und Details zu Sicherheitsbulletins.
  4. Führen Sie eine Schweregradbewertung gemäß den festgelegten Richtlinien durch.

Nach drei Jahren nach der öffentlichen Veröffentlichung des API-Levels empfiehlt Google die folgenden Richtlinien:

  • Verwenden Sie einen Drittanbieter (z. B. einen SoC-Anbieter oder Kernel-Anbieter) für den Backport-Support für Betriebssystemsicherheitsupdates, die älter als drei Jahre nach der API-Veröffentlichung sind.
  • Codeüberprüfungen mithilfe der öffentlich bereitgestellten ASBs von einem Drittanbieter durchführen lassen ASBs identifizieren zwar Sicherheitslücken für die aktuell unterstützte Version, ein Hersteller kann die bereitgestellten Informationen jedoch verwenden, um die neu veröffentlichten Updates mit früheren Versionen zu vergleichen. Diese Daten können verwendet werden, um eine Auswirkungenanalyse durchzuführen und möglicherweise ähnliche Patches für Betriebssystemversionen zu generieren, die älter als drei Jahre nach der API-Veröffentlichung sind.
  • Laden Sie gegebenenfalls Sicherheitsupdates in das Android Open Source Project (AOSP) hoch.
  • Der Hersteller muss den Umgang mit Sicherheitsupdates für anbieterspezifischen Code koordinieren (z. B. proprietären gerätespezifischen Code).
  • Der Hersteller sollte der NDA-Gruppe für die Vorabversion der Benachrichtigungen zu Android-Sicherheitsbulletins für Partner beitreten. Dazu ist die Unterzeichnung rechtlicher Vereinbarungen wie der Entwickler-NDA erforderlich. Bulletins sollten Folgendes enthalten:
    • Ankündigungen
    • Zusammenfassung der Probleme nach Patchebene, einschließlich CVE und Schweregrad
    • Falls zutreffend: Details zur Sicherheitslücke

Weitere Referenzen

Anleitungen zu sicheren Programmier- und Softwareentwicklungspraktiken finden Sie unter den folgenden Links:

Google empfiehlt die folgenden Best Practices.

Generell wird empfohlen, jedes vernetzte Produkt mit der neuesten Betriebssystemversion auf den Markt zu bringen. Hersteller sollten vor der Markteinführung des Produkts versuchen, die neueste Betriebssystemversion zu verwenden. Die Versionssperre ist zwar erforderlich, um die Stabilität vor dem Testen und der Validierung zu verbessern, aber der Hersteller muss die Produktstabilität, die durch ältere Betriebssystemversionen erreicht wird, mit neueren Betriebssystemversionen in Einklang bringen, die weniger bekannte Sicherheitslücken und einen verbesserten Sicherheitsschutz haben.

Zu den empfohlenen Richtlinien gehören:

  • Aufgrund der langen Entwicklungszeiten, die mit dem Fahrzeugentwicklungsprozess verbunden sind, müssen Hersteller möglicherweise mit der Betriebssystemversion n-2 oder älter auf den Markt kommen.
  • Für jede veröffentlichte Android-Version muss die Kompatibilität mit Android mit einer Over-the-air-Kampagne (OTA) eingehalten werden.
  • Implementieren Sie die Funktion „Firmware-over-the-air“ (FOTA) für Android-Produkte, um schnelle und kundenfreundliche Updates zu ermöglichen. Für die OTA-Aktualisierung sollten Sicherheitsbest Practices wie Codesignatur und TLS-Verbindung zwischen Produkt und IT-Backoffice verwendet werden.
  • Reichen Sie unabhängig erkannte Sicherheitslücken in Android an das Android-Sicherheitsteam ein.

Hinweis:Google hat die Möglichkeit von geräte- oder branchenspezifischen Benachrichtigungen in Android-Sicherheitsbulletins geprüft. Da Google jedoch den Kernel, die Treiber oder die Chipsätze eines bestimmten Geräts (Fahrzeug, Fernseher, Wearable, Smartphone usw.) nicht kennt, Google kann ein bestimmtes Sicherheitsproblem nicht eindeutig einem Gerätetyp zuordnen.

Der Hersteller sollte bei Verbesserungen während des Produktzyklus alle Anstrengungen unternehmen, die neueste Betriebssystemversion oder Sicherheitsupdates für die verwendete Version zu verwenden. Updates können bei regelmäßigen Produktupdates oder als Hotfixes zur Behebung von Qualitäts- und/oder anderen Problemen durchgeführt werden. Zu den empfohlenen Best Practices gehören:

  • Erstellen Sie einen Plan für die Aktualisierung von Treibern, Kerneln und Protokollen.
  • Verwenden Sie eine branchenübliche Methode, um Updates für eingesetzte Fahrzeuge bereitzustellen.

Compatibility Definition Document (CDD)

Im Compatibility Definition Document (CDD) werden die Anforderungen beschrieben, die ein Gerät erfüllen muss, um als Android-kompatibel zu gelten. Der CDD ist öffentlich und für alle verfügbar. Sie können CDD-Versionen von Android 1.6 bis zur neuesten Version unter source.android.com herunterladen.

Um diese Anforderungen für ein Produkt zu erfüllen, sind die folgenden grundlegenden Schritte erforderlich:

  1. Der Partner unterzeichnet die Android Compatibility Commitment (ACC) mit Google. Ein Technical Solutions Consultant (TSC) wird dann als Ansprechpartner zugewiesen.
  2. Der Partner führt die CDD-Prüfung für die Android-Betriebssystemversion des Produkts durch.
  3. Der Partner führt die CTS-Ergebnisse (siehe unten) aus und sendet sie, bis die Ergebnisse für die Android-Kompatibilität akzeptabel sind.

Compatibility Test Suite (CTS)

Mit dem Testtool Compatibility Test Suite (CTS) wird geprüft, ob eine Produktimplementierung mit Android kompatibel ist und ob die neuesten Sicherheits-Patches enthalten sind. CTS ist öffentlich, Open Source und für alle verfügbar. Sie können CTS-Versionen von Android 1.6 bis zur neuesten Version unter source.android.com herunterladen.

Jeder öffentlich veröffentlichte Build von Android-Software (Images für die werkseitige Installation und für das Feldupdate) muss die Android-Kompatibilität durch CTS-Ergebnisse nachweisen. Wenn auf dem Gerät beispielsweise Android 7.1 ausgeführt wird, sollte beim Erstellen und Testen eines Build-Images mit Release-Absicht auf die neueste entsprechende Version von CDD 7.1 und CTS 7.1 verwiesen werden. Wir empfehlen Herstellern dringend, CTS frühzeitig und häufig zu verwenden, um Probleme zu erkennen und zu beheben.

HINWEIS:Partner, die andere Vereinbarungen unterzeichnen, z. B. die Google Mobile-Dienste (GMS), müssen möglicherweise andere Anforderungen erfüllen.

CTS-Workflow

Der CTS-Workflow umfasst die Einrichtung der Testumgebung, das Ausführen von Tests, die Auswertung der Ergebnisse und das Verständnis des CTS-Quellcodes. Die folgenden Richtlinien sollen CTS-Nutzern (z. B. Entwicklern, Herstellern) helfen, CTS effektiv und effizient zu nutzen.

  • Führen Sie häufig Tests durch. CTS ist ein automatisiertes Tool, das in Ihr Build-System eingebunden wird. Wenn Sie CTS häufig ausführen, können Sie Fehler schnell und frühzeitig finden, wenn es zu einer Verschlechterung der Software oder zu Regressionen kommt.
  • CTS-Quellcode herunterladen und prüfen Der vollständige CTS-Quellcode ist Open-Source-Software, die jeder herunterladen und verwenden kann. Der heruntergeladene Quellcode kann vollständig kompiliert und ausgeführt werden. Wenn ein Test auf dem Gerät fehlschlägt, können Sie anhand des entsprechenden Abschnitts des Quellcodes herausfinden, warum.
  • Holen Sie sich die neueste CTS-Version. Neue Android-Releases können das CTS mit Fehlerkorrekturen, Verbesserungen und neuen Tests aktualisieren. Prüfen Sie die CTS-Downloads regelmäßig und aktualisieren Sie Ihr CTS-Programm bei Bedarf. Hersteller und Google müssen sich auf die CTS-Version einigen, die für die Produktveröffentlichung verwendet werden soll, da das Produkt irgendwann eingefroren werden muss, während die CTS weiter aktualisiert wird.

CTS übergeben

Bei einem Android-kompatiblen Produkt stellt Google sicher, dass die Testergebnisse des CTS und des CTS Verifier für das Gerät akzeptabel sind. Im Prinzip müssen alle Tests bestanden werden. Ein Test, der aus anderen Gründen als der Nichteinhaltung der Android-Kompatibilitätsanforderungen fehlschlägt, wird jedoch von Google überprüft. Dabei passiert Folgendes:

  1. Der Hersteller stellt Google die vorgeschlagenen CTS-Patches, Patchvalidierungen und Begründungen zur Verfügung, um seine Behauptung zu belegen.
  2. Google prüft die eingereichten Materialien und aktualisiert die entsprechenden CTS-Tests, falls sie akzeptiert werden, sodass das Gerät die nächste CTS-Version besteht.

Wenn ein CTS-Test nach der Anwendung eines Sicherheitspatches plötzlich fehlschlägt, muss der Hersteller den Patch so ändern, dass die Kompatibilität nicht beeinträchtigt wird, ODER nachweisen, dass der Test falsch ist, und eine Korrektur für den Test bereitstellen (wie oben beschrieben).

Das CTS bleibt für die Überprüfung von Testkorrekturen geöffnet. Für Android 4.4 werden beispielsweise weiterhin Fehlerkorrekturen akzeptiert (siehe https://android-review.googlesource.com/#/c/273371/).

Häufig gestellte Fragen

F: Wer ist für die Anwendung von Sicherheitsupdates auf eine bestimmte Android-Implementierung verantwortlich?

A: Der Hersteller, der das Gerät direkt liefert, ist dafür verantwortlich. Diese Entität ist nicht Google, das Sicherheitsupdates in AOSP und nicht für ein bestimmtes Gerät (z. B. ein Fahrzeug) veröffentlicht.

F: Wie geht Google mit Sicherheitsproblemen bei Android um?

A: Google untersucht Probleme kontinuierlich und entwickelt potenzielle Fehlerkorrekturen, die im Rahmen des regelmäßigen Sicherheitsupdate-Prozesses für alle unterstützten API-Levels verfügbar gemacht werden. Seit August 2015 veröffentlicht Google regelmäßig Bulletins und Links zu Updates auf source.android.com. Außerdem veröffentlicht Google Sicherheitsupdates im Rahmen wichtiger Betriebssystemversionen. Weitere Informationen finden Sie in der Richtlinie für Backports von Sicherheitsupdates.

F: Wenn ein Hersteller alle AOSP-Patches aus einem ASB integriert hat, aber keine Patches vom BSP-Anbieter, der im selben Bulletin erwähnt wird, kann er das Sicherheitsniveau trotzdem erhöhen (z. B. den entsprechenden Patch auf die Plattform/das Build anwenden)?

A: Um eine Android-Sicherheits-Patch-Ebene (SPL) zu deklarieren, muss ein Hersteller alle erforderlichen Probleme beheben, die im Android-Sicherheitsbulletin veröffentlicht wurden (einschließlich früherer Bulletins) und einer bestimmten Android-SPL zugeordnet wurden. Ein Hersteller, der das Sicherheitsbulletin vom März 2017 (2017-03-01 SPL) verwendet, hat beispielsweise alle erforderlichen Probleme behoben, die im Bulletin vom März 2017 für diese SPL und alle vorherigen Updates dokumentiert sind, einschließlich gerätespezifischer Updates für alle vorherigen Android-Sicherheitsbulletins, einschließlich der gerätespezifischen Updates, die mit dem SPL vom 05.02.2017 verknüpft sind.

F: Was passiert, wenn der Hersteller nicht mit den vom BSP-Anbieter bereitgestellten Sicherheitsupdates einverstanden ist ODER wenn Sicherheitsupdates, die von einer ASB vorgeschrieben sind, nicht von den Anbietern bereitgestellt werden?

A: In einem ASB werden Sicherheitslücken (aufgeführt in einer Liste von CVEs) beschrieben und es werden häufig entsprechende Sicherheitstests bereitgestellt. Ziel ist es, dafür zu sorgen, dass die aufgeführten Sicherheitslücken auf einem Gerät nicht mehr reproduziert werden können und dass das Gerät die zugehörigen Sicherheitstests besteht. Es geht also nicht darum, ein Sicherheitsupdate von Google oder einem Drittanbieter zu installieren, sondern darum, dass der Hersteller bestätigt, dass das Gerät nicht anfällig für die CVEs in der ASB ist. Der Hersteller kann die bereitgestellten Sicherheitsupdates verwenden oder, wenn er eine Änderung hat, die für sein Gerät besser geeignet ist, diese Änderung stattdessen verwenden.

Angenommen, Google behebt eine AOSP-Sicherheitslücke durch eine Codeänderung, die es der Komponente ermöglicht, voll funktionsfähig und konform mit der CDD zu bleiben. Wenn der Hersteller feststellt, dass die Komponente auf dem Gerät nicht benötigt wird oder nicht durch die CDD (oder entsprechende Zertifizierungstests) vorgeschrieben ist, kann er die Komponente entfernen, um zukünftige Wartungsanforderungen zu reduzieren und die Angriffsfläche zu verringern. Der Hersteller hat das bereitgestellte Sicherheitsupdate zwar nicht verwendet, hat aber dafür gesorgt, dass das Gerät nicht anfällig für die im Sicherheitsbulletin dokumentierte CVE ist. Wenn der Hersteller jedoch vom empfohlenen Sicherheitsupdate abweicht, besteht das Risiko, dass das Problem nicht richtig behoben wird, neue Sicherheitslücken entstehen oder die Funktionalität des Endbuilds anderweitig beeinträchtigt wird.

Wir arbeiten mit allen SoC-Partnern zusammen, um dafür zu sorgen, dass es für alle Probleme in einem ASB Lösungen gibt. Wir empfehlen Herstellern jedoch, für den gesamten Lebenszyklus eines Geräts eine Servicevereinbarung mit ihren SoC-Anbietern abzuschließen. SoCs stellen die Unterstützung eines Chipsatzes möglicherweise früher als gewünscht ein. Daher ist es ein wichtiger Teil des Geräteeinführungsprozesses, vor der Auswahl des Chipsatzes Vereinbarungen zu treffen.

Wenn es nicht möglich ist, eine Korrektur für ein in einem ASB dokumentiertes Problem direkt zu erwerben oder unabhängig zu erstellen, kann ein Hersteller die vorherige Android SPL beibehalten und dem Build trotzdem die neuen verfügbaren Korrekturen hinzufügen. Diese Praxis führt jedoch letztendlich zu Problemen mit der Build-Zertifizierung, da Android dafür sorgt, dass auf zertifizierten Geräten der neueste Stand der Sicherheitsupdates verfügbar ist. Google empfiehlt, sich im Voraus mit Ihrem SoC in Verbindung zu setzen, um dies zu vermeiden.

F: Wenn der Hersteller feststellt, dass ein ASB-Element für sein Produkt nicht zutrifft, muss es dann trotzdem angewendet oder gepatcht werden, um die anderen Google-Anforderungen zu erfüllen oder den CTS zu bestehen?

A: Es sind keine Patches erforderlich, um eine Android-Sicherheits-Patch-Ebene (SPL) zu deklarieren. Der Hersteller muss jedoch bestätigen, dass sein Build nicht anfällig für das Problem ist.

Ein Beispiel ist, wenn eine gepatchte Komponente nicht im System des Herstellers vorhanden ist oder eine Komponente aus dem System des Herstellers entfernt wird, um ein Problem zu beheben. In diesem Fall ist das System möglicherweise konform, ohne dass der Hersteller einen Patch anwenden muss.

Das unterscheidet sich grundlegend von einem Hersteller, der beispielsweise nur kritische Patches korrigieren möchte, aber keine anderen anwendbaren Patches, die einen Sicherheitstest zum Scheitern bringen würden. In diesem Fall wird davon ausgegangen, dass der SPL nicht erfüllt wurde.