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 eine andere Erweiterung über „chrome.platformKeys“ verwendet werden.
Berechtigungen
enterprise.platformKeys
Verfügbarkeit
Konzepte und Verwendung
Diese API wird üblicherweise so verwendet, um ein Clientzertifikat zu registrieren:
Rufen Sie alle verfügbaren Tokens mit
enterprise.platformKeys.getTokens()
ab.Suchen Sie das Token, bei dem
id
gleich"user"
ist. Verwenden Sie dieses Token später.Generieren Sie mit der Token-Methode
generateKey()
(in SubtleCrypto definiert) ein Schlüsselpaar. Dadurch wird ein Handle auf den Schlüssel zurückgegeben.Exportieren Sie den öffentlichen Schlüssel mit der Token-Methode
exportKey()
(definiert in SubtleCrypto).Erstellen Sie die Signatur der Daten der Zertifizierungsanfrage mithilfe der Token-Methode
sign()
(definiert in SubtleCrypto).Füllen Sie die Zertifizierungsanfrage aus und senden Sie sie an die Zertifizierungsstelle.
Wenn ein Zertifikat empfangen wurde, importieren Sie es mit [
enterprise.platformKeys.importCertificate()
`[3]
Das folgende Beispiel zeigt die wichtigsten API-Interaktionen 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
Typ des Schlüssels, der generiert werden soll.
Enum
„RSA“
„ECDSA“
ChallengeKeyOptions
Attribute
-
Challenge
ArrayBuffer
Eine Herausforderung, die von der Verified Access Web API ausgelöst wurde.
-
registerKey
RegisterKeyOptions optional
Falls vorhanden, wird der abgefragte Schlüssel mit dem Token des angegebenen
scope
registriert. Der Schlüssel kann dann mit einem Zertifikat verknüpft und wie jeder andere Signaturschlüssel verwendet werden. Bei nachfolgenden Aufrufen dieser Funktion wird dann ein neuer Enterprise-Schlüssel im angegebenenscope
generiert. -
Bereich
Welcher Enterprise Key infrage kommt.
RegisterKeyOptions
Attribute
-
Algorithmus
Algorithmus, der für den registrierten Schlüssel verwendet werden soll.
Scope
Gibt an, ob der Enterprise-Nutzerschlüssel oder der Enterprise-Computerschlüssel verwendet werden soll.
Enum
"NUTZER"
"MACHINE"
Token
Attribute
-
id
String
Identifiziert dieses
Token
eindeutig.Statische IDs sind
"user"
und"system"
und beziehen sich auf das nutzerspezifische bzw. systemweite Hardwaretoken der Plattform. Alle anderen Tokens mit anderen Kennungen können vonenterprise.platformKeys.getTokens
zurückgegeben werden. -
softwareBackedSubtleCrypto
SubtleCrypto
Chrome 97 und höherImplementiert die SubtleCrypto-Schnittstelle von WebCrypto. Die kryptografischen Vorgänge, einschließlich der Schlüsselgenerierung, sind softwaregestützte. Der Schutz der Schlüssel und damit die Implementierung der nicht-extrahierbaren Eigenschaft erfolgt über Software, d. h. die Schlüssel sind weniger geschützt als hardwaregestützte Schlüssel.
Nur nicht extrahierbare RSASSA-PKCS1-V1_5-Schlüssel mit einer
modulusLength
bis 2.048 können generiert werden. Jeder Schlüssel kann nur einmal zum Signieren von Daten verwendet werden.Für eine bestimmte
Token
generierte Schlüssel können weder mit anderen Tokens noch mitwindow.crypto.subtle
verwendet werden. Ebenso können mitwindow.crypto.subtle
erstellteKey
-Objekte nicht mit dieser Schnittstelle verwendet werden. -
subtleCrypto
SubtleCrypto
Implementiert die SubtleCrypto-Schnittstelle von WebCrypto. Die kryptografischen Vorgänge, einschließlich der Schlüsselgenerierung, sind hardwaregestützte.
Nur nicht extrahierbare RSASSA-PKCS1-V1_5-Schlüssel mit
modulusLength
bis 2048 und ECDSA mitnamedCurve
P-256 können generiert werden. Jeder Schlüssel kann nur einmal zum Signieren von Daten verwendet werden.Für eine bestimmte
Token
generierte Schlüssel können weder mit anderen Tokens noch mitwindow.crypto.subtle
verwendet werden. Ebenso können mitwindow.crypto.subtle
erstellteKey
-Objekte nicht mit dieser Schnittstelle verwendet werden.
Methoden
challengeKey()
chrome.enterprise.platformKeys.challengeKey(
options: ChallengeKeyOptions,
callback: function,
)
Ähnlich wie challengeMachineKey
und challengeUserKey
, ermöglicht aber die Angabe des Algorithmus eines registrierten Schlüssels. Fordert einen hardwaregestützten Enterprise-Maschinenschlüssel an und gibt die Antwort als Teil eines Remote-Attestierungsprotokolls aus. Nur unter Chrome OS und in Verbindung mit der Verified Access Web API nützlich, die sowohl Identitätsbestätigungen als auch Antworten überprüft.
Eine erfolgreiche Bestätigung durch die Web API für den bestätigten Zugriff ist ein starkes Signal dafür, dass das aktuelle Gerät ein legitimes Chrome OS-Gerät ist, dass das aktuelle Gerät von der Domain verwaltet wird, die bei der Überprüfung angegeben wurde, der aktuell angemeldete Nutzer von der Domain verwaltet wird, die bei der Überprüfung angegeben wurde, und dass der aktuelle Gerätestatus den Geräterichtlinien des Unternehmens entspricht. Beispielsweise kann in einer Richtlinie festgelegt sein, dass sich das Gerät nicht im Entwicklermodus befinden darf. Jede Geräteidentität, die bei der Überprüfung ausgegeben wird, ist eng an die Hardware des aktuellen Geräts gebunden. Wenn der Bereich "user"
angegeben ist, ist die Identität außerdem eng an den aktuell angemeldeten Nutzer gebunden.
Diese Funktion ist stark eingeschränkt und schlägt fehl, wenn das aktuelle Gerät nicht verwaltet wird, der aktuelle Nutzer nicht verwaltet wird oder wenn dieser Vorgang nicht explizit durch die Unternehmensrichtlinien für den Aufrufer aktiviert wurde. Der abgefragte Schlüssel befindet sich nicht im Token "system"
oder "user"
und ist für keine andere API zugänglich.
Parameter
-
Optionen
Objekt mit den in
ChallengeKeyOptions
definierten Feldern. -
callback
Funktion
Der Parameter
callback
sieht so aus:(response: ArrayBuffer) => void
-
Antwort
ArrayBuffer
Die Antwort auf die Challenge.
-
challengeMachineKey()
chrome.enterprise.platformKeys.challengeMachineKey(
challenge: ArrayBuffer,
registerKey?: boolean,
callback: function,
)
Verwenden Sie stattdessen challengeKey
.
Fordert einen hardwaregestützten Enterprise-Maschinenschlüssel an und gibt die Antwort als Teil eines Remote-Attestierungsprotokolls aus. Nur unter Chrome OS und in Verbindung mit der Verified Access Web API nützlich, die sowohl Identitätsbestätigungen als auch Antworten überprüft. Eine erfolgreiche Bestätigung durch die Verified Access Web API ist in folgenden Situationen ein starkes Signal: * Das aktuelle Gerät ist ein legitimes Chrome OS-Gerät. * Das aktuelle Gerät wird von der Domain verwaltet, die bei der Bestätigung angegeben wurde. * Der aktuell angemeldete Nutzer wird von der Domain verwaltet, die bei der Bestätigung angegeben wurde. * Der aktuelle Gerätestatus entspricht den Geräterichtlinien des Unternehmens. Beispielsweise kann in einer Richtlinie festgelegt sein, dass sich das Gerät nicht im Entwicklermodus befinden darf. * Jede Geräteidentität, die bei der Überprüfung 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 nicht verwaltet wird, der aktuelle Nutzer nicht verwaltet wird oder wenn dieser Vorgang nicht explizit durch die Unternehmensrichtlinien für den Aufrufer aktiviert wurde. Der Enterprise-Maschinenschlüssel befindet sich nicht im "system"
-Token und ist für keine andere API zugänglich.
Parameter
-
Challenge
ArrayBuffer
Eine Herausforderung, die von der Verified Access Web API ausgelöst wurde.
-
registerKey
Boolescher Wert optional
Chrome 59 und höherWenn festgelegt, wird der aktuelle Enterprise-Maschinenschlüssel mit dem Token
"system"
registriert und die Rolle „Enterprise-Maschinenschlüssel“ wird entzogen. Der Schlüssel kann dann mit einem Zertifikat verknüpft 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-Maschinenschlüssel generiert. -
callback
Funktion
Der Parameter
callback
sieht so aus:(response: ArrayBuffer) => void
-
Antwort
ArrayBuffer
Die Antwort auf die Challenge.
-
challengeUserKey()
chrome.enterprise.platformKeys.challengeUserKey(
challenge: ArrayBuffer,
registerKey: boolean,
callback: function,
)
Verwenden Sie stattdessen challengeKey
.
Fordert einen hardwaregestützten Enterprise-Nutzerschlüssel an und gibt die Antwort als Teil eines Remote-Attestierungsprotokolls aus. Nur unter Chrome OS und in Verbindung mit der Verified Access Web API nützlich, die sowohl Identitätsbestätigungen als auch Antworten überprüft. Eine erfolgreiche Bestätigung durch die Verified Access Web API ist in folgenden Situationen ein starkes Signal: * Das aktuelle Gerät ist ein legitimes Chrome OS-Gerät. * Das aktuelle Gerät wird von der Domain verwaltet, die bei der Bestätigung angegeben wurde. * Der aktuell angemeldete Nutzer wird von der Domain verwaltet, die bei der Bestätigung angegeben wurde. * Der aktuelle Gerätestatus entspricht den Richtlinien für Unternehmensnutzer. Beispielsweise kann in einer Richtlinie festgelegt sein, dass sich das Gerät nicht im Entwicklermodus befinden darf. * Der öffentliche Schlüssel, der bei der Bestätigung ausgegeben wird, ist eng an die Hardware des aktuellen Geräts und an den aktuell angemeldeten Nutzer gebunden. Diese Funktion ist stark eingeschränkt und schlägt fehl, wenn das aktuelle Gerät nicht verwaltet wird, der aktuelle Nutzer nicht verwaltet wird oder wenn dieser Vorgang nicht explizit durch eine Unternehmensnutzerrichtlinie für den Aufrufer aktiviert wurde. Der Enterprise-Nutzerschlüssel befindet sich nicht im "user"
-Token und ist für keine andere API zugänglich.
Parameter
-
Challenge
ArrayBuffer
Eine Herausforderung, die von der Verified Access Web API ausgelöst wurde.
-
registerKey
boolean
Wenn festgelegt, wird der aktuelle Enterprise-Nutzerschlüssel mit dem
"user"
-Token registriert und die Rolle „Enterprise-Nutzerschlüssel“ wird entzogen. Der Schlüssel kann dann mit einem Zertifikat verknüpft 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-Nutzerschlüssel generiert. -
callback
Funktion
Der Parameter
callback
sieht so aus:(response: ArrayBuffer) => void
-
Antwort
ArrayBuffer
Die Antwort auf die Challenge.
-
getCertificates()
chrome.enterprise.platformKeys.getCertificates(
tokenId: string,
callback: function,
)
Gibt die Liste aller Clientzertifikate zurück, die für 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. -
callback
Funktion
Der Parameter
callback
sieht so aus:(certificates: ArrayBuffer[]) => void
-
Zertifikate
ArrayBuffer[]
Die Liste der Zertifikate mit jeweils DER-Codierung eines X.509-Zertifikats
-
getTokens()
chrome.enterprise.platformKeys.getTokens(
callback: function,
)
Gibt die verfügbaren Tokens zurück. In einer regulären Nutzersitzung 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 (Gerät im Sinne von z.B. Chromebook) gleich.
Parameter
importCertificate()
chrome.enterprise.platformKeys.importCertificate(
tokenId: string,
certificate: ArrayBuffer,
callback?: function,
)
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 es dem Betriebssystem und dem 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
-
callback
Funktion optional
Der Parameter
callback
sieht so aus:() => void
removeCertificate()
chrome.enterprise.platformKeys.removeCertificate(
tokenId: string,
certificate: ArrayBuffer,
callback?: function,
)
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 Zertifikatsauswahl nicht überladen wird. Sollte verwendet werden, um Speicherplatz im Zertifikatspeicher freizugeben.
Parameter
-
tokenId
String
Die ID eines Tokens, das von
getTokens
zurückgegeben wird. -
Zertifikat
ArrayBuffer
Die DER-Codierung eines X.509-Zertifikats
-
callback
Funktion optional
Der Parameter
callback
sieht so aus:() => void