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

Користувачі вибирають тип наради, коли планують нараду. Під час допуску учасників із холу а також під час наради організатор може бачити стан підтвердження посвідчень кожного учасника. Також існує код наради, який є спільним для всіх поточних учасників наради, який вони можуть використовувати, щоб переконатися, що їх нараду не перехопив небажаний сторонній Посередник В Центрі (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 видає сертифікат пристрою, коли він реєструється після запуску, і за потреби поновлює його. Для пристроїв сертифікат включає ідентифікатор облікового запису та домен.

Якщо ваша організація не має домену, CA Webex видасть сертифікат без домену.

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

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

Сертифікат пристрою, виданий за кордоном

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

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

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

Ми рекомендуємо використовувати окремий сертифікат на один пристрій і унікальну кількість номерів (CN) на один пристрій. "Наприклад, ""meeting-room-1.example.com"" для організації, яка володіє доменом ""example.com""."

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

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

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

Функції та обмеження

Пристрої

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

  • Дошка Webex

  • Webex Desk Pro

  • Стіл Webex

  • Набір Webex Room

  • Мінікомплект Webex Room Kit

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

  • Серія Webex C

  • Серія Webex DX

  • Webex серії EX

  • Серія Webex MX

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

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

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

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

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

Ідентифікаційні дані

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

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

Наради

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

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

Інтерфейс керування

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

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

  • Webex Meetings 41.7.

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

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

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

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

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

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

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

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

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

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

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

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

  • Мета: Метою сертифіката має бути ідентифікація Webex.

  • Створення ключів: Сертифікати повинні базуватися на парах ключів 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 blob на пристрій.

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

  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":"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 blobs повинен дотримуватися тієї ж процедури, щоб отримати той самий ключ шифрування/дешифрування з секрету клієнта.

Пристрої використовують 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-блоба до пристрою (іміка додавання сертифіката, з дуже коротким рядком замість повного сертифіката + ключа). Секрет клієнта в прикладі — ossifrage.

  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_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 blob.

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

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

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

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

    • Корисне навантаження: this is a PEM file

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

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

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

    Це четвертий елемент (JWE Ciphertext) в блобі JWE.

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

    Це п'ятий елемент в JWE blob.

  10. Об’єднайте п’ять елементів JWE блоба з крапками (JOSEheader..IV.Ciphertext.Tag), щоб отримати:

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

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

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

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

Типи сеансів для нарад з нульовою довірою доступні для всіх вебсайтів нарад безкоштовно. Один із цих типів сеансів називається Pro-End to End Encryption_VOIPonly. Це ім’я загальнодоступної служби, яке ми можемо змінити в майбутньому. Поточні імена типів сеансів див. в розділі Ідентифікатори типів сеансів у розділі Довідка цієї статті.

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

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

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

2

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

3

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

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

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

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

4

Якщо ви ще не маєте нового типу сеансу, зверніться до представника 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

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

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

9

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

10

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

11

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

12

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

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

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

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

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

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

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

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

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

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

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

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

Функції та обмеження

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

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

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

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

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

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

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

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

1

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

2

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

3

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

4

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

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

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

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

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

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

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

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

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

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

1

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

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

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

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

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

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

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

Зв’яжіться зі своїм сертифікатом і закритим ключем:

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

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

3

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

  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, кодованим заголовком JOSE, щоб зашифрувати текст із конкатентифікованого файлу pem.

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

  8. Побудувати JWE blob так (усі значення закодовані base64url):

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4

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

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

Переконайтеся, що сертифікат додається запуском xcommand Security Certificates Services Show

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

6

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

  1. Зчитуйте відбиток сертифіката або з самого сертифіката, або з виводу xcommand Security Certificates Services Show.

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

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

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

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

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

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

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

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

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

  9. Побудувати JWE blob так (усі значення закодовані base64url):

    JOSEHeader..InitVector.EncryptedFingerprint.AuthTag

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

                      xcommand Security Certificates Services Activate Purpose: WebexIdentity Fingerprint: "Your..JWE.encrypted.fingerprint"

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

Вбудувати пристрій у свою організацію Control Hub.

Тестування наскрізного шифрування з перевіркою посвідчень
1

Заплануйте нараду правильного типу (Webex Meetings Pro-End Encryption_VOIP).

Див. розділ Планування наради Webex із наскрізним шифруванням.

2

Приєднайтеся до наради як організатор за допомогою клієнта Webex Meetings.

Див. розділ Приєднання до наради Webex із наскрізним шифруванням.

3

Приєднайтеся до наради з пристрою, особистість якого підтверджено CA Webex.

4

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

Див. розділ Приєднання до наради Webex із наскрізним шифруванням.

5

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

6

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

7

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

8

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

9

Як організатор, прийміть або відхиліть користувачів/пристрої.

10

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

11

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

12

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

13

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

Установити область і очікування

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

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

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

Керування ідентифікаціями

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

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

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

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

Назва загальнодоступної служби

638

Тільки Шифрування E2E+VoIP

652

Тільки наскрізний Еncryption_VOIP

660

Про 3 Безкоштовний наскрізний Encryption_VOIPonly

Шифрування E2E + ідентифікаційні дані

672

Pro 3 Free50-Наскрізний Encryption_VOIPonly

673

Навчальний посібник E2E Encryption_VOIPonly

676

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

677

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

681

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

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

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

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

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

  • Зареєстровано локально та пов’язано з Webex з Webex Edge для пристроїв

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

виклик API

Опис

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

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

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

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

xStatus Conference EndToEndEncryption Availability

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

xStatus Conference EndToEndEncryption ExternalIdentity Verification

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

xStatus Conference EndToEndEncryption ExternalIdentity Identity

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

xStatus Conference EndToEndEncryption ExternalIdentity CertificateChain Certificate # specificinfo

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

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

  • Fingerprint

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

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

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

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

  • Validity Надає статус дійсності цього сертифіката (наприклад, valid або expired)

xStatus Conference EndToEndEncryption ExternalIdentity Status

Стан зовнішнього посвідчення пристрою (наприклад, valid або error).

xStatus Conference EndToEndEncryption InternalIdentity Verification

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

xStatus Conference EndToEndEncryption InternalIdentity Identity

Ідентифікаційні дані пристрою, як зазначено з загального імені сертифіката Webex.

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

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

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

xStatus Conference EndToEndEncryption InternalIdentity CertificateChain Certificate # specificinfo

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

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

  • Fingerprint

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

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

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

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

  • Validity Надає статус дійсності цього сертифіката (наприклад, valid або expired)

Таблиця 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 blob, що містить зашифровані дані 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.