חוויית משתמש

המשתמשים בוחרים את סוג הפגישה כשהם מתזמנים פגישה. בעת הכנסת משתתפים מהלובי, כמו גם במהלך הפגישה, המארח יכול לראות את מצב אימות הזהות של כל משתתף. יש גם קוד פגישה שמשותף לכל המשתתפים הנוכחיים בפגישה, שבו הם יכולים להשתמש כדי לוודא שהפגישה שלהם לא נקלטה על-ידי מתקפת צד שלישי לא רצויה של Meddler In The Middle (MITM).

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

אימות זהות עם CA פנימי או חיצוני

אמת זהות

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

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

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

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

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

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

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

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

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

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

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

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

אישור מכשיר שהונפק באופן חיצוני

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

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

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

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

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

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

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

תכונות ומגבלות

מכשירים

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

  • לוח Webex

  • Webex Desk Pro

  • שולחן העבודה של Webex

  • ערכת חדר של Webex

  • ערכת Webex Room Mini

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

  • סדרת Webex C

  • סדרת Webex DX

  • סדרת Webex EX

  • סדרת Webex MX

  • מכשירי SIP של צד שלישי

לקוחות תוכנה

  • יישום Webex עבור לקוחות שולחניים ולקוחות ניידים יכולים להצטרף לפגישות E2EE.

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

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

זהות

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

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

פגישות

  • פגישות E2EE תומכות כעת לכל היותר 1000 משתתפים.

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

ממשק ניהול

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

משאבים נוספים
תנאים מוקדמים

  • Webex Meetings 41.7.

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

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

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

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

קבל אישורי מכשיר

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

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

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

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

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

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

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

  • מטרה: מטרת התעודה חייבת להיות Webex Identity.

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

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

הכן לצרף מכשירים

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

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

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

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

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

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

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

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

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

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

  1. בקש את האישורים שלך.

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

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

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

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

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

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

  6. העלה את blob JWE שנוצר למכשיר.

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

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

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

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

עיין בJSON Web Encryption (JWE) https://datatracker.ietf.org/doc/html/rfc7516 וJSON Web Signature (JWS) https://datatracker.ietf.org/doc/html/rfc7515.

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

  • כותרת 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 MUST להיות ערך אקראי של 12 בתים (אנו משתמשים במשפחת צופן aes-gcm, שדורשת שה-iv יהיה באורך של 12 בתים).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • CostFactor (N) הוא 32768

  • BlockSizeFactor (r) הוא 8

  • ParallelFactor (p) הוא 1

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

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

  • נפח זיכרון מקסימלי הוא 64MB

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

דוגמה עובדת

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

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

  1. בחר צופן הצפנה. דוגמה זו משתמשת ב-A128GCM (AES עם מקשי 128 סיביות במצב מונה של גלואה). ניתן להשתמש בכלי שלך 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 בתים (הקסדצימלי) כדלקמן: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 עם serialization קומפקטית (בצע את אותו סדר של פרמטרים שבהם אנו משתמשים כאן) ולאחר מכן base64url מקודד אותו:

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

    כותרת JOSE מקודדת בסיס64url היא eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

    זה יהיה האלמנט הראשון של blob JWE.

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

  7. הרכיב השלישי של blob JWE הוא וקטור האתחול NLNd3V9Te68tkpWD.

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

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

    • תוכן מנה הוא this is a PEM file

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

    • הבסיס64url מקודד כותרת JOSE כנתונים מאומתים נוספים (AAD)

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

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

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

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

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

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

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

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

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

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

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

אמת את סוג המפגש החדש
1

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

2

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

3

תחת הגדרות נפוצות, בחר סוגי הפעלה.

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

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

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

4

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

מה הלאה

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

הפעל פגישות E2EE עבור משתמשים בודדים
1

היכנס אל Control Hub ועבור אל ניהול > משתמשים.

2

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

3

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

4

סמן את התיבה לצד Pro-End to End Encryption_VOIPonly.

5

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

6

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

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

הפעל פגישות E2EE עבור משתמשים מרובים
1

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

2

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

3

במקטע רישיונות ומשתמשים , לחץ על נהל בצובר.

4

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

5

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

6

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

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

7

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

הפניה לתבנית קובץ CSV של Webex מכילה פרטים על המטרה והתוכן של קובץ ה-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. בחר את הפגישה ברשימה כדי לראות את תוצאות הניתוח. לחץ על לחצן 'הורד' כדי להוריד את התוצאות.

תכונות ומגבלות

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

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

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

צרף מכשירים (CA פנימי)

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

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

לפני שתתחיל

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

1

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

2

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

3

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

4

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

צרף מכשירים (CA חיצוני)

לפני שתתחיל

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

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

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

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

  • ודא שיש לך כלי לבסיס64url קידוד בתים או טקסט.

  • ודא שיש לך scrypt יישום.

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

1

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

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

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

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

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

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

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

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

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

    זהו טקסט המטען שתמצפין ותשים בבלוחית JWE שלך.

3

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

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

  2. גזור מפתח הצפנת תוכן עם כלי הגירוד שלך.

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

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

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

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

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

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

  8. בנה את blob JWE כדלקמן (כל הערכים מקודדים בבסיס64url):

    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. צור כותרת, הגדרה alg, enc וcisco-kdf מקשים של JOSE כפי שמתואר בהבנת זהות חיצונית עבור מכשירים. הגדר את פעולת "הפעלה" באמצעות מקש:value "cisco-action":"activate" בכותרת JOSE שלך (מכיוון שאנחנו מפעילים את התעודה במכשיר).

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

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

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

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

  9. בנה את blob JWE כדלקמן (כל הערכים מקודדים בבסיס64url):

    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-מקצה לקצה Encryption_VOIPonly).

ראה תזמון פגישה ב-Webex עם הצפנה מקצה לקצה.

2

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

ראה הצטרף לפגישת Webex עם הצפנה מקצה לקצה.

3

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

4

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

ראה הצטרף לפגישת Webex עם הצפנה מקצה לקצה.

5

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

6

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

7

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

8

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

9

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

10

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

11

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

12

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

13

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

הגדרת היקף וציפיות

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

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

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

ניהול זהויות

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

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

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

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

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

638

הצפנת E2E+VoIP בלבד

652

פרו-מקצה לקצהncryption_VOIPבלבד

660

Pro 3 מקצה לקצה Encryption_VOIPonly

הצפנת E2E + זהות

672

Pro 3 חינם50 מקצה לקצה Encryption_VOIPonly

673

מדריך חינוך E2E Encryption_VOIPonly

676

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

677

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

681

Schoology חינם בתוספת הצפנה מקצה לקצה

פקודות xAPI קשורות

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

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

  • רשום ב-Webex

  • רשום באופן מקומי ומקושר ל-Webex עם Webex Edge למכשירים

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

שיחת API

ערך FALSE (הסתכל בסוג boolean).

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

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

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

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

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)

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

שיחת API

ערך FALSE (הסתכל בסוג boolean).

xEvent Conference ParticipantList ParticipantAdded

xEvent Conference ParticipantList ParticipantUpdated

xEvent Conference ParticipantList ParticipantDeleted

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

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

שיחת API

ערך FALSE (הסתכל בסוג boolean).

xCommand Security ClientSecret Populate Secret: "base64url-encoded"

או

xCommand Security ClientSecret Populate Secret: JWEblob

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

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

xCommand Security Certificates Services Add JWEblob

מוסיף תעודה (עם מפתח פרטי).

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

xCommand Security Certificates Services Activate Purpose:WebexIdentity FingerPrint: JWEblob

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

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

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