Experiența utilizatorului

Utilizatorii aleg tipul de întâlnire atunci când programează o întâlnire. La admiterea participanților din sala de așteptare, precum și în timpul întâlnirii, gazda poate vedea starea de verificare a identității fiecărui participant. Există, de asemenea, un cod de întâlnire care este comun tuturor participanților actuali la întâlnire, pe care îl pot utiliza pentru a verifica dacă întâlnirea lor nu a fost interceptată de un atac nedorit Meddler In The Middle (MITM).

Partajați următoarele informații cu gazdele întâlnirii:

Verificarea identității cu CA intern sau extern

Verificați identitatea

Criptarea end-to-end cu verificarea identității oferă securitate suplimentară unei întâlniri criptate end-to-end.

Atunci când participanții sau dispozitivele intră într-un grup MLS (Messaging Layer Security) partajat, aceștia își prezintă certificatele celorlalți membri ai grupului, care validează apoi certificatele împotriva autorităților de certificare emitente (CA). Confirmând că certificatele sunt valide, CA verifică identitatea participanților, iar întâlnirea afișează participanții/dispozitivele ca verificate.

Utilizatorii Aplicației Webex se autentifică pe depozitul de identitate Webex, ceea ce le emite un token de acces atunci când autentificarea reușește. Dacă au nevoie de un certificat pentru a-și verifica identitatea într-o întâlnire criptată end-to-end, Webex CA le emite un certificat pe baza tokenului lor de acces. În acest moment, nu oferim utilizatorilor Webex Meetings o modalitate de a obține un certificat eliberat de o autoritate de certificare terță/externă.

Dispozitivele se pot autentifica utilizând un certificat eliberat de CA intern (Webex) sau un certificat eliberat de un CA extern:

  • CA intern — Webex emite un certificat intern pe baza tokenului de acces al contului dispozitivului. Certificatul este semnat de Webex CA. Dispozitivele nu au ID-uri de utilizator în același mod ca utilizatorii, astfel încât Webex utilizează (unul dintre) domeniile organizației dvs. atunci când scrieți identitatea certificatului dispozitivului (nume comun (CN)).

  • CA extern – Solicitați și achiziționați certificate ale dispozitivului direct de la emitentul ales. Trebuie să criptați, să încărcați direct și să autorizați certificatele utilizând un secret cunoscut numai dvs.

    Cisco nu este implicat, ceea ce face ca acest lucru să garanteze o criptare integrală reală și identitatea verificată și să prevină posibilitatea teoretică ca Cisco să vă poată intercepta întâlnirea/decripta conținutul media.

Certificatul dispozitivului emis la nivel intern

Webex emite un certificat dispozitivului atunci când se înregistrează după pornire și îl reînnoiește atunci când este necesar. Pentru dispozitive, certificatul include ID-ul contului și un domeniu.

Dacă organizația dvs. nu are un domeniu, Webex CA emite certificatul fără un domeniu.

Dacă organizația dvs. are mai multe domenii, puteți utiliza Control Hub pentru a indica Webex ce domeniu să utilizeze dispozitivul pentru identitatea sa. De asemenea, puteți utiliza API-ul xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com".

Dacă aveți mai multe domenii și nu setați domeniul preferat pentru dispozitiv, Webex alege unul pentru dvs.

Certificatul dispozitivului emis la nivel extern

Un administrator poate furniza unui dispozitiv propriul certificat care a fost semnat cu una dintre CA-urile publice.

Certificatul trebuie să se bazeze pe o pereche de chei ECDSA P-256, deși poate fi semnat de o cheie RSA.

Valorile din certificat sunt la discreția organizației. Numele comun (CN) și numele alternativ al subiectului (SAN) vor fi afișate în interfața de utilizator a întâlnirii Webex, conform descrierii din Criptare integrală cu verificarea identității pentru Webex Meetings.

Vă recomandăm să utilizați un certificat separat pentru fiecare dispozitiv și să aveți un CN unic pentru fiecare dispozitiv. De exemplu, „meeting-room-1.example.com” pentru organizația care deține domeniul „example.com”.

Pentru a proteja pe deplin certificatul extern de modificare, este utilizată o caracteristică secretă client pentru a cripta și semna diferite comenzi xcommands.

Atunci când utilizați secretul clientului, este posibil să gestionați în siguranță certificatul de identitate Webex extern prin intermediul xAPI. În prezent, acest lucru este limitat la dispozitivele online.

Webex oferă în prezent comenzi API pentru gestionarea acestui lucru.

Funcții și limitări

Dispozitive

Următoarele dispozitive înregistrate în cloud Webex din seria Room și Webex Desk pot intra în întâlniri E2EE:

  • Tablă Webex

  • Webex Desk Pro

  • Webex Desk

  • Webex Room Kit

  • Webex Room Kit Mini

Următoarele dispozitive nu pot intra în întâlniri E2EE:

  • Seria Webex C

  • Seria Webex DX

  • Seria Webex EX

  • Seria Webex MX

  • Dispozitive SIP terțe

Clienți software

  • Aplicația Webex pentru clienții desktop și mobili pot intra în întâlniri E2EE.

  • Clientul web Webex nu poate intra în întâlnirile E2EE.

  • Clienții software SIP terți nu pot intra în întâlnirile E2EE.

Identitate

  • Din punct de vedere al concepției, nu oferim opțiuni Control Hub pentru a vă gestiona identitatea dispozitivului verificată extern. Pentru criptarea integrală adevărată, numai dvs. trebuie să cunoașteți/accesați secretele și cheile. Dacă am introdus un serviciu cloud pentru a gestiona acele chei, există posibilitatea ca acestea să fie interceptate.

  • În prezent, oferim o „rețetă” pentru a vă proiecta propriile instrumente, pe baza tehnicilor de criptare standard în industrie, pentru a vă ajuta să solicitați sau să criptați certificatele de identitate ale dispozitivului și cheile lor private. Nu dorim să avem acces real sau perceput la secretele sau cheile dvs.

Întâlniri

  • Întâlnirile E2EE acceptă în prezent maximum 1000 de participanți.

  • Puteți partaja table noi în întâlnirile E2EE. Există unele diferențe față de table în întâlnirile obișnuite:
    • În întâlnirile E2EE, utilizatorii nu pot accesa table create în afara întâlnirii, inclusiv table private, table partajate de alte persoane și table din spațiile Webex.
    • Tablele create în întâlnirile E2EE sunt disponibile numai în timpul întâlnirii. Acestea nu sunt salvate și nu sunt accesibile după încheierea întâlnirii.
    • Dacă cineva partajează conținut într-o întâlnire E2EE, îl puteți adnota. Pentru mai multe informații despre adnotări, consultați Aplicația Webex | Marcați conținutul partajat cu adnotări.

Gestionare interfață

Vă recomandăm insistent să utilizați Control Hub pentru a vă gestiona site-ul Meetings, deoarece organizațiile Control Hub au identitate centralizată pentru întreaga organizație.

Resurse suplimentare
Cerințe preliminare

  • Webex Meetings 41.7.

  • Dispozitive Webex din seria Room și Webex Desk înregistrate în cloud, care rulează 10.6.1-RoomOS_August_2021.

  • Acces administrativ la site-ul întâlnirii în Control Hub.

  • Unul sau mai multe domenii verificate din organizația dvs. Control Hub (dacă utilizați Webex CA pentru a emite certificate de dispozitiv pentru identitatea verificată).

  • Sălile de întâlnire pentru colaborare trebuie să fie activate, astfel încât persoanele să poată intra de pe sistemul lor video. Pentru mai multe informații, consultați Permiteți sistemelor video să se alăture întâlnirilor și evenimentelor pe site-ul dvs. Webex.

Obțineți certificate de dispozitiv

Puteți omite acest pas dacă nu aveți nevoie de identități verificate extern.

Pentru cel mai înalt nivel de securitate și pentru verificarea identității, fiecare dispozitiv ar trebui să aibă un certificat unic eliberat de o autoritate publică de certificare (CA) de încredere.

Trebuie să interacționați cu CA pentru a solicita, achiziționa și primi certificatele digitale și pentru a crea cheile private asociate. La solicitarea certificatului, utilizați acești parametri:

  • Certificatul trebuie să fie emis și semnat de o autoritate de certificare publică bine cunoscută.

  • Unică: Vă recomandăm ferm să utilizați un certificat unic pentru fiecare dispozitiv. Dacă utilizați un singur certificat pentru toate dispozitivele, securitatea dvs. este compromisă.

  • Denumire comună (NC) şi nume alternativ(e) subiect(e): Acestea nu sunt importante pentru Webex, dar trebuie să fie valori pe care oamenii le pot citi și le pot asocia cu dispozitivul. CN va afișa altor participanți la întâlnire ca identitate verificată principală a dispozitivului, iar dacă utilizatorii inspectează certificatul prin interfața cu utilizatorul a întâlnirii, vor vedea SAN/urile. Poate doriți să utilizați nume precum name.model@example.com.

  • Format fișier: Certificatele și cheile trebuie să fie în .pem format.

  • Scop: Scopul certificatului trebuie să fie identitatea Webex.

  • Se generează cheile: Certificatele trebuie să se bazeze pe perechile de taste ECDSA P-256 (algoritm de semnătură digitală cu curba eliptică care utilizează curba P-256).

    Această cerință nu se extinde și la cheia de semnare. CA poate utiliza o cheie RSA pentru a semna certificatul.

Pregătiți-vă pentru integrarea dispozitivelor

Puteți omite acest pas dacă nu doriți să utilizați identitatea verificată extern cu dispozitivele dvs.

Dacă utilizați dispozitive noi, nu le înscrieți încă în Webex. Pentru a fi în siguranță, nu le conectați la rețea în acest moment.

Dacă aveți dispozitive existente pe care doriți să le faceți upgrade pentru a utiliza identitatea verificată extern, trebuie să resetați dispozitivele la setările din fabrică.

  • Salvați configurația existentă dacă doriți să o păstrați.

  • Programați o fereastră atunci când dispozitivele nu sunt utilizate sau utilizați o abordare etapizată. Notificați utilizatorii cu privire la modificările la care se pot aștepta.

  • Asigurați accesul fizic la dispozitive. Dacă trebuie să accesați dispozitivele prin rețea, rețineți că secretele călătoresc în text simplu și că vă compromiteți securitatea.

După ce ați finalizat acești pași, permiteți sistemelor video să intre în întâlniri și evenimente pe site-ul dvs. Webex.

Înțelegeți procesul de identitate externă pentru dispozitive

Pentru a vă asigura că fișierele media ale dispozitivului nu pot fi criptate de nimeni cu excepția dispozitivului, trebuie să criptați cheia privată de pe dispozitiv. Am proiectat API-uri pentru dispozitiv pentru a permite gestionarea cheii criptate și a certificatului, utilizând JSON Web Encryption (JWE).

Pentru a asigura o criptare integrală reală prin cloudul nostru, nu ne putem implica în criptarea și încărcarea certificatului și a cheii. Dacă aveți nevoie de acest nivel de securitate, trebuie să:

  1. Solicitați certificatele.

  2. Generați perechile de chei ale certificatelor dvs.

  3. Creați (și protejați) un secret inițial pentru fiecare dispozitiv, pentru a semăna capacitatea de criptare a dispozitivului.

  4. Dezvoltați și mențineți-vă propriul instrument pentru criptarea fișierelor utilizând standardul JWE.

    Procesul și parametrii (non-secreți) de care veți avea nevoie sunt explicați mai jos, precum și o rețetă de urmat în instrumentele de dezvoltare la alegere. De asemenea, oferim unele date de testare și blobs JWE rezultate așa cum ne așteptăm, pentru a vă ajuta să verificați procesul.

    O implementare de referință neacceptată care utilizează Python3 și biblioteca JWCrypto este disponibilă de la Cisco, la cerere.

  5. Concatenați și criptați certificatul și cheia utilizând instrumentul și secretul inițial al dispozitivului.

  6. Încărcați blob JWE rezultat pe dispozitiv.

  7. Setați scopul certificatului criptat care va fi utilizat pentru identitatea Webex și activați certificatul.

  8. (Recomandat) Furnizați o interfață (sau distribuiți) instrumentului dvs. pentru a permite utilizatorilor dispozitivului să schimbe secretul inițial și să își protejeze conținutul media de dvs.

Cum folosim formatul JWE

Această secțiune descrie modul în care ne așteptăm ca JWE să fie creat ca intrare pentru dispozitive, astfel încât să puteți construi propriul instrument pentru a crea blocurile din certificate și chei dvs.

Consultați JSON Web Encryption (JWE) https://datatracker.ietf.org/doc/html/rfc7516 și JSON Web Signature (JWS) https://datatracker.ietf.org/doc/html/rfc7515.

Folosim Serializarea compactă a unui document JSON pentru a crea blobs JWE. Parametrii pe care trebuie să îi includeți atunci când creați blobs JWE sunt:

  • JOSE Header (protejat). În antetul Semnare și criptare obiect JSON TREBUIE să includeți următoarele perechi de valori cheie:

    • "alg":"dir"

      Algoritmul direct este singurul pe care îl acceptăm pentru criptarea sarcinii utile și trebuie să utilizați secretul inițial al clientului dispozitivului.

    • "enc":"A128GCM" sau "enc":"A256GCM"

      Acceptăm acești doi algoritmi de criptare.

    • "cisco-action": "add" sau "cisco-action": "populate" sau "cisco-action": "activate" sau "cisco-action": "deactivate"

      Aceasta este o cheie privată și patru valori pe care le poate lua. Am introdus această cheie pentru a semnala scopul datelor criptate dispozitivului țintă. Valorile sunt denumite după comenzile xAPI de pe dispozitiv pe care utilizați datele criptate.

      Am numit-o cisco-action pentru a atenua potențialele ciocniri cu viitoarele extensii JWE.

    • "cisco-kdf": { "version": "1", "salt": "base64URLEncodedRandom4+Bytes" }

      O altă cheie proprietară. Utilizăm valorile pe care le furnizați ca intrări pentru derivarea cheii pe dispozitiv. version trebuie să fie 1 (versiunea funcției noastre de derivare cheie). Valoarea salt trebuie să fie o secvență codificată pe URL-ul base64 de cel puțin 4 biți, pe care trebuie să o alegeți la întâmplare.

  • Cheie criptată JWE. Acest câmp este gol. Dispozitivul îl derivă din ClientSecret inițial.

  • Vector de inițializare JWE. Trebuie să furnizați un vector de inițializare codificat pe baza URL pentru decriptarea sarcinii utile. IV TREBUIE să fie o valoare aleatorie de 12 biți (folosim familia de cifruri AES-GCM, care necesită ca IV să aibă o lungime de 12 biți).

  • JWE AAD (date autentificate suplimentare). Trebuie să omiteți acest câmp deoarece nu este acceptat în Serializare compactă.

  • Text cifru JWE: Aceasta este sarcina utilă criptată pe care doriți să o păstrați secretă.

    Sarcina utilă POATE fi goală. De exemplu, pentru a reseta secretul clientului, trebuie să îl suprascrieți cu o valoare goală.

    Există diferite tipuri de sarcini lucrative, în funcție de ceea ce încercați să faceți pe dispozitiv. Comenzile xAPI diferite așteaptă sarcini utile diferite și trebuie să specificați scopul sarcinii utile cu cisco-action cheia, după cum urmează:

    • Cu "cisco-action":"populate" cifrul este noul ClientSecret.

    • Cu „"cisco-action":"add" cifrul este o bulă PEM care poartă certificatul și cheia sa privată (concatenată).

    • Cu „"cisco-action":"activate" cifrul este amprenta (reprezentarea hexazecimală a sha-1) a certificatului pe care îl activăm pentru verificarea identității dispozitivului.

    • Cu „"cisco-action":"deactivate" cifrul este amprenta (reprezentarea hexazecimală a sha-1) a certificatului pe care îl dezactivăm de la a fi utilizat pentru verificarea identității dispozitivului.

  • Etichetă de autentificare JWE: Acest câmp conține eticheta de autentificare pentru a verifica integritatea întregii bule JWE serializate compact

Cum extragem cheia de criptare din ClientSecret

După prima populație a secretului, nu acceptăm sau afișăm secretul ca text simplu. Acest lucru are rolul de a preveni potențialele atacuri din dicționar ale unei persoane care ar putea accesa dispozitivul.

Software-ul dispozitivului utilizează secretul clientului ca intrare într-o funcție de derivare a cheii (kdf) și apoi utilizează cheia derivată pentru decriptarea/criptarea conținutului pe dispozitiv.

Ceea ce înseamnă acest lucru pentru tine este că instrumentul de a produce blobs JWE trebuie să urmeze aceeași procedură pentru a obține aceeași cheie de criptare/decriptare din secretul clientului.

Dispozitivele utilizează scrypt pentru derivarea cheii (a se vedea https://en.wikipedia.org/wiki/Scrypt), cu următorii parametri:

  • CostFactor (N) este 32768

  • BlockSizeFactor (r) este 8

  • ParalelizareFactor (p) este 1

  • Sarea este o secvență aleatorie de cel puțin 4 octeți; trebuie să furnizați aceeași secvență salt atunci când specificați cisco-kdf parametrul.

  • Lungimile cheii sunt fie 16 biți (dacă selectați algoritmul AES-GCM 128), fie 32 biți (dacă selectați algoritmul AES-GCM 256)

  • Capacul maxim al memoriei este de 64 MB

Acest set de parametri este singura configurație a scrypt care este compatibilă cu funcția de derivare a cheii pe dispozitive. Acest kdf de pe dispozitive se numește "version":"1", care este singura versiune utilizată în prezent de cisco-kdf parametrul.

Exemplu lucrat

Iată un exemplu pe care îl puteți urma pentru a verifica dacă procesul de criptare JWE funcționează la fel ca procesul pe care l-am creat pe dispozitive.

Exemplul este adăugarea unei bule PEM la dispozitiv (mimează adăugarea unui certificat, cu un șir foarte scurt în loc de un certificat + cheie completă). Secretul clientului din exemplu este ossifrage.

  1. Alegeți un cifru de criptare. Acest exemplu utilizează A128GCM (AES cu chei de 128 biți în modul contor Galois). Instrumentul dvs. poate utiliza A256GCM dacă preferați.

  2. Alegeți o sare (trebuie să fie o secvență aleatorie de cel puțin 4 octeți). Acest exemplu utilizează (biți hexazecimali)E5 E6 53 08 03 F8 33 F6. URL-ul de bază64 codifică secvența pentru a obține 5eZTCAP4M_Y (eliminați padding-ul base64).

  3. Iată un exemplu de scrypt apel pentru a crea cheia de criptare a conținutului (cek):

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

    Cheia derivată trebuie să fie de 16 biți (hex) după cum urmează:95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac la ce bază URL codifică adresa lZ66bdEiAQV4_mqdInj_rA.

  4. Alegeți o secvență aleatorie de 12 biți de utilizat ca vector de inițializare. Acest exemplu utilizează (hexazecimal) 34 b3 5d dd 5f 53 7b af 2d 92 95 83 pe care baza URL-ului de 64 codifică NLNd3V9Te68tkpWD.

  5. CREAȚI ANTETUL JOSE CU SERIALIZARE COMPACTĂ (URMAȚI ACEEAȘI ORDINE DE PARAMETRI PE CARE ÎI FOLOSIM AICI) ȘI APOI CODUL URL DE BAZĂ ｟_ph_32｠:

    {"alg":"dir","cisco-action":"add","cisco-kdf":{"salt":"5eZTCAP4M_Y","version":"1"},"enc":"A128GCM"}

    Antetul JOSE codificat pe baza URL-ului este eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

    Acesta va fi primul element al bulei JWE.

  6. Al doilea element al blob-ului JWE este gol, deoarece nu furnizăm o cheie de criptare JWE.

  7. Al treilea element al blobului JWE este vectorul de inițializare NLNd3V9Te68tkpWD.

  8. Utilizați instrumentul de criptare JWE pentru a produce o sarcină utilă criptată și o etichetă. În acest exemplu, sarcina utilă necriptată va fi falsul PEM blob this is a PEM file

    Parametrii de criptare pe care ar trebui să îi utilizați sunt:

    • Sarcina utilă este this is a PEM file

    • Cifrul de criptare este AES 128 GCM

    • URL-ul de bază, codificat antetul JOSE ca date suplimentare autentificate (AAD)

    URL-UL DE BAZĂ ｟_ph_32｠ CODIFICĂ SARCINA UTILĂ CRIPTATĂ, CARE AR TREBUI SĂ AIBĂ CA REZULTAT f5lLVuWNfKfmzYCo1YJfODhQ

    Acesta este al patrulea element (JWE Ciphertext) din blob JWE.

  9. URL-ul de bază, codifică eticheta pe care ați produs-o la pasul 8, care ar trebui să aibă ca rezultat PE-wDFWGXFFBeo928cfZ1Q

    Acesta este al cincilea element din blob JWE.

  10. Concatenați cele cinci elemente ale bulei JWE cu puncte (JOSEheader..IV.Ciphertext.Tag) pentru a obține:

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

  11. Dacă ați obținut aceleași valori codificate URL de bază, așa cum se arată aici, folosind propriile instrumente, sunteți gata să le utilizați pentru a securiza criptarea E2E și identitatea verificată a dispozitivelor dvs.

  12. Acest exemplu nu va funcționa de fapt, dar, în principiu, următorul pas ar fi să utilizați blob JWE pe care l-ați creat mai sus ca intrare la comanda xcommand pe dispozitivul care adaugă certificatul:

    xCommand Security Certificates Add eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

Tipurile de sesiune pentru întâlnirile de tip zero încredere sunt disponibile pentru toate site-urile de întâlniri fără costuri suplimentare. Unul dintre aceste tipuri de sesiuni se numește Pro-End to End Encryption_VOIPonly. Acesta este Numele serviciului public, pe care îl putem modifica în viitor. Pentru numele actuale ale tipurilor de sesiuni, consultați ID-urile tipurilor de sesiune în secțiunea Referință din acest articol.

Nu este nimic ce trebuie să faceți pentru a obține această capacitate pentru site-ul dvs.; trebuie să acordați utilizatorilor noul tip de sesiune (numit și Privilegiu întâlnire). Puteți face acest lucru individual prin intermediul paginii de configurare a utilizatorului sau în bloc cu un export/import CSV.

Verificați noul tip de sesiune
1

Conectați-vă la Control Hub și accesați Servicii > Întâlnire.

2

Faceți clic pe Site-uri, alegeți site-ul Webex pentru care doriți să modificați setările, apoi faceți clic pe Setări.

3

În secțiunea Setări comune, selectați Tipuri de sesiune.

Trebuie să vedeți unul sau mai multe tipuri de sesiune cu criptare end-to-end. Consultați lista ID-urilor tipurilor de sesiune din secțiunea Referință din acest articol. De exemplu, este posibil să vedeți Pro-End to End Encryption_VOIPonly.

Există un tip de sesiune mai vechi, cu un nume foarte similar: Criptare pro-End to End. Acest tip de sesiune include acces PSTN necriptat la întâlniri. Asigurați-vă că aveți versiunea _VOIPonly pentru a asigura criptarea end-to-end. Puteți verifica trecând cu mouse-ul peste linkul PRO din coloana codului de sesiune; în acest exemplu, ținta linkului trebuie să fie javascript:ShowFeature(652).

În viitor, putem schimba numele serviciilor publice pentru aceste tipuri de sesiuni.

4

Dacă nu aveți încă noul tip de sesiune, contactați reprezentantul Webex.

Ce este de făcut în continuare

Activați acest tip de sesiune/privilegiu de întâlnire pentru unii sau pentru toți utilizatorii dvs.

Activați întâlnirile E2EE pentru utilizatori individuali
1

Conectați-vă la Control Hub și accesați Gestionare > Utilizatori.

2

Selectați un cont de utilizator pe care să-l actualizați, apoi selectați Întâlniri.

3

Din lista derulantă Setările se aplică , selectați site-ul întâlnirii pe care doriți să-l actualizați.

4

Bifați caseta de lângă Pro-End to End Encryption_VOIPonly.

5

Închideți panoul de configurare a utilizatorului.

6

Repetați pentru alți utilizatori, dacă este necesar.

Pentru a atribui acest lucru mai multor utilizatori, utilizați următoarea opțiune Activați întâlnirile E2EE pentru mai mulți utilizatori.

Activați întâlnirile E2EE pentru mai mulți utilizatori
1

Conectați-vă la Control Hub și accesați Servicii > Întâlnire.

2

Faceți clic pe Site-uri, alegeți site-ul Webex pentru care doriți să modificați setările.

3

În secțiunea Licențe și utilizatori , faceți clic pe Gestionați în bloc.

4

Faceți clic pe Generare raport și așteptați cât timp pregătim fișierul.

5

Când fișierul este gata, faceți clic pe Exportați rezultatele , apoi pe Descărcați. (Trebuie să închideți manual fereastra pop-up după ce faceți clic pe Descărcare.)

6

Deschideți fișierul CSV descărcat pentru editare.

Există un rând pentru fiecare utilizator, iar MeetingPrivilege coloana conține ID-urile tipului său de sesiune ca listă delimitată prin virgulă.

7

Pentru fiecare utilizator pentru care doriți să acordați noul tip de sesiune, adăugați 1561 ca valoare nouă în lista delimitate prin virgulă din MeetingPrivilege celulă.

Referința privind formatul fișierului CSV conține detalii despre scopul și conținutul fișierului CSV.

8

Deschideți panoul de configurare a site-ului de întâlniri din Control Hub.

Dacă ați fost deja pe pagina cu lista site-ului de întâlniri, poate fi necesar să o reîmprospătați.

9

În secțiunea Licențe și utilizatori , faceți clic pe Gestionați în bloc.

10

Faceți clic pe Importare și selectați fișierul CSV editat, apoi faceți clic pe Importare. Așteptați încărcarea fișierului.

11

Când importul este finalizat, puteți face clic pe Importați rezultatele pentru a verifica dacă au existat erori.

12

Accesați pagina Utilizatori și deschideți unul dintre utilizatori pentru a verifica dacă deține noul tip de sesiune.

Adăugați o inscripționare audio pentru securitate

Puteți adăuga o inscripționare la înregistrările întâlnirilor cu tipul de Webex Meetings Pro-End to End Encryption_VOIPonly sesiune, care vă permite să identificați clientul sursă sau dispozitivul sursă al înregistrărilor neautorizate ale întâlnirilor confidențiale.

Când această caracteristică este activată, transmisia audio a întâlnirii include un identificator unic pentru fiecare client sau dispozitiv participant. Puteți încărca înregistrări audio în Control Hub, care apoi analizează înregistrarea și caută identificatorii unici. Puteți să vă uitați la rezultate pentru a vedea ce client sau dispozitiv sursă a înregistrat întâlnirea.

  • Pentru a fi analizată, înregistrarea trebuie să fie un fișier AAC, MP3, M4A, WAV, MP4, AVI sau MOV care să nu depășească 500 MB.
  • Înregistrarea trebuie să aibă o durată mai mare de 100 de secunde.
  • Puteți analiza numai înregistrările pentru întâlnirile găzduite de persoane din organizația dvs.
  • Informațiile privind inscripționarea sunt păstrate pe aceeași durată ca și informațiile privind întâlnirea organizației.

Adăugați inscripționări audio la întâlnirile E2EE

  1. Conectați-vă la Control Hub, apoi în secțiunea Gestionare, selectați Setări organizație.
  2. În secțiunea Inscripționări pentru întâlnire , comutați pe Adăugați inscripționare audio.

    La puțin timp după activarea acesteia, utilizatorii care programează întâlniri cu Webex Meetings Pro-End to End Encryption_VOIPonly tipul de sesiune văd o opțiune Inscripționare digitală în secțiunea Securitate.

Încărcați și analizați o întâlnire inscripționată

  1. În Control Hub, sub Monitorizare, selectați Soluționarea problemelor.
  2. Faceți clic pe Analiză inscripționare.
  3. Căutați sau selectați întâlnirea din listă, apoi faceți clic pe Analizați.
  4. În fereastra Analizați inscripționarea audio , introduceți un nume pentru analiza dvs.
  5. (Opțional) Introduceți o notă pentru analiza dvs.
  6. Glisați și fixați fișierul audio pentru a fi analizat sau faceți clic pe Alegeți fișierul pentru a naviga la fișierul audio.
  7. Faceți clic pe Închideți.

    După finalizarea analizei, aceasta va fi afișată în lista de rezultate de pe pagina Analizați inscripționarea .

  8. Selectați întâlnirea din listă pentru a vedea rezultatele analizei. Faceți clic Buton descărcare pentru a descărca rezultatele.

Funcții și limitări

Factorii implicați în decodarea cu succes a unei inscripționări înregistrate includ distanța dintre dispozitivul de înregistrare și difuzorul care emite sunetul, volumul acelui sunet, zgomotul ambiental etc. Tehnologia noastră de inscripționare are o rezistență suplimentară la codificarea de mai multe ori, așa cum s-ar putea întâmpla atunci când media este partajată.

Această funcție este concepută pentru a permite decodarea cu succes a identificatorului de inscripționare într-un set larg, dar rezonabil de circumstanțe. Scopul nostru este ca un dispozitiv de înregistrare, cum ar fi un telefon mobil, care este situat pe un birou lângă un terminal personal sau un client de laptop, să creeze întotdeauna o înregistrare care să conducă la o analiză reușită. Pe măsură ce dispozitivul de înregistrare este deplasat departe de sursă sau nu aude întregul spectru audio, șansele unei analize reușite sunt reduse.

Pentru a analiza cu succes o înregistrare, este necesară o captură rezonabilă a transmisiei audio a întâlnirii. Dacă transmisia audio a unei întâlniri este înregistrată pe același computer care găzduiește clientul, limitările nu trebuie să se aplice.

Înregistrați dispozitivele (CA intern)

Dacă dispozitivele dvs. sunt deja integrate în organizația dvs. Control Hub și doriți să utilizați Webex CA pentru a genera automat certificatele lor de identificare, nu trebuie să resetați dispozitivele la setările din fabrică.

Această procedură selectează domeniul pe care dispozitivul îl utilizează pentru a se identifica și este necesară numai dacă aveți mai multe domenii în organizația dvs. Control Hub. Dacă aveți mai multe domenii, vă recomandăm să procedați astfel pentru toate dispozitivele care vor avea identitate „verificată de Cisco”. Dacă nu spuneți Webex ce domeniu identifică dispozitivul, se alege automat unul și este posibil ca acesta să pară greșit la alți participanți la întâlnire.

Înainte de a începe

Dacă dispozitivele dvs. nu sunt încă integrate, urmați Înregistrarea unui dispozitiv în Cisco Webex utilizând API sau interfața web locală sau Integrarea în cloud pentru seriile Board, Desk și Room. De asemenea, ar trebui să verificați domeniul/domeniile pe care doriți să le utilizați pentru a identifica dispozitivele din Gestionați domeniile.

1

Conectați-vă la Control Hub, iar în secțiunea Gestionare, selectați Dispozitive.

2

Selectați un dispozitiv pentru a-și deschide panoul de configurare.

3

Selectați domeniul pe care doriți să îl utilizați pentru a identifica acest dispozitiv.

4

Repetați pentru alte dispozitive.

Înregistrați dispozitivele (CA extern)

Înainte de a începe

  • Obțineți un certificat semnat de CA și o cheie privată, în .pem format, pentru fiecare dispozitiv.

  • În fila Pregătire , citiți subiectul Înțelegerea procesului de identitate externă pentru dispozitive,

  • Pregătiți un instrument de criptare JWE cu privire la informațiile de acolo.

  • Asigurați-vă că aveți un instrument pentru a genera secvențe de octeți aleatorii cu lungimi date.

  • ASIGURAȚI-VĂ CĂ AVEȚI UN INSTRUMENT PENTRU A BAZA ｟_ph_32｠ URL-UL DE CODIFICARE BYTES SAU TEXT.

  • Asigurați-vă că aveți o scrypt implementare.

  • Asigurați-vă că aveți câte un cuvânt sau o frază secretă pentru fiecare dispozitiv.

1

Populați dispozitivul ClientSecret cu un secret de text simplu:

Prima dată când populați Secret, îl furnizați în text simplu. De aceea, vă recomandăm să faceți acest lucru la consola dispozitivului fizic.

  1. URL-ul de bază64 codifică fraza secretă pentru acest dispozitiv.

  2. Deschideți TShell pe dispozitiv.

  3. Execută xcommand Security ClientSecret Populate Secret: "MDEyMzQ1Njc4OWFiY2RlZg"

    Comanda exemplu de mai sus populează Secret cu fraza 0123456789abcdef. Trebuie să o alegeți pe a dvs.

Dispozitivul are secretul său inițial. Nu uitați acest lucru; nu îl puteți recupera și trebuie să resetați dispozitivul la setările din fabrică pentru a începe din nou.
2

Concatenați certificatul și cheia privată:

  1. Folosind un editor de text, deschideți fișierele .pem, lipiți cheia blob blob-ul de certificat și salvați-l ca nou fișier .pem.

    Acesta este textul sarcinii utile pe care îl veți cripta și îl veți pune în blob-ul JWE.

3

Creați o blob JWE pe care să o utilizați ca intrare pentru comanda de adăugare a certificatului:

  1. Creați o secvență aleatorie de cel puțin 4 octeți. Aceasta este sarea ta.

  2. Extrageți o cheie de criptare a conținutului cu instrumentul dvs. de scriere.

    Pentru aceasta aveți nevoie de secretul, sarea și o lungime a cheilei pentru a se potrivi cifrului de criptare ales. Există alte valori fixe de furnizat (N=32768, r=8, p=1). Dispozitivul utilizează același proces și valori pentru a obține aceeași cheie de criptare a conținutului.

  3. Creați o secvență aleatorie de exact 12 biți. Acesta este vectorul dvs. de inițializare.

  4. Creați un antet, o setare alg, enc și cisco-kdf chei JOSE așa cum este descris în Înțelegerea procesului de identitate externă pentru dispozitive. Setați acțiunea „adăugare” utilizând cheia:valoarea "cisco-action":"add" din antetul JOSE (deoarece adăugăm certificatul la dispozitiv).

  5. URL-ul de bază64 codifică antetul JOSE.

  6. Utilizați instrumentul de criptare JWE cu cifrul ales și antetul JOSE codificat pe baza URL pentru a cripta textul din fișierul pem concatenat.

  7. URL-ul de bază 64 codifică vectorul de inițializare, sarcina utilă criptată PEM și eticheta de autentificare.

  8. Construiți blob-ul JWE după cum urmează (toate valorile sunt codificate URL-ul de bază260):

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4

Deschideți TShell pe dispozitiv și executați comanda de adăugare (multilinie): 

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

Verificați dacă certificatul este adăugat rulând xcommand Security Certificates Services Show

Copiați amprenta noului certificat.

6

Activați certificatul în scopul WebexIdentity:

  1. Citiți amprenta certificatului, fie din certificatul în sine, fie din rezultatul lui xcommand Security Certificates Services Show.

  2. Creați o secvență aleatorie de cel puțin 4 octeți și codificați URL-ul de bază260 acea secvență. Aceasta este sarea ta.

  3. Extrageți o cheie de criptare a conținutului cu instrumentul dvs. de scriere.

    Pentru aceasta aveți nevoie de secretul, sarea și o lungime a cheilei pentru a se potrivi cifrului de criptare ales. Există alte valori fixe de furnizat (N=32768, r=8, p=1). Dispozitivul utilizează același proces și valori pentru a obține aceeași cheie de criptare a conținutului.

  4. Creați o secvență aleatorie de exact 12 octeți, iar baza URL-ului de criptare codifică acea secvență. Acesta este vectorul dvs. de inițializare.

  5. Creați un antet, o setare alg, enc și cisco-kdf chei JOSE așa cum este descris în Înțelegerea procesului de identitate externă pentru dispozitive. Setați acțiunea „activare” utilizând cheia:valoarea "cisco-action":"activate" din antetul JOSE (deoarece activăm certificatul pe dispozitiv).

  6. URL-ul de bază64 codifică antetul JOSE.

  7. Utilizați instrumentul de criptare JWE cu cifrul ales și antetul JOSE codificat pe baza URL pentru a cripta amprenta certificatului.

    Instrumentul ar trebui să afișeze o secvență de 16 sau 32 de biți, în funcție de alegerea AES-GCM pe 128 sau 256 de biți și o etichetă de autentificare.

  8. Baza260 urlencode amprenta criptată și eticheta de autentificare.

  9. Construiți blob-ul JWE după cum urmează (toate valorile sunt codificate URL-ul de bază260):

    JOSEHeader..InitVector.EncryptedFingerprint.AuthTag

  10. Deschideți TShell pe dispozitiv și executați următoarea comandă de activare:

                      xcommand Security Certificates Services Activate Purpose: WebexIdentity Fingerprint: "Your..JWE.encrypted.fingerprint"

Dispozitivul are un certificat criptat, activ, emis de CA, gata de a fi utilizat pentru identificarea în întâlnirile Webex cu criptare integrală.
7

Integrați dispozitivul în organizația dvs. Control Hub.

Testați criptarea integrală cu verificarea identității
1

Programați o întâlnire de tipul corect (Webex Meetings Pro-End to End Encryption_VOIPonly).

Consultați Programați o întâlnire Webex cu criptare integrală.

2

Intrați în întâlnire ca gazdă, utilizând un client Webex Meetings.

Consultați Alăturați-vă unei întâlniri Webex cu criptare integrală.

3

Intrați în întâlnire de pe un dispozitiv care are identitatea verificată de Webex CA.

4

În calitate de gazdă, verificați dacă acest dispozitiv apare în sala de așteptare cu pictograma de identitate corectă.

Consultați Alăturați-vă unei întâlniri Webex cu criptare integrală.

5

Intrați în întâlnire de pe un dispozitiv care are identitatea verificată de o autoritate de certificare externă.

6

În calitate de gazdă, verificați dacă acest dispozitiv apare în sala de așteptare cu pictograma de identitate corectă. Aflați mai multe despre pictogramele de identitate.

7

Intrați în întâlnire ca participant neautentificat la întâlniri.

8

În calitate de gazdă, verificați dacă acest participant apare în sala de așteptare cu pictograma de identitate corectă.

9

În calitate de gazdă, permiteți sau respingeți persoane/dispozitive.

10

Validați identitatea participantului/dispozitivului, dacă este posibil, prin verificarea certificatelor.

11

Verificați dacă toate persoanele din întâlnire văd același cod de securitate al întâlnirii.

12

Intrați în întâlnire cu un participant nou.

13

Verificați dacă toată lumea vede același cod de securitate nou al întâlnirii.

Setați domeniul de aplicare și așteptările

  • Doriți să setați întâlnirile cu criptare integrală ca opțiune implicită pentru întâlnire sau să o activați numai pentru unii utilizatori sau să permiteți tuturor gazdelor să decidă? Când v-ați decis cum veți utiliza această funcție, pregătiți acei utilizatori care o vor utiliza, mai ales în ceea ce privește limitările și la ce să se aștepte în cadrul întâlnirii.

  • Trebuie să vă asigurați că nici Cisco, nici altcineva nu vă poate decripta conținutul și nu vă poate personaliza dispozitivele? Dacă da, aveți nevoie de certificate de la o autoritate de certificare publică.

  • Dacă aveți niveluri diferite de verificare a identității, autorizați utilizatorii să se verifice reciproc cu identitatea pe bază de certificat. Chiar dacă există circumstanțe în care participanții pot apărea ca neverificați, iar participanții ar trebui să știe cum să verifice, este posibil ca persoanele neverificate să nu fie impostori.

Gestionarea identității

Dacă utilizați o autoritate de certificare externă pentru a emite certificate de dispozitiv, sarcina dvs. este de a monitoriza, reîmprospăta și reaplica certificatele.

Dacă ați creat secretul inițial, înțelegeți că este posibil ca utilizatorii dvs. să vrea să schimbe secretul dispozitivului lor. Este posibil să fie necesar să creați o interfață/să distribuiți un instrument pentru a le permite să facă acest lucru.

ID-uri tip sesiune
Tabelul 1. ID-uri tip sesiune pentru întâlnirile cu criptare integrală

ID tip sesiune

Nume serviciu public

638

Criptare E2E+Numai VoIP

652

Pro-End Encryption_VOIPonly

660

Pro 3 Free-End to End Encryption_VOIPonly

Criptare E2E + identitate

672

Pro 3 Gratuit50-End to End Encryption_VOIPonly

673

Instructor pentru educație E2E Encryption_VOIPonly

676

Criptare integrală Broadworks Standard

677

Criptare integrală Broadworks Premium plus

681

Schoology Free plus criptare integrală

Comenzi xAPI asociate

Aceste tabele descriu comenzile API-ului dispozitivelor Webex pe care le-am adăugat pentru întâlnirile cu criptare integrală și identitatea verificată. Pentru mai multe informații despre modul de utilizare a API-ului, consultați Accesarea API-ului pentru dispozitivele Webex de cameră și birou și Webex Boards.

Aceste comenzi xAPI sunt disponibile numai pe dispozitivele care sunt:

  • Înscris în Webex

  • Înscris local și conectat la Webex cu Webex Edge for Devices

Tabelul 2. API-uri la nivel de sistem pentru întâlnirile cu criptare integrală și identitatea verificată

Apel API

Descriere

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

Această configurație se realizează atunci când administratorul setează domeniul preferat al dispozitivului din Control Hub. Necesar numai dacă organizația are mai multe domenii.

Dispozitivul utilizează acest domeniu atunci când solicită un certificat de la Webex CA. Domeniul identifică apoi dispozitivul.

Această configurație nu este aplicabilă atunci când dispozitivul are un certificat activ, emis la nivel extern, pentru a se identifica.

xStatus Conference EndToEndEncryption Availability

Indică dacă dispozitivul se poate alătura unei întâlniri cu criptare integrală. API-ul în cloud îl apelează, astfel încât o aplicație asociată să știe dacă poate utiliza dispozitivul pentru a intra.

xStatus Conference EndToEndEncryption ExternalIdentity Verification

Indică dacă dispozitivul utilizează External verificarea (are un certificat emis la nivel extern).

xStatus Conference EndToEndEncryption ExternalIdentity Identity

Identitatea dispozitivului, așa cum este citită din Numele comun al certificatului emis extern.

xStatus Conference EndToEndEncryption ExternalIdentity CertificateChain Certificate # specificinfo

Citește informații specifice dintr-un certificat emis extern.

În comanda afișată, înlocuiți # cu numărul certificatului. Înlocuiți specificinfo cu una dintre următoarele opțiuni:

  • Fingerprint

  • NotAfter Data de încheiere a valabilității

  • NotBefore Data de începere a valabilității

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

  • Subject # Name O listă a subiectelor pentru certificat (de exemplu, adresa de e-mail sau numele domeniului)

  • Validity Oferă starea de valabilitate a acestui certificat (de ex. valid sau expired)

xStatus Conference EndToEndEncryption ExternalIdentity Status

Starea identității externe a dispozitivului (de ex. valid sau error).

xStatus Conference EndToEndEncryption InternalIdentity Verification

Indică dacă dispozitivul are un certificat valid, eliberat de Webex CA.

xStatus Conference EndToEndEncryption InternalIdentity Identity

Identitatea dispozitivului, astfel cum este citită din Numele comun al certificatului emis de Webex.

Conține un nume de domeniu dacă organizația are un domeniu.

Este gol dacă organizația nu are un domeniu.

Dacă dispozitivul se află într-o organizație care are mai multe domenii, aceasta este valoarea din PreferredDomain.

xStatus Conference EndToEndEncryption InternalIdentity CertificateChain Certificate # specificinfo

Citește informații specifice din certificatul emis de Webex.

În comanda afișată, înlocuiți # cu numărul certificatului. Înlocuiți specificinfo cu una dintre următoarele opțiuni:

  • Fingerprint

  • NotAfter Data de încheiere a valabilității

  • NotBefore Data de începere a valabilității

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

  • Subject # Name O listă a subiectelor pentru certificat (de exemplu, adresa de e-mail sau numele domeniului)

  • Validity Oferă starea de valabilitate a acestui certificat (de ex. valid sau expired)

Tabelul 3. În API-urile de apel pentru întâlnirile cu criptare integrală și identitatea verificată

Apel API

Descriere

xEvent Conference ParticipantList ParticipantAdded

xEvent Conference ParticipantList ParticipantUpdated

xEvent Conference ParticipantList ParticipantDeleted

Aceste trei evenimente includ acum EndToEndEncryptionStatus, EndToEndEncryptionIdentity și EndToEndEncryptionCertInfo pentru participantul afectat.

Tabelul 4. API-uri corelate cu ClientSecret pentru întâlniri cu criptare integrală și identitate verificată

Apel API

Descriere

xCommand Security ClientSecret Populate Secret: "base64url-encoded"

sau

xCommand Security ClientSecret Populate Secret: JWEblob

Acceptă o valoare de text simplu codificată pe URL de bază, pentru însămânțarea secretului clientului pe dispozitiv pentru prima dată.

Pentru a actualiza secretul după acea primă dată, trebuie să furnizați o bulă JWE care conține noul secret criptat de vechiul secret.

xCommand Security Certificates Services Add JWEblob

Adaugă un certificat (cu cheie privată).

Am extins această comandă pentru a accepta un blob JWE care conține datele PEM criptate.

xCommand Security Certificates Services Activate Purpose:WebexIdentity FingerPrint: JWEblob

Activează un anumit certificat pentru WebexIdentity. Pentru aceasta Purpose, comanda necesită ca amprenta de identificare să fie criptată și serializată într-o blob JWE.

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

Dezactivează un anumit certificat pentru WebexIdentity. Pentru aceasta Purpose, comanda necesită ca amprenta de identificare să fie criptată și serializată într-o blob JWE.