Description
Utilisez l'API chrome.enterprise.platformKeys
pour générer des clés et installer les certificats de ces clés. Ces certificats seront gérés par la plate-forme et peuvent servir à l'authentification TLS, à l'accès au réseau ou à une autre extension via chrome.platformKeys.
Autorisations
enterprise.platformKeys
Disponibilité
Concepts et utilisation
Pour enregistrer un certificat client à l'aide de cette API, procédez comme suit:
Obtenez tous les jetons disponibles à l'aide de
enterprise.platformKeys.getTokens()
.Recherchez le jeton dont
id
est égal à"user"
. Utilisez ensuite ce jeton.Générez une paire de clés à l'aide de la méthode de jeton
generateKey()
(définie dans SubtleCrypto). La poignée de la clé est renvoyée.Exportez la clé publique à l'aide de la méthode de jeton
exportKey()
(définie dans SubtleCrypto).Créez la signature des données de la requête de certification à l'aide de la méthode de jeton
sign()
(définie dans SubtleCrypto).Remplissez la demande de certification et envoyez-la à l'autorité de certification.
Si un certificat est reçu, importez-le à l'aide de [
enterprise.platformKeys.importCertificate()
`[3]
Voici un exemple qui illustre les principales interactions avec l'API, à l'exception de la création et de l'envoi de la demande de certification:
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);
Types
Algorithm
Type de clé à générer.
Énumération
"RSA"
"ECDSA"
ChallengeKeyOptions
Propriétés
-
challenge
ArrayBuffer
Défi émis par l'API Web Verified Access.
-
registerKey
RegisterKeyOptions facultatif
Si elle est présente, enregistre la clé contestée avec le jeton de l'
scope
spécifié. La clé peut ensuite être associée à un certificat et utilisée comme n'importe quelle autre clé de signature. Les appels ultérieurs de cette fonction génèrent alors une nouvelle clé d'entreprise dans lescope
spécifié. -
champ d'application
Clé d'entreprise à invalider.
RegisterKeyOptions
Propriétés
-
algorithm
Algorithme que la clé enregistrée doit utiliser.
Scope
Indique si vous devez utiliser la clé utilisateur Enterprise ou la clé machine Enterprise.
Énumération
"USER"
"MACHINE"
Token
Propriétés
-
id
chaîne
Identifie de manière unique cet élément
Token
.Les ID statiques sont
"user"
et"system"
, qui font respectivement référence au jeton matériel spécifique à l'utilisateur de la plate-forme et au jeton matériel à l'échelle du système. Tout autre jeton (avec d'autres identifiants) peut être renvoyé parenterprise.platformKeys.getTokens
. -
softwareBackedSubtleCrypto
SubtleCrypto
Chrome 97 ou version ultérieureImplémente l'interface SubtleCrypto de WebCrypto. Les opérations de cryptographie, y compris la génération de clés, sont prises en charge par le logiciel. La protection des clés et donc l'implémentation de la propriété non extractible sont effectuées par logiciel. Les clés sont donc moins protégées que les clés intégrées au matériel.
Seules les clés RSASSA-PKCS1-V1_5 non extractibles avec
modulusLength
jusqu'à 2 048 peuvent être générées. Chaque clé ne peut être utilisée pour signer des données qu'une seule fois.Les clés générées sur un
Token
spécifique ne peuvent pas être utilisées avec d'autres jetons ni avecwindow.crypto.subtle
. De même, les objetsKey
créés avecwindow.crypto.subtle
ne peuvent pas être utilisés avec cette interface. -
subtleCrypto
SubtleCrypto
Implémente l'interface SubtleCrypto de WebCrypto. Les opérations de chiffrement, y compris la génération de clés, sont intégrées au matériel.
Seules les clés RSASSA-PKCS1-V1_5 non extractibles avec
modulusLength
jusqu'à 2 048 et ECDSA avecnamedCurve
P-256 peuvent être générées. Chaque clé ne peut être utilisée pour signer des données qu'une seule fois.Les clés générées sur un
Token
spécifique ne peuvent pas être utilisées avec d'autres jetons ni avecwindow.crypto.subtle
. De même, les objetsKey
créés avecwindow.crypto.subtle
ne peuvent pas être utilisés avec cette interface.
Méthodes
challengeKey()
chrome.enterprise.platformKeys.challengeKey(
options: ChallengeKeyOptions,
callback?: function,
)
Semblable à challengeMachineKey
et challengeUserKey
, mais permet de spécifier l'algorithme d'une clé enregistrée. Défige une clé de machine d'entreprise intégrée au matériel et émet la réponse dans le cadre d'un protocole d'attestation à distance. Uniquement utile sur ChromeOS et en association avec l'API Web Verified Access, qui émet des défis et valide les réponses.
Une validation réussie par l'API Web Verified Access est un signal fort indiquant que l'appareil actuel est un appareil ChromeOS légitime, qu'il est géré par le domaine spécifié lors de la validation, que l'utilisateur actuellement connecté est géré par le domaine spécifié lors de la validation et que l'état actuel de l'appareil est conforme à la stratégie d'appareil de l'entreprise. Par exemple, une règle peut spécifier que l'appareil ne doit pas être en mode développeur. Toute identité d'appareil émise par la validation est étroitement liée au matériel de l'appareil actuel. Si le champ d'application "user"
est spécifié, l'identité est également étroitement liée à l'utilisateur actuellement connecté.
Cette fonction est très limitée et échouera si l'appareil actuel n'est pas géré, si l'utilisateur actuel n'est pas géré ou si cette opération n'a pas été explicitement activée pour l'appelant par la stratégie d'appareil d'entreprise. La clé mise en cause ne réside pas dans le jeton "system"
ou "user"
et n'est accessible par aucune autre API.
Paramètres
-
options
Objet contenant les champs définis dans
ChallengeKeyOptions
. -
rappel
fonction facultatif
Le paramètre
callback
se présente comme suit :(response: ArrayBuffer) => void
-
réponse
ArrayBuffer
Réponse au défi.
-
Renvoie
-
Promise<ArrayBuffer>
Chrome 131 ou version ultérieureLes promesses sont compatibles avec la version 3 du fichier manifeste et les versions ultérieures, mais des rappels sont fournis pour assurer la rétrocompatibilité. Vous ne pouvez pas utiliser les deux dans le même appel de fonction. La promesse se résout avec le même type que celui transmis au rappel.
challengeMachineKey()
chrome.enterprise.platformKeys.challengeMachineKey(
challenge: ArrayBuffer,
registerKey?: boolean,
callback?: function,
)
Utilisez plutôt challengeKey
.
Défige une clé de machine d'entreprise intégrée au matériel et émet la réponse dans le cadre d'un protocole d'attestation à distance. Uniquement utile sur ChromeOS et en association avec l'API Web Verified Access, qui émet des défis et valide les réponses. Une validation réussie par l'API Web Verified Access est un signal fort de tous les éléments suivants: * L'appareil actuel est un appareil ChromeOS légitime. * L'appareil actuel est géré par le domaine spécifié lors de la validation. * L'utilisateur actuellement connecté est géré par le domaine spécifié lors de la validation. * L'état actuel de l'appareil est conforme aux règles relatives aux appareils de l'entreprise. Par exemple, une règle peut spécifier que l'appareil ne doit pas être en mode développeur. * Toute identité d'appareil émise par la validation est étroitement liée au matériel de l'appareil actuel. Cette fonction est très limitée et échouera si l'appareil actuel n'est pas géré, si l'utilisateur actuel n'est pas géré ou si cette opération n'a pas été explicitement activée pour l'appelant par la stratégie d'appareil d'entreprise. La clé de machine d'entreprise ne réside pas dans le jeton "system"
et n'est accessible par aucune autre API.
Paramètres
-
challenge
ArrayBuffer
Défi émis par l'API Web Verified Access.
-
registerKey
booléen facultatif
Chrome 59 et versions ultérieuresSi elle est définie, la clé d'ordinateur d'entreprise actuelle est enregistrée avec le jeton
"system"
et abandonne le rôle de clé d'ordinateur d'entreprise. La clé peut ensuite être associée à un certificat et utilisée comme n'importe quelle autre clé de signature. Cette clé est RSA de 2 048 bits. Les appels ultérieurs à cette fonction génèrent alors une nouvelle clé de machine d'entreprise. -
rappel
fonction facultatif
Le paramètre
callback
se présente comme suit :(response: ArrayBuffer) => void
-
réponse
ArrayBuffer
Réponse au défi.
-
Renvoie
-
Promise<ArrayBuffer>
Chrome 131 ou version ultérieureLes promesses sont compatibles avec la version 3 du fichier manifeste et les versions ultérieures, mais des rappels sont fournis pour assurer la rétrocompatibilité. Vous ne pouvez pas utiliser les deux dans le même appel de fonction. La promesse se résout avec le même type que celui transmis au rappel.
challengeUserKey()
chrome.enterprise.platformKeys.challengeUserKey(
challenge: ArrayBuffer,
registerKey: boolean,
callback?: function,
)
Utilisez plutôt challengeKey
.
Il lance une requête auprès d'une clé utilisateur d'entreprise intégrée au matériel et émet la réponse dans le cadre d'un protocole d'attestation à distance. Uniquement utile sur ChromeOS et en association avec l'API Web Verified Access, qui émet des défis et valide les réponses. Une validation réussie par l'API Web Verified Access est un signal fort de tous les éléments suivants: * L'appareil actuel est un appareil ChromeOS légitime. * L'appareil actuel est géré par le domaine spécifié lors de la validation. * L'utilisateur actuellement connecté est géré par le domaine spécifié lors de la validation. * L'état actuel de l'appareil est conforme à la stratégie utilisateur de l'entreprise. Par exemple, une règle peut spécifier que l'appareil ne doit pas être en mode développeur. * La clé publique émise par la validation est étroitement liée au matériel de l'appareil actuel et à l'utilisateur actuellement connecté. Cette fonction est très limitée et échouera si l'appareil actuel n'est pas géré, si l'utilisateur actuel n'est pas géré ou si cette opération n'a pas été explicitement activée pour l'appelant par la stratégie utilisateur d'entreprise. La clé utilisateur d'entreprise ne se trouve pas dans le jeton "user"
et n'est accessible par aucune autre API.
Paramètres
-
challenge
ArrayBuffer
Défi émis par l'API Web Verified Access.
-
registerKey
booléen
Si elle est définie, la clé utilisateur Enterprise actuelle est enregistrée avec le jeton
"user"
et abandonne le rôle de clé utilisateur Enterprise. La clé peut ensuite être associée à un certificat et utilisée comme n'importe quelle autre clé de signature. Cette clé est RSA de 2 048 bits. Les appels ultérieurs à cette fonction génèrent alors une nouvelle clé utilisateur d'entreprise. -
rappel
fonction facultatif
Le paramètre
callback
se présente comme suit :(response: ArrayBuffer) => void
-
réponse
ArrayBuffer
Réponse au défi.
-
Renvoie
-
Promise<ArrayBuffer>
Chrome 131 ou version ultérieureLes promesses sont compatibles avec la version 3 du fichier manifeste et les versions ultérieures, mais des rappels sont fournis pour assurer la rétrocompatibilité. Vous ne pouvez pas utiliser les deux dans le même appel de fonction. La promesse se résout avec le même type que celui transmis au rappel.
getCertificates()
chrome.enterprise.platformKeys.getCertificates(
tokenId: string,
callback?: function,
)
Renvoie la liste de tous les certificats client disponibles à partir du jeton donné. Permet de vérifier l'existence et l'expiration des certificats client utilisables pour une certaine authentification.
Paramètres
-
tokenId
chaîne
ID d'un jeton renvoyé par
getTokens
. -
rappel
fonction facultatif
Le paramètre
callback
se présente comme suit :(certificates: ArrayBuffer[]) => void
-
certificates
ArrayBuffer[]
Liste des certificats, chacun encodé DER pour un certificat X.509.
-
Renvoie
-
Promise<ArrayBuffer[]>
Chrome 131 ou version ultérieureLes promesses sont compatibles avec la version 3 du fichier manifeste et les versions ultérieures, mais des rappels sont fournis pour assurer la rétrocompatibilité. Vous ne pouvez pas utiliser les deux dans le même appel de fonction. La promesse se résout avec le même type que celui transmis au rappel.
getTokens()
chrome.enterprise.platformKeys.getTokens(
callback?: function,
)
Renvoie les jetons disponibles. Dans la session d'un utilisateur standard, la liste contient toujours le jeton de l'utilisateur avec id
"user"
. Si un jeton TPM à l'échelle du système est disponible, la liste renvoyée contient également le jeton à l'échelle du système avec id
"system"
. Le jeton à l'échelle du système sera le même pour toutes les sessions sur cet appareil (appareil au sens d'un Chromebook, par exemple).
Paramètres
Renvoie
-
Promise<Token[]>
Chrome 131 ou version ultérieureLes promesses sont compatibles avec la version 3 du fichier manifeste et les versions ultérieures, mais des rappels sont fournis pour assurer la rétrocompatibilité. Vous ne pouvez pas utiliser les deux dans le même appel de fonction. La promesse se résout avec le même type que celui transmis au rappel.
importCertificate()
chrome.enterprise.platformKeys.importCertificate(
tokenId: string,
certificate: ArrayBuffer,
callback?: function,
)
Importe certificate
dans le jeton donné si la clé certifiée est déjà stockée dans ce jeton. Une fois la demande de certification réussie, cette fonction doit être utilisée pour stocker le certificat obtenu et le mettre à la disposition du système d'exploitation et du navigateur pour l'authentification.
Paramètres
-
tokenId
chaîne
ID d'un jeton renvoyé par
getTokens
. -
certificat
ArrayBuffer
Encodage DER d'un certificat X.509.
-
rappel
fonction facultatif
Le paramètre
callback
se présente comme suit :() => void
Renvoie
-
Promise<void>
Chrome 131 ou version ultérieureLes promesses sont compatibles avec la version 3 du fichier manifeste et les versions ultérieures, mais des rappels sont fournis pour assurer la rétrocompatibilité. Vous ne pouvez pas utiliser les deux dans le même appel de fonction. La promesse se résout avec le même type que celui transmis au rappel.
removeCertificate()
chrome.enterprise.platformKeys.removeCertificate(
tokenId: string,
certificate: ArrayBuffer,
callback?: function,
)
Supprime certificate
du jeton donné, le cas échéant. À utiliser pour supprimer les certificats obsolètes afin qu'ils ne soient pas pris en compte lors de l'authentification et qu'ils ne surchargent pas le choix des certificats. À utiliser pour libérer de l'espace de stockage dans le magasin de certificats.
Paramètres
-
tokenId
chaîne
ID d'un jeton renvoyé par
getTokens
. -
certificat
ArrayBuffer
Encodage DER d'un certificat X.509.
-
rappel
fonction facultatif
Le paramètre
callback
se présente comme suit :() => void
Renvoie
-
Promise<void>
Chrome 131 ou version ultérieureLes promesses sont compatibles avec la version 3 du fichier manifeste et les versions ultérieures, mais des rappels sont fournis pour assurer la rétrocompatibilité. Vous ne pouvez pas utiliser les deux dans le même appel de fonction. La promesse se résout avec le même type que celui transmis au rappel.