Diese Seite wurde von der Cloud Translation API übersetzt.

Versionsbindung

In Keymaster 1 wurden alle Keymaster-Schlüssel kryptografisch an das Gerät gebunden. Root of Trust oder der Schlüssel für den bestätigten Bootmodus. In Keymaster 2 und 3 werden alle Schlüssel sind außerdem an das Betriebssystem und die Patchebene des System-Images gebunden. So kann ein Angreifer, der eine Schwachstelle in einem alten Die Systemversion oder die TEE-Software kann kein Rollback auf das anfällige Gerät durchführen. Version und verwenden Schlüssel, die mit der neueren Version erstellt wurden. Wenn außerdem ein Schlüssel mit einer bestimmten Version und einem bestimmten Patch-Level auf einem Gerät verwendet wird, das aktualisiert wurde auf eine neuere Version oder Patch-Level haben, wird der Schlüssel aktualisiert, und die vorherige Version des Schlüssels ungültig geworden ist. Da das Gerät dann nach einem Upgrade rasten die Tasten mit dem Gerät vorwärts, aber alle Wenn Sie das Gerät auf eine frühere Version zurücksetzen, werden die Tasten unbrauchbar.

Um die modulare Struktur von Treble zu unterstützen und die Bindung von system.img an aufzuheben boot.img hat Keymaster 4 das Schlüsselversions-Bindungsmodell geändert, sodass Patchebenen für jede Partition. So kann jede Partition aktualisiert werden und gleichzeitig Rollbackschutz bieten.

In Android 9: boot, system und vendor alle Partitionen haben ihre eigene Patchebene.

Geräte mit Android Verified Boot (AVB) können alle Patchebenen und die Systemversion in vbmeta, sodass der Bootloader sie Keymaster. Bei verketteten Partitionen lauten die Versionsinformationen für die Partition in der verketteten vbmeta enthalten sein. Generell sollten Versionsinformationen im vbmeta struct mit den Bestätigungsdaten (Hash oder Hashtree) für eine bestimmte Partition an.
Auf Geräten ohne AVB: <ph type="x-smartling-placeholder">
- Implementierungen des verifizierten Bootmodus müssen einen Hash der Version bereitstellen. Metadaten an Bootloader, damit der Bootloader den Hash an Keymaster bereitstellen kann.
- boot.img kann Patchebene weiterhin im Header speichern
- system.img kann Patchlevel und Betriebssystemversion weiterhin schreibgeschützt speichern Eigenschaften
- vendor.img speichert die Patchebene im schreibgeschützten Attribut. ro.vendor.build.version.security_patch.
- Der Bootloader kann einen Hash aller Daten bereitstellen, die durch den verifizierten Bootmodus validiert wurden. zum Keymaster.
Verwenden Sie in Android 9 die folgenden Tags, um Versionsinformationen für folgende Partitionen: <ph type="x-smartling-placeholder">
- VENDOR_PATCH_LEVEL: Partition vendor
- BOOT_PATCH_LEVEL: Partition boot
- OS_PATCH_LEVEL und OS_VERSION: system-Partition. (OS_VERSION wird entfernt aus den boot.img-Header.
Bei Keymaster-Implementierungen sollten alle Patchebenen unabhängig behandelt werden. Schlüssel sind verwendbar, wenn alle Versionsinformationen mit den Werten übereinstimmen, die mit einem Schlüssel verknüpft sind, und IKeymaster::upgradeDevice() rollt auf ein höheres Patchlevel, wenn erforderlich.

HAL-Änderungen

Um Versionsbindung und Versionsattestierung zu unterstützen, wurde in Android 7.1 die Tags Tag::OS_VERSION und Tag::OS_PATCHLEVEL sowie die configure und upgradeKey. Die Versions-Tags werden von Keymaster 2+ Implementierungen automatisch allen neu generierten (oder aktualisierte) Schlüssel. Jeder Versuch, einen Schlüssel ohne Betriebssystem zu verwenden, Version oder Patch-Level, die der aktuellen Betriebssystemversion oder dem Patch-Level entsprechen, wird mit ErrorCode::KEY_REQUIRES_UPGRADE abgelehnt.

Tag::OS_VERSION ist ein UINT-Wert, der für Haupt-, Neben- und Sub-Minor-Teile einer Android-Systemversion als MMmmss, wobei MM die Hauptversion, mm die Nebenversion und ss die Sub-Minor-Version ist Version. Beispiel: 6.1.2 wird als 060102 dargestellt.

Tag::OS_PATCHLEVEL ist ein UINT-Wert, der für Jahr und Monat der letzten Systemaktualisierung im Format JJJJMM, wobei JJJJ für den Wert das vierstellige Jahr und MM der zweistellige Monat. Beispiel: März 2016 wäre dargestellt als 201603.

UpgradeKey

Damit Schlüssel auf die neue Betriebssystemversion und das neue Patch-Level des Systems aktualisiert werden können Image hat Android 7.1 dem HAL die Methode upgradeKey hinzugefügt:

Keymaster 3

    upgradeKey(vec keyBlobToUpgrade, vec upgradeParams)
        generates(ErrorCode error, vec upgradedKeyBlob);

Keymaster 2

keymaster_error_t (*upgrade_key)(const struct keymaster2_device* dev,
    const keymaster_key_blob_t* key_to_upgrade,
    const keymaster_key_param_set_t* upgrade_params,
    keymaster_key_blob_t* upgraded_key);

dev ist die Gerätestruktur
keyBlobToUpgrade ist der Schlüssel, der aktualisiert werden muss
upgradeParams sind Parameter, die zum Upgrade des Schlüssels erforderlich sind. Diese enthält Tag::APPLICATION_ID und Tag::APPLICATION_DATA, die zum Entschlüsseln des Schlüssels erforderlich sind blob, wenn sie während der Generierung bereitgestellt wurden.
upgradedKeyBlob ist der Ausgabeparameter, mit dem die Variable neuen Schlüssel-Blob.

Wenn upgradeKey mit einem Schlüssel-BLOB aufgerufen wird, der nicht geparst werden kann, oder ansonsten ungültig ist, wird ErrorCode::INVALID_KEY_BLOB zurückgegeben. Wenn es mit einem Schlüssel aufgerufen wird, dessen Patch-Level größer als der aktuelle Systemwert ist, wird ErrorCode::INVALID_ARGUMENT zurückgegeben. Wenn sie mit einem Schlüssel aufgerufen wird, deren Betriebssystemversion größer als der aktuelle Systemwert ist, und der Systemwert nicht Null ist, wird ErrorCode::INVALID_ARGUMENT zurückgegeben. Betriebssystemversion Upgrades von einem Wert ungleich null auf null sind zulässig. Im Fall von Fehlern Kommunikation mit der sicheren Welt führt, gibt sie einen entsprechenden Fehlerwert (z.B. ErrorCode::SECURE_HW_ACCESS_DENIED, ErrorCode::SECURE_HW_BUSY). Andernfalls wird zurückgegeben, ErrorCode::OK und gibt ein neues Schlüssel-BLOB in upgradedKeyBlob.

keyBlobToUpgrade bleibt auch nach dem upgradeKey gültig und könnte theoretisch bei einem Downgrade des Geräts wieder verwendet werden. In ruft der Schlüsselspeicher in der Regel deleteKey im keyBlobToUpgrade-Blob kurz nach dem Aufruf von upgradeKey Wenn keyBlobToUpgrade ein Tag hätte Tag::ROLLBACK_RESISTANT, dann sollte upgradedKeyBlob haben (und sollte auch Rollback-resistent sein).

Sichere Konfiguration

Hinweis:Keymaster 3 hat die Keymaster 2-Methode entfernt. configure. Die Informationen, die zuvor Keymaster HALs zur Verfügung gestellt wurden bis configure ist in den Systemeigenschaftendateien verfügbar. Hersteller-Implementierungen lesen diese Dateien beim Start.

Zur Implementierung der Versionsbindung benötigt der Keymaster TA eine Möglichkeit, den Empfang der aktuellen Betriebssystemversion und dem aktuellen Patch-Level (Versionsinformationen) und sicherzustellen, Die erhaltenen Informationen stimmen mit den Informationen zur laufenden System.

Um die sichere Übermittlung von Versionsinformationen an den TA zu ermöglichen, wird eine OS_VERSION Feld wurde dem Boot-Image-Header hinzugefügt. Boot-Image-Build wird dieses Feld automatisch ausgefüllt. OEMs und Keymaster-TA-Implementierer müssen gemeinsam die Geräte-Bootloader ändern, um die Version zu extrahieren aus dem Boot-Image und übergeben sie vor dem nicht sicheren das System gestartet ist. Dadurch wird sichergestellt, dass Angreifer die Bereitstellung nicht beeinträchtigen können. Versionsinformationen an den TA.

Außerdem muss sichergestellt werden, dass das System-Image dieselbe Version Informationen als Boot-Image. Zu diesem Zweck wurde die Methode „configure“ an den Keymaster HAL:

keymaster_error_t (*configure)(const struct keymaster2_device* dev,
  const keymaster_key_param_set_t* params);

Das Argument params enthält Tag::OS_VERSION und Tag::OS_PATCHLEVEL Diese Methode wird von keymaster2-Clients aufgerufen. nach dem Öffnen des HAL, aber vor dem Aufrufen anderer Methoden. Wenn eine andere Methode vor dem Konfigurieren aufgerufen wird, gibt der TA ErrorCode::KEYMASTER_NOT_CONFIGURED

Wenn configure nach dem Starten des Geräts zum ersten Mal aufgerufen wird, sollte überprüft werden, ob die angegebenen Versionsinformationen mit den dem Bootloader. Wenn die Versionsinformationen nicht übereinstimmen, configure gibt ErrorCode::INVALID_ARGUMENT zurück, und alle Andere Keymaster-Methoden werden weiterhin ErrorCode::KEYMASTER_NOT_CONFIGURED Wenn die Informationen übereinstimmen, configure gibt ErrorCode::OK zurück und anderer Keymaster wieder ganz normal funktionieren.

Nachfolgende Aufrufe von configure geben den gleichen Wert zurück, der vom und den Status von Keymaster nicht ändern. Dieser Prozess erfordert, dass alle OTAs sowohl System- als auch Boot-Images aktualisieren; Sie können nicht aktualisiert werden um die Versionsinformationen synchron zu halten.

Weil configure von dem System aufgerufen wird, dessen Inhalt es ist die Daten validieren sollen, haben Angreifer nur ein enges Zeitfenster, in dem sie das System-Image kompromittieren und Versionsinformationen mit dem Boot-Image übereinstimmt, aber nicht der tatsächlichen Systemversion entspricht. Die Kombination aus Boot-Image-Überprüfung und dm-verity-Validierung des System-Images und die Tatsache, dass configure sehr früh im Systemstart erschwert die Nutzung dieses Zeitfensters.