Experiență utilizator

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

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

Verificarea identității cu CA intern sau extern

Verificați identitatea

Criptarea integrală cu verificarea identității oferă securitate suplimentară pentru o întâlnire criptată integrală.

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

Utilizatorii Aplicației Webex se autentifică împotriva magazinului de identitate Webex, ceea ce le dă un token de acces atunci când autentificarea reușește. Dacă au nevoie de un certificat pentru a-și verifica identitatea într-o întâlnire criptată end-to-end, Webex CA le emite un certificat pe baza tokenului de acces. În acest moment, nu oferim utilizatorilor Webex Meetings o modalitate de a obține un certificat eliberat 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:

  • CA intern – Webex emite un certificat intern bazat pe tokenul de acces al contului mașinii dispozitivului. Certificatul este semnat de Webex CA. Dispozitivele nu au ID-uri de utilizator la fel ca utilizatorii, astfel încât Webex utilizează (unul dintre) domeniile organizației dvs. atunci când scrie identitatea certificatului dispozitivului (Common Name (CN)).

  • CA extern – Cereț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ă fie o modalitate de a garanta o criptare integrală și o identitate verificată și de a preveni posibilitatea teoretică ca Cisco să se prăbușească pe întâlnire/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 întâlnirii Webex, așa cum este descris în criptarea end-to-end cu verificarea identității pentru Webex Meetings.

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

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

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

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

Caracteristici și limitări

Dispozitive

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

  • Webex Board

  • Webex Desk Pro

  • Webex Desk

  • Webex Room Kit

  • Kit Webex Room Mini

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

  • Seria Webex C

  • Seria Webex DX

  • Seria Webex EX

  • Seria Webex MX

  • Dispozitive SIP de la terți

Clienți software

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

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

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

Identitate

  • Prin design, nu oferim opțiuni Control Hub pentru a gestiona identitatea dispozitivului verificat extern. Pentru criptarea integrală adevărată, trebuie doar să cunoașteți/să accesați secretele și cheile. Dacă am introdus un serviciu cloud pentru a gestiona aceste chei, există o șansă ca acestea să fie interceptate.

  • În prezent, vă oferim o „rețetă” pentru a vă proiecta propriile instrumente, pe baza tehnicilor 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 vrem să avem acces real sau perceput la secretele sau cheile tale.

Întâlniri

  • Întâlnirile E2EE acceptă în prezent un număr maxim de 1000 de participanți.

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

Interfața de gestionare

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

Resurse suplimentare
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-ul întâlnirii din Control Hub.

  • 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ă).

  • Sălile de întâlnire de colaborare trebuie să fie activate, astfel încât utilizatorii să se poată alătura din sistemul lor video. Pentru mai multe informații, consultați Permiteți 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 trebuie să aibă un certificat unic eliberat de o autoritate de certificare publică de încredere (CA).

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

  • 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. Este posibil să 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 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.

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

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

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 faceți upgrade pentru a utiliza identitatea verificată extern, trebuie să resetați dispozitivele la setările din fabrică.

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

  • Programați o fereastră atunci când dispozitivele nu sunt utilizate sau utilizați o abordare etapizată. 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.

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

Înțelegerea procesului de identitate externă pentru dispozitive

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 și a certificatului criptat, utilizând criptarea web JSON (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, trebuie:

  1. Solicitați-vă certificatele.

  2. Generați perechile de chei ale certificatelor.

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

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

    Procesul și parametrii (non-secrete) de care veți avea nevoie sunt explicați mai jos, precum și o rețetă de urmat în instrumentele de dezvoltare de alegere. De asemenea, oferim unele 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ă utilizând Python3 și biblioteca JWCrypto este disponibilă de la Cisco la cerere.

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

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

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

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

Cum folosim formatul JWE

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

Consultați criptarea web JSON (JWE) https://datatracker.ietf.org/doc/html/rfc7516 și semnătura web JSON (JWS) https://datatracker.ietf.org/doc/html/rfc7515.

Folosim serializarea compactă a unui document JSON pentru a crea bloguri JWE. Parametrii pe care trebuie să le includeți atunci când creați blocurile JWE sunt:

  • Titlul 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" or "cisco-action": "populate" or "cisco-action": "activate" or "cisco-action": "dezactivate"

      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 acțiune cisco pentru a atenua potențialele ciocniri cu viitoarele extensii JWE.

    • "cisco-kdf": { "versiune": "1", "sare": "bază22URLEncodedRandom4+Bytes" }

      O altă cheie de proprietate. Folosim valorile pe care le furnizați ca intrări pentru derivarea cheilor pe dispozitiv. Versiunea trebuie să fie 1 (versiunea funcției noastre de derivare cu tastatură). Valoarea sării trebuie să fie o secvență URL codificată de bază64 de cel puțin 4 octeți, pe care trebuie să o alegeți aleatoriu.

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

  • Vector de inițializare JWE. Trebuie să furnizați un vector de inițializare 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ă.

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

    Sarcina utilă POATE fi goală. De exemplu, pentru a reseta secretul clientului, trebuie să-l suprascrie 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 de plată diferite și trebuie să specificați scopul sarcinii de plată cu cheia cisco-action , după cum urmează:

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

    • Cu ""cisco-action":"add" the ciphertext is a PEM blob carrying the certificate and its private key (concatenated).

    • Cu ""cisco-action":"activați" textul cifrului este amprenta (reprezentarea hexadecimal a sha-1) a certificatului pe care îl activăm pentru verificarea identității dispozitivului.

    • Cu ""cisco-action":"dezactivați" textul cifrului este amprenta (reprezentarea hexagonală 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

Cum derivăm 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 aceeași sare atunci când specificați parametrul cisco-kdf .

  • 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 "versiune":"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 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 pe 128 de biți în modul Counter Galois). Instrumentul dvs. ar putea utiliza A256GCM dacă preferați.

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

  3. Aici este un apel de tip scrypt pentru a crea cheia de criptare a conținutului (cek):

    cek=scrypt (parolă="ossifrage", sare=secvență de 4 octeți, N=32768, r=8, p=1, keylength=16)

    Cheia derivată trebuie 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 care codifică bdEiAQV4_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 which base22url encodes to NLNd3V9Te⁺ tkpWD.

  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"}

    Cadrul codificat JOSE de bază 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 NLNd3V9Te⁺ tkpWD.

  8. Utilizați instrumentul de criptare JWE pentru a produce o sarcină utilă criptată și o etichetă. De exemplu, sarcina utilă necriptată va fi blob-ul fals PEM 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)

    URL-ul de baza codifică sarcina utilă criptată, care ar trebui să rezulte în f5lLVuWNfKfmzYCo1YJfODhQ

    Acesta este al patrulea element (JWE Ciphertext) în blob JWE.

  9. Url Base26encode tag-ul pe care l-ați produs în pasul 8, care ar trebui să conducă 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..9NLNd3V9Te⁺ tkpWD.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:

    Certificatele de securitate xCommand Adăugați eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te⁺ tkpWD.f5LVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

Tipurile de sesiune 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 sesiuni, consultați ID-urile tip sesiune din secțiunea Referință din acest articol.

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

Verificați noul tip de sesiune
1

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

2

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

3

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

4
Ar trebui să vedeți unul sau mai multe tipuri de sesiuni de criptare integrală. 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 până la end. Acest tip de sesiune include acces PSTN necriptat la întâlniri. Asigurați-vă că aveți versiunea _VOIPonly pentru a asigura criptarea end-to-end. Puteți verifica accesând linkul PRO din coloana codului de sesiune; de exemplu, obiectivul linkului trebuie să fie javascript:ShowFeature(652).

În viitor, putem modifica Numele Serviciului Public pentru aceste tipuri de sesiuni.

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.

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

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

2

Selectați un cont de utilizator pentru a actualiza, apoi selectați Meetings.

3

Din Setări se aplică în derulant, selectați site-ul întâlnirii pentru a actualiza.

4

Bifați caseta de lângă Pro-End la ncryption_End E.

5

Închideți panoul de configurare a utilizatorului.

6

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

Pentru a aloca acest lucru 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 accesați Servicii > Întâlnire.

2

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

3

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

4

Faceți clic pe Generare 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ărcare . (Trebuie să închideți manual fereastra pop-up după ce faceți clic pe Descărcare.)

6

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

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

7

Pentru fiecare utilizator pe care doriți să-l acordați noului tip de sesiune, adăugați 1561 ca valoare nouă în lista delimitată de virgulă din celula MeetingPrivilege .

Referința formatului de fișier CSV Webex conține detalii privind 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 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 Utilizatori și deschideți unul dintre utilizatori pentru a verifica dacă au noul tip de sesiune.

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

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

Când această funcție este activată, transmisia audio a întâlnirii include un identificator unic pentru fiecare client sau dispozitiv participant. Puteți încărca înregistrări audio în Control Hub, care apoi analizează înregistrarea și vizualizează identificatorii unici. Puteți să analizați rezultatele pentru a vedea ce sursă a înregistrat clientul sau dispozitivul întâlnirii.

  • Pentru a fi analizată, înregistrarea trebuie să fie un fișier AAC, MP3, M4A, WAV, MP4, AVI sau MOV care nu depășește 500MB.
  • Înregistrarea trebuie să dureze mai mult de 100 de secunde.
  • Puteți analiza doar înregistrările pentru întâlnirile găzduite de persoane din organizația dvs.
  • Informațiile privind marca înregistrată sunt păstrate pentru aceeași durată ca și informațiile despre întâlnire ale organizației.

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 secțiunea Meeting watermarks , activați Adăugați filigran audio.

    La ceva timp după ce aceasta este activată, utilizatorii care programează întâlniri cu tipul de sesiune Webex Meetings Pro-End to End Encryption_VOIPonly văd o opțiune de marcare digitală a apei în secțiunea Securitate.

Încărcați și analizați o întâlnire marcată cu apă

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

    Când analiza este finalizată, aceasta va fi afișată în lista de rezultate de pe pagina Analiză filigran .

  8. Selectați întâlnirea din listă pentru a vedea rezultatele analizei. Faceți clic Butonul Descărcare 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 emite audio, volumul acelui audio, zgomotul de mediu etc. Tehnologia noastră de marcare a apei are o rezistență suplimentară de a fi codificată de mai multe ori, așa cum s-ar putea întâmpla atunci când mass-media este partajată.

Această caracteristică este concepută pentru a permite decodarea cu succes a identificatorului de marcă într-un set larg, dar rezonabil de circumstanțe. Scopul nostru este pentru 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 de laptop, ar trebui să creeze întotdeauna o înregistrare care să ducă la o analiză reușită. Pe măsură ce dispozitivul de înregistrare este mutat departe de sursă sau este ascuns de audierea spectrului audio complet, șansele unei analize reușite sunt reduse.

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

Dispozitive de la bord (AC intern)

Dacă dispozitivele dvs. sunt deja încorporate în 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 dispozitivele 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 care vor avea identitate "verificată cisco". Dacă nu spuneți Webex care 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 Înregistrarea unui dispozitiv la Cisco Webex utilizând API sau interfață 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 din Gestionați domeniile.

1

Conectați-vă la Control Hub, iar sub Management, selectați 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.

Dispozitive de la bord (AC extern)

Înainte de a începe

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

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

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

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

  • Asigurați-vă că aveți un instrument pentru a Base22url encode bytes sau text.

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

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

1

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

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

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

  2. Deschideți TShell pe dispozitiv.

  3. Rulați xcommand Securitate ClientSecret Populate Secret: "MDEyMzQ1Njc4OWFiY2RlZg"

    Exemplul de comandă 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 dispozitivul la setările din fabrică pentru a începe 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 de sarcină utilă pe care îl veți cripta și îl veți pune în blob-ul dvs. 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. Creați un antet JOSE, setați tastele alg, enc și cisco-kdf așa cum este descris în înțelegerea procesului de identitate externă pentru dispozitive. Setați acțiunea „add” utilizând cheia: valoare „cisco-action”: „add” în antetul dvs. 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ă cum 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 Adăugați IsEncrypted: Adevărat...JWE.str.ing\n .\n
5

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

Copiați amprenta noului certificat.

6

Activați certificatul în scopul WebexIdentity:

  1. Citiți amprenta certificatului, fie de la certificatul în sine, fie de la ieșirea din 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. Creați un antet JOSE, setați tastele alg, enc și cisco-kdf 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”: „activare” în antetul JOSE (deoarece activăm certificatul de 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ă 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 Servicii certificate de securitate Activați scopul: WebexIdentity Fingerprint: "amprenta ta..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.

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

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

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

2

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

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

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

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

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ă. Aflați mai multe despre pictogramele de identitate.

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, acolo unde este posibil, identitățile participanților/dispozitivelor prin verificarea certificatelor.

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.

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

  • 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 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 î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.

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

Managementul identității

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.

ID-uri de tip sesiune
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 EVOIPonlyncryption_

660

Pro 3 EVOIPonly free-end to endncryption_

Criptare E2E + identitate

672

Pro 3 Free50-End to End EVOIPonlyncryption_

673

Instructor de educație E2E EVOIPonlyncryption_

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 asociate

Aceste tabele descriu comenzile API pentru dispozitive Webex pe care le-am adăugat pentru întâlniri criptate integral și identitate verificată. Pentru mai multe informații despre cum se utilizează API-ul, consultați Accesarea API-ului pentru dispozitive webex room and desk și webex boards.

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

xConfiguration Conference EndEndEncryption 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 EndEndEncryption 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 EndEndEncryption ExternalIdentity Verification

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

xStatus Conference EndEndEncryption ExternalIdentity Identity

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

xStatus Conference EndEndEncryption 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 specificațiile cu una dintre:

  • Amprentă digitală

  • După data finalizării valabilității

  • Înaintea începerii datei de valabilitate

  • PrimaryName

  • Algoritm de publicare

  • Număr în serie

  • Algoritm de semnătură

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

  • Valabilitatea Oferă starea de valabilitate a acestui certificat (de ex. valabil sau expirat)

xStatus Conference EndEndEncryption ExternalIdentity Status

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

xStatus Conference EndEndEncryption InternalIdentity Verificare

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

xStatus Conference EndEndEncryption 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 este într-o organizație care are mai multe domenii, aceasta este valoarea din PreferredDomain.

xStatus Conference EndEndEncryption InternalIdentity CertificateChain Certificate # specificinfo

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

În comanda afișată, înlocuiți # cu numărul certificatului. Înlocuiți specificațiile cu una dintre:

  • Amprentă digitală

  • După data finalizării valabilității

  • Înaintea începerii datei de valabilitate

  • PrimaryName

  • Algoritm de publicare

  • Număr în serie

  • Algoritm de semnătură

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

  • Valabilitatea Oferă starea de valabilitate a acestui certificat (de ex. valabil sau expirat)

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

Apel API

Descriere

xListă de participanți la conferința evenimentuluiAdăugat

xListă de participanți la conferință eveniment Actualizat

xListă de participanți la conferințe eveniment ștearsă

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: "bază22url-codat"

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.

Servicii xCommand Certificate de securitate 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.

xCommand Security Certificates Services Activare scop:WebexIdentity FingerPrint: JWEblob

Activează un anumit certificat pentru WebexIdentity. În acest Scop, comanda necesită ca amprenta de identificare să fie criptată și serializată într-un bloc JWE.

xCommand Security Certificates Services Dezactivat Scopul:WebexIdentity FingerPrint: JWEblob

Dezactivează un anumit certificat pentru WebexIdentity. În acest Scop, comanda necesită ca amprenta de identificare să fie criptată și serializată într-un bloc JWE.