Puteți detalia întâlnirile sau apelurile pentru fiecare participant și puteți vedea informații detaliate despre calitatea lor audio, video și partajarea. Datele sunt actualizate în fiecare minut pentru Webex Meetings și Call on Webex, astfel încât să puteți diagnostica problemele pe măsură ce apar. Datele pentru Webex Calling sunt actualizate la sfârșitul fiecărui apel.

Experiența utilizatorului

Utilizatorii aleg tipul de întâlnire atunci când programarea unei întâlniri. 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 aceștia îl pot utiliza pentru a se verifica reciproc.

Partajați următoarele informații gazdelor întâlnirii dvs.:

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

Utilizatorii aplicației Webex se autentifică în magazinul de identități 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, CA Webex le emite un certificat pe baza token-ului lor de acces. Momentan, nu oferim o modalitate pentru utilizatorii Webex Meetings de a obține un certificat emis de o terță parte/AC externă.

Dispozitivele se pot autentifica folosind un certificat emis de CA intern (Webex) sau un certificat emis de un CA extern:

  • CA intern – Webex emite un certificat intern pe baza token-ului de acces al contului automat al dispozitivului. Certificatul este semnat de CA Webex. Dispozitivele nu au ID-uri de utilizator în același mod ca și utilizatorii, așa că 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 acest lucru să garanteze criptarea end-to-end reală și identitatea verificată și pentru a preveni posibilitatea teoretică ca Cisco să vă asculte întâlnirea/decriptarea conținutului media.

Certificat dispozitiv emis intern

Webex emite un certificat către dispozitiv atunci când acesta 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 domeniu, CA Webex emite certificatul fără domeniu.

Dacă organizația dvs. are mai multe domenii, puteți utiliza Control Hub pentru a spune Webex ce domeniu va utiliza dispozitivul pentru identitatea acestuia. 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, atunci Webex alege unul pentru dvs.

Certificat dispozitiv emis extern

Un administrator poate asigura un dispozitiv cu propriul certificat care a fost semnat cu una dintre CA publice.

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

Valorile din certificat sunt la latitudinea organizației. Numele comun (CN) și numele alternativ al subiectului (SAN) vor fi afișate în interfață utilizator Întâlnire Webex , așa cum este descris în Criptare end-to-end cu verificarea identității pentru Webex Meetings .

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

Pentru a proteja pe deplin certificatul extern împotriva modificărilor, se utilizează o caracteristică secret client pentru a cripta și semna diferite xcommands.

Când se utilizează secretul clientului, este posibilă gestionarea în siguranță a certificatului de identitate Webex extern prin xAPI. Momentan, acesta este limitat la dispozitivele online.

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

Caracteristici și limitări

Dispozitive

Următoarele dispozitive din seria Webex Room și Webex Desk înregistrate în cloud pot participa la întâlniri criptate end-to-end:

  • Webex Board

  • Webex Desk Pro

  • Webex Desk

  • Webex Room Kit

  • Kit Webex Room Mini

Următoarele dispozitive nu pot participa la întâlniri criptate end-to-end:

  • Webex Seria C

  • Seria Webex DX

  • Seria Webex EX

  • Seria Webex MX

  • Dispozitive SIP de la terți

Clienți software

  • Începând cu versiunea 41.6, clientul desktop Webex Meetings poate participa la întâlniri criptate end-to-end.

  • Dacă organizația dvs. permite aplicația Webex să participe la întâlniri prin lansarea aplicației desktop Meetings, puteți utiliza această opțiune pentru a participa la întâlniri criptate end-to-end.

  • Clientul web Webex nu poate participa la întâlniri criptate end-to-end.

  • Clienții SIP terți nu pot participa la întâlniri criptate end-to-end.

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 dvs. trebuie să cunoașteți/accesați secretele și cheile. Dacă am introdus un serviciu cloud pentru gestionarea acestor chei, există șansa ca acestea să fie interceptate.

  • În prezent, vă oferim o „rețetă” prin care puteți să vă proiectați propriile instrumente, pe baza tehnicilor de criptare standard din industrie, pentru a vă ajuta la solicitarea sau criptarea certificatelor de identitate a dispozitivului și a cheilor private ale acestora. Nu dorim să avem acces real sau perceput la secretele sau cheile dvs.

Întâlniri

  • În prezent, întâlnirile criptate end-to-end acceptă maximum 200 de participanți.

  • Din cei 200 de participanți, se pot alătura maximum 25 de dispozitive verificate extern, iar aceștia trebuie să fie primii participanți care participă la întâlnire .

    Atunci când un număr mai mare de dispozitive intră într-o întâlnire, serviciile noastre media back-end încearcă să transcodeze fluxurile media. Dacă nu putem decripta, transcoda și recriptează mass-media (deoarece nu avem și nu ar trebui să avem cheile de criptare ale dispozitivelor), atunci transcodificarea eșuează.

    Pentru a reduce această limitare, vă recomandăm să întâlniți mai mici pentru dispozitive sau să eșalonați invitațiile între dispozitive și clienții Meetings.

Interfață de gestionare

Vă recomandăm cu insistență să utilizați Control Hub pentru a vă gestiona site-ul Meetingului, deoarece organizațiile Control Hub au identitate centralizată pentru întreaga organizație, în timp ce în Administrarea site-ului, identitatea este controlată site cu site.

Utilizatorii gestionați din Administrarea site-ului nu pot avea opțiunea de identitate verificată de Cisco. Acelor utilizatori li se eliberează un certificat anonim pentru a participa la o întâlnire criptată end-to-end și pot fi excluși din întâlnirile în care gazda dorește să asigure verificarea identității.

Resurse suplimentare

Informații conexe

Cerințe preliminare

  • Webex Meetings 41.7.

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

  • Acces administrativ la site- site de întâlnire în Control Hub, pentru a activa noul tip de sesiune pentru utilizatori.

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

  • Sălile de întâlnire de colaborare trebuie să fie activate, astfel încât utilizatorii să poată participa de pe sistemul lor video. Pentru mai multe informații, consultați Permite sistemelor video să participe la întâlniri și evenimente de pe site- Site Webex .

Obțineți certificate pentru 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 trebuie să aibă un certificat unic emis de o Autoritatea certificatului (CA) publică 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. Când solicitați certificatul, utilizați acești parametri:

  • Certificatul trebuie să fie emis și semnat de un CA public binecunoscut.

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

  • Denumire comună (NC) și denumire/nume alternativ(e) pentru subiect (SAN/denumiri): Acestea nu sunt importante pentru Webex, dar ar trebui să fie valori pe care oamenii le pot citi și asocia cu dispozitivul. CN va afișa celorlalți participanți la întâlnire ca identitate verificată principală a dispozitivului și, dacă utilizatorii inspectează certificatul prin interfața UI a întâlnirii, vor vedea SAN/-urile. Ați putea dori 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 Webex Identity.

  • Generare chei: Certificatele trebuie să se bazeze pe perechile de chei ECDSA P-256 (algoritmul de semnătură digitală cu curbă eliptică care utilizează curba P-256).

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

Pregătiți-vă pentru integrarea dispozitivelor

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

Dacă utilizați dispozitive noi, nu le înregistrați încă în Webex . Pentru 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 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ă când dispozitivele nu sunt utilizate sau utilizați o abordare treptată. 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 vă compromiteți securitatea.

După ce ați parcurs acești pași, permiteți sistemelor video să participe la întâlniri și evenimente de pe site- Site Webex .

Înțelegeți procesul identității externe pentru dispozitive

Pentru a vă asigura că dispozitivul dvs. media nu poate fi criptat de către nimeni, cu excepția dispozitivului, trebuie să criptați cheia privată a dispozitivului. 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 end-to-end reală prin cloud-ul nostru, nu putem fi implicați în criptarea și încărcarea certificatului și a cheii. Dacă aveți nevoie de acest nivel de securitate, trebuie să:

  1. Solicitați-vă 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 iniția capacitatea de criptare a dispozitivului.

  4. Dezvoltați și mențineți propriul instrument de criptare a 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 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ă la cerere de la Cisco .

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

  6. Încărcați blob-ul 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ță pentru (sau distribuiți) instrumentului dvs. pentru a le permite utilizatorilor dispozitivului să schimbe secretul inițial și să-și protejeze conținutul media față de dvs.

Cum utilizăm formatul JWE

Această secțiune descrie modul în care 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 Criptare Web JSON (JWE)https://datatracker.ietf.org/doc/html/rfc7516și Semnătură Web JSON (JWS)https://datatracker.ietf.org/doc/html/rfc7515.

Utilizăm Serializare 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 client inițial al 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 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 denumite după comenzile xAPI de pe dispozitivul pe care utilizați datele criptate.

      Noi i-am pus numele cisco-action pentru a atenua potențialele conflicte cu viitoarele extensii JWE.

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

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

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

  • Vector de inițializare JWE . Trebuie să furnizați un vector de inițializare codificat în base64url pentru decriptarea sarcinii utile. Secțiunea IV TREBUIE să fie o valoare aleatorie de 12 biți (utilizam familia de AES-GCM, care necesită ca IV-ul să aibă lungimea de 12 biți).

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

  • Text cifrat JWE : Acesta este volumul criptat pe care doriți să îl păstrați secret.

    Sarcina utilă POT 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. Diferitele comenzi xAPI așteaptă sarcini utile diferite și trebuie să specificați scopul sarcinii utile cu ajutorul fișierului cisco-action cheie, 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 (reprezentarea hexazecimală a lui sha-1) a certificatului pe care îl activăm pentru verificarea identității dispozitivului.

    • Cu „ "cisco-action":"deactivate" textul cifrat este amprenta (reprezentarea hexazecimală a lui sha-1) a certificatului pe care îl dezactivăm pentru a nu 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 serializat compact

Cum obținem cheie de criptare din ClientSecret

După prima populare a secretului, nu acceptăm sau nu scoatem secretul ca text simplu. Acest lucru este pentru a preveni potențialele atacuri din dicționar din partea unei persoane care ar putea accesa dispozitivul.

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

Acest lucru înseamnă pentru dvs. că instrumentul dvs. de producere a blob-urilor JWE trebuie să urmeze aceeași procedură pentru a obține aceeași cheie de criptare/decriptare din secretul clientului.

Dispozitivele utilizează criptați pentru derivarea cheii (a se vedeahttps://en.wikipedia.org/wiki/Scrypt ), cu următorii parametri:

  • CostFactor (N) este 32768

  • BlockSizeFactor (r) este 8

  • ParalelizationFactor (p) este 1

  • Salt este o secvență aleatorie de cel puțin 4 octeți; trebuie să furnizați același lucru salt la specificarea cisco-kdf parametru.

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

  • Capacitatea maximă a memoriei este de 64 MB

Acest set de parametri este singura configurație a criptați care este compatibil cu funcția de derivare a tastei de pe dispozitive. Acest kdf de pe dispozitive este apelat "version":"1", care este singura versiune utilizată în prezent de către cisco-kdf parametru.

Exemplu funcțional

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

Exemplul de scenariu este adăugarea unui blob PEM pe dispozitiv (imită adăugarea unui certificat, cu un șir foarte scurt în loc de un certificat complet + cheie). 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 Galois Counter). 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 hex) E5 E6 53 08 03 F8 33 F6. Base64url codifică secvența de a obține 5eZTCAP4M_Y(înlăturați căptușeala bază64).

  3. Iată un eșantion scrypt apel pentru a crea cheie 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ă aibă 16 biți (hex) după cum urmează: 95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac pe care o codifică base64url lZ66bdEiAQV4_mqdInj_rA.

  4. Alegeți o secvență aleatorie de 12 biți pentru a o utiliza ca vector de inițializare. Acest exemplu utilizează (hex) 34 b3 5d dd 5f 53 7b af 2d 92 95 83 pe care o codifică base64url NLNd3V9Te68tkpWD.

  5. Creați antetul JOSE cu serializare compactă (urmați aceeași ordine a parametrilor pe care o folosim aici) și apoi codați-l în base64url:

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

    Antetul JOSE codificat în 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 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ă criptate. Pentru acest exemplu, sarcina utilă necriptată va fi blob PEM fals 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

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

    Base64url codifică încărcarea criptată, ceea ce ar trebui să aibă ca rezultat f5lLVuWNfKfmzYCo1YJfODhQ

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

  9. Base64url 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-ul JWE.

  10. Concatenați cele cinci elemente ale blobului 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 base64url așa cum arătăm 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 de fapt nu va funcționa, dar, în principiu, următorul pas ar fi să utilizați blob-ul JWE pe care l-ați creat mai sus ca intrare la comanda x de pe dispozitivul care adaugă certificatul:

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

Există noi tipuri de sesiuni pentru întâlnirile cu încredere zero, care vor fi disponibile pentru toate site-urile de întâlniri fără costuri suplimentare. Se apelează unul dintre noile tipuri de sesiune Pro-End to End Encryption_VOIPonly. Acesta este Nume serviciu public pe care le putem schimba în viitor. Pentru denumirile curente ale tipurilor de sesiuni, consultați ID-uri tip sesiune în Referință secțiunea din acest articol.

Nu trebuie să faceți nimic pentru a obține noua capacitate pentru site-ul dvs., dar va trebui să acordați noul tip de sesiune (numit și Privilegiu întâlnire ) către utilizatori. Puteți face acest lucru individual prin pagină de configurare a utilizatorului sau în bloc printr-un export/import CSV .

Verificați noul tip de sesiune

1

Conectați-vă la Control Hub și deschideți Întâlnire pagina.

2

Faceți clic pe numele site-ului dvs. pentru a deschide panoul de configurare al site-ului.

3

Faceți clic pe Configurare site.

4

În Setări comune zonă, faceți clic Tipuri de sesiune .

Ar trebui să vedeți unul sau mai multe tipuri de sesiuni de criptare end-to-end. Consultați lista de ID-uri tip sesiune în Referință secțiunea din acest articol. De exemplu, este posibil să vedeți Pro-End to End Encryption_ Doar VOIP .

 

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_ Doar VOIP versiune pentru a asigura criptarea end-to-end. Puteți verifica prin plasarea cursorului peste PRO link în coloana cod sesiune; pentru acest exemplu, ținta linkului ar trebui să fie javascript:ShowFeature(652).

Este posibil să modificăm pe viitor Denumirile serviciului public pentru aceste tipuri de sesiuni.

5

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/privilegiul de întâlnire pentru unii sau pentru toți utilizatorii dvs.

Activați întâlnirile E2EE pentru utilizatorii individuali

1

Sub Management , faceți clic Utilizatori .

2

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

3

Selectați site-ul (dacă utilizatorul este în mai multe) și faceți clic Gazdă .

4

Bifați caseta de lângă Pro-End to End Encryption_ Doar VOIP .

5

Închideți panoul de configurație utilizator .

6

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

Pentru a aloca 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 , apoi sub Servicii , selectați Întâlnire .

2

Selectați site-ul dvs.

3

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

4

Faceți clic Export , și așteptați până când pregătim fișierul.

5

Când fișierul este gata, faceți clic Export rezultate şi apoi Descărcați . (Trebuie să închideți manual acea fereastră pop-up după ce faceți clic Descărcați .)

6

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

Există un rând pentru fiecare utilizator și MeetingPrivilege coloana conține ID-urile tipurilor de sesiune ale acestora sub formă de listă delimitată prin virgulă.

7

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

Elementul Referință pentru formatul fișierului CSV Webex conține detalii privind scopul și conținutul fișier CSV.

8

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


 

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

9

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

10

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

11

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

12

Accesați Utilizatori ș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 ajutorul butonului Webex Meetings Pro-end to End Encryption_ Doar VOIP tip sesiune, care vă permite să identificați cine a partajat înregistrarea în exterior.

Când această caracteristică este activată, transmisia audio a întâlnirii include un identificator unic pentru fiecare participant. Puteți încărca înregistrări audio în Control Hub, care apoi analizează înregistrarea și caută identificatori unici. Puteți examina rezultatele pentru a vedea ce participant a partajat conținutul întâlnirii în exterior.

  • Pentru a putea fi analizată, înregistrarea trebuie să fie un fișier AAC, MP3, M4A, WAV, MP4, AVI sau MOV de cel mult 500 MB.
  • Înregistrarea trebuie să dureze mai mult de 90 de secunde.
  • Puteți analiza numai înregistrările pentru întâlniri găzduite de persoane din organizația dvs.
  • Înregistrările analizate sunt șterse imediat ce analiza este finalizată.
Adăugați filigrane audio la întâlnirile E2EE
  1. Conectați-vă la Control Hub , apoi sub Management , selectați Setări organizație .
  2. În Filigrane întâlnire secțiune, comutați Adăugați filigran audio .
Încărcați și analizați o întâlnire cu filigran
  1. În Control Hub, sub Monitorizare , selectați Depanare .
  2. Faceți clic Analiză filigran .
  3. Căutați sau selectați întâlnirea din listă, apoi faceți clic Analizați fișierul .
  4. În Analizați filigranul audio fereastră, introduceți un nume pentru analiza dvs.
  5. (Opțional) Introduceți o notă pentru analiza dvs.
  6. Trageți și plasați fișierul audio de analizat sau faceți clic Alegeți fișierul pentru a parcurge fișierul audio.
  7. Faceți clic Închideți .

    Când analiza este finalizată, aceasta va fi afișată în lista de rezultate din Analizați filigranul pagina.

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

Dispozitive integrate (CA intern)

Dacă dispozitivele sunt deja integrate în organizația Control Hub și doriți să utilizați CA Webex pentru a genera automat certificatele de identificare ale acestora, nu este necesar să resetare la setările din fabrică .

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

Înainte de a începe

Dacă dispozitivele dvs. nu sunt încă integrate, urmați Înregistrați un dispozitiv în Cisco Webex utilizând API sau interfața Web locală sau Integrare în cloud pentru seria Board, Desk și Room . De asemenea, trebuie să verificați domeniul/domeniile pe care doriți să le utilizați pentru a identifica dispozitivele Gestionați-vă domeniile .

1

Conectați-vă la Control Hub , și sub Management , selectați Dispozitive .

2

Selectați un dispozitiv pentru a deschide panoul de configurare al acestuia.

3

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

4

Repetați pentru alte dispozitive.

Dispozitive integrate (CA extern)

Înainte de a începe

Aveți nevoie de:

  • Pentru a obține un certificat și o cheie privată semnate de CA, în .pem format, pentru fiecare dispozitiv.

  • Pentru a citi subiectul Înțelegerea procesului de identitate externă pentru dispozitive , în Pregătiți-vă parte a acestui articol.

  • Pentru a pregăti un instrument de criptare JWE cu privire la informațiile de acolo.

  • Un instrument pentru generarea de secvențe aleatoare de octeți de lungimi date.

  • Un instrument de codificare base64url pentru octeți sau text.

  • An scrypt implementare.

  • Un cuvânt sau o expresie secretă pentru fiecare dispozitiv.

1

Populați dispozitivul ClientSecret cu un secret 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 pe consola dispozitivului fizic.

  1. Base64url codifică expresia secretă pentru acest dispozitiv.

  2. Deschideți TShell pe dispozitiv.

  3. Rulare xcommand Security ClientSecret Populate Secret: "MDEyMzQ1Njc4OWFiY2RlZg"

    Exemplul de comandă de mai sus populează fișierul Secret cu sintagma 0123456789abcdef. Trebuie să vă alegeți pe cont propriu.

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 porni din nou.
2

Concatenați certificatul și cheia privată:

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

    (Acesta este textul sarcinii utile pe care îl veți cripta și îl veți introduce în blob-ul JWE)

3

Creați un blob JWE pe care îl utilizați ca intrare în comanda certificate add:

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

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

    Pentru aceasta, aveți nevoie de secretul, de sare și de o lungime a cheii care să corespundă cifrului de criptare ales. Există și alte valori fixe de furnizat (N=32768, r=8, p=1). Dispozitivul utilizează același proces și aceleaș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 JOSE, setare alg, enc și cisco-kdf tastele așa cum este descris în Înțelegerea procesului de identitate externă pentru dispozitive . Setați acțiunea „adăugare” utilizând cheia:valoare "cisco-action":"add" în antetul dvs. JOSE (deoarece adăugăm certificatul pe dispozitiv).

  5. Base64url codifică antetul JOSE.

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

  7. Base64url codifică vectorul de inițializare, încărcarea utilă PEM criptată și eticheta de autentificare.

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

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4

Deschideți TShell pe dispozitiv și rulați comanda (multilinie) add:

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

Verificați dacă certificatul este adăugat prin rulare xcommand Security Certificates Services Show

Copiați amprenta noului certificat.

6

Activați certificatul în acest scop WebexIdentity:

  1. Citiți amprenta certificatului, fie din certificatul propriu-zis, fie din rezultatul xcommand Security Certificates Services Show.

  2. Creați o secvență aleatorie de cel puțin 4 biți, iar base64url codifică secvența respectivă. Aceasta este sarea dumneavoastră.

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

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

  4. Creați o secvență aleatorie de exact 12 biți, iar base64url codifică secvența respectivă. Acesta este vectorul dvs. de inițializare.

  5. Creați un antet JOSE, setare alg, enc și cisco-kdf tastele așa cum este descris în Înțelegerea procesului de identitate externă pentru dispozitive . Setați acțiunea „activare” utilizând cheia:valoare "cisco-action":"activate" în antetul dvs. 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 în base64url pentru a cripta amprenta certificatului.

    Instrumentul ar trebui să scoată o secvență de 16 sau 32 de biți, în funcție de faptul că ați ales AES-GCM pe 128 sau 256 de biți și o etichetă de autentificare.

  8. Base64urlencode amprenta criptată și eticheta de autentificare.

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

    JOSEHeader..InitVector.EncryptedFingerprint.AuthTag

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

                      xcommand Security Certificates Services Activate Purpose: WebexIdentity Fingerprint: "Your..JWE.encrypted.fingerprint"
Dispozitivul are un certificat criptat, activ, eliberat de CA, gata pentru a fi utilizat pentru identificarea acestuia în întâlnirile Webex criptate end-to-end.
7

Integraț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 Meetings Pro-end to End Encryption_ Doar VOIP ).

Vedeți Programați o întâlnire Webex cu criptare end-to-end .

2

Participați la întâlnire ca gazdă, de la un client Webex Meetings .

Vedeți Participați la o întâlnire Webex cu criptare end-to-end .

3

Participați la întâlnire de pe un dispozitiv care are identitatea verificată de către Webex CA.

4

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

Vedeți Participați la o întâlnire Webex cu criptare end-to-end .

5

Participați la întâlnire de pe un dispozitiv care are identitatea verificată de un CA extern.

6

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

7

Participați la întâlnire ca participant neautentificat la întâlnire.

8

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

9

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

10

Validați identitățile participantului/dispozitivului dacă este posibil prin verificarea certificatelor.

11

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

12

Participați la întâlnire cu un nou participant.

13

Asigurați-vă că toată lumea văd același cod de securitate pentru întâlniri, noul.

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

Veți transforma întâlnirile criptate end-to-end în opțiunea implicită de întâlnire sau veți activa această opțiune numai pentru unii utilizatori sau veți permite tuturor gazdelor să decidă? După ce ați decis cum veți utiliza această caracteristică, pregătiți acei utilizatori care o vor utiliza, mai ales în ceea ce privește limitările și la ce să vă așteptați în întâlnire.

Trebuie să vă asigurați că nici Cisco , nici altcineva nu vă poate decripta conținutul sau uzurpa identitatea dispozitivelor dvs.? Dacă da, aveți nevoie de certificate de la un CA public. Este posibil să aveți doar până la 25 de dispozitive într-o întâlnire securizată. Dacă aveți nevoie de acest nivel de securitate, nu trebuie să permiteți clienților întâlnirilor să participe.

Pentru utilizatorii care se alătură cu dispozitive securizate, lăsați dispozitivele să se alăture primele și setați așteptările utilizatorilor ca aceștia să nu poată participa dacă se alătură târziu.

Dacă aveți diferite niveluri de verificare a identității, permiteți utilizatorilor să se verifice reciproc cu identitatea susținută de certificat și codul de securitate pentru întâlnire. Chiar dacă există circumstanțe în care participanții pot apărea ca Neverificați și participanții trebuie să știe cum să verifice, este posibil ca persoanele neverificate să nu fie niște impostori.

Managementul identității

Dacă utilizați un CA extern pentru a emite certificatele dispozitivului, vă revine sarcina de a monitoriza, reîmprospăta și aplica din nou certificatele.

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

ID-uri tip sesiune

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

ID tip sesiune

Nume serviciu public

638

Doar Criptare E2E+ VoIP

652

Pro-End to End Encryption_ Doar VOIP

660

Pro 3 Free-End-End Encryption_ Doar VOIP

Criptare E2E + identitate

672

Pro 3 Free50-End to End Encryption_ Doar VOIP

673

Instructor educație E2E Encryption_ Doar VOIP

676

Broadworks Standard plus criptare end-to-end

677

Broadworks Premium plus criptare end to end

681

Schoology Free plus criptare end to end

Comenzi xAPI conexe

Aceste tabele descriu comenzile API pentru dispozitivele 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, consultați Accesați API -ul pentru Webex Room și Desk și Webex Board .

Aceste comenzi xAPI sunt disponibile numai pe dispozitivele care sunt:

  • Înscris în Webex

  • Înscris în rețeaua corporatistă și conectat la Webex cu Webex Edge for Devices

Tabelul 2. API-uri la nivel de sistem pentru întâlniri criptate end-to-end și identitate 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. Este necesar doar dacă organizația are mai multe domenii.

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

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

xStatus Conference EndToEndEncryption Availability

Indică dacă dispozitivul poate participa la o întâlnire criptată end-to-end. API -ul cloud îl apelează astfel încât o aplicație asociată să știe dacă poate utiliza dispozitivul pentru a participa.

xStatus Conference EndToEndEncryption ExternalIdentity Verification

Indică dacă dispozitivul utilizează External verificare (are un certificat eliberat extern).

xStatus Conference EndToEndEncryption ExternalIdentity Identity

Identitatea dispozitivului, așa 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. Înlocuire specificinfo cu unul dintre:

  • Fingerprint

  • NotAfter Data de dată finalizare a valabilității

  • NotBefore dată de pornire valabilității

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

  • Subject # Name O listă cu subiectele pentru certificat (de exemplu, adresa de e-adresă de e-mail sau nume domeniu)

  • Validity Indică 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 valabil emis de CA Webex.

xStatus Conference EndToEndEncryption InternalIdentity Identity

Identitatea dispozitivului așa cum este citită din denumirea comună a certificatului emis de Webex.

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

Este necompletat 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. Înlocuire specificinfo cu unul dintre:

  • Fingerprint

  • NotAfter Data de dată finalizare a valabilității

  • NotBefore dată de pornire valabilității

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

  • Subject # Name O listă cu subiectele pentru certificat (de exemplu, adresa de e-adresă de e-mail sau nume domeniu)

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

Tabelul 3. API-uri în apel pentru întâlniri criptate end-to-end și identitate 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 legate de ClientSecret pentru întâlniri criptate end-to-end ș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ă în base64url pentru prima dată când secretul clientului este setat pe dispozitiv.

Pentru a actualiza secretul după prima dată, trebuie să furnizați un blob JWE care să conțină 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 certificat specific pentru WebexIdentity. Pentru aceasta Purpose, comanda necesită criptarea și serializarea amprentei de identificare într-un blob JWE.

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

Dezactivează un certificat specific pentru WebexIdentity. Pentru aceasta Purpose, comanda necesită criptarea și serializarea amprentei de identificare într-un blob JWE.