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-gazdákkal:

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 hitelesíthetik magukat a belső (Webex) hitelesítésszolgáltató által kiadott tanúsítvánnyal vagy egy külső hitelesítésszolgáltató által kiadott tanúsítvánnyal:

  • 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 a Webex CA írta alá. 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. A tanúsítványokat csak az Ön által ismert titokban kell titkosítania, közvetlenül feltöltenie és engedélyeznie.

    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 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ében a tanúsítvány tartalmazza a fiókazonosítót és a tartományt.

Ha a szervezet nem rendelkezik tartománysal, a Webex hitelesítésszolgáltató 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 meg tudja mondani a Webexnek, hogy melyik tartományt használja az eszköz az identitásához. Használhatja az xConfiguration Conference EndToEndEncryption Identity PreferredDomain: „example.com” API-t is.

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

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

A rendszergazda saját tanúsítvánnyal rendelkező eszközt hozhat ki, amelyet az egyik nyilvános hitelesítésszolgáltatóval írtak alá.

A tanúsítványnak 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. 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.

Annak érdekében, hogy teljes mértékben megvédje a külső tanúsítványt a manipulációtól, egy ügyféltitkos funkcióval titkosítják és aláírják a különböző xcommandokat.

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 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őben regisztrált Webex Room sorozatú és Webex Desk sorozatú eszközök csatlakozhatnak az E2EE-é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 E2EE-értekezletekhez:

  • Webex C sorozat

  • Webex DX sorozat

  • Webex EX sorozat

  • Webex MX sorozat

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

Szoftveres ügyfelek

  • 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 bevezettünk egy felhőszolgáltatást a kulcsok kezelésére, akkor van esély arra, hogy elfogjá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 vélt hozzáférést a titkaihoz vagy kulcsaihoz.

Meetings

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

  • Webex találkozók 41.7.

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

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

  • A Control Hub szervezet egy vagy több ellenőrzött tartománya (ha a Webex hitelesítésszolgáltatót használja az ellenőrzött identitáshoz használt eszköztanúsítványok kiállítására).

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

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.

A digitális tanúsítványok igénylése, megvásárlása és fogadása, valamint a kapcsolódó személyes kulcsok létrehozásához kapcsolatba kell lépnie a hitelesítésszolgáltatóval. 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 kiállítania és aláírnia.

  • Egyedülálló: Javasoljuk, hogy minden eszközhöz használjon egyedi tanúsítványt. Ha egy tanúsítványt használ az összes eszközhöz, veszélyezteti a biztonságot.

  • Köznapi név (CN) és tárgy alternatív neve(i)k (SAN/s): Ezek nem fontosak a Webex számára, de olyan értékeknek kell lenniük, amelyeket az emberek olvashatnak és társíthatnak az eszközhöz. A CN az értekezlet többi résztvevőjének mutatja meg az eszköz elsődleges ellenőrzött személyazonosságát, és ha a felhasználók az értekezlet felhasználói felületén keresztül ellenőrzik a tanúsítványt, látni fogják a SAN/s-t. Előfordulhat, hogy olyan neveket szeretne használni, mint name.model@example.com.

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

  • Cél: A tanúsítvány célja a Webex Identity kell, hogy legyen.

  • Kulcsok generálása: A tanúsítványoknak ECDSA P-256 kulcspárokon kell alapulniuk (elliptikus görbe digitális aláírási algoritmus a P-256 görbével).

    Ez a követelmény nem terjed ki az aláíró kulcsra. A hitelesítésszolgáltató RSA-kulccsal aláírhatja a tanúsítványt.

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-re. 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 az elvárt változásokról.

  • Fizikai hozzáférés biztosítása az eszközökhöz. Ha a hálózaton keresztül kell hozzáférnie az eszközökhöz, vegye figyelembe, 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.

Annak érdekében, hogy az eszköz adathordozóját az eszközön kívül senki ne tudja titkosítani, titkosítania kell az eszközön lévő személyes kulcsot. 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ást biztosítsunk, 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ányokat.

  2. Hozza létre a tanúsítványok kulcspárját.

  3. Hozzon létre (és védjen) egy kezdeti titkot minden eszközhöz, hogy elültesse az eszköz titkosítási képességét.

  4. Fejlessze és karbantartsa saját eszközét a fájlok titkosítására a JWE szabvány használatával.

    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. Néhány tesztadatot és az ebből eredő JWE-blobokat is biztosítjuk, ahogy várjuk őket, hogy segítsünk a folyamat ellenőrzésében.

    Kérésre nem támogatott referencia-implementáció érhető el a Cisco-tól a Python3 és a JWCrypto könyvtár használatával.

  5. Összefűzheti és titkosíthatja a tanúsítványt és a kulcsot az eszközzel és az eszköz kezdeti titkával.

  6. Töltse fel a 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 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.

Hogyan használjuk a JWE formátumot?

Ez a szakasz azt ismerteti, hogyan várjuk el, hogy a JWE az eszközök bemeneteként jön létre, í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 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-objektum aláírása és titkosítása 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 adat titkosításához, és az eszköz kezdeti ügyféltitkját kell használnia.

    • "enc":"A 352GCM" vagy "enc":"A 352GCM"

      Támogatjuk ezt a két titkosítási algoritmust.

    • „cisco-action”: „add” vagy „cisco-action”: „populate” vagy „cisco-action”: „aktiválás” vagy „cisco-action”: „deaktiválás”

      Ez egy szabadalmaztatott kulcs és négy érték, amit el lehet venni. Ezt a kulcsot azért vezettük be, hogy jelezzük a titkosított adatok célját a céleszközre. Az értékeket a titkosított adatokat használó eszközön található xAPI parancsokról nevezik el.

      Cisco-action névre keresztelt, hogy enyhítse a jövőbeli JWE-bővítményekkel való lehetséges ütközéseket.

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

      Egy másik szabadalmaztatott kulcs. Az Ön által megadott értékeket bemenetként használjuk az eszköz kulcsfontosságú származtatásához. A verziónak1 -nek kell lennie (a kulcsderivációs függvényünk verziója). A salt értéknek legalább 4 bájtos base64 URL-kódolt sorozatnak kell lennie, amelyet véletlenszerűen kell kiválasztani.

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

  • JWE inicializációs vektor. A hasznos teher visszafejtéséhez meg kell adnia egy base64url kódolású inicializálási vektort. A IV-nek véletlenszerű 12 bájt értékűnek kell lennie (az AES-GCM titkosítási családot használjuk, amely megköveteli, hogy a IV 12 bájt hosszú legyen).

  • JWE AAD (további hitelesített adatok). Ezt a mezőt ki kell kihagynia, mert a Kompakt szerializálás nem támogatja.

  • JWE-címerszöveg: Ez az a titkosított hasznos teher, 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 vannak, attól függően, hogy mit próbál tenni az eszközön. A különböző xAPI-parancsok különböző terheléseket várnak, és a Cisco-action gombbal meg kell határoznia a terhelés célját az alábbiak szerint:

    • A "cisco-action" esetén:"populate" a cipherszöveg az új ClientSecret.

    • A „„cisco-action”:„add” karakterrel a cipherszöveg egy PEM-füzet, amely tartalmazza a tanúsítványt és annak titkos kulcsát (összekapcsolva).

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

    • A „„cisco-action”:„deactivate” funkcióval a cipherszöveg annak a tanúsítványnak az ujjlenyomata (az sha-1 hexadecimális ábrázolása) lesz, amelyet inaktiválunk az eszközazonosító ellenőrzésére.

  • JWE hitelesítési címke: Ez a mező tartalmazza a hitelesítési címkét a teljes JWE tömörített szerializált blob integritásának megállapításához

Hogyan származtatjuk le a titkosítási kulcsot a ClientSecret-ből

A titok első populációja után nem fogadjuk el vagy iktjuk ki a titkot egyszerű szövegként. Ez megakadályozza az eszközhöz hozzáférő személy esetleges szótári támadásait.

Az eszközszoftver az ügyfél titkos kulcsát használja egy kulcsfontosságú származtatási függvény (kdf) bemeneteként, majd a származtatott kulcsot használja az eszközön lévő tartalom visszafejtéséhez / titkosításához.

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

Az eszközök a scrypt-et használják a kulcs származtatásához (lásd ), a következő https://en.wikipedia.org/wiki/Scryptparaméterekkel:

  • CostFactor (N) a 32768

  • BlockSizeFactor (r) 8

  • A párhuzamosítási tényező (p) 1

  • A salt legalább 4 bájtos véletlenszerű szekvencia; ugyanazt a sót kell megadni a cisco-kdf paraméter megadásakor.

  • A kulcs hossza 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ória sapka 64 MB

Ez a paraméterkészlet a kripta egyetlen olyan konfigurációja, amely kompatibilis az eszközök kulcs származtatási funkciójával. Ezt a KDF-et az eszközökön „version”-nek hívják:„1”, amely az egyetlen verzió, amelyet jelenleg használ a cisco-kdf paraméter.

Bevált példa

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

A példa forgatókönyve egy PEM-blob hozzáadása az eszközhöz (a 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 az ossifrage.

  1. Válasszon egy titkosítási titkosítási titkosítást. Ez a példa az A 002GCM -et használja (128 bites gombokkal rendelkező AES Galois Counter módban). Az eszköz használhatná a GCM-et , ha szeretné.

  2. Válasszon egy sót (legalább 4 bájt 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 az 5eZTCAP4M_Y megszerzéséhez (távolítsa el a base64 kitöltést).

  3. Íme egy mintapéldány a tartalom titkosítási kulcsának (cek) létrehozásához:

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

    A származtatott kulcsnak 16 bájtnak (hexának) 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 a lZ66bdEiAQV4_mqdInj_rA-ra kódolja.

  4. Válasszon egy 12 bájtból álló véletlenszerű szekvenciát inicializálási vektorként. Ez a példa a (hex) 34 b3 5d dd 5f 53 7b af 2d 92 95 83 módszert használja, amely a base64url-t az NLNd3V9Te68tkpWD-re kódolja.

  5. Hozza létre a JOSE fejlécet kompakt szerializációval (kövesse ugyanazt a paramétersort, amelyet itt használunk), majd a base64url kódolja:

    {"alg":"dir","cisco-action":"add","cisco-kdf":{"salt":"5eZTCAP4M_Y","verzió":"1"},"enc":"A 002GCM"}

    A base64url kódolt JOSE fejléc a következő: eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

    Ez lesz a JWE blob első eleme.

  6. A JWE blob második eleme üres, mert nem biztosítunk JWE titkosítási kulcsot.

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

  8. A JWE titkosítási eszközzel titkosított hasznos adat és címke készülhet. Ebben a példában a titkosítatlan hasznos adat a hamis PEM-blob lesz ez egy PEM-fájl

    A használnod kell a titkosítási paraméterek a következők:

    • A hasznos adat ez egy PEM-fájl

    • Titkosítási titkosítás: AES 128 GCM

    • A base64url jose fejlécet további hitelesített adatként (AAD) kódolta

    Base64url kódolja a titkosított hasznos adatokat, amelynek eredménye az f5lLVuWNfKfmzYCo1YJfODhQ

    Ez a JWE-blob negyedik eleme (JWE Ciphertext).

  9. Base64url kódolja a 8. lépésben létrehozott címkét, amelynek eredménye a következő lesz: PE-wDFWGXFFBeo928cfZ1Q

    Ez a JWE blob ötödik eleme.

  10. A JWE blob öt elemét összefűzi üssd (JOSEheader.). IV.Ciphertext.Tag) a következőhöz:

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjvlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

  11. Ha ugyanazokat a base64url kódolású értékeket szerezte be, mint amit itt mutatunk, saját eszközeivel készen áll arra, hogy ezeket használja az E2E titkosítás és az eszközök ellenőrzött 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 a fent létrehozott JWE blob használata lenne a tanúsítványt adó eszköz xcommand bemeneteként:

    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 neve Pro-End to End Encryption_VOIPonly. Ez a közszolgáltatás neve, amelyet a jövőben módosíthatunk. A munkamenettípusok aktuális neveit a cikk Hivatkozás szakaszában található Munkamenettípus-idák című témakörben találja.

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 egyénileg is megteheti a felhasználó konfigurációs oldalán, vagy tömegesen CSV exportálással/importálással.

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
Egy vagy több végpontok közötti titkosítással rendelkező foglalkozástípust kell látnia. A cikk Hivatkozási szakaszában található munkamenettípus-idák listája. Láthatja például a Pro-End to End Encryption_VOIPonlyelemet.

Van egy régebbi munkamenettípus, nagyon hasonló névvel: Végpontok közötti titkosítás. Ez a munkamenettípus nem titkosított PSTN-hozzáférést tartalmaz az értekezletekhez. 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. Ellenőrizheti, ha a munkamenet kód oszlopában a PRO hivatkozás fölé viszi a mutatót; ebben a példában a hivatkozás céljának a javascript:ShowFeature(652) kell lennie.

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

5

Ha még nem rendelkezik az új munkamenettípussal, forduljon a Webex képviselőjéhez.

Mi a következő lépés

Engedélyezze ezt a munkamenettípust / értekezlet-jogosultságot néhány vagy az összes felhasználó 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 legördülő menü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

Ismételje meg más felhasználók számára, ha szükséges.

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.

1

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

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

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

Ha a fájl készen áll, kattintson a Eredmények exportálása, majd a Letöltés parancsra. (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 a 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á az 1561 -et új értékként a MeetingPrivilege cella vesszővel tagolt listájához.

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 Értekezlet hely konfigurációs paneljét a Vezérlőpulton.

Ha már az Értekezlet helye listaoldalon volt, előfordulhat, hogy frissítenie kell.

9

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

10

Kattintson az Importálás gombra, és jelölje ki a szerkesztett CSV-t, majd kattintson a Importálás parancsra. Várjon, amíg a fájl feltöltődik.

11

Amikor az importálás befejeződött, az Eredmények importálása gombra kattintva áttekintheti, hogy voltak-e hibák.

12

Nyissa meg a Felhasználók lapot, és nyissa meg az egyik felhasználót, és ellenőrizze, hogy rendelkeznek-e az új munkamenettípussal.

A Webex Meetings Pro-End to End Encryption_VOIPonly foglalkozástípussal vízjelet adhat hozzá az értekezletfelvételekhez, 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 a Biztonság részben Digitális vízjel lehetőséget látnak.

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 lehetőségre.

    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.

Szolgáltatások é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 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.

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 az önazonossághoz, és csak akkor szükséges, ha több tartománya van a Control Hub szervezetben. Ha egynél több domainnel rendelkezik, javasoljuk, hogy ezt tegye meg minden olyan eszközén, amely "Cisco által ellenőrzött" identitá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ételje meg más eszközökön.

Mielőtt elkezdené

  • Kérjen CA által aláírt tanúsítványt és titkos kulcsot .pem formátumban minden egyes 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 scrypt implementációval rendelkezik.

  • 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 ClientSecret kódját egy egyszerű szöveges üzenettel:

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

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

  2. Nyissa meg a TShellt az eszközön.

  3. Futtassa az xcommand Security ClientSecret titkos kódját: "MDEyMzQ1Njc4OWFiY2RlZg"

    A fenti példa parancs feltölti a Titkos kódot a 0123456789abcdef kifejezéssel. Meg kell választania a sajátját.

A készüléknek megvan a kezdeti titka. Ezt ne felejtse el; nem tudja visszaállítani, és az újraindításhoz gyári alaphelyzetbe kell állítani az eszközt.
2

A tanúsítvány és a személyes kulcs összefűzása:

  1. Szövegszerkesztővel nyissa meg a .pem fájlokat, illessze be a kulcs blobot a tanúsítvány blobjába, és mentse új .pem fájlként.

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

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 véletlenszerű, legalább 4 bytes sorozatot. Ez a te sód.

  2. Tartalomtitkosítási kulcsot származtat a scrypt eszközzel.

    Ehhez szüksége van a titokra, a sóra és a kulcstartóra, hogy megfeleljen a választott titkosítási titkosítási titkosításnak. Van még néhány fix érték a kínálatban (N=32768, r=8, p=1). Az eszköz ugyanazt a folyamatot és értékeket használja ugyanazzal a tartalomtitkosítási kulccsal.

  3. Hozzon létre egy véletlenszerű, pontosan 12 sájtból álló sorozatot. Ez az inicializálási vektorod.

  4. Hozzon létre egy JOSE-fejlécet, beállítási 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” kulcs:érték használatával a JOSE fejlécben (mert hozzáadjuk a tanúsítványt az eszközhöz).

  5. Base64url kódolja a JOSE fejlécet.

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

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

  8. A JWE blobot a következőképpen kell létrehozni (az összes érték base64url kódolású):

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4

Nyissa meg a TShellt az eszközön, és futtassa a (többsoros) hozzáadás parancsot:

xcommand Biztonsági tanúsítványok szolgáltatásai Add IsEncrypted: Igaz a..JWE.str.ing\n .\n
5

Ellenőrizze, hogy hozzáadta-e a tanúsítványt az xcommand Security Certificates Services Show futtatásával

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

6

A tanúsítvány aktiválása a WebexIdentity célhoz:

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

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

  3. Tartalomtitkosítási kulcsot származtat a scrypt eszközzel.

    Ehhez szüksége van a titokra, a sóra és a kulcstartóra, hogy megfeleljen a választott titkosítási titkosítási titkosításnak. Van még néhány fix érték a kínálatban (N=32768, r=8, p=1). Az eszköz ugyanazt a folyamatot és értékeket használja ugyanazzal a tartalomtitkosítási kulccsal.

  4. Hozzon létre egy véletlenszerű sorrendet pontosan 12 bájtból, és a base64url kódolja ezt a sorozatot. Ez az inicializálási vektorod.

  5. Hozzon létre egy JOSE-fejlécet, beállítási 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” kulcs:érték használatával a JOSE fejlécben (mert aktiváljuk a tanúsítványt az eszközön).

  6. Base64url kódolja a JOSE fejlécet.

  7. A JWE titkosítási eszközzel a kiválasztott rejtjellel és a base64url kódolású JOSE fejléccel titkosíthatja a tanúsítvány ujjlenyomatát.

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

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

  9. A JWE blobot a következőképpen kell létrehozni (az összes érték base64url kódolású):

    JOSEHeader..InitVector.EncryptedUjjlenyomat.AuthTag

  10. Nyissa meg a TShellt az eszközön, és futtassa a következő aktiválási parancsot:

     xcommand Biztonsági tanúsítványok szolgáltatásai aktiválják a célt: WebexIdentity-ujjlenyomat: „Az Ön..JWE.encrypted.fingerprint” 

Az eszköz titkosított, aktív, hitelesítésszolgáltató által kiadott tanúsítvánnyal rendelkezik, amely készen áll arra, hogy a végpontok közötti titkosított Webex-értekezleteken azonosítsa.
7

Az eszköz fedélzeten a Control Hub szervezetnek.

1

A megfelelő típusú értekezlet ütemezése (Webex Meetings Pro-End to End Encryption_VOIPonly).

2

Csatlakozzon az értekezlethez házigazdaként, webex meetings ügyféltől.

3

Csatlakozzon az értekezlethez olyan eszközről, amelynek személyazonosságát a Webex hitelesítésszolgáltató ellenőrzi.

4

Házigazdaként ellenőrizze, hogy ez az eszköz a megfelelő identitás ikonnal jelenik-e meg az előcsarnokban.

5

Csatlakozzon az értekezlethez egy olyan eszközről, amelynek identitását egy külső hitelesítésszolgáltató ellenőrzi.

6

Házigazdaként ellenőrizze, hogy ez az eszköz a megfelelő identitás ikonnal jelenik-e meg az előcsarnokban. További részletek az identitásikonokról.

7

Csatlakozzon az értekezlethez, mint nem hitelesített értekezlet résztvevői.

8

Házigazdaként ellenőrizze, hogy ez a résztvevő a megfelelő identitás ikonnal jelenik-e meg az előcsarnokban.

9

Házigazdaként fogadj be vagy utasítsd el az embereket / 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 értekezleten mindenki 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 értekezlet-biztonsági kódot látja-e.

  • A végpontok között titkosított értekezleteket teszi alapértelmezett értekezlet-beállítássá, vagy csak néhány felhasználó számára engedélyezi, vagy engedélyezi az összes gazdagép számára a döntést? Ha úgy döntött, 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ösen a korlátozások és az értekezleten várható várakozások tekintetében.

  • Biztosítania kell, hogy sem a Cisco, sem senki más nem tudja visszafejteni a tartalmat, vagy megszemélyesíteni az eszközeit? Ha igen, nyilvános hitelesítésszolgáltató tanúsítványaira van szüksége.

  • 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. 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 kell ellenőrizni, az ellenőrizetlen emberek nem lehetnek csalók.

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ésére, frissítésére és újbóli alkalmazására van szükség.

Ha létrehozta a kezdeti titkot, értse meg, hogy a felhasználók esetleg módosítani akarják eszközük titkát. Előfordulhat, hogy létre kell hoznia egy felületet / terjesztenie kell egy eszközt, hogy ezt lehetővé tegye.

1. táblázat Munkamenettípus-adatok végpontok között titkosított értekezletekhez

Munkamenettípus azonosítója

Közszolgáltatás neve

638

E2E titkosítás+csak voIP

652

Pro-End to End EVOIPonlyncryption_

660

Pro 3 free-end to end EVOIPonlyncryption_

E2E titkosítás + identitás

672

Pro 3 Free50-End to End EVOIPonlyncryption_

673

Oktatási oktató E2E EVOIPonlyncryption_

676

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

677

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

681

Schoology Free plus end to end titkosítás

Ezek a táblák a végpontok közötti titkosított értekezletekhez és az ellenőrzött identitáshoz hozzáadott Webex-eszközök API-parancsait ismertetik. Az API használatával kapcsolatos további információkért lásd: Access the API for Webex Room and Desk Devices and Webex Boards.

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

  • Regisztrált a Webex-re

  • Regisztrált a helyszínen és kapcsolódik a Webexhez a Webex Edge for Devices segítségével

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

API-hívás

Leírás

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: „example.com”

Ez a konfiguráció akkor történik, amikor a rendszergazda beállítja az eszköz által előnyben részesített tartományt 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 hitelesítésszolgáltató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 kiadott tanúsítvánnyal rendelkezik önmaga azonosítására.

xStatus Konferencia végpontok közötti titkosításának elérhetősége

Azt jelzi, hogy az eszköz képes-e csatlakozni egy végponttól végpontig titkosított értekezlethez. A felhő API meghívja, hogy a párosított alkalmazás tudja, hogy használhatja-e az eszközt a csatlakozáshoz.

xStatus Konferencia végpontok közötti titkosítása ExternalIdentity-ellenőrzés

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

xStatus Konferencia Végpontok közötti titkosítás ExternalIdentity Identity

Az eszköz azonosítója a külsőleg kiadott tanúsítvány törzsnevéből olvasott módon.

xStatus Conference EndToEndEncryption ExternalIdentity CertificateChain Certificate # specificinfo

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

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

  • Ujjlenyomat

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

  • NemElőtte Az érvényesség kezdési dátuma

  • ElsődlegesName

  • Nyilvános kulcs algoritmusa

  • Sorozatszám

  • Aláírási algoritmus

  • Tárgy # Név A tanúsítványhoz tartozó témák listája (pl. e-mail-cím vagy tartománynév)

  • Érvényesség A tanúsítvány érvényességi állapotát adja meg (pl. érvényes vagy lejárt)

xStatus Konferencia végpontok közötti titkosítása ExternalIdentity állapota

Az eszköz külső identitásának állapota (pl. érvényes vagy hiba).

xStatus Konferencia végpontok közötti titkosítása InternalIdentity-ellenőrzés

Azt jelzi, hogy az eszköz rendelkezik-e a Webex hitelesítésszolgáltató által kiadott érvényes tanúsítvánnyal.

xStatus Konferencia végpontok közötti titkosítása InternalIdentity Identity

Az eszköz azonosítója a Webex által kiadott tanúsítvány törzsnevéből olvasott személyazonossága.

Tartománynevet tartalmaz, ha a szervezet rendelkezik tartománysal.

Ü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 az Előnyben részesített tartomány.

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 # jelet a tanúsítvány számára. A specificinfo cseréje a következők egyikére:

  • Ujjlenyomat

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

  • NemElőtte Az érvényesség kezdési dátuma

  • ElsődlegesName

  • Nyilvános kulcs algoritmusa

  • Sorozatszám

  • Aláírási algoritmus

  • Tárgy # Név A tanúsítványhoz tartozó témák listája (pl. e-mail-cím vagy tartománynév)

  • Érvényesség A tanúsítvány érvényességi állapotát adja meg (pl. érvényes vagy lejárt)

3. táblázat. Hívás API-k a végpontok között titkosított értekezletekhez és az ellenőrzött identitáshoz

API-hívás

Leírás

xEvent Conference ParticipantRésztvevők listájaHozzáadva

xEvent Conference ParticipantRésztvevők listájaFrissítve

xEvent Conference ParticipantRésztvevők listájaTörölve

Ez a három esemény mostantól a következő: 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 identitáshoz

API-hívás

Leírás

xCommand Security ClientSecret Titkos feltöltés: "base64url-encoded"

vagy

xCommand Security ClientSecret Titkos feltöltés: Jblob csevegés

Elfogadja a base64url kódolt egyszerű szöveges értéket az ügyfél titkos kódjának első vetítéséhez az eszközön.

A titkos rendszer első frissítése után meg kell adnia egy JWE-blobot, amely a régi titok által titkosított új titkot tartalmazza.

xCommand biztonsági tanúsítványok szolgáltatásai JWEblob hozzáadása

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

Kiterjesztettük ezt a parancsot egy titkosított PEM-adatokat tartalmazó JWE-blob fogadására.

xCommand Security Certificates Services Activate Purpose:WebexIdentity FingerPrint: Jblob csevegés

Egy adott tanúsítvány aktiválása a WebexIdentity számára. Ebből a Célból a parancsnak az azonosító ujjlenyomatot JWE-blokkban kell titkosítania és szerializálnia.

xCommand Biztonsági tanúsítványok szolgáltatásai Inaktiválás célja:WebexIdentity FingerPrint: Jblob csevegés

Deaktivál egy adott tanúsítványt a WebexIdentity számára. Ebből a Célból a parancsnak az azonosító ujjlenyomatot JWE-blokkban kell titkosítania és szerializálnia.