Можливості користувача

Користувачі вибирають тип наради під час планування наради. Під час допуску учасників із холу, а також під час наради організатор може бачити стан підтвердження особи кожного учасника. Існує також код наради, загальний для всіх поточних учасників наради, який вони можуть використовувати, щоб переконатися, що їхня нарада не була перехоплена небажаною атакою третьої сторони, що знаходиться на середині (MITM).

Поділіться з організаторами наради наступною інформацією:

Перевірка особи за допомогою внутрішнього або зовнішнього CA

Підтвердьте особу

Наскрізне шифрування з перевіркою особи забезпечує додаткову безпеку нарад із наскрізним шифруванням.

Коли учасники або пристрої приєднуються до спільної групи MLS (Messaging Layer Security), вони надають свої сертифікати іншим членам групи, які потім перевіряють сертифікати в центрах сертифікації (CA), що їх видають. Підтверджуючи, що сертифікати дійсні, CA перевіряє ідентичність учасників, а на нараді відображається як перевірені учасники/пристрої.

Користувачі програми Webex автентифікуються в сховищі ідентифікаційних даних Webex, яке видає їм маркер доступу, коли автентифікація проходить успішно. Якщо їм потрібен сертифікат, щоб підтвердити свою особу на нараді з наскрізним шифруванням, CA Webex видає їм сертифікат на основі маркера доступу. Зараз ми не надаємо можливість користувачам Webex Meetings отримати сертифікат, виданий стороннім або зовнішнім CA.

Пристрої можуть аутентифікувати себе за допомогою сертифіката, виданого внутрішнім (Webex) ЦС, або сертифіката, виданого зовнішнім ЦС:

  • Внутрішній CA — Webex видає внутрішній сертифікат на основі токена доступу комп’ютерного облікового запису пристрою. Сертифікат підписаний Webex CA. Пристрої не мають ідентифікаторів користувачів так само, як користувачі, тому Webex використовує (один із) доменів вашої організації під час запису посвідчення сертифіката пристрою (Common Name (CN)).

  • Зовнішній CA — запитайте та купуйте сертифікати пристрою безпосередньо у вибраного вами емітента. Ви повинні зашифрувати, безпосередньо завантажити та авторизувати сертифікати, використовуючи секрет, відомий лише вам.

    Cisco не бере участі, що дозволяє гарантувати справжнє наскрізне шифрування та підтверджену ідентичність, а також запобігати теоретичній ймовірності того, що Cisco може підслухати вашу нараду/розшифрувати медіафайли.

Внутрішній сертифікат пристрою

Webex видає сертифікат пристрою, коли він реєструється після запуску, і поновлює його, коли це необхідно. Для пристроїв сертифікат містить ідентифікатор облікового запису та домен.

Якщо у вашій організації немає домену, вебекс-ЦС видає сертифікат без домену.

Якщо ваша організація має кілька доменів, за допомогою Центру керування можна вказати Webex, який домен використовувати для ідентифікації пристрою. Ви також можете використовувати API xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com" .

Якщо у вас кілька доменів і ви не встановлюєте бажаний домен для пристрою, то Webex вибирає один для вас.

Зовнішній сертифікат пристрою

Адміністратор може надати пристрій із власним сертифікатом, підписаним одним із загальнодоступних CAs.

Сертифікат повинен базуватися на парі ключів ECDSA P-256, хоча він може бути підписаний ключем RSA.

Значення в сертифікаті знаходяться на розсуд організації. Загальне ім’я (CN) і альтернативне ім’я суб’єкта (SAN) відображатимуться в інтерфейсі користувача наради Webex, як описано в Наскрізне шифрування з перевіркою особи для Webex Meetings .

Ми рекомендуємо використовувати окремий сертифікат для кожного пристрою та мати унікальну CN для кожного пристрою. Наприклад, «кімната-нарад-1.example.com» для організації, яка володіє доменом «example.com».

Для того щоб повністю захистити зовнішній сертифікат від фальсифікації, для шифрування і підпису різних xcommand використовується функція client-secret.

Використовуючи секрет клієнта, можна безпечно керувати зовнішнім сертифікатом посвідчення Webex через xAPI. В даний час це обмежується онлайн-пристроями.

Зараз Webex надає команди API для керування цим.

Особливості та обмеження

Пристрої

До нарад E2EE можуть приєднуватися такі пристрої серії Webex Room і Webex Desk, зареєстровані в хмарі:

  • Webex Board

  • Webex Desk Pro

  • Webex Desk

  • Webex Room Kit

  • Webex Room Kit Mini

Такі пристрої не можуть приєднуватися до нарад E2EE:

  • Вебекс серії С

  • Серія Webex DX

  • Серія Webex EX

  • Серія Webex MX

  • Сторонні SIP-пристрої

Клієнти програмного забезпечення

  • Програма Webex для комп’ютерів і мобільних клієнтів може приєднуватися до нарад E2EE.

  • Вебклієнт Webex не може приєднуватися до нарад E2EE.

  • Програмні клієнти SIP третіх сторін не можуть приєднуватися до нарад E2EE.

Ідентичність

  • За задумом ми не надаємо параметри Control Hub, щоб керувати ідентифікаційними даними пристрою, що перевіряється ззовні. Для справжнього наскрізного шифрування лише ви повинні знати та мати доступ до секретів і ключів. Якщо ми запровадили хмарний сервіс для управління цими ключами, є ймовірність їх перехоплення.

  • Наразі ми надаємо «рецепт» для розробки власних інструментів на основі стандартних галузевих методів шифрування, щоб допомогти запитувати або шифрувати сертифікати ідентифікації вашого пристрою та їхні закриті ключі. Ми не хочемо мати реального або уявного доступу до ваших секретів або ключів.

Meetings

  • Зараз наради E2EE підтримують не більше 1000 учасників.

  • Ви можете надавати спільний доступ до нових дощок на нарадах E2EE. Є деякі відмінності від дощок на звичайних нарадах:
    • На нарадах E2EE користувачі не можуть отримати доступ до дощок, створених за межами наради, зокрема приватних дощок, дощок, якими надали спільний доступ інші користувачі, а також дощок із просторів Webex.
    • Дошки, створені на нарадах E2EE, доступні лише під час наради. Вони не збережені й недоступні після завершення наради.
    • Якщо хтось надає спільний доступ до контенту на нараді E2EE, ви можете додати до нього анотацію. Додаткову інформацію про анотацію див Програма Webex| Позначте спільний контент анотаціями .

Інтерфейс управління

Настійно рекомендуємо використовувати Control Hub для керування вебсайтом Meetings, оскільки організації Control Hub мають централізовану ідентифікацію для всієї організації.

Додаткові матеріали
Передумови

  • Вебекс зустрічі 41.7.

  • Пристрої серії Webex Room і Webex Desk, зареєстровані в хмарі, працюють 10.6.1-RoomOS_ Вugust_ 2021 .

  • Адміністративний доступ до сайту наради в Control Hub.

  • Один або кілька перевірених доменів в організації Control Hub (якщо вебекс ЦС використовується для видачі сертифікатів пристрою для підтвердженої ідентичності).

  • Кімнати для нарад для співпраці потрібно ввімкнути, щоб користувачі могли приєднатися зі своєї відеосистеми. Додаткову інформацію див Дозвольте відеосистемам приєднуватися до нарад і подій на вашому вебсайті Webex .

Отримайте сертифікати пристрою

Цей крок можна пропустити, якщо вам не потрібні підтверджені ззовні посвідчення.

Для найвищого рівня безпеки та перевірки ідентичності кожен пристрій повинен мати унікальний сертифікат, виданий довіреним публічним центром сертифікації (CA).

Вам потрібно взаємодіяти з ЦС, щоб запитувати, купувати та отримувати цифрові сертифікати та створювати пов'язані приватні ключі. Запитуючи сертифікат, використовуйте такі параметри:

  • Сертифікат повинен бути виданий і підписаний відомим публічним ЦС.

  • Унікальний: Ми настійно рекомендуємо використовувати унікальний сертифікат для кожного пристрою. Якщо ви використовуєте один сертифікат для всіх пристроїв, ви ставите під загрозу свою безпеку.

  • Загальна назва (CN) та альтернативне ім'я/и суб'єкта (SAN/s): Вони не важливі для Webex, але повинні бути значеннями, які люди можуть читати та асоціювати з пристроєм. CN покаже іншим учасникам наради як основну підтверджену ідентичність пристрою, і якщо користувачі перевірять сертифікат через інтерфейс зустрічі, вони побачать SAN/и. Ви можете використовувати такі імена, як name.model@example.com .

  • Формат файлу: Сертифікати та ключі повинні бути у форматі .pem .

  • Мета: Метою сертифіката має бути webex identity.

  • Генерація ключів: Сертифікати повинні базуватися на парах ключів ECDSA P-256 (алгоритм цифрового підпису еліптичної кривої з використанням кривої P-256).

    Ця вимога не поширюється на ключ підписання. ЦС може використовувати ключ RSA для підписання сертифіката.

Підготуйтеся до вбудовування пристроїв

Цей крок можна пропустити, якщо ви не хочете використовувати перевірену зовнішню особу на своїх пристроях.

Якщо ви використовуєте нові пристрої, поки не реєструйте їх у Webex. З міркувань безпеки не підключайте їх до мережі на цьому етапі.

Якщо у вас є пристрої, які ви хочете оновити, щоб використовувати зовнішньо перевірені посвідчення, необхідно відновити заводські налаштування пристроїв.

  • Збережіть наявну конфігурацію, якщо хочете зберегти її.

  • Заплануйте вікно, коли пристрої не використовуються, або використовуйте поетапний підхід. Повідомляти користувачів про зміни, на які вони можуть розраховувати.

  • Забезпечте фізичний доступ до пристроїв. Якщо вам потрібно отримати доступ до пристроїв через мережу, майте на увазі, що секрети подорожують звичайним текстом, і ви ставите під загрозу свою безпеку.

Виконавши ці кроки, дозволити відеосистемам приєднуватися до нарад і подій на вашому вебсайті Webex .

Ознайомтеся з процесом зовнішньої ідентифікації для пристроїв

Щоб гарантувати, що медіафайли вашого пристрою не можуть бути зашифровані ніким, крім пристрою, ви повинні зашифрувати приватний ключ на пристрої. Ми розробили API для пристрою, щоб дозволити керування зашифрованим ключем і сертифікатом за допомогою вебшифрування JSON (JWE).

Щоб забезпечити справжнє наскрізне шифрування через нашу хмару, ми не можемо брати участь у шифруванні та завантаженні сертифіката та ключа. Якщо вам потрібен цей рівень безпеки, ви повинні:

  1. Замовте свої сертифікати.

  2. Створіть пари ключів ваших сертифікатів.

  3. Створіть (і захистіть) початковий секрет для кожного пристрою, щоб отримати можливість шифрування пристрою.

  4. Розробити і підтримувати власний інструмент для шифрування файлів з використанням стандарту JWE.

    Процес і необхідні (несекретні) параметри пояснюються нижче, а також рецепт, якого слід дотримуватися в обраних інструментах розробки. Ми також надаємо деякі тестові дані та отримані краплі JWE, як ми очікуємо, щоб допомогти вам перевірити ваш процес.

    Непідтримувана еталонна реалізація з використанням Python3 і бібліотеки JWCrypto доступна в Cisco за запитом.

  5. Об'єднайте та зашифруйте сертифікат і ключ, використовуючи інструмент і початковий секрет пристрою.

  6. Завантажте отриману пляму JWE на пристрій.

  7. Установіть призначення зашифрованого сертифіката, який використовуватиметься для веб-ідентифікації, і активуйте сертифікат.

  8. (Рекомендовано) Надайте інтерфейс (або розповсюджуйте) ваш інструмент, щоб дозволити користувачам пристрою змінювати початковий секрет і захистити свої медіа від вас.

Як ми використовуємо формат JWE

У цьому розділі описано, як ми очікуємо, що JWE буде створено як вхідні дані для пристроїв, щоб ви могли створити власний інструмент для створення ляпок із ваших сертифікатів та ключів.

Див Вебшифрування JSON (JWE) https://datatracker.ietf.org/doc/html/rfc7516 і Вебпідпис JSON (JWS) https://datatracker.ietf.org/doc/html/rfc7515 .

Ми використовуємо Компактна серіалізація документа JSON для створення BLOB-об’єктів JWE. Параметри, які потрібно включити під час створення BLOB-об’єктів JWE:

  • Заголовок JOSE (захищено). У заголовок JSON «Підписання об'єкта та шифрування» необхідно включити такі пари ключ-значення:

    • "alg":"dir"

      Прямий алгоритм є єдиним, який ми підтримуємо для шифрування корисного навантаження, і ви повинні використовувати початковий клієнтський секрет пристрою.

    • "enc":"A128GCM" або "enc":"A256GCM"

      Ми підтримуємо ці два алгоритми шифрування.

    • "cisco-action": "додати" або "cisco-action": "заповнити" або "cisco-action": "активувати" або "cisco-action": "деактивувати"

      Це пропрієтарний ключ і чотири значення, які він може взяти. Ми ввели цей ключ, щоб сигналізувати про призначення зашифрованих даних цільовому пристрою. Значення названі на честь команд xAPI на пристрої, де використовуються зашифровані дані.

      Ми назвали його cisco-action щоб пом’якшити потенційні конфлікти з майбутніми розширеннями JWE.

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

      Ще один фірмовий ключ. Ми використовуємо значення, які ви надаєте, як вхідні дані для виведення ключа на пристрої. , версії має бути 1 (версія нашої функції отримання ключів). Значення сіль має бути послідовністю в кодуванні URL-адреси base64 довжиною принаймні 4 байти обов’язково вибрати випадковим чином.

  • Зашифрований ключ JWE . Це поле пусте. Пристрій отримує його від початкового ClientSecret .

  • Вектор ініціалізації JWE . Ви повинні поставити закодований вектор ініціалізації base64url для розшифровки корисного навантаження. IV MUST є випадковим значенням 12 байтів (ми використовуємо сімейство шифрів AES-GCM, яке вимагає, щоб IV мав довжину 12 байт).

  • JWE AAD (додаткові дані для автентифікації). Ви повинні пропустити це поле, оскільки воно не підтримується в компактній серіалізації.

  • Зашифрований текст JWE : Це зашифроване корисне навантаження, яке ви хочете зберегти в секреті.

    Корисне навантаження МОЖЕ бути пустим. Наприклад, щоб скинути секрет клієнта, потрібно перезаписати його порожнім значенням.

    Існують різні типи корисного навантаження, залежно від того, що ви намагаєтеся зробити на пристрої. Для різних команд xAPI передбачено різне корисне навантаження, і ви повинні вказати призначення корисного навантаження за допомогою cisco-action ключ, як показано нижче:

    • З "cisco-action":"заповнити" зашифрований текст є новим ClientSecret .

    • З " "cisco-action":"додати" зашифрований текст є BLOB-об’єктом PEM, що містить сертифікат і його закритий ключ (з’єднаний).

    • З " "cisco-action":"активувати" зашифрований текст — це відбиток пальця (шістнадцяткове подання sha-1) сертифіката, який ми активуємо для перевірки ідентичності пристрою.

    • З " "cisco-action":"деактивувати" зашифрований текст — це відбиток пальця (шістнадцяткове подання sha-1) сертифіката, який ми деактивуємо для використання для перевірки ідентичності пристрою.

  • Тег аутентифікації JWE: Це поле містить тег аутентифікації для з'ясування цілісності всієї компактно серіалізованої ляпки JWE

Як ми отримуємо ключ шифрування з ClientSecret

Після першої сукупності секрету ми не приймаємо і не виводимо секрет як звичайний текст. Це робиться для запобігання потенційним атакам на словники з боку того, хто міг отримати доступ до пристрою.

Програмне забезпечення пристрою використовує клієнтський секрет як вхід до функції виведення ключа (kdf), а потім використовує похідний ключ для дешифрування/шифрування вмісту на пристрої.

Це означає для вас, що ваш інструмент для створення ляпів JWE повинен дотримуватися тієї ж процедури, щоб отримати той самий ключ шифрування/дешифрування з клієнтського секрету.

Пристрої використовують scrypt для виведення ключів (див. https://en.wikipedia.org/wiki/Scrypt), з наступними параметрами:

  • CostFactor (N) – 32768

  • BlockSizeFactor (r) дорівнює 8

  • РозпаралелюванняФактор (р) дорівнює 1

  • Salt — це випадкова послідовність із щонайменше 4 байтів; ви повинні надати це саме сіль під час визначення cisco-kdf параметра.

  • Довжина клавіш становить або 16 байт (якщо вибрати алгоритм AES-GCM 128), або 32 байти (якщо вибрати алгоритм AES-GCM 256)

  • Максимальне обмеження пам'яті становить 64 МБ

Цей набір параметрів є єдиною конфігурацією scrypt , сумісною з функцією виведення ключів на пристроях. Цей kdf на пристроях викликається "version": "1" , що є єдиною версією, наразі прийнятою cisco-kdf параметра.

Відпрацьований приклад

Ось приклад, який ви можете наслідувати, щоб переконатися, що ваш процес шифрування JWE працює так само, як і процес, який ми створили на пристроях.

Приклад сценарію - додавання ляпки PEM на пристрій (імітує додавання сертифіката, з дуже коротким рядком замість повного cert + ключа). Секрет клієнта в прикладі: кістковий камінь .

  1. Виберіть шифр шифрування. У цьому прикладі використовується A128GCM (AES зі 128-бітовими ключами в режимі лічильника Галуа). Ваш інструмент може використати A256GCM за бажанням.

  2. Виберіть сіль (повинна бути випадкова послідовність не менше 4 байт). У цьому прикладі використовується (шістнадцятковий код байтів) 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_mqd яnj_r В .

  4. Виберіть випадкову послідовність з 12 байтів для використання в якості вектора ініціалізації. У цьому прикладі використовується (шістнадцятковий) 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: eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZQWTJJOY9

    Це буде перший елемент ляпки JWE.

  6. Другий елемент blob JWE порожній, тому що ми не постачаємо ключ шифрування JWE.

  7. Третім елементом BLOB-об’єкта JWE є вектор ініціалізації NLNd3V9Te68tkpWD .

  8. Використовуйте свій інструмент шифрування JWE, щоб створити зашифроване корисне навантаження та тег. У цьому прикладі незашифрованим корисним навантаженням буде фальшивий блоб PEM це файл PEM

    Параметри шифрування, які слід використовувати:

    • Корисне навантаження є це файл PEM

    • Шифр шифрування - AES 128 GCM

    • Base64url закодував заголовок JOSE як додаткові автентифіковані дані (AAD)

    Base64url кодує зашифроване корисне навантаження, що має призвести до f5lLVuWNfKfmzYCo1YJfODhQ

    Це четвертий елемент (шифротекст JWE) в блобі JWE.

  9. Base64url кодує тег, який ви створили на кроці 8, що має призвести до PE-wDFWGXFFBeo928cfZ1Q

    Це п'ятий елемент в блоці JWE.

  10. Об'єднайте п'ять елементів краплі JWE з точками (JOSEheader.. IV.Шифротекст.Тег), щоб отримати:

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

  11. Якщо ви вивели ті самі закодовані значення base64url, які ми показуємо тут, використовуючи власні інструменти, ви готові використовувати їх для захисту шифрування E2E та підтвердженої ідентичності ваших пристроїв.

  12. Цей приклад насправді не спрацює, але в принципі вашим наступним кроком буде використання створеної вище краплі JWE як входу до xcommand на пристрої, який додає сертифікат:

    Додати сертифікати безпеки xCommand eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

Типи сеансів для нарад із нульовою довірою доступні для всіх сайтів для нарад без додаткової оплати. Один із цих типів сеансів називається Наскрізний Encryption_ Лише VOIP . Це Ім’я публічної служби , який ми можемо змінити в майбутньому. Поточні назви типів сеансів наведено в розділі Ідентифікатори типу сеансу в розділі Посилання цієї статті.

Вам не потрібно нічого робити, щоб отримати цю можливість для свого вебсайту; вам потрібно надати новий тип сеансу (також називається Права на нараду ) користувачам. Ви можете зробити це окремо через сторінку конфігурації користувача або масово за допомогою експорту/імпорту CSV.

Перевірте новий тип сеансу
1

Увійдіть до Control Hub і перейдіть до розділу Служби > Нарада.

2

Клацніть Вебсайти, виберіть вебсайт Webex, для якого потрібно змінити налаштування, а потім натисніть Налаштування.

3

У розділі Загальні параметривиберіть Типи сеансів.

4
Ви повинні побачити один або кілька типів сеансів наскрізного шифрування. Зверніться до списку ідентифікаторів типу сеансу в розділі "Посилання " цієї статті. Наприклад, ви можете побачити Pro-End to End Encryption_VOIPonly.

Існує більш старий тип сеансу з дуже схожою назвою: Професійне наскрізне шифрування . Цей тип сеансу включає незашифрований доступ тмЗК до нарад. Переконайтеся, що у вас є_ Лише VOIP версії для забезпечення наскрізного шифрування. Можна перевірити, навівши вказівник миші на ПРОФ посилання в стовпці коду сеансу; у цьому прикладі цільовим елементом посилання має бути javascript:ShowFeature(652) .

У майбутньому ми можемо змінити імена загальнодоступних служб для цих типів сеансів.

5

Якщо у вас ще немає нового типу сеансу, зв'яжіться зі своїм представником Webex.

Що далі

Увімкніть цей тип сеансу / привілей зустрічі для деяких або всіх ваших користувачів.

Увімкніть наради E2EE для окремих користувачів
1

Увійти в Control Hub , і перейдіть до Керування > Користувачі .

2

Виберіть обліковий запис користувача для оновлення, а потім виберіть Наради .

3

З Налаштування застосовуються до виберіть сайт наради, який потрібно оновити.

4

Установіть прапорець поруч із Наскрізний Encryption_ Лише VOIP .

5

Закрийте панель конфігурації користувача.

6

За потреби повторіть цю процедуру для інших користувачів.

Щоб призначити це багатьом користувачам, використовуйте наступний параметр: Увімкніть наради E2EE для кількох користувачів .

Увімкніть наради E2EE для кількох користувачів
1

Увійдіть до Control Hub і перейдіть до розділу Служби > Нарада.

2

Клацніть Сайти , виберіть вебсайт Webex, для якого потрібно змінити налаштування.

3

У розділі Ліцензії та користувачі виберіть пункт Групове керування.

4

Клацніть Створити звіт , і зачекайте, поки ми підготуємо файл.

5

Коли файл буде готовий, натисніть кнопку Експортувати результати , а потім – Завантажити. (Ви повинні вручну закрити це спливаюче вікно після клацання Завантажити .)

6

Відкрийте завантажений файл CSV для редагування.

Для кожного користувача існує рядок і Права на нараду стовпець містить їхні ідентифікатори типів сеансів у вигляді списку, розділеного комами.

7

Для кожного користувача, якому потрібно надати новий тип сеансу, додайте 1561 як нове значення в роздільному комами списку в Права на нараду клітинку.

, Довідка про формат файлу CSV Webex містить відомості про призначення та вміст файлу CSV.

8

Відкрийте панель конфігурації сайту наради в Центрі керування.

Якщо ви вже були на сторінці списку сайтів наради, можливо, знадобиться оновити її.

9

У розділі Ліцензії та користувачі виберіть пункт Групове керування.

10

Натисніть кнопку Імпорт і виберіть відредагований файл CSV, а потім натисніть кнопку Імпорт. Зачекайте, поки файл буде завантажено.

11

Після завершення імпорту можна натиснути кнопку Імпорт результатів , щоб перевірити, чи не було помилок.

12

Перейдіть на сторінку Користувачі та відкрийте одного з користувачів, щоб переконатися, що у них новий тип сеансу.

Додавання аудіопідкладки з метою безпеки

Ви можете додати підкладку до записів нарад за допомогою Webex Meetings Pro-End-End-Endncryption_ Лише VOIP тип сеансу, який дозволяє ідентифікувати клієнта або пристрою-джерела несанкціонованих записів конфіденційних нарад.

Якщо цю функцію ввімкнено, аудіо наради містить унікальний ідентифікатор для кожного клієнта або пристрою, що бере участь. Ви можете передати аудіозаписи до Control Hub, який потім аналізує запис і шукає унікальні ідентифікатори. Ви можете переглянути результати, щоб дізнатися, на якому клієнті або пристрої записалася нарада.

  • Для аналізу запис має бути файлом AAC, MP3, M4A, WAV, MP4, AVI або MOV розміром не більше ніж 500 МБ.
  • Тривалість запису повинна перевищувати 100 секунд.
  • Ви можете аналізувати записи лише для нарад, організованих користувачами вашої організації.
  • Інформація про підкладку зберігається впродовж тієї ж тривалості, що й інформація про нараду організації.

Додайте аудіопідкладки до нарад E2EE

  1. Увійти в Control Hub , потім під Керування , виберіть Налаштування організації .
  2. У Підкладки наради розділ, увімкніть Додати аудіопідкладку .

    Через деякий час після ввімкнення цього параметра користувачі планують наради за допомогою Webex Meetings Pro-End-End-Endncryption_ Лише VOIP тип сеансу, див. a Цифровий водяний знак у розділі Безпека.

Передати й проаналізувати нараду з підкладкою

  1. У Control Hub, під Моніторинг , виберіть Усунення несправностей .
  2. Клацніть Аналіз підкладки .
  3. Знайдіть або виберіть нараду в списку, а потім клацніть Аналізувати .
  4. У Проаналізуйте аудіопідкладку вікно, введіть ім’я для аналізу.
  5. (Необов’язково) Введіть примітку для аналізу.
  6. Перетягніть аудіофайл, який потрібно проаналізувати, або клацніть Виберіть файл , щоб перейти до аудіофайлу.
  7. Клацніть Закрити.

    Після завершення аналізу його буде відображено в списку результатів на Аналізувати підкладку сторінка.

  8. Виберіть нараду в списку, щоб переглянути результати аналізу. КлацнітьКнопка "Завантажити" , щоб завантажити результати.

Особливості та обмеження

Фактори успішного декодування записаного підкладки включають відстань між записуючим пристроєм і динаміком, який виводить аудіо, гучність цього аудіо, шум навколишнього середовища тощо. Наша технологія підкладки має додаткову стійкість до багаторазового кодування, що може статися під час спільного доступу до медіафайлів.

Ця функція призначена для успішного декодування ідентифікатора підкладки за широкого, але розумного набору обставин. Наша мета полягає в тому, щоб пристрій запису, як-от мобільний телефон, який лежить на столі поруч із персональним кінцевим пристроєм або клієнтом ноутбука, завжди повинен створювати запис, який призводить до успішного аналізу. Оскільки записуючий пристрій віддалено від джерела звуку або він не чує повний спектр аудіо, шанси на успішний аналіз зменшуються.

Щоб успішно проаналізувати запис, потрібен розумний запис аудіо наради. Якщо аудіо наради записано на тому самому комп’ютері, де розміщено клієнт, обмеження не повинні застосовуватися.

Вбудовані пристрої (внутрішній CA)

Якщо ваші пристрої вже підключено до вашої організації Control Hub і ви хочете використовувати CA Webex для автоматичного створення ідентифікаційних сертифікатів, відновлювати заводські налаштування пристроїв не потрібно.

Ця процедура визначає, який домен використовує пристрій для ідентифікації себе, і потрібна, лише якщо в організації Концентратора керування є кілька доменів. Якщо у вас кілька доменів, ми рекомендуємо зробити це для всіх ваших пристроїв, які матимуть "перевірену Cisco" ідентичність. Якщо ви не вкажете Webex, який домен ідентифікує пристрій, один із доменів буде вибрано автоматично, і інші учасники наради можуть виглядати неправильно.

Перш ніж почати

Якщо ваші пристрої ще не підключені, виконайте дії Зареєструйте пристрій у Cisco Webex за допомогою API або локального вебінтерфейсу або Хмарне приєднання для серії Board, Desk і Room . Також потрібно перевірити домени, які ви хочете використовувати для ідентифікації пристроїв Керуйте своїми доменами .

1

Увійти в Control Hub , і нижче Керування , виберіть Пристрої .

2

Виберіть пристрій, щоб відкрити його панель конфігурації.

3

Виберіть домен, який потрібно використовувати для ідентифікації цього пристрою.

4

Повторіть цю дію для інших пристроїв.

Вбудовані пристрої (зовнішній CA)

Перш ніж почати

  • Отримайте підписаний CA сертифікат і закритий ключ .pem формат, для кожного пристрою.

  • Під Підготуватися вкладці, прочитайте тему Розуміння процесу зовнішньої ідентифікації для пристроїв ,

  • Підготуйте інструмент шифрування JWE щодо наданої інформації.

  • Переконайтеся, що у вас є інструмент для створення випадкових послідовностей байтів заданої довжини.

  • Переконайтеся, що у вас є інструмент для кодування байтів або тексту base64url.

  • Переконайтеся, що у вас є scrypt впровадження.

  • Переконайтеся, що ви маєте секретне слово або фразу для кожного пристрою.

1

Заповніть пристрій ClientSecret із секретом у вигляді простого тексту:

Під час першого заповнення Секретний , ви надаєте його у вигляді звичайного тексту. Тому ми рекомендуємо робити це на консолі фізичного пристрою.

  1. Base64url кодує секретну фразу для цього пристрою.

  2. Відкрийте TShell на пристрої.

  3. Виконати xcommand Security ClientSecret Секрет заповнення: "MDEyMzQ1Njc4OWFiY2RlZg"

    Наведений вище приклад команди заповнює Секретний з фразою0123456 789abcdef . Вибирати потрібно свій.

Пристрій має свій початковий секрет. Не забувайте про це; його неможливо відновити, і для повторного запуску потрібно відновити заводські налаштування пристрою.
2

Об'єднайте сертифікат і закритий ключ:

  1. За допомогою текстового редактора відкрийте файли .pem, вставте ляпку ключа на blob сертифіката та збережіть його як новий файл .pem.

    Це текст корисного навантаження, який ви зашифруєте та помістіть у свій блоб JWE.

3

Створіть ляпку JWE, щоб використовувати її як вхідні дані для команди додавання сертифіката:

  1. Створіть випадкову послідовність не менше 4 байт. Це ваша сіль.

  2. Отримайте ключ шифрування вмісту за допомогою інструменту scrypt.

    Для цього вам потрібні секрет, сіль і довжина ключа, щоб відповідати обраному шифру шифрування. Існують деякі інші фіксовані значення для постачання (N=32768, r=8, p=1). Пристрій використовує той самий процес і значення для отримання одного і того ж ключа шифрування вмісту.

  3. Створіть випадкову послідовність рівно в 12 байт. Це ваш вектор ініціалізації.

  4. Створити заголовок JOSE, налаштування alg , enc , і cisco-kdf ключі, як описано в Розуміння процесу зовнішньої ідентифікації для пристроїв . Установіть дію "додати" за допомогою ключ:значення "cisco-action":"додати" у вашому заголовку JOSE (оскільки ми додаємо сертифікат на пристрій).

  5. Base64url кодує заголовок JOSE.

  6. Використовуйте свій інструмент шифрування JWE з обраним шифром і закодованим заголовком JOSE base64url, щоб зашифрувати текст з об'єднаного файлу pem.

  7. Base64url кодує вектор ініціалізації, зашифроване корисне навантаження PEM і тег аутентифікації.

  8. Побудуйте blob JWE наступним чином (всі значення закодовані за основою64url):

    Заголовок JOSE.Вектор ініціалізації.ЗашифрованийPEM.Тег автентифікації

4

Відкрийте TShell на пристрої та запустіть команду (багаторядкове) add: 

Додати служби сертифікатів безпеки xcommand IsEncrypted: True ваш..JWE.str.ing\n .\n
5

Переконайтеся, що сертифікат додано, запустивши Показати служби сертифікатів безпеки xcommand

Скопіюйте відбиток пальця нового сертифіката.

6

Активуйте сертифікат для цієї мети WebexIdentity :

  1. Зчитуйте відбиток сертифіката з самого сертифіката або з виводу Показати служби сертифікатів безпеки xcommand .

  2. Створіть випадкову послідовність принаймні 4 байти та закодуйте цю послідовність base64url. Це ваша сіль.

  3. Отримайте ключ шифрування вмісту за допомогою інструменту scrypt.

    Для цього вам потрібні секрет, сіль і довжина ключа, щоб відповідати обраному шифру шифрування. Існують деякі інші фіксовані значення для постачання (N=32768, r=8, p=1). Пристрій використовує той самий процес і значення для отримання одного і того ж ключа шифрування вмісту.

  4. Створіть випадкову послідовність рівно 12 байтів і base64url закодуйте цю послідовність. Це ваш вектор ініціалізації.

  5. Створити заголовок JOSE, налаштування alg , enc , і cisco-kdf ключі, як описано в Розуміння процесу зовнішньої ідентифікації для пристроїв . Установіть дію "активувати", використовуючи ключ:значення "cisco-action":"активувати" у вашому заголовку JOSE (оскільки ми активуємо сертифікат на пристрої).

  6. Base64url кодує заголовок JOSE.

  7. Використовуйте інструмент шифрування JWE з вибраним шифром і закодованим заголовком JOSE base64url, щоб зашифрувати відбиток сертифіката.

    Інструмент повинен вивести послідовність 16 або 32 байтів, в залежності від того, вибрали ви 128 або 256 біт AES-GCM, і тег аутентифікації.

  8. Base64urlencode – зашифрований відбиток пальця та тег автентифікації.

  9. Побудуйте blob JWE наступним чином (всі значення закодовані за основою64url):

    Заголовок JOSE.Вектор ініціалізації.Зашифрований відбиток пальця.Тег автентифікації

  10. Відкрийте TShell на пристрої і запустіть наступну команду активувати:

     Мета активації служб сертифікатів безпеки xcommand: Відбиток WebexIdentity: "Ваш..JWE.encrypted.fingerprint"

Пристрій має зашифрований, активний сертифікат, виданий CA, готовий до використання для його ідентифікації на наскрізно зашифрованих зустрічах Webex.
7

Підключення пристрою до вашої організації Control Hub.

Перевірте наскрізне шифрування з перевіркою особи
1

Заплануйте зустріч правильного типу (Webex Meetings Pro-End to End Encryption_VOIPonly).

Дивіться Планування зустрічі Webex з наскрізним шифруванням.

2

Приєднуйтесь до зустрічі в якості ведучого з клієнта Webex Meetings.

Дивіться Приєднатися до вебекс-зустрічі з наскрізним шифруванням.

3

Приєднуйтесь до наради з пристрою, посвідчення якого підтверджено вебекс-ц.єктом.

4

Як хост, переконайтеся, що цей пристрій з'являється у фойє з правильним значком ідентичності.

Дивіться Приєднатися до вебекс-зустрічі з наскрізним шифруванням.

5

Приєднання до наради з пристрою, посвідчення якого підтверджено зовнішнім ЦС.

6

Як хост, переконайтеся, що цей пристрій з'являється у фойє з правильним значком ідентичності. Докладніше про значки ідентифікаційних даних .

7

Приєднання до наради в якості неавтентифікованого учасника наради.

8

Як ведучий, переконайтеся, що цей учасник з'являється у фойє з правильним значком ідентичності.

9

Як господар, визнайте або відхиляйте людей / пристрої.

10

За можливості перевіряйте ідентифікаційні дані учасника/пристрою, перевіряючи сертифікати.

11

Переконайтеся, що всі учасники наради бачать однаковий код безпеки наради.

12

Приєднання до наради з новим учасником.

13

Переконайтеся, що всі бачать однаковий новий код безпеки наради.

Встановіть сферу застосування та очікування

  • Чи збираєтеся ви зробити наскрізні зашифровані наради опцією зустрічі за замовчуванням, або ввімкнути її лише для деяких користувачів, або дозволити всім хостам приймати рішення? Коли ви вирішите, як ви збираєтеся використовувати цю функцію, підготуйте тих користувачів, які будуть її використовувати, особливо щодо обмежень і того, чого очікувати під час зустрічі.

  • Вам потрібно переконатися, що ні Cisco, ні будь-хто інший не зможуть розшифрувати ваш вміст або видати себе за ваші пристрої? Якщо так, вам потрібні сертифікати від загальнодоступного ЦС.

  • Якщо у вас є різні рівні перевірки ідентичності, надайте користувачам можливість перевіряти один одного за допомогою посвідчень на основі сертифікатів. Незважаючи на те, що існують обставини, коли учасники можуть з'явитися як Неперевірені, і учасники повинні знати, як перевірити, неперевірені люди можуть не бути самозванцями.

Управління ідентифікацією

Якщо ви використовуєте зовнішній ЦС для видачі сертифікатів пристрою, ви повинні відстежувати, оновлювати та повторно застосовувати сертифікати.

Якщо ви створили початковий секрет, зрозумійте, що ваші користувачі можуть захотіти змінити секрет свого пристрою. Вам може знадобитися створити інтерфейс / розповсюдити інструмент, щоб вони могли це зробити.

Ідентифікатори типу сеансу
Таблиця 1. Ідентифікатори типу сеансу для наскрізно зашифрованих нарад

Ідентифікатор типу сеансу

Назва державної служби

638

Лише шифрування E2E+VoIP

652

Pro-End to End Encryption_VOIPonly

660

Pro 3 Free-End to End Encryption_VOIPonly

Шифрування E2E + ідентичність

672

Pro 3 Free50-End to End Encryption_VOIPonly

673

Освіта інструктора E2E Encryption_VOIPonly

676

Стандарт broadworks плюс наскрізне шифрування

677

Broadworks Premium плюс наскрізне шифрування

681

Schoology Free plus наскрізне шифрування

Пов'язані команди xAPI

Ці таблиці описують команди API пристроїв Webex, які ми додали для наскрізно зашифрованих зустрічей та підтвердженої ідентичності. Для отримання додаткової інформації про те, як використовувати API, перегляньте статтю Доступ до API для пристроїв Webex Room and Desk і Webex.

Ці команди xAPI доступні лише на пристроях, які:

  • Зареєстровано на Webex

  • Зареєстрований локально та пов'язаний з Webex за допомогою Webex Edge для пристроїв

Таблиця 2. API системного рівня для наскрізно зашифрованих нарад і підтвердженої ідентичності

Виклик API

Опис

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

Ця конфігурація здійснюється, коли адміністратор встановлює бажаний домен пристрою з Control Hub. Необхідно тільки в тому випадку, якщо в організації є кілька доменів.

Пристрій використовує цей домен, коли запитує сертифікат від Webex CA. Потім домен ідентифікує пристрій.

Ця конфігурація не застосовується, коли пристрій має активний сертифікат, виданий зовнішнім рахунком, для ідентифікації себе.

Доступність шифрування xStatus конференції EndToEnd

Вказує, чи може пристрій приєднатися до наскрізної зашифрованої наради. Хмарний API називає його, щоб парний додаток знав, чи може він використовувати пристрій для приєднання.

xStatus конференції EndToEndEncryption Перевірка зовнішньоїідентичності

Указує, чи використовує пристрій Зовнішній перевірка (має сертифікат, виданий зовнішнім).

Ідентифікація зовнішньоїідентичності ExternalIdentity EndToEndEndcryption для конференції xStatus

Ідентичність пристрою, прочитана із загального імені зовнішньо виданого сертифіката.

xStatus конференції EndToEndEncryption ExternalIdentity CertificateChain Certificate# конкретна інформація

Зчитує конкретну інформацію із зовнішньо виданого сертифіката.

У показаній команді замініть # з номером сертифіката. Замінити конкретна інформація з одним із:

  • Відбиток пальця

  • Непісля Дата завершення дії

  • NotBefore Дата початку дії

  • PrimaryName

  • Алгоритм відкритого ключа

  • Серійний номер

  • Алгоритм підпису

  • Тема # Ім’я Список тем для сертифіката (наприклад, адреса електронної пошти або ім’я домену)

  • Термін дії Надає стан дійсності цього сертифіката (наприклад, дійсний або термін дії завершився )

Стан xStatus конференції EndToEndEncryption ExternalIdentity

Стан зовнішньої ідентичності пристрою (наприклад, дійсний або помилка ).

xStatus конференції EndToEndEncryption Внутрішня перевіркаідентичності

Вказує, чи має пристрій дійсний сертифікат, виданий Webex CA.

xStatus конференції EndToEndEncryption Ідентифікація внутрішньоїідентичності

Ідентичність пристрою, прочитана із загальної назви сертифіката, виданого Webex.

Містить доменне ім'я, якщо в організації є домен.

Пустий, якщо в організації немає домену.

Якщо пристрій належить організації, що має кілька доменів, це значення з БажанийДомен .

xStatus конференції EndToEndEncryption CertificateInternalIdentityChainСертифікат № конкретна інформація

Зчитує конкретну інформацію із сертифіката, виданого Webex.

У показаній команді замініть # з номером сертифіката. Замінити конкретна інформація з одним із:

  • Відбиток пальця

  • Непісля Дата завершення дії

  • NotBefore Дата початку дії

  • PrimaryName

  • Алгоритм відкритого ключа

  • Серійний номер

  • Алгоритм підпису

  • Тема # Ім’я Список тем для сертифіката (наприклад, адреса електронної пошти або ім’я домену)

  • Термін дії Надає стан дійсності цього сертифіката (наприклад, дійсний або термін дії завершився )

Таблиця 3. В API викликів для наскрізно зашифрованих нарад і підтвердженої ідентичності

Виклик API

Опис

xEvent Conference ParticipantListParticipantAdded

Список учасників конференції xEventУчасникСписок учасниківоновлено

Учасник конференції xEventСписок учасниківВидалено

Ці три події тепер включають EndToEndEncryptionStatus , ЗавершитиІдентифікаціюШифрування , і ЗавершитиКіннюКерітьІнфо сертифіката шифрування для відповідного учасника.

Таблиця 4. КлієнтСекрет пов'язані API для наскрізно зашифрованих зустрічей і підтвердженої особистості

Виклик API

Опис

xCommand Security ClientSecret Секрет заповнення: "base64url-encoded"

або

xCommand Security ClientSecret Секрет заповнення: JWEblob

Приймає закодоване простим текстовим значенням base64url для першого посіву клієнтського секрету на пристрої.

Щоб оновити секрет після цього першого разу, ви повинні надати краплю JWE, що містить новий секрет, зашифрований старим секретом.

Додати служби сертифікатів xCommand Security JWEblob

Додає сертифікат (з закритим ключем).

Ми розширили цю команду, щоб прийняти ляпку JWE, що містить зашифровані дані PEM.

Мета активації служб сертифікатів безпеки xCommand:Відбиток пальця WebexIdentity: JWEblob

Активує певний сертифікат для WebexIdentity. Для цього Мета , команда вимагає, щоб ідентифікаційний відбиток був зашифрований і серіалізований у BLOB-об’єкті JWE.

Деактивувати служби сертифікатів xCommand Security Призначення: WebexIdentity FingerPrint: JWEblob

Деактивує певний сертифікат для WebexIdentity. Для цього Мета , команда вимагає, щоб ідентифікаційний відбиток був зашифрований і серіалізований у BLOB-об’єкті JWE.