A felhasználók az értekezlet ütemezésekor az új értekezlettípust választják. Amikor a résztvevőket beengedi az előcsarnokból, és az értekezlet során a házigazda láthatja az egyes résztvevők személyazonosság-ellenőrzési állapotát. Van egy értekezleti kód is, amely az értekezlet minden jelenlegi résztvevője számára közös, és amelyet felhasználhatnak egymás ellenőrzésére.

Ossza meg a következő információkat a találkozó házigazdáival:

Személyazonosság ellenőrzése

A végpontok között történő személyazonosság-ellenőrzés 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 (Messaging Layer Security) csoporthoz, bemutatják tanúsítványaikat a csoport többi tagjának, akik ezután érvényesítik a tanúsítványokat a kibocsátó tanúsítványhatóság/ies (CA) ellen. A tanúsítványok érvényességének megerősítésével a ca ellenőrzi a résztvevők személyazonosságát, és az értekezlet igazoltan mutatja a résztvevőket / eszközöket.

A Webex Meetings alkalmazás felhasználói hitelesítik magukat a Webex identitásbolttal szemben, amely hozzáférési tokent ad ki nekik, ha sikerrel járnak. Ha tanúsítványra van szükségük a személyazonosságuk ellenőrzéséhez - egy végpontok között titkosított értekezleten -, a Webex CA tanúsítványt ad ki számukra a hozzáférési token alapján. Még nem biztosítjuk a Módját annak, hogy a Webex Meetings felhasználói egy harmadik fél / külső kbt. által kiadott tanúsítványt kapjanak.

Az eszközök a belső (Webex) HITELESÍTÉSSZOLGÁLTATÓ által kiadott tanúsítvánnyal vagy egy külső hitelesítésszolgáltató által kiállított tanúsítvánnyal hitelesíthetik magukat:

  • A belső CA-ügy esetében a Webex belső tanúsítványt állít ki az eszköz gépi fiókjának hozzáférési tokenje alapján. 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, így a Webex (az egyik) szervezet tartományát (tartományát) használja az eszköztanúsítvány személyazonosságának (Common Name (CN)) megírásakor.

  • A külső ca-ügyben ön közvetlenül a kiválasztott kibocsátótól kér és vásárol eszköztanúsítványokat. Titkosítania kell, közvetlenül fel kell töltenie és engedélyeznie kell a tanúsítványokat egy olyan titok használatával, amelyet csak Ön ismer.

    Cisco nem vesz részt, ami ezt a módját, hogy garantálja a valódi végpontok közötti titkosítás és ellenőrzött személyazonosságot, és megakadályozzák az elméleti lehetőségét, hogy a Cisco is lehallgatni a találkozó / dekódolja a média.

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

A Webex tanúsítványt ad ki az eszköznek, amikor indítás után regisztrál, és szükség esetén megújítja. 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 domainlel, a Webex CA tartomány nélkül bocsátja ki a tanúsítványt.

Ha a szervezet több tartománysal rendelkezik, a Control Hub segítségével megmondhatja a Webexnek, hogy az eszköz melyik tartományt használja identitásához. Használhatja az API-t is xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com".

Ha több tartománya van, és nem állította 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 kiadott eszköztanúsítvány

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

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

A tanúsítványban szereplő értékek a szervezet belátása szerint vannak. A közös név (CN) és a tárgy alternatív neve (SAN) megjelenik a Webex értekezlet felhasználói felületén, a Webex értekezletek személyazonosságának ellenőrzésével kapcsolatos végpontok közötti titkosításban leírtakszerint.

Javasoljuk, hogy eszközönként külön tanúsítványt használjon, és eszközönként egyedi KÖZPONTI IDEGRENDSZERREL rendelkezzen. Ez lehet például a "meeting-room-1.example.com", a "example.com" domaint birtokló szervezet számára.

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ót használnak a különböző xcommandok titkosítására és aláírására.

Az ügyféltitkok használatakor lehetőség van a külső webex személyazonossági tanúsítvány biztonságos kezelésére az xAPI-n keresztül. Ez jelenleg az online eszközökre korlátozódik.

Jelenleg a Webex API-parancsokat biztosít ennek kezelésére.

Eszközök

A felhőben regisztrált Webex Room sorozatú és Webex Desk sorozatú eszközök végpontok között titkosított értekezleteket is csatlakozhatnak, többek között:

  • Webex Board

  • Webex Desk Pro

  • Webex asztal

  • Webex Room Kit

  • Webex Room Kit Mini

A következő eszközök nem csatlakozhatnak a végpontok között a titkosított értekezletek befejezéséhez:

  • Webex C sorozat

  • Webex DX sorozat

  • Webex EX sorozat

  • Webex MX sorozat

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

Szoftveres ügyfelek

  • A 41.7-től a Webex Meetings asztali kliens csatlakozhat a végpontok között titkosított értekezletekhez.

  • A Webex alkalmazás nem csatlakozhat a végpontok között titkosított értekezletekhez.

    Ha a szervezet engedélyezi, hogy a Webex alkalmazás csatlakozzon az értekezletekhez a Meetings asztali alkalmazás elindításával, akkor ezzel a lehetőséggel csatlakozhat a végpontok között titkosított értekezletekhez.

  • A Webex webkontenzáns nem csatlakozhat a végpontok között titkosított értekezletekhez.

  • A harmadik féltől származó SIP-puha ügyfelek nem csatlakozhatnak a végpontok között titkosított értekezletekhez.

Azonosság

  • Nem biztosítunk semmilyen Control Hub lehetőséget a külsőleg ellenőrzött eszköz identitásának kezelésére. Ez a döntés a tervezés, mert az igazi end-to-end titkosítás, csak akkor kell tudni / hozzáférni a titkokat és kulcsokat. Ha bevezettünk egy felhőszolgáltatást a kulcsok kezelésére, akkor van esély arra, hogy elfogják őket.

  • Jelenleg nem biztosítunk olyan eszközöket, amelyek segítenek az eszköz személyazonosító tanúsítványainak és azok személyes kulcsainak igénylésében vagy titkosításában. Jelenleg egy "receptet" biztosítunk Önnek, hogy megtervezze saját eszközeit, amelyek az iparági szabványoknak megfelelő titkosítási technikákon alapulnak, hogy segítsék ezeket a folyamatokat. Nem akarunk valós vagy vélt hozzáférést a titkaihoz vagy kulcsaihoz.

Meetings

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

  • A 200 résztvevő közül legfeljebb 25 külsőleg ellenőrzött eszköz csatlakozhat, és ők az első résztvevők, akik csatlakoznak a találkozóhoz.

    Amikor több eszköz csatlakozik egy értekezlethez, háttérmédia-szolgáltatásaink megpróbálják átkódolni a médiafolyamokat. Ha nem tudjuk visszafejteni, átkódolni és újra titkosítani az adathordozót (mert nem rendelkezünk és nem is kell rendelkeznünk az eszközök titkosítási kulcsával), akkor az átkódolás sikertelen.

    A korlátozás enyhítése érdekében kisebb értekezleteket ajánlunk az eszközök számára, vagy az eszközök és a Meetings-ügyfelek közötti meghívásokat.

Kezelőfelület

Javasoljuk, hogy használja a Control Hubot az értekezleti webhely kezeléséhez.

Ennek fő oka a control hub és a webhelyfelügyelet identitáskezelésének módja közötti különbség. A Control Hub-szervezetek központosított identitással rendelkeznek az egész szervezet számára, míg a Webhely-felügyeletben az identitást webhely alapon ellenőrzik.

Ez azt jelenti, hogy nem rendelkezhet Cisco által ellenőrzött személyazonossági lehetőséggel azon felhasználók számára, akiket a Webhely-felügyelet kezel. Ezek a felhasználók névtelen tanúsítványt kaptak, hogy csatlakozzanak egy végpontok között titkosított értekezlethez, és kizárhatók azokból az értekezletekből, ahol a fogadó biztosítani kívánja a személyazonosságot.

Kapcsolódó információk

JWE blobok mintája

A helyesen titkosított JWE mintája a megadott paraméterek alapján (függelék)

  • Webex találkozók 41.7.

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

  • Rendszergazdai hozzáférés a Vezérlőközpont értekezleti helyéhez, hogy a felhasználók számára lehetővé váljon az új munkamenettípus.

  • Egy vagy több ellenőrzött tartomány a Vezérlőközpont szervezetében (ha a Webex CA-t használja az eszköztanúsítványok kiadására az ellenőrzött személyazonossághoz).

Ezt a lépést kihagyhatja, ha nincs szüksége külsőleg igazolt 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ó állami tanúsítványhatóság által kiállított egyedi tanúsítvánnyal.

A digitális tanúsítványok igényléséhez, megvásárlásához és fogadásához, valamint a kapcsolódó privát kulcsok létrehozásához kapcsolatba kell lépnie a ca-val. A tanúsítvány igénylése során ezek a paraméterek használhatók:

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

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

  • Közös név (CN) és tárgy alternatív neve(i) (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özzel. A CN megmutatja a többi értekezlet résztvevőjének az eszköz elsődleges ellenőrzött személyazonosságát, és ha a felhasználók az értekezlet felhasználói útján ellenőrzik a tanúsítványt, akkor látni fogják az SAN/s-t. Érdemes lehet olyan neveket használni, mint name.model@example.com De ez a te döntésed.

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

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

    Ez a követelmény nem terjed ki az aláírókulcsra. A tanúsítvány aláírásához a ca rsa kulcsot használhat.

Ezt a lépést kihagyhatja, ha nem szeretne külsőleg ellenőrzött személyazonosságot használni az eszközökkel.

Ha új eszközöket használ, még ne regisztrálja őket a Webex-re. A legbiztonságosabb, ha még nem is csatlakoztatjuk őket a hálózathoz.

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

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

  • Ütemezzen be egy ablakot, amikor az eszközöket nem használja, vagy szakaszos megközelítést alkalmazzon. Értesítse a felhasználókat az általuk várható változásokról.

  • Biztosítsa az eszközökhöz való fizikai hozzáférést. 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ágát.

Annak biztosítása é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ő privát kulcsot. Az eszközhöz api-kat terveztünk, hogy lehetővé tegye a titkosított kulcs és tanúsítvány kezelését a JSON Web Encryption (JWE) használatával.

Annak érdekében, hogy valódi végpontok közötti titkosítást biztosítsunk a felhőn keresztül, nem vehetünk részt 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ő a feladata:

  • Kérje a tanúsítványokat.

  • A tanúsítványok kulcspárjának létrehozása.

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

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

    Az alábbiakban elmagyarázzuk a folyamatot és a (nem titkos) paramétereket, amire szüksége lesz, és egy receptet, hogy kövesse a választott fejlesztési eszközöket. Mi is adunk néhány vizsgálati adatokat és az ebből eredő JWE blobs, ahogy várjuk őket, hogy segítsen ellenőrizni a folyamatot.

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

  • A tanúsítvány és a kulcs összefűzése és titkosítása az eszköz és az eszköz kezdeti titkával.

  • Töltse fel a kapott JWE blobot az eszközre.

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

  • (Ajánlott) Biztosítson felületet az eszközhöz (vagy terjessze) annak érdekében, hogy az eszköz felhasználói módosíthassák a kezdeti titkot (hogy megvédjék a médiájukat Öntől!).

Hogyan használjuk a JWE formátumot?

Ez a rész leírja, 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 tanúsítványokból és kulcsokból származó foltok létrehozásához.

Hivatkoznia kell a JSON Web Encryption (JWE)https://datatracker.ietf.org/doc/html/rfc7516 és a JSON Web Signature (JWS)https://datatracker.ietf.org/doc/html/rfc7515hivatkozására.

Úgy döntöttünk, hogy egy JSON dokumentum kompakt szerializálását használjuk JWE blobok létrehozásához. A JWE-blokkok létrehozásakor a következő paramétereket kell megadnia:

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

    • "alg":"dir"

      A közvetlen algoritmus az egyetlen, amelyet támogatunk a hasznos teher titkosításához, és az eszköz kezdeti ügyféltitkát kell használnia.

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

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

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

      Ez egy szabadalmaztatott kulcs és négy érték, amit el lehet vinni. Bevezettük ezt a kulcsot, hogy jelezzük a titkosított adatok célját a céleszköznek. Az értékek a titkosított adatokat használó eszköz xAPI parancsai után kapnak nevet.

      Elneveztük cisco-action a JWE jövőbeli kiterjesztéseivel való esetleges összeütközés enyhítése.

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

      Egy másik saját kulcs. Az Ön által megadott értékeket bemenetként használjuk az eszköz kulcslevezetéséhez. Az version Kell 1(a legfontosabb deriválási függvényünk verziója). Az érték salt legalább 4 bájtos base64 URL-kódolt szekvenciának kell lennie, amelyet véletlenszerűen kell kiválasztania.

  • JWE titkosított kulcs. Ez a mező üres. A készülék a kezdeti ClientSecret.

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

  • JWE AAD (további hitelesített adatok). Ezt a mezőt ki kell hagynia, mert a Compact Serialization nem támogatja.

  • JWE rejtjelszöveg: Ez az a titkosított hasznos teher, amit titokban akarsz tartani.

    A hasznos teher üres lehet (Például az ügyfél titkának visszaállításához üres értékkel kell felülírnia).

    Különböző típusú hasznos teher van, attól függően, hogy mit próbál tenni az eszközön. A különböző xAPI parancsok eltérő hasznos terhet várnak el, és meg kell adnia a hasznos teher célját a cisco-action kulcs, az alábbiak szerint:

    • Val "cisco-action":"populate" a rejtjelszöveg az új ClientSecret

    • A " "cisco-action":"add" a rejtjel egy PEM blob, amely a tanúsítványt és annak privát kulcsát hordozza (összefűzve)

    • A " "cisco-action":"activate" a rejtjel az eszközazonosító ellenőrzésére aktivált tanúsítvány ujjlenyomata (sha-1 hatoldalú ábrázolása)

    • A " "cisco-action":"deactivate" a rejtjel az eszköz személyazonosságának ellenőrzésére használt tanúsítvány ujjlenyomata (sha-1 hatoldalú ábrázolása)

  • JWE hitelesítési címke: Ez a mező tartalmazza a hitelesítési címkét, hogy megállapítsa a teljes JWE kompaktan szerializált blob integritását

Hogyan nyerjük le a titkosítási kulcsot a ClientSecret

A titok első népe után nem fogadjuk el vagy adjuk ki a titkot egyszerű szövegként. Ez annak megakadályozása, hogy valaki hozzáférjen az eszközhöz.

Az eszközszoftver az ügyfél titkát használja egy kulcslevezetési függvény (kdf) bemeneteként, majd a származtatott kulcsot használja az eszköz tartalmi visszafejtéséhez/ titkosításához.

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, hogy ugyanazt a titkosítási / visszafejtési kulcsot az ügyfél titkából nyerje.

Az eszközök a kulcslevezetéshez (lásd ) scrypt-ethttps://en.wikipedia.org/wiki/Scrypthasználnak a következő paraméterekkel:

  • CostFactor (N) 32768

  • BlockSizeFactor (r) 8

  • PárhuzamosításFactor (p) 1

  • A só legalább 4 bájt véletlenszerű sorozat; ezt kell megadnia salt megadásakor cisco-kdf paraméter.

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

Ez a paraméterkészlet az egyetlen olyan konfiguráció a titkosításban, amely kompatibilis az eszközök kulcslevezetési funkciójával. Ezt a kdf-et az eszközökön "version":"1", amely az egyetlen verzió, amelyet jelenleg a cisco-kdf paraméter.

Bevált példa

Íme egy példa, amelyet követve ellenőrizheti, hogy a JWE titkosítási folyamata 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áncgal a teljes cert + kulcs helyett). Az ügyfél titka a példában ossifrage.

  1. Válasszon titkosítási titkosítási titkosítást. Ez a példa A128GCM(AES 128 bites billentyűkkel a Galois számláló módban). Az eszköz használható A256GCM ha úgy tetszik.

  2. Válasszon sót (legalább 4 bájt véletlenszerű sorozatnak kell lennie). Ez a példa használ (hexabájt) E5 E6 53 08 03 F8 33 F6. Base64url kódolja a sorrendet, hogy 5eZTCAP4M_Y(távolítsa el az alap64 párnázást).

  3. Itt van egy minta scrypt felhívás a tartalomtitkosítási kulcs (cek) létrehozására:

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

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

  4. Válasszon egy 12 bájtos véletlenszerű sorozatot, amelyet inicializálási vektorként használhat. Ez a példa használ (hexa) 34 b3 5d dd 5f 53 7b af 2d 92 95 83 amely base64url kódol NLNd3V9Te68tkpWD.

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

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

    A base64url kódolt JOSE fejléc eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

    Ez lesz az első eleme a JWE blob.

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

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

  8. Használja a JWE titkosítási eszközt titkosított hasznos teher és címke előállításához. Ebben a példában a titkosítatlan hasznos teher lesz a hamis PEM blob this is a PEM file

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

    • A hasznos teher this is a PEM file

    • A titkosítási titkosítás AES 128 GCM

    • A base64url kódolt JOSE fejléc további hitelesített adatokként (AAD)

    Base64url kódolja a titkosított hasznos terhet, ami azt eredményezi, hogy f5lLVuWNfKfmzYCo1YJfODhQ

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

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

    Ez az ötödik elem a JWE blob.

  10. A JWE blob öt elemét pontokkal (JOSEheader.) IV.Ciphertext.Tag), hogy:

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

  11. Ha ugyanazokat a base64url kódolt értékeket szerezte be, mint amit itt mutatunk, saját eszközeivel, készen áll arra, hogy azokat az E2E titkosítás és az eszközök ellenőrzött személyazonosságának biztosítására használja.

  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 a tanúsítványt hozzáadó eszköz xcommand bemeneteként:

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

A nulla bizalmi szintű értekezletek új munkamenet-típusait minden értekezlet-helyszínre további költségek nélkül bevezetjük. Az egyik új munkamenet-típus neve Pro-End to End Encryption_VOIPonly. Ez az a közszolgálati név, amelyet a jövőben megváltoztathatunk. A munkamenettípusok aktuális neveit lásd a cikk Hivatkozás szakaszában található Munkamenet-azonosítók című részben.

Semmit sem kell tennie ahhoz, hogy megkapja webhelye új képességét, de meg kell adnia az új munkamenettípust (más néven Meeting Privilege ) afelhasználóknak. Ezt egyénileg teheti meg a felhasználó konfigurációs oldalán keresztül, vagy ömlesztve egy CSV exportálással / importálással oda-vissza.

1

Jelentkezzen be a Vezérlőközpontba, és nyissa meg az Értekezlet lapot.

2

Kattintson a webhely nevére a webhely konfigurációs paneljének megnyitásához.

3

Kattintson a Webhely konfigurálásagombra.

4

A Gyakori beállítások területen kattintson a Munkamenettípusokelemre.

Ezen az oldalon egy vagy több végponttól végpontig terjedő titkosítási munkamenettípust kell látnia. Olvassa el a cikk Hivatkozás szakaszában található munkamenet-azonosítók listáját. Előfordulhat például, hogy a Pro-End to End Encryption_VOIPonly.

 

Van egy régebbi munkamenettípus, amelynek neve nagyon hasonló: Végpontok közötti titkosítás. Ez a munkamenettípus nem titkosított PSTN-hozzáférést biztosít az értekezletekhez. Győződjön meg arról, hogy rendelkezik a _VOIPonly verzióval a végpontok közötti titkosítás biztosításához. A munkamenet kód oszlopában található PRO hivatkozásra mutatva ellenőrizheti. Ebben a példában a hivatkozás céljának javascript:ShowFeature(652).

A jövőben megváltoztathatjuk ezeknek a munkamenettípusoknak a közszolgálati nevét, például azt tervezzük, hogy a Pro-End to End Encryption_VOIPonlyE2E titkosításra + identitásramódosítjuk.

5

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

A következő teendők:

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

1

Kattintson a Felhasználók gombra, és válasszon ki egy felhasználót a felhasználó konfigurációs paneljének megnyitásához.

2

A Szolgáltatások területen kattintson a Cisco Webex Meetingselemre.

3

Jelölje ki a webhelyet (ha a felhasználó több helyen is tartózkodik), és kattintson a Gazdagépgombra.

4

Jelölje be a Encryption_VOIPonly pro-end címkével ellátott Webex Meetings bejegyzés melletti 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 többi felhasználót.

Ha ezt sok felhasználóhoz szeretné hozzárendelni, használja a CSV tömeges opciót.

1

Jelentkezzen be a Vezérlőközpontba, https://admin.webex.com és nyissa meg az Értekezlet lapot.

2

Kattintson a webhely nevére a webhely konfigurációs panel megnyitásához.

3

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

4

Kattintson az Exportálásgombra, és várjon, amíg elkészítjük a fájlt.

5

Ha a fájl készen áll, kattintson az Eredmények exportálása, majd a Letöltés gombra. (Manuálisan be kell zárnia azt a felugró ablakot, miután Letöltés>>

6

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

Minden felhasználónak van egy sora, és a MeetingPrivilege oszlop vesszővel körülhatárolt listaként tartalmazza a munkamenet-típus-eddeket.

7

Minden olyan felhasználó esetében, aki számára az új munkamenettípust szeretné megadni, 1561 új értékként a vesszővel körülhatárolt listán a MeetingPrivilege sejt.

A CSV fájlformátumra vonatkozó hivatkozás részletesen https://help.webex.com/en-us/5vox83 ismerteti a CSV-fájl célját és tartalmát.

8

Nyissa meg az Értekezlet-webhely konfiguráció panelt a Vezérlőpulton.

Ha már a Találkozó webhely listaoldalán volt, előfordulhat, hogy frissítenie kell.

9

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

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 feltöltjük a fájlt.

11

Ha az importálás befejeződött, kattintson az Eredmények importálása gombra, hogy áttekintse, voltak-e hibák.

12

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

Ha az eszközök már be vannak állítva a Control Hub szervezetbe, és a Webex CA segítségével szeretné automatikusan létrehozni az azonosító tanúsítványokat, nem kell gyárilag visszaállítania az eszközöket.

Ez az eljárás kiválasztja, hogy az eszköz melyik tartományt használja az azonosításhoz, és csak akkor szükséges, ha több tartomány van a Vezérlőközpont szervezetében. Ha egynél több domainje van, javasoljuk, hogy ezt tegye meg minden olyan eszközére, amely "Cisco-igazolt" személyazonossággal rendelkezik. Ha nem mondja el a Webexnek, hogy melyik tartomány azonosítja az eszközt, kiválasztunk egyet, és az rosszul néz ki a többi értekezlet-résztvevő számára.

Mielőtt elkezdené

Ha az eszközök még nincsenek bevésve, követheti https://help.webex.com/n25jyr8 vagy https://help.webex.com/nutc0dy. Ellenőriznie kell azt a tartományt(ok)t is, amelyeket az eszközök azonosítására használni szeretne (https://help.webex.com/cd6d84).

1

Jelentkezzen be a Vezérlőközpontba (https://admin.webex.com) és nyissa meg az Eszközök lapot.

2

Jelölje ki a konfigurációs panel megnyitásához használjon eszközt.

3

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

4

Ismételje meg más eszközökhöz.

Mielőtt elkezdené

Szükséged van:

  • A CA által aláírt tanúsítvány és a privát kulcs .pem formátumban történő megszerzéséhez minden eszközhöz.

  • Olvassa el a következő témakört: Az eszközök külső identitásánakmegértése folyamat – a cikk Előkészítés részében.

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

  • Egy eszköz, a segítségével véletlenszerű byte szekvenciák adott hosszúságú.

  • Egy eszköz a 64url kódolásához bájtok vagy szöveg kódolásához.

  • Egy scrypt végrehajtás.

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

1

A készülék ClientSecret egyszerű szöveges titokkal:

Az első alkalommal, amikor feltölti a Secret, egyszerű szöveggel látja el. Ezért javasoljuk, hogy ezt a fizikai eszköz konzolon tegye meg.

  1. Base64url kódolja a titkos kifejezést erre az eszközre.

  2. Nyissa meg a készüléken lévő TShell-t.

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

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

Az eszköznek megvan a kezdeti titka. Ne felejtsd el ezt, nem tudod visszaállítani, és gyárilag vissza kell állítania az eszközt az újrakezdéshez.
2

A tanúsítvány és a privát kulcs összefűzve:

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

    (Ez az a hasznos teher szöveg, amelyet titkosít és berak a JWE blobba)

3

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

  1. Hozzon létre egy véletlenszerű sorozat legalább 4 byte. Ez a te sója.

  2. Tartalomtitkosítási kulcs levezetése a titkosító eszközzel.

    Ehhez szüksége van a titokra, a sóra és a kulcshosszra, hogy megfeleljen a kiválasztott titkosítási titkosítási titkosításnak. Van még néhány rögzített érték a kínálatban (N=32768, r=8, p=1). Az eszköz ugyanazt a folyamatot és értékeket használja ugyanazon tartalomtitkosítási kulcs levezetéséhez.

  3. Hozzon létre egy véletlenszerű sorrendben pontosan 12 byte. Ez az inicializálási vektorod.

  4. JOSE-fejléc létrehozása, beállítás alg, enc és cisco-kdf az eszközök külső identitásának megértése folyamatban leírtak szerint. Állítsa be a "hozzáadás" műveletet a kulcs:érték "cisco-action":"add" a JOSE fejlécében (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ódolt JOSE fejléccel a szöveg titkosításához az összefűzött pem fájlból.

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

  8. Építsd fel a JWE blobot az alábbiak szerint (minden érték base64url kódolású):

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4

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

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

Ellenőrizze, hogy a tanúsítványt futással adják-e hozzá xcommand Security Certificates Services Show

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

6

A tanúsítvány aktiválása erre a 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.

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

  3. Tartalomtitkosítási kulcs levezetése a titkosító eszközzel.

    Ehhez szüksége van a titokra, a sóra és a kulcshosszra, hogy megfeleljen a kiválasztott titkosítási titkosítási titkosításnak. Van még néhány rögzített érték a kínálatban (N=32768, r=8, p=1). Az eszköz ugyanazt a folyamatot és értékeket használja ugyanazon tartalomtitkosítási kulcs levezetéséhez.

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

  5. JOSE-fejléc létrehozása, beállítás alg, enc és cisco-kdf az eszközök külső identitásának megértése folyamatban leírtak szerint. Állítsa be az "aktiválás" műveletet a key:value "cisco-action":"activate" a JOSE fejlécében (mert aktiváljuk a tanúsítványt az eszközön).

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

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

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

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

  9. Építsd fel a JWE blobot az alábbiak szerint (minden érték base64url kódolású):

    JOSEHeader..InitVector.EncryptedFingerprint.AuthTag

  10. Nyissa meg a TShell-t 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-s tanúsítvánnyal rendelkezik, amely készen áll arra, hogy a végpontok között titkosított Webex-értekezleteken azonosítsa.
7

Az eszköz fedélzetén a Vezérlőközpont szervezetével.

1

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

2

Csatlakozzon az értekezlethez házigazdaként, a Webex Meetings ügyféltől.

3

Csatlakozzon az értekezlethez olyan eszközről, amelynek személyazonosságát a Webex CA ellenőrzi.

4

Házigazdaként ellenőrizze, hogy ez az eszköz a megfelelő azonosító ikonra jelenik-e meg az előcsarnokban.

5

Csatlakozzon az értekezlethez olyan eszközről, amelynek személyazonosságát egy külső kbt.

6

Házigazdaként ellenőrizze, hogy ez az eszköz a megfelelő azonosító ikonra jelenik-e meg az előcsarnokban.

7

Csatlakozzon az értekezlethez, mint nem támogatott résztvevők.

8

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

9

Mint a fogadó, ismerjék el vagy utasítsák el az embereket / eszközöket.

10

Lehetőség szerint ellenőrizze a résztvevők/eszközök azonosítóit a tanúsítványok ellenőrzésével.

11

Ellenőrizze, hogy az értekezleten mindenki ugyanazt a biztonsági kódot látja-e.

12

Csatlakozzon a találkozóhoz 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 lehetővé teszi az összes állomás számára a döntést? 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íthat az értekezleten.

Meg kell győződni arról, hogy sem a Cisco, sem más nem tudja visszafejteni a tartalmat, vagy megszemélyesíteni az eszközöket? Ha igen, akkor egy nyilvános kbt. Előfordulhat, hogy egy biztonságos értekezleten legfeljebb 25 eszköz áll önhöz. Ha ilyen szintű biztonságra van szüksége, ne engedje, hogy az ügyfelek csatlakozzanak.

Azok a felhasználók, akik biztonságos eszközökkel csatlakoznak, először hagyják, hogy az eszközök csatlakozzanak, és állítsa be a felhasználói elvárásokat, hogy esetleg nem tudnak csatlakozni, ha későn csatlakoznak.

Ha a személyazonosság ellenőrzése különböző szintű, hatalmazza fel a felhasználókat arra, hogy a tanúsítványokkal alátámasztott személyazonossággal és az értekezlet biztonsági kódjával 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 ellenőrizni, az ellenőrizetlen személyek nem lehetnek csalók.

Ha külső tanúsítványt használ az eszköztanúsítványok kibocsátásához, a tanúsítvány figyelésére, frissítésére és újbóli alkalmazására a figyelő, frissítő és újraalkalmazási járadék van.

Ha létrehozta a kezdeti titkot, értse meg, hogy a felhasználók megváltoztathatják az eszköz titkát. Előfordulhat, hogy létre kell hoznia egy interfészt / egy eszközt, amely lehetővé teszi számukra, hogy ezt megtegyék.

1. táblázat. Munkamenet-típus-előzandók végpontok között titkosított értekezletekhez

Munkamenet típusazonosítója

Közszolgáltatás neve

638

Csak E2E titkosítás+VoIP

652

Pro-End a végéig Encryption_VOIPonly

660

Pro 3 Free-End a végéig Encryption_VOIPonly

E2E titkosítás + identitás

672

Pro 3 Free50-End to End Encryption_VOIPonly

673

Oktatási oktató E2E Encryption_VOIPonly

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 Free plus 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 értekezletek és ellenőrzött személyazonosság érdekében adtunk hozzá. Az API használatáról bővebben a > https://help.webex.com/nzwo1ok>>

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

API-hívás

Leírás

xConfiguration Conference EndToEndEncryption Mode: On

Vége a titkosítási módnak On vagy Off.

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 preferált tartományt a Control Hubból. Csak akkor szükséges, ha a szervezet több domain.

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 rendelkezik aktív, külsőleg kiadott tanúsítvánnyal az azonosításhoz.

xStatus Conference EndToEndEncryption Availability

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

xStatus Conference EndToEndEncryption ExternalIdentity Valid

Jelzi, hogy az eszköz rendelkezik-e érvényes, külsőleg kiállított tanúsítvánnyal.

xStatus Conference EndToEndEncryption ExternalIdentity Identity

Az eszköz személyazonossága a külsőleg kiadott tanúsítvány közös nevéből kiolvasva.

xStatus Conference EndToEndEncryption ExternalIdentity CertInfo

Beolvassa a tanúsítvány adatait a külsőleg kiadott tanúsítványból, és JSON blob-ként adja ki.

xStatus Conference EndToEndEncryption InternalIdentity Valid

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

xStatus Conference EndToEndEncryption InternalIdentity Identity

Az eszköz személyazonossága a Webex által kiadott tanúsítvány közös nevéből kiolvasva.

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

Üres, ha a szervezet nem rendelkezik tartománysal.

Ha az eszköz több tartományból áll, akkor ez az érték a PreferredDomain.

xStatus Conference EndToEndEncryption InternalIdentity CertInfo

Elolvassa a tanúsítvány adatait a Webex által kiadott tanúsítványból, és JSON blob-ként adja ki.

3. táblázat. A végpontok között titkosított értekezletek és ellenőrzött személyazonosság esetén hívható API-k

API-hívás

Leírás

xStatus Call # ServerEncryption Type

Beolvassa a WebexHEZ való HTTPS-kapcsolat titkosítási titkosítási titkosítását. Ez megjelenik a felhasználó számára.

xStatus Conference Call # EndToEndEncryption Status

Olvassa el a hívások végpontok közötti titkosítási állapotát. A lakat ikon jelenléteként (vagy hiányaként) jelenik meg a felhasználó számára.

xStatus Conference Call # EndToEndEncryption SecurityCode

Elolvassa a találkozó biztonsági kódját. Ez megjelenik a felhasználó számára, és a résztvevők csatlakozásakor megváltozik.

xStatus Conference Call # EndToEndEncryption MediaEncryption Type

Elolvassa a médiakapcsolatban használt titkosítási titkosítási titkosítást. Ez megjelenik a felhasználó számára.

xStatus Conference Call # EndToEndEncryption GroupEncryption Type

Beolvassa az üzenetküldő réteg biztonságához (MLS) használt titkosítási titkosítási titkosítást.

xStatus Conference Call # EndToEndEncryption Roster Participant

Felsorolja azokat a résztvevőket, akik ezen a találkozón hozzájárulnak az MLS-csoport állapotához. A listát az MLS fedezte fel, nem a Webex.

xStatus Conference Call # EndToEndEncryption Roster Participant # Id

Egy adott résztvevő WDM-URL-címe.

xStatus Conference Call # EndToEndEncryption Roster Participant # Status:

A megadott résztvevő ellenőrzési állapota.

xStatus Conference Call # EndToEndEncryption Roster Participant # Identity:

A megadott résztvevő elsődleges azonosítója, jellemzően egy domain (eszköz) vagy e-mail cím (felhasználó).

xStatus Conference Call # EndToEndEncryption Roster Participant # DisplayName:

A megadott résztvevő megjelenített neve. A résztvevő/eszköz aláírása.

xStatus Conference Call # EndToEndEncryption Roster Participant # CertInfo:

A megadott résztvevő JSON blob tanúsítványából származó tanúsítvány adatai.

xCommand Conference ParticipantList Search

Ezt a parancsot kiterjesztettük a résztvevők végpontok közötti titkosítási információira is.

xCommand Conference ParticipantList Search

A résztvevők listájának keresése mostantól tartalmazza EndToEndEncryptionStatus, a résztvevő személyazonosság-ellenőrzési státusza. Ez az érték megjelenik a felhasználói oldalon.

xCommand Conference ParticipantList Search

A résztvevők listájának keresése mostantól tartalmazza EndToEndEncryptionIdentity, a résztvevő elsődleges személyazonosságát. Ez általában egy tartomány vagy egy e-mail cím. Ez az érték megjelenik a felhasználói oldalon.

xCommand Conference ParticipantList Search

A résztvevők listájának keresése mostantól tartalmazza EndToEndEncryptionCertInfo, a JSON blob, amely tartalmazza a résztvevő tanúsítványát. Ez az érték megjelenik a felhasználói oldalon.

xEvent Conference ParticipantList Participant(Added)

xEvent Conference ParticipantList Participant(Updated)

xEvent Conference ParticipantList Participant(Deleted)

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 értekezletek és ellenőrzött személyazonosság

API-hívás

Leírás

xCommand Security ClientSecret Populate Secret: "base64url-encoded" vagy xCommand Security ClientSecret Populate Secret: JWEblob

Elfogadja a base64url kódolt egyszerű szöveges értéket az ügyfél titkának első alkalommal történő bevetésére az eszközön.

A titok frissítéséhez az első alkalom után be kell szolgáltatnia egy JWE blobot, amely tartalmazza a régi titok által titkosított új titkot.

xCommand Security Certificates Services Add JWEblob

Tanúsítványt ad hozzá (privát kukával).

Kiterjesztettük ezt a parancsot, hogy elfogadjuk a titkosított PEM adatokat tartalmazó JWE blobot.

xCommand Security Certificates Services Activate Purpose:WebexIdentity FingerPrint: JWEblob

Aktivál egy adott tanúsítványt a WebexIdentity-hez. Ehhez Purpose, a parancs megköveteli, hogy az azonosító ujjlenyomatot egy JWE blobban titkosítsák és szerializálják.

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

Deaktivál egy adott tanúsítványt a WebexIdentity-hez. Ehhez Purpose, a parancs megköveteli, hogy az azonosító ujjlenyomatot egy JWE blobban titkosítsák és szerializálják.