Leitfaden für Hersteller zur langfristigen Android-Sicherheit

In diesem Leitfaden werden die von Google empfohlenen Best Practices für die Anwendung von Sicherheitspatches beschrieben, die von der Android Compatibility Test Suite (CTS) bewertet werden. Sie ist für Hersteller von Android-kompatibler OEM-Ausrüstung (Hersteller) vorgesehen, die länger als drei Jahre unterstützt werden, z. B. Fahrzeuge, Fernseher, Set-Top-Boxen und Haushaltsgeräte. Dieser Leitfaden ist nicht für Endnutzer (z. B. Fahrzeughalter) gedacht.

Danksagungen und rechtliche Hinweise

Dieser Leitfaden ist für Google und andere Hersteller weder rechtlich noch vertraglich bindend und soll keine Reihe von Anforderungen darstellen. Dieser Leitfaden ist vielmehr eine Anleitung, in der empfohlene Vorgehensweisen 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ätszusicherung. 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-Updates over the air
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 auf 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-Software-Stack auf Linux-Basis, der für eine Vielzahl von Geräten und Formfaktoren entwickelt wurde. Seit der ersten Veröffentlichung im Jahr 2008 hat sich Android zum beliebtesten Betriebssystem entwickelt und wird auf über 1,4 Milliarden Geräten weltweit (2016) verwendet. Etwa 67% dieser Geräte verwenden seit März 2017 Android 5.0 (Lollipop) oder höher. Aktuellere Zahlen sind im Android-Dashboard verfügbar. Die meisten Geräte sind Smartphones und Tablets, aber Android wird auch auf Smartwatches, Fernsehern und Infotainment-Systemen in Fahrzeugen immer beliebter.

Die Anzahl der im Google Play Store verfügbaren Android-Apps hat 2016 2,2 Millionen erreicht. Die Entwicklung von Android-Apps wird durch das 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. Die Android-Kompatibilitätsprogramme sorgen dafür, dass jede Android-App auf jedem Android-kompatiblen Gerät ausgeführt werden kann, das die für die App erforderlichen Funktionen unterstützt.

Google veröffentlicht regelmäßig neue Betriebssystemversionen, Betriebssystemsicherheitsupdates und Informationen zu entdeckten Sicherheitslücken. Hersteller sollten die Sicherheitsbulletins für Android prüfen, um festzustellen, ob diese Updates für Produkte mit Android-Betriebssystem gelten. Informationen zu Android-Sicherheit, Kompatibilität und Build-Systemen finden Sie hier:

Verbundene Fahrzeuge (kanonische langlebige Produkte)

Fahrzeuge wurden mit der Einführung von AM-Radio in den 1920er-Jahren vernetzt. Von da an wuchs die Zahl der externen physischen und drahtlosen Verbindungen, da Aufsichtsbehörden und Automobilhersteller auf Elektronik setzten, um die Diagnose und Wartung zu erleichtern (z. B. OBD-II-Anschluss), die Sicherheit zu verbessern (z. B. TPMS) und die Kraftstoffverbrauchsvorgaben zu erfüllen. Die nächste Welle der Konnektivität brachte Fahrerkomfortfunktionen wie die schlüssellose Fernbedienung, Telematiksysteme und fortschrittliche Infotainmentfunktionen wie Bluetooth, WLAN und Smartphone-Projektion mit sich. Integrierte Sensoren und Konnektivität (z. B. GPS) unterstützen heute Sicherheits- und halbautonome Fahrsysteme.

Mit der Anzahl der Fahrzeugverbindungen wächst auch die potenzielle Angriffsfläche des Fahrzeugs. Verbindungen bergen ähnliche Cybersicherheitsrisiken wie Unterhaltungselektronik. Während Neustarts, tägliche Patch-Updates und unerklärliches Verhalten bei Unterhaltungselektronik normal sind, sind sie bei Produkten mit sicherheitskritischen Systemen wie Fahrzeugen nicht akzeptabel.

Hersteller müssen proaktiv vorgehen, um die fortlaufende Sicherheit eines Produkts im Einsatz sicherzustellen. Kurz gesagt: Hersteller müssen sich bekannter Sicherheitslücken im Produkt bewusst sein und einen risikobasierten Ansatz zur Behebung dieser Lücken verfolgen.

Langfristige Sicherheit gewährleisten

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

  • Das Produkt wird regelmäßig anhand der CVE-Datenbank (Common Vulnerabilities and Exposures) bewertet.
  • Sammeln von Informationen zu produktbezogenen Sicherheitslücken.
  • Sicherheitstests.
  • Aktive Analyse von Android-Sicherheitsbulletins

Beispiele für Betriebssystem- und Sicherheitspatch-Updates (IVI-Systeme mit Android):

Abbildung 1. Beispiel für die Einführung wichtiger Betriebssystem- und Sicherheitsupdates über die Lebensdauer des Fahrzeugs hinweg.

# Schritt Aktivitäten

①

 Entwicklungszweig Der Hersteller wählt eine Version von Android aus (Android X). In diesem Beispiel wird „Android X“ zur Grundlage für das, was zwei Jahre vor dem ersten Produktionsstart (Start of Production, SOP) im Fahrzeug ausgeliefert wird.
② Erste Phase der Einführung Einige Monate, bevor Android X die erste im Produkt ausgelieferte Betriebssystemversion wird, werden Sicherheitsupdates aus Sicherheitsbulletins für Android und möglicherweise anderen Quellen bezogen, die der Hersteller als wertvoll erachtet. y2 = das zweite Sicherheitsbulletin für Version X von Android, das vom Hersteller auf Android X angewendet (rückportiert) wurde. Dieses Update wird im Produkt ausgeliefert und die Produktionsuhr beginnt mit Android X.y2 im Jahr 0.

In diesem Beispiel hat der Hersteller entschieden, das neuere jährliche Release Android X+1 nicht auszuliefern. Gründe für die Auslieferung der neuesten Version sind unter anderem das Hinzufügen neuer Funktionen, das Beheben neuer Sicherheitslücken und/oder die Auslieferung von Google- oder Drittanbieterdiensten, für die die neuere Android-Version erforderlich ist. Gründe gegen die Auslieferung mit der neuesten Version sind der Zeitmangel, der mit der Entwicklung und Einführung von Fahrzeugen einhergeht und der für die Integration, das Testen und die Validierung der Änderungen erforderlich ist, einschließlich der Einhaltung aller behördlichen und Zertifizierungsanforderungen.
③ Vollständiges Betriebssystem-Update Nach dem SOP veröffentlicht der Hersteller ein Android X+2-Betriebssystem-Update, das zwei Android-Versionen nach der Version für das ursprüngliche Produkt (Android X0) liegt. ASB-Sicherheitsupdates sind für das API-Level (ab dem Versanddatum) verfügbar.Das Update wird also als X+2.y0 etwa 1,25 Jahre nach dem SOP veröffentlicht. Dieses Betriebssystem-Update ist möglicherweise nicht mit den im Feld eingesetzten Produkten kompatibel. Wenn das der Fall ist, kann ein Plan erstellt werden, um bereitgestellte Fahrzeuge zu aktualisieren.

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

Hersteller können zwar einzelne Sicherheitspatches aus einem beliebigen ASB auswählen, müssen aber alle erforderlichen Probleme im Bulletin beheben, um den mit dem Bulletin verknüpften Android-Sicherheitspatch-Level (SPL) zu verwenden (z. B. 2017-02-05). Der Hersteller ist für die Durchführung des Backports und die Sicherheitsveröffentlichung für das unterstützte Produkt verantwortlich.
⑤ Vollständiges Betriebssystem-Update Eine Wiederholung von Schritt 3 (vollständiges Betriebssystemupdate). Das zweite vollständige Betriebssystemupdate bringt das Produkt nach drei Jahren Produktionslebensdauer des Fahrzeugs auf Android X+4. Der Hersteller wägt nun die neueren Hardwareanforderungen einer aktuellen Android-Version gegen die Hardware im Produkt und die Vorteile für den Nutzer durch ein aktualisiertes Android-Betriebssystem ab. Der Hersteller veröffentlicht ein Update ohne Sicherheitsupdates, sodass das Produkt jetzt das Betriebssystem (X+4.y0) + Android-Sicherheitspatch-Level hat.

In diesem Beispiel ist X+4 aufgrund von Hardwarebeschränkungen die letzte Hauptversion von Android, die für dieses Produkt bereitgestellt wird. Die erwartete Lebensdauer des Fahrzeugs von mehr als 6 Jahren erfordert jedoch weiterhin Sicherheitsunterstützung.
⑥ Sicherheitsupdate Wiederholung von Schritt 4 (Sicherheitsupdate). Der Hersteller muss ASB-Sicherheitsupdates aus einer viel späteren Android-Version (X+6) übernehmen und einige oder alle dieser Updates auf Android X+4 portieren. Es liegt in der Verantwortung des Herstellers, die Updates zusammenzuführen, zu integrieren und auszuführen (oder einen Dritten damit zu beauftragen). Außerdem sollte der Hersteller wissen, dass Sicherheitsprobleme in Versionen von Android, die nicht mehr unterstützt werden, nicht im ASB behandelt werden.
⑦ Sicherheitsupdate Acht Jahre nach Beginn des Produktionslebenszyklus des Fahrzeugs, vier Android-Releases seit dem letzten Betriebssystemupdate in Schritt 5 (Vollständiges Betriebssystemupdate) und zehn Jahre seit der Spezifizierung von Android X liegt die Last der Kuratierung und des Backporting von Sicherheitspatches vollständig beim Hersteller für Versionen, die älter als drei Jahre seit der öffentlichen Veröffentlichung des API-Levels sind.

Best Practices für Sicherheit

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

Sicherheitsrichtlinien

Empfohlene Sicherheitsmaßnahmen:

  • Verwenden Sie die neuesten Versionen externer Bibliotheken und Open-Source-Komponenten.
  • In Release-Versionen des Betriebssystems dürfen keine aufdringlichen Debugging-Funktionen enthalten sein.
  • Entfernen Sie nicht verwendete Funktionen, um die Angriffsfläche zu verringern.
  • Wenden Sie das Prinzip der geringsten Berechtigung und andere Best Practices für die Entwicklung von Android-Apps an.

Richtlinien für die Softwareentwicklung

Empfohlene Praktiken für die sichere Softwareentwicklung für den Lebenszyklus des Systems sind:

  • Führen Sie eine Bedrohungsmodellierung durch, um Assets, Bedrohungen und potenzielle Gegenmaßnahmen zu identifizieren und zu bewerten.
  • Überprüfen Sie die Architektur/das Design, um ein sicheres und solides Design zu gewährleisten.
  • Führen Sie regelmäßige Code-Reviews durch, um Anti-Pattern und Fehler so schnell wie möglich zu erkennen.
  • Entwerfen, implementieren und ausführen von Unittests mit hoher Codeabdeckung, einschließlich:
    • Funktionstests (einschließlich negativer Testläufe)
    • Regelmäßige Regressionstests (um sicherzustellen, dass behobene Fehler nicht wieder auftreten)
    • Fuzzing-Tests (als Teil der Einheitentest-Suite)
  • Verwenden Sie Tools zur statischen Quellcodeanalyse (scan-build, lint usw.), 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 Software-Quellcode und Release-Konfiguration/Version.
  • Sie haben eine Patch-Management-Strategie für die Erstellung und Bereitstellung von Software-Patches.

Richtlinie für Sicherheits-Backports

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

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

Nach drei Jahren seit dem öffentlichen Release-Datum des API-Levels empfiehlt Google die folgenden Richtlinien:

  • Verwenden Sie einen Drittanbieter (z. B. einen SoC-Anbieter oder Kernel-Anbieter) für die Backport-Unterstützung von Betriebssystem-Sicherheitsupdates, die älter als drei Jahre nach der API-Veröffentlichung sind.
  • Sie beauftragen einen Drittanbieter mit der Durchführung von Code-Reviews anhand der öffentlich bereitgestellten ASBs. ASBs identifizieren zwar Sicherheitslücken für die derzeit unterstützte Version, ein Hersteller kann die bereitgestellten Informationen jedoch verwenden, um die neu veröffentlichten Updates mit früheren Versionen zu vergleichen. Anhand dieser Daten können Sie eine Wirkungsanalyse durchführen und möglicherweise ähnliche Patches für Betriebssystemversionen erstellen, die älter als drei Jahre nach der API-Veröffentlichung sind.
  • Laden Sie gegebenenfalls Sicherheitsupdates in das Open-Source-Projekt für Android (AOSP) hoch.
  • Der Hersteller muss die Verarbeitung von Sicherheitsupdates für anbieterspezifischen Code koordinieren, z. B. für proprietären gerätespezifischen Code.
  • Der Hersteller sollte der Benachrichtigungsgruppe für die NDA-Partner-Vorabversion des Android-Sicherheitsbulletins beitreten. Dazu ist die Unterzeichnung rechtlicher Vereinbarungen wie der Entwickler-NDA erforderlich. Bulletins sollten Folgendes enthalten:
    • Ankündigungen
    • Zusammenfassung der Probleme nach Patch-Level, einschließlich CVE und Schweregrad
    • Details zur Sicherheitslücke, sofern zutreffend

Weitere Referenzen

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

Google empfiehlt die folgenden Best Practices.

Es wird generell empfohlen, dass alle verbundenen Produkte mit der neuesten Betriebssystemversion auf den Markt gebracht werden. Hersteller sollten versuchen, die neueste Betriebssystemversion zu verwenden, bevor sie das Produkt auf den Markt bringen. Das Festlegen der Version ist zwar erforderlich, um vor dem Testen und der Validierung für Stabilität zu sorgen, der Hersteller muss jedoch die Produktstabilität, die durch ältere Betriebssystemversionen erreicht wird, mit neueren Betriebssystemversionen abwägen, die weniger bekannte Sicherheitslücken und verbesserte Sicherheitsfunktionen aufweisen.

Empfohlene Richtlinien:

  • Aufgrund der langen Entwicklungszeiten, die mit der Fahrzeugentwicklung einhergehen, müssen Hersteller möglicherweise mit der Betriebssystemversion n–2 oder älter auf den Markt kommen.
  • Sorgen Sie dafür, dass jede veröffentlichte Android-Betriebssystemversion über eine OTA-Kampagne (Over-the-Air) mit Android-Kompatibilität konform ist.
  • Implementieren Sie die FOTA-Funktion (Firmware-over-the-air) für Android-Produkte, um schnelle, kundenfreundliche Updates zu ermöglichen. FOTA sollte gemäß Best Practices für die Sicherheit erfolgen, z. B. durch Codesignierung und TLS-Verbindung zwischen Produkt und IT-Backoffice.
  • Senden Sie unabhängig identifizierte Android-Sicherheitslücken an das Android-Sicherheitsteam.

Hinweis:Google hat in den Sicherheitsbulletins für Android benachrichtigungen für bestimmte Gerätetypen oder Branchen in Erwägung gezogen. Da Google jedoch den Kernel, die Treiber oder die Chipsets für ein bestimmtes Gerät (Fahrzeug, Fernseher, Wearable, Smartphone usw.) nicht kennt, kann Google ein bestimmtes Sicherheitsproblem nicht deterministisch mit einem Gerätetyp kennzeichnen.

Der Hersteller sollte alles daran setzen, die aktuelle Betriebssystemversion oder Sicherheitsupdates für die verwendete Version während der Produktzyklusverbesserungen zu verwenden. Aktualisierungen können im Rahmen wiederkehrender regelmäßiger Produktaktualisierungen oder für Hotfixes zur Behebung von Qualitäts- und/oder anderen Problemen erfolgen. Empfohlene Vorgehensweisen:

  • Erstellen Sie einen Plan für Treiber-, Kernel- und Protokollupdates.
  • Verwenden Sie eine branchenspezifische Methode, um Updates für bereitgestellte 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. Das 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. Ihnen wird dann ein Technical Solution Consultant (TSC) zugewiesen.
  2. Der Partner schließt die CDD-Überprüfung für die Android-Version des Produkts ab.
  3. Der Partner führt die CTS-Tests aus und reicht die Ergebnisse ein (siehe unten), bis sie für die Android-Kompatibilität akzeptabel sind.

Compatibility Test Suite (CTS)

Mit dem Testtool „Compatibility Test Suite“ (CTS) wird überprüft, ob eine Produktimplementierung mit Android kompatibel ist und die neuesten Sicherheitspatches enthält. CTS ist öffentlich, Open Source und für alle verfügbar. Sie können CTS-Versionen von Android 1.6 bis zur neuesten Version von source.android.com herunterladen.

Für jeden Build von Android-Software, der für die Öffentlichkeit freigegeben wird (Images für die Werksinstallation und für Updates), muss die Android-Kompatibilität durch CTS-Ergebnisse nachgewiesen werden. Wenn auf dem Gerät beispielsweise Android 7.1 ausgeführt wird, sollte bei der Erstellung und beim Testen eines Release-Intent-Build-Images auf die neueste entsprechende Version von CDD 7.1 und CTS 7.1 verwiesen werden. Hersteller werden dringend aufgefordert, das CTS frühzeitig und häufig zu verwenden, um Probleme zu erkennen und zu beheben.

HINWEIS:Partner, die andere Vereinbarungen wie die Google Mobile Services (GMS) unterzeichnen, müssen möglicherweise andere Anforderungen erfüllen.

CTS-Workflow

Der CTS-Workflow umfasst das Einrichten der Testumgebung, das Ausführen von Tests, das Interpretieren von Ergebnissen und das Verstehen des CTS-Quellcodes. Die folgenden Richtlinien sollen CTS-Nutzern (z. B. Entwicklern, Herstellern) helfen, das CTS effektiv und effizient zu verwenden.

  • Häufig Tests durchführen: CTS ist als automatisiertes Tool konzipiert, das in Ihr Build-System integriert wird. Wenn Sie den CTS häufig ausführen, können Sie Fehler schnell und frühzeitig erkennen, wenn es zu einer Verschlechterung der Software oder zu Regressionen kommt.
  • CTS-Quellcode herunterladen und untersuchen Der vollständige CTS-Quellcode ist Open-Source-Software, die jeder herunterladen und verwenden kann. Der heruntergeladene Quellcode ist vollständig kompilierbar und ausführbar. Wenn ein Test auf dem Gerät fehlschlägt, können Sie den entsprechenden Abschnitt des Quellcodes untersuchen, um die Ursache zu ermitteln.
  • Aktuelles CTS herunterladen Mit neuen Android-Releases kann das CTS mit Fehlerkorrekturen, Verbesserungen und neuen Tests aktualisiert werden. Sehen Sie regelmäßig unter CTS-Downloads nach und aktualisieren Sie Ihr CTS-Programm bei Bedarf. Der Hersteller und Google müssen sich auf die CTS-Version einigen, die für die Produkteinführung erforderlich ist, da das Produkt irgendwann eingefroren werden muss, während die CTS weiterhin aktualisiert wird.

CTS bestehen

Bei einem Android-kompatiblen Produkt sorgt Google dafür, dass die Testergebnisse des CTS und der CTS-Verifier-Berichte des Geräts akzeptabel sind. Grundsätzlich 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. Das passiert:

  1. Der Hersteller stellt Google die vorgeschlagenen CTS-Patches, Patch-Validierungen und Begründungen zur Verfügung, um das Argument zu belegen.
  2. Google prüft das eingereichte Material und aktualisiert, sofern es akzeptiert wird, die entsprechenden CTS-Tests, damit das Gerät in der nächsten 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. Beispiel: Android 4.4 akzeptiert weiterhin Fehlerkorrekturen (siehe https://android-review.googlesource.com/c/platform/cts/+/273371).

Häufig gestellte Fragen

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

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

F: Wie geht Google mit Sicherheitsproblemen in Android um?

A: Google untersucht Probleme fortlaufend und entwickelt potenzielle Korrekturen, die im Rahmen des regulären Sicherheitsupdateprozesses 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 Sicherheits-Backports.

F: Wenn ein Hersteller alle AOSP-Patches aus einem ASB integriert, aber keine Patches vom im selben Bulletin erwähnten BSP-Anbieter, kann er dann trotzdem das Sicherheitsniveau erhöhen (z. B. den entsprechenden Patch auf „platform/build“ anwenden)?

A: Um einen Android-Sicherheitspatch-Level (SPL) zu deklarieren, muss ein Hersteller alle erforderlichen Probleme beheben, die im Android-Sicherheitsbulletin (einschließlich früherer Bulletins) veröffentlicht und einem bestimmten Android-SPL zugeordnet sind. Ein Hersteller, der beispielsweise das Sicherheitsbulletin für März 2017 (SPL vom 01.03.2017) verwendet, hat alle erforderlichen Probleme behoben, die in diesem Bulletin für diesen SPL und alle vorherigen Updates dokumentiert sind, einschließlich gerätespezifischer Updates für alle vorherigen Sicherheitsbulletins für Android, einschließlich der gerätespezifischen Updates, die mit dem SPL vom 05.02.2017 verknüpft sind.

F: Was passiert, wenn der Hersteller den vom BSP-Anbieter bereitgestellten Sicherheitsupdates nicht zustimmt ODER wenn von einem ASB vorgeschriebene Sicherheitsupdates nicht von Anbietern bereitgestellt werden?

A: In einem ASB werden Sicherheitslücken (aufgelistet nach CVEs) beschrieben und häufig passende 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 von Google oder einem Drittanbieter bereitgestelltes Sicherheitsupdate zu installieren, sondern darum, dass der Hersteller bestätigt, dass das Gerät nicht für die im ASB aufgeführten CVEs anfällig ist. Der Hersteller kann die bereitgestellten Sicherheitsupdates verwenden oder stattdessen eine Änderung vornehmen, die besser für sein Gerät geeignet ist.

Angenommen, Google behebt eine AOSP-Sicherheitslücke mit einer Codeänderung, die es der Komponente ermöglicht, voll funktionsfähig zu bleiben und dem CDD zu entsprechen. Wenn der Hersteller feststellt, dass die Komponente auf dem Gerät nicht benötigt wird oder nicht durch das CDD (oder die zugehörigen Zertifizierungstests) vorgeschrieben ist, kann er die Komponente entfernen, um den zukünftigen Wartungsaufwand und die Angriffsfläche zu verringern. Obwohl der Hersteller das bereitgestellte Sicherheitsupdate nicht verwendet hat, hat er dafür gesorgt, dass das Gerät nicht für die im Sicherheitsbulletin dokumentierte CVE anfällig ist. Wenn der Hersteller jedoch vom empfohlenen Sicherheitsupdate abweicht, riskiert er, das Problem falsch zu beheben, neue Sicherheitslücken einzuführen oder die Funktionalität des endgültigen Builds anderweitig zu verringern.

Wir arbeiten mit allen SoC-Partnern zusammen, um sicherzustellen, dass für alle Probleme in einem ASB Korrekturen vorhanden sind. Wir empfehlen Herstellern jedoch, für die gesamte Lebensdauer eines Geräts eine Wartungsvereinbarung mit ihren SoC-Anbietern abzuschließen. SoCs stellen die Unterstützung für einen Chipsatz möglicherweise früher als gewünscht ein. Daher ist es wichtig, vor der Auswahl des Gerätechipsatzes 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 das vorherige Android-SPL beibehalten und dem Build trotzdem die neuen verfügbaren Korrekturen hinzufügen. Diese Vorgehensweise führt jedoch letztendlich zu Problemen mit der Build-Zertifizierung, da Android dafür sorgt, dass der neueste Sicherheitspatch-Level auf zertifizierten Geräten verfügbar ist. Google empfiehlt, sich im Voraus mit Ihrem SoC abzustimmen, um dies zu vermeiden.

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

A: Wir verlangen nicht, dass Patches übernommen werden, um einen Android-Sicherheitspatch-Level (SPL) zu deklarieren. Wir verlangen jedoch, dass der Hersteller bestätigt, dass sein Build nicht für das Problem anfällig ist.

Ein Beispiel ist, wenn eine zu patchende Komponente im System des Herstellers nicht 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 davon, wenn ein Hersteller beispielsweise nur kritische Patches beheben möchte, aber andere anwendbare Patches nicht berücksichtigt, was dazu führen würde, dass ein Sicherheitstest fehlschlägt. In diesem Fall wird davon ausgegangen, dass das SPL nicht erreicht wurde.