Implementarea întâlnirilor cu încredere zero
Zero-Trust Security de la Webex oferă criptare end-to-end și verificare puternică a identității în întâlnirile programate și personale din sală.
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:
-
Asocierea la o întâlnire Webex cu criptare end-to-end
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.
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.
Informații conexe
-
Securitate Zero-Trust pentru Webex (hârtie tehnică de securitate)
-
Criptare web JSON (JWE) (proiect standard IETF)
-
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 în 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.
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.
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.
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:
-
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.
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.
-
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 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ă). Valoareasă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 noulClientSecret
. -
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țiparametrul 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
.
-
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 utilizaA256GCM
dacă preferați. -
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ține5eZTCAP4M_Y
(eliminați padding-ul de bază64). -
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
. -
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 toNLNd3V9Te⁺ tkpWD
. -
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.
-
Al doilea element al blob-ului JWE este gol, deoarece nu furnizăm o cheie de criptare JWE.
-
Al treilea element al blob-ului JWE este vectorul de inițializare
NLNd3V9Te⁺ tkpWD
. - 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.
-
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.
-
Concatenează cele cinci elemente ale blobului JWE cu puncte (JOSEheader.. IV.Ciphertext.Tag) pentru a obține:
eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te⁺ tkpWD.f5LLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q
-
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.
-
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.
1 |
Conectați-vă la Control Hub, apoi accesați . |
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 Î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.
1 |
Conectați-vă la Control Hub și accesați . |
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. |
1 |
Conectați-vă la Control Hub, apoi accesați . |
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 |
7 |
Pentru fiecare utilizator pe care doriți să-l acordați noului tip de sesiune, adăugați 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. |
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
- Conectați-vă la Control Hub, apoi, sub Management, selectați Setări organizație.
- Î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ă
- În Control Hub, sub Monitorizare, selectați Depanare.
- Faceți clic pe Analiza marcajului.
- Căutați sau selectați întâlnirea din listă, apoi faceți clic pe Analizați.
- În fereastra Analizați marca audio , introduceți un nume pentru analiza dvs.
- (Opțional) Introduceți o notă pentru analiza dvs.
- 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.
- 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 .
- Selectați întâlnirea din listă pentru a vedea rezultatele analizei. Faceți clic 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.
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. |
Î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 Prima dată când populați 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ă: |
3 |
Creați o blobĂ JWE pentru a o utiliza ca intrare la comanda adăugare certificat: |
4 |
Deschideți TShell pe dispozitiv și executați comanda de adăugare (multiline): |
5 |
Verificați dacă certificatul este adăugat prin rularea Copiați amprenta noului certificat. |
6 |
Activați certificatul în scopul 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ă. 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. |
-
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.
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-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 |
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
Apel API |
Descriere |
---|---|
|
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. |
|
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. |
|
Indică dacă dispozitivul utilizează verificarea |
|
Identitatea dispozitivului așa cum este citită din numele comun al certificatului emis extern. |
xStatus |
Citește informații specifice dintr-un certificat emis extern. În comanda afișată, înlocuiți
|
|
Starea identității externe a dispozitivului (de exemplu, |
|
Indică dacă dispozitivul are un certificat valid emis de Ca Webex. |
|
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 |
xStatus |
Citește informații specifice din certificatul emis de Webex. În comanda afișată, înlocuiți
|
Apel API |
Descriere |
---|---|
| Aceste trei evenimente includ acum |
Apel API |
Descriere |
---|---|
sau
| 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 | Adaugă un certificat (cu cheie privată). Am extins această comandă pentru a accepta un blob JWE care conține datele PEM criptate. |
| Activează un anumit certificat pentru WebexIdentity. În acest |
| Dezactivează un anumit certificat pentru WebexIdentity. În acest |