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

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

Подтвердить личность

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

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

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

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

  • Внутренний ЦС. Webex выдает внутренний сертификат на основе маркера доступа учетной записи устройства. Сертификат подписывается ЦС Webex. У устройств нет идентификаторов пользователей, как у пользователей, поэтому Webex использует (один из) доменов вашей организации при записи идентификатора сертификата устройства (Common Name (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, зарегистрированные в облаке, могут присоединяться к совещаниям с непрерывным шифрованием:

  • Webex Board

  • Webex Desk Pro

  • Webex Desk

  • Webex Room Kit

  • Webex Room Kit Mini

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

  • Серия Webex C

  • Серия Webex DX

  • Серия Webex EX

  • Серия Webex MX

  • Устройства SIP сторонних поставщиков

Программные клиенты
  • Начиная с версии 41.6, клиент Webex Meetings для настольных ПК может присоединяться к совещаниям со сквозным шифрованием.

  • Если ваша организация позволяет приложение Webex присоединяться к совещаниям, запустив настольное приложение Meetings, вы можете использовать этот параметр для присоединения к совещаниям с непрерывным шифрованием.

  • Веб-клиент Webex не может присоединяться к совещаниям со сквозным шифрованием.

  • Клиенты SIP сторонних поставщиков не могут присоединяться к совещаниям со сквозным шифрованием.

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

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

Совещания
  • В совещаниях со сквозным шифрованием в настоящий момент может участвовать не более 200 пользователей.

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

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

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

Интерфейс управления

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

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

Связанная информация
  • Webex Meetings 41.7.

  • Устройства Webex Room и Webex Desk, зарегистрированные в облаке, запущены 10.6.1-RoomOS_August_2021.

  • Административный доступ к веб-сайту совещания в Control Hub для подключения нового типа сеанса для пользователей.

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

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

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

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

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

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

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

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

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

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

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

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

Вы можете пропустить этот шаг, если не хотите использовать на своих устройствах удостоверение личности, подтвержденное извне.

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

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

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

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

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

Выполнив эти шаги, разрешить видеосистемам присоединяться к совещаниям и мероприятиям на веб- веб-сайт 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 (JWS)https://datatracker.ietf.org/doc/html/rfc7515.

Мы используем Компактная сериализация документа JSON для создания больших двоичных объектов JWE. При создании BLOB-объектов 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 должно представлять собой базовую последовательность с кодированием 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 байт; необходимо предоставить ее salt при указании cisco-kdf.

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

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

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

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

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

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

  1. Выберите шифр для шифрования. В этом примере используется A128GCM(AES со 128-битными ключами в режиме счетчика Галуа). Инструмент может использовать A256GCM с учетом ваших предпочтений.

  2. Выберите соль (должна быть случайной последовательностью длиной не менее 4 байт). В этом примере используются (байты в шестнадцатеричном представлении) E5 E6 53 08 03 F8 33 F6. Закодируйте последовательность в Base64url для получения 5eZTCAP4M_Y(удалите заполнитель base64).

  3. Вот пример scrypt вызова для создания ключа шифрования контента (cek):

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

    Значение формируемого ключа должно составлять 16 байт следующим образом: 95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac которые в кодировании base64url представляют собой lZ66bdEiAQV4_mqdInj_rA.

  4. Выберите случайную последовательность из 12 байт для использования в качестве вектора инициализации. В этом примере используется (в шестнадцатеричном представлении) 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. Второй элемент двоичного объекта JWE пуст, поскольку мы не поставляем ключ шифрования JWE.

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

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

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

    • Полезная нагрузка this is a PEM file

    • Шифр – 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.

 

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

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

5

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

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

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

1.

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

2.

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

3.

В раскрывающемся списке Настройки применить выберите веб-сайт совещания, который необходимо обновить.

4.

Установите флажок рядом с От конца до конца Encryption_ VOIPonly .

5

Закройте панель конфигурации пользователя.

6

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

Чтобы назначить это многим пользователям, используйте следующую опцию, Включение совещаний E2EE для нескольких пользователей .

1.

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

2.

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

3.

В разделе Лицензии и пользователи щелкните Массовое управление.

4.

Щелкните Создать отчет и подождите, пока мы подготовим файл.

5

Когда файл будет готов, щелкните Экспорт результатов, а затем Скачать. (Вы должны вручную закрыть это всплывающее окно после того, как нажмете Скачать .)

6

Откройте скачанный файл CSV для редактирования.

Для каждого пользователя есть строка, а столбец MeetingPrivilege содержит идентификаторы типов сеанса в виде списка с разделителями-запятыми.

7.

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

В Справочник по формату файла Webex CSV содержит подробную информацию о назначении и содержании файл 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 CA для автоматического создания их идентифицирующих сертификатов, вам не нужно выполнять сброс до заводских настроек .

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

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

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

1.

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

2.

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

3.

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

4.

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

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

Вам потребуется:

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

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

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

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

  • Средство кодирования base64url для байтов или текста.

  • Одна из реализаций scrypt.

  • Секретные слова или фразы для каждого устройства.

1.

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

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

  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 как описано в статье О процедуре внешней идентификации для устройств. Задайте действие "добавить" с помощью пары ключ:значение "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":"activate" в заголовке 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 Security Certificates Services Activate Purpose: WebexIdentity Fingerprint: "Your..JWE.encrypted.fingerprint" 
                    
Устройство имеет зашифрованный активный сертификат, выданный ЦС, готовый к его идентификации в совещаниях Webex со сквозным шифрованием.
7.

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

1.

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

2.

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

3.

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

4.

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

5

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

6

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

7.

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

8

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

9

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

10

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

11

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

12

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

13

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

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

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

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

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

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

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

Таблица 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 со сквозным шифрованием

В этих таблицах описываются команды 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 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.

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.