Досвід користувача

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

Поділіться наведеною нижче інформацією з організаторами зустрічей:

Верифікація особи з внутрішнім або зовнішнім ЦС

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

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

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

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

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

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

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

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

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

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

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

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

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

Сертифікат на зовнішній пристрій

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

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

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

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

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

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

В даний час Webex надає команди API для управління цим.

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

Пристрої

Наступні зареєстровані в хмарі пристрої серій Webex Room і Webex Desk можуть приєднуватися до наскрізних зашифрованих зустрічей:

  • Webex Board

  • Webex Desk Pro

  • Webex Desk

  • Webex Room Kit

  • Webex Room Kit Mini

Наступні пристрої не можуть приєднатися до наскрізних зашифрованих зустрічей:

  • Webex C Series

  • телефони серії Webex DX;

  • Серії Webex EX

  • Серії Webex MX

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

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

  • Починаючи з версії 41.6, настільний клієнт Webex Meetings може приєднуватися до наскрізних зашифрованих зустрічей.

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

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

  • Сторонні програмні клієнти SIP не можуть приєднатися до наскрізних зашифрованих зустрічей.

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

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

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

Наради

  • Наскрізні зашифровані зустрічі в даний час підтримують максимум 200 учасників.

  • З цих 200 учасників до зустрічі можуть приєднатися максимум 25 зовнішньо перевірених пристроїв, і вони повинні бути першими учасниками, які приєднаються до зустрічі.

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

    Щоб пом 'якшити це обмеження, ми рекомендуємо менші зустрічі для пристроїв або розподіляти запрошення між пристроями та клієнтами зустрічей.

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

Ми настійно рекомендуємо використовувати Центр керування для керування сайтом нарад, оскільки організації Центру керування мають централізовану ідентифікацію для всієї організації, тоді як в Адміністрації сайту ідентифікація контролюється на основі кожного сайту.

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

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

Пов 'язана інформація

Передумови

  • Webex Зустрічі 41.7.

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

  • Адміністративний доступ до місця зустрічі в Control Hub, щоб увімкнути новий тип сеансу для користувачів.

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

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

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

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

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

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

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

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

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

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

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

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

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

Підготовка до роботи з бортовими пристроями

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

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

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

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

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

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

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

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

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

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

  1. Запитуйте свої сертифікати.

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Заголовок JOSE (захищений). У заголовку JSON Object Signing and Encryption ви ПОВИННІ включити наступні пари ключ-значення:

    • "alg":"dir"

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

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

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

    • "cisco-action": "add" або "cisco-action": "populate" або "cisco-action": "activate" або "cisco-action": "deactivate"

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

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

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

      Інший власницький ключ. Ми використовуємо значення, які ви вказуєте, як вхідні дані для виведення ключів на пристрої. Нараду version має бути 1(версія нашої функції похідного ключа). Цінність salt має бути закодована URL-адресою base64 послідовність не менше 4 байтів, яку потрібно вибрати випадковим чином.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • CostFactor (N) - 32768

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

  • ПаралелізаціяFactor (p) дорівнює 1

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

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

  • Максимальний об 'єм пам' яті - 64 МБ

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

Робочий приклад

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

Приклад сценарію - додавання PEM BLOB до пристрою (імітує додавання сертифіката, з дуже коротким рядком замість повного ключа cert +). Секрет клієнта в прикладі 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 байт (HEX) наступним чином: 95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac який base64url кодує в lZ66bdEiAQV4_mqdInj_rA.

  4. Виберіть випадкову послідовність з 12 байтів для використання в якості вектора ініціалізації. У цьому прикладі використовується (HEX) 34 b3 5d dd 5f 53 7b af 2d 92 95 83 який base64url кодує в NLNd3V9Te68tkpWD.

  5. Створіть заголовок JOSE з компактною серіалізацією (дотримуйтесь того ж порядку параметрів, який ми використовуємо тут), а потім base64url закодуйте його:

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

    Заголовок JOSE, закодований base64url, є eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

    Це буде перший елемент JWE 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 BLOB.

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

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

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

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

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

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

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

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

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

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

1.

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

2.

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

3.

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

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

 

Існує старий тип сеансу з дуже схожою назвою: Pro-End для закінчення шифрування. Цей тип сеансу включає незашифрований доступ PSTN до зустрічей. Переконайтеся, що у вас є _ версія VOIPonly, щоб забезпечити наскрізне шифрування. Ви можете перевірити, наводячи курсор на посилання PRO в стовпці коду сеансу; для цього прикладу ціль посилання повинна бути javascript:ShowFeature(652).

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

5.

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

Що далі

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

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

1.

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

2.

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

3.

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

4.

Поставте прапорець біля пункту Pro-End to End Encryption_VOIPonly.

5.

Закрийте панель налаштування користувача.

6.

Повторіть для інших користувачів, якщо це необхідно.

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

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

1.

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

2.

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

3.

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

4.

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

5.

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

6.

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

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

7.

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

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

8

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


 

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

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 тип сеансу, див. a Цифровий водяний знак у розділі Безпека.

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

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

  8. Виберіть зустріч у списку, щоб побачити результати аналізу. КлацнітьDownload button, щоб завантажити результати.
Функції та обмеження

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

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

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

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

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

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

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

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

1.

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

2.

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

3.

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

4.

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

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

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

Вам потрібно:

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

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

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

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

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

  • An scrypt впровадження.

  • Секретне слово або фраза для кожного пристрою.

1.

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

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

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

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

  3. Виконайте команду xcommand Security ClientSecret Populate Secret: "MDEyMzQ1Njc4OWFiY2RlZg"

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

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

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

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

    (Це текст корисного навантаження, який ви зашифруєте та вставите у свій JWE BLOB)

3.

Створіть JWE BLOB для використання в якості вхідних даних для команди додавання сертифіката:

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

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

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

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

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

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

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

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

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

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4.

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

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 ключі, як описано в розділі Розуміння процесу зовнішньої ідентифікації пристроїв. Встановіть дію «активувати» за допомогою ключа:значення "cisco-action":"activate" у заголовку JOSE (тому що ми активуємо сертифікат на пристрої).

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

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

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

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

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

    JOSEHeader..InitVector.EncryptedFingerprint.AuthTag

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

                      xcommand Security Certificates Services Activate Purpose: WebexIdentity Fingerprint: "Your..JWE.encrypted.fingerprint"
Пристрій має зашифрований, активний сертифікат CA, готовий до використання для ідентифікації його в наскрізних зашифрованих зустрічах Webex.
7.

Підключіть пристрій до організації Control Hub.

Перевірте наскрізне шифрування з підтвердженням особи

1.

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

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

2.

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

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

3.

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

4.

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

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

5.

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

6.

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

7.

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

8

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

9

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

10

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

11

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

12

Приєднуйтесь до зустрічі з новим учасником.

13

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

Встановити обсяг та очікування

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

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

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

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

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

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

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

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

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

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

Назва публічної служби

638

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

652

Pro-End до кінця Encryption_VOIPonly

660

Pro 3 Free-End до кінця Encryption_VOIPonly

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

672

Pro 3 Free50-End до кінця Encryption_VOIPonly

673

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

676

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

677

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

681

Schoology Free plus end to end шифрування

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

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

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

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

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

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

Виклик API

Опис

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

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

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

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

xStatus Conference EndToEndEncryption Availability

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

xStatus Conference EndToEndEncryption ExternalIdentity Verification

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

xStatus Conference EndToEndEncryption ExternalIdentity Identity

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

xStatus Conference EndToEndEncryption ExternalIdentity CertificateChain Certificate # specificinfo

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

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

  • Fingerprint

  • NotAfter Дата закінчення терміну дії

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

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

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

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

xStatus Conference EndToEndEncryption ExternalIdentity Status

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

xStatus Conference EndToEndEncryption InternalIdentity Verification

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

xStatus Conference EndToEndEncryption InternalIdentity Identity

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

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

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

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

xStatus Conference EndToEndEncryption InternalIdentity CertificateChain Certificate # specificinfo

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

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

  • Fingerprint

  • NotAfter Дата закінчення терміну дії

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

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

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

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

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

Виклик API

Опис

xEvent Conference ParticipantList ParticipantAdded

xEvent Conference ParticipantList ParticipantUpdated

xEvent Conference ParticipantList ParticipantDeleted

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

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

Виклик API

Опис

xCommand Security ClientSecret Populate Secret: "base64url-encoded"

або

xCommand Security ClientSecret Populate Secret: JWEblob

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

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

xCommand Security Certificates Services Add JWEblob

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

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

xCommand Security Certificates Services Activate Purpose:WebexIdentity FingerPrint: JWEblob

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

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

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