Потребителско изживяване

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

Споделете следната информация с вашите домакини на събрания:

Проверка на самоличността с вътрешен или външен CA

Потвърдете самоличността

Шифроването от край до край с проверка на самоличността осигурява допълнителна сигурност на криптирана среща от край до край.

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

Потребителите на Webex App се удостоверяват в магазина за самоличност на Webex , който им издава токен за достъп, когато удостоверяването е успешно. Ако им е необходим сертификат, за да потвърдят самоличността си в криптирана среща от край до край, Webex CA им издава сертификат въз основа на техния токен за достъп. Понастоящем не предоставяме начин на потребителите на Webex Meetings да получат сертификат, издаден от трета страна/външен CA.

Устройствата могат да се удостоверяват с помощта на сертификат, издаден от вътрешния (Webex) CA, или сертификат, издаден от външен CA:

  • Вътрешен CA— Webex издава вътрешен сертификат въз основа на токена за достъп на машинния акаунт на устройството. Сертификатът е подписан от Webex CA. Устройствата нямат потребителски идентификатори по същия начин като потребителите, така че Webex използва (един от) домейните на вашата организация, когато пише самоличността на сертификата на устройството (Общо име (CN)).

  • Външен CA—Искайте и закупете сертификати за устройство директно от избрания от вас издател. Трябва да шифровате, директно да качвате и упълномощавате сертификатите, като използвате тайна, известна само на вас.

    Cisco не участва, което прави това начин за гарантиране на истинско криптиране от край до край и проверена самоличност и предотвратяване на теоретичната възможност Cisco да подслушва вашата среща/декриптиране на вашата медия.

Вътрешно издаден сертификат на устройството

Webex издава сертификат на устройството, когато се регистрира след стартиране, и го подновява, когато е необходимо. За устройства сертификатът включва ИД на акаунта и домейн.

Ако вашата организация няма домейн, Webex CA издава сертификата без домейн.

Ако вашата организация има няколко домейна, можете да използвате Контролния център, за да кажете на 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“.

За да се защити напълно външният сертификат от подправяне, за криптиране и подписване на различни xcommands се използва клиент-тайна функция.

Когато използвате тайната на клиента, е възможно сигурно да управлявате външния сертификат за самоличност на Webex чрез xAPI. В момента това е ограничено до онлайн устройства.

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

Характеристики и ограничения

Устройства

Следните регистрирани в облак серии Webex Room и устройства от серията Webex Desk могат да се присъединят към E2EE срещи:

  • Табло на Webex

  • Webex Desk Pro

  • Webex Desk

  • Комплект стая Webex

  • Webex стая комплект мини

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

Допълнителни ресурси
Предпоставки

  • Уебекс Срещи 41.7.

  • Регистрирани в облак устройства от серията Webex Room и Webex Desk, работещи 10.6.1-RoomOS_ Аugust_ 2021 г .

  • Административен достъп до място за срещи в Control Hub.

  • Един или повече потвърдени домейни във вашата организация на контролния център (ако използвате Webex CA за издаване на сертификати за устройства за потвърдена самоличност).

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

Вземете сертификати за устройство

Можете да пропуснете тази стъпка, ако не се нуждаете от външно потвърдени самоличности.

За най-високо ниво на сигурност и за проверка на самоличността, всяко устройство трябва да има уникален сертификат, издаден от доверен публичен орган за сертификати (CA).

Трябва да взаимодействате с ТЗ, за да поискате, закупите и получите цифровите сертификати и да създадете свързаните частни ключове. Когато поискате сертификат, използвайте следните параметри:

  • Сертификатът трябва да бъде издаден и подписан от добре познат обществен ТЗ.

  • Уникален: Силно препоръчваме да използвате уникален сертификат за всяко устройство. Ако използвате един сертификат за всички устройства, вие компрометирате защитата си.

  • Общо име (CN) и Тема Алтернативно име/и (SAN/s): Това не са важни за Webex, но трябва да бъдат ценности, които хората могат да четат и свързват с устройството. CN ще покаже на други участници в събранието като основна проверена самоличност на устройството и ако потребителите инспектират сертификата чрез ПИ на събранието, ще видят SAN/s. Може да искате да използвате имена като ime.model@example.com .

  • Файлов формат: Сертификатите и клавишите трябва да са във формат .pem.

  • Цел: Целта на сертификата трябва да бъде Webex Identity.

  • Генериране на ключове: Сертификатите трябва да се основават на ключови двойки ECDSA P-256 (Елиптичен крива цифров подпис алгоритъм с помощта на кривата P-256).

    Това изискване не се простира до ключа за подписване. CA може да използва RSA ключ за подписване на сертификата.

Подгответе се за бордови устройства

Можете да пропуснете тази стъпка, ако не искате да използвате външно потвърдена самоличност с вашите устройства.

Ако използвате нови устройства, все още не ги регистрирайте в Webex. За да сте в безопасност, не ги свързвайте към мрежата в този момент.

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

  • Запазете съществуващата конфигурация, ако искате да я запазите.

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

  • Осигурете физически достъп до устройствата. Ако трябва да имате достъп до устройства по мрежата, бъдете наясно, че тайните пътуват с обикновен текст и компрометирате сигурността си.

След като завършите тези стъпки, позволявайте на видеосистемите да се присъединяват към срещи и събития на вашия сайт на Webex .

Разберете процеса на външна идентичност за устройства

За да сте сигурни, че носителят на устройството ви не може да бъде шифрован от никого с изключение на устройството, трябва да шифровате частния ключ на устройството. Ние проектирахме API за устройството, за да позволим управлението на криптирания ключ и сертификат, използвайки JSON интернет Encryption (JWE).

За да осигурим истинско криптиране от край до край чрез нашия облак, не можем да участваме в криптирането и качването на сертификата и ключа. Ако имате нужда от това ниво на сигурност, трябва:

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

  2. Генерирайте ключовите двойки на сертификатите си.

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

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

    Процесът и (несекретните) параметри, от които ще се нуждаете, са обяснени по-долу, както и рецепта, която да следвате в избраните от вас инструменти за разработка. Също така предоставяме някои тестови данни и получените JWE blobs, както ги очакваме, за да ви помогнем да потвърдите процеса си.

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

  5. Свържете и шифровайте сертификата и ключа с помощта на вашия инструмент и първоначалната тайна на устройството.

  6. Качете получения JWE blob на устройството.

  7. Задайте целта на шифрования сертификат да се използва за webex самоличност и активирайте сертификата.

  8. (Препоръчително) Осигурете интерфейс за (или разпространете) вашия инструмент, за да позволите на потребителите на устройства да променят първоначалната тайна и да защитят своите медии от вас.

Как използваме jWE формата

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

Отнесете се към JSON интернет криптиране (JWE) https://datatracker.ietf.org/doc/html/rfc7516 и JSON интернет подпис (JWS) https://datatracker.ietf.org/doc/html/rfc7515 .

Ние използваме Компактна сериализация на JSON документ за създаване на JWE блобове. Параметрите, които трябва да включите при създаването на JWE blobs са:

  • JOSE Заглавка (защитен). В заглавката на json обект подписване и шифроване трябва да включва следните двойки ключ-стойност:

    • "alg": "dir"

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

    • "enc": "A128GCM" или "enc": "A256GCM"

      Поддържаме тези два алгоритъма за криптиране.

    • "cisco-action": "добавяне" или "cisco-action": "попълване" или "cisco-action": "активиране" или "cisco-action": "деактивиране"

      Това е патентован ключ и четири стойности, които може да вземе. Въведохме този ключ, за да сигнализираме за целта на шифрованите данни към целевото устройство. Стойностите са кръстени на командите xAPI на устройството, където използвате шифрованите данни.

      Нарекохме го cisco-действие за смекчаване на потенциални сблъсъци с бъдещи разширения на JWE.

    • "cisco-kdf": { "версия": "1", "salt": "base64URLEncodedRandom4+Bytes" }

      Още един патентован ключ. Използваме стойностите, които предоставяте като входове за дериват на ключове на устройството. В версия трябва да бъде 1 (версията на нашата функция за извличане на ключ). Стойността на сол трябва да бъде base64 URL-кодирана последователност от поне 4 байта, която вие трябва изберете произволно.

  • JWE криптиран ключ . Това поле е празно. Устройството го извлича от първоначалното ClientSecret .

  • Вектор за инициализация на JWE . Трябва да снабдите base64url кодиран вектор за инициализация за дешифриране на полезния товар. IV ТРЯБВА да бъде случайна стойност от 12 байта (използваме шифрованото семейство AES-GCM, което изисква IV да бъде с дължина 12 байта).

  • JWE AAD (допълнителни удостоверени данни). Трябва да пропускате това поле, защото то не се поддържа в компактната сериализация.

  • Шифрен текст на JWE : Това е криптираният полезен товар, който искате да пазите в тайна.

    Полезният товар МОЖЕ да е празен. Например, за да нулирате тайната на клиента, трябва да я презапишете с празна стойност.

    Има различни видове полезни товари, в зависимост от това, което се опитвате да направите на устройството. Различните xAPI команди очакват различни полезни товари и трябва да посочите целта на полезния товар с cisco-действие ключ, както следва:

    • С "cisco-action": "попълване" шифротекстът е новият ClientSecret .

    • с " "cisco-action":"добави" шифротекстът е PEM blob, носещ сертификата и неговия частен ключ (свързан).

    • с " "cisco-action": "активиране" шифротекстът е пръстовият отпечатък (шестнадесетично представяне на sha-1) на сертификата, който активираме за проверка на самоличността на устройството.

    • с " "cisco-action": "деактивиране" шифротекстът е пръстовият отпечатък (шестнадесетично представяне на sha-1) на сертификата, който деактивираме, за да не се използва за проверка на самоличността на устройството.

  • Маркер за удостоверяване на JWE: Това поле съдържа маркера за удостоверяване, за да се установи целостта на целия JWE компактно сериализиран блоб

Как извличаме ключ за шифроване от ClientSecret

След първото население на тайната, ние не приемаме и не излизаме тайната като обикновен текст. Това е за предотвратяване на потенциални речникови атаки от някой, който би могъл да получи достъп до устройството.

Софтуерът на устройството използва клиентската тайна като вход към функция за дериват на ключ (kdf) и след това използва производния ключ за декриптация/криптиране на съдържание на устройството.

Какво означава това за вас е, че вашият инструмент за производство на JWE blobs трябва да следва същата процедура, за да извлечете същия ключ за криптиране/декрипция от клиентската тайна.

Устройствата използват scrypt за дериват на ключове (виж https://en.wikipedia.org/wiki/Scrypt), със следните параметри:

  • РазходФактор (N) е 32768

  • БлокSizeFactor (r) е 8

  • ПаралелизацияФактор (р) е 1

  • Salt е произволна последователност от най-малко 4 байта; трябва да предоставите същото сол при уточняване на cisco-kdf параметър.

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

  • Максимална капачка на паметта е 64MB

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

Отработен пример

Ето един пример, който можете да следвате, за да проверите дали вашият процес на криптиране на JWE работи по същия начин като процеса, който създадохме на устройствата.

Примерният сценарий е добавяне на PEM blob към устройството (имитира добавяне на сертификат, с много кратък низ вместо пълен cert + ключ). Тайната на клиента в примера е осифража .

  1. Изберете шифър за шифроване. Този пример използва A128GCM (AES със 128-битови ключове в режим Galois Counter). Вашият инструмент може да се възползва A256GCM ако предпочитате.

  2. Изберете сол (трябва да бъде случайна последователност от най-малко 4 байта). Този пример използва (шестнадесетични байтове) E5 E6 53 08 03 F8 33 F6 . Base64url кодира последователността за получаване 5eZTCAP4M_ Й (премахнете подложката 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_mqd азnj_r А .

  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, е eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZWTEy9

    Това ще бъде първият елемент на JWE петното.

  6. Вторият елемент на JWE blob е празен, защото не доставяме ключ за jWE криптиране.

  7. Третият елемент на JWE blob е векторът за инициализация NLNd3V9Te68tkpWD .

  8. Използвайте инструмента си за криптиране на JWE, за да произвеждате криптиран полезен товар и маркер. За този пример некриптираният полезен товар ще бъде фалшивото PEM петно това е PEM файл

    Параметрите за шифроване, които трябва да използвате, са:

    • Полезният товар е това е PEM файл

    • Шифър за криптиране е AES 128 GCM

    • Base64url кодирани JOSE заглавка като допълнителни удостоверени данни (AAD)

    Base64url кодира криптирания полезен товар, което трябва да доведе до f5lLVuWNfKfmzYCo1YJfODhQ

    Това е четвъртият елемент (JWE Ciphertext) в петното на JWE.

  9. Base64url кодира маркера, който сте създали в стъпка 8, което трябва да доведе до PE-wDFWGXFFBeo928cfZ1Q

    Това е петият елемент в блоб jWE.

  10. Сглобете петте елемента на блоб JWE с точки (JOSEheader.. IV.Шифъртекст.Таг), за да получите:

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

  11. Ако сте иззели същите base64url кодирани стойности, както показваме тук, използвайки собствените си инструменти, сте готови да ги използвате, за да осигурите E2E криптирането и потвърдената самоличност на вашите устройства.

  12. Този пример всъщност няма да работи, но по принцип следващата ви стъпка би била да използвате JWE blob, който създадохте по-горе като вход към xcommand на устройството, което добавя сертификата:

    xCommand сертификати за сигурност Добавяне eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

Типовете сесии за срещи с нулево доверие са достъпни за всички сайтове за срещи без допълнителни разходи. Един от тези типове сесии се нарича Pro-End to End Encryption_ Само за VOIP . Това е Име на обществена услуга , което може да променим в бъдеще. За текущите имена на типовете сесии вижте ИД на тип сесия в секцията Препратка на тази статия.

Няма какво да правите, за да получите тази възможност за вашия сайт; трябва да предоставите новия тип сесия (наричан още Привилегия за срещи ) на потребителите. Можете да направите това поотделно чрез конфигурационната страница на потребителя, или групово с CSV експортиране/импортиране.

Проверете новия тип сесия
1

Влезте в Control Hub и отидете на Услуги > Среща.

2

Щракнете върху Сайтове, изберете сайт на Webex, за който искате да промените настройките, и след това щракнете върху Настройки .

3

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

4
Трябва да видите един или повече сесии за криптиране от край до край. Вижте списъка с Идентификатори на тип сесия в секцията препратка на тази статия. Например можете да видите Pro-End до край Encryption_VOIPonly.

Има по-стар тип сесия с много подобно име: Професионално шифроване от край до край . Този тип сесия включва нешифрован PSTN достъп до събрания. Уверете се, че имате_ Само за VOIP версия за осигуряване на криптиране от край до край. Можете да проверите, като задържите курсора на мишката върху ПРОФ връзка в колоната с код на сесията; за този пример целта на връзката трябва да бъде javascript:ShowFeature(652) .

Може да променим имената на обществените услуги за тези типове сесии в бъдеще.

5

Ако още не разполагате с новия тип сесия, свържете се с вашия представител на Webex.

Какво да направите след това

Активирайте този тип сесия / привилегия за събрание на някои или всички ваши потребители.

Активирайте E2EE срещи за отделни потребители
1

Влезте в Контролен център , и отидете на Управление > Потребители .

2

Изберете потребителски акаунт за актуализиране, след което изберете Срещи .

3

От Настройките се отнасят за падащо меню, изберете място за срещи да актуализирате.

4

Поставете отметка в квадратчето до Pro-End to End Encryption_ Само за VOIP .

5

Затворете потребителския конфигурационен панел.

6

Повторете за други потребители, ако е необходимо.

За да зададете това на много потребители, използвайте следващата опция, Активирайте E2EE срещи за множество потребители .

Активирайте E2EE срещи за множество потребители
1

Влезте в Control Hub и отидете на Услуги > Среща.

2

Щракнете върху сайтове , изберете сайт на Webex , за който искате да промените настройките.

3

В секцията Лицензи и потребители изберете Групово управление.

4

Щракнете върху Генериране на отчет , и изчакайте, докато подготвим файла.

5

Когато файлът е готов, щракнете върху Експортиране на резултати и след това Изтеглете . (Трябва да затворите ръчно този изскачащ прозорец, след като щракнете Изтеглете .)

6

Отворете изтегления CSV файл за редактиране.

Има ред за всеки потребител и MeetingPrivilege колона съдържа техните идентификатори на тип сесия като списък, разделен със запетая.

7

За всеки потребител, на когото искате да предоставите нов тип сесия, добавете 1561 г като нова стойност в списъка, разделен със запетая в MeetingPrivilege клетка.

В Референтен формат за CSV файл на Webex съдържа подробности за целта и съдържанието на CSV файл.

8

Отворете конфигурационния панел на сайта за събрания в контролния център.

Ако вече сте били на страницата със списък със сайтове за събрания, може да се наложи да я обновите.

9

В секцията Лицензи и потребители изберете Групово управление.

10

Щракнете върху Импортиране и изберете редактирания CSV, след което щракнете върху Импортиране. Изчакайте, докато файлът е качен.

11

Когато импортирането приключи, можете да щракнете върху Импортиране на резултати, за да прегледате, ако е имало някакви грешки.

12

Отидете на страницата Потребители и отворете един от потребителите, за да проверите, че имат новия тип сесия.

Добавяне на аудио воден знак за сигурност

Можете да добавите воден знак към записите на срещи с Webex Meetings Pro-End to End Encryption_ Само за VOIP тип сесия, който ви позволява да идентифицирате клиента или устройство източник на неоторизирани записи на поверителни срещи.

Когато тази функция е активирана, аудиото на срещата включва уникален идентификатор за всеки участващ клиент или устройство. Можете да качвате аудиозаписи в Control Hub, който след това анализира записа и търси уникалните идентификатори. Можете да разгледате резултатите, за да видите кой източник или устройство е записало срещата.

  • За да бъде анализиран, записът трябва да бъде AAC, MP3, M4A, WAV, MP4, AVI или MOV файл не по-голям от 500MB.
  • Записът трябва да е по-дълъг от 100 секунди.
  • Можете да анализирате записи само за срещи, организирани от хора във вашата организация.
  • Информацията за воден знак се запазва за същото време като информацията за срещите на организацията.

Добавете аудио водни знаци към E2EE срещи

  1. Влезте в Контролен център , след това под Управление , изберете Настройки на организацията .
  2. В Среща водни знаци раздел, включете Добавете аудио воден знак .

    Известно време след като това е включено, потребителите планират срещи с Webex Meetings Pro-End to End Encryption_ Само за VOIP тип сесия виж a Цифров воден знак опция в раздела Сигурност.

Качете и анализирайте среща с воден знак

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

    Когато анализът приключи, той ще бъде показан в списъка с резултати на Анализирайте воден знак страница.

  8. Изберете срещата в списъка, за да видите резултатите от анализа. Щракнете върхуБутон за изтегляне за да изтеглите резултатите.

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

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

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

За да се анализира успешно запис, е необходимо разумно заснемане на аудиото от срещата. Ако аудиото от срещата е записано на същия компютър, който е хост на клиента, ограниченията не трябва да се прилагат.

Вградени устройства (вътрешен CA)

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

Тази процедура избира кой домейн използва устройството, за да се идентифицира, и се изисква само ако имате няколко домейна във вашата организация на контролния център. Ако имате повече от един домейн, препоръчваме ви да направите това за всички ваши устройства, които ще имат "Cisco-проверени" самоличност. Ако не кажете на Webex кой домейн идентифицира устройството, едното се избира автоматично и може да изглежда неправилно за другите участници в срещата.

Преди да започнете

Ако вашите устройства все още не са включени, следвайте Регистрирайте устройство в Cisco Webex с помощта на API или локален интернет интерфейс или Включване в облак за сериите Board, Desk и Room . Трябва също да потвърдите домейна/ите, които искате да използвате, за да идентифицирате устройствата Управлявайте вашите домейни .

1

Влезте в Контролен център , и под Управление , изберете Устройства .

2

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

3

Изберете домейна, който искате да използвате, за да идентифицирате това устройство.

4

Повторете за други устройства.

Вградени устройства (външен CA)

Преди да започнете

  • Вземете подписан от CA сертификат и частен ключ .pem формат за всяко устройство.

  • Под Подгответе се раздел, прочетете темата Разбиране на процеса на външна идентичност за устройства ,

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

  • Уверете се, че имате инструмент за генериране на произволни последователности от байтове с дадена дължина.

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

  • Уверете се, че имате a scrypt изпълнение.

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

1

Попълнете данните на устройството ClientSecret с тайна в обикновен текст:

Първият път, когато попълните тайна , вие го предоставяте в прав текст. Ето защо препоръчваме да направите това на конзолата на физическото устройство.

  1. Base64url кодира тайната фраза за това устройство.

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

  3. Бягай xcommand Security ClientSecret Попълване на тайната: "MDEyMzQ1Njc4OWFiY2RlZg"

    Примерната команда по-горе попълва тайна с фразата0123456 789abcdef . Трябва да избереш свой собствен.

Устройството има първоначалната си тайна. Не забравяйте това; не можете да го възстановите и трябва да възстановите фабричните настройки на устройството, за да стартирате отново.
2

Свържете вашия сертификат и частен ключ:

  1. С помощта на текстов редактор отворете .pem файловете, поставете ключа blob blob сертификата и го запишете като нов .pem файл.

    Това е текстът на полезен товар, който ще шифровате и ще поставите във вашия JWE blob.

3

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

  1. Създайте случайна последователност от поне 4 байта. Това е твоята сол.

  2. Извлечете ключ за шифроване на съдържание с инструмента си за скрийптиране.

    За това имате нужда от тайната, солта и ключова дължина, за да съответства на избрания от вас шифър за криптиране. Има някои други фиксирани стойности за снабдяване (N=32768, r=8, p=1). Устройството използва същия процес и стойности, за да извлече един и същ ключ за шифроване на съдържание.

  3. Създайте случайна последователност от точно 12 байта. Това е твоят вектор за инициализация.

  4. Създайте заглавка на JOSE, настройка алг , вкл , и cisco-kdf ключове, както е описано в Разбиране на процеса на външна идентичност за устройства . Задайте действието "добавяне", като използвате ключ: стойност "cisco-action":"добави" в заглавката на JOSE (защото добавяме сертификата към устройството).

  5. Base64url кодира заглавката на JOSE.

  6. Използвайте вашия инструмент за шифроване На JWE с избрания шифър и base64url кодирани JOSE заглавка, за да шифровате текста от файла concatenated pem.

  7. Base64url кодира вектора за инициализация, шифрования PEM полезен товар и маркера за удостоверяване.

  8. Конструирайте jWE blob както следва (всички стойности са base64url кодирани):

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4

Отворете TShell на устройството и изпълнете командата (multiline) добавяне: 

xcommand Security Certificates Services Добавяне на IsEncrypted: Вярно е вашият..JWE.str.ing\n .\n
5

Проверете дали сертификатът е добавен, като стартирате xcommand Security Certificates Services Show

Копирайте пръстовия отпечатък на новия сертификат.

6

Активирайте сертификата за целта WebexIdentity :

  1. Прочетете пръстовия отпечатък на сертификата или от самия сертификат, или от изхода на xcommand Security Certificates Services Show .

  2. Създайте случайна последователност от поне 4 байта и base64url кодирайте тази последователност. Това е твоята сол.

  3. Извлечете ключ за шифроване на съдържание с инструмента си за скрийптиране.

    За това имате нужда от тайната, солта и ключова дължина, за да съответства на избрания от вас шифър за криптиране. Има някои други фиксирани стойности за снабдяване (N=32768, r=8, p=1). Устройството използва същия процес и стойности, за да извлече един и същ ключ за шифроване на съдържание.

  4. Създайте случайна последователност от точно 12 байта и base64url кодирайте тази последователност. Това е твоят вектор за инициализация.

  5. Създайте заглавка на JOSE, настройка алг , вкл , и cisco-kdf ключове, както е описано в Разбиране на процеса на външна идентичност за устройства . Задайте действието "активиране", като използвате ключ: стойност "cisco-action": "активиране" в заглавката на JOSE (защото активираме сертификата на устройството).

  6. Base64url кодира заглавката на JOSE.

  7. Използвайте вашия инструмент за шифроване На JWE с избрания шифър и base64url кодирани JOSE заглавка, за да шифровате сертификата пръстов отпечатък.

    Инструментът трябва да изведе последователност от 16 или 32 байта, в зависимост от това дали сте избрали 128 или 256 бита AES-GCM и етикет за удостоверяване.

  8. Base64urlencode шифрования пръстов отпечатък, и маркера за удостоверяване.

  9. Конструирайте jWE blob както следва (всички стойности са base64url кодирани):

    JOSEHeader..InitVector.EncryptedFingerprint.AuthTag

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

     xcommand Security Certificates Services Активиране Цел: Пръстов отпечатък на WebexIdentity: "Вашият..JWE.криптиран.пръстов отпечатък"

Устройството има шифрован, активен, CA-издаден сертификат, готов да се използва за идентифицирането му в от край до край шифровани Webex срещи.
7

На борда на устройството към вашата организация control Hub.

Тествайте криптиране от край до край с проверка на самоличността
1

Насрочете събрание от правилния тип (Webex Срещи Pro-End to End Encryption_VOIPonly).

Вижте Планиране на webex среща с шифроване от край до край.

2

Присъединете се към събранието като домакин, от клиент на Webex Meetings.

Вижте Присъединяване към webex среща с шифроване от край до край.

3

Присъединете се към събранието от устройство, което има своята самоличност, проверена от Webex CA.

4

Като хост проверете това устройство се появява във фоайето с правилната икона за самоличност.

Вижте Присъединяване към webex среща с шифроване от край до край.

5

Присъединете се към събранието от устройство, което има своята самоличност, проверена от външен CA.

6

Като хост проверете това устройство се появява във фоайето с правилната икона за самоличност. Научете повече за иконите за самоличност .

7

Присъединете се към събранието като неудостоверен участник в събранията.

8

Като домакин проверете този участник се появява във фоайето с правилната икона за самоличност.

9

Като домакин, признайте или отхвърлите хора / устройства.

10

Проверете самоличността на участник/устройство, когато е възможно, като проверите сертификатите.

11

Проверете дали всички в събранието виждат един и същ код за защита на събранието.

12

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

13

Проверете дали всеки вижда един и същ, нов код за защита на събранието.

Задаване на обхват и очаквания

  • Ще направите ли от край до край шифрованите събрания опцията за събрание по подразбиране или ще я разрешите само за някои потребители, или ще позволите на всички хостове да решат? Когато сте решили как ще използвате тази функция, подгответе тези потребители, които ще я използват, особено по отношение на ограниченията и какво да очаквате в събранието.

  • Трябва ли да гарантирате, че нито Cisco, нито някой друг може да дешифрира съдържанието ви или да се представя за вашите устройства? Ако е така, са ви необходими сертификати от публичен CA.

  • Ако имате различни нива на потвърждение на самоличността, дайте възможност на потребителите да се проверяват взаимно с удостоверения за самоличност. Въпреки че има обстоятелства, при които участниците могат да се явят като Непроверени, а участниците трябва да знаят как да проверяват, непроверените хора може да не са самозащитници.

Управление на самоличността

Ако използвате външен CA, за да издадете сертификатите на устройството си, onus е върху вас, за да наблюдавате, обновите и приложите отново сертификати.

Ако сте създали първоначалната тайна, разберете, че потребителите ви може да искат да променят тайната на устройството си. Може да се наложи да създадете интерфейс/да разпространите инструмент, който да им даде възможност да направят това.

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

ИД на тип сесия

Име на обществена услуга

638

E2E Шифроване+Само voIP

652

Про-край до край EVOIПонеncryption_

660

Pro 3 свободен край до край EVOIПонеncryption_

E2E шифроване + идентичност

672

Pro 3 безплатно50-край до край EVOIPonlyncryption_

673

Образователен инструктор E2E EVOIПонеncryption_

676

Broadworks Стандарт плюс край до край криптиране

677

Broadworks Premium плюс край до край криптиране

681

Schoology Безплатно плюс край до край криптиране

Свързани xAPI команди

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

Тези xAPI команди са налични само на устройства, които са или:

  • Регистриран в Webex

  • Регистрирани в помещенията и свързани с Webex с Webex Edge за устройства

Таблица 2. API за ниво на системата за криптирани срещи от край до край и проверена самоличност

API повикване

Описание

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

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

Устройството използва този домейн, когато поиска сертификат от Webex CA. След това домейнът идентифицира устройството.

Тази конфигурация не е приложима, когато устройството има активен, външно издаден сертификат, за да се идентифицира.

xStatus Conference EndToEndEncryption Наличност

Показва дали устройството може да се присъедини към шифровано събрание от край до край. API на облака го нарича така, че сдвоено приложение да знае дали може да използва устройството, за да се присъедини.

xStatus Conference EndToEndEncryption ExternalIdentity Verification

Показва дали устройството използва Външен проверка (има външно издаден сертификат).

xStatus Conference EndToEndEncryption ExternalIdentity Identity

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

xStatus Conference EndToEndEncryption ExternalIdentity CertificateChain Certificate # специфична информация

Чете конкретна информация от външно издаден сертификат.

В показаната команда заменете # с номера на сертификата. Сменете специфична информация с един от:

  • Пръстов отпечатък

  • NotAfter крайна дата на валидност

  • Не преди дата на стартиране на валидност

  • Основно име

  • Алгоритъм за публичен ключ

  • сериен номер

  • Алгоритъм за подпис

  • Предмет # име Списък на темите за сертификата (напр. имейл адрес или име на домейн)

  • валидност Дава статута на валидност на този сертификат (напр валиден или изтекъл )

xStatus Conference EndToEndEncryption ExternalIdentity Status

Състоянието на външната идентичност на устройството (напр. валиден или грешка ).

xStatus Conference EndToEndEncryption InternalIdentity Verification

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

xStatus Conference EndToEndEncryption InternalIdentity Identity

Самоличността на устройството, както е прочетено от Общото име на издадения от Webex сертификат.

Съдържа име на домейн, ако организацията има домейн.

Е празен, ако организацията няма домейн.

Ако устройството е в организация, която има множество домейни, това е стойността от Предпочитан домейн .

xStatus Conference EndToEndEncryption InternalIdentity CertificateChain Certificate # специфична информация

Чете конкретна информация от сертификата, издаден от Webex.

В показаната команда заменете # с номера на сертификата. Сменете специфична информация с един от:

  • Пръстов отпечатък

  • NotAfter крайна дата на валидност

  • Не преди дата на стартиране на валидност

  • Основно име

  • Алгоритъм за публичен ключ

  • сериен номер

  • Алгоритъм за подпис

  • Предмет # име Списък на темите за сертификата (напр. имейл адрес или име на домейн)

  • валидност Дава статута на валидност на този сертификат (напр валиден или изтекъл )

Таблица 3. В извикване на API за криптирани срещи от край до край и проверена самоличност

API повикване

Описание

xEvent Conference ParticipantList ParticipantAdded

xEvent Conference ParticipantList ParticipantUpdated

xEvent Conference ParticipantList ParticipantDeleted

Тези три събития сега включват EndToEndEncryptionStatus , EndToEndEncryptionIdentity , и EndToEndEncryptionCertInfo за засегнатия участник.

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

API повикване

Описание

xCommand Security ClientSecret Populate Secret: "base64url-encoded"

или

xCommand Security ClientSecret Попълване на тайна: JWEblob

Приема base64url кодирана обикновена текстова стойност за засяване на клиентската тайна на устройството за първи път.

За да актуализирате тайната след този първи път, трябва да снабдите jWE петно, съдържащо новата тайна, криптирана от старата тайна.

xCommand Security Certificates Services Добавяне JWEblob

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

Разширихме тази команда, за да приемем JWE блоб, съдържащ шифрованите PEM данни.

xCommand Security Certificates Services Активиране Цел: WebexIdentity Finger Print: JWEblob

Активира конкретен сертификат за WebexIdentity. За това Цел , командата изисква идентифициращият пръстов отпечатък да бъде криптиран и сериализиран в JWE blob.

xCommand Security Certificates Services Деактивиране Цел:WebexIdentity FingerPrint: JWEblob

Дезактивира конкретен сертификат за WebexIdentity. За това Цел , командата изисква идентифициращият пръстов отпечатък да бъде криптиран и сериализиран в JWE blob.