A felhasználók az értekezlet értekezlet ütemezése választják ki az értekezlet típusa . A résztvevők előszobából történő beengedésekor, valamint az értekezlet során a szervező láthatja az egyes résztvevők személyazonosságának ellenőrzési állapotát. Létezik egy értekezletkód is, amely a megbeszélés összes jelenlegi résztvevőjére közös, és ennek segítségével ellenőrizhetik egymást.

Ossza meg a következő információkat az értekezlet szervezőivel:

Személyazonosság igazolása

A végpontok közötti titkosítás és a személyazonosság ellenőrzése további biztonságot nyújt a végpontok között titkosított értekezletek számára.

Amikor a résztvevők vagy eszközök csatlakoznak egy megosztott MLS (Üzenetküldés Layer Security) csoporthoz, bemutatják a tanúsítványaikat a csoport többi tagjának, akik ezt követően ellenőrzik a tanúsítványokat a kibocsátó hitelesítő hatóságokkal (CA) szemben. A tanúsítványok érvényességének megerősítésével a CA ellenőrzi a résztvevők kilétét, és az értekezlet ellenőrzöttként mutatja a résztvevőket/eszközöket.

A Webex alkalmazás felhasználói a Webex identitástár segítségével végzik el a hitelesítést, amely sikeres hitelesítés esetén hozzáférési tokent bocsát ki számukra. Ha tanúsítványra van szükségük a személyazonosságuk ellenőrzéséhez egy végpontok közötti titkosított értekezleten, a Webex CA a hozzáférési tokenjük alapján állít ki nekik egy tanúsítványt. Jelenleg nem biztosítunk lehetőséget a Webex Meetings -felhasználók számára, hogy harmadik fél/külső CA által kiállított tanúsítványt kapjanak.

Az eszközök a belső (Webex) CA vagy egy külső CA által kiadott tanúsítvány segítségével hitelesíthetik magukat:

  • Belső hitelesítésszolgáltató—A Webex belső tanúsítványt ad ki az eszköz gépfiókjának hozzáférési tokenje alapján. A tanúsítványt a Webex CA írja alá. Az eszközök ugyanúgy nem rendelkeznek felhasználói azonosítóval, mint a felhasználók, ezért a Webex a szervezet (egyik) tartományát használja az eszköztanúsítvány identitásának (Common Name (CN)) írásakor.

  • Külső hitelesítésszolgáltató – Kérjen és vásároljon eszköztanúsítványokat közvetlenül a kiválasztott kibocsátótól. Titkosítania, közvetlenül feltöltenie és hitelesítenie kell a tanúsítványokat egy csak Ön által ismert titok használatával.

    A Cisco nem vesz részt, így garantálható a valódi, end-to-end titkosítás és az ellenőrzött azonosság, és megakadályozható annak elméleti lehetősége, hogy a Cisco lehallgathatja az értekezletét/visszafejtheti a média adathordozóit.

Belsőleg kiadott eszköztanúsítvány

A Webex tanúsítványt ad ki az eszköznek, amikor az indítás után regisztrál, és szükség esetén megújítja azt. Eszközök esetén a tanúsítvány tartalmazza a azonosító és egy tartományt.

Ha a szervezete nem rendelkezik tartománynal, a Webex CA tartomány nélkül állítja ki a tanúsítványt.

Ha a szervezetnek több tartománya van, a Control Hub segítségével megmondhatja a Webex , hogy az eszköz melyik tartományt használja az identitásaként. Használhatja az API -t is xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com".

Ha több tartománya van, és nem állítja be a preferált tartományt az eszközhöz, akkor a Webex kiválaszt egyet az Ön számára.

Külsőleg kiállított eszköztanúsítvány

A rendszergazda kiépíthet egy eszközt a saját tanúsítványával, amelyet valamelyik nyilvános hitelesítésszolgáltatónál írtak alá.

A tanúsítványnak ECDSA P-256 kulcspáron kell alapulnia, bár RSA kulccsal aláírható.

A tanúsítványban szereplő értékekről a szervezet dönt. A közös név (CN) és az Téma másik megnevezése (SAN) megjelenik a Webex-értekezlet felhasználói felület, amint az itt olvasható: Végpontok közötti titkosítás személyazonosság-ellenőrzéssel a Webex Meetings számára .

Javasoljuk, hogy eszközenként külön tanúsítványt, és eszközönként egyedi CN-t használjon. Például: „meeting-room-1.example.com” az „example.com” tartományt birtokló szervezet esetében.

A külső tanúsítvány manipuláció elleni teljes védelme érdekében egy kliens-titkos funkciót használnak a különböző xparancsok titkosításához és aláírásához.

Az ügyféltitok használata esetén lehetőség van a külső Webex identitástanúsítvány biztonságos kezelésére az xAPI-n keresztül. Ez jelenleg az online eszközökre korlátozódik.

A Webex jelenleg API -parancsokat biztosít ennek kezelésére.

Eszközök

A következő, felhőre regisztrált Webex Room sorozat és Webex Desk sorozatú eszközök tudnak csatlakozni végpontok közötti titkosított értekezletekhez:

  • Webex Board

  • Webex Desk Pro

  • Webex íróasztal

  • Webex Room Kit

  • Webex Room Kit Mini

A következő eszközök nem tudnak csatlakozni végpontok között titkosított értekezletekhez:

  • Webex C sorozat

  • Webex DX sorozat

  • Webex EX sorozat

  • Webex MX sorozat

  • Harmadik féltől származó SIP -eszközök

Szoftver kliensek
  • A 41.6-os verziótól kezdődően a Webex Meetings asztali kliens képes csatlakozni a végpontok között titkosított értekezletekhez.

  • Ha a szervezet engedélyezi a Webex alkalmazás számára az értekezletekhez való csatlakozást a Meetings asztali alkalmazás elindításával, akkor ezzel a lehetőséggel csatlakozhat végpontok között titkosított értekezletekhez.

  • A Webex webes kliens nem tud csatlakozni végpontok között titkosított értekezletekhez.

  • Harmadik féltől származó szoftveres SIP -ügyfelek nem tudnak csatlakozni a végpontok között titkosított értekezletekhez.

Identitás
  • A tervek szerint nem biztosítunk Control Hub-beállításokat a külsőleg ellenőrzött eszközazonosság kezelésére. A valódi, végpontok közötti titkosítás érdekében csak Önnek kell ismernie/hozzáférnie a titkokhoz és a kulcsokhoz. Ha bevezetnénk egy felhőszolgáltatást ezeknek a kulcsoknak a kezelésére, fennáll annak az esélye, hogy elfogják őket.

  • Jelenleg egy „receptet” biztosítunk az Ön számára, hogy saját, iparági szabványos titkosítási technikákon alapuló eszközeit megtervezze, hogy segítse az eszközazonossági tanúsítványok és azok privát kulcsainak lekérését vagy titkosítását. Nem akarunk valós vagy vélt hozzáférést kapni az Ön titkaihoz vagy kulcsaihoz.

Értekezletek
  • A végpontok között titkosított értekezletek jelenleg legfeljebb 200 résztvevőt támogatnak.

  • Ebből a 200 résztvevőből legfeljebb 25 külsőleg hitelesített eszköz csatlakozhat, és ők legyen az első résztvevő, aki csatlakozik az értekezlethez .

    Amikor több eszköz csatlakozik egy értekezlethez, a háttér-médiaszolgáltatásunk megpróbálja átkódolni a médiastreameket. Ha nem tudjuk visszafejteni, átkódolni és újratitkosítani az adathordozót (mert nem rendelkezünk és nem is kellene rendelkeznünk az eszközök titkosítási kulcsaival), akkor az átkódolás sikertelen lesz.

    A korlátozás enyhítése érdekében javasoljuk, hogy kisebb értekezleteket tartsanak az eszközökön, vagy csoportosítsák a meghívásokat az eszközök és a Meetings kliensek között.

Kezelőfelület

Kifejezetten javasoljuk, hogy a Control Hub segítségével kezelje a Meeting-webhelyét, mivel a Control Hub-szervezetek központi identitással rendelkeznek a teljes szervezet számára, míg a Webes adminisztráció esetén az identitás felügyelete telephelyenként történik.

A Webes adminisztráció kezelt felhasználók nem rendelkezhetnek a Cisco által ellenőrzött azonosság opcióval. Ezek a felhasználók névtelen tanúsítványt kapnak a végpontok között titkosított értekezletekhez való csatlakozáshoz, és előfordulhat, hogy kizárják őket azokról az értekezletekről, ahol a szervező biztosítani szeretné a személyazonosságot.

Kapcsolódó információk
  • Webex Meetings 41.7.

  • Felhőben regisztrált Webex Room és Webex Desk sorozatú eszközök, futnak 10.6.1-RoomOS_August_2021.

  • Rendszergazdai hozzáférés a értekezlet webhelye a Control Hubban, hogy engedélyezze az új foglalkozás típusa a felhasználók számára.

  • Egy vagy több ellenőrzött tartomány a Control Hub-szervezetben (ha a Webex CA segítségével ad ki eszköztanúsítványokat az ellenőrzött személyazonossághoz).

  • Az Együttműködési tárgyalókat be kell kapcsolni, hogy az emberek a videórendszerükről csatlakozhassanak. További információkért lásd: Engedélyezze a videórendszerek számára, hogy értekezletekhez és eseményekhez csatlakozzanak a Webex-webhely .

Kihagyhatja ezt a lépést, ha nincs szüksége külsőleg ellenőrzött személyazonosságra.

A legmagasabb szintű biztonság és a személyazonosság ellenőrzése érdekében minden eszköznek rendelkeznie kell egy megbízható nyilvános Certificate Authority (CA) által kiadott egyedi tanúsítvánnyal.

Kapcsolatba kell lépnie a CA-val a digitális tanúsítványok kéréséhez, megvásárlásához és fogadásához, valamint a kapcsolódó privát kulcsok létrehozásához. A tanúsítvány igénylésekor használja az alábbi paramétereket:

  • A tanúsítványt egy jól ismert nyilvános CA-nak kell kiállítania és aláírnia.

  • Egyedi: Kifejezetten javasoljuk, hogy minden egyes eszközhöz egyedi tanúsítványt használjon. Ha egyetlen tanúsítványt használ az összes eszközhöz, az veszélyezteti a biztonságát.

  • Közös név (CN) és alany alternatív neve(i) (SAN/ek): Ezek nem fontosak a Webex számára, de olyan értékeknek kell lenniük, amelyeket az emberek be tudnak olvasni és az eszközhöz társítani tudnak. A CN jelenik meg az értekezlet többi résztvevője számára az eszköz elsődleges ellenőrzött identitásaként, és ha a felhasználók az értekezlet felhasználói felületén keresztül vizsgálják meg a tanúsítványt, látni fogják a SAN/eket. Érdemes lehet olyan neveket használni, mint: name.model@example.com.

  • Fájlformátum: A tanúsítványoknak és kulcsoknak a következőben kell lenniük: .pem formátumban.

  • Cél: A tanúsítvány céljának Webex Identity-nek kell lennie.

  • Kulcsok generálása: A tanúsítványoknak ECDSA P-256 kulcspárokon kell alapulniuk (Elliptical Curve Digital Signature Algorithm with the P-256 curve).

    Ez a követelmény nem vonatkozik az aláíró kulcsra. A hitelesítésszolgáltató RSA -kulcsot használhat a tanúsítvány aláírásához.

Kihagyhatja ezt a lépést, ha nem szeretne külsőleg ellenőrzött azonosságot használni az eszközeivel.

Ha új eszközöket használ, még ne regisztrálja őket a Webex rendszerébe. A biztonság kedvéért most ne csatlakoztassa őket a hálózathoz.

Ha vannak olyan meglévő eszközei, amelyeket külsőleg ellenőrzött identitás használatára szeretne frissíteni, vissza kell állítania az eszközök gyári beállításait.

  • Mentse a meglévő konfigurációt, ha meg szeretné tartani.

  • Ütemezzen egy ablakot, amikor az eszközök nincsenek használatban, vagy használjon szakaszos megközelítést. Értesítse a felhasználókat a várható változásokról.

  • Biztosítsa az eszközök fizikai elérését. Ha a hálózaton keresztül kell elérnie az eszközöket, ügyeljen arra, hogy a titkok egyszerű szövegként terjednek, és ezzel veszélyezteti a biztonságát.

Miután elvégezte ezeket a lépéseket, engedélyezze a videórendszerek számára, hogy csatlakozzanak értekezletekhez és eseményekhez a Webex-webhely .

Annak érdekében, hogy az eszközön lévő adathordozót az eszközön kívül senki más ne titkosítsa, titkosítania kell az eszközön lévő privát kulcsot. Az eszközhöz olyan API-kat terveztünk, amelyek lehetővé teszik a titkosított kulcs és tanúsítvány kezelését a JSON web Encryption (JWE) használatával.

A valódi, végpontok közötti titkosítás biztosítása érdekében a felhőnken keresztül nem tudunk részt venni a tanúsítvány és a kulcs titkosításában és feltöltésében. Ha ilyen szintű biztonságra van szüksége, a következőket kell tennie:

  1. Kérje a tanúsítványait.

  2. Állítsa elő a tanúsítványok kulcspárjait.

  3. Hozzon létre (és védje) egy kezdeti titkosítást minden egyes eszköz számára, az eszköz titkosítási képességének beindításához.

  4. Fejlessze ki és tartsa karban a fájlok JWE szabvány szerinti titkosítására szolgáló saját eszközét.

    Az alábbiakban ismertetjük a folyamatot és a szükséges (nem titkos) paramétereket, valamint egy követendő receptet a választott fejlesztői eszközökben. Néhány tesztadatot és az eredményül kapott JWE-blobokat is a vártnak megfelelően biztosítjuk, hogy segítsük a folyamat ellenőrzését.

    A Python3-at és a JWCrypto könyvtárat használó nem támogatott referenciamegvalósítás a Cisco -tól kérésre beszerezhető.

  5. A tanúsítvány és a kulcs összekapcsolása és titkosítása az eszköze és az eszköz kezdeti titkos kódja segítségével.

  6. Töltse fel az eredményül kapott JWE-blobot az eszközre.

  7. Állítsa be a Webex -identitáshoz használandó titkosított tanúsítvány célját, és aktiválja a tanúsítványt.

  8. (Ajánlott) Biztosítson olyan felületet (vagy terjesztheti) az eszközt, amely lehetővé teszi az eszköz felhasználói számára, hogy módosítsák a kezdeti titkosítást, és megvédjék az adathordozóikat Öntől.

Hogyan használjuk a JWE formátumot

Ez a rész azt ismerteti, hogy a JWE várhatóan miként kerül létrehozásra az eszközök bemeneteként, így saját eszközt hozhat létre a blobok létrehozásához a tanúsítványokból és kulcsokból.

Lásd: JSON web titkosítás (JWE)https://datatracker.ietf.org/doc/html/rfc7516és JSON web aláírás (JWS)https://datatracker.ietf.org/doc/html/rfc7515.

Használjuk a Kompakt szerializálás egy JSON-dokumentumot a JWE-blobok létrehozásához. A következő paramétereket kell megadnia a JWE blobok létrehozásakor:

  • JOSE fejléc (védett). A JSON Object Signing and Encryption fejlécben KÖTELEZŐ megadni a következő kulcs-érték párokat:

    • "alg":"dir"

      A direkt algoritmus az egyetlen, amelyet támogatunk a hasznos adatok titkosítására, és Önnek az eszköz kezdeti ügyféltitkát kell használnia.

    • "enc":"A128GCM" vagy "enc":"A256GCM"

      Ezt a két titkosítási algoritmust támogatjuk.

    • "cisco-action": "add" vagy "cisco-action": "populate" vagy "cisco-action": "activate" vagy "cisco-action": "deactivate"

      Ez egy védett kulcs, és négy értéket vehet fel. Ezt a kulcsot azért vezettük be, hogy jelezze a titkosított adatok célját a céleszköz felé. Az értékek a titkosított adatokat használó eszköz xAPI-parancsairól kaptak nevet.

      Elneveztük cisco-action a jövőbeli JWE-bővítésekkel való esetleges ütközések csökkentése érdekében.

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

      Egy másik védett kulcs. Az Ön által megadott értékeket használjuk bemenetként a kulcsok levezetéséhez az eszközön. A version kell lennie 1(a kulcs levezetési függvényünk verziója). Az értéke salt Legalább 4 bájtos base64 URL kódolású sorozatnak kell lennie, amelyet Ön kell válasszon véletlenszerűen.

  • JWE titkosított kulcs . Ez a mező üres. Az eszköz a kezdőbetűből származtatja ClientSecret.

  • JWE inicializálási vektor . Meg kell adnia egy base64url kódolású inicializálási vektort a hasznos adat visszafejtéséhez. A IV KELL véletlenszerű 12 bájtos érték legyen (mi az AES-GCM titkosítási családot használjuk, amihez az IV-nek 12 bájt hosszúnak kell lennie).

  • JWE AAD (további hitelesített adatok). Ezt a mezőt ki kell hagynia, mert a tömörített sorosítás nem támogatja.

  • JWE titkosított szöveg : Ez az a titkosított hasznos adat, amelyet titokban szeretne tartani.

    LEHET, hogy a hasznos adat üres. Például az ügyfél titkosságának alaphelyzetbe állításához felül kell írnia egy üres értékkel.

    A hasznos terhelések különböző típusai léteznek, attól függően, hogy mit próbál tenni az eszközön. A különböző xAPI parancsok más-más hasznos adatra számítanak, és meg kell adnia a hasznos adat célját a következővel: cisco-action kulcsot, az alábbiak szerint:

    • Ezzel "cisco-action":"populate" a titkosított szöveg az új ClientSecret.

    • A következővel: " "cisco-action":"add" a titkosított szöveg egy PEM blob, amely tartalmazza a tanúsítványt és a privát kulcsát (összefűzve).

    • A következővel: " "cisco-action":"activate" a titkosított szöveg az eszközazonosság ellenőrzéséhez általunk aktivált tanúsítvány ujjlenyomata (az sha-1 hexadecimális reprezentációja).

    • A következővel: " "cisco-action":"deactivate" a rejtjelezett szöveg annak a tanúsítványnak az ujjlenyomata (az sha-1 hexadecimális reprezentációja), amelynek az eszközazonosság ellenőrzéséhez való használatát inaktiváljuk.

  • JWE hitelesítési címke: Ez a mező tartalmazza a hitelesítési címkét a teljes JWE kompakt szerializált blob sértetlenségének ellenőrzéséhez.

Hogyan származtatjuk a titkosítási kulcs a ClientSecret

A titok első populációja után nem fogadjuk el és nem adjuk ki a titkot egyszerű szövegként. Ez azért van így, hogy megakadályozzuk az eszközhöz hozzáférő személyek esetleges szótártámadásait.

Az eszközszoftver a kliens titkos adatot használja egy kulcs származtatási funkció (kdf) bemeneteként, majd a származtatott kulcsot használja a tartalom visszafejtéséhez/titkosításához az eszközön.

Ez azt jelenti az Ön számára, hogy a JWE blobok előállítására szolgáló eszköznek ugyanazt az eljárást kell követnie ahhoz, hogy ugyanazt a titkosítási/visszafejtési kulcsot származtassa az ügyfél titkos adataiból.

Az eszközök használnak scrypt a kulcsok származtatásához (lásdhttps://en.wikipedia.org/wiki/Scrypt ), a következő paraméterekkel:

  • A CostFactor (N) értéke 32768

  • A BlockSizeFactor (r) értéke 8

  • ParallelizationFactor (p) értéke 1

  • A Salt egy legalább 4 bájt hosszúságú véletlenszerű sorozat; ezt meg kell adnia salt amikor megadja a cisco-kdf paramétert.

  • A kulcsok hossza vagy 16 bájt (ha az AES-GCM 128 algoritmust választja), vagy 32 bájt (ha az AES-GCM 256 algoritmust választja)

  • A maximális memóriakapacitás 64 MB

Ez a paraméterkészlet az egyetlen konfigurációja a(z) scrypt amely kompatibilis az eszközök kulcs levezetési funkciójával. Az eszközökön ez a kdf neve "version":"1", amely jelenleg a(z) egyetlen verziója cisco-kdf paramétert.

Bevált példa

Íme egy példa, amelyet követve ellenőrizheti, hogy a JWE-titkosítási folyamat ugyanúgy működik-e, mint az eszközökön létrehozott folyamat.

A példahelyzet egy PEM blob hozzáadása az eszközhöz (tanúsítvány hozzáadását utánozza, egy nagyon rövid karakterlánccal a teljes cert + kulcs helyett). A példában szereplő ügyféltitk az ossifrage.

  1. Válasszon egy titkosítási kódot. Ez a példa a következőt használja: A128GCM(AES 128 bites kulcsokkal Galois számláló módban). Az eszköze hasznos lehet A256GCM ha úgy tetszik.

  2. Válasszon sót (legalább 4 bájtos véletlenszerű sorozatnak kell lennie). Ebben a példában a(z) (hex byte) E5 E6 53 08 03 F8 33 F6. A Base64url kódolja a lekérni kívánt szekvenciát 5eZTCAP4M_Y(távolítsa el a base64 kitöltést).

  3. Itt van egy minta scrypt hívás a tartalom titkosítási kulcs létrehozásához (cek):

    cek=scrypt(password="ossifrage", salt=4-byte-sequence, N=32768, r=8, p=1, keylength=16)

    A származtatott kulcsnak 16 bájtosnak (hexa) kell lennie, az alábbiak szerint: 95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac amelyre a base64url kódol lZ66bdEiAQV4_mqdInj_rA.

  4. Válasszon ki egy 12 bájtos véletlenszerű sorozatot inicializálási vektorként. Ebben a példában a(z) (hex) 34 b3 5d dd 5f 53 7b af 2d 92 95 83 amelyre a base64url kódol NLNd3V9Te68tkpWD.

  5. Hozzon létre egy JOSE fejlécet kompakt szerializálással (követje az itt használt paraméterek sorrendjét), majd kódolja a base64url-t:

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

    A base64url kódolású JOSE fejléc eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

    Ez lesz a JWE blob első eleme.

  6. A JWE blob második eleme üres, mert nem adunk meg JWE titkosítási kulcs.

  7. A JWE blob harmadik eleme az inicializálási vektor NLNd3V9Te68tkpWD.

  8. Használja a JWE titkosítási eszközt titkosított hasznos adat és címke létrehozásához. Ebben a példában a nem titkosított hasznos adat a hamis PEM-blob lesz this is a PEM file

    A következő titkosítási paramétereket kell használnia:

    • A hasznos teher az this is a PEM file

    • A titkosítási kód AES 128 GCM

    • A base64url kódolású JOSE fejléc kiegészítő hitelesített adatként (AAD)

    A Base64url kódolja a titkosított hasznos adatot, aminek a következőt kell eredményeznie: f5lLVuWNfKfmzYCo1YJfODhQ

    Ez a negyedik elem (JWE Ciphertext) a JWE blobban.

  9. A Base64url kódolja a 8. lépésben létrehozott címkét, amelynek eredményeképpen meg kell jelennie PE-wDFWGXFFBeo928cfZ1Q

    Ez az ötödik elem a JWE-blobban.

  10. A JWE blob öt elemének összekapcsolása pontokkal (JOSEheader..IV.Ciphertext.Tag) így kap:

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

  11. Ha a saját eszközeivel ugyanazokat a base64url kódolású értékeket származtatta, mint itt bemutatjuk, akkor készen áll arra, hogy ezeket használja az eszközei E2E titkosításának és ellenőrzött azonosságának biztosítására.

  12. Ez a példa valójában nem fog működni, de elvileg a következő lépés az lenne, hogy a fent létrehozott JWE blobot használja az xcommand bemeneteként a tanúsítványt hozzáadó eszközön:

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

A nulla bizalmas értekezletek munkamenettípusai az összes értekezletoldal számára további költségek nélkül elérhetők. Az egyik ilyen foglalkozástípus az ún Pro-End to End Encryption_VOIPonly. Ez a Közszolgálati név , amelyet a jövőben módosíthatunk. A foglalkozástípusok aktuális nevéhez lásd: Munkamenettípus-azonosítók a Hivatkozás szakaszában.

Nincs teendője annak érdekében, hogy megszerezze ezt a funkciót a webhelyén; Önnek engedélyeznie kell az új foglalkozás típusa (más néven Értekezletjog ) a felhasználók számára. Ezt megteheti egyénileg a felhasználó konfigurációs oldal, vagy tömegesen egy CSV export/import segítségével.

1

Jelentkezzen be a Control Hubba, majd lépjen a Szolgáltatás > Értekezlet menüpontra.

2

Kattintson a Webhelyek lehetőségre, válassza ki azt a Webex-webhelyet, amelynek beállításait módosítani szeretné, majd kattintson a Beállítások elemre.

3

Az Általános beállítások menüpontban válassza ki a Foglalkozástípusok lehetőséget.

4
Látnia kell egy vagy több végpontok közötti titkosítási munkamenet-típust. Lásd a listát Munkamenettípus-azonosítók a Hivatkozás szakaszában. Például láthatja Pro-End-Encryption_ Csak VOIP .

 

Van egy régebbi foglalkozás típusa , amelynek nagyon hasonló a neve: Pro-End-to End titkosítás . Ez a foglalkozás típusa nem titkosított PSTN-elérés tartalmaz az értekezletekhez. Győződjön meg arról, hogy rendelkezik a_ Csak VOIP verziót a végpontok közötti titkosítás biztosítása érdekében. Ellenőrizheti, ha az egérmutatót a következő fölé viszi PRO hivatkozást a munkamenetkód oszlopban; ebben a példában a hivatkozás céljának a következőnek kell lennie javascript:ShowFeature(652).

Előfordulhat, hogy a jövőben módosítani fogjuk ezeknek a foglalkozástípusoknak a közszolgáltatási nevét.

5

Ha még nem rendelkezik az új foglalkozás típusa , forduljon a Webex -képviselőjéhez.

Mi a következő teendő

Engedélyezze ezt a foglalkozás típusa /értekezlet-jogosultságot néhány vagy az összes felhasználó számára.

1

Jelentkezzen be ide: Control Hub , majd lépjen ide: Kezelés > Felhasználók lehetőségre .

2

Válasszon ki egy frissíteni kívánt felhasználói fiók , majd válassza a lehetőséget Értekezletek .

3

A következőből: A beállítások a következőre vonatkoznak: legördülő menüből válassza ki a frissíteni kívánt a értekezlet webhelye .

4

Jelölje be a mellette lévő jelölőnégyzetet Pro-End-Encryption_ Csak VOIP .

5

Zárja be a felhasználói beállítások panelt.

6

Szükség esetén ismételje meg a műveletet más felhasználóknál is.

Ha ezt sok felhasználóhoz szeretné hozzárendelni, használja a következő opciót, Engedélyezze az E2EE értekezleteket több felhasználó számára .

1

Jelentkezzen be a Control Hubba, majd lépjen a Szolgáltatás > Értekezlet menüpontra.

2

Kattintson Webhelyek lehetőségre , válassza ki azt a Webex-webhely , amelynek a beállításait módosítani szeretné.

3

A Licencek és felhasználók szakaszban kattintson Tömeges kezelés lehetőségre .

4

Kattintson Jelentés generálása , és várjon, amíg előkészítjük a fájlt.

5

Amikor a fájl készen áll, kattintson a gombra Eredmények exportálása majd Letöltés . (A kattintás után manuálisan be kell zárnia az előugró ablakot Letöltés .)

6

Nyissa meg a letöltött CSV-fájl szerkesztésre.

Minden felhasználóhoz tartozik egy sor, és a MeetingPrivilege oszlop a foglalkozás típusa -azonosítóikat tartalmazza vesszővel tagolt listaként.

7

Minden egyes felhasználóhoz, akinek az új foglalkozás típusa szeretné megadni, adja meg 1561 új értékként a vesszővel tagolt listában a MeetingPrivilege cellába.

A Webex CSV fájlformátum-referencia részletesen tartalmazza a CSV-fájl célját és tartalmát.

8

Nyissa meg az Értekezlethelyszín konfigurációs panelt a Control Hubban.


 

Ha már szerepelt az értekezlet webhelylista oldalán, előfordulhat, hogy frissítenie kell azt.

9

A Licencek és felhasználók szakaszban kattintson Tömeges kezelés lehetőségre .

10

Kattintson Importálás lehetőségre és válassza ki a szerkesztett CSV-fájlt , majd kattintson a gombra Importálás lehetőségre . Várjon, amíg a fájl feltöltődik.

11

Az importálás befejeztével kattintson a gombra Eredmények importálása hogy ellenőrizze, történt-e hiba.

12

Lépjen a következőre: Felhasználók lehetőségre oldalt, és nyissa meg az egyik felhasználót, és ellenőrizze, hogy rendelkeznek-e az új foglalkozás típusa.

Vízjelet adhat az értekezletfelvételekhez a következővel: Webex Meetings Pro-End to End Encryption_VOIPonly foglalkozás típusa, amely lehetővé teszi a bizalmas értekezletek nem engedélyezett felvételeinek forráskliensének vagy eszközének azonosítását.

Ha ez a funkció engedélyezve van, az értekezlet hangja egyedi azonosítót tartalmaz minden résztvevő klienshez vagy eszközhöz. A hangfelvételeket feltöltheti a Control Hub rendszerébe, amely elemzi a felvételt, és megkeresi az egyedi azonosítókat. Az eredményekből megtudhatja, hogy melyik forráskliens vagy eszköz rögzítette az értekezletet.

  • Az elemzéshez a felvételnek 500 MB-nál nem nagyobb AAC-, MP3-, M4A-, WAV-, MP4-, AVI- vagy MOV-fájlnak kell lennie.
  • A felvételnek hosszabbnak kell lennie 100 másodpercnél.
  • Csak a szervezetén belüli személyek által szervezett értekezletek felvételeit tudja elemezni.
  • A vízjelinformációkat a szervezet értekezletinformációival azonos ideig őrzik meg.
Hangos vízjel hozzáadása az E2EE értekezletekhez
  1. Jelentkezzen be a Control Hub szolgáltatásba, majd a Kezelés alatt válassza ki a Szervezeti beállítások elemet.
  2. A Értekezlet vízjelei szakaszt, kapcsolja be Hang vízjel hozzáadása .

    Egy idő után ennek bekapcsolása után a felhasználók a következővel ütemeznek értekezleteket Webex Meetings Pro-End to End Encryption_VOIPonly foglalkozás típusa lásd a Digitális vízjel opciót a Biztonság részben.

Vízjellel ellátott értekezlet feltöltése és elemzése
  1. A Control Hubban, alatt Monitoring , válassza ki Hibaelhárítás .
  2. Kattintson Vízjel-elemzés .
  3. Keresse meg vagy jelölje ki az értekezletet a listában, majd kattintson a gombra Elemzés .
  4. A Hang vízjel elemzése ablakban adja meg az elemzés nevét.
  5. (Nem kötelező) Írjon be egy megjegyzést az elemzéshez.
  6. Húzza át az elemezni kívánt hangfájlt, vagy kattintson a gombra Válasszon fájlt hogy tallózzon a hangfájlhoz.
  7. Kattintson Bezárás .

    Ha az elemzés befejeződött, az megjelenik az eredménylistában a(z) oldalon Vízjel elemzése oldalon.

  8. Az elemzés eredményeinek megtekintéséhez válassza ki a megbeszélést a listából. KattintsonLetöltés gomb az eredmények letöltéséhez.
Jellemzők és korlátozások

A rögzített vízjel sikeres dekódolásában szerepet játszó tényezők közé tartozik a felvevő eszköz és a hangot kibocsátó beszélő közötti távolság, a hang hangereje, a környezeti zaj stb. Vízjel-technológiánk további ellenálló képességgel rendelkezik a többszöri kódolás ellen, ami előfordulhat, ha a a média meg van osztva.

Ez a funkció lehetővé teszi a vízjel azonosító sikeres dekódolását széles körű, de ésszerű körülmények között. Célunk, hogy egy személyes végpont vagy laptop kliens közelében asztalon fekvő felvevő eszköz, például mobiltelefon mindig sikeres elemzést eredményező felvételt készítsen. Ha a felvevő eszköz távolodik a forrástól, vagy nem hallja a teljes hangspektrumot, csökken a sikeres elemzés esélye.

A felvételek sikeres elemzéséhez az értekezlet hangjának ésszerű rögzítésére van szükség. Ha egy értekezlet hangjának felvétele ugyanazon a számítógépen történik, amelyen az ügyfél is helyet kapott, a korlátozások nem vonatkoznak.

Ha az eszközei már be vannak építve a Control Hub-szervezetbe, és a Webex CA segítségével szeretné automatikusan előállítani az azonosító tanúsítványaikat, akkor nem kell gyári alaphelyzetbe állítás beállításait.

Ez az eljárás kiválasztja, hogy az eszköz melyik tartományból azonosítja magát, és csak akkor szükséges, ha több tartománya van a Control Hub-szervezetben. Ha egynél több tartománya van, javasoljuk, hogy tegye ezt az összes olyan eszközén, amely „Cisco által ellenőrzött” identitással rendelkezik. Ha nem közli a Webex -szel, hogy melyik tartomány azonosítja az eszközt, a rendszer automatikusan kiválaszt egyet, és az értekezlet többi résztvevője számára hibásnak tűnhet.

Mielőtt elkezdené

Ha az eszközei még nincsenek regisztrálva, kövesse az alábbi lépéseket Regisztráljon egy eszközt a Cisco Webex rendszerébe API vagy helyi web felület segítségével vagy Felhőalapú beléptetés Board, Desk és Room sorozatokhoz . Ellenőrizze azt a tartományt is, amely(ek)ben az eszközöket azonosítani szeretné A tartományok kezelése .

1

Jelentkezzen be a Control Hub rendszerébe , és alatt Kezelés , válassza ki Eszközök lehetőségre .

2

Válasszon ki egy eszközt a konfigurációs paneljének megnyitásához.

3

Válassza ki az eszköz azonosításához használni kívánt tartományt.

4

Ismételje meg a műveletet más eszközök esetében is.

Mielőtt elkezdené

Szüksége van:

  • A CA által aláírt tanúsítvány és privát kulcs beszerzéséhez lépjen be .pem formátumban, minden eszköz számára.

  • A téma elolvasásához Az eszközök külső azonosítási folyamatának megértése , a Készüljön fel része ennek a cikknek.

  • JWE titkosítási eszköz elkészítése az ott található információk alapján.

  • Adott hosszúságú véletlenszerű bájtszekvenciák generálására szolgáló eszköz.

  • Egy eszköz bájtok vagy szöveg base64url kódolására.

  • An scrypt végrehajtását.

  • Egy titkos szó vagy kifejezés minden eszközhöz.

1

Töltse fel az eszközét ClientSecret egyszerű szöveges titkával:

Amikor először tölti fel a Secret, egyszerű szöveggel adja meg. Ezért javasoljuk, hogy ezt a fizikai eszköz konzolján tegye.

  1. A Base64url kódolja a titkos kifejezést ehhez az eszközhöz.

  2. Nyissa meg a TShell alkalmazást az eszközön.

  3. Futtatás xcommand Security ClientSecret Populate Secret: "MDEyMzQ1Njc4OWFiY2RlZg"

    A fenti példaparancs kitölti a Secret kifejezéssel 0123456789abcdef. Ki kell választania a sajátját.

Az eszköznek megvan a kezdeti titka. Ne felejtse el ezt; nem tudja visszaállítani, és az újraindításhoz gyári alaphelyzetbe kell állítania az eszközt.
2

A tanúsítvány és a privát kulcs összekapcsolása:

  1. Szövegszerkesztővel nyissa meg a .pem fájlokat, illessze be a kulcsblobot a tanúsítványblobba, és mentse el új .pem fájlként.

    (Ez az a hasznos szöveg, amelyet titkosítani kell, és el kell helyezni a JWE blobba)

3

Hozzon létre egy JWE-blobot, amelyet a tanúsítvány hozzáadása parancs bemeneteként használ:

  1. Hozzon létre egy legalább 4 bájtos véletlenszerű sorozatot. Ez a te sód.

  2. Hozzon létre tartalomtitkosítási titkosítási kulcs a scrypt eszközével.

    Ehhez szükség van a titkosításra, a sóértékre és a kiválasztott titkosítási kódnak megfelelő kulcshosszra. Más rögzített értékek is megadhatók (N=32768, r=8, p=1). Az eszköz ugyanazt a folyamatot és ugyanazt az értékeket használja ugyanazon tartalom- titkosítási kulcs származtatásához.

  3. Hozzon létre egy pontosan 12 bájtos véletlenszerű sorozatot. Ez az Ön inicializálási vektora.

  4. Hozzon létre egy JOSE fejlécet, beállítást alg, enc, és cisco-kdf pontban leírtak szerint Az eszközök külső azonosítási folyamatának megértése . Állítsa be az "hozzáadás" műveletet a kulcs:érték használatával "cisco-action":"add" a JOSE fejlécében (mert a tanúsítványt hozzáadjuk az eszközhöz).

  5. A Base64url a JOSE fejlécét kódolja.

  6. Használja a JWE titkosító eszközt a kiválasztott rejtjellel és a base64url kódolású JOSE fejléccel az összefűzött PEM fájl szövegének titkosításához.

  7. A Base64url kódolja az inicializálási vektort, a titkosított PEM hasznos adatot és a hitelesítési címkét.

  8. Állítsa össze a JWE blobot a következőképpen (minden érték base64url kódolású):

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4

Nyissa meg a TShell alkalmazást az eszközön, és futtassa a (többsoros) add parancsot:

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

Ellenőrizze, hogy a tanúsítvány hozzá lett adva futtatással xcommand Security Certificates Services Show

Másolja át az új tanúsítvány ujjlenyomatát.

6

Aktiválja a tanúsítványt erre a célra WebexIdentity:

  1. Olvassa be a tanúsítvány ujjlenyomatát, akár magából a tanúsítványból, akár a kimenetéből xcommand Security Certificates Services Show.

  2. Hozzon létre egy legalább 4 bájtos véletlenszerű sorozatot, és a base64url kódolja ezt a sorozatot. Ez a te sód.

  3. Hozzon létre tartalomtitkosítási titkosítási kulcs a scrypt eszközével.

    Ehhez szükség van a titkosításra, a sóértékre és a kiválasztott titkosítási kódnak megfelelő kulcshosszra. Más rögzített értékek is megadhatók (N=32768, r=8, p=1). Az eszköz ugyanazt a folyamatot és ugyanazt az értékeket használja ugyanazon tartalom- titkosítási kulcs származtatásához.

  4. Hozzon létre egy pontosan 12 bájtos véletlenszerű sorozatot, és a base64url kódolja ezt a sorozatot. Ez az Ön inicializálási vektora.

  5. Hozzon létre egy JOSE fejlécet, beállítást alg, enc, és cisco-kdf pontban leírtak szerint Az eszközök külső azonosítási folyamatának megértése . Állítsa be az "aktiválás" műveletet a key:value segítségével "cisco-action":"activate" a JOSE fejlécében (mert éppen aktiváljuk a tanúsítványt az eszközön).

  6. A Base64url a JOSE fejlécét kódolja.

  7. Használja a JWE titkosító eszközt a kiválasztott rejtjellel és a base64url kódolású JOSE fejléccel a tanúsítvány ujjlenyomatának titkosításához.

    Az eszköznek 16 vagy 32 bájtos szekvenciát kell kiadnia attól függően, hogy 128 vagy 256 bites AES-GCM-et választott, és egy hitelesítési címkét.

  8. A Base64urlencode a titkosított ujjlenyomatot és a hitelesítési címkét.

  9. Állítsa össze a JWE blobot a következőképpen (minden érték base64url kódolású):

    JOSEHeader..InitVector.EncryptedFingerprint.AuthTag

  10. Nyissa meg a TShell alkalmazást az eszközön, és futtassa a következő activate parancsot:

                      xcommand Security Certificates Services Activate Purpose: WebexIdentity Fingerprint: "Your..JWE.encrypted.fingerprint" 
                    
Az eszköz titkosított, aktív, CA által kibocsátott tanúsítvánnyal rendelkezik, amely készen áll a végpontok közötti titkosítású Webex értekezletek során történő azonosításra.
7

Helyezze be az eszközt a Control Hub-szervezetbe.

1

Ütemezzen egy megfelelő típusú értekezletet ( Webex Meetings Pro-End to End Encryption_ Csak VOIP ).

2

Csatlakozzon az értekezlethez szervezőként, Webex Meetings kliensből.

3

Csatlakozzon az értekezlethez egy olyan eszközről, amelynek azonosságát a Webex CA ellenőrizte.

4

Szervezőként ellenőrizze, hogy ez az eszköz a megfelelő identitás ikonnal jelenik-e meg az előszobában.

5

Csatlakozzon az értekezlethez olyan eszközről, amelynek azonosságát külső hitelesítésszolgáltató ellenőrizte.

6

Szervezőként ellenőrizze, hogy ez az eszköz a megfelelő identitás ikonnal jelenik-e meg az előszobában. Tudjon meg többet az identitás ikonokról .

7

Csatlakozzon az értekezlethez nem hitelesített értekezlet-résztvevőként.

8

Szervezőként ellenőrizze, hogy ez a résztvevő a megfelelő identitás ikonnal jelenik-e meg az előszobában.

9

Szervezőként fogadjon be vagy utasítson el személyeket/eszközöket.

10

A tanúsítványok ellenőrzésével lehetőség szerint ellenőrizze a résztvevő-/eszközazonosítókat.

11

Ellenőrizze, hogy az értekezlet minden résztvevője ugyanazt az értekezlet biztonsági kódját látja-e.

12

Csatlakozzon az értekezlethez egy új résztvevővel.

13

Ellenőrizze, hogy mindenki ugyanazt az új értekezletbiztonsági kódot látja-e.

A végpontok között titkosított értekezletek lesz az alapértelmezett értekezletbeállítás, vagy csak egyes felhasználók számára engedélyezi, vagy az összes szervező dönthet? Amikor eldöntötte, hogyan fogja használni ezt a funkciót, készítse fel azokat a felhasználókat, akik használni fogják, különös tekintettel a korlátozásokra és arra, hogy mire számíthatnak az értekezleten.

Biztosítania kell, hogy sem a Cisco , sem más ne tudja visszafejteni az Ön tartalmának titkosítását, és ne adja ki magát az eszközeinek? Ha igen, akkor nyilvános CA-tól származó tanúsítványokra van szüksége. Legfeljebb 25 eszköz lehet egy biztonságos értekezletben. Ha ilyen szintű biztonságra van szüksége, ne engedélyezze az értekezlet-ügyfelek csatlakozását.

A biztonságos eszközökkel csatlakozó felhasználók számára engedélyezze az eszközök csatlakozását először, és állítsa be azokat a felhasználói elvárásokat, amelyek szerint előfordulhat, hogy nem tudnak csatlakozni, ha későn csatlakoznak.

Ha a személyazonosság-ellenőrzés különböző szintjei vannak, engedélyezze a felhasználók számára, hogy hitelesítsék egymást a tanúsítvány által támogatott személyazonossággal és az értekezlet biztonsági kódjával. Annak ellenére, hogy vannak olyan körülmények, amikor a résztvevők ellenőrizetlenként jelenhetnek meg, és a résztvevőknek tudniuk kell, hogyan ellenőrizzék, az ellenőrizetlen személyek nem feltétlenül csalók.

Ha külső CA-t használ az eszköztanúsítványok kiadásához, akkor az Ön feladata a tanúsítványok figyelése, frissítése és újbóli alkalmazása.

Ha Ön hozta létre a kezdeti titkosságot, ne feledje, hogy a felhasználók esetleg módosítani szeretnék az eszközük titkát. Előfordulhat, hogy létre kell hoznia egy felületet/ki kell terjesztenie egy eszközt, hogy ezt lehetővé tegye.

1. táblázat Munkamenettípus-azonosítók végpontok között titkosított értekezletek számára

Munkamenettípus- azonosító

Közszolgálati név

638

Csak E2E Encryption+ VoIP

652

Pro-End-Encryption_ Csak VOIP

660

Pro 3 Free-End-Encryption_ Csak VOIP

E2E titkosítás + identitás

672

Pro 3 Free50-End-Encryption_ Csak VOIP

673

Oktatási oktató E2E Encryption_ Csak VOIP

676

Broadworks Standard plus végpontok közötti titkosítás

677

Broadworks Premium plus végpontok közötti titkosítás

681

Schoology Ingyenes plusz végpontok közötti titkosítás

Ezek a táblázatok a Webex -eszközök API -parancsait írják le, amelyeket a végpontok között titkosított értekezletekhez és ellenőrzött személyazonossághoz adtunk hozzá. Az API használatával kapcsolatos további információkért lásd: Hozzáférés a Webex Room and Desk Devices és a Webex táblák API -jához .

Ezek az xAPI-parancsok csak azokon az eszközökön érhetők el, amelyek:

  • Regisztrálva a Webex

  • Helyszíni regisztrációval és a helyszíni alkalmazással összekapcsolt Webex Webex Edge for Devices

2. táblázat Rendszerszintű API-k a végpontok között titkosított értekezletekhez és ellenőrzött személyazonossághoz

API-hívás

Leírás

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

Erre a konfigurációra akkor kerül sor, amikor a rendszergazda beállítja az eszköz előnyben részesített tartományát a Control Hubból. Csak akkor szükséges, ha a szervezetnek egynél több tartománya van.

Az eszköz ezt a tartományt használja, amikor tanúsítványt kér a Webex CA-tól. A tartomány ezután azonosítja az eszközt.

Ez a konfiguráció nem alkalmazható, ha az eszköz aktív, külsőleg kibocsátott tanúsítvánnyal rendelkezik az önazonosításra.

xStatus Conference EndToEndEncryption Availability

Jelzi, hogy az eszköz csatlakozhat-e egy végpontok között titkosított értekezlethez. A felhő API azért hívja meg, hogy a párosított alkalmazás tudja, tudja-e használni az eszközt a csatlakozáshoz.

xStatus Conference EndToEndEncryption ExternalIdentity Verification

Jelzi, ha az eszköz használja External hitelesítés (külsőleg kiállított tanúsítvánnyal rendelkezik).

xStatus Conference EndToEndEncryption ExternalIdentity Identity

Az eszköznek a külsőleg kibocsátott tanúsítvány közös nevéből kiolvasott azonosítója.

xStatus Conference EndToEndEncryption ExternalIdentity CertificateChain Certificate # specificinfo

Konkrét információkat olvas be egy külsőleg kibocsátott tanúsítványból.

A megjelenő parancsban cserélje ki # a tanúsítvány számával. Csere specificinfo a következők egyikével:

  • Fingerprint

  • NotAfter Érvényesség befejezés dátuma

  • NotBefore Érvényesség kezdés dátuma

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

  • Subject # Name A tanúsítvány alanyainak listája (pl. e- e-mail-cím vagy tartomány neve)

  • Validity A tanúsítvány érvényességi állapotát adja meg (pl valid vagy expired)

xStatus Conference EndToEndEncryption ExternalIdentity Status

Az eszköz külső azonosítójának állapota (pl valid vagy error).

xStatus Conference EndToEndEncryption InternalIdentity Verification

Jelzi, ha az eszköz rendelkezik a Webex CA által kiadott érvényes tanúsítvánnyal.

xStatus Conference EndToEndEncryption InternalIdentity Identity

Az eszköz Webex által kiadott tanúsítvány közös nevéből kiolvasott identitása.

tartomány neve tartalmaz, ha a szervezetnek van tartománya.

Üres, ha a szervezetnek nincs tartománya.

Ha az eszköz több tartományú szervezetben van, akkor ez az érték a következőből származik: PreferredDomain.

xStatus Conference EndToEndEncryption InternalIdentity CertificateChain Certificate # specificinfo

Konkrét információkat olvas be a Webex által kiadott tanúsítványból.

A megjelenő parancsban cserélje ki # a tanúsítvány számával. Csere specificinfo a következők egyikével:

  • Fingerprint

  • NotAfter Érvényesség befejezés dátuma

  • NotBefore Érvényesség kezdés dátuma

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

  • Subject # Name A tanúsítvány alanyainak listája (pl. e- e-mail-cím vagy tartomány neve)

  • Validity A tanúsítvány érvényességi állapotát adja meg (pl valid vagy expired)

3. táblázat. Hívás közbeni API-k végpontok között titkosított értekezletekhez és ellenőrzött személyazonossághoz

API-hívás

Leírás

xEvent Conference ParticipantList ParticipantAdded

xEvent Conference ParticipantList ParticipantUpdated

xEvent Conference ParticipantList ParticipantDeleted

Ez a három esemény most már tartalmazza EndToEndEncryptionStatus, EndToEndEncryptionIdentity, és EndToEndEncryptionCertInfo az érintett résztvevő számára.

4. táblázat. ClientSecret kapcsolódó API-k végpontok között titkosított értekezletekhez és ellenőrzött személyazonossághoz

API-hívás

Leírás

xCommand Security ClientSecret Populate Secret: "base64url-encoded"

vagy

xCommand Security ClientSecret Populate Secret: JWEblob

Elfogad egy base64url kódolású sima szöveg értéket az ügyfél titkos titkosságának első alkalommal történő elküldéséhez az eszközön.

A titkosítás első alkalommal történő frissítéséhez meg kell adnia egy JWE-blobot, amely tartalmazza az új titkosságot a régi titkosítással titkosítva.

xCommand Security Certificates Services Add JWEblob

Tanúsítvány hozzáadása (saját kulccsal).

Ezt a parancsot kiterjesztettük a titkosított PEM-adatokat tartalmazó JWE-blobok fogadására.

xCommand Security Certificates Services Activate Purpose:WebexIdentity FingerPrint: JWEblob

Egy adott tanúsítványt aktivál a WebexIdentity számára. Ehhez Purpose, a parancs megköveteli az azonosító ujjlenyomat titkosítását és szerializálását egy JWE-blobban.

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

Deaktivál egy adott tanúsítványt a WebexIdentity számára. Ehhez Purpose, a parancs megköveteli az azonosító ujjlenyomat titkosítását és szerializálását egy JWE-blobban.