Utilizatorii aleg noul tip de întâlnire atunci când programează o întâlnire. La admiterea participanților din lobby ș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 se verifica reciproc.

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

Verificarea identității

Verificarea identității integrale oferă securitate suplimentară unei întâlniri criptate integral.

Atunci când participanții sau dispozitivele se alătură unui grup MLS (Messaging Layer Security) partajat, aceștia își prezintă certificatele celorlalți membri ai grupului care apoi validează certificatele împotriva autorității/autorității de certificare emitente (CA). Prin confirmarea validității certificatelor, CA verifică identitatea participanților, iar întâlnirea arată participanții / dispozitivele ca fiind verificate.

Utilizatorii aplicației Webex Meetings se autentifică împotriva magazinului de identitate Webex care le emite un simbol de acces atunci când reușesc. Dacă au nevoie de un certificat pentru a-și verifica identitatea - într-o întâlnire criptată integral - CA Webex le eliberează un certificat bazat pe simbolul lor de acces. Nu oferim încă o modalitate prin care utilizatorii Webex Meetings să obțină un certificat emis de un CA terț/extern.

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

  • Pentru cazul 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) domeniul (ele) organizației (vostru) atunci când scrieți identitatea certificatului de dispozitiv [Nume comun (CN)].

  • Pentru cazul 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 utilizând un secret cunoscut numai de dvs.

    Cisco nu este implicat, ceea ce face ca acest lucru să garanteze criptarea adevărată end-to-end și identitatea verificată și să prevină posibilitatea teoretică ca Cisco să vă intercepteze întâlnirea / să vă decripteze mass-media.

Certificat de dispozitiv eliberat intern

Webex eliberează un certificat pe dispozitiv 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 nu are un domeniu, CA Webex emite certificatul fără un domeniu.

Dacă organizația 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-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 de dispozitiv emis extern

Un administrator poate furniza un dispozitiv cu propriul certificat care a fost semnat cu unul dintre autoritățile case 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 cu utilizatorul a întâlnirii Webex, așa este descris în Criptare end-to-end cu verificarea identității pentru Webex Meetings.

Se recomandă utilizarea unui certificat separat pentru fiecare dispozitiv și de a avea un CN unic pentru fiecare dispozitiv. Acest lucru ar putea fi, de exemplu, "meeting-room-1.example.com", pentru organizația care deține domeniul "example.com".

Pentru a proteja complet certificatul extern împotriva manipulării frauduloase, o caracteristică secretă client este utilizată pentru a cripta și semna diverse xcommands.

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

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

Dispozitive

Seriile Webex Room înregistrate în cloud și dispozitivele din seria Webex Desk se pot asocia la întâlniri criptate integral, inclusiv:

  • Webex Board

  • Webex Desk Pro

  • Webex Desk

  • Webex Room Kit

  • Kit Webex Room Mini

Următoarele dispozitive nu se pot asocia la întâlniri criptate de la un capăt la altul:

  • Seria Webex C

  • Seria Webex DX

  • Seria Webex EX

  • Seria Webex MX

  • Dispozitive SIP de la terți

Clienți software

  • Începând cu 41.7, clientul desktop Webex Meetings se poate alătura întâlnirilor criptate integral.

  • Aplicația Webex nu se poate asocia la întâlniri criptate integral.

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

  • Clientul web Webex nu se poate asocia la întâlniri criptate integral.

  • Clienții soft SIP terți nu se pot alătura întâlnirilor criptate end-to-end.

Identitate

  • Nu vă oferim nicio opțiune control hub pentru a gestiona identitatea verificată extern a dispozitivului. Această decizie este prin design, deoarece pentru criptarea adevărată end-to-end, numai tu ar trebui să cunoască / acces la secretele și cheile. Dacă am introdus un serviciu cloud pentru a gestiona aceste chei, există o șansă ca acestea să fie interceptate.

  • În prezent, nu oferim niciun instrument care să vă ajute să solicitați sau să criptați certificatele de identitate ale dispozitivului și cheile lor private. În prezent, vă oferim o "rețetă" pentru a vă proiecta propriile instrumente, pe baza tehnicilor de criptare standard în industrie, pentru a vă ajuta cu aceste procese. Nu vrem să avem acces real sau perceput la secretele sau cheile tale.

Întâlniri

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

  • Dintre cei 200 de participanți, se pot alătura maximum 25 de dispozitive verificate extern și trebuie să fie primii participanți care se alătură întâlnirii.

    Atunci când un număr mai mare de dispozitive se alătură unei întâlniri, serviciile noastre media backend încearcă să transcodeze fluxurile media. Dacă nu putem decripta, transcoda și recripta suportul media (deoarece nu avem și nu ar trebui să avem cheile de criptare ale dispozitivelor), atunci transcodarea nu reușește.

    Pentru a atenua această limitare, vă recomandăm întâlniri mai mici pentru dispozitive sau eșalonarea invitațiilor între dispozitive și clienții Întâlniri.

Interfața de gestionare

Vă recomandăm să utilizați Control Hub pentru a gestiona site-ul întâlnirii.

Principalul motiv pentru aceasta este diferența dintre modul în care Control Hub și Administrarea site-ului gestionează identitatea. Organizațiile Control Hub au identitate centralizată pentru întreaga organizație, în timp ce în Administrarea site-ului identitatea este controlată pe site în funcție de site.

Aceasta înseamnă că nu puteți avea opțiunea de identitate verificată Cisco pentru utilizatorii care sunt gestionați din Administrarea site-ului. Acestor utilizatori li se eliberează un certificat anonim pentru a se asocia la o întâlnire criptată end-to-end și pot fi excluși din întâlnirile în care gazda dorește să asigure identitatea.

Informații conexe

Derivând proba JWE blobs

Eșantion de JWE criptat corect pe baza parametrilor dați (apendice)

  • 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-ul întâlnirii din Control Hub, pentru a activa noul tip de sesiune pentru utilizatori.

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

Puteți sări peste acest pas dacă nu aveți nevoie de identitate verificată 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 de încredere.

Trebuie să interacționați cu CA pentru a solicita, a achiziționa și a primi certificatele digitale și a crea cheile private asociate. La solicitarea certificatului, aceștia sunt parametrii de utilizat:

  • Certificatul trebuie să fie eliberat și semnat de un cunoscut CA public.

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

  • Denumirea comună (CN) și denumirea/denumirile alternative ale subiectului (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 va arăta altor participanți la întâlnire ca identitatea verificată principală a dispozitivului, iar dacă utilizatorii inspectează certificatul prin interfața cu utilizatorul a întâlnirii, vor vedea SAN/san-urile. S-ar putea să doriți să utilizați nume precum: name.model@example.com dar este alegerea ta.

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

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

  • Generatoare de chei: Certificatele trebuie să se bazeze pe perechile de chei ECDSA P-256 (Algoritmul de semnătură digitală a curbei eliptice utilizând curba P-256).

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

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. Este cel mai sigur să nu le conectați încă la rețea.

Dacă aveți dispozitive existente pe care doriți să le actualizați pentru a utiliza identitatea verificată extern, va trebui 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 etapizată. Anunțați utilizatorii cu privire la modificările la care se pot aștepta.

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

Pentru a vă asigura că suportul de pe dispozitiv 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, utilizând JSON Web Encryption (JWE).

Pentru a asigura criptarea integrală 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, rentabilitatea este de a:

  • Solicitați-vă certificatele.

  • Generați perechile de chei ale certificatelor.

  • Creați (și protejați) un secret inițial pentru fiecare dispozitiv, pentru a însămânța capacitatea de criptare a dispozitivului.

  • Dezvoltați și întrețineți propriul instrument pentru criptarea fișierelor utilizând standardul JWE.

    Mai jos vă explicăm procesul și parametrii (non-secreti) de care veți avea nevoie și o rețetă de urmat în instrumentele de dezvoltare alese. De asemenea, oferim unele date de testare și blob-urile JWE rezultate așa le așteptăm, pentru a vă ajuta să vă verificați procesul.

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

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

  • Încărcați blobul JWE rezultat pe dispozitiv.

  • Setați scopul certificatului criptat pentru a fi utilizat pentru identitatea Webex și activați certificatul.

  • (Recomandat) Furnizați o interfață pentru (sau distribuiți) instrumentul pentru a permite utilizatorilor dispozitivului să schimbe secretul inițial (pentru a-și proteja mass-media de dvs.!).

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 blob-urile din certificatele și cheile dvs.

Va trebui să 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.

Am ales să folosim serializarea compactă a unui document JSON pentru a crea bloburi JWE. Parametrii pe care va trebui să îi includeți la crearea bloburilor JWE sunt:

  • Antet JOSE (protejat). În antetul JSON semnarea obiectului și criptare, 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 inițial al clientului dispozitivului.

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

      Susținem 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 de proprietate și patru valori se poate lua. Am introdus această cheie pentru a semnala scopul datelor criptate pe dispozitivul țintă. Valorile sunt denumite după comenzile xAPI de pe dispozitivul 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 de proprietate. Folosim valorile pe care le furnizați ca intrări pentru derivarea cheilor pe dispozitiv. Cel version Trebuie 1(versiunea funcției noastre cheie de derivare). Valoarea salt trebuie să fie o secvență codificată URL de bază64 de cel puțin 4 octeți, pe care trebuie să o alegeți aleatoriu.

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

  • JWE Initialization Vector. Trebuie să furnizați un vector de inițializare codat base64url pentru decriptarea sarcinii utile. IV TREBUIE să fie o valoare aleatoare de 12 octeți (folosim familia de cifru 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ă.

  • JWECiphertext: 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 cisco-action cheie, după 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 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 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 stabili integritatea întregului Blob serializat compact JWE

obținem cheia de criptare din ClientSecret

După prima populație a secretului, nu acceptăm și nu scoatem secretul ca text simplu. Acest lucru este pentru a preveni potențialele atacuri din dicționar ale cuiva care ar putea accesa dispozitivul.

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

Ce înseamnă acest lucru pentru tine este că instrumentul pentru 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 cheilor (a se vedea https://en.wikipedia.org/wiki/Scrypt), cu următorii parametri:

  • CostFactor (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 același lucru salt atunci când se specifică cisco-kdf parametru.

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

  • Capacul maxim de memorie este de 64MB

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

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.

Scenariul 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 + cheie). Secretul clientului în exemplu este ossifrage.

  1. Alegeți un cifru de criptare. Acest exemplu utilizează A128GCM(AES cu taste de 128 de biți în modul Galois Counter). Instrumentul 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 codifica secvența pentru a obține 5eZTCAP4M_Y(scoateți umplutura base64).

  3. Aici este un eșantion 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 octeți (hex) după urmează: 95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac care base64url codifică la lZ66bdEiAQV4_mqdInj_rA.

  4. Selectați o secvență aleatoare de 12 octeți de utilizat ca vector de inițializare. Acest exemplu utilizează (hex) 34 b3 5d dd 5f 53 7b af 2d 92 95 83 care base64url codifică la NLNd3V9Te68tkpWD.

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

    {"alg":"dir","cisco-action":"add","cisco-kdf":{"salt":"5eZTCAP4M_Y","version":"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 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ă. Pentru acest exemplu, sarcina utilă necriptată va fi blobul FALS PEM 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 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) în blob JWE.

  9. Base64url codifică eticheta pe care ați produs-o la pasul 8, ceea ce ar trebui să ducă la PE-wDFWGXFFBeo928cfZ1Q

    Acesta este al cincilea element din blob JWE.

  10. Concatenează 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 pe care le 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 nu va funcționa de fapt, dar, în principiu, următorul pas ar fi să utilizați blobul JWE pe care l-ați creat mai sus ca intrare la xcommandul 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 pe care le lansăm pe toate site-urile de întâlniri fără costuri suplimentare. Unul dintre noile 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 sesiuni, consultați ID-urile tip sesiune din secțiunea Referință din acest articol.

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

1

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

2

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

3

Faceți clic pe Configurare site.

4

În zona Setări comune, faceți clic pe Tipuri de sesiuni.

Pe acea pagină ar trebui să vedeți unul sau mai multe tipuri de sesiuni de criptare end-to-end. Consultați lista de ID-uri de tip sesiune din secțiunea Referință a acestui 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 la sfârșit. Acest tip de sesiune include acces PSTN necriptat la întâlniri. Asigurați-vă că aveți versiunea _VOIPonly pentru a asigura criptarea de la un capăt la altul. Puteți verifica trecând peste linkul PRO din coloana cu codul sesiunii; pentru acest exemplu, ținta link-ului ar trebui să fie javascript:ShowFeature(652).

Este posibil să schimbăm numele serviciului public pentru aceste tipuri de sesiuni în viitor, de exemplu, intenționăm să schimbăm Pro-End to End Encryption_VOIPonly în Criptare E2E + Identitate.

5

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

Ce trebuie să faceți în continuare

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

1

Faceți clic pe Utilizatori și selectați un utilizator pentru a deschide panoul de configurare al utilizatorului.

2

În zona Servicii, faceți clic pe Cisco Webex Meetings.

3

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

4

Bifați caseta de lângă intrarea Webex Meetings etichetată Pro-End to End Encryption_VOIPonly.

5

Închideți panoul de configurare a utilizatorului.

6

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

Dacă doriți să atribuiți acest lucru mai multor utilizatori, utilizați opțiunea în bloc CSV.

1

Conectați-vă la Control Hub https://admin.webex.com și deschideți pagina Întâlnire.

2

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

3

În secțiunea Licențe și utilizatori, faceți clic pe Gestionare masivă.

4

Faceți clic pe Exportș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ărcare. (Trebuie să închideți manual acea fereastră pop-up după ce faceți clic pe Descarca.)

6

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

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

7

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

Referința formatului de fișier CSV la are câteva detalii cu privire la https://help.webex.com/en-us/5vox83 scopul și conținutul fișierului CSV.

8

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

Dacă vă a aflați deja pe pagina Listă de site-uri întâlnire, poate fi necesar să o reîmprospătați.

9

În secțiunea Licențe și utilizatori, faceți clic pe Gestionare masivă.

10

Faceți clic pe Import și selectați CSV-ul editat, apoi faceți clic pe Import. Așteptați în timp ce încărcăm fișierul.

11

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

12

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

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

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 care vor avea identitate "verificată cisco". Dacă nu spuneți Webex ce domeniu identifică dispozitivul, vom alege unul și este posibil să arate greșit pentru alți participanți la întâlnire.

Înainte de a începe

Dacă dispozitivele nu sunt încă încorporate, puteți urmări https://help.webex.com/n25jyr8 sau https://help.webex.com/nutc0dy. De asemenea, ar trebui să verificați domeniul /domeniul (e) pe care doriți să îl utilizați pentru a identifica dispozitivele (https://help.webex.com/cd6d84).

1

Conectați-vă la Control Hub (https://admin.webex.com) și deschideți pagina Dispozitive.

2

Selectați un dispozitiv pentru a deschide panoul său 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.

Înainte de a începe

Ai nevoie:

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

  • Pentru a citi subiectul Înțelegerea procesului de identitate externă pentru dispozitive, în partea Pregătirea acestui articol.

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

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

  • Un instrument pentru a codifica base64url octeți sau text.

  • Un scrypt Implementarea.

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

1

Populează dispozitivul ClientSecret cu un secret text simplu:

Prima dată când populezi Secret, î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 pe dispozitiv.

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

    Comanda exemplu de mai sus populează Secret cu fraza 0123456789abcdef. Trebuie să vă alegeți propriul dvs.

Dispozitivul are secretul 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. Utilizând un editor de text, deschideți fișierele .pem, lipiți cheia blob blob certificat și salvați-l ca un nou fișier .pem.

    (Acesta este textul sarcinii utile pe care îl veți cripta și pune în blobul JWE)

3

Creați o blobĂ JWE pentru a o utiliza ca intrare la comanda adăugare certificat:

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

    Pentru aceasta aveți nevoie de secretul, sarea și o cheie pentru a se potrivi cu cifrul 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 octeți. Acesta este vectorul de inițializare.

  4. Crearea unui antet JOSE, setarea alg, enc și cisco-kdf chei așa 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 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 codificat 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ă urmează (toate valorile sunt codificate base64url):

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4

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

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

Verificați dacă certificatul este adăugat executând 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 în sine, fie din rezultatul xcommand Security Certificates Services Show.

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

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

    Pentru aceasta aveți nevoie de secretul, sarea și o cheie pentru a se potrivi cu cifrul 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 octeți și base64url codifică acea secvență. Acesta este vectorul de inițializare.

  5. Crearea unui antet JOSE, setarea alg, enc și cisco-kdf chei așa 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 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 codat base64url pentru a cripta amprenta certificatului.

    Instrumentul ar trebui să șteasă o secvență de 16 sau 32 de octeți, în funcție de faptul dacă 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 blobul JWE după 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 ca, gata de a fi utilizat pentru identificarea acestuia în întâlniri Webex criptate end-to-end.
7

Înscrieți dispozitivul în organizația Control Hub.

1

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

2

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

3

Asociați-vă la întâlnire de pe un dispozitiv care are identitatea verificată de CA Webex.

4

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

5

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

6

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

7

Alăturați-vă întâlnirii în calitate de participant la întâlniri neautentitate.

8

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

9

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

10

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

11

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

12

Asociați-vă la întâlnire cu un participant nou.

13

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

Veți face din întâlnirile criptate end-to-end opțiunea implicită de întâlnire sau o veți activa numai pentru unii utilizatori sau veți permite tuturor gazdelor să decidă? Când ați decis 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 în întâlnire.

Trebuie să vă asigurați că nici Cisco, nici altcineva nu vă poate decripta conținutul sau nu vă poate uzurpa identitatea dispozitivelor? 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âlniri să se alăture.

Pentru utilizatorii care se alătură dispozitivelor securizate, permiteți dispozitivelor să se alăture mai întâi și setați așteptările utilizatorilor că este posibil să nu se poată alătura dacă se alătură cu întârziere.

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 al întâlnirii. Chiar dacă există circumstanțe în care participanții pot apărea ca neverificate, iar participanții ar trebui să știe să verifice, este posibil ca persoanele neverificate să nu fie impostori.

Dacă utilizați un CA extern pentru a emite certificatele de dispozitiv, sarcina este pe dvs. să monitorizați, să reîmprospătați și să aplicați din nou certificatele.

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

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

ID-ul tipului de sesiune

Numele serviciului public

638

Criptare E2E+VoIP numai

652

Pro-End to End Encryption_VOIPonly

660

Pro 3 Free-End to End Encryption_VOIPonly

Criptare E2E + Identitate

672

Pro 3 Free50-End to End Encryption_VOIPonly

673

Instructor de educație E2E Encryption_VOIPonly

676

Broadworks Standard plus criptare end to end

677

Broadworks Premium plus criptare end to end

681

Schoology Free plus criptare end to end

Aceste tabele descriu comenzile API pentru dispozitive Webex pe care le-am adăugat pentru întâlniri criptate integral și identitate verificată. Pentru a citi mai multe despre se utilizează API-ul, consultați https://help.webex.com/nzwo1ok.

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

Apel API

Descriere

xConfiguration Conference EndToEndEncryption Mode: On

Se transformă în modul de criptare de la un capăt la altul On sau Off.

xConfiguration Conference 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 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 se poate asocia la o întâlnire criptată integral. API-ul cloud îl apelează astfel încât o aplicație asociată să știe dacă poate utiliza dispozitivul pentru a se alătura.

xStatus Conference EndToEndEncryption ExternalIdentity Valid

Indică dacă dispozitivul are un certificat valabil emis extern.

xStatus Conference EndToEndEncryption ExternalIdentity Identity

Identitatea dispozitivului așa este citită din numele comun al certificatului emis extern.

xStatus Conference EndToEndEncryption ExternalIdentity CertInfo

Citește informațiile certificatului din certificatul emis extern și îl transmite ca blob JSON.

xStatus Conference EndToEndEncryption InternalIdentity Valid

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

xStatus Conference EndToEndEncryption InternalIdentity Identity

Identitatea dispozitivului 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 CertInfo

Citește informațiile despre certificat din certificatul emis de Webex și le transmite ca blob JSON.

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

Apel API

Descriere

xStatus Call # ServerEncryption Type

Citește cifrul de criptare utilizat în conexiunea HTTPS la Webex. Acest lucru este afișat utilizatorului.

xStatus Conference Call # EndToEndEncryption Status

Citește starea de criptare end-to-end a apelurilor. Afișat utilizatorului ca prezența (sau absența) pictogramei lacătului.

xStatus Conference Call # EndToEndEncryption SecurityCode

Citește codul de securitate al întâlnirii. Acest lucru este afișat utilizatorului și se modifică atunci când participanții se alătură.

xStatus Conference Call # EndToEndEncryption MediaEncryption Type

Citește cifrul de criptare utilizat în conexiunea media. Acest lucru este afișat utilizatorului.

xStatus Conference Call # EndToEndEncryption GroupEncryption Type

Citește cifrul de criptare utilizat pentru Messaging Layer Security (MLS).

xStatus Conference Call # EndToEndEncryption Roster Participant

Listează participanții care contribuie la starea grupului MLS în această întâlnire. Lista este descoperită de MLS, nu de Webex.

xStatus Conference Call # EndToEndEncryption Roster Participant # Id

ADRESA URL WDM a unui participant specificat.

xStatus Conference Call # EndToEndEncryption Roster Participant # Status:

Starea de verificare a participantului specificat.

xStatus Conference Call # EndToEndEncryption Roster Participant # Identity:

Identitatea principală a participantului specificat, de obicei un domeniu (dispozitiv) sau o adresă de e-mail (utilizator).

xStatus Conference Call # EndToEndEncryption Roster Participant # DisplayName:

Numele afișat al participantului specificat. Semnat de participant/dispozitiv.

xStatus Conference Call # EndToEndEncryption Roster Participant # CertInfo:

Informațiile certificatului din certificatul participantului specificat ca blob JSON.

xCommand Conference ParticipantList Search

Am extins această comandă pentru a include informații de criptare end-to-end pentru participanți.

xCommand Conference ParticipantList Search

Căutarea listei de participanți include acum EndToEndEncryptionStatus, starea de verificare a identității participantului. Această valoare este afișată în interfața cu utilizatorul.

xCommand Conference ParticipantList Search

Căutarea listei de participanți include acum EndToEndEncryptionIdentity, identitatea primară a participantului. Acesta este de obicei un domeniu sau o adresă de e-mail. Această valoare este afișată în interfața cu utilizatorul.

xCommand Conference ParticipantList Search

Căutarea listei de participanți include acum EndToEndEncryptionCertInfo, blobul JSON care conține certificatul participantului. Această valoare este afișată în interfața cu utilizatorul.

xEvent Conference ParticipantList Participant(Added)

xEvent Conference ParticipantList Participant(Updated)

xEvent Conference ParticipantList Participant(Deleted)

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ă base64url pentru însămânțarea secretului clientului pe dispozitiv pentru prima dată.

Pentru a actualiza secretul după aceea prima dată, trebuie să furnizați un blob 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 pată 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 pată JWE.