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

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

אימות זהות

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

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

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

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

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

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

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

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

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

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

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

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

אישור התקן שהונפק חיצונית

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

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

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

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

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

בעת שימוש בסוד הלקוח, ניתן לנהל באופן מאובטח את אישור הזהות החיצוני של 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

  • סדרת וובקס MX

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

לקוחות תוכנה

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

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

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

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

זהות

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

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

Meetings

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

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

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

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

ממשק ניהול

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

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

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

מידע קשור

גזירת כתמי JWE לדוגמה

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

  • מפגשי Webex 41.7.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • העלה את כתם JWE שנוצר למכשיר.

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

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

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

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

יהיה עליך להתייחס להצפנת האינטרנט של JSON (JWE) https://datatracker.ietf.org/doc/html/rfc7516 ולחתימת האינטרנט JSON (JWS) . https://datatracker.ietf.org/doc/html/rfc7515

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

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

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

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

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

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

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

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

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

  • תג אימות JWE: שדה זה מכיל את תג האימות כדי לוודא את שלמותו של כל הכתם הדחוס של JWE

כיצד אנו שואבים את מפתח ההצפנה מתוך ClientSecret

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

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

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

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

  • עלות-פקטור (N) היא 32768

  • BlockSizeFactor (r) הוא 8

  • גורם מקבילי (p) הוא 1

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

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

  • מכסה הזיכרון המרבי הוא 64 מגה-בתים

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

דוגמה מעובדת

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

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

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

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

  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 הוא ריק, כי אנחנו לא מספקים מפתח הצפנה JWE.

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

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

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

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

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

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

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

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

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

    זהו האלמנט החמישי בכתם JWE.

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

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

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

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

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

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

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

1

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

2

לחץ על שם האתר שלך כדי לפתוח את לוח התצורה של האתר.

3

לחץ על קביעת תצורה של אתר.

4

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

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

 

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

אנו עשויים לשנות את שמות השירות הציבורי עבור סוגי הפעלות אלה בעתיד, לדוגמה, אנו מתכננים לשנות את Pro-End ל- End Encryption_VOIPonly להצפנת E2E + זהות.

5

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

מה הלאה?

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

1

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

2

באזור השירותים , לחץ על פגישותWebex של Cisco.

3

בחר את האתר (אם המשתמש נמצא ביותר מאחד) ולחץ על מארח.

4

סמן את התיבה לצד הערך Webex Meetings שכותרתו Pro-End to End Encryption_VOIPonly.

5

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

6

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

אם ברצונך להקצות זאת למשתמשים רבים, השתמש באפשרות CSV בתפזורת.

1

היכנס אל מרכז הבקרה ופתח https://admin.webex.com את דף הפגישה .

2

לחץ על שם האתר שלך כדי לפתוח את לוח התצורה של האתר.

3

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

4

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

5

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

6

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

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

7

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

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

8

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


 

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

9

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

10

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

11

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

12

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

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

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

לפני שתתחיל

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

1

היכנס למרכז הבקרה (https://admin.webex.com) ופתח את הדף 'התקנים '.

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, הדבק את כתם המפתח בכתם האישור ושמור אותו כקובץ .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 באופן הבא (כל הערכים מקודדים ב- 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 בתים, תלוי אם בחרתם ב-AES-GCM של 128 או 256 סיביות ובתג אימות.

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

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

    JOSEHeader..InitVector.EncryptedFingerprint.AuthTag

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

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

הצמידו את המכשיר לארגון מרכז הבקרה שלכם.

1

תזמן פגישה מהסוג הנכון (Webex Meetings Pro-End to End Encryption_VOIPonly).

2

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

3

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

4

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

5

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

6

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

7

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

8

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

9

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

10

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

11

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

12

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

13

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

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

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

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

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

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

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

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

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

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

638

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

652

Pro-End to End Encryption_VOIPonly

660

Pro 3 מקצה לקצה Encryption_VOIPonly

הצפנת E2E + זהות

672

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

673

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

676

הרחבה סטנדרטית בתוספת הצפנה מקצה לקצה

677

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

681

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

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

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

  • רשום ב-Webex

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

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

קריאת API

תיאור

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

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

ההתקן משתמש בתחום זה כאשר הוא מבקש אישור מ- 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 הפקודה דורשת שטביעת האצבע המזהה תהיה מוצפנת וסדרתית בכתם JWE.,

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

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