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

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

Підтвердження особи

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пристрої

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

  • Webex Board

  • Webex Desk Pro

  • Webex Desk

  • Webex Room Kit

  • Webex Room Kit Mini

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

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

  • Серія Webex DX

  • Серія Webex EX

  • Серія Webex MX

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

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

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

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

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

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

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

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

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

Meetings

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

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

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

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

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

Настійно рекомендуємо використовувати Центр керування для керування сайтом нарад.

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

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

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

Виведення проби ляпів JWE

Зразок правильно зашифрованого JWE на основі заданих параметрів (додаток)

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

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

  • Адміністративний доступ до місця наради в Центрі керування для ввімкнення нового типу сеансу для користувачів.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Як ми використовуємо формат 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 «Підписання об'єкта та шифрування» необхідно включити такі пари ключ-значення:

    • "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 повинна бути базова64 URL-кодована послідовність не менше 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" шифротекст - відбиток пальця (шістнадцяткове представлення ша-1) сертифіката, який ми активуємо для перевірки ідентифікації пристрою

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

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

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

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

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

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

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

  • CostFactor (N) – 32768

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

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

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

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

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

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

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

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

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

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

  2. Виберіть сіль (повинна бути випадкова послідовність не менше 4 байт). У цьому прикладі використовуються (шістнадцяткові байти) E5 E6 53 08 03 F8 33 F6. Base64url кодує послідовність, щоб отримати 5eZTCAP4M_Y(зняти цоколь64 підкладки).

  3. Ось зразок scrypt виклик для створення ключа шифрування вмісту (cek):

    cek=scrypt(password="ossifrage", salt=4-byte-sequence, N=32768, r=8, p=1, keylength=16)

    Похідний ключ повинен складати 16 байт (гекс) наступним чином: 95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac який base64url кодує до lZ66bdEiAQV4_mqdInj_rA.

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

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

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

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

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

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

  7. Третій елемент плями JWE - вектор ініціалізації NLNd3V9Te68tkpWD.

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

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

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

    • Шифр шифрування - 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 Security Certificates Add eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

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

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

1.

Увійдіть у Центр керування та відкрийте сторінку Наради .

2.

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

3.

Виберіть пункт Настроїти сайт.

4.

В області Загальні настройки виберіть пункт Типи сеансів.

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

 

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

У майбутньому ми можемо змінити назви державних служб для цих типів сеансів, наприклад, ми плануємо змінити Pro-End на End Encryption_VOIPonly на E2E Шифрування + Ідентичність.

5.

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

Що далі

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

1.

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

2.

В області Служби виберіть пункт ЗустрічіCisco Webex.

3.

Виберіть сайт (якщо користувач знаходиться в декількох) і натисніть Хост .

4.

Установіть прапорець поруч із записом Вебекс-наради з позначкою Pro-End to End Encryption_VOIPonly.

5.

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

6

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

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

1.

Увійдіть у Центр https://admin.webex.com керування та відкрийте сторінку наради .

2.

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

3.

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

4.

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

5.

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

6

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

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

7

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

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

8

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


 

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

9

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

10

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

11

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

12

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

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

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

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

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

1.

Увійдіть у Центр керування (https://admin.webex.com) і відкрийте сторінку Пристрої .

2.

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

3.

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

4.

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

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

Тобі потрібно:

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

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

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

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

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

  • Ан scrypt здійснення.

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

1.

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

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

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

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

  3. Бігти xcommand Security ClientSecret Populate Secret: "MDEyMzQ1Njc4OWFiY2RlZg"

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

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

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

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

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

3.

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

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

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

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

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

  4. Створення заголовка JOSE, настройка alg, enc, і cisco-kdf ключі, як описано в розділі Розуміння процесу зовнішньої ідентифікації для пристроїв. Встановіть дію "додати" за допомогою клавіші:значення "cisco-action":"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 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. Побудуйте blob JWE наступним чином (всі значення закодовані за основою64url):

    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).

2.

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

3.

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

4.

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

5.

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

6

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

7

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

8

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

9

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

10

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

11

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

12

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

13

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

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

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

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

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

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

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

Таблиця 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 наскрізне шифрування

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

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

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

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

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

Виклик API

Опис

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

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

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

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

xStatus 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 для наскрізно зашифрованих зустрічей і підтвердженої особистості

Виклик API

Опис

xCommand Security ClientSecret Populate Secret: "base64url-encoded"

або

xCommand Security ClientSecret Populate Secret: JWEblob

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

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

xCommand Security Certificates Services Add JWEblob

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

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

xCommand Security Certificates Services Activate Purpose:WebexIdentity FingerPrint: JWEblob

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

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

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