10 octombrie 2026 | 1115 vizualizare(ări) | 0 persoane au considerat că este util
Implementați întâlniri Zero-Trust
list-menuFeedback?
Securitatea Zero-Trust de la Webex oferă criptare end-to-end și verificare puternică a identității în întâlnirile dvs. programate și personale în sala de întâlnire.

Experiența utilizatorului

Utilizatorii aleg tipul de întâlnire atunci când programează o întâlnire. La admiterea participanților din hol, 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 folosi 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ă

Verifică 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 se alătură unui grup MLS partajat (Messaging Layer Security), aceștia își prezintă certificatele celorlalți membri ai grupului, care apoi validează certificatele în raport cu Autoritățile de Certificare (CA) emitente. Prin confirmarea valabilității certificatelor, CA verifică identitatea participanților, iar întâlnirea arată participanții/dispozitivele ca fiind verificate.

Utilizatorii aplicației Webex se autentifică împotriva magazinului de identitate Webex, care 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 bazat pe tokenul de acces. În acest moment, nu oferim Webex Meetings utilizatorilor o modalitate de a obține un certificat emis de o terță/externă CA.

Dispozitivele se pot autentifica utilizând un certificat emis de CA intern (Webex) sau un certificat emis de o autorizație externă:

  • CA internă — WebEx emite un certificat intern bazat pe simbolul de acces al contului de mașină al 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 identitatea certificatului dispozitivului (Nume comun (CN)).

  • CA externă — solicitați și achiziționați certificate de dispozitiv direct de la emitentul ales. Trebuie să criptați, să încărcați direct și să autorizați certificatele folosind un secret cunoscut numai de dvs.

    Cisco nu este implicat, ceea ce face ca aceasta să fie modalitatea de a garanta o adevărată criptare end-to-end și o identitate verificată și de a preveni posibilitatea teoretică ca Cisco să vă asculte întâlnirile/să decripteze suportul media.

Certificat de dispozitiv emis 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ă domeniu.

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

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

Certificat de dispozitiv emis extern

Un administrator poate furniza unui dispozitiv propriul certificat care a fost semnat cu unul dintre certificatele publice de certificare.

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 cu utilizatorul întâlnirii Webex, așa cum este descris în Crip tare end-to-end cu verificare identitate pentru Webex Meetings.

Vă recomandăm să utilizați un certificat separat pentru fiecare dispozitiv și să aveți un CN unic pe 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 manipulare, o caracteristică secretă a clientului este utilizată pentru a cripta și semna diverse xcomenzi.

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

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

Caracteristici și limitări

Dispozitive

Dispozitivele Cisco Board, Desk și Room Series înregistrate în cloud se pot alătura întâlnirilor E2EE.

Următoarele dispozitive nu se pot alătura întâlnirilor E2EE:

  • Dispozitive SIP terță parte

Clienți software

  • Aplicația Webex pentru clienții desktop și mobil se pot alătura întâlnirilor E2EE.

  • Clientul web Webex nu se poate alătura întâlnirilor E2EE.

  • Clienții soft SIP terți nu se pot alătura întâlnirilor E2EE.

Identitate

  • Prin proiectare, nu oferim opțiuni Control Hub pentru a gestiona identitatea dispozitivului verificată extern. Pentru o adevărată criptare end-to-end, numai tu ar trebui să știți/să accesezi secretele și cheile. Dacă am introdus un serviciu cloud pentru a gestiona acele chei, există șansa ca acestea să fie interceptate.

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

Întâlniri

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

  • Puteți partaja tablouri albe noi în întâlnirile E2EE. Există unele diferențe față de tablele albe în întâlnirile obișnuite:
    • În întâlnirile E2EE, utilizatorii nu pot accesa tablele albe create în afara întâlnirii, inclusiv tablele albe private, tablele albe partajate de alte persoane și tablele albe din spațiile Webex.
    • Tablele albe 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 adnotare, consultați Aplic ația Webex | Marcarea conținutului partajat cu adnotări.

Interfață de management

Vă recomandăm cu tărie să utilizați Control Hub pentru a gestiona site-ul Întâlniri, deoarece organizațiile Control Hub au identitate centralizată pentru întreaga organizație.

Resurse suplimentare
Cerințe preliminare

  • Webex Meetings41.7.

  • Dispozitive Cisco Board, Desk și Room Series înregistrate în cloud, care rulează 10.6.1- RoomOS_august_2021 sau o versiune ulterioară.

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

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

  • Colaborare Săli de întâlniri trebuie să fie activate, astfel încât utilizatorii să se poată alătura din sistemul lor video. Pentru mai multe informații, consultați Permit erea sistemelor video să se alăture întâlnirilor și evenimentelor de pe site-ul dvs. Webex.

Obțineți certificate de dispozitiv

Puteți sări peste 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 un public de încredere Certificate Authority (CA).

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

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

  • Unic: Vă recomandăm cu tărie să utilizați un certificat unic pentru fiecare dispozitiv. Dacă utilizați un singur certificat pentru toate dispozitivele, vă compromiteți securitatea.

  • Nume comun (CN) și Nume alternativ subiect (SAN/s): Acestea nu sunt importante pentru Webex, dar ar trebui să fie valori pe care oamenii le pot citi și asocia cu dispozitivul. CN se va afișa celorlalți participanți la întâlnire ca identitate verificată principală a dispozitivului, iar dacă utilizatorii inspectează certificatul prin interfața de utilizare 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 format .pem.

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

  • Generarea cheilor: Certificatele trebuie să se bazeze pe perechi de chei ECDSA P-256 (Algoritmul de semnătură digitală curbă eliptică utilizând curba P-256).

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

Pregătiți-vă pentru dispozitivele de bord

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

Dacă utilizați dispozitive noi, nu le înregistrați încă pe 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 actualizați pentru a utiliza identitate verificată extern, trebuie să resetați din fabrică dispozitivele.

  • 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 pe etape. 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, fiți conștienți de faptul că secretele călătoresc în text simplu și vă compromiteți securitatea.

După ce ați finalizat acești pași, permiteți sistemelor video să se alăture întâlnirilor și evenimentelor de pe site-ul dvs. Webex.

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

Pentru a vă asigura că suportul dispozitivului dvs. nu poate fi criptat 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, folosind JSON Web Encryption (JWE).

Pentru a asigura o adevărată criptare end-to-end prin cloud-ul nostru, nu putem fi implicați în criptarea și încărcarea certificatului și 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 propriul instrument pentru criptarea fișierelor folosind standardul JWE.

    Procesul și parametrii (non-secreți) de care veți avea nevoie sunt explicate mai jos, precum și o rețetă de urmat în instrumentele de dezvoltare alese. De asemenea, oferim câteva date de testare și blob-urile JWE rezultate așa cum le așteptăm, pentru a vă ajuta să vă verificați procesul.

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

  5. Concatenați și criptați certificatul și cheia folosind instrumentul dvs. și secretul inițial al dispozitivului.

  6. Încărcați blobul 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) instrumentul dvs. pentru a permite utilizatorilor dispozitivului să schimbe secretul inițial și să își protejeze suportul 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ă vă puteți construi propriul instrument pentru a crea blob-urile din certificatele și cheile dvs.

Consultați C riptarea web JSON (JWE) https://datatracker.ietf.org/doc/html/rfc7516 și Sem nătura web JSON (JWS) https://datatracker.ietf.org/doc/html/rfc7515.

Folosim serializarea compactă a unui document JSON pentru a crea blob-uri JWE. Parametrii pe care trebuie să îi includeți la crearea blob-urilor JWE sunt:

  • JOSE Antet (protejat). În antetul JSON Object Signing and Encryption, TREBUIE să includeți următoarele perechi cheie-valoare:

    • „alg” :"dir”

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

    • „enc”: „A128GCM” sau „enc”: „A256GCM”

      Susținem acești doi algoritmi de criptare.

    • „cisco-acțiune”: „adăugați” sau „cisco-acțiune”: „populați” sau „cisco-acțiune”: „activați” sau „cisco-acțiune”: „dezactivați”

      Aceasta este o cheie proprietară și patru valori pe care le poate lua. Am introdus această cheie pentru a semnala scopul datelor criptate către dispozitivul țintă. Valorile sunt numite după comenzile xAPI de pe dispozitivul pe care utilizați datele criptate.

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

    • „cisco-kdf”: {„version”: „1", „salt”: „base64UrlenCodeDrandom4+octeți”}

      O altă cheie proprietară. Folosim valorile pe care le furnizați ca intrări pentru derivarea cheii pe dispozitiv. Versiunea trebuie să fie 1 (versiunea funcției noastre de derivare a cheii). Valoarea să rii trebuie să fie o secvență codată cu adresa URL base64 de cel puțin 4 octeți, pe care trebuie să o alegeți aleatoriu.

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

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

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

  • JWE Ciphertext: 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 utile, în funcție de ceea ce încercați să faceți pe dispozitiv. Diferite comenzi xAPI se așteaptă la sarcini utile diferite și trebuie să specificați scopul sarcinii utile cu cheia cisco-action, după cum urmează:

    • Cu „cisco-action” :"populate” textul cifrat este noul ClientSecret.

    • Cu "„cisco-action” :"add” textul cifrat este un blob PEM care poartă certificatul și cheia sa privată (concatenată).

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

    • Cu "„cisco-action” :"dezactivați” textul cifrat este amprenta digitală (reprezentare hexazecimală a sha-1) a certificatului pe care îl dezactivăm pentru a fi utilizat pentru verificarea identității dispozitivului.

  • Etichetă de autentificare JWE: Acest câmp conține eticheta de autentificare pentru a stabili integritatea întregului blob JWE compact serializat

Cum obținem cheia de criptare din ClientSecret

După prima populație a secretului, nu acceptăm sau scoatem secretul ca text simplu. Acest lucru este pentru a preveni potențialele atacuri de dicționar de către cineva care ar putea accesa dispozitivul.

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

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

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

  • Cost Factor (N) este 32768

  • BlockSizeFactor (r) este 8

  • ParallelizationFactor (p) este 1

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

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

  • Capacul maxim de memorie este de 64 MB

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

Exemplu lucrat

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

Scenariul de exemplu este adăugarea unui blob PEM la dispozitiv (imită adăugarea unui certificat, cu un șir foarte scurt în loc de o cheie completă cert +). Secretul clientului din exemplu este ossifrage.

  1. Alegeți un cifru de criptare. Acest exemplu utilizează A128GCM (AES cu taste pe 128 de biți în modul Contor Galois). Instrumentul dvs. ar putea folosi 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ă (octeți hexagonal) E5 E6 53 08 03 F8 33 F 6. Base64URL codifică secvența pentru a obține 5eztcap4 m_y (eliminați căptușeala base64).

  3. Iată un exemplu de apel scrypt 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ă ar trebui să fie de 16 octeți (hex) după cum urmează: 95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac pe care base64url îl codifică la LZ66BDeiaqv4_mqdinj_ra.

  4. Alegeți o secvență aleatorie de 12 octeți pentru a utiliza ca vector de inițializare. Acest exemplu folosește (hex) 34 b3 5d dd 5f 53 7b af 2d 92 95 83 pe care base64url îl codifică la nLnd3v9te68tkpwd.

  5. Creați antetul JOSE cu serializare compactă (urmați aceeași ordine de parametri pe care îi folosim aici) și apoi base64url codificați-l:

    {"alg” :"dir”, "cisco-acțiune” :"add”, "cisco-kdf”: {"salt” :"5eztcap4M_y”, "versiune” :"1"}, "enc” :"A128GCM "}

    Antetul JOSE codificat base64url este EyjhbGcioIJkAxiiLcJjaXnJBY1hy3rpb24ioiJhzgqILcJjaXnjbY1rzGyionSiC2fsdCi6iJvLwLrdqVA0tV9ziiWIDmVyc2LvBii6iJEifsWiZw5jiJoiqTEyoeddTSj9

    Acesta va fi primul element al blob-ului 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 blob-ului JWE este vectorul de inițializare nLND3v9TE68tkpwd.

  8. Utilizați instrumentul dvs. de criptare JWE pentru a produce o sarcină utilă și o etichetă criptată. Pentru acest exemplu, sarcina utilă necriptată va fi blobul PEM fals, acesta este un fișier PEM

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

    • Sarcina utilă este acesta este un fișier PEM

    • Cifrul de criptare este AES 128 GCM

    • Antetul JOSE codificat base64url ca date autentificate suplimentare (AAD)

    Base64URL codifică sarcina utilă criptată, ceea ce ar trebui să ducă la F5llVUWNfkfmzyco1yjFODHQ

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

  9. Base64URL codifică eticheta pe care ați produs-o la pasul 8, ceea ce ar trebui să rezulte în PE-wdfwgxffbeo928cfz1q

    Acesta este al cincilea element din blobul JWE.

  10. Concatenați cele cinci elemente ale blob-ului JWE cu puncte (JoseHeader.. iv.CipherText.tag) pentru a obține:

    EYJhbgCIOIjkAxiiLcJjaXnjbY1hy3rpb24ioiJhzgQiLcJjaXnJbY1rZgYionSiC2fsdCi6iVLrdQVA0tV9ziiWIDmVyC2LvBiI6iJiIFsWiZw5jiJoiqTeyOeddTSj.. 9nLnd3v9TE68pWlLd.f5JiJoIQtEYoEDDtSj.. 9nLnd3v9TE68pWd.tKf5llLf5jIJoIQtEYoEDDtSj.. VUWNfkfmzyco1yjfodhq.pe-wdfwgxffbeo928cfz1q

  11. Dacă ați obținut aceleași valori codificate base64url așa cum arătăm aici, folosind propriile instrumente, sunteți gata să le utilizați pentru a asigura criptarea E2E și identitatea verificată a dispozitivelor dvs.

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

    Certificatele de securitate XCommand Adaugă eyJhbgCIoIJkAxiiLcJjaXnjby1HY3rpb24ioiJhzgQiLCJjaXnJBY1rzGYionsIC2fsdci6ijVLWLrdqVA0tV9ZiiWidMvYc2LvBii6iJEifswizw5JIjoiqTEyoeDdTsJ.. 9nLnLnd3v9Tk68TkJ.. pwd. f5llVUwNfkfmzyco1yjfodhq.pe-wdfwg xffbeo928cfz1q

Tipurile de sesiuni pentru întâlniri cu încredere zero 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 schimba în viitor. Pentru numele curente ale tipurilor de sesiune, consultați ID-urile tipului de sesiune din secțiunea Ref erință din acest articol.

Nu trebuie să faceți nimic pentru a obține această capacitate pentru site-ul dvs.; trebuie să acordați noul tip de sesiune (numit și privilegiu de întâlnire) utilizatorilor. Puteți face acest lucru individual prin pagina 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âln ire.

2

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

3

Sub Setări comune, selectați Tipuri de sesiune.

Ar trebui să vedeți unul sau mai multe tipuri de sesiuni de criptare end-to-end. Consultați lista ID-urilor de tip sesiune din secțiunea Ref erință a acestui articol. De exemplu, este posibil să vedeți Pro-End to End Encryp tion_VoipOnly.

Există un tip de sesiune mai vechi cu un nume foarte asemănător: Encryption Pro-End to End. Acest tip de sesiune include accesul PSTN necriptat la întâlniri. Asigurați-vă că aveți versiunea _VoipOnly pentru a asigura criptarea end-to-end. Puteți verifica plasând cursorul peste linkul PRO din coloana de cod de sesiune; pentru acest exemplu, ținta linkului ar trebui să fie JavaScript :showFeature (652).

Este posibil să modificăm numele serviciilor publice pentru aceste tipuri de sesiuni în viitor.

4

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

Ce să faci î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 utilizatorii individuali
1

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

2

Selectați un cont de utilizator de actualizat, apoi selectați Întâ lniri.

3

Din lista derul antă Setări se aplică la, selectați site-ul întâlnirii de actualizat.

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âln ire.

2

Faceți clic pe Sit e-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 Gestion are în bloc.

4

Faceți clic pe Generați raport și așteptați în timp ce pregătim fișierul.

5

Când fișierul este gata, faceți clic pe Export rezultate și apoi pe Descăr care. (Trebuie să închideți manual fereastra pop-up după ce faceți clic pe Descăr care.)

6

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

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

7

Pentru fiecare utilizator căruia doriți să acordați noul tip de sesiune, adăugați 1561 ca valoare nouă în lista delimitată prin virgulă din celula MeetingPrivilege.

Referința formatului de fișier CSV Webex conține detalii despre scopul și conținutul fișierului CSV.

8

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

Dacă vă aflați deja pe pagina de listă site de întâlniri, poate fi necesar să o reîmprospătați.

9

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

10

Faceți clic pe Import și selectați CSV-ul editat, apoi faceți clic pe Import. Așteptați până când fișierul este încărcat.

11

Când importul este terminat, puteți face clic pe Import rezultate pentru a examina dacă au existat erori.

12

Accesați pagina Utiliz atori și deschideți unul dintre utilizatori pentru a verifica dacă au noul tip de sesiune.

Adăugați un filigran audio pentru securitate

Puteți adăuga un filigran la înregistrările întâlnirilor cu tipul de sesiune Webex MeetingsPro-End to End Encryption_VoipOnly, care vă permite să identificați clientul sau dispozitivul sursă al înregistrărilor neautorizate ale întâlnirilor confidențiale.

Când această caracteristică este activată, sunetul î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 privi rezultatele pentru a vedea ce client sursă sau dispozitiv a înregistrat întâlnirea.

  • Pentru a fi analizată, înregistrarea trebuie să fie un fișier AAC, MP3, M4A, WAV, MP4, AVI sau MOV nu mai mare de 500 MB.
  • Înregistrarea trebuie să fie mai lungă de 100 de secunde.
  • Puteți analiza înregistrările numai pentru întâlnirile găzduite de persoane din organizație.
  • Informațiile filigranului sunt păstrate pe aceeași durată ca informațiile despre întâlnire ale organizației.

Adăugarea filigranelor audio la întâlnirile E2EE

  1. Conectați-vă la Control Hub, apoi sub Management, selectați Setări organizație.
  2. În secțiunea Filigran ele întâlni rii, comutați pe Adăugați filigran audio.

    La ceva timp după ce acest lucru este activat, utilizatorii care programează întâlniri cu tipul de sesiune Webex MeetingsPro-End to End Encryption_VoipOnly văd o opțiune Filigrare digitală în secțiunea Securitate.

Încărcarea și analizarea unei întâlniri cu filigran

  1. În Control Hub, sub Monitorizare, selectați Depan are.
  2. Faceți clic pe Analiza filigran ului.
  3. Căutați sau selectați întâlnirea din listă, apoi faceți clic pe Analiză.
  4. În fereastra Analizează filigran audio, introduceți un nume pentru analiză.
  5. (Opțional) Introduceți o notă pentru analiză.
  6. Trageți și fixați fișierul audio de analizat sau faceți clic pe Alegeți fișierul pentru a naviga la fișierul audio.
  7. Faceți clic pe Închid ere.

    Când analiza este completă, aceasta va fi afișată în lista de rezultate de pe pagina Analizați filigran ul.

  8. Selectați întâlnirea din listă pentru a vedea rezultatele analizei. Click Download button pentru a descărca rezultatele.

Caracteristici și limitări

Factorii implicați în decodarea cu succes a unui filigran înregistrat includ distanța dintre dispozitivul de înregistrare și difuzorul care scoate sunetul, volumul acelui sunet, zgomotul mediului etc. Tehnologia noastră de filigrare are o rezistență suplimentară la a fi codificată de mai multe ori, așa cum s-ar putea întâmpla atunci când suportul media este partajat.

Această caracteristică este concepută pentru a permite decodarea cu succes a identificatorului filigranului într-un set larg, dar rezonabil de circumstanțe. Scopul nostru este ca un dispozitiv de înregistrare, cum ar fi un telefon mobil, care se află pe un birou lângă un punct final personal sau un client laptop, să creeze întotdeauna o înregistrare care are ca rezultat o analiză de succes. Pe măsură ce dispozitivul de înregistrare este îndepărtat de sursă sau este ascuns de la auzirea întregului spectru audio, șansele unei analize reușite sunt reduse.

Pentru a analiza cu succes o înregistrare, este necesară o captare rezonabilă a sunetului întâlnirii. Dacă sunetul unei întâlniri este înregistrat pe același computer care găzduiește clientul, limitările nu ar trebui să se aplice.

Dispozitive la bord (CA internă)

Dacă dispozitivele dvs. sunt deja conectate la organizația dvs. Control Hub și doriți să utilizați CA Webex pentru a genera automat certificatele de identificare ale acestora, nu este necesar să resetați din fabrică dispozitivele.

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 Hub de control. Dacă aveți mai multe domenii, vă recomandăm să faceți acest lucru pentru toate dispozitivele dvs. care vor avea identitate „verificată Cisco”. Dacă nu spuneți Webex ce domeniu identifică dispozitivul, unul este ales automat și poate părea greșit pentru ceilalți participanți la întâlnire.

Înainte de a începe

Dacă dispozitivele dvs. nu sunt încă conectate, urmați În registrați un dispozitiv la Cisco Webex utilizarea API-ului sau interfeței web locale sau integr area în cloud pentru Board, Desk și Room Series. De asemenea, ar trebui să verificați domeniul/domeniile pe care doriți să le utilizați pentru a identifica dispozitivele din Ges tionați-vă domeniile.

1

Conectați-vă la Control Hub și, sub Gestionare, selectați Dis pozitive.

2

Selectați un dispozitiv pentru a 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.

Dispozitive la bord (CA externă)

Înainte de a începe

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

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

  • Pregătiți un instrument de criptare JWE în ceea ce privește informațiile de acolo.

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

  • Asigurați-vă că aveți un instrument pentru a codifica octeți sau text base64url.

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

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

1

Populați ClientSecret al dispozitivului cu un secret text simplu:

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

  1. Base64URL codifică fraza secretă pentru acest dispozitiv.

  2. Deschideți TShell de pe dispozitiv.

  3. Rulați xcommand Security ClientSecret Populate Secret: „MdeYmzq1Njc4owfiY2rlzg”

    Exemplul de comandă de mai sus populează Secre tul cu fraza 0 123456789abcdef. Trebuie să vă alegeți propriul.

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

Concatenați certificatul și cheia privată:

  1. Folosind un editor de text, deschideți fișierele.pem, lipiți blobul cheie în blobul de certificat și salvați-l ca un nou fișier.pem.

    Acesta este textul de încărcare utilă pe care îl veți cripta și pune în blobul JWE.

3

Creați un blob JWE pe care să îl utilizați ca intrare la comanda de adăugare a certificatului:

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

  2. Obțineți o cheie de criptare a conținutului cu instrumentul dvs. de scrypt.

    Pentru aceasta aveți nevoie de secret, sare și o lungime a cheii pentru a se potrivi cu cifrul 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 octeți. Acesta este vectorul dvs. de inițializare.

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

  5. Base64URL codifică antetul JOSE.

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

  7. Base64URL codifică vectorul de inițializare, sarcina utilă PEM criptată și eticheta de autentificare.

  8. Construiți blobul JWE după cum urmează (toate valorile sunt codificate base64url):

    JoseHeader.. initVector.encryptedPem.AuthTag

4

Deschideți TShell pe dispozitiv și executați comanda (multiline) add: 

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 ieșirea din xcommand Security Certificates Services Show.

  2. Creați o secvență aleatorie de cel puțin 4 octeți și base64url codificați acea secvență. Aceasta este sarea ta.

  3. Obțineți o cheie de criptare a conținutului cu instrumentul dvs. de scrypt.

    Pentru aceasta aveți nevoie de secret, sare și o lungime a cheii pentru a se potrivi cu cifrul 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 și base64url codificați acea secvență. Acesta este vectorul dvs. de inițializare.

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

  6. Base64URL codifică antetul JOSE.

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

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

  8. Base64URLEncodificați amprenta criptată și eticheta de autentificare.

  9. Construiți blobul JWE după cum urmează (toate valorile sunt codificate base64url):

    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 să fie utilizat pentru identificarea acestuia în întâlnirile Webex criptate end-to-end.
7

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

Testați criptarea end-to-end cu verificarea identității
1

Programați o întâlnire de tipul corect (Webex MeetingsPro-End to End Encryption_ VoipOnly).

Consultați Programarea unei întâlniri Webex cu criptare end-to-end.

2

Alăturați-vă întâlnirii ca gazdă, de la un Webex Meetings client.

Consultați Participarea la o întâlnire Webex cu criptare end-to-end.

3

Alăturați-vă întâlnirii de pe un dispozitiv a cărui identitate este verificată de Webex CA.

4

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

Consultați Participarea la o întâlnire Webex cu criptare end-to-end.

5

Alăturați-vă întâlnirii de pe un dispozitiv a cărui identitate este verificată de o autorizație externă.

6

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

7

Alăturați-vă întâlnirii ca participant la întâlniri neautentificat.

8

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

9

Ca gazdă, admiteți sau respingeți persoane/dispozitive.

10

Validați identitățile participanților/dispozitivului, acolo unde este posibil, verificând certificatele.

11

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

12

Alăturați-vă întâlnirii cu un nou participant.

13

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

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

  • Aveți de gând să faceți întâlnirile criptate end-to-end opțiunea implicită de întâlnire sau să o activați doar pentru unii utilizatori sau să permiteți tuturor gazdelor să decidă? Când ați decis cum veți utiliza această caracteristică, pregătiți acei utilizatori care o vor folosi, în special în ceea ce privește limitările și la ce să vă așteptați la întâlnire.

  • Trebuie să vă asigurați că nici Cisco, nici altcineva nu vă pot decripta conținutul sau impersona dispozitivele dvs.? Dacă da, aveți nevoie de certificate de la o CA publică.

  • Dacă aveți diferite niveluri de verificare a identității, permiteți utilizatorilor să se verifice reciproc cu o identitate susținută de certificat. Chiar dacă există circumstanțe în care participanții pot apărea ca neverificați și participanții ar trebui să știe cum să verifice, este posibil ca persoanele neverificate să nu fie impostori.

Managementul identității

Dacă utilizați o autorizație externă pentru a emite certificatele dispozitivului, este responsabilitatea de a monitoriza, reîmprospăta și aplica din nou certificatele.

Dacă ați creat secretul inițial, înțelegeți că utilizatorii dvs. ar putea dori să schimbe secretul dispozitivului lor. Poate fi necesar să creați o interfață/distribuiți un instrument pentru a le permite să facă acest lucru.

ID-uri tip sesiune
Tabelul 1. ID-uri tip sesiune pentru întâlniri criptate end-to-end

ID-ul tipului de sesiune

Denumirea serviciului public

638

Criptare E2E+numai VoIP

652

Encryption Pro-End to End Encryption_VoipOnly

660

Criptare Pro 3 de la capăt la sfârșit de la capăt la altul _VoipOnly

Criptare E2E+Identitate

672

Pro 3 Free50-Encriptare de la capăt la sfârşit_VoipOnly

673

Instructor de educație E2E Encryption_VoipOnly

676

Broadworks Standard plus criptare de la capăt la altul

677

Broadworks Premium plus criptare de la capăt la altul

681

Schoology Free plus criptare de la capăt la capăt

Comenzi XAPI conexe

Aceste tabele descriu comenzile API ale dispozitivelor Webex pe care le-am adăugat pentru întâlniri criptate end-to-end și identitate verificată. Pentru mai multe informații despre modul de utilizare a API-ului, consultați Accesarea API-ului pentru dispozitivele Board, Desk și Room Series.

Aceste comenzi xAPI sunt disponibile numai pe dispozitivele care sunt:

  • Înregistrat la Webex

  • Înregistrat local și conectat la Webex cu Webex Edge pentru dispozitive

Tabelul 2. API-uri la nivel de sistem pentru întâlniri criptate end-to-end și identitate verificată

Apel API

Descriere

Conferința XConfiguration EndToEndEncryption Identity PreferredDomain: „example.com”

Această configurație se face atunci când administratorul setează domeniul preferat al dispozitivului din Control Hub. Este 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 extern, pentru a se identifica.

Disponibilitatea Conferinței XStatus EndToEndEncryption

Indică dacă dispozitivul se poate alătura unei întâlniri criptate end-to-end. API-ul cloud îl apelează astfel încât o aplicație asociată să știe dacă poate folosi dispozitivul pentru a se alătura.

Conferința XStatus EndToEndEncryption ExternalIdentity Verification

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

Conferința XStatus EndToEndEncryption ExternalIdentity Identity

Identitatea dispozitivului, astfel cum este citită din Denumirea comună a 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 unul dintre:

  • amprentă

  • NotAfter Data de încheiere a valabilității

  • NotÎnainte de data înce perii valabilității

  • Nume primar

  • Algoritm cheie publică

  • Număr de serie

  • Algoritm de semnătură

  • Su biect # Nume O listă a subiecților pentru certificat (de exemplu, adresa de e-mail sau numele domeniului)

  • Valabilitate Oferă statutul de valabilitate al acestui certificat (de exemplu, valabil sau expirat)

Starea Conferinței XStatus EndEncryption ExternalIdentity Status

Starea identității externe a dispozitivului (de exemplu, validă sau eroare).

Conferința XStatus EndToEndEncryption InternalIdentity Verification

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

Conferința XStatus EndToEndEncryption InternalIdentity Identity

Identitatea dispozitivului, așa 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 CertificateCertificate Chain # 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 unul dintre:

  • amprentă

  • NotAfter Data de încheiere a valabilității

  • NotÎnainte de data înce perii valabilității

  • Nume primar

  • Algoritm cheie publică

  • Număr de serie

  • Algoritm de semnătură

  • Su biect # Nume O listă a subiecților pentru certificat (de exemplu, adresa de e-mail sau numele domeniului)

  • Valabilitate Oferă statutul de valabilitate al acestui certificat (de exemplu, valabil sau expirat)

Tabelul 3. API-uri în apel pentru întâlniri criptate end-to-end și identitate verificată

Apel API

Descriere

Participanții la conferință xEventLista participanțilorAdăugat

Participanți la conferință XEventLista participanțilorActualizat

Participanți la conferință xEventLista participanțilorȘterse

Aceste trei evenimente includ acum EndToEndenCryptionStatus, EndToEndenCryptionIdentity și EndToEndenCryption Cert Info pentru participantul afectat.

Tabelul 4. API-uri legate de ClientSecret pentru întâlniri criptate end-to-end și identitate verificată

Apel API

Descriere

XCommand Security ClientSecret Populate Secret: „codat base64url”

sau

Secretul de populare a ClientSecretului de securitate XCommand: JWeBlob

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

Pentru a actualiza secretul după prima dată, trebuie să furnizați un blob JWE care conține noul secret criptat de vechiul secret.

Servicii de certificate de securitate XCommand Adăugați JWEblob

Adaugă un certificat (cu cheie privată).

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

Servicii de certificate de securitate XCommand Activare Scopul: WebExIdentity FingerPrint: JWEblob

Activează un certificat specific pentru WebExIdentity. În acest scop, comanda necesită ca amprenta de identificare să fie criptată și serializată într-un blob JWE.

Servicii de dezactivare a certificatelor de securitate XCommand Scopul: WebExIdentity FingerPrint: JWEblob

Dezactivează un certificat specific pentru WebExIdentity. În acest scop, comanda necesită ca amprenta de identificare să fie criptată și serializată într-un blob JWE.

A fost util acest articol?
A fost util acest articol?
PrețuriAplicația WebexMeetingsCallingMesageriePartajare ecran
Webex SuiteCallingMeetingsMesagerieSlidoSeminare webEventsContact CenterCPaaSSecuritateControl Hub
CăștiCamereSeria DeskSeria RoomSeria BoardSeria PhoneAccesorii
EducațieAsistență medicalăGuvernFinanțeSport și divertismentPrima linieNonprofitStart-upuriActivitate hibridă
DescărcăriIntrați într-o întâlnire de probăCursuri onlineIntegrăriAccesibilitateIncluzivitateSeminare web live și la cerereComunitate WebexDezvoltatori WebexNoutăți și inovație
CiscoContactați asistențaContactați departamentul de vânzăriWebex BlogSpirit inovator WebexMagazin produse WebexCariere
  • X
  • LinkedIn
  • Facebook
  • Youtube
  • Instagram
Clauze și condițiiDeclarație de confidențialitateModule cookieMărci comerciale
©2026 Cisco și/sau afiliații săi. Toate drepturile rezervate.
Clauze și condițiiDeclarație de confidențialitateModule cookieMărci comerciale