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

שתף את המידע הבא עם מארחי הפגישה שלך:

אמת את הזהות

הצפנה מקצה לקצה עם אימות זהות מספקת אבטחה נוספת לפגישה מוצפנת מקצה לקצה.

כאשר משתתפים או מכשירים מצטרפים לקבוצת MLS (העברת הודעות Layer Security) משותפת, הם מציגים את האישורים שלהם לחברי הקבוצה האחרים, אשר לאחר מכן מאשרים את האישורים מול רשויות האישורים המנפיקות (CA). על ידי אישור שהתעודות תקפות, ה-CA מאמת את זהות המשתתפים, והפגישה מציגה את המשתתפים/המכשירים כמאומתים.

משתמשי Webex App מאמתים את עצמם מול מאגר הזהות של Webex , שמנפיק להם אסימון גישה כאשר האימות מצליח. אם הם צריכים אישור כדי לאמת את זהותם בפגישה מוצפנת מקצה לקצה, ה- Webex CA מנפיק להם אישור על סמך אסימון הגישה שלהם. בשלב זה, איננו מספקים דרך למשתמשי Webex Meetings לקבל אישור שהונפק על ידי רשות צד שלישי/חיצונית.

מכשירים יכולים לאמת את עצמם באמצעות אישור שהונפק על ידי ה-CA הפנימי (Webex), או אישור שהונפק על ידי CA חיצוני:

  • CA פנימי - Webex מנפיק אישור פנימי המבוסס על אסימון הגישה של חשבון המחשב של המכשיר. האישור חתום על ידי Webex CA. למכשירים אין מזהי משתמש באותו אופן שבו משתמשים, ולכן Webex משתמשת (אחד מהדומיינים של הארגון שלך בעת כתיבת הזהות של אישור המכשיר (Common Name (CN)).

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

    Cisco אינה מעורבת, מה שהופך זאת לדרך להבטיח הצפנה אמיתית מקצה לקצה וזהות מאומתת, ולמנוע את האפשרות התיאורטית Cisco תוכל לצותת לפגישה שלך/לפענח את המדיה שלך.

תעודת מכשיר שהונפקה באופן פנימי

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

אם לארגון שלך אין דומיין, ה- Webex CA מנפיק את האישור ללא דומיין.

אם לארגון שלך יש מספר דומיינים, אתה יכול להשתמש ב-Control Hub כדי לומר ל- Webex באיזה תחום המכשיר להשתמש עבור זהותו. אתה יכול גם להשתמש ב- API xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com".

אם יש לך מספר דומיינים ואינך מגדיר את הדומיין המועדף עבור המכשיר, Webex בוחר אחד עבורך.

תעודת מכשיר שהונפקה חיצונית

מנהל מערכת יכול לספק למכשיר אישור משלו שנחתם עם אחד מה-CAs הציבוריים.

האישור חייב להיות מבוסס על זוג מפתחות ECDSA P-256, אם כי ניתן לחתום עליו באמצעות מפתח RSA .

הערכים בתעודה הם לפי שיקול דעת הארגון. השם המשותף (CN) והשם החלופי של הנושא (SAN) יוצגו ממשק משתמש פגישה ב-Webex , כמתואר ב הצפנה מקצה לקצה עם אימות זהות עבור Webex Meetings .

אנו ממליצים להשתמש באישור נפרד לכל מכשיר ולהיות בעל CN ייחודי לכל מכשיר. לדוגמה, "meeting-room-1.example.com" עבור הארגון שבבעלותו הדומיין "example.com".

על מנת להגן באופן מלא על התעודה החיצונית מפני שיבוש, תכונה סודית לקוח משמשת להצפנה וחתימה על פקודות x שונות.

בעת שימוש בסוד הלקוח, ניתן לנהל בצורה מאובטחת את תעודת הזהות החיצונית של Webex באמצעות ה-xAPI. זה מוגבל כרגע למכשירים מקוונים.

Webex מספקת כרגע פקודות API לניהול זה.

מכשירים

סדרת Webex Room והמכשירים מסדרת Webex Desk הבאים הרשומים בענן יכולים להצטרף לפגישות מוצפנות מקצה לקצה:

  • Webex Board

  • Webex Desk Pro

  • Webex Desk

  • Webex Room Kit

  • Webex Room Kit Mini

המכשירים הבאים אינם יכולים להצטרף לפגישות מוצפנות מקצה לקצה:

  • Webex סדרה C

  • סדרת Webex DX

  • סדרת Webex EX

  • Webex MX Series

  • התקני SIP של צד שלישי

לקוחות תוכנה
  • החל מגרסה 41.6, לקוח שולחן העבודה של Webex Meetings יכול להצטרף לפגישות מוצפנות מקצה לקצה.

  • אם הארגון שלך מאפשר יישום Webex להצטרף לפגישות על ידי הפעלת אפליקציית שולחן העבודה של Meetings, אז אתה יכול להשתמש באפשרות זו כדי להצטרף לפגישות מוצפנות מקצה לקצה.

  • לקוח האינטרנט של Webex אינו יכול להצטרף לפגישות מוצפנות מקצה לקצה.

  • לקוחות SIP רכים של צד שלישי אינם יכולים להצטרף לפגישות מוצפנות מקצה לקצה.

זהות
  • לפי התכנון, אנחנו לא מספקים לך אפשרויות Control Hub לניהול זהות מכשיר מאומתת חיצונית. להצפנה אמיתית מקצה לקצה, רק אתה צריך לדעת/לגשת לסודות ולמפתחות. אם הצגנו שירות ענן לניהול המפתחות הללו, יש סיכוי שיירטו אותם.

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

פגישות
  • פגישות מוצפנות מקצה לקצה תומכות כיום במקסימום של 200 משתתפים.

  • מתוך אותם 200 משתתפים, מקסימום 25 מכשירים מאומתים חיצונית יכולים להצטרף, והם חייבים להיות המשתתפים הראשונים שמצטרפים לפגישה .

    כאשר מספר גדול יותר של מכשירים מצטרף לפגישה, שירותי המדיה האחוריים שלנו מנסים להמיר את זרמי המדיה. אם איננו יכולים לפענח, להמיר ולהצפין מחדש את המדיה (מכיוון שאין לנו ולא אמורים להיות לנו מפתחות ההצפנה של המכשירים), אזי ההמרה נכשלת.

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

ממשק ניהול

אנו ממליצים מאוד להשתמש ב-Control Hub כדי לנהל את אתר הפגישות שלך, שכן לארגוני Control Hub יש זהות מרוכזת לכל הארגון, בעוד ניהול אתר, הזהות נשלטת על בסיס אתר-אתר.

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

מידע קשור
  • Webex Meetings 41.7.

  • מכשירים מסדרת Webex Room ו- Webex Desk הרשומים בענן, פועלים 10.6.1-RoomOS_August_2021.

  • גישה מנהלתית אתר הפגישה ב-Control Hub, כדי להפעיל את סוג ההפעלה החדש למשתמשים.

  • דומיין מאומת אחד או יותר בארגון Control Hub שלך (אם אתה משתמש ב- Webex CA כדי להנפיק אישורי מכשיר עבור זהות מאומתת).

  • יש להפעיל את חדרי ישיבות שיתוף פעולה כדי שאנשים יוכלו להצטרף ממערכת הווידאו שלהם. למידע נוסף, ראה אפשר למערכות וידאו להצטרף לפגישות ואירועים אתר Webex שלך .

אתה יכול לדלג על שלב זה אם אינך זקוק לזהויות מאומתות חיצונית.

לרמת האבטחה הגבוהה ביותר ולאימות זהות, לכל מכשיר צריך להיות תעודה ייחודית שהונפקה על ידי Certificate Authority ציבורית מהימנה (CA).

עליך ליצור אינטראקציה עם ה-CA כדי לבקש, לרכוש ולקבל את האישורים הדיגיטליים וליצור את המפתחות הפרטיים המשויכים. בעת בקשת האישור, השתמש בפרמטרים הבאים:

  • האישור חייב להיות מונפק וחתום על ידי CA ציבורי ידוע.

  • ייחודי: אנו ממליצים בחום להשתמש בתעודה ייחודית לכל מכשיר. אם אתה משתמש באישור אחד עבור כל המכשירים, אתה פוגע באבטחה שלך.

  • שם נפוץ (CN) ושמות חלופיים של נושא (SAN/ים): אלה אינם חשובים ל- Webex, אבל צריכים להיות ערכים שבני אדם יכולים לקרוא ולשייך למכשיר. ה-CN יראה למשתתפים אחרים בפגישה בתור הזהות המאומתת הראשית של המכשיר, ואם משתמשים יבדקו את האישור דרך ממשק המשתמש של הפגישה, הם יראו את ה-SAN/s. אולי תרצה להשתמש בשמות כמו name.model@example.com.

  • פורמט קובץ: האישורים והמפתחות חייבים להיות ב- .pem פורמט.

  • מטרה: מטרת האישור חייבת להיות Webex Identity.

  • יצירת מפתחות: התעודות חייבות להיות מבוססות על צמדי מפתחות של ECDSA P-256 (אלגוריתם חתימה דיגיטלית של עקומה אליפטית באמצעות עקומת P-256).

    דרישה זו אינה חלה על מפתח החתימה. ה-CA יכול להשתמש במפתח RSA כדי לחתום על האישור.

אתה יכול לדלג על שלב זה אם אינך רוצה להשתמש בזהות מאומתת חיצונית עם המכשירים שלך.

אם אתה משתמש במכשירים חדשים, אל תרשום אותם עדיין ל- Webex . ליתר ביטחון, אל תחבר אותם לרשת בשלב זה.

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

  • שמור את התצורה הקיימת אם ברצונך לשמור אותה.

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

  • ודא גישה פיזית למכשירים. אם אתה חייב לגשת למכשירים דרך הרשת, שים לב שהסודות מסתובבים בטקסט רגיל ואתה מתפשר על האבטחה שלך.

לאחר שתסיים את השלבים האלה, אפשר למערכות וידאו להצטרף לפגישות ואירועים אתר Webex שלך .

כדי להבטיח שמדיה של המכשיר שלך לא תוכל להיות מוצפנת על ידי אף אחד מלבד המכשיר, עליך להצפין את המפתח הפרטי במכשיר. תכננו ממשקי API עבור המכשיר כדי לאפשר ניהול של המפתח והאישור המוצפנים, באמצעות JSON מקוון/באינטרנט Encryption (JWE).

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

  1. בקש את התעודות שלך.

  2. צור צמדי מפתחות של התעודות שלך.

  3. צור (והגן) סוד ראשוני עבור כל מכשיר, כדי לראות את יכולת ההצפנה של המכשיר.

  4. פתח ותחזק כלי משלך להצפנת קבצים באמצעות תקן JWE.

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

    מימוש עזר לא נתמך באמצעות Python3 וספריית JWCrypto זמין מ- Cisco לפי בקשה.

  5. שרשור והצפין את האישור והמפתח באמצעות הכלי שלך והסוד הראשוני של המכשיר.

  6. העלה את ה-JWE שהתקבל למכשיר.

  7. הגדר את מטרת האישור המוצפן לשימוש עבור זהות Webex , והפעל את האישור.

  8. (מומלץ) ספק ממשק לכלי שלך (או להפיץ אותו) כדי לאפשר למשתמשי המכשיר לשנות את הסוד הראשוני ולהגן על המדיה שלהם ממך.

כיצד אנו משתמשים בפורמט JWE

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

עיין ב JSON מקוון/באינטרנט Encryption (JWE)https://datatracker.ietf.org/doc/html/rfc7516ו JSON מקוון/באינטרנט Signature (JWS)https://datatracker.ietf.org/doc/html/rfc7515.

אנו משתמשים ב- סריאליזציה קומפקטית של מסמך JSON ליצירת כתמי JWE. הפרמטרים שעליך לכלול בעת יצירת ה-JWE blobs הם:

  • כותרת JOSE (מוגן). בכותרת חתימה והצפנה של אובייקטים של JSON, עליך לכלול את צמדי ערכי המפתח הבאים:

    • "alg":"dir"

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

    • "enc":"A128GCM" או "enc":"A256GCM"

      אנו תומכים בשני אלגוריתמי ההצפנה הללו.

    • "cisco-action": "add" או "cisco-action": "populate" או "cisco-action": "activate" או "cisco-action": "deactivate"

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

      קראנו לזה cisco-action כדי לצמצם התנגשויות פוטנציאליות עם הרחבות עתידיות של JWE.

    • "cisco-kdf": { "version": "1", "salt": "base64URLEncodedRandom4+Bytes" }

      מפתח קנייני נוסף. אנו משתמשים בערכים שאתה מספק כקלט עבור גזירת מפתח במכשיר. הפגישה ב- version חייב להיות 1(הגרסה של פונקציית גזירת המפתח שלנו). הערך של salt חייב להיות רצף מקודד של URL של base64 של לפחות 4 בתים, שאתה חייב לבחור באופן אקראי.

  • מפתח מוצפן של JWE . שדה זה ריק. המכשיר שואב את זה מההתחלה ClientSecret.

  • וקטור אתחול JWE . עליך לספק וקטור אתחול מקודד base64url לפענוח המטען. ה-IV חייב להיות ערך אקראי של 12 בתים (אנו משתמשים במשפחת הצופנים AES-GCM, הדורשת שה-IV יהיה באורך 12 בתים).

  • JWE AAD (נתונים מאומתים נוספים). עליך להשמיט שדה זה מכיוון שהוא אינו נתמך ב-Comact Serialization.

  • JWE Chiphertext : זהו המטען המוצפן שברצונך לשמור בסוד.

    המטען עשוי להיות ריק. לדוגמה, כדי לאפס את סוד הלקוח, עליך להחליף אותו בערך ריק.

    ישנם סוגים שונים של מטענים, בהתאם למה שאתה מנסה לעשות במכשיר. פקודות xAPI שונות מצפות למטענים שונים, ועליך לציין את מטרת המטען עם cisco-action מפתח, כדלקמן:

    • עם "cisco-action":"populate" טקסט ההצפנה הוא החדש ClientSecret.

    • עם " "cisco-action":"add" טקסט ההצפנה הוא כתם PEM הנושא את התעודה והמפתח הפרטי שלו (משורשר).

    • עם " "cisco-action":"activate" טקסט הצפנה הוא טביעת האצבע (ייצוג הקסדצימלי של sha-1) של האישור שאנו מפעילים לאימות זהות המכשיר.

    • עם " "cisco-action":"deactivate" טקסט הצופן הוא טביעת האצבע (ייצוג הקסדצימלי של sha-1) של האישור שאנו מבטלים את השימוש בו לצורך אימות זהות המכשיר.

  • תג אימות JWE: שדה זה מכיל את תג האימות כדי לוודא את תקינות ה-JWE ה-Blob הקומפקטי המסודר

כיצד אנו גוזרים את מפתח הצפנה מה- ClientSecret

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

תוכנת המכשיר משתמשת בסוד הלקוח כקלט לפונקציית גזירת מפתח (kdf) ולאחר מכן משתמשת במפתח הנגזר לפענוח/הצפנה של תוכן במכשיר.

המשמעות עבורך היא שהכלי שלך לייצור בלובים של JWE חייב לבצע את אותו הליך כדי להפיק את אותו מפתח הצפנה/פענוח מסוד הלקוח.

המכשירים משתמשים scrypt לגזירת מפתח (ראהhttps://en.wikipedia.org/wiki/Scrypt ), עם הפרמטרים הבאים:

  • CostFactor (N) הוא 32768

  • BlockSizeFactor (r) הוא 8

  • ParallelizationFactor (p) הוא 1

  • מלח הוא רצף אקראי של לפחות 4 בתים; אתה חייב לספק את אותו הדבר salt כאשר מציינים את cisco-kdf פרמטר.

  • אורכי מפתח הם 16 בתים (אם תבחר באלגוריתם AES-GCM 128), או 32 בתים (אם תבחר באלגוריתם AES-GCM 256)

  • מכסת זיכרון מקסימלית היא 64MB

סט פרמטרים זה הוא התצורה היחידה של scrypt שתואם לפונקציית גזירת המפתח במכשירים. ה-kdf הזה במכשירים נקרא "version":"1", שהיא הגרסה היחידה שנלקחה כרגע על ידי ה cisco-kdf פרמטר.

דוגמה עובדת

הנה דוגמה שתוכל לעקוב אחריה כדי לוודא שתהליך ההצפנה של JWE שלך עובד כמו התהליך שיצרנו במכשירים.

התרחיש לדוגמה הוא הוספת כתם PEM למכשיר (מחקה הוספת אישור, עם מחרוזת קצרה מאוד במקום אישור מלא + מפתח). סוד הלקוח בדוגמה הוא ossifrage.

  1. בחר צופן הצפנה. דוגמה זו משתמשת A128GCM(AES עם מפתחות 128 סיביות במצב מונה Galois). הכלי שלך יכול להשתמש A256GCM אם אתה מעדיף.

  2. בחר מלח (חייב להיות רצף אקראי של לפחות 4 בתים). דוגמה זו משתמשת (hex bytes) E5 E6 53 08 03 F8 33 F6. Base64url מקודד את הרצף כדי לקבל 5eZTCAP4M_Y(הסר את ריפוד base64).

  3. הנה דוגמה scrypt קריאה ליצירת מפתח הצפנה התוכן (cek):

    cek=scrypt(password="ossifrage", salt=4-byte-sequence, N=32768, r=8, p=1, keylength=16)

    המפתח הנגזר צריך להיות 16 בתים (hex) באופן הבא: 95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac אשר base64url מקודד אליו lZ66bdEiAQV4_mqdInj_rA.

  4. בחר רצף אקראי של 12 בתים לשימוש כווקטור אתחול. דוגמה זו משתמשת (hex) 34 b3 5d dd 5f 53 7b af 2d 92 95 83 אשר base64url מקודד אליו NLNd3V9Te68tkpWD.

  5. צור את הכותרת של JOSE עם סדרה קומפקטית (עקוב אחר אותו סדר של פרמטרים שאנו משתמשים כאן) ואז base64url מקודד אותו:

    {"alg":"dir","cisco-action":"add","cisco-kdf":{"salt":"5eZTCAP4M_Y","version":"1"},"enc":"A128GCM"}

    הכותרת JOSE המקודדת base64url היא eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

    זה יהיה המרכיב הראשון של כתם JWE.

  6. הרכיב השני של ה-JWE blob ריק, מכיוון שאיננו מספקים מפתח הצפנה של JWE.

  7. האלמנט השלישי של ה-JWE blob הוא וקטור האתחול NLNd3V9Te68tkpWD.

  8. השתמש בכלי ההצפנה של JWE שלך כדי לייצר מטען ותג מוצפנים. עבור הדוגמה הזו, המטען הלא מוצפן יהיה כתם PEM מזויף this is a PEM file

    פרמטרי ההצפנה שבהם עליך להשתמש הם:

    • מטען הוא this is a PEM file

    • צופן ההצפנה הוא AES 128 GCM

    • כותרת JOSE מקודדת base64url כנתונים מאומתים נוספים (AAD)

    Base64url מקודד את המטען המוצפן, מה שאמור להוביל f5lLVuWNfKfmzYCo1YJfODhQ

    זהו האלמנט הרביעי (JWE Ciphertext) ב-JWE blob.

  9. Base64url מקודד את התג שיצרת בשלב 8, מה שאמור להוביל PE-wDFWGXFFBeo928cfZ1Q

    זהו האלמנט החמישי ב-JWE blob.

  10. שרשרת את חמשת האלמנטים של ה-JWE עם נקודות (JOSEheader..IV.Ciphertext.Tag) כדי לקבל:

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

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

  12. הדוגמה הזו לא באמת תעבוד, אבל באופן עקרוני הצעד הבא שלך יהיה להשתמש ב-JWE blob שיצרת למעלה כקלט ל-xcommand במכשיר שמוסיף את האישור:

    xCommand Security Certificates Add eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

סוגי פגישות לפגישות אפס אמון זמינים לכל אתרי הפגישות ללא עלות נוספת. אחד מסוגי ההפעלה האלה נקרא Pro-End to End Encryption_VOIPonly. זהו שם השירות הציבורי, שאנו עשויים להשתנות בעתיד. לשמות הנוכחיים של סוגי הפעלות, ראה מזהי סוג הפעלה ב הפניה סעיף של מאמר זה.

אין שום דבר שעליך לעשות כדי לקבל יכולת זו עבור האתר שלך; עליך להעניק למשתמשים את סוג המפגש החדש (הנקרא גם Meeting Privilege). אתה יכול לעשות זאת בנפרד דרך דף תצורה של המשתמש , או בכמות גדולה עם ייצוא/ייבוא CSV .

1

היכנס אל Control Hub, ואז עבור אל שירותים > פגישות.

2

לחץ אתרים, בחר את אתר Webex שעבורו תרצה לשנות את ההגדרות, ולאחר מכן לחץ על הגדרות.

3

מתחת הגדרות נפוצות , בחר סוגי מפגשים .

4
אתה אמור לראות סוג אחד או יותר של הפעלת הצפנה מקצה לקצה. עיין ברשימה של מזהי סוג הפעלה ב הפניה סעיף של מאמר זה. לדוגמה, אתה עשוי לראות Pro-End to End Encryption_ VOIP בלבד .

 

יש סוג הפעלה ישן יותר עם שם דומה מאוד: הצפנה פרו-קצה לקצה . סוג הפעלה זה כולל גישת PSTN לא מוצפנת לפגישות. ודא שיש לך את_ VOIP בלבד גרסה כדי להבטיח הצפנה מקצה לקצה. אתה יכול לבדוק על ידי ריחוף מעל PRO קישור בעמודת קוד ההפעלה; עבור דוגמה זו, היעד של הקישור צריך להיות javascript:ShowFeature(652).

אנו עשויים לשנות את שמות השירות הציבורי עבור סוגי הפעלות אלה בעתיד.

5

אם עדיין אין לך את סוג ההפעלה החדש, צור קשר עם נציג Webex שלך.

מה הלאה?

אפשר את סוג הפגישה/הרשאת הפגישה הזו לחלק מהמשתמשים שלך או לכולם.

1

היכנס אל רכזת בקרה , ולך אל ניהול > משתמשים .

2

בחר חשבון משתמש לעדכון ולאחר מכן בחר פגישות .

3

מתוך ההגדרות חלות על תפריט נפתח, בחר את אתר הפגישה שיש לעדכן.

4

סמן את התיבה שליד Pro-End to End Encryption_ VOIP בלבד .

5

סגור את לוח תצורת משתמש .

6

חזור על זה עבור משתמשים אחרים במידת הצורך.

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

1

היכנס אל Control Hub, ואז עבור אל שירותים > פגישות.

2

לחץ על אתרים, בחר את אתר Webex עבורו ברצונך לשנות את ההגדרות.

3

ב- רישיונות ומשתמשים סעיף, לחץ ניהול בכמות גדולה .

4

לחץ על צור דוח, והמתן בזמן שאנחנו מכינים את הקובץ.

5

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

6

פתח את קובץ CSV שהורד לעריכה.

יש שורה עבור כל משתמש, וה- MeetingPrivilege העמודה מכילה את מזהי סוג ההפעלה שלהם כרשימה מופרדת בפסיקים.

7

עבור כל משתמש שברצונך להעניק את סוג ההפעלה החדש, הוסף 1561 כערך חדש ברשימה המופרדת בפסיקים ב- MeetingPrivilege תא.

ה עיון בפורמט קובץ Webex CSV מכיל פרטים על המטרה והתוכן של קובץ CSV.

8

פתח את חלונית התצורה של אתר הפגישה ב-Control Hub.


 

אם כבר היית בדף רשימת אתרי הפגישה, ייתכן שיהיה עליך לרענן אותו.

9

ב- רישיונות ומשתמשים סעיף, לחץ ניהול בכמות גדולה .

10

לחץ ייבוא ובחר את CSV הערוך ולאחר מכן לחץ ייבוא . המתן בזמן שהקובץ מועלה.

11

בסיום הייבוא, תוכל ללחוץ ייבוא תוצאות כדי לבדוק אם היו שגיאות.

12

עבור אל משתמשים עמוד ופתח את אחד מהמשתמשים כדי לוודא שיש להם את סוג ההפעלה החדש.

באפשרותך להוסיף סימן מים להקלטות פגישות עם Webex Meetings Pro-End to End Encryption_VOIPonly סוג הפעלה, המאפשר לך לזהות את לקוח המקור או מכשיר של הקלטות לא מורשות של פגישות חבויות.

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

  • על מנת לנתח, ההקלטה חייבת להיות קובץ AAC, MP3, M4A, WAV, MP4, AVI או MOV שגודלו אינו עולה על 500MB.
  • ההקלטה חייבת להיות ארוכה מ-100 שניות.
  • אתה יכול לנתח הקלטות רק עבור פגישות שמתארחות על ידי אנשים בארגון שלך.
  • פרטי סימן מים נשמרים למשך זמן זהה לפרטי הפגישה של הארגון.
הוסף סימני מים אודיו לפגישות E2EE
  1. היכנס ל-Control Hub ולאחר מכן תחת ניהול, בחר הגדרות ארגון.
  2. ב- מפגש עם סימני מים מקטע, הפעל הוסף סימן מים אודיו .

    זמן מה לאחר שינוי מצב זה, משתמשים מתזמנים פגישות עם Webex Meetings Pro-End to End Encryption_VOIPonly סוג הפעלה ראה אפשרות סימון מים דיגיטלי בקטע אבטחה.

העלה ונתח פגישה עם סימן מים
  1. ב-Control Hub, מתחת ניטור , בחר פתרון בעיות .
  2. לחץ ניתוח סימן מים .
  3. חפש או בחר את הפגישה ברשימה ולאחר מכן לחץ על נתח.
  4. ב- נתח סימן מים אודיו חלון, הזן שם עבור הניתוח שלך.
  5. (אופציונלי) הזן הערה לניתוח שלך.
  6. גרור ושחרר את קובץ השמע לניתוח, או לחץ בחר קובץ כדי לדפדף לקובץ האודיו.
  7. לחץ סגור .

    כאשר הניתוח יושלם, הוא יוצג ברשימת התוצאות ב- נתח סימן מים עמוד.

  8. בחר את הפגישה ברשימה כדי לראות את תוצאות הניתוח. לחץכפתור הורדה להורדת התוצאות.
תכונות ומגבלות

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

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

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

אם המכשירים שלך כבר מוכנסים לארגון Control Hub שלך ואתה רוצה להשתמש ב- Webex CA כדי ליצור אוטומטית את תעודות הזיהוי שלהם, אינך צריך איפוס להגדרות יצרן את המכשירים להגדרות היצרן.

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

לפני שתתחיל

אם המכשירים שלך עדיין לא מוכנסים, עקוב רשום מכשיר ל- Cisco Webex באמצעות API או ממשק מקוון/באינטרנט מקומי או קליטה בענן לסדרות לוח, שולחן וחדרים . עליך גם לאמת את הדומיין/ים שבהם ברצונך להשתמש כדי לזהות את המכשירים שבהם נהל את הדומיינים שלך .

1

היכנס ל-Control Hub , ומתחת ניהול , בחר התקנים .

2

בחר מכשיר כדי לפתוח את לוח התצורה שלו.

3

בחר את הדומיין שבו ברצונך להשתמש כדי לזהות מכשיר זה.

4

חזור על הפעולה עבור מכשירים אחרים.

לפני שתתחיל

אתה צריך:

  • כדי לקבל אישור חתום CA ומפתח פרטי, היכנס .pem פורמט, עבור כל מכשיר.

  • לקריאת הנושא הבנת תהליך זהות חיצונית עבור מכשירים , ב הכן חלק מהמאמר הזה.

  • להכין כלי הצפנה של JWE ביחס למידע שם.

  • כלי ליצירת רצפי בתים אקראיים באורכים נתונים.

  • כלי לקידוד base64url בתים או טקסט.

  • א scrypt יישום.

  • מילה או ביטוי סודי לכל מכשיר.

1

אכלס את המכשיר ClientSecret עם סוד טקסט פשוט:

בפעם הראשונה שאתה מאכלס את Secret, אתה מספק אותו בטקסט רגיל. לכן אנו ממליצים לעשות זאת בקונסולת המכשיר הפיזי.

  1. Base64url מקודד את הביטוי הסודי עבור מכשיר זה.

  2. פתח את ה-TShell במכשיר.

  3. הפעל xcommand Security ClientSecret Populate Secret: "MDEyMzQ1Njc4OWFiY2RlZg"

    הפקודה לדוגמה לעיל מאכלסת את Secret עם הביטוי 0123456789abcdef. אתה צריך לבחור בעצמך.

למכשיר יש את הסוד הראשוני שלו. אל תשכח את זה; אינך יכול לשחזר אותו ועליך לאפס את המכשיר כדי להתחיל מחדש.
2

שרוך את האישור והמפתח הפרטי שלך:

  1. באמצעות עורך טקסט, פתח את קובצי ה-.pem, הדבק את ה-key blob את גוש האישורים ושמור אותו כקובץ .pem חדש.

    (זהו טקסט המטען שתצפין ותכניס ל-JWE שלך)

3

צור כתם JWE לשימוש כקלט לפקודת הוספה של האישור:

  1. צור רצף אקראי של לפחות 4 בתים. זה המלח שלך.

  2. הפק מפתח הצפנה תוכן עם כלי ההצפנה שלך.

    בשביל זה אתה צריך את הסוד, המלח ואורך מפתח שיתאימו לצופן ההצפנה שבחרת. יש עוד כמה ערכים קבועים שצריך לספק (N=32768, r=8, p=1). המכשיר משתמש באותו תהליך ובאותו ערכים כדי להפיק את אותו מפתח הצפנה תוכן.

  3. צור רצף אקראי של 12 בתים בדיוק. זה וקטור האתחול שלך.

  4. צור כותרת JOSE, הגדרה alg, enc, וכן cisco-kdf מפתחות כמתואר ב הבנת תהליך זהות חיצונית עבור מכשירים . הגדר את פעולת "הוסף" באמצעות המפתח:ערך "cisco-action":"add" בכותרת JOSE שלך (כי אנחנו מוסיפים את האישור למכשיר).

  5. Base64url מקודד את הכותרת JOSE.

  6. השתמש בכלי ההצפנה שלך ב-JWE עם הצופן הנבחר וכותרת JOSE המקודדת base64url כדי להצפין את הטקסט מקובץ pem המשורשר.

  7. Base64url מקודד את וקטור האתחול, מטען ה-PEM המוצפן ותג האימות.

  8. בנה את ה-JWE blob באופן הבא (כל הערכים מקודדים base64url):

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4

פתח את ה-TShell במכשיר והפעל את פקודת ההוספה (רב שורות):

xcommand Security Certificates Services Add IsEncrypted: True
your..JWE.str.ing\n
.\n
5

ודא שהאישור נוסף על ידי הפעלה xcommand Security Certificates Services Show

העתק את טביעת האצבע של התעודה החדשה.

6

הפעל את התעודה לשם כך WebexIdentity:

  1. קרא את טביעת האצבע של התעודה, מהתעודה עצמה או מהפלט של xcommand Security Certificates Services Show.

  2. צור רצף אקראי של לפחות 4 בתים, ו-base64url מקודד את הרצף הזה. זה המלח שלך.

  3. הפק מפתח הצפנה תוכן עם כלי ההצפנה שלך.

    בשביל זה אתה צריך את הסוד, המלח ואורך מפתח שיתאימו לצופן ההצפנה שבחרת. יש עוד כמה ערכים קבועים שצריך לספק (N=32768, r=8, p=1). המכשיר משתמש באותו תהליך ובאותו ערכים כדי להפיק את אותו מפתח הצפנה תוכן.

  4. צור רצף אקראי של 12 בתים בדיוק, ו-base64url מקודד את הרצף הזה. זה וקטור האתחול שלך.

  5. צור כותרת JOSE, הגדרה alg, enc, וכן cisco-kdf מפתחות כמתואר ב הבנת תהליך זהות חיצונית עבור מכשירים . הגדר את פעולת "הפעל" באמצעות המפתח:ערך "cisco-action":"activate" בכותרת JOSE שלך (כי אנחנו מפעילים את האישור במכשיר).

  6. Base64url מקודד את הכותרת JOSE.

  7. השתמש בכלי ההצפנה של JWE שלך עם הצופן הנבחר וכותרת JOSE המקודדת base64url כדי להצפין את טביעת האצבע של האישור.

    הכלי צריך להוציא רצף של 16 או 32 בתים, תלוי אם בחרת 128 או 256 סיביות AES-GCM, ותג אימות.

  8. Base64urlencode את טביעת האצבע המוצפנת, ואת תג האימות.

  9. בנה את ה-JWE blob באופן הבא (כל הערכים מקודדים base64url):

    JOSEHeader..InitVector.EncryptedFingerprint.AuthTag

  10. פתח את ה-TShell במכשיר והפעל את פקודת ההפעלה הבאה:

                      xcommand Security Certificates Services Activate Purpose: WebexIdentity Fingerprint: "Your..JWE.encrypted.fingerprint" 
                    
למכשיר יש תעודה מוצפנת, פעילה, שהונפקה על ידי CA, המוכנה לשימוש לזיהויו בפגישות Webex מוצפנות מקצה לקצה.
7

הכנס את המכשיר לארגון Control Hub שלך.

1

קבע פגישה מהסוג הנכון ( Webex Meetings Pro-End to End Encryption_ VOIP בלבד ).

2

הצטרף לפגישה כמארח, מלקוח Webex Meetings .

3

הצטרף לפגישה ממכשיר שהזהות שלו מאומתת על ידי Webex CA.

4

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

5

הצטרף לפגישה ממכשיר שהזהות שלו מאומתת על ידי CA חיצוני.

6

כמארח, ודא שהמכשיר הזה מופיע בלובי עם סמל הזהות הנכון. למידע נוסף על סמלי זהות .

7

הצטרף לפגישה כמשתתף בפגישות לא מאומת.

8

כמארח, ודא שמשתתף זה מופיע בלובי עם סמל הזהות הנכון.

9

כמארח, הודה או דחה אנשים/מכשירים.

10

אמת את זהויות המשתתף/המכשיר במידת האפשר על ידי בדיקת התעודות.

11

בדוק שכולם בפגישה רואים את אותו קוד אבטחה לפגישה.

12

הצטרפו לפגישה עם משתתף חדש.

13

בדוק שכולם רואים את אותו קוד אבטחה חדש לפגישה.

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

האם אתה צריך לוודא שלא Cisco ולא אף אחד אחר יוכלו לפענח את התוכן שלך או להתחזות למכשירים שלך? אם כן, אתה צריך אישורים מ-CA ציבורי. ייתכן שיהיה לך רק עד 25 מכשירים בפגישה מאובטחת. אם אתה זקוק לרמת אבטחה זו, אל תאפשר ללקוחות לפגישות להצטרף.

למשתמשים שמצטרפים עם מכשירים מאובטחים, תן למכשירים להצטרף תחילה, והגדר את ציפיות המשתמש שאולי לא יוכלו להצטרף אם יצטרפו מאוחר.

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

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

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

טבלה 1. מזהי סוג הפעלה עבור פגישות מוצפנות מקצה לקצה

מזהה סוג הפעלה

שם השירות הציבורי

638

E2E Encryption+ VoIP בלבד

652

Pro-End to End Encryption_ VOIP בלבד

660

Pro 3 Free-End to End Encryption_ VOIP בלבד

E2E הצפנה + זהות

672

Pro 3 Free50-End to End Encryption_ VOIP בלבד

673

מדריך חינוך E2E Encryption_ VOIP בלבד

676

Broadworks Standard פלוס הצפנה מקצה לקצה

677

Broadworks Premium פלוס הצפנה מקצה לקצה

681

Schoology Free פלוס הצפנה מקצה לקצה

טבלאות אלו מתארות פקודות API של מכשירי Webex שהוספנו עבור פגישות מוצפנות מקצה לקצה וזהות מאומתת. למידע נוסף על אופן השימוש ב- API, ראה גש ל- API עבור Webex Room and Desk Devices ו- Webex Boards .

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

  • רשום ב- Webex

  • רשום מקומי ומקושר ל- Webex עם Webex Edge למכשירים

טבלה 2. ממשקי API ברמת המערכת לפגישות מוצפנות מקצה לקצה וזהות מאומתת

קריאת API

תיאור

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

תצורה זו מתבצעת כאשר המנהל מגדיר את הדומיין המועדף של המכשיר מ-Control Hub. הכרחי רק אם לארגון יש יותר מדומיין אחד.

המכשיר משתמש בדומיין זה כאשר הוא מבקש אישור מ- Webex CA. לאחר מכן, הדומיין מזהה את המכשיר.

תצורה זו אינה ישימה כאשר למכשיר יש תעודה פעילה שהונפקה חיצונית לזיהוי עצמו.

xStatus Conference EndToEndEncryption Availability

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

xStatus Conference EndToEndEncryption ExternalIdentity Verification

מציין אם המכשיר משתמש External אימות (בעל תעודה שהונפקה חיצונית).

xStatus Conference EndToEndEncryption ExternalIdentity Identity

זהות המכשיר כפי שנקרא מהשם המשותף של התעודה שהונפקה חיצונית.

xStatus Conference EndToEndEncryption ExternalIdentity CertificateChain Certificate # specificinfo

קורא מידע ספציפי מתעודה שהונפקה חיצונית.

בפקודה המוצגת, החלף # עם מספר התעודה. החלף specificinfo עם אחד מ:

  • Fingerprint

  • NotAfter תאריך סיום תוקף

  • NotBefore תאריך התחלה תוקף

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

  • Subject # Name רשימה של נושאי התעודה (למשל "כתובת דוא""ל" או שם דומיין)

  • Validity נותן את סטטוס התוקף של אישור זה (למשל valid או expired)

xStatus Conference EndToEndEncryption ExternalIdentity Status

מצב הזהות החיצונית של המכשיר (למשל valid או error).

xStatus Conference EndToEndEncryption InternalIdentity Verification

מציין אם למכשיר יש אישור תקף שהונפק על ידי Webex CA.

xStatus Conference EndToEndEncryption InternalIdentity Identity

זהות ההתקן כפי שנקראה מהשם המשותף של האישור שהונפק ב-Webex.

מכיל שם דומיין אם לארגון יש דומיין.

ריק אם לארגון אין דומיין.

אם המכשיר נמצא בארגון שיש לו מספר דומיינים, זה הערך מה- PreferredDomain.

xStatus Conference EndToEndEncryption InternalIdentity CertificateChain Certificate # specificinfo

קורא מידע ספציפי מהאישור שהונפק על ידי Webex.

בפקודה המוצגת, החלף # עם מספר התעודה. החלף specificinfo עם אחד מ:

  • Fingerprint

  • NotAfter תאריך סיום תוקף

  • NotBefore תאריך התחלה תוקף

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

  • Subject # Name רשימה של נושאי התעודה (למשל "כתובת דוא""ל" או שם דומיין)

  • Validity נותן את סטטוס התוקף של אישור זה (למשל valid או expired)

טבלה 3. ממשקי API בשיחות לפגישות מוצפנות מקצה לקצה וזהות מאומתת

קריאת API

תיאור

xEvent Conference ParticipantList ParticipantAdded

xEvent Conference ParticipantList ParticipantUpdated

xEvent Conference ParticipantList ParticipantDeleted

שלושת האירועים הללו כוללים כעת EndToEndEncryptionStatus, EndToEndEncryptionIdentity, וכן EndToEndEncryptionCertInfo עבור המשתתף המושפע.

טבלה 4. ממשקי API הקשורים ל-ClientSecret עבור פגישות מוצפנות מקצה לקצה וזהות מאומתת

קריאת API

תיאור

xCommand Security ClientSecret Populate Secret: "base64url-encoded"

או

xCommand Security ClientSecret Populate Secret: JWEblob

מקבל ערך טקסט רגיל מקודד base64url עבור הצגת סוד הלקוח במכשיר בפעם הראשונה.

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

xCommand Security Certificates Services Add JWEblob

מוסיף אישור (עם מפתח פרטי).

הרחבנו פקודה זו כדי לקבל בלוק JWE המכיל את נתוני ה-PEM המוצפנים.

xCommand Security Certificates Services Activate Purpose:WebexIdentity FingerPrint: JWEblob

מפעיל אישור ספציפי עבור WebexIdentity. בשביל זה Purpose, הפקודה מחייבת את טביעת האצבע המזהה להיות מוצפנת וסידרה ב-Bob של JWE.

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

מבטל אישור ספציפי עבור WebexIdentity. בשביל זה Purpose, הפקודה מחייבת את טביעת האצבע המזהה להיות מוצפנת וסידרה ב-Bob של JWE.