Работа с пользователями

При планировании совещания пользователи выбирают тип совещания. При допуске участников из холла, а также во время совещания организатор может видеть состояние проверки удостоверений каждого участника. Кроме того, существует общий для всех текущих участников совещания код совещания, который можно использовать для проверки того, что совещание не было перехвачено нежелательной третьей стороной Meddler In The Middle (MITM).

Поделитесь информацией по следующим темам с организаторами совещаний.

Проверка удостоверений с помощью внутреннего или внешнего ЦС

Проверка удостоверения

Сквозное шифрование с проверкой удостоверений обеспечивает дополнительную безопасность совещания со сквозным шифрованием.

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

Пользователи приложения Webex аутентифицируются в хранилище удостоверений Webex, что выдает им маркер доступа при успешной аутентификации. Если на совещании со сквозным шифрованием им необходим сертификат, ЦС Webex выдает сертификат на основе маркера доступа. В настоящее время у пользователей Webex Meetings нет возможности получить сертификат, выданный сторонним или внешним ЦС.

Устройства могут самостоятельно проходить аутентификацию с помощью сертификата, выданного внутренним ЦС (ЦС Webex), или сертификата, выданного внешним ЦС.

  • Внутренний ЦС. Webex выдает внутренний сертификат на основе маркера доступа учетной записи компьютера устройства. Сертификат подписывается ЦС Webex. У устройств нет идентификаторов пользователей так же, как у пользователей, поэтому Webex использует (один из) доменов вашей организации при записи удостоверения сертификата устройства (общее имя (CN)).

  • Внешний ЦС: запрос и покупка сертификатов устройства непосредственно у выбранного эмитента. Для шифрования, непосредственной загрузки и авторизации сертификатов необходимо использовать секретный код, известный только вам.

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

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

Для полной защиты внешнего сертификата от несанкционированного вмешательства используется функция шифрования и подписи различных xcommand секретом клиента.

При использовании секрета клиента можно безопасно управлять внешним сертификатом удостоверений Webex с помощью xAPI. В настоящее время эта функция доступна только для сетевых устройств.

В настоящее время Webex предоставляет команды API для управления этим процессом.

Функции и ограничения

Устройства

Следующие зарегистрированные в облаке устройства серии Webex Room и Webex Desk могут присоединяться к совещаниям E2EE.

  • Webex Board

  • Webex Desk Pro

  • Webex Desk

  • Webex Room Kit

  • Webex Room Kit Mini

Следующие устройства не могут присоединиться к совещаниям 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 для управления веб-сайтом Meetings, поскольку организации Control Hub имеют централизованную идентификацию для всей организации.

Дополнительные ресурсы
Предварительные условия

  • Webex Meetings 41.7.

  • Зарегистрированные в облаке устройства серии Webex Room и Webex Desk под управлением 10.6.1-RoomOS_August_2021.

  • Административный доступ к веб-сайту совещаний в Control Hub.

  • Один или несколько проверенных доменов в организации Control Hub (если вы используете центр сертификации Webex для выдачи сертификатов устройств для проверки идентификации).

  • Чтобы участники могли присоединиться с помощью видеосистемы, необходимо включить функцию совместных комнат совещаний. Дополнительную информацию см. в статье Разрешить видеосистемам присоединяться к совещаниям и event-совещаниям на веб-сайте Webex.

Получение сертификатов устройств

Этот шаг можно пропустить, если вам не нужны внешние удостоверения личности.

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

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

  • Сертификат должен быть выдан и подписан широко известным общедоступным ЦС.

  • Уникальный: Настоятельно рекомендуется использовать уникальный сертификат для каждого устройства. Если для всех устройств используется один сертификат, вы ставите под угрозу безопасность.

  • Общее имя (CN) и альтернативное имя (имена) субъекта (SAN): Они не играют никакой роли для Webex, но должны быть значениями, которые люди могут прочитать и связать с устройством. CN будет показываться другим участникам совещания в качестве основной проверенной идентификации устройства. Если пользователи проверяют сертификат с помощью интерфейса пользователя совещания, они будут видеть одно или несколько SAN. Вы можете использовать такие имена, как name.model@example.com.

  • Формат файла. Сертификаты и ключи должны быть в формате .pem.

  • Назначение Назначением сертификата должна быть идентификация Webex.

  • Создание ключей Сертификаты должны быть основаны на парах ключей ECDSA P-256 (алгоритм цифровых подписей на основе эллиптических кривых с помощью кривой P-256).

    Это требование не распространяется на ключ подписи. Для подписания сертификата ЦС может использовать ключ RSA.

Подготовка к подключению устройств

Этот шаг можно пропустить, если вы не хотите использовать внешне проверенную идентификацию на своих устройствах.

Если вы используете новые устройства, пока не регистрируйте их в Webex. Чтобы быть безопасным, не подключайте их к сети в данный момент.

Если у вас есть существующие устройства, которые необходимо модернизировать для использования внешних удостоверений, необходимо выполнить сброс устройств до заводских настроек.

  • Сохраните существующую конфигурацию, если хотите сохранить ее.

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

  • Обеспечьте физический доступ к устройствам. Если вам необходимо иметь доступ к устройствам по сети, следует помнить о том, что секреты пересылаются открытым текстом и что это ставит под угрозу безопасность.

После выполнения этих действий разрешите видеосистемам присоединяться к совещаниям и event-совещаниям на веб-сайте Webex.

Понимание процесса внешней идентификации устройств

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

Чтобы обеспечить действительное сквозное шифрование в облаке, мы не можем участвовать в шифровании и загрузке сертификата и ключа. Если вам необходим такой уровень безопасности, вы должны:

  1. Запрос сертификатов.

  2. Генерация пар ключей для ваших сертификатов.

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

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

    Процесс и (не секретные) параметры, которые вам понадобятся, описаны ниже, а также рецепт, которым вы будете следовать в выбранных вами инструментах разработки. Кроме того, мы предоставляем некоторые тестовые данные и итоговые двоичные объекты JWE, которые, как мы предполагаем, помогут вам проверить процесс.

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

  5. Объедините сертификат и ключ в цепочку и зашифруйте их с помощью инструмента и исходного секретного кода устройства.

  6. Загрузите получившийся двоичный объект JWE на устройство.

  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.

Для создания двоичных объектов JWE используется компактная сериализация документа JSON. Параметры, которые необходимо включить при создании двоичных объектов JWE, приведены ниже.

  • Заголовок JOSE (защищен). Заголовок подписи и шифрования объекта JSON ДОЛЖЕН включать следующие пары ключ-значение:

    • "alg":"dir"

      Для шифрования полезной нагрузки поддерживается только прямой алгоритм. Необходимо использовать исходный секрет клиента устройства.

    • "enc":"A GCM" или "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" }

      Другой закрытый ключ. Мы используем значения, которые вы предоставляете в качестве входных данных для формирования ключей на устройстве. Версия должна быть 1 (версия функции генерации ключей). Значение salt должно быть последовательностью URL-кода base64 не менее 4 байт, которую вы должны выбрать случайным образом.

  • Зашифрованный ключ JWE. Это поле остается пустым. Устройство получает его из исходного кода ClientSecret.

  • Вектор инициализации JWE. Необходимо предоставить вектор инициализации с кодированием base64url для расшифровки полезной нагрузки. Вектор инициализации ДОЛЖЕН быть случайным значением длиной 12 байт (используется семейство шифров AES-GCM, которое требует, чтобы вектор инициализации имел длину 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

  • ParallelizationFactor (p) – 1

  • Соль — это случайная последовательность длиной не менее 4 байт; эту же соль необходимо указать при задании параметра cisco-kdf .

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

  • Максимальный объем памяти – 64 МБ

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

Рабочий пример

Ниже приводится пример, за которым можно проследить, чтобы убедиться, что процесс шифрования JWE работает так же, как и процесс на устройствах.

Сценарий примера добавляет к устройству двоичный объект PEM (имитирует добавление сертификата с очень короткой строкой вместо полного сертификата + ключа). Секретом клиента в примере является ossifrage.

  1. Выберите шифр для шифрования. В этом примере используется A GCM (AES с 128-битными ключами в режиме счетчика Galois). При желании инструмент может использовать A256GCM .

  2. Выберите соль (должна быть случайной последовательностью длиной не менее 4 байт). В этом примере используются (шестнадцатеричные байты)E5 E6 53 08 03 F8 33 F6. Base64url кодирует последовательность, чтобы получить 5eZTCAP4M_Y (удалите padding 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 which base64url encodes to 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":"A GCM"}

    Заголовок JOSE в кодировке base64url – eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

    Это будет первый элемент двоичного объекта JWE.

  6. Второй элемент двоичного объекта JWE пуст, поскольку мы не поставляем ключ шифрования JWE.

  7. Третьим элементом двоичного объекта JWE является вектор инициализации NLNd3V9Te68tkpWD.

  8. Используйте инструмент шифрования JWE для получения зашифрованной полезной нагрузки и тега. В этом примере незашифрованной полезной нагрузкой будет поддельный двоичный объект PEM это файл PEM

    Следует использовать такие параметры шифрования:

    • Полезная нагрузка — это файл PEM

    • Шифр – AES 128 GCM

    • Заголовок JOSE, закодированный в base64url, выступает в качестве дополнительных аутентифицированных данных (AAD)

    Base64url кодирует зашифрованную полезную нагрузку, которая должна привести к f5lLVuWNfKfmzYCo1YJfODhQ

    Это четвертый элемент (JWE Ciphertext) в двоичном объекте BWE.

  9. Base64url кодирует тег, созданный на шаге 8, что должно привести к PE-wDFWGXFFBeo928cfZ1Q

    Это пятый элемент в двоичном объекте JWE.

  10. Объедините пять элементов бинарного объекта JWE в цепочку с помощью точек (JOSEheader. IV.Ciphertext.Tag), чтобы получить:

    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. Это название государственной службы, которое мы можем изменить в будущем. Текущие названия типов сеансов см. в секции Типы сеансов в разделе Справочные материалы этой статьи.

Чтобы получить эту возможность для вашего веб-сайта, необходимо предоставить пользователям новый тип сеанса (также называемый привилегией совещания). Сделать это можно для каждого отдельного пользователя на странице его настроек или массово посредством экспорта и импорта в формате CSV.

Проверьте новый тип сеанса
1

Войдите в Control Hub и перейдите к меню Службы > Совещание.

2

Щелкните Веб-сайты, выберите веб-сайт Webex, для которого необходимо изменить настройки, и щелкните Настройки.

3

В разделе Общие настройки выберите Типы сеансов.

4
Вы должны видеть один или несколько типов сеансов сквозного шифрования. Обратитесь к списку Идентификаторы типа сеанса в разделе Справочные материалы этой статьи. К примеру, может отображаться название Pro-End to End Encryption_VOIPonly.

Существует более старый тип сеанса с очень похожим названием: Сквозное шифрование. Этот тип сеанса включает незашифрованный PSTN-доступ к совещаниям. Убедитесь, что у вас есть версия _VOIPonly для обеспечения сквозного шифрования. Вы можете проверить, наведя курсор мыши на ссылку PRO в столбце кода сеанса; в этом примере целью ссылки должен быть javascript:ShowFeature(652).

В будущем мы можем изменить названия общедоступных служб для этих типов сеансов.

5

Если у вас еще нет новых типов сеанса, обратитесь к представителю Webex.

Дальнейшие действия

Включите этот тип сеанса/права для совещания для некоторых или всех пользователей.

Включение совещаний E2EE для отдельных пользователей
1

Войдите в Control Hub и перейдите в раздел Управление > Пользователи.

2

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

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 .

Справочная информация о формате файла 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 , видят параметр Digital Watermarking в разделе "Безопасность".

Загрузка и анализ совещания с водяными метками

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

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

  8. Выберите совещание в списке, чтобы просмотреть результаты анализа. ЩелкнитеКнопка "Скачать" , чтобы скачать результаты.

Функции и ограничения

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

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

Для успешного анализа записи необходима разумная запись аудио совещания. Если аудио совещания записывается на том же компьютере, на котором размещен клиент, ограничения не должны применяться.

Подключенные устройства (внутренний ЦС)

Если ваши устройства уже подключены к вашей организации Control Hub и вы хотите использовать ЦС Webex для автоматической генерации сертификатов идентификации, сброс устройств к заводским настройкам не требуется.

В этой процедуре выбирается домен, который устройство использует для идентификации себя. Она требуется только в том случае, если в вашей организации Control Hub имеется несколько доменов. Если у вас несколько доменов, рекомендуется сделать это для всех устройств с идентификацией, проверенной Cisco. Если вы не сообщите Webex, какой домен идентифицирует устройство, выбранный домен будет автоматически выбран и другим участникам совещания может показаться неправильным.

Перед началом работы

Если устройства еще не подключены, выполните регистрацию устройства в Cisco Webex с помощью API или локального веб-интерфейса или подключения в облаке для серий Board, Desk и Room. Также необходимо проверить домены, которые необходимо использовать для идентификации устройств в разделе Управление доменами.

1

Войдите в Control Hub и в разделе Управление выберите Устройства.

2

Выберите устройство, чтобы открыть его панель конфигурации.

3

Выберите домен, который необходимо использовать для идентификации этого устройства.

4

Повторите эту процедуру для других устройств.

Подключенные устройства (внешний ЦС)

Перед началом работы

  • Получите сертификат и закрытый ключ, подписанный ЦС, в формате .pem для каждого устройства.

  • На вкладке Подготовка прочтите тему Понимание процесса внешней идентификации устройств.

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

  • Убедитесь, что у вас есть инструмент для создания случайных последовательностей байтов заданной длины.

  • Убедитесь, что у вас есть инструмент для кодирования байтов или текста base64url.

  • Убедитесь, что у вас есть реализация scrypt .

  • Убедитесь, что у вас есть секретное слово или фраза для каждого устройства.

1

Заполните ClientSecret устройства секретом обычного текста:

При первом заполнении секрета вы предоставляете его простым текстом. Поэтому мы рекомендуем делать это на физической консоли устройства.

  1. Закодируйте секретную фразу для этого устройства с помощью Base64url.

  2. Откройте TShell на устройстве.

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

    Приведенная выше команда в примере заполняет Secret фразой 0123456789abcdef. Необходимо выбрать собственную фразу.

Устройство обладает исходным секретом. Не забудьте об этом. Вы не можете восстановить его, и для повторного запуска устройства необходимо выполнить сброс до заводских настроек.
2

Объедините сертификат и закрытый ключ в цепочку:

  1. С помощью текстового редактора откройте файлы .pem, скопируйте и вставьте туда двоичный объект ключа, двоичный объект сертификата и сохраните его как новый файл .pem.

    Это текст полезной нагрузки, который будет зашифрован и помещен в двоичный объект JWE.

3

Создайте двоичный объект JWE для использования в качестве вводных данных команды добавления сертификата:

  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. Закодируйте заглавный код JOSE в Base64url.

  6. Используйте средство шифрования JWE с выбранным шифром и заголовок JOSE в кодировке base64url для шифрования текста из соединенного файла PEM.

  7. Закодируйте в Base64url вектор инициализации, зашифрованную полезную нагрузку PEM и тег аутентификации.

  8. Создайте двоичный объект JWE следующим образом (все значения кодируются как 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 , как описано в разделе Понимание процесса внешней идентификации для устройств. Установите действие "активировать", используя ключ:значение "cisco-action":"активировать" в заголовке JOSE (поскольку на устройстве активируется сертификат).

  6. Закодируйте заглавный код JOSE в Base64url.

  7. Для шифрования идентификационной метки сертификата используйте средство шифрования JWE с выбранным шифром и кодируемым в base64url заголовком JOSE.

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

  8. Зашифрованная в Base64urlencode идентификационная метка и тег аутентификации.

  9. Создайте двоичный объект JWE следующим образом (все значения кодируются как base64url):

    JOSEHeader..InitVector.EncryptedFingerprint.AuthTag

  10. Откройте TShell на устройстве и запустите следующую команду активации:

     Цель активации служб сертификатов безопасности xcommand: Отпечаток пальца WebexIdentity: "Ваш..JWE.encrypted.fingerprint"

Устройство имеет зашифрованный активный сертификат, выданный ЦС, готовый к его идентификации в совещаниях Webex со сквозным шифрованием.
7

Подключите устройство к вашей организации в Control Hub.

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

Запланируйте совещание необходимого типа (Webex Meetings Pro-End to End Encryption_VOIPonly).

См. статью Планирование совещания Webex со сквозным шифрованием.

2

Присоединитесь к совещанию в качестве организатора из клиента Webex Meetings.

См. статью Присоединение к совещанию Webex со сквозным шифрованием.

3

Присоединитесь к совещанию с устройства, идентификация которого проверена ЦС Webex.

4

Будучи организатором, убедитесь, что это устройство отображается в холле с необходимой пиктограммой идентификации.

См. статью Присоединение к совещанию Webex со сквозным шифрованием.

5

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

6

Будучи организатором, убедитесь, что это устройство отображается в холле с необходимой пиктограммой идентификации. Узнайте больше о значках удостоверений.

7

Присоединитесь к совещанию в качестве участника, не прошедшего аутентификацию.

8

Будучи организатором, убедитесь, что этот участник появится в холле с необходимой пиктограммой идентификации.

9

Будучи организатором, попробуйте допустить пользователей или устройства на совещание или отклонить их.

10

По возможности проверяйте удостоверения участников/устройств, проверяя сертификаты.

11

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

12

Присоединитесь к совещанию с новым участником.

13

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

Настройка области действия и ожиданий

  • Вы собираетесь сделать совещания со сквозным шифрованием вариантом по умолчанию, включить их только для некоторых пользователей или дать всем организаторам возможность принять решение самостоятельно? После того как вы решили использовать эту функцию, подготовьте пользователей, которые будут ее использовать. Обратите особое внимание на ограничения и то, чего можно ожидать на совещании.

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

  • Если у вас разные уровни проверки удостоверений, предоставьте пользователям возможность проверять друг друга с помощью удостоверений, подкрепленных сертификатами. Несмотря на то, что в определенных обстоятельствах участники могут выглядеть как непроверенные и участники должны знать, как это проверить, непроверенные люди могут оказаться не самозванцами.

Управление удостоверениями

Если для выдачи сертификатов устройства используется внешний ЦС, контроль, обновление и повторное применение сертификатов находится в зоне вашей ответственности.

Если вы создали исходный секрет, помните, что пользователи могут захотеть изменить секрет своего устройства. Для этого может потребоваться создать интерфейс или распределить инструмент.

Идентификаторы типов сеанса
Таблица 1. Коды типов сеансов для совещаний со сквозным шифрованием

Идентификатор типа сеанса

Название общедоступной службы

638

E2E Encryption+VoIP only

652

Pro-End to End Encryption_VOIPonly

660

Pro 3 Free-End to End Encryption_VOIPonly

E2E Encryption + Identity

672

Pro 3 Free50-End to End Encryption_VOIPonly

673

Education Instructor E2E Encryption_VOIPonly

676

Broadworks Standard со сквозным шифрованием

677

Broadworks Premium со сквозным шифрованием

681

Schoology Free со сквозным шифрованием

Связанные команды xAPI

В этих таблицах описываются команды API для устройств Webex, добавленные для совещаний со сквозным шифрованием и проверкой идентификации. Дополнительную информацию об использовании API см. в статье Доступ к API для Webex Room, настольных устройств и Webex Board.

Эти команды xAPI доступны только на устройствах, которые:

  • зарегистрированы в Webex;

  • зарегистрированы локально и связаны с Webex с помощью Webex Edge для устройств.

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

Вызов API

Описание

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

Эта конфигурация используется, если администратор задает предпочтительный домен устройства в Control Hub. Требуется только в том случае, если у организации несколько доменов.

Устройство использует этот домен при запросе сертификата от ЦС Webex. Затем домен идентифицирует устройство.

Эта конфигурация неприменима, если устройство имеет активный внешний сертификат для самоидентификации.

Доступность конечного шифрования конференции xStatus

Указывает, может ли устройство присоединиться к совещанию со сквозным шифрованием. API в облаке вызывает его, чтобы сопряженное приложение определило, может ли оно использовать устройство для присоединения.

xStatus Conference EndToEndEncryption ExternalIdentity

Указывает, использует ли устройство внешнюю проверку (имеет внешний сертификат).

xStatus Conference EndToEndEncryption ExternalIdentity Identity

Идентификация устройства, как указано в общем имени внешнего сертификата.

xStatus Conference EndToEndEncryption ExternalIdentity CertificateChain Certificate # спецификация

Считывает конкретные сведения из сертификата, выданного внешней организацией.

В показанной команде замените # номером сертификата. Замените конкретную информацию одним из следующих элементов:

  • Отпечаток пальца

  • Дата окончания срока действия NotAfter

  • Дата начала действия NotBefore

  • PrimaryName

  • Алгоритм PublicKey

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

  • SignatureAlgorithm

  • Тема # Имя Список субъектов для сертификата (например, адрес электронной почты или имя домена)

  • Действительность Указывает статус действительности этого сертификата (например, действительный или истек срок действия)

Состояние внешнего удостоверения конференции xStatus EndToEndEncryption

состояние внешнего удостоверения устройства (например, valid или error).

xStatus Conference EndToEndEncryption InternalIdentity

Указывает, имеет ли устройство действительный сертификат, выданный ЦС Webex.

xStatus Conference EndToEndEncryption InternalIdentity Identity

Удостоверение устройства, как указано в общем имени сертификата, выданного Webex.

Содержит имя домена, если у организации есть домен.

Это поле пусто, если у организации нет домена.

Если устройство находится в организации с несколькими доменами, это значение из PreferredDomain.

xStatus Conference EndToEndEncryption InternalIdentity CertificateChain Certificate # спецификация

Считывает конкретные сведения из сертификата, выданного Webex.

В показанной команде замените # номером сертификата. Замените конкретную информацию одним из следующих элементов:

  • Отпечаток пальца

  • Дата окончания срока действия NotAfter

  • Дата начала действия NotBefore

  • PrimaryName

  • Алгоритм PublicKey

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

  • SignatureAlgorithm

  • Тема # Имя Список субъектов для сертификата (например, адрес электронной почты или имя домена)

  • Действительность Указывает статус действительности этого сертификата (например, действительный или истек срок действия)

Таблица 3. API вызовов для совещаний со сквозным шифрованием и проверкой идентификации

Вызов API

Описание

xEvent Conference ParticipantList ParticipantAdded

xEvent Conference ParticipantListParticipantUpdated

xEvent Conference ParticipantList ParticipantDeleted

Эти три события теперь включают EndToEndEncryptionStatus, EndToEndEncryptionIdentity и EndToEndEncryptionCertInfo для затронутого участника.

Таблица 4. API, связанные с секретом клиента, для совещаний со сквозным шифрованием и проверкой идентификации

Вызов API

Описание

xCommand Security ClientSecret Populate Secret: "base64url-encoded"

или

xCommand Security ClientSecret Заполнить секретный код: JWEblob

Принимает значение закодированного в base64url открытого текста, чтобы в первый раз задать секрет клиента на устройстве.

Чтобы обновить секрет после первого раза, необходимо предоставить двоичный объект JWE, содержащий новый секрет, зашифрованный с помощью старого.

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

Добавляет сертификат (с закрытым ключом).

Эта команда была расширена и теперь принимает двоичный объект JWE, содержащий зашифрованные данные PEM.

xCommand Security Certificates Services Activate Purpose:WebexIdentity FingerPrint: JWEblob

Активирует определенный сертификат для объекта WebexIdentity. Для этой Цели, команда требует шифрования идентификационного отпечатка пальца и сериализации в двоичном файле JWE.

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

Деактивирует определенный сертификат для объекта WebexIdentity. Для этой Цели, команда требует шифрования идентификационного отпечатка пальца и сериализации в двоичном файле JWE.