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

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

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

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

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

Потребителите на приложението Webex Meetings се удостоверяват срещу хранилището за самоличност на 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 срещи.

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

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

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

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

Устройства

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

  • Табло на Webex

  • Уебекс Бюро Про

  • Бюро Уебекс

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

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

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

  • Серия Webex C

  • Серия Webex DX

  • Серия Webex EX

  • Серия Webex MX

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

Софтуерни клиенти

  • От 41.7 уебекс събрания настолен клиент може да се присъедини от край до край шифровани събрания.

  • Приложението Webex не може да се присъедини към шифровани събрания от край до край.

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

  • Webex уеб клиент не може да се присъедини към от край до край шифровани събрания.

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

Самоличност

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

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

Срещи

  • Шифрованите срещи от край до край в момента поддържат максимум 200 участници.

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

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

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

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

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

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

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

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

Производна проба JWE мехури

Проба от правилно криптирана JWE въз основа на дадени параметри (допълнение)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • (Препоръчва се) Предоставете интерфейс на (или разпространявайте) инструмента си, за да дадете възможност на потребителите на устройства да променят първоначалната тайна (за да защитят своите медии от вас!).

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

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

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

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

  • JOSE Header (защитен). В заглавката на 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" }

      Още един патентован ключ. Използваме стойностите, които предоставяте като входове за дериват на ключове на устройството. The version трябва да се 1(версията на ключовата ни функция за дериват). Стойността на salt трябва да бъде базова 64 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 блоб, носещ сертификата и неговия частен ключ (сплотен)

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

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

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

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

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

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

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

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

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

  • БлокSizeFactor (r) е 8

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

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

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

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

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

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

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

Примерният сценарий е добавяне на PEM blob към устройството (имитира добавяне на сертификат, с много кратък низ вместо пълен cert + ключ). Клиентската тайна в примера е 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"}

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

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

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

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

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

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

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

    • Шифър за криптиране е 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 Security Certificates Add eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

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

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

1

Влезте в контролния център и отворете страницата "Събрание".

2

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

3

Щракнете върху Конфигуриране на сайт.

4

В областта Общи настройки щракнете върху Типове сесии.

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

 

Има по-стар тип сесия с много подобно име: Pro-Край до край криптиране. Този тип сесия включва нешифрован PSTN достъп до събрания. Уверете се, че имате _VOIPonly версия, за да се гарантира край до край криптиране. Можете да проверите, като задържите курсора на курсора на курсора върху PRO връзката в колоната за код на сесията; за този пример целта на връзката трябва да бъде javascript:ShowFeature(652).

Може да променим Имената на обществените услуги за тези типове сесии в бъдеще, например, планираме да променим Pro-End to End Encryption_VOIPonlye2E Encryption + Identity.

5

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

Какво да правим по-нататък

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

1

Щракнете върху Потребители и изберете потребител, за да отворите конфигурационния панел на потребителя.

2

В областта услуги щракнете върхуCisco Webex събрания.

3

Изберете сайта (ако потребителят е в повече от един) и щракнете върху Хост.

4

Поставете отметка в квадратчето до записа Webex Meetings с етикет Pro-End to End Encryption_VOIPonly.

5

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

6

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

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

1

Влезте в Контролния център при https://admin.webex.com и отворете страницата "Събрание".

2

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

3

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

4

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

5

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

6

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

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

7

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

Позоваването на CSV файлов формат при https://help.webex.com/en-us/5vox83 има някои подробности за целта и съдържанието на CSV файла.

8

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

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

9

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

10

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

11

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

12

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

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

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

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

Ако вашите устройства все още не са на борда, можете да следвате https://help.webex.com/n25jyr8 или https://help.webex.com/nutc0dy. Също така трябва да проверите домейна/домейна, който искате да използвате, за да идентифицирате устройствата (https://help.webex.com/cd6d84).

1

Влезте в Контролния център (https://admin.webex.com) и отворете страницата Устройства.

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 файловете, поставете ключа blob blob сертификата и го запишете като нов .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 с избрания шифър и base64url кодирани JOSE заглавка, за да шифровате текста от файла concatenated pem.

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

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

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4

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

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 с избрания шифър и base64url кодирани JOSE заглавка, за да шифровате сертификата пръстов отпечатък.

    Инструментът трябва да изведе последователност от 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 Срещи Pro-End до Край Encryption_VOIPonly).

2

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

3

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

4

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

5

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

6

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

7

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

8

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

9

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

10

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

11

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

12

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

13

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

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

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

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

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

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

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

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

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

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

638

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

652

Про-край до край Encryption_VOIPonly

660

Pro 3 свободен край до края Encryption_VOIPonly

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

672

Pro 3 Free50-края до края Encryption_VOIPonly

673

Образование инструктор E2E Encryption_VOIPonly

676

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

677

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

681

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

Тези таблици описват Webex устройства API команди, които добавихме за от край до край шифровани събрания и потвърдена самоличност. За да прочетете повече за това как да използвате API, вижте https://help.webex.com/nzwo1ok.

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

API повикване

Описание

xConfiguration Conference EndToEndEncryption Mode: On

Завоите завършват до край на режима на шифроване On или Off.

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

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

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

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

xStatus Conference EndToEndEncryption Availability

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

xStatus Conference EndToEndEncryption ExternalIdentity Valid

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

xStatus Conference EndToEndEncryption ExternalIdentity Identity

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

xStatus Conference EndToEndEncryption ExternalIdentity CertInfo

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

xStatus Conference EndToEndEncryption InternalIdentity Valid

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

xStatus Conference EndToEndEncryption InternalIdentity Identity

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

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

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

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

xStatus Conference EndToEndEncryption InternalIdentity CertInfo

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

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

API повикване

Описание

xStatus Call # ServerEncryption Type

Чете шифъра за шифроване, използван в HTTPS връзката към Webex. Това се показва на потребителя.

xStatus Conference Call # EndToEndEncryption Status

Чете повикванията от край до край криптиране състояние. Показва се на потребителя като наличие (или отсъствие) на иконата на катинар.

xStatus Conference Call # EndToEndEncryption SecurityCode

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

xStatus Conference Call # EndToEndEncryption MediaEncryption Type

Чете шифъра за шифроване, използван в медийната връзка. Това се показва на потребителя.

xStatus Conference Call # EndToEndEncryption GroupEncryption Type

Чете шифъра за шифроване, използван за защита на слой за съобщения (MLS).

xStatus Conference Call # EndToEndEncryption Roster Participant

Изброява участниците, допринасящи за държавата от групата MLS в това събрание. Списъкът е открит от MLS, а не от Webex.

xStatus Conference Call # EndToEndEncryption Roster Participant # Id

WDM URL адресът на определен участник.

xStatus Conference Call # EndToEndEncryption Roster Participant # Status:

Състоянието на проверка на указания участник.

xStatus Conference Call # EndToEndEncryption Roster Participant # Identity:

Основната самоличност на посочения участник, обикновено домейн (устройство) или имейл адрес (потребител).

xStatus Conference Call # EndToEndEncryption Roster Participant # DisplayName:

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

xStatus Conference Call # EndToEndEncryption Roster Participant # CertInfo:

Информацията за сертификата от сертификата на указания участник като JSON blob.

xCommand Conference ParticipantList Search

Разширихме тази команда, за да включим информация за криптиране от край до край за участниците.

xCommand Conference ParticipantList Search

Търсенето в списъка с участници вече включва EndToEndEncryptionStatus, статуса на проверка на самоличността на участника. Тази стойност се показва в ПИ.

xCommand Conference ParticipantList Search

Търсенето в списъка с участници вече включва EndToEndEncryptionIdentity, основната самоличност на участника. Това обикновено е домейн или имейл адрес. Тази стойност се показва в ПИ.

xCommand Conference ParticipantList Search

Търсенето в списъка с участници вече включва EndToEndEncryptionCertInfo, jSON blob, съдържащ сертификата на участника. Тази стойност се показва в ПИ.

xEvent Conference ParticipantList Participant(Added)

xEvent Conference ParticipantList Participant(Updated)

xEvent Conference ParticipantList Participant(Deleted)

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

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

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

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

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