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

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

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

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

Перевірити посвідчення

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ми рекомендуємо використовувати окремий сертифікат на один пристрій і унікальну кількість номерів (CN) на один пристрій. "Наприклад, ""meeting-room-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 для керування вебсайтом для нарад, оскільки організації Control Hub мають централізовану ідентичність для всієї організації.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Підготовка до підключення пристроїв

Можна пропустити цей крок, якщо не хочете використовувати зовнішньо підтверджені ідентифікаційні дані для своїх пристроїв.

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

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

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

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

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

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

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

Щоб гарантувати, що медіафайли вашого пристрою не можуть бути зашифровані ніким, крім пристрою, ви повинні зашифрувати приватний ключ на пристрої. Ми розробили API для пристрою, щоб дозволити керування зашифрованим ключем і сертифікатом за допомогою JSON Web Encryption (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 Web Signature (JWS) https://datatracker.ietf.org/doc/html/rfc7515.

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

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

    • "alg":"dir"

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

    • «enc»:«A ｟_ph_20｠ GCM» або «enc»:«A ｟_ph_20｠ GCM»

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

    • "cisco-action": "add" або "cisco-action": "populate" або "cisco-action": "activate" або "cisco-action": "деактивувати"

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

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

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

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

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

  • Вектор ініціалізації JWE. Ви повинні поставити закодований вектор ініціалізації base64url для розшифровки корисного навантаження. IV MUST є випадковим значенням 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":"деактивувати" текст шифру є відбитком пальця (шістнадцяткове представлення sha-1) сертифіката, який ми деактивуємо, оскільки використовується для перевірки ідентифікації пристрою."

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

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

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

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

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

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

  • CostFactor (N) – 32768

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

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

  • Сіль — це випадкова послідовність, що містить щонайменше 4 байти. Цю саму сіль потрібно постачати при заданні параметра cisco-kdf .

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

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

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

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

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

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

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

  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 кодує lZ128 bdEiAQV4_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","версія":"1"},"enc":"A165 GCM"}

    Заголовок бази64url, кодований JOSE, eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

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

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

  7. Третій елемент JWE blob — вектор ініціалізації 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.

Існує більш старий тип сеансу з дуже схожою назвою: Наскрізне шифрування. Цей тип сеансу включає незашифрований доступ тмЗК до нарад. Щоб забезпечити наскрізне шифрування, упевніться, що версія _VOIPonly . Ви можете перевірити, навевши вказівник на посилання PRO в стовпці коду сеансу. Для цього прикладу ціль посилання має бути javascript:ShowFeature(652).

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

5

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

Що далі

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

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

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

2

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

3

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

4

Установіть прапорець поруч із Pro-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

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

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

9

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

10

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

11

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

12

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

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

Можна додати підкладку до записів нарад за допомогою типу сеансу Webex Meetings Pro-End Encryption_VOIPonly , що дозволить ідентифікувати клієнта-джерела або пристрій неавторизованих записів конфіденційних нарад.

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

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

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

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

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

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

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

    Коли аналіз буде завершено, він з’явиться в списку результатів на сторінці Аналізувати підкладку .

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

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

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

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

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

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

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

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

Перед початком

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

1

Увійдіть у Control Hub і в розділі Керування виберіть Пристрої.

2

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

3

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

4

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

Підключені пристрої (зовнішній CA)

Перед початком

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

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

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

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

  • Переконайтеся, що у вас є інструмент для бази64URL-кодування байтів або тексту.

  • Упевніться, що у вас є scrypt реалізація.

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

1

Заповніть ClientSecret пристрою простим текстовим секретом:

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

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

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

  3. Запустити xcommand Security ClientSecret Populate Secret: "MDEyMzQ1Njc4OWFiY2RlZg"

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

Пристрій має свій початковий секрет. Не забувайте про це. Його неможливо відновити. Щоб запустити знову, потрібно скинути заводські налаштування.
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 , як описано в розділі Розуміння процесу зовнішньої ідентифікації для пристроїв. Установіть дію "Додати" за допомогою ключа: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 на пристрої та запустіть команду (багаторядкове) add: 

Додавання служб сертифікатів безпеки xcommand зашифровано: Дійсно ваш..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 , як описано в розділі Розуміння процесу зовнішньої ідентифікації для пристроїв. Установіть дію «Активувати» за допомогою ключа:value «cisco-action»:«Активувати» у заголовку JOSE (оскільки ми активуємо сертифікат на пристрої).

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

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

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

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

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

    JOSEHeader..InitVector. EncryptedFingerprint. AuthTag

  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. Потім домен ідентифікує пристрій.

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

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

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

Перевірка зовнішньої ідентифікації для наскрізного шифрування конференції xStatus

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

Конференція xStatus EndToEndEncryption ExternalIdentity

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

xStatus EndToEndEncryption ExternalIdentity CertificateChain Certificate # specificinfo

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

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

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

  • Дата завершення терміну дії не пізніше

  • Дата початку терміну дії не раніше

  • Основне ім’я

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

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

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

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

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

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

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

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

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

xStatus НаскрізнеШифрування Внутрішня ідентифікація

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

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

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

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

xStatus Conference EndToEndEncryption InternalIdentity CertificateChain Certificate # specificinfo

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

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

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

  • Дата завершення терміну дії не пізніше

  • Дата початку терміну дії не раніше

  • Основне ім’я

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

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

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

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

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

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

Виклик API

Опис

Учасник конференціїПодіїСписок учасниківДодано

Список учасників конференції xПодіїСписок учасників оновлено

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

Тепер ці три події включають EndToEndEncryptionStatus, EndToEndEncryptionIdentity і EndToEndEncryptionCertInfo для залученого учасника.

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

Виклик API

Опис

xCommand Security ClientSecret Populate Secret: "base64url-encoded"

або

xCommand Security ClientSecret Populate Secret: JWEblob

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

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

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

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

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

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

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

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

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