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

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

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

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

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

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

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

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

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

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

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

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

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

Ако вашата организация има няколко домейна, можете да използвате Control Hub, за да кажете на Webex кой домейн да използва устройството за своята идентичност. Можете също да използвате API xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com".

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

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

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

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

Стойностите в сертификата са по преценка на организацията. Общото име (CN) и алтернативното име на субекта (SAN) ще бъдат показани в потребителски интерфейс на Среща в Webex , както е описано в Шифроване от край до край с проверка на самоличността за Webex Meetings .

Препоръчваме да използвате отделен сертификат за устройство и да имате уникална CN за устройство. Например „meeting-room-1.example.com“ за организацията, която притежава домейна „example.com“.

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

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

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

Устройства

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

  • Табло на Webex

  • Webex Desk Pro

  • Webex Desk

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

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

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

  • Webex C серия

  • Серия Webex DX

  • Webex EX серия

  • Серия Webex MX

  • SIP устройства на трети страни

Софтуерни клиенти
  • Започвайки с версия 41.6, настолният клиент на Webex Meetings може да се присъединява към криптирани срещи от край до край.

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

  • Уеб клиентът на Webex не може да се присъедини към криптирани срещи от край до край.

  • SIP клиентите на трети страни не могат да се присъединят към криптирани срещи от край до край.

Самоличност
  • По дизайн ние не предоставяме опции на Control Hub, за да управлявате външно потвърдена идентичност на устройството. За истинско криптиране от край до край, само вие трябва да знаете/да имате достъп до тайните и ключовете. Ако въведем облачна услуга за управление на тези ключове, има вероятност те да бъдат прихванати.

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

Срещи
  • Понастоящем криптираните срещи от край до край поддържат максимум 200 участници.

  • От тези 200 участници могат да се присъединят максимум 25 външно проверени устройства и те трябва да са първите участници, които се присъединяват към срещата .

    Когато по-голям брой устройства се присъединят към среща, нашите мултимедийни услуги се опитват да прекодират медийните потоци. Ако не можем да декриптираме, транскодираме и повторно криптираме носителя (защото нямаме и не трябва да разполагаме с ключове за криптиране на устройствата), тогава транскодирането се проваля.

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

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

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

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

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

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

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

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

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

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

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

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

  • Сертификатът трябва да бъде издаден и подписан от добре познат публичен CA.

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

  • Общо име (CN) и алтернативно име/и на субекта (SAN/s): Те не са важни за Webex, но трябва да бъдат стойности, които хората могат да четат и свързват с устройството. CN ще се показва на други участници в срещата като основна потвърдена самоличност на устройството и ако потребителите проверят сертификата чрез потребителския интерфейс на срещата, те ще видят SAN/s. Може да искате да използвате имена като name.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 да бъде създаден като вход към устройствата, така че да можете да създадете свой собствен инструмент за създаване на блобове от вашите сертификати и ключове.

Отнесете се към 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": "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 URL-кодирана последователност от поне 4 байта, която вие трябва изберете произволно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Разходният фактор (N) е 32768

  • BlockSizeFactor (r) е 8

  • Коефициентът на паралелизация (p) е 1

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

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

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

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

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

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

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

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

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

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

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

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

    • Полезният товар е this is a PEM file

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

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

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

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

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

    Това е петият елемент в JWE blob.

  10. Свържете петте елемента на JWE blob с точки (JOSEheader..IV.Ciphertext.Tag), за да получите:

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

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

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

    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_ Само за VOIP .

 

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

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

5

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

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

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

1

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

2

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

3

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

4

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

5

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

6

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

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

1

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

2

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

3

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

4

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

5

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

6

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

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

7

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

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

8

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


 

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

9

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

10

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

11

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

12

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1

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

2

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

3

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

4

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

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

имате нужда от:

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

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

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

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

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

  • Ан scrypt изпълнение.

  • Тайна дума или фраза за всяко устройство.

1

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

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

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

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

  3. Изпълнете xcommand Security ClientSecret Populate Secret: "MDEyMzQ1Njc4OWFiY2RlZg"

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

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

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

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

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

3

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

  1. Създайте произволна последователност от поне 4 байта. Това е вашата сол.

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

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

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

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

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

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

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

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

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4

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

xcommand Security Certificates Services Add IsEncrypted: True
your..JWE.str.ing\n
.\n
5

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

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

6

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

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

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

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

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

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

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

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

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

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

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

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

    JOSEHeader..InitVector.EncryptedFingerprint.AuthTag

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

                      xcommand Security Certificates Services Activate Purpose: WebexIdentity Fingerprint: "Your..JWE.encrypted.fingerprint" 
                    
Устройството има криптиран, активен сертификат, издаден от CA, готов за използване за идентифицирането му в криптирани срещи на Webex от край до край.
7

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

1

Насрочете среща от правилния тип ( Webex Meetings Pro-End to End Encryption_ Само за VOIP ).

2

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

3

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

4

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

5

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

6

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

7

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

8

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

9

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

10

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

11

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

12

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

13

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

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

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

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

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

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

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

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

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

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

638

Само E2E Encryption+ VoIP

652

Pro-End to End Encryption_ Само за VOIP

660

Pro 3 от свободен край до край Encryption_ Само за VOIP

E2E криптиране + идентичност

672

Pro 3 Free50-End to End Encryption_ Само за VOIP

673

Инструктор по образование E2E Encryption_ Само за VOIP

676

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

677

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

681

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

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

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

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

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

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

API обаждане

Описание

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

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

Устройството използва този домейн, когато поиска сертификат от CA на 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 CA.

xStatus Conference EndToEndEncryption InternalIdentity Identity

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

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

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

Ако устройството е в организация, която има няколко домейна, това е стойността от PreferredDomain.

xStatus Conference EndToEndEncryption InternalIdentity CertificateChain Certificate # specificinfo

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

В показаната команда заменете # с номера на сертификата. Замени specificinfo с един от:

  • Fingerprint

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

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

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

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

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

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

API обаждане

Описание

xEvent Conference ParticipantList ParticipantAdded

xEvent Conference ParticipantList ParticipantUpdated

xEvent Conference ParticipantList ParticipantDeleted

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

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

API обаждане

Описание

xCommand Security ClientSecret Populate Secret: "base64url-encoded"

или

xCommand Security ClientSecret Populate Secret: JWEblob

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

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

xCommand Security Certificates Services Add JWEblob

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

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

xCommand Security Certificates Services Activate Purpose:WebexIdentity FingerPrint: JWEblob

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

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

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