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) geprüft 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 ist nicht für Endnutzer (z. B. Fahrzeugbesitzer) bestimmt sind.
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. Feedback geben anmanufacturers-guide-android@googlegroups.com.
Glossar
| Begriff | Definition |
|---|---|
| ACC | Android-Kompatibilitätsvereinbarung. Früher als Android Anti-Fragmentation Agreement (AFA) bezeichnet. |
| AOSP | Open-Source-Projekt von Android |
| ASB | Sicherheitsbulletin für Android |
| BSP | Board-Supportpaket |
| Logo: CDD | Dokument zur Kompatibilitätsdefinition |
| Logo: CTS | Kompatibilitätstest-Suite |
| FOTA | Firmware per WLAN |
| GPS | Global Positioning System |
| MISSRA | Motor Industry Software Reliability Association |
| NIST | National Institute of Standards and Technology |
| OBD | On-Board-Diagnose (OBD-II ist eine Verbesserung gegenüber OBD-I sowohl hinsichtlich der Standardisierung) |
| OEM | Erstausrüster |
| Betriebssystem | Betriebssystem |
| SEI | Software Engineering Institute |
| SoC | System-on-a-Chip |
| SOP | Produktionsbeginn |
| SPL | Stand der Sicherheits-Patches |
| TPMS | Reifendruck-Kontrollsystem |
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 Android 5.0 (Lollipop) oder höher mit Stand März 2017 (aktuelle Zahlen finden Sie auf der Android Dashboard. 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 wurde erreicht Über 2,2 Millionen (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. Die Android-Kompatibilitätsprogramme stellen sicher, dass jede Android-App auf allen Android-kompatiblen Gerät, das die erforderlichen Funktionen für die App unterstützt.
Google veröffentlicht regelmäßig neue Betriebssystemversionen, Betriebssystemsicherheitsupdates und Informationen zu entdeckten Sicherheitslücken. Das Android- Sicherheitsbulletin sollten vom Hersteller auf die Anwendbarkeit dieser Updates auf das unterstützte Android-Betriebssystem geprüft werden. zu verbessern. Hier finden Sie einen Überblick über die Sicherheits-, Kompatibilitäts- und Build-Systeme von Android:
- Android-Geräte schützen
- Sicherheitsupdates und ‑ressourcen
- Kompatibilitätstest-Suite
- Codenamen, Tags und Build-Nummern
Verbundene Fahrzeuge (kanonische, langlebige Produkte)
Mit der Einführung des AM-Radios in den 1920er-Jahren begannen die Vernetzung von Fahrzeugen. 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. Heute Integrierte Sensoren und Konnektivität (z. B. GPS) unterstützen Sicherheit und autonomes Fahren Systeme.
Wenn die Anzahl der Fahrzeugverbindungen zunimmt, nimmt auch das Gebiet des potenziellen Fahrzeugangriffs zu. Oberfläche. 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 zu gewährleisten. eines Produkts in der Praxis. Kurz gesagt: Hersteller müssen sich über bekannte Sicherheitslücken im Produkt im Klaren sein und diese auf risikobasierte Weise beheben.
Langfristige Sicherheit gewährleisten
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 Bewertung des Produkts anhand der CVE-Datenbank (Common Vulnerabilities and Exposures)
- Erfassen von Bedrohungsdaten für produktbezogene Sicherheitsmängel
- Sicherheitstests
- Aktive Analyse von Android-Sicherheitsbulletins.
Beispiel für Betriebssystem- und Sicherheitspatch-Updates (IVIs mit Android):
Abbildung 1. Beispiel eines großen Rollouts von Betriebssystem- und Sicherheitsupdates während der Lebensdauer des Fahrzeugs.
| # | Schritt | Aktivitäten |
|---|---|---|
|
1. |
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. |
| 2. | Ersteinführung | Einige Monate bevor Android X als erste im Produkt ausgelieferte Betriebssystemversion verfügbar ist,
Die Updates stammen aus den Android-Sicherheitsbulletins (ASBs) und möglicherweise aus anderen Quellen,
für den Hersteller wertvoll. y2 = das zweite Sicherheitsbulletin für Android-Version X,
vom Hersteller auf Android X angewendet (zurückportiert). Dieses Update ist im Produkt enthalten und die Produktionsuhr beginnt mit Android X.y2 bei Null.
In diesem Beispiel hat der Hersteller die Entscheidung getroffen, den Artikel nicht zu versenden, neuestem Jahresrelease von Android X+1. Gründe für die Einführung der neuesten Version sind unter anderem die Hinzufügung 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 der Zeitmangel im Rahmen des Fahrzeugentwicklungs- und -einführungsprozesses, der für die Integration, Prüfung und Validierung der Änderungen erforderlich ist, einschließlich der Einhaltung aller behördlichen und Zertifizierungsanforderungen. |
| 3. | Vollständiges Betriebssystemupdate | Nach dem SOP veröffentlicht der Hersteller
Android X+2 OS-Update, zwei Android-Releases
nach der Version, die für das ursprüngliche Produkt (Android X0) verwendet wurde. ASB-Sicherheitsupdates sind verfügbar
für die API-Ebene (ab Versanddatum), sodass die Aktualisierung als X+2.y0 (ca. 1,25) erfolgt.
Jahre nach SOP. Dieses Betriebssystemupdate ist möglicherweise nicht mit Feldprodukten kompatibel. Ist dies der Fall,
könnte ein Plan zur Aktualisierung
bereitgestellter Fahrzeuge erstellt werden.
Sofern keine anderen Geschäftsvereinbarungen bestehen, liegt die Entscheidung für ein vollständiges Betriebssystemupdate ausschließlich im Ermessen des Herstellers. |
| 4. | Sicherheitsupdate | Zwei Jahre nach der Produktionslaufzeit des Fahrzeugs flickt der Hersteller
Android X + 2. Diese Entscheidung basiert auf der Risikobewertung des Herstellers. Hersteller
wählt das dritte ASB-Sicherheitsupdate für Version X+2 als Grundlage für das Update. 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 Bulletin 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 | Wiederholen Sie Schritt 3 (vollständiges Betriebssystemupdate). Mit dem zweiten vollständigen Update wird das Produkt auf
Android X+4, drei Jahre nach der Produktionslaufzeit des Fahrzeugs. Der Hersteller muss jetzt die neuen 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 eine
ohne Sicherheitsupdates zu aktualisieren. Das Produkt befindet sich daher jetzt im Betriebssystem- und Android-Sicherheitspatch (X+4.y0).
Niveau.
In diesem Beispiel ist X+4 aufgrund von Hardwareeinschränkungen die letzte Hauptversion von Android, die wird für dieses Produkt zur Verfügung gestellt, wobei die erwartete Lebensdauer des Fahrzeugs mindestens 6 Jahre beträgt. erfordert weiterhin Sicherheitssupport. |
| ⑥ | 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). Außerdem sollte der Hersteller wissen, Sicherheitsprobleme bei nicht mehr unterstützten Android-Versionen werden in den ASB. |
| ⑦ | 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 die 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:
- Neueste Versionen externer Bibliotheken und Open-Source-Komponenten verwenden.
- Nehmen Sie keine störenden Debugging-Funktionen in Release-Versionen des Betriebssystems auf.
- 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 über den gesamten Lebenszyklus des Systems gehören:
- Führen Sie eine Bedrohungsmodellierung durch, um Assets, Bedrohungen und potenzielle Risikominderungen zu bewerten und zu identifizieren.
- Architektur-/Designüberprüfung durchführen, um ein sicheres und solides Design zu gewährleisten
- Führen Sie regelmäßige Codeüberprüfungen durch, um Anti-Muster und Bugs so schnell wie möglich zu identifizieren.
- 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 auftauchen)
- Fuzzing-Tests (als Teil der Unittest-Suite)
- Verwenden Sie Analysetools für statische Quellcodes (Scan-Build, Lint usw.), um potenzielle Probleme.
- 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 Softwarequellcode und die Releasekonfiguration/-version entwickelt.
- Eine Patch-Verwaltungsstrategie zum Generieren und Bereitstellen von Software-Patches haben
Richtlinie für den Sicherheits-Backport
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:
- Berichte zu Sicherheitslücken erhalten und untersuchen.
- Sicherheitsupdates erstellen, testen und veröffentlichen
- Stellen Sie wiederkehrende Veröffentlichungen von Sicherheitsupdates und Details zum Sicherheitsbulletin bereit.
- Führen Sie eine Schweregradbewertung gemäß den festgelegten Richtlinien durch.
Drei Jahre nach dem öffentlichen Veröffentlichungsdatum des API-Levels empfiehlt Google Folgendes: Richtlinien:
- Verwenden Sie einen Drittanbieter (z. B. einen SoC-Anbieter oder einen Kernel-Anbieter) für den Backport-Support für Betriebssystemsicherheitsupdates, die älter als drei Jahre nach der API-Veröffentlichung sind.
- Beauftragen Sie einen Drittanbieter damit, Codeüberprüfungen mithilfe der öffentlich bereitgestellten ASBs durchzuführen. Während ASBs finden Sicherheitslücken für die derzeit unterstützte Version, kann ein Hersteller das bereitgestellte um die neu veröffentlichten Updates mit früheren Versionen zu vergleichen. Anhand dieser Daten können Wirkungsanalysen durchführen und möglicherweise ähnliche Patches für Betriebssystemversionen, die älter als drei sind, generieren Jahre nach der API-Veröffentlichung.
- Laden Sie gegebenenfalls Sicherheitsupdates in das Android Open Source Project (AOSP) hoch.
- Der Hersteller muss die Handhabung von Sicherheitsupdates für anbieterspezifischen Code koordinieren. (z. B. proprietärer gerätespezifischer Code).
- Der Hersteller sollte sich der Vertraulichkeitsvereinbarung für das Sicherheitsbulletin für die Partnervorschau für Android anschließen.
Gruppe erforderlich (die Unterzeichnung rechtlicher Vereinbarungen wie der Vertraulichkeitsvereinbarung für Entwickler erforderlich). Bulletins sollten Folgendes enthalten:
- Ankündigungen
- Zusammenfassung der Probleme nach Patch-Level, einschließlich CVE und Schweregrad
- Details zu Sicherheitslücken (sofern zutreffend)
Weitere Referenzen
Anleitungen für sicheres Codieren und Softwareentwicklung finden Sie hier:
- Motor Industry Software Reliability Association (MISRA)
- Software Engineering Institute (SEI) Tools & Methods
- National Institute of Standards and Technologie (NIST):
Empfohlene Produktpraktiken
Google empfiehlt die folgenden empfohlenen Vorgehensweisen.
Allgemeine Richtlinien für die Markteinführung
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, der Hersteller muss jedoch die Produktstabilität älterer Betriebssystemversionen 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 starten.
- Für jede veröffentlichte Android-Betriebssystemversion die Konformität mit der Android-Kompatibilität mit einem Over-the-Air-Kampagne.
- Implementieren Sie das Produkt mit Android Firmware Over-the-Air-fähig (FOTA), was schnell und kundenfreundlich ist. Aktualisierungen. Für die OTA-Aktualisierung sollten Sicherheitsbest Practices wie Codesignatur und TLS-Verbindung zwischen Produkt und IT-Backoffice verwendet werden.
- Senden die unabhängig voneinander Android-Sicherheitslücken für das Android Security-Team identifizierten.
Hinweis: Google hat den Gerätetyp oder branchenspezifische in den Android-Sicherheitsbulletins. Da Google jedoch den Kernel, die Treiber oder die Chipsätze eines bestimmten Geräts (Fahrzeug, Fernseher, Wearable, Smartphone usw.) nicht kennt, Google hat keine eine deterministische Möglichkeit, ein Sicherheitsproblem mit einem Gerätetyp zu kennzeichnen.
Richtlinien für den Produktzyklus
Der Hersteller sollte bei Verbesserungen während des Produktzyklus alle Anstrengungen unternehmen, die neueste Betriebssystemversion oder Sicherheitsupdates für die verwendete Version zu verwenden. Aktualisierungen können während wiederkehrender regelmäßige Produktupdates oder Hotfixes zur Behebung von Qualitäts- und/oder anderen Problemen zu erhalten. Zu den empfohlenen Best Practices gehören:
- Erstellen Sie einen Plan für Treiber-, Kernel- und Protokollaktualisierungen.
- Sie müssen eine branchenübliche Methode zur Bereitstellung von Updates für eingesetzte Fahrzeuge verwenden.
Compatibility Definition Document (CDD)
Im Compatibility Definition Document (CDD) werden die Anforderungen für ein zu berücksichtigendes Gerät beschrieben. Mit Android kompatibel. 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 folgende grundlegende Schritte erforderlich:
- Der Partner unterzeichnet die Android-Kompatibilitätsvereinbarung mit Google. Ein Technical Solutions Consultant (TSC) wird dann als Ansprechpartner zugewiesen.
- Der Partner schließt die CDD-Überprüfung für die Android-Version des Produkts ab.
- Der Partner führt die CTS-Ergebnisse (siehe unten) so lange aus und sendet sie ein, bis sie 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.
CTS-Workflow
Im CTS-Workflow wird der Testumgebung, Ausführen von Tests, Interpretieren der Ergebnisse und Verständnis des CTS-Quellcodes. Die folgenden Richtlinien sollen CTS-Nutzern (z. B. Entwicklern, Herstellern) helfen, die CTS effektiv und effizient zu nutzen.
- Führen Sie häufig Tests durch. CTS ist ein automatisiertes Tool, das in Ihr Build-System integrieren. Die häufige Ausführung von CTS kann Ihnen helfen, Fehler schnell und frühzeitig zu finden, kann es zu Beeinträchtigungen oder Regressionen kommen.
- 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-Versionen können die CTS mit Fehlerkorrekturen aktualisieren, Verbesserungen und neue Tests. 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 bestehen
Bei einem Android-kompatiblen Produkt stellt Google sicher, dass die Testergebnisse des CTS und des CTS Verifier für das Gerät 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. Dabei passiert Folgendes:
- Der Hersteller stellt Google die vorgeschlagenen CTS-Patches, Patch-Validierungen und Begründungen zur Verfügung, um seine Behauptung zu belegen.
- Google prüft das eingereichte Material und aktualisiert die entsprechenden CTS-Tests, falls sie angenommen werden, dass das Gerät in der nächsten CTS-Version bestehen würde.
Wenn ein CTS-Test nach der Anwendung eines Sicherheitspatches plötzlich fehlschlägt, muss der Hersteller den Patch so ändern, dass er die Kompatibilität nicht beeinträchtigt, ODER nachweisen, dass der Test falsch ist, und eine Korrektur für den Test bereitstellen (wie oben beschrieben).
Das CTS ist weiterhin für die Überprüfung von Testkorrekturen offen. 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 das Sicherheits-Backporting
F: Wenn ein Hersteller alle AOSP-Patches aus einem ASB integriert, aber nicht oder ob Patches von einem BSP-Anbieter gefunden werden, (Beispiel: den entsprechenden Patch auf die Plattform/den 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 den Sicherheitsupdates von BSP-Anbieter ODER wenn von einem ASB vorgeschriebene Sicherheitsupdates nicht von den Anbietern bereitgestellt werden?
A: Ein ASB beschreibt Sicherheitslücken (aufgeführt in einer Liste von CVEs) und bietet häufig entsprechende Sicherheitstests. Ziel ist es, sicherzustellen, dass die aufgeführten Sicherheitslücken reproduziert werden und dass das Gerät zugehörige Sicherheitstests bestehen kann. 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. Die kann der Hersteller die bereitgestellten Sicherheitsupdates verwenden. verwendet werden, verwenden Sie stattdessen diese Änderung.
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 die der Hersteller bestimmt, dass die Komponente auf dem Gerät nicht benötigt wird oder nicht von der CDD vorgeschrieben ist (oder Zertifizierungsprüfungen), kann der Hersteller das Bauteil entfernen, um künftige Wartungen und die Angriffsfläche 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. Sie können jedoch vom empfohlenen Sicherheitsupdate abweichen, geht der Hersteller das Risiko ein, zur Behebung des Problems, zur Einführung neuer Sicherheitslücken oder zur anderweitigen Reduzierung der Funktionalität des endgültigen Builds.
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. Dies wird jedoch letztendlich zu Problemen mit dem Build führen. Zertifizierung (da Android sicherstellt, dass auf den zertifizierten Geräte). Google empfiehlt, im Voraus mit Ihrem SoC zu arbeiten, um das 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 kann das System konform sein, ohne dass der Hersteller einen Patch ausführen 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.