Felhasználói élmény

A felhasználók az értekezlet ütemezésekor kiválasztják az értekezlet típusát. 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-ellenőrzési állapotát. Van egy értekezletkód is, amely az értekezlet összes jelenlegi résztvevője számára közös, és amellyel ellenőrizhetik, hogy az értekezletüket nem blokkolta-e egy nemkívánatos, harmadik féltől származó Meddler In The Middle (MITM) támadás.

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

Személyazonosság-ellenőrzés belső vagy külső hitelesítésszolgáltatóval

Identitás ellenőrzése

A végpontok közötti titkosítás személyazonosság-ellenőrzéssel további biztonságot nyújt a végpontok közti titkosítással rendelkező értekezleteknek.

Amikor a résztvevők vagy eszközök egy megosztott MLS (Messaging Layer Security) csoporthoz csatlakoznak, bemutatják tanúsítványaikat a csoport többi tagjának, akik ezután a kibocsátó hitelesítésszolgáltatókkal (CA) szemben érvényesítik a tanúsítványokat. A tanúsítványok érvényességének megerősítésével a hitelesítésszolgáltató ellenőrzi a résztvevők személyazonosságát, és az értekezlet hitelesített résztvevőként mutatja a résztvevőket/eszközöket.

A Webex alkalmazás felhasználói a Webex azonosítótárában végzik el a hitelesítést, amely hozzáférési tokent bocsát ki számukra, amikor a hitelesítés sikeres. Ha tanúsítványra van szükségük a személyazonosság ellenőrzéséhez egy végpontok közötti titkosítással rendelkező értekezleten, a Webex CA a hozzáférési tokenje alapján tanúsítványt ad ki nekik. Jelenleg nem biztosítunk módot a Webex Meetings felhasználói számára arra, hogy harmadik féltől/külső hitelesítésszolgáltatótól származó tanúsítványt kapjanak.

Az eszközök a belső (Webex) hitelesítésszolgáltató által kibocsátott tanúsítvánnyal vagy külső hitelesítésszolgáltató által kibocsátott tanúsítvánnyal hitelesíthetik magukat:

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

  • Külső hitelesítésszolgáltató – eszköztanúsítványokat kérhet és vásárolhat közvetlenül a kiválasztott kibocsátótól. Titkosítania kell, közvetlenül fel kell töltenie és engedélyeznie kell a tanúsítványokat egy csak Ön számára ismert titkos kóddal.

    A Cisco nem vesz részt benne, így garantálható a valódi, végpontok közötti titkosítás és hitelesített személyazonosság, továbbá megelőzhető annak elméleti lehetősége, hogy a Cisco lehallgathatja az értekezletét/visszafejtheti a médiát.

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

A Webex a rendszerindítás után tanúsítványt bocsát ki az eszközre, és szükség esetén megújítja. Eszközök esetében a tanúsítvány tartalmazza a fiók azonosítóját és egy tartományt.

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

Ha a szervezet több tartománnyal is rendelkezik, a Control Hub segítségével meghatározhatja a Webex számára, hogy az eszköz melyik tartományt használja az azonosításához. Használhatja a(z) xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com" API-t is.

Ha több tartománnyal rendelkezik, és nem állítja be az eszköz előnyben részesített tartományát, akkor a Webex kiválaszt egyet az Ön számára.

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

A rendszergazda saját tanúsítvánnyal is üzembe helyezhet egy eszközt, amelyet aláírt az egyik nyilvános hitelesítésszolgáltatóval.

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

A tanúsítványban szereplő értékek a szervezet belátása szerint vannak meghatározva. A köznapi név (CN) és a téma alternatív neve (SAN) megjelenik a Webex-értekezlet felhasználói felületén, a Webex Meetings végpontok közötti titkosítás személyazonosság-ellenőrzéssel című részben leírtak szerint.

Javasoljuk, hogy eszközönként használjon külön tanúsítványt, és rendelkezzen egyedi CN-vel. 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álással szembeni teljes védelme érdekében egy kliens-titkos funkciót használ a különböző xcommand-parancsok titkosítására és aláírására.

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

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

Funkciók és korlátok

Eszközök

A következő, felhőben regisztrált Webex Room sorozatú és Webex Desk sorozatú eszközök csatlakozhatnak az E2EE-értekezletekhez:

  • Webex Board tábla

  • Webex Desk Pro eszköz

  • Webex asztal

  • Webex tárgyalókészlet

  • Webex Room Kit mini

A következő eszközök nem tudnak csatlakozni E2EE-értekezletekhez:

  • Webex C sorozat

  • Webex DX sorozat

  • Webex EX sorozat

  • Webex MX sorozat

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

Szoftverkliensek

  • Az asztali és mobilos Webex alkalmazás ügyfelei csatlakozhatnak E2EE-értekezletekhez.

  • A Webex webkliens nem tud csatlakozni E2EE-értekezletekhez.

  • Harmadik féltől származó SIP szoftveres ügyfelek nem tudnak csatlakozni E2EE-értekezletekhez.

Identitás

  • Jellegénél fogva nem biztosítunk Control Hub-lehetőségeket a külsőleg ellenőrzött eszközazonosítás kezelésére. A valódi, végpontok közötti titkosításhoz csak a titkokat és a kulcsokat kell ismernie/hozzáférnie. Ha bevezetünk egy felhőszolgáltatást ezeknek a kulcsoknak a kezelésére, van rá esély, hogy blokkolják őket.

  • Jelenleg egy „receptet” biztosítunk Önnek, hogy az iparági szabványoknak megfelelő titkosítási technikákon alapuló saját eszközeit tervezze meg, hogy segítse az eszközazonosító tanúsítványok és a privát kulcsok kérelmezését vagy titkosítását. Nem akarunk valódi vagy észlelt hozzáférést a titkaihoz vagy kulcsaihoz.

Értekezletek

  • Az E2EE-értekezletek jelenleg legfeljebb 1000 résztvevőt támogatnak.

  • Az E2EE-értekezleteken új jegyzettáblákat oszthat meg. A rendszeres értekezletek során van néhány különbség a jegyzettábláktól:
    • Az E2EE-értekezleteken a felhasználók nem férhetnek hozzá az értekezleten kívül létrehozott jegyzettáblákhoz, beleértve a privát jegyzettáblákat, a mások által megosztott jegyzettáblákat és a Webex-szobákból származó jegyzettáblákat.
    • Az E2EE-értekezleteken létrehozott jegyzettáblák csak az értekezlet során érhetők el. Ezek nem kerülnek mentésre, és az értekezlet befejezése után nem érhetők el.
    • Ha valaki tartalmat oszt meg egy E2EE-értekezleten, akkor megjegyzéssel láthatja el. A megjegyzésekkel kapcsolatos további információkért lásd: Webex alkalmazás | Megosztott tartalom megjelölése megjegyzésekkel.

Kezelőfelület

Kifejezetten javasoljuk, hogy a Control Hub segítségével kezelje a Meetings-webhelyét, mivel a Control Hub-szervezetek az egész szervezetre vonatkozóan központosított identitással rendelkeznek.

Kiegészítő források
Előfeltételek

  • Webex Meetings 41.7.

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

  • Rendszergazdai hozzáférés a Control Hub értekezlet webhelyéhez.

  • Egy vagy több ellenőrzött tartomány az Ön Control Hub szervezetében (ha a Webex CA-t használja az ellenőrzött identitáshoz tartozó eszköztanúsítványok kibocsátására).

  • Be kell kapcsolni az együttműködési tárgyalókat, hogy az emberek a videórendszerükről csatlakozhassanak. További információkért lásd: Videorendszerek csatlakozásának engedélyezése értekezletekhez és eseményekhez a Webex-webhelyén.

Eszköztanúsítványok lekérése

Ezt a lépést kihagyhatja, ha nincs szüksége külsőleg ellenőrzött identitásokra.

A legmagasabb szintű biztonság és a személyazonosság-ellenőrzés érdekében minden eszköznek rendelkeznie kell egy megbízható nyilvános hitelesítésszolgáltató (CA) által kibocsátott egyedi tanúsítvánnyal.

Kapcsolatba kell lépnie a hitelesítésszolgáltatóval a digitális tanúsítványok leké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 kérésekor használja az alábbi paramétereket:

  • A tanúsítványt egy jól ismert nyilvános hitelesítésszolgáltatónak kell kibocsátania és aláírnia.

  • Egyedi: Határozottan javasoljuk, hogy minden eszközhöz egyedi tanúsítványt használjon. Ha az összes eszközhöz egy tanúsítványt használ, az veszélyezteti a biztonságot.

  • Általános név (CN) és téma másik megnevezése (SAN/k): Ezek a Webex számára nem fontosak, de értékeknek kell lenniük, amelyeket az emberek el tudnak olvasni és társítani az eszközzel. A CN az eszköz elsődleges hitelesített azonosítójaként jelenik meg az értekezlet többi résztvevője számára, és ha a felhasználók az értekezlet felhasználói felületén keresztül vizsgálják a tanúsítványt, akkor a SAN/mp-eket fogják látni. Előfordulhat, hogy olyan neveket szeretne használni, mint például name.model@example.com.

  • Fájlformátum: A tanúsítványoknak és kulcsoknak .pem formátumúnak kell lenniük.

  • Cél: A tanúsítvány céljának a 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 a P-256 görbét használva).

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

Felkészülés eszközök beléptetésére

Ezt a lépést kihagyhatja, ha nem szeretne külsőleg ellenőrzött identitást 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 érdekében ne csatlakoztassa őket a hálózathoz.

Ha rendelkezik olyan meglévő eszközökkel, amelyeket a külsőleg ellenőrzött személyazonosság használatához frissíteni szeretne, az eszközöket gyári alaphelyzetbe kell állítania.

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

  • Ütemezzen be egy ablakot, ha az eszközöket nem használja, 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ökhöz való fizikai hozzáférést. Ha hálózaton keresztül kell elérnie az eszközöket, ne feledje, hogy a titkok egyszerű szövegben utaznak, és veszélyezteti a biztonságot.

Miután befejezte ezeket a lépéseket, engedélyezze a videorendszerek számára, hogy csatlakozzanak értekezletekhez és eseményekhez a Webex-webhelyén.

Az eszközök külső identitási folyamatának megértése

Annak biztosítására, hogy az eszköz médiáját az eszközön kívül senki ne tudja titkosítani, a titkos kulcsot az eszközön kell titkosítania. API-kat terveztünk az eszközhöz, hogy lehetővé tegyük a titkosított kulcs és tanúsítvány JSON webes titkosítás (JWE) használatával történő kezelését.

Annak érdekében, hogy a felhőn keresztül valódi, végpontok közötti titkosítás valósuljon meg, nem avatkozhatunk be a tanúsítvány és a kulcs titkosításába és feltöltésébe. Ha ilyen szintű biztonságra van szüksége, a következőket kell tennie:

  1. Igényelje a tanúsítványokat.

  2. Saját tanúsítványok kulcspároinak létrehozása.

  3. Hozzon létre (és védje meg) egy kezdeti titkot minden egyes eszközhöz, hogy megpecsételje az eszköz titkosítási képességét.

  4. Fejlesszen ki és tartson karban saját eszközt a fájlok JWE szabvány szerinti titkosítására.

    Az alábbiakban ismertetjük a folyamatot és a (nem titkos) paramétereket, valamint a választott fejlesztési eszközökben követendő receptet. Emellett megadunk néhány teszteredményt és az eredményül kapott JWE-t, ahogy elvárjuk tőlük, hogy segítsenek ellenőrizni a folyamatot.

    A Cisco kérésre egy nem támogatott, Python3-at és a JWCrypto-könyvtárat használó referencia-végrehajtás érhető el.

  5. Egyesítse és titkosítsa a tanúsítványt és a kulcsot az eszköz és az eszköz kezdeti titkos kódja segítségével.

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

  7. Állítsa be a Webex azonosítá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 egy felületet az eszköze (vagy terjesztése) számára, amely lehetővé teszi, hogy az eszköz felhasználói megváltoztassák a kezdeti titkot, és megvédjék a médiát Öntől.

A JWE formátum használata

Ez a szakasz azt ismerteti, hogyan számítunk arra, hogy a JWE-t az eszközök bemeneteként hozzák létre, így Ön saját eszközt hozhat létre a tanúsítványokból és kulcsokból származó hibák létrehozásához.

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

JWE blobok létrehozásához a JSON-dokumentum Kompakt szerializálását használjuk. A JWE-blobok létrehozásakor szerepelnie kell a következő paramétereknek:

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

    • "alg":"dir"

      A közvetlen algoritmus az egyetlen, amelyet támogatunk a hasznos adatok titkosításához, és Önnek az eszköz eredeti klienstitká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 tulajdonosi kulcs, és négy értéket vehet fel. Ezt a kulcsot azért vezettük be, hogy jelezzük a titkosított adatok célját a céleszköznek. Az értékek az eszköz xAPI parancsai alapján kerülnek elnevezésre, ahol a titkosított adatokat használja.

      Azért neveztük el, cisco-action hogy enyhítsük az esetleges összecsapásokat a jövőbeli JWE bővítményekkel.

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

      Másik tulajdonosi kulcs. Az eszközön a kulcslevezetéshez megadott értékeket használjuk bemenetként. A(z) version értéknek 1 (a kulcsderivációs függvényünk verziója) kell lennie. A(z) salt értéknek legalább 4 bájtos base64 URL-kódolt sorozatnak kell lennie, amelyet véletlenszerűen kell kiválasztania.

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

  • JWE inicializációs vektor. Meg kell adnia a base64url kódolt inicializációs vektort a hasznos adat visszafejtéséhez. A IV MUST egy véletlenszerű 12 bájtos értéknek kell lennie (az AES-GCM rejtjelcsaládot használjuk, amely 12 bájt hosszúságot igényel).

  • JWE AAD (további hitelesített adatok). Ki kell hagynia ezt a mezőt, mert nem támogatott a Compact Serializációban.

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

    A hasznos adat üres LEHET. Például, ha vissza szeretné állítani a kliens titkos kódját, felül kell írni egy üres értékkel.

    Különböző típusú hasznos terhelések léteznek, attól függően, hogy mit próbál csinálni az eszközön. A különböző xAPI-parancsok különböző terheléseket várnak, és meg kell határoznia a terhelés célját a cisco-action kulccsal, az alábbiak szerint:

    • "cisco-action":"populate" A cipher szöveg az új ClientSecret.

    • A ""cisco-action":"add" a ciphertext egy PEM-blob, amely tartalmazza a tanúsítványt és annak titkos kulcsát (összekapcsolva).

    • A „"cisco-action":"activate" a cipher szöveg annak a tanúsítványnak az ujjlenyomata (sha-1 hexadecimális ábrázolása), amelyet aktiválunk az eszközazonosság ellenőrzéséhez.

    • A „"cisco-action":"deactivate" a cipherszöveg annak a tanúsítványnak az ujjlenyomata (az sha-1 hexadecimális ábrázolása), amelyet inaktiválunk a készülékazonosító-ellenőrzéshez való használatból.

  • JWE-hitelesítési címke: Ez a mező tartalmazza a hitelesítési címkét a teljes JWE kompakt szerializált blokk integritásának ellenőrzésére

Hogyan származtatjuk le a titkosítási kulcsot a ClientSecret

A titok első népessége után nem fogadjuk el vagy adjuk ki a titkot egyszerű szövegként. Ennek célja, hogy megakadályozza a lehetséges szótári támadásokat olyan személy részéről, aki hozzá tud férni az eszközhöz.

Az eszköz szoftvere a kliens titkát használja bemenetként egy kulcsderivációs függvényhez (kdf), majd a származtatott kulcsot használja a tartalom dekódolásához/titkosításához az eszközön.

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

Az eszközök a scrypt -t használják a kulcsderiváláshoz (lásd https://en.wikipedia.org/wiki/Scrypt), a következő paraméterekkel:

  • CostFactor (N) értéke 32768

  • BlockSizeFactor (r) értéke 8

  • ParallelizationFactor (p) értéke 1

  • A salt legalább 4 bájtos véletlenszerű szekvencia; ezt meg kell adni salt a cisco-kdf paraméter megadásakor.

  • A kulcshossz 16 byte (ha az AES-GCM 128 algoritmust választja) vagy 32 byte (ha az AES-GCM 256 algoritmust választja)

  • A maximális memóriaküszöb 64 MB

Ez a paraméterkészlet az egyetlen olyan scrypt konfigurációja, amely kompatibilis az eszközökön lévő kulcslevezetési funkcióval. Ezt a KDF-et az eszközökön "version":"1"-nek hívják, ez az egyetlen olyan verzió, amelyet a cisco-kdf paraméter elfogad.

Bevált példa

Az alábbi példa segítségével 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éldaprogram egy PEM blob hozzáadása az eszközhöz (egy tanúsítvány hozzáadását utánozza, egy nagyon rövid karakterlánccal a teljes tanúsítvány + kulcs helyett). A kliens titka a példában ossifrage.

  1. Titkosítási rejtjel kiválasztása. Ez a példa a következőt használja: A128GCM (AES 128 bites gombokkal Galois Counter módban). Az eszköz használhatja A256GCM ha szeretné.

  2. Válasszon saltot (legalább 4 bájtos véletlenszerű szekvenciának kell lennie). Ez a példa a következőt használja: (hexadecimális bájt)E5 E6 53 08 03 F8 33 F6. A base64 url kódolja a szekvenciát 5eZTCAP4M_Y (távolítsa el a base64 kitöltést).

  3. Íme egy mintahívás scrypt a tartalom titkosítási kulcsának (cek) létrehozásához:

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

    A származtatott kulcsnak 16 byte-nak (hexadecimálisnak) kell lennie az alábbiak szerint:95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac amely a base64url-t kódolja lZ66bdEiAQV4_mqdInj_rA-re.

  4. Válasszon ki egy 12 bájtos véletlenszerű sorozatot, amelyet inicializációs vektorként szeretne használni. Ez a példa az (hexadecimális) 34 b3 5d dd 5f 53 7b af 2d 92 95 83 amely a base64url-t NLNd3V9Te68tkpWD-re kódolja.

  5. Hozza létre a JOSE fejlécet kompakt szerializációval (kövesse az itt használt paraméterek sorrendjét), majd a base64url kódolja:

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

    A base64 url kódolt JOSE fejléc: eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

    Ez lesz a JWE blob első eleme.

  6. A JWE blokk második eleme üres, mert nem adunk JWE titkosítási kulcsot.

  7. A JWE blob harmadik eleme az inicializációs vektor NLNd3V9Te68tkpWD.

  8. A JWE titkosítási eszköz segítségével titkosított hasznos adatokat és címkét generálhat. Ebben a példában a titkosítatlan hasznos adat a hamis PEM blob lesz this is a PEM file

    A használni kívánt titkosítási paraméterek a következők:

    • Hasznos adat this is a PEM file

    • A titkosítási rejtjel AES 128 GCM

    • A base64 url a JOSE fejlécet kiegészítő hitelesített adatként (AAD) kódolja

    Base64url kódolja a titkosított hasznos adatokat, amelynek eredményeképp f5lLVuWNfKfmzYCo1YJfODhQ

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

  9. Base64url kódolja a 8. lépésben létrehozott címkét, ami azt eredményezi, hogy PE-wDFWGXFFBeo928cfZ1Q

    Ez az ötödik elem a JWE blokkban.

  10. Egyesítse az öt eleme a JWE blob pontok (JOSEheader..IV.Ciphertext.Tag), hogy:

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

  11. Ha ugyanazokat a base64url kódolt értékeket származtatott, mint amelyeket itt mutatunk, saját eszközeivel készen áll arra, hogy ezeket használni tudja az eszközök E2E titkosításának és hitelesített identitásá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, hogy a fent létrehozott JWE blob-ot használja bemenetként az xcommand-hez az eszközön, amely hozzáadja a tanúsítványt:

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

A zéró bizalmi értekezletek alkalomtípusai további költségek nélkül elérhetők az összes értekezletwebhely számára. Az egyik foglalkozástípus az úgynevezett Pro-End to End Encryption_VOIPonly. Ez a közszolgáltatás neve, amelyet a jövőben módosíthatunk. A foglalkozástípusok aktuális neveit lásd Foglalkozástípus-azonosítók a cikk Hivatkozás szakaszában.

Semmit sem kell tennie ahhoz, hogy ezt a funkciót elérje a webhelyén; meg kell adnia az új foglalkozástípust (amelyet Értekezletjogosultságnak is neveznek) a felhasználóknak. Ezt egyenként is megteheti a felhasználó konfigurációs oldalán, vagy tömegesen CSV-exportálással/importálással.

Az új foglalkozástípus ellenőrzése
1

Jelentkezzen be a Control Hubba, és lépjen a Szolgáltatások > Értekezletelemre.

2

Kattintson a Webhelyekelemre, válassza ki azt a Webex-webhelyet, amelynek beállításait módosítani szeretné, majd kattintson a Beállítások gombra.

3

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

Egy vagy több végpontok közötti titkosítással rendelkező foglalkozástípust kell látnia. Olvassa el a Foglalkozástípus-azonosítók listáját a cikk Hivatkozás szakaszában. Például látható a Pro-End to End Encryption_VOIPonly.

Van egy régebbi foglalkozástípus, nagyon hasonló névvel: Végpontok közötti titkosítás. Ez a foglalkozástípus magában foglalja az értekezletekhez való titkosítatlan PSTN-hozzáférést. A végpontok közötti titkosítás biztosítása érdekében győződjön meg arról, hogy rendelkezik a _VOIPonly verzióval. Ezt úgy ellenőrizheti, ha a foglalkozáskód oszlopban a PRO hivatkozás fölé viszi a mutatót; ebben a példában a hivatkozás céljának javascript:ShowFeature(652) kell lennie.

A jövőben megváltoztathatjuk ezeknek az alkalomtípusoknak a közszolgáltatási nevét.

4

Ha még nem rendelkezik az új foglalkozástípussal, vegye fel a kapcsolatot Webex képviselőjével.

A következő teendő

Engedélyezze ezt a foglalkozástípust/értekezletjogosultságot néhány vagy az összes felhasználója számára.

E2EE-értekezletek engedélyezése az egyes felhasználók számára
1

Jelentkezzen be a Control Hubba, és lépjen a Kezelés > Felhasználókelemre.

2

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

3

A Beállítások alkalmazása a legördülő listából válassza ki a frissítendő értekezlet webhelyét.

4

Jelölje be a Pro-End to End Encryption_VOIPonly jelölőnégyzetet.

5

Zárja be a felhasználói konfigurációs panelt.

6

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

Ha ezt sok felhasználóhoz szeretné hozzárendelni, használja a következő lehetőséget: E2EE-értekezletek engedélyezése több felhasználó számára.

E2EE-értekezletek engedélyezése több felhasználó számára
1

Jelentkezzen be a Control Hubba, és lépjen a Szolgáltatások > Értekezletelemre.

2

Kattintson a Webhelyekelemre, válassza ki azt a Webex-webhelyet, amelynek beállításait módosítani szeretné.

3

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

4

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

5

Amikor a fájl elkészült, kattintson az Exportálási eredmények , majd a Letöltés gombra. (Manuálisan kell bezárnia az előugró ablakot, miután a Letöltés gombra kattintott.)

6

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

Minden felhasználóhoz tartozik egy sor, és az MeetingPrivilege oszlop vesszővel tagolt listáként tartalmazza a foglalkozástípus azonosítóját.

7

Minden egyes felhasználónak, akinek engedélyezni szeretné az új foglalkozástípust, adja hozzá 1561 új értékként a cella vesszővel tagolt listájáhozMeetingPrivilege .

A Webex CSV-fájlformátumra vonatkozó hivatkozás a CSV-fájl céljáról és tartalmáról tartalmaz részleteket.

8

Nyissa meg az értekezletwebhely konfigurációs panelt a Control Hubban.

Ha már szerepelt az Értekezlet webhelylista oldalon, előfordulhat, hogy frissítenie kell azt.

9

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

10

Kattintson az Importálás gombra, és válassza ki a szerkesztett CSV-t, majd kattintson az Importálás gombra. Várjon, amíg a fájl feltöltésre kerül.

11

Amikor az importálás befejeződött, az Importálási eredmények elemre kattintva ellenőrizheti, hogy történt-e hiba.

12

Lépjen a Felhasználók oldalra, és nyissa meg az egyik felhasználót, és ellenőrizze, hogy az új foglalkozástípussal rendelkezik-e.

Hangvízjel hozzáadása a biztonság érdekében

Vízjelet adhat az értekezletfelvételekhez a Webex Meetings Pro-End to End Encryption_VOIPonly foglalkozás típusával, ami lehetővé teszi a bizalmas értekezletek jogosulatlan 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 Hubba, amely elemzi a felvételt, és megkeresi az egyedi azonosítókat. Az eredmények megtekintésével láthatja, hogy melyik forráskliens vagy eszköz rögzítette az értekezletet.

  • Az elemzés érdekében a felvételnek egy AAC, MP3, M4A, WAV, MP4, AVI vagy MOV fájlnak kell lennie, amely legfeljebb 500 MB lehet.
  • A felvételnek 100 másodpercnél hosszabb kell lennie.
  • Csak olyan értekezletek felvételeit tudja elemezni, amelyeket a szervezetében lévő személyek szerveznek.
  • A vízjelinformációk a szervezet értekezletinformációival megegyező ideig maradnak meg.

Hangvízjelek hozzáadása E2EE-értekezletekhez

  1. Jelentkezzen be a Control Hub rendszerébe, majd a Kezelés alatt válassza a Szervezeti beállításoklehetőséget.
  2. Az Értekezletvízjelek szakaszban kapcsolja be a Hangvízjel hozzáadása lehetőséget.

    Valamivel a beállítás bekapcsolása után a Webex Meetings Pro-End to End Encryption_VOIPonly foglalkozástípussal ütemező felhasználók Digitális vízjel lehetőséget látnak a Biztonság részben.

Vízjeles értekezlet feltöltése és elemzése

  1. A Control Hubban, a Felügyelet alatt válassza a Hibaelhárítás lehetőséget.
  2. Kattintson a Vízjel elemzése lehetőségre.
  3. Keresse meg vagy válassza ki az értekezletet a listában, majd kattintson az Elemzés gombra.
  4. A Hangvízjel elemzése ablakban adja meg az elemzés nevét.
  5. (Nem kötelező) Adjon meg egy megjegyzést az elemzéséhez.
  6. Húzza át az elemzendő hangfájlt, vagy kattintson a Fájl kiválasztása gombra a hangfájl böngészéséhez.
  7. Kattintson a Bezárás gombra.

    Az elemzés befejezésekor megjelenik az eredmények listájában a Vízjel elemzése oldalon.

  8. Az elemzés eredményeinek megtekintéséhez válassza ki az értekezletet a listában. Kattintson Letöltés gomb az eredmények letöltéséhez.

Funkciók és korlátok

A rögzített vízjel sikeres dekódolásában szerepet játszó tényezők közé tartozik a felvételi eszköz és a hangot kimenő hangszóró közötti távolság, a hang hangereje, a környezeti zaj stb. A vízjel technológiánk ellenállóbbá teszi a többszöri kódolást, mint például a média megosztásakor.

Ezt a funkciót úgy tervezték, hogy széles, de ésszerű körülmények között lehetővé tegye a vízjel-azonosító sikeres dekódolását. Célunk, hogy egy személyes végpont vagy laptop kliens közelében lévő íróasztalon elhelyezett felvevő eszköz, például mobiltelefon esetén mindig készítsen egy sikeres elemzést eredményező felvételt. Mivel a rögzítőeszköz távol kerül a forrástól, vagy elrejtve van a teljes hangspektrum hallgatása elől, csökken a sikeres elemzés esélye.

A felvétel sikeres elemzéséhez az értekezlet hangjának észszerű rögzítésére van szükség. Ha egy értekezlet hangját ugyanazon a számítógépen rögzítik, amelyen az ügyfélnek helyet kap, a korlátozások nem alkalmazhatók.

Eszközök beléptetése (belső CA)

Ha az eszközök már be vannak vonva a Control Hub szervezetébe, és a Webex CA-t szeretné használni az azonosító tanúsítványok automatikus létrehozásához, nem kell gyári alaphelyzetbe állítania az eszközöket.

Ez az eljárás kiválasztja, hogy az eszköz melyik tartományt használja önazonosításra, és csak akkor szükséges, ha több tartomány is van a Control Hub szervezetében. Ha egynél több tartománnyal rendelkezik, azt javasoljuk, hogy ezt tegye minden olyan eszközénél, amely „Cisco által ellenőrzött” azonosítással rendelkezik. Ha nem mondja meg a Webex-nek, hogy melyik tartományt azonosítja az eszközt, akkor a rendszer automatikusan kiválaszt egyet, és ez hibásnak tűnhet az értekezlet többi résztvevője számára.

Mielőtt elkezdené

Ha az eszközei még nincsenek beléptetve, kövesse az Eszköz regisztrálása a Cisco Webexbe API vagy helyi webinterfész használatával vagy a Felhőalapú bejelentkezés Board, Desk és Room sorozatú eszközökhözparancsokat. Ellenőriznie kell a Tartományok kezelése menüpontban az eszközök azonosításához használni kívánt tartományt/tartományokat is.

1

Jelentkezzen be a Control Hubba, és a Kezelés csoportban válassza az Eszközöklehetőséget.

2

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

3

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

4

Ismétlés más eszközök esetén.

Eszközök beléptetése (külső hitelesítésszolgáltató)

Mielőtt elkezdené

  • Kérjen CA által aláírt tanúsítványt és titkos kulcsot .pem minden eszközhöz.

  • Az Előkészítés lapon olvassa el a Külső identitásfolyamat megértése az eszközöknél című témakört,

  • Készítsen elő egy JWE titkosítási eszközt az ott található információk tekintetében.

  • Bizonyosodjon meg arról, hogy rendelkezik egy eszközzel adott hosszúságú véletlenszerű bájtsorozatok létrehozására.

  • Bizonyosodjon meg arról, hogy van eszköze a byte- vagy szövegkódoláshoz64 URL-hez.

  • Győződjön meg róla, hogy van scrypt implementációja.

  • Győződjön meg arról, hogy minden eszközhöz tartozik egy titkos szó vagy kifejezés.

1

Töltse fel az eszköz eszközét ClientSecret egy egyszerű, titkos szöveggel:

Amikor először kitölti a(z) Secret eszközt, egyszerű szövegként adja meg. Ezért javasoljuk, hogy ezt a fizikai eszköz konzolján tegye meg.

  1. A base64url az eszköz titkos kifejezését kódolja.

  2. Nyissa meg a TShell-ot az eszközön.

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

    A fenti példa parancs feltölti a(z) Secret -t a(z) 0123456789abcdef kifejezéssel. Ki kell választania a sajátját.

Az eszköz rendelkezik a kezdeti titkos kóddal. Ezt ne felejtse el; nem tudja visszaállítani, és az újraindításhoz gyári alaphelyzetbe kell állítani az eszközt.
2

Egyesítse a tanúsítványt a titkos kulccsal:

  1. Szövegszerkesztő használatával nyissa meg a .pem fájlokat, illessze be a kulcsot a tanúsítványkiadóba, és mentse el új .pem fájlként.

    Ez az a hasznos szöveg, amelyet titkosítani fog, és a JWE-szoftverbe helyezi.

3

Hozzon létre egy JWE-blokkot, amelyet bemenetként használhat a tanúsítvány-hozzáadás parancshoz:

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

  2. Származtasson le tartalom-titkosítási kulcsot a Scrypt eszközzel.

    Ehhez a választott titkosítási rejtjelnek megfelelő titkos kódra, sóra és kulcshosszra van szükség. Van még néhány egyéb rögzített érték is (N=32768, r=8, p=1). Az eszköz ugyanazokat a folyamatokat és értékeket használja ugyanannak a tartalomtitkosítási kulcsnak a levezetéséhez.

  3. Hozzon létre egy pontosan 12 bájtos véletlenszerű sorrendet. Ez az Ön inicializációs vektora.

  4. Hozzon létre egy JOSE-fejlécet, beállítást alg, encés cisco-kdf kulcsokat a Külső identitásfolyamat megértése az eszközökhöz című részben leírtak szerint. Állítsa be a „hozzáadás” műveletet a "cisco-action":"add" JOSE fejlécben található kulcs:érték használatával (mivel hozzáadjuk a tanúsítványt az eszközhöz).

  5. A base64url a JOSE fejlécet kódolja.

  6. Használja a JWE titkosítási eszközt a választott rejtjelrel és a base64url kódolt JOSE fejléccel az összekapcsolt pem fájl szövegének titkosításához.

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

  8. Építsd meg a JWE blob-t az alábbiak szerint (minden érték base64url kódolva van):

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4

Nyissa meg a TShell eszközt 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 hozzáadta-e a tanúsítványt a következővel: xcommand Security Certificates Services Show

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

6

A tanúsítvány aktiválása a következő célra: WebexIdentity:

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

  2. Hozzon létre egy legalább 4 bájtos véletlenszerű sorrendet, és a base64 url kódolja azt. Ez a te sód.

  3. Származtasson le tartalom-titkosítási kulcsot a Scrypt eszközzel.

    Ehhez a választott titkosítási rejtjelnek megfelelő titkos kódra, sóra és kulcshosszra van szükség. Van még néhány egyéb rögzített érték is (N=32768, r=8, p=1). Az eszköz ugyanazokat a folyamatokat és értékeket használja ugyanannak a tartalomtitkosítási kulcsnak a levezetéséhez.

  4. Hozzon létre egy pontosan 12 bájtos véletlenszerű sorrendet, és a base64 url kódolja azt. Ez az Ön inicializációs vektora.

  5. Hozzon létre egy JOSE-fejlécet, beállítást alg, encés cisco-kdf kulcsokat a Külső identitásfolyamat megértése az eszközökhöz című részben leírtak szerint. Állítsa be az „aktiválás” műveletet a "cisco-action":"activate" JOSE fejlécben szereplő kulcs:érték használatával (mivel aktiváljuk a tanúsítványt az eszközön).

  6. A base64url a JOSE fejlécet kódolja.

  7. A tanúsítvány-ujjlenyomat titkosításához használja a JWE titkosítási eszközt a kiválasztott rejtjelrel és a base64url kódolt JOSE fejléccel.

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

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

  9. Építsd meg a JWE blob-t az alábbiak szerint (minden érték base64url kódolva van):

    JOSEHeader..InitVector.EncryptedFingerprint.AuthTag

  10. Nyissa meg a TShell alkalmazást az eszközön, és futtassa a következő aktiválási 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ással rendelkező Webex-értekezletek azonosítására.
7

Kapcsolja be az eszközt a Control Hub szervezetébe.

Végpontok közötti titkosítás tesztelése személyazonosság-ellenőrzéssel
1

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

Lásd: Webex-értekezlet ütemezése végpontok közötti titkosítással.

2

Csatlakozzon az értekezlethez szervezőként egy Webex Meetings ügyfélről.

Lásd: Csatlakozás Webex-értekezlethez végpontok közötti titkosítással.

3

Csatlakozzon az értekezlethez egy olyan eszközről, amelynek a személyazonosságát a Webex hitelesítésszolgáltató 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.

Lásd: Csatlakozás Webex-értekezlethez végpontok közötti titkosítással.

5

Csatlakozzon az értekezlethez olyan eszközről, amelynek a személyazonossá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. További részletek az identitásikonokról.

7

Csatlakozzon az értekezlethez nem hitelesített résztvevőként az értekezletek során.

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 beengedhet vagy utasíthat el személyeket/eszközöket.

10

Lehetőség szerint a tanúsítványok ellenőrzésével érvényesítse a résztvevő/eszköz identitását.

11

Ellenőrizze, hogy az értekezlet összes résztvevője ugyanazt az értekezletbiztonsági kódot 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.

Hatókör és elvárások beállítása

  • A végpontok közti titkosítással rendelkező értekezleteket fogja az értekezlet alapértelmezett opciójává tenni, vagy csak néhány felhasználó számára engedélyezi azt, vagy pedig minden szervező dönti el ezt? Miután eldöntötte, hogyan fogja használni ezt a funkciót, készítse elő 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íthat az értekezleten.

  • Gondoskodnia kell arról, hogy sem a Cisco, sem bárki más nem tudja visszafejteni a tartalmát, illetve megszemélyesíteni az eszközeit? Ebben az esetben nyilvános hitelesítésszolgáltatótól származó tanúsítványokra van szükség.

  • Ha a személyazonosság-ellenőrzés különböző szintekkel rendelkezik, tegye lehetővé a felhasználók számára, hogy tanúsítvány-alapú személyazonossággal ellenőrizzék egymást. Bár vannak olyan körülmények, amikor a résztvevők ellenőrizetlenként jelenhetnek meg, és a résztvevőknek tudniuk kell, hogyan kell ellenőrizni, a nem ellenőrzött személyek nem lehetnek csalók.

Identitáskezelés

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

Ha létrehozta az eredeti titkot, vegye figyelembe, hogy a felhasználók szeretnék módosítani az eszközük titkosítását. Lehet, hogy létre kell hoznia egy felületet/eszközt ahhoz, hogy ezt megtehesse.

Alkalomtípus azonosítói
1. táblázat A végpontok között titkosított értekezletek alkalomtípusazonosítói

Alkalomtípus azonosítója

Közszolgáltatás neve

638

E2E titkosítás+csak VoIP

652

Pro-végponttól végpontig csakncryption_VOIP

660

Pro 3 Ingyenes végponttól végpontig Encryption_VOIPcsak

E2E titkosítás + identitás

672

Pro 3 Free50 végponttól végpontigncryption_csak VOIP

673

Oktatási oktató – E2Encryption_VOIPonly

676

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

677

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

681

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

Kapcsolódó xAPI parancsok

Ezek a táblázatok ismertetik a Webex-eszközök API-parancsait, amelyeket a végpontok közötti titkosítással rendelkező értekezletekhez és hitelesített személyazonossághoz adtunk hozzá. Az API használatáról további információt az API elérése Webex Room és Desk eszközökhöz és Webex Board táblákhoz című részben talál.

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

  • Regisztrálva a Webex rendszerében

  • Telephelyi regisztrálva és a Webexhez a Webex Edge for Devices segítségével társítva

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

API-hívás

Leírás

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

Ez a konfiguráció akkor történik meg, 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 szervezet több tartománnyal rendelkezik.

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, amellyel azonosítja magát.

xStatus Conference EndToEndEncryption Availability

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

xStatus Conference EndToEndEncryption ExternalIdentity Verification

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

xStatus Conference EndToEndEncryption ExternalIdentity Identity

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

xStatus Conference EndToEndEncryption ExternalIdentity CertificateChain Certificate # specificinfo

Külsőleg kiadott tanúsítványból beolvassa a konkrét információkat.

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

  • Fingerprint

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

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

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

  • Subject # Name A tanúsítvány tárgyainak listája (pl. e-mail-cím vagy tartománynév)

  • 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ő identitásának állapota (pl. valid vagy error).

xStatus Conference EndToEndEncryption InternalIdentity Verification

Azt jelzi, hogy az eszköz rendelkezik-e a Webex CA által kibocsátott érvényes tanúsítvánnyal.

xStatus Conference EndToEndEncryption InternalIdentity Identity

Az eszköz azonosítója a Webex által kibocsátott tanúsítvány általános nevéből olvasva.

Tartománynevet tartalmaz, ha a szervezetnek van tartománya.

Üres, ha a szervezetnek nincs tartománya.

Ha az eszköz egy több tartománnyal rendelkező szervezetben található, akkor ez az érték a következőből: PreferredDomain.

xStatus Conference EndToEndEncryption InternalIdentity CertificateChain Certificate # specificinfo

Beolvassa a Webex által kibocsátott tanúsítvány konkrét információit.

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

  • Fingerprint

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

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

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

  • Subject # Name A tanúsítvány tárgyainak listája (pl. e-mail-cím vagy tartománynév)

  • 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 a végpontok között titkosított értekezletekhez és hitelesített 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 mostantól magában foglalja a(z) EndToEndEncryptionStatus, EndToEndEncryptionIdentity és EndToEndEncryptionCertInfo az érintett résztvevő számára.

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

API-hívás

Leírás

xCommand Security ClientSecret Populate Secret: "base64url-encoded"

vagy

xCommand Security ClientSecret Populate Secret: JWEblob

A base64url kódolt egyszerű szöveges értéket fogad el a kliens titkos kódjának első alkalommal történő elhelyezésére.

Ahhoz, hogy a titkot ez után az első alkalommal frissítse, be kell nyújtania egy JWE-blob-t, amely tartalmazza a régi titok által titkosított új titkot.

xCommand Security Certificates Services Add JWEblob

Hozzáad egy tanúsítványt (privát kulccsal).

Kiterjesztettük ezt a parancsot, hogy elfogadjunk egy titkosított PEM adatokat tartalmazó JWE-blob-t.

xCommand Security Certificates Services Activate Purpose:WebexIdentity FingerPrint: JWEblob

Aktiválja a WebexIdentity-hez tartozó tanúsítványt. Ehhez Purposea parancshoz az azonosító ujjlenyomatot JWE-blokkban kell titkosítani és szerializálni.

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

Inaktiválja a WebexIdentity-hez tartozó tanúsítványt. Ehhez Purposea parancshoz az azonosító ujjlenyomatot JWE-blokkban kell titkosítani és szerializálni.