Возможности для пользователей

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

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

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

Проверка идентификации

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

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

Пользователи приложения Webex Meetings проходят аутентификацию с помощью хранилища удостоверений 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 для каждого устройства. К примеру, для организации, которая владеет доменом example.com, это может быть "meeting-room-1.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. У организаций Control Hub есть централизованные удостоверения для всей организации, а служба администрирования веб-сайта управляет удостоверениями для каждого веб-сайта в отдельности.

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

Дополнительные материалы

Связанная информация

Пример больших двоичных объектов JWE

Пример корректно зашифрованного JWE на основе заданных параметров (приложение)

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

  • Webex Meetings 41.7.

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

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

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

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

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

Этот этап можно пропустить, если внешняя проверка идентификации не требуется.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Задайте назначение зашифрованного сертификата, который будет использоваться для идентификации Webex, и активируйте сертификат.

  • (Рекомендуется) Предоставьте интерфейс к вашему инструменту (или распределите его), чтобы пользователи устройств могли изменять исходный секретный код (для защиты своих данных от вас!).

Использование формата 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 должно представлять собой базовую последовательность с кодированием 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

Щелкните имя своего веб-сайта, чтобы открыть панель конфигурации веб-сайта.
3

Щелкните Настроить веб-сайт.
4

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

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

 

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

Возможно, в будущем названия общедоступных служб для этих типов сеансов будут изменены. К примеру, планируется изменить название Pro-End to End Encryption_VOIPonly на E2E Encryption + Identity.
5

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

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

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

Включение сквозного шифрования для отдельных пользователей

1

Щелкните Пользователи и выберите пользователя, чтобы открыть панель конфигурации пользователя.
2

В области Службы выберите Cisco Webex Meetings.
3

Выберите веб-сайт (если пользователь присутствует в более чем одном) и щелкните Организатор.
4

Установите флажок напротив записи Webex Meetings с названием Pro-End to End Encryption_VOIPonly.
5

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

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

Чтобы назначить этот тип многим пользователям, воспользуйтесь возможностью пакетной обработки в CSV.

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

1

Войдите в Control Hub на https://admin.webex.com и откройте страницу Совещание.
2

Щелкните имя своего веб-сайта, чтобы открыть панель конфигурации веб-сайта.
3

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

Щелкните Экспорт и подождите, пока идет подготовка файла.
5

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

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

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

7

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

В статье О формате файлов CSV для Cisco Webex приведены сведения о назначении и содержимом файла CSV.
8

Откройте панель конфигурации веб-сайта совещания в Control Hub.


 

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

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

Щелкните Импорт и выберите отредактированный CSV, затем щелкните Импорт. Дождитесь загрузки файла.
11

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

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

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

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

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

Прежде чем начать

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

1

Войдите в Control Hub (https://admin.webex.com) и откройте страницу Устройства.
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).

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

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

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

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

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

См. статью Присоединение к совещанию Webex со сквозным шифрованием.
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 со сквозным шифрованием

Связанные команды 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 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.