chrome.enterprise.platformKeys

Beschreibung

Verwenden Sie die chrome.enterprise.platformKeys API, um Schlüssel zu generieren und Zertifikate für diese Schlüssel zu installieren. Die Zertifikate werden von der Plattform verwaltet und können für die TLS-Authentifizierung, den Netzwerkzugriff oder von anderen Erweiterungen über chrome.platformKeys verwendet werden.

Berechtigungen

enterprise.platformKeys

Verfügbarkeit

Konzepte und Verwendung

Die typische Verwendung dieser API zum Registrieren eines Clientzertifikats umfasst die folgenden Schritte:

  • Alle verfügbaren Tokens mit enterprise.platformKeys.getTokens() abrufen.

  • Suchen Sie das Token, bei dem id gleich "user" ist. Verwenden Sie dieses Token anschließend.

  • Generieren Sie ein Schlüsselpaar mit der generateKey()-Token-Methode (definiert in SubtleCrypto). Dadurch wird der Handle für den Schlüssel zurückgegeben.

  • Exportieren Sie den öffentlichen Schlüssel mit der exportKey()-Token-Methode (definiert in SubtleCrypto).

  • Erstellen Sie die Signatur der Daten der Zertifizierungsanfrage mit der sign()-Token-Methode (definiert in SubtleCrypto).

  • Füllen Sie den Zertifizierungsantrag aus und senden Sie ihn an die Zertifizierungsstelle.

  • Wenn ein Zertifikat empfangen wird, importieren Sie es mit [enterprise.platformKeys.importCertificate()`[3]

Hier ist ein Beispiel, das die wichtigsten API-Interaktionen zeigt, mit Ausnahme des Erstellens und Sendens der Zertifizierungsanfrage:

function getUserToken(callback) {   chrome.enterprise.platformKeys.getTokens(function(tokens) {     for (var i = 0; i < tokens.length; i++) {       if (tokens[i].id == "user") {         callback(tokens[i]);         return;       }     }     callback(undefined);   }); }  function generateAndSign(userToken) {   var data = new Uint8Array([0, 5, 1, 2, 3, 4, 5, 6]);   var algorithm = {     name: "RSASSA-PKCS1-v1_5",     // RsaHashedKeyGenParams     modulusLength: 2048,     publicExponent:         new Uint8Array([0x01, 0x00, 0x01]),  // Equivalent to 65537     hash: {       name: "SHA-256",     }   };   var cachedKeyPair;   userToken.subtleCrypto.generateKey(algorithm, false, ["sign"])     .then(function(keyPair) {             cachedKeyPair = keyPair;             return userToken.subtleCrypto.exportKey("spki", keyPair.publicKey);           },           console.log.bind(console))     .then(function(publicKeySpki) {             // Build the Certification Request using the public key.             return userToken.subtleCrypto.sign(                 {name : "RSASSA-PKCS1-v1_5"}, cachedKeyPair.privateKey, data);           },           console.log.bind(console))     .then(function(signature) {               // Complete the Certification Request with |signature|.               // Send out the request to the CA, calling back               // onClientCertificateReceived.           },           console.log.bind(console)); }  function onClientCertificateReceived(userToken, certificate) {   chrome.enterprise.platformKeys.importCertificate(userToken.id, certificate); }  getUserToken(generateAndSign);

Typen

Algorithm

Chrome 110 und höher

Typ des zu generierenden Schlüssels.

Enum

"RSA"

"ECDSA"

ChallengeKeyOptions

Chrome 110 und höher

Attribute

  • Challenge

    ArrayBuffer

    Eine von der Verified Access Web API ausgegebene Challenge.

  • registerKey

    RegisterKeyOptions optional

    Wenn vorhanden, wird der angefochtene Schlüssel mit dem Token des angegebenen scope registriert. Der Schlüssel kann dann einem Zertifikat zugeordnet und wie jeder andere Signaturschlüssel verwendet werden. Bei nachfolgenden Aufrufen dieser Funktion wird dann ein neuer Enterprise-Schlüssel im angegebenen scope generiert.

  • Bereich

    Ebene

    Welcher Enterprise-Schlüssel soll für die Challenge verwendet werden?

RegisterKeyOptions

Chrome 110 und höher

Attribute

  • Algorithmus

    Algorithmus

    Welchen Algorithmus der registrierte Schlüssel verwenden soll.

Scope

Chrome 110 und höher

Gibt an, ob der Enterprise-Nutzerschlüssel oder der Enterprise-Geräteschlüssel verwendet werden soll.

Enum

"USER"

"MACHINE"

Token

Attribute

  • id

    String

    Hiermit wird diese Token eindeutig identifiziert.

    Statische IDs sind "user" und "system", die sich auf das nutzerspezifische bzw. das systemweite Hardware-Token der Plattform beziehen. Alle anderen Tokens (mit anderen Kennungen) können von enterprise.platformKeys.getTokens zurückgegeben werden.

  • softwareBackedSubtleCrypto

    SubtleCrypto

    Chrome 97 und höher

    Implementiert die SubtleCrypto-Schnittstelle von WebCrypto. Die kryptografischen Vorgänge, einschließlich der Schlüsselgenerierung, werden durch Software unterstützt. Der Schutz der Schlüssel und damit die Implementierung der Eigenschaft, dass sie nicht extrahiert werden können, erfolgt in der Software. Daher sind die Schlüssel weniger geschützt als hardwaregestützte Schlüssel.

    Es können nur nicht extrahierbare Schlüssel generiert werden. Die unterstützten Schlüsseltypen sind RSASSA-PKCS1-V1_5 und RSA-OAEP (in Chrome-Versionen 135 und höher) mit modulusLength bis zu 2048. Jeder RSASSA-PKCS1-V1_5-Schlüssel kann höchstens einmal zum Signieren von Daten verwendet werden, es sei denn, die Erweiterung ist über die KeyPermissions-Richtlinie auf die Zulassungsliste gesetzt. In diesem Fall kann der Schlüssel unbegrenzt verwendet werden. RSA-OAEP-Schlüssel werden seit Chrome-Version 135 unterstützt und können von Erweiterungen verwendet werden, die über dieselbe Richtlinie auf die Zulassungsliste gesetzt wurden, um andere Schlüssel zu entpacken.

    Schlüssel, die auf einem bestimmten Token generiert wurden, können nicht mit anderen Tokens oder mit window.crypto.subtle verwendet werden. Ebenso können Key-Objekte, die mit window.crypto.subtle erstellt wurden, nicht mit dieser Schnittstelle verwendet werden.

  • subtleCrypto

    SubtleCrypto

    Implementiert die SubtleCrypto-Schnittstelle von WebCrypto. Die kryptografischen Vorgänge, einschließlich der Schlüsselgenerierung, werden durch Hardware unterstützt.

    Es können nur nicht extrahierbare Schlüssel generiert werden. Die unterstützten Schlüsseltypen sind RSASSA-PKCS1-V1_5 und RSA-OAEP (in Chrome-Versionen 135 und höher) mit modulusLength bis zu 2048 und ECDSA mit namedCurve P-256. Jeder RSASSA-PKCS1-V1_5- und ECDSA-Schlüssel kann höchstens einmal zum Signieren von Daten verwendet werden, es sei denn, die Erweiterung ist über die KeyPermissions-Richtlinie auf die Zulassungsliste gesetzt. In diesem Fall kann der Schlüssel unbegrenzt verwendet werden. RSA-OAEP-Schlüssel werden seit Chrome-Version 135 unterstützt und können von Erweiterungen verwendet werden, die über dieselbe Richtlinie auf die Zulassungsliste gesetzt wurden, um andere Schlüssel zu entpacken.

    Schlüssel, die auf einem bestimmten Token generiert wurden, können nicht mit anderen Tokens oder mit window.crypto.subtle verwendet werden. Ebenso können Key-Objekte, die mit window.crypto.subtle erstellt wurden, nicht mit dieser Schnittstelle verwendet werden.

Methoden

challengeKey()

Chrome 110 und höher 
chrome.enterprise.platformKeys.challengeKey(
  options: ChallengeKeyOptions,
): Promise<ArrayBuffer>

Ähnlich wie challengeMachineKey und challengeUserKey, ermöglicht aber die Angabe des Algorithmus eines registrierten Schlüssels. Fordert einen hardwaregestützten Enterprise Machine Key an und gibt die Antwort als Teil eines Remote-Attestierungsprotokolls aus. Nur unter ChromeOS und in Verbindung mit der Verified Access Web API nützlich, die sowohl Challenges ausgibt als auch Antworten überprüft.

Eine erfolgreiche Bestätigung durch die Verified Access Web API ist ein starkes Signal dafür, dass das aktuelle Gerät ein legitimes ChromeOS-Gerät ist, das aktuelle Gerät von der bei der Bestätigung angegebenen Domain verwaltet wird, der aktuell angemeldete Nutzer von der bei der Bestätigung angegebenen Domain verwaltet wird und der aktuelle Gerätestatus der Unternehmensrichtlinie für Geräte entspricht. Eine Richtlinie kann beispielsweise festlegen, dass sich das Gerät nicht im Entwicklermodus befinden darf. Jede Geräteidentität, die durch die Bestätigung ausgegeben wird, ist eng an die Hardware des aktuellen Geräts gebunden. Wenn der Bereich "user" angegeben ist, ist die Identität auch eng an den aktuell angemeldeten Nutzer gebunden.

Diese Funktion ist stark eingeschränkt und schlägt fehl, wenn das aktuelle Gerät oder der aktuelle Nutzer nicht verwaltet wird oder wenn dieser Vorgang nicht explizit durch die Unternehmensrichtlinie für Geräte für den Aufrufer aktiviert wurde. Der angefochtene Schlüssel befindet sich nicht im "system"- oder "user"-Token und ist für keine andere API zugänglich.

Parameter

Ausgabe

  • Promise<ArrayBuffer>

    Chrome 131 und höher

challengeMachineKey()

Chrome 50 und höher Seit Chrome 110 eingestellt
chrome.enterprise.platformKeys.challengeMachineKey(
  challenge: ArrayBuffer,
  registerKey?: boolean,
): Promise<ArrayBuffer>

Verwenden Sie stattdessen challengeKey.

Fordert einen hardwaregestützten Enterprise Machine Key an und gibt die Antwort als Teil eines Remote-Attestierungsprotokolls aus. Nur unter ChromeOS und in Verbindung mit der Verified Access Web API nützlich, die sowohl Challenges ausgibt als auch Antworten überprüft. Eine erfolgreiche Überprüfung durch die Verified Access Web API ist ein starkes Signal für Folgendes: * Das aktuelle Gerät ist ein legitimes ChromeOS-Gerät. * Das aktuelle Gerät wird von der bei der Bestätigung angegebenen Domain verwaltet. * Der aktuell angemeldete Nutzer wird von der bei der Bestätigung angegebenen Domain verwaltet. * Der aktuelle Gerätestatus entspricht der Unternehmensgeräterichtlinie. Eine Richtlinie kann beispielsweise festlegen, dass sich das Gerät nicht im Entwicklermodus befinden darf. * Jede Geräteidentität, die durch die Bestätigung ausgegeben wird, ist eng an die Hardware des aktuellen Geräts gebunden. Diese Funktion ist stark eingeschränkt und schlägt fehl, wenn das aktuelle Gerät oder der aktuelle Nutzer nicht verwaltet wird oder wenn dieser Vorgang nicht explizit durch die Unternehmensrichtlinie für Geräte für den Aufrufer aktiviert wurde. Der Enterprise Machine Key befindet sich nicht im "system"-Token und ist nicht über andere APIs zugänglich.

Parameter

  • Challenge

    ArrayBuffer

    Eine von der Verified Access Web API ausgegebene Challenge.

  • registerKey

    boolean optional

    Chrome 59 und höher

    Wenn festgelegt, wird der aktuelle Enterprise Machine Key mit dem "system"-Token registriert und die Rolle des Enterprise Machine Key wird aufgegeben. Der Schlüssel kann dann einem Zertifikat zugeordnet und wie jeder andere Signaturschlüssel verwendet werden. Dieser Schlüssel ist ein 2048-Bit-RSA-Schlüssel. Bei nachfolgenden Aufrufen dieser Funktion wird dann ein neuer Enterprise Machine Key generiert.

Ausgabe

  • Promise<ArrayBuffer>

    Chrome 131 und höher

challengeUserKey()

Chrome 50 und höher Seit Chrome 110 eingestellt
chrome.enterprise.platformKeys.challengeUserKey(
  challenge: ArrayBuffer,
  registerKey: boolean,
): Promise<ArrayBuffer>

Verwenden Sie stattdessen challengeKey.

Fordert einen hardwaregestützten Enterprise-Nutzerschlüssel an und gibt die Antwort als Teil eines Remote-Attestierungsprotokolls aus. Nur unter ChromeOS und in Verbindung mit der Verified Access Web API nützlich, die sowohl Challenges ausgibt als auch Antworten überprüft. Eine erfolgreiche Überprüfung durch die Verified Access Web API ist ein starkes Signal für Folgendes: * Das aktuelle Gerät ist ein legitimes ChromeOS-Gerät. * Das aktuelle Gerät wird von der bei der Bestätigung angegebenen Domain verwaltet. * Der aktuell angemeldete Nutzer wird von der bei der Bestätigung angegebenen Domain verwaltet. * Der aktuelle Gerätestatus entspricht der Richtlinie für Unternehmensnutzer. Eine Richtlinie kann beispielsweise festlegen, dass sich das Gerät nicht im Entwicklermodus befinden darf. * Der von der Überprüfung ausgegebene öffentliche Schlüssel ist eng an die Hardware des aktuellen Geräts und den aktuell angemeldeten Nutzer gebunden. Diese Funktion ist stark eingeschränkt und schlägt fehl, wenn das aktuelle Gerät oder der aktuelle Nutzer nicht verwaltet wird oder wenn dieser Vorgang nicht explizit durch die Unternehmensnutzerrichtlinie für den Aufrufer aktiviert wurde. Der Enterprise User Key befindet sich nicht im "user"-Token und ist über keine andere API zugänglich.

Parameter

  • Challenge

    ArrayBuffer

    Eine von der Verified Access Web API ausgegebene Challenge.

  • registerKey

    boolean

    Wenn festgelegt, wird der aktuelle Enterprise-Nutzerschlüssel mit dem "user"-Token registriert und die Rolle des Enterprise-Nutzerschlüssels wird aufgegeben. Der Schlüssel kann dann einem Zertifikat zugeordnet und wie jeder andere Signaturschlüssel verwendet werden. Dieser Schlüssel ist ein 2048-Bit-RSA-Schlüssel. Bei nachfolgenden Aufrufen dieser Funktion wird dann ein neuer Enterprise User Key generiert.

Ausgabe

  • Promise<ArrayBuffer>

    Chrome 131 und höher

getCertificates()

chrome.enterprise.platformKeys.getCertificates(
  tokenId: string,
): Promise<ArrayBuffer[]>

Gibt die Liste aller Clientzertifikate zurück, die über das angegebene Token verfügbar sind. Kann verwendet werden, um das Vorhandensein und den Ablauf von Clientzertifikaten zu prüfen, die für eine bestimmte Authentifizierung verwendet werden können.

Parameter

  • tokenId

    String

    Die ID eines Tokens, das von getTokens zurückgegeben wird.

Ausgabe

  • Promise<ArrayBuffer[]>

    Chrome 131 und höher

getTokens()

chrome.enterprise.platformKeys.getTokens(): Promise<Token[]>

Gibt die verfügbaren Tokens zurück. In der Sitzung eines regulären Nutzers enthält die Liste immer das Token des Nutzers mit id "user". Wenn ein systemweites TPM-Token verfügbar ist, enthält die zurückgegebene Liste auch das systemweite Token mit id "system". Das systemweite Token ist für alle Sitzungen auf diesem Gerät (z.B. einem Chromebook) identisch.

Ausgabe

  • Promise<Token[]>

    Chrome 131 und höher

importCertificate()

chrome.enterprise.platformKeys.importCertificate(
  tokenId: string,
  certificate: ArrayBuffer,
): Promise<void>

Importiert certificate in das angegebene Token, wenn der zertifizierte Schlüssel bereits in diesem Token gespeichert ist. Nach einer erfolgreichen Zertifizierungsanfrage sollte diese Funktion verwendet werden, um das erhaltene Zertifikat zu speichern und dem Betriebssystem und Browser zur Authentifizierung zur Verfügung zu stellen.

Parameter

  • tokenId

    String

    Die ID eines Tokens, das von getTokens zurückgegeben wird.

  • Zertifikat

    ArrayBuffer

    Die DER-Codierung eines X.509-Zertifikats.

Ausgabe

  • Promise<void>

    Chrome 131 und höher

removeCertificate()

chrome.enterprise.platformKeys.removeCertificate(
  tokenId: string,
  certificate: ArrayBuffer,
): Promise<void>

Entfernt certificate aus dem angegebenen Token, falls vorhanden. Sollte verwendet werden, um veraltete Zertifikate zu entfernen, damit sie bei der Authentifizierung nicht berücksichtigt werden und die Zertifikatauswahl nicht unübersichtlich wird. Sollte verwendet werden, um Speicherplatz im Zertifikatsspeicher freizugeben.

Parameter

  • tokenId

    String

    Die ID eines Tokens, das von getTokens zurückgegeben wird.

  • Zertifikat

    ArrayBuffer

    Die DER-Codierung eines X.509-Zertifikats.

Ausgabe

  • Promise<void>

    Chrome 131 und höher