chrome.enterprise.platformKeys

תאריך הרענון: 2026-09-25 robots: noindex

תיאור

משתמשים ב-API‏ chrome.enterprise.platformKeys כדי ליצור מפתחות ולהתקין אישורים למפתחות האלה. הפלטפורמה תנהל את האישורים, ואפשר להשתמש בהם לאימות TLS, לגישה לרשת או באמצעות תוסף אחר דרך chrome.platformKeys.

הרשאות

enterprise.platformKeys

זמינות

‫ChromeOS בלבד נדרשת מדיניות

שימוש

שימוש אופייני ב-API הזה כדי לרשום אישור לקוח כולל את השלבים הבאים:

  • אפשר לקבל את כל האסימונים הזמינים באמצעות enterprise.platformKeys.getTokens.

  • מוצאים את האסימון עם id ששווה ל-"user". משתמשים באסימון הזה בהמשך.

  • יוצרים זוג מפתחות באמצעות השיטה generateKey Token (מוגדרת ב-SubtleCrypto). הפעולה הזו תחזיר את שם המשתמש למפתח.

  • מייצאים את המפתח הציבורי באמצעות השיטה exportKey Token (מוגדר ב-SubtleCrypto).

  • יוצרים את החתימה של נתוני בקשת האישור באמצעות השיטה sign Token (מוגדרת ב-SubtleCrypto).

  • ממלאים את בקשת האישור ושולחים אותה לרשות האישורים.

  • אם מתקבל אישור, מייבאים אותו באמצעות enterprise.platformKeys.importCertificate

בדוגמה הבאה מוצגת האינטראקציה העיקרית עם ה-API, למעט יצירה ושליחה של בקשת האישור:

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);

סוגים

Algorithm

‫Chrome 110 ואילך

סוג המפתח שרוצים ליצור.

ספירה

‫"RSA"

‫"ECDSA"

ChallengeKeyOptions

‫Chrome 110 ואילך

מאפיינים

  • אתגר

    ArrayBuffer

    אתגר כפי שהוא מופק על ידי Verified Access Web API.

  • registerKey

    ‫RegisterKeyOptions אופציונלי

    אם יש כזה, הפונקציה רושמת את המפתח שנדרש לאימות באמצעות האסימון של scope שצוין. אפשר לשייך את המפתח לאישור ולהשתמש בו כמו בכל מפתח חתימה אחר. בשיחות הבאות לפונקציה הזו, ייווצר מפתח Enterprise חדש ב-scope שצוין.

  • היקף

    היקף

    איזה מפתח Enterprise צריך לאתגר.

RegisterKeyOptions

‫Chrome 110 ואילך

מאפיינים

  • אלגוריתם

    אלגוריתם

    האלגוריתם שבו המפתח הרשום צריך להשתמש.

Scope

‫Chrome 110 ואילך

האם להשתמש במפתח המשתמש של Enterprise או במפתח המכונה של Enterprise.

ספירה

‫"USER"

‫"MACHINE"

Token

מאפיינים

  • id [מזהה]

    מחרוזת

    מזהה באופן ייחודי את Token.

    מזהים סטטיים הם "user" ו-"system", שמתייחסים לאסימון החומרה הספציפי למשתמש בפלטפורמה ולאסימון החומרה של המערכת, בהתאמה. יכול להיות שטוקנים אחרים (עם מזהים אחרים) יוחזרו על ידי enterprise.platformKeys.getTokens.

  • softwareBackedSubtleCrypto

    SubtleCrypto

    ‫Chrome 97 ואילך

    מיישם את הממשק SubtleCrypto של WebCrypto. הפעולות הקריפטוגרפיות, כולל יצירת מפתחות, מגובות על ידי תוכנה. ההגנה על המפתחות, ולכן גם ההטמעה של המאפיין 'לא ניתן לחילוץ', מתבצעת בתוכנה, ולכן המפתחות פחות מוגנים ממפתחות מבוססי חומרה.

    אפשר ליצור רק מפתחות שלא ניתן לחלץ. סוג המפתח הנתמך היחיד הוא RSASSA-PKCS1-V1_5 עם modulusLength עד 2048. אפשר להשתמש בכל מפתח לחתימה על נתונים פעם אחת לכל היותר, אלא אם התוסף נכלל ברשימת ההיתרים באמצעות המדיניות KeyPermissions. במקרה כזה, אפשר להשתמש במפתח ללא הגבלה.

    אי אפשר להשתמש במפתחות שנוצרו ב-Token ספציפי עם אסימונים אחרים, וגם לא עם window.crypto.subtle. באופן דומה, אי אפשר להשתמש בממשק הזה בKey אובייקטים שנוצרו באמצעות window.crypto.subtle.

  • subtleCrypto

    SubtleCrypto

    מיישם את הממשק SubtleCrypto של WebCrypto. פעולות הקריפטוגרפיה, כולל יצירת מפתחות, מגובות בחומרה.

    אפשר ליצור רק מפתחות שלא ניתן לחלץ. סוגי המפתחות הנתמכים הם RSASSA-PKCS1-V1_5 עם modulusLength עד 2048 ו-ECDSA עם namedCurve P-256. אפשר להשתמש בכל מפתח לחתימה על נתונים פעם אחת לכל היותר, אלא אם התוסף נכלל ברשימת ההיתרים של מדיניות KeyPermissions. במקרה כזה, אפשר להשתמש במפתח ללא הגבלה.

    אי אפשר להשתמש במפתחות שנוצרו ב-Token מסוים עם אסימונים אחרים, וגם לא עם window.crypto.subtle. באופן דומה, אי אפשר להשתמש בממשק הזה בKey אובייקטים שנוצרו באמצעות window.crypto.subtle.

Methods

challengeKey()

Promise Chrome 110+ 
chrome.enterprise.platformKeys.challengeKey(
  options: ChallengeKeyOptions,
  callback?: function,
): Promise<ArrayBuffer>

דומה ל-challengeMachineKey ול-challengeUserKey, אבל מאפשר לציין את האלגוריתם של מפתח רשום. מאתגר מפתח מכונה ארגוני מבוסס חומרה ומפיק את התגובה כחלק מפרוטוקול אימות מרחוק. היא שימושית רק ב-ChromeOS ובשילוב עם Verified Access Web API, שגם מנפיק אתגרים וגם מאמת תשובות.

אימות מוצלח באמצעות Verified Access Web API הוא אות חזק לכך שהמכשיר הנוכחי הוא מכשיר ChromeOS לגיטימי, שהמכשיר הנוכחי מנוהל על ידי הדומיין שצוין במהלך האימות, שהמשתמש הנוכחי שמחובר לחשבון מנוהל על ידי הדומיין שצוין במהלך האימות, ושמצב המכשיר הנוכחי תואם למדיניות המכשירים של הארגון. לדוגמה, יכול להיות שכלל מדיניות יציין שהמכשיר לא יכול להיות במצב פיתוח. כל זהות מכשיר שנוצרת על ידי האימות קשורה באופן הדוק לחומרה של המכשיר הנוכחי. אם מציינים את "user" Scope, הזהות קשורה גם למשתמש הנוכחי שמחובר לחשבון.

הפונקציה הזו מוגבלת מאוד, והיא תיכשל אם המכשיר הנוכחי לא מנוהל, אם המשתמש הנוכחי לא מנוהל או אם הפעולה הזו לא הופעלה באופן מפורש עבור המתקשר על ידי מדיניות המכשיר של הארגון. המפתח שנדרש לא נמצא בטוקן "system" או "user", ואין אפשרות לגשת אליו דרך אף API אחר.

פרמטרים

  • אובייקט שמכיל את השדות שמוגדרים ב-ChallengeKeyOptions.

  • callback

    פונקציה אופציונלית

    הפרמטר callback נראה כך: 

    (response: ArrayBuffer) => void

    • תשובה

      ArrayBuffer

      התשובה לאתגר.

החזרות

  • Promise<ArrayBuffer>

    ‫Chrome 131 ואילך

    מחזירה הבטחה (Promise) שמושלמת עם התגובה לאתגר.

    התמיכה ב-Promises קיימת רק ב-Manifest V3 ואילך. בפלטפורמות אחרות צריך להשתמש ב-callbacks.

challengeMachineKey()

Promise Chrome 50+ Deprecated since Chrome 110
chrome.enterprise.platformKeys.challengeMachineKey(
  challenge: ArrayBuffer,
  registerKey?: boolean,
  callback?: function,
): Promise<ArrayBuffer>

במקום זאת, צריך להשתמש ב-challengeKey.

מאתגר מפתח מכונה ארגוני מבוסס חומרה ומפיק את התגובה כחלק מפרוטוקול אימות מרחוק. האפשרות הזו שימושית רק ב-ChromeOS, בשילוב עם Verified Access Web API, שגם מנפיק אתגרים וגם מאמת תשובות. אימות מוצלח על ידי Verified Access Web API הוא אות חזק לכל אחד מהדברים הבאים: * המכשיר הנוכחי הוא מכשיר ChromeOS לגיטימי. * המכשיר הנוכחי מנוהל על ידי הדומיין שצוין במהלך האימות. * המשתמש שמחובר כרגע מנוהל על ידי הדומיין שצוין במהלך האימות. * המצב הנוכחי של המכשיר תואם למדיניות המכשירים של הארגון. לדוגמה, יכול להיות שכלל מדיניות יציין שהמכשיר לא יכול להיות במצב פיתוח. * כל זהות מכשיר שמופקת מהאימות קשורה באופן הדוק לחומרה של המכשיר הנוכחי. הפונקציה הזו מוגבלת מאוד, והיא תיכשל אם המכשיר הנוכחי לא מנוהל, אם המשתמש הנוכחי לא מנוהל או אם הפעולה הזו לא הופעלה באופן מפורש עבור המתקשר על ידי מדיניות המכשיר של הארגון. מפתח המכונה של Enterprise לא נמצא בטוקן "system" ואין אפשרות לגשת אליו דרך אף API אחר.

פרמטרים

  • אתגר

    ArrayBuffer

    אתגר כפי שהוא מופק על ידי Verified Access Web API.

  • registerKey

    ‫boolean אופציונלי

    Chrome 59 ואילך

    אם המדיניות מוגדרת, מפתח המכונה הנוכחי של Enterprise נרשם באמצעות הטוקן "system" ומוותר על התפקיד של מפתח המכונה של Enterprise. אפשר לשייך את המפתח לאישור ולהשתמש בו כמו בכל מפתח חתימה אחר. המפתח הזה הוא RSA של 2048 ביט. שיחות עוקבות לפונקציה הזו ייצרו מפתח מכונה חדש ל-Enterprise.

  • callback

    פונקציה אופציונלית

    הפרמטר callback נראה כך: 

    (response: ArrayBuffer) => void

    • תשובה

      ArrayBuffer

      התשובה לאתגר.

החזרות

  • Promise<ArrayBuffer>

    ‫Chrome 131 ואילך

    מחזירה הבטחה (Promise) שמושלמת עם התגובה לאתגר.

    התמיכה ב-Promises קיימת רק ב-Manifest V3 ואילך. בפלטפורמות אחרות צריך להשתמש ב-callbacks.

challengeUserKey()

Promise Chrome 50+ Deprecated since Chrome 110
chrome.enterprise.platformKeys.challengeUserKey(
  challenge: ArrayBuffer,
  registerKey: boolean,
  callback?: function,
): Promise<ArrayBuffer>

במקום זאת, צריך להשתמש ב-challengeKey.

מאתגר מפתח משתמש ארגוני שמגובה בחומרה ומפיק את התגובה כחלק מפרוטוקול אימות מרחוק. האפשרות הזו שימושית רק ב-ChromeOS, בשילוב עם Verified Access Web API, שגם מנפיק אתגרים וגם מאמת תשובות. אימות מוצלח באמצעות Verified Access Web API הוא אות חזק לכל אחד מהדברים הבאים: * המכשיר הנוכחי הוא מכשיר ChromeOS לגיטימי. * המכשיר הנוכחי מנוהל על ידי הדומיין שצוין במהלך האימות. * המשתמש שמחובר כרגע מנוהל על ידי הדומיין שצוין במהלך האימות. * המצב הנוכחי של המכשיר תואם למדיניות המשתמשים בגרסה הארגונית. לדוגמה, יכול להיות שכלל מדיניות יציין שהמכשיר לא יכול להיות במצב פיתוח. * המפתח הציבורי שנוצר על ידי האימות קשור באופן הדוק לחומרה של המכשיר הנוכחי ולמשתמש הנוכחי שמחובר לחשבון. הפונקציה הזו מוגבלת מאוד, והיא תיכשל אם המכשיר הנוכחי לא מנוהל, אם המשתמש הנוכחי לא מנוהל או אם הפעולה הזו לא הופעלה במפורש עבור המתקשר על ידי מדיניות המשתמשים בארגון. מפתח המשתמש הארגוני לא נמצא באסימון "user" ולא ניתן לגשת אליו באמצעות אף API אחר.

פרמטרים

  • אתגר

    ArrayBuffer

    אתגר כפי שהוא מופק על ידי Verified Access Web API.

  • registerKey

    בוליאני

    אם המדיניות מוגדרת, מפתח המשתמש הנוכחי ב-Enterprise נרשם עם אסימון "user", והמערכת מוותרת על התפקיד של מפתח המשתמש ב-Enterprise. אפשר לשייך את המפתח לאישור ולהשתמש בו כמו בכל מפתח חתימה אחר. המפתח הזה הוא RSA של 2048 ביט. שיחות עוקבות לפונקציה הזו ייצרו מפתח חדש של משתמש Enterprise.

  • callback

    פונקציה אופציונלית

    הפרמטר callback נראה כך: 

    (response: ArrayBuffer) => void

    • תשובה

      ArrayBuffer

      התשובה לאתגר.

החזרות

  • Promise<ArrayBuffer>

    ‫Chrome 131 ואילך

    מחזירה הבטחה (Promise) שמושלמת עם התשובה לאתגר.

    התמיכה ב-Promises קיימת רק ב-Manifest V3 ואילך. בפלטפורמות אחרות צריך להשתמש ב-callbacks.

getCertificates()

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

הפונקציה מחזירה את רשימת כל אישורי הלקוח שזמינים מהאסימון הנתון. אפשר להשתמש בה כדי לבדוק את קיומם של אישורי לקוח שניתן להשתמש בהם לאימות מסוים, ואת תאריך התפוגה שלהם.

פרמטרים

  • tokenId

    מחרוזת

    המזהה של טוקן שמוחזר על ידי getTokens.

  • callback

    פונקציה אופציונלית

    הפרמטר callback נראה כך: 

    (certificates: ArrayBuffer[]) => void

    • אישורים

      ArrayBuffer[]

      רשימת האישורים, כל אחד בקידוד DER של אישור X.509.

החזרות

  • Promise<ArrayBuffer[]>

    ‫Chrome 131 ואילך

    מחזירה אובייקט Promise שמוביל לרשימת האישורים הזמינים.

    התמיכה ב-Promises קיימת רק ב-Manifest V3 ואילך. בפלטפורמות אחרות צריך להשתמש ב-callbacks.

getTokens()

Promise 
chrome.enterprise.platformKeys.getTokens(
  callback?: function,
): Promise<Token[]>

הפונקציה מחזירה את הטוקנים הזמינים. בסשן של משתמש רגיל, הרשימה תמיד תכיל את האסימון של המשתמש עם id "user". אם יש טוקן TPM ברמת המערכת, הרשימה שמוחזרת תכיל גם את הטוקן ברמת המערכת עם id "system". האסימון בכל המערכת יהיה זהה לכל הפעלות במכשיר הזה (מכשיר במובן של למשל Chromebook).

פרמטרים

  • callback

    פונקציה אופציונלית

    הפרמטר callback נראה כך: 

    (tokens: Token[]) => void

    • טוקנים

      טוקן[]

      רשימת האסימונים הזמינים.

החזרות

  • Promise<Token[]>

    ‫Chrome 131 ואילך

    מופעל על ידי getTokens עם רשימת האסימונים הזמינים.

    התמיכה ב-Promises קיימת רק ב-Manifest V3 ואילך. בפלטפורמות אחרות צריך להשתמש ב-callbacks.

importCertificate()

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

מייבא את certificate לטוקן הנתון אם המפתח המאושר כבר מאוחסן בטוקן הזה. אחרי בקשת אישור מוצלחת, צריך להשתמש בפונקציה הזו כדי לאחסן את האישור שהתקבל וכדי להפוך אותו לזמין למערכת ההפעלה ולדפדפן לצורך אימות.

פרמטרים

  • tokenId

    מחרוזת

    המזהה של טוקן שמוחזר על ידי getTokens.

  • אישור

    ArrayBuffer

    קידוד DER של אישור X.509.

  • callback

    פונקציה אופציונלית

    הפרמטר callback נראה כך: 

    () => void

החזרות

  • Promise<void>

    ‫Chrome 131 ואילך

    מחזירה אובייקט Promise שמושלם כשהפעולה הזו מסתיימת.

    התמיכה ב-Promises קיימת רק ב-Manifest V3 ואילך. בפלטפורמות אחרות צריך להשתמש ב-callbacks.

removeCertificate()

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

מסיר את certificate מהאסימון הנתון, אם הוא קיים. ההגדרה הזו משמשת להסרת אישורים שיצאו משימוש, כדי שלא ייכללו בתהליך האימות ולא יפריעו לבחירת האישור. צריך להשתמש בו כדי לפנות מקום באחסון בחנות האישורים.

פרמטרים

  • tokenId

    מחרוזת

    המזהה של טוקן שמוחזר על ידי getTokens.

  • אישור

    ArrayBuffer

    קידוד DER של אישור X.509.

  • callback

    פונקציה אופציונלית

    הפרמטר callback נראה כך: 

    () => void

החזרות

  • Promise<void>

    ‫Chrome 131 ואילך

    מחזירה אובייקט Promise שמושלם כשהפעולה הזו מסתיימת.

    התמיכה ב-Promises קיימת רק ב-Manifest V3 ואילך. בפלטפורמות אחרות צריך להשתמש ב-callbacks.