A felhasználók az értekezlet ütemezésekor választják ki az új értekezlettípust. Amikor beengedi a résztvevőket 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 értekezletkód is, amely közös az értekezlet összes jelenlegi résztvevője számára, amelyet egymás ellenőrzésére használhatnak.

Ossza meg a következő információkat az értekezlet-gazdákkal:

Személyazonosság ellenőrzése

A végpontok közötti személyazonosság-ellenőrzés további biztonságot nyújt a végpontok közötti 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 kiállító hitelesítésszolgáltatóval(CA) szemben. 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 a résztvevőket / eszközöket ellenőrzöttként jeleníti meg.

A Webex Meetings alkalmazás felhasználói hitelesítik magukat a Webex identity store-ban, amely sikeresen hozzáférési jogkivonatot ad ki nekik. Ha tanúsítványra van szükségük személyazonosságuk ellenőrzéséhez - végpontok között titkosított értekezleten -, a Webex hitelesítésszolgáltató a hozzáférési jogkivonatuk alapján tanúsítványt állít ki nekik. Még nem biztosítunk módot a Webex Meetings felhasználói számára, hogy egy harmadik fél / külső hitelesítésszolgáltató által kiadott 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:

  • A belső hitelesítésszolgáltatói esethez a Webex belső tanúsítványt állít ki az eszköz gépfiókjának hozzáférési jogkivonata alapján. A tanúsítványt a Webex CA írta alá. Az eszközök nem rendelkeznek felhasználói azonosítókkal ugyanúgy, mint a felhasználók, ezért a Webex a szervezet tartományának(i) egyikét használja az eszköztanúsítvány személyazonosságának (közös név (CN)) írásakor.

  • A külső hitelesítésszolgáltató esetében az eszköztanúsítványokat közvetlenül a kiválasztott kibocsátótól kérheti és vásárolhatja meg. 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, ami lehetővé teszi a valódi végpontok közötti titkosítás és az ellenőrzött identitás garantálásának módját, és megakadályozza annak az elméleti lehetőségét, hogy a Cisco lehallgathatja az értekezletet / 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 API-t is xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com".

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ö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 találkozók személyazonosság-ellenőrzésével a 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 CN-t használjon. Ez lehet például "meeting-room-1.example.com", a "example.com" domaint birtokos 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óval titkosítják és aláírják a különböző xcommandokat.

Az ügyfél titkos kódjának használatakor biztonságosan kezelheti a külső webex személyazonosító tanúsítványt 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éhez.

Eszközök

A felhőalapú webex szoba sorozat és a Webex Desk sorozatú eszközök végpontok között titkosított értekezletekhez csatlakozhatnak, többek között:

  • Webex Board

  • Webex Desk Pro

  • Webex íróasztal

  • Webex Room Kit

  • Webex Room Kit Mini

A következő eszközök nem csatlakozhatnak a titkosított értekezletek végé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.6-tól a Webex Meetings asztali ügyfél csatlakozhat a végpontok között titkosított értekezletekhez.

  • Ha a szervezet engedélyezi a Webex alkalmazás számára, hogy az Értekezletek asztali alkalmazás elindításával csatlakozzon az értekezletekhez, akkor ezzel a beállítással csatlakozhat a végpontok között titkosított értekezletekhez.

  • A Webex webügyfél nem tud csatlakozni a végpontok között titkosított értekezletekhez.

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

Azonosság

  • Nem biztosítunk Control Hub-beállításokat a külsőleg ellenőrzött eszközidentitás kezeléséhez. Ez a döntés szándékos, mert a valódi végpontok közötti titkosításhoz csak Önnek kell tudnia / hozzáférnie a titkokhoz és kulcsokhoz. 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 személyes kulcsainak kérésében vagy titkosításában. Jelenleg egy "receptet" biztosítunk Önnek, hogy saját eszközöket tervezzen az iparági szabványú titkosítási technikák alapján, hogy segítse ezeket a folyamatokat. Nem akarunk valódi 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 nekik kell első résztvevőknek lenniük, akik csatlakoznak az értekezlethez.

    Amikor több eszköz csatlakozik egy értekezlethez, háttérmédia-szolgáltatásaink megkísérlik á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 szabad rendelkeznünk az eszközök titkosítási kulcsaival), akkor az átkódolás sikertelen.

    A korlátozás enyhítése érdekében kisebb értekezleteket ajánlunk az eszközökhöz, vagy tántorítjuk el az eszközök és az Értekezletek ügyfelei közötti meghívásokat.

Kezelőfelület

Javasoljuk, hogy a Control Hub segítségével kezelje az értekezlet-webhelyet.

Ennek fő oka a Control Hub és a Site Administration identitáskezelése 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 Site Administrationben az identitást hely szerint szabályozzák.

Ez azt jelenti, hogy nem rendelkezik Cisco által ellenőrzött identitás opcióval a Webhelyfelügyeletből felügyelt felhasználók számára. Ezek a felhasználók névtelen tanúsítványt kapnak, hogy csatlakozzanak egy végponttól végpontig titkosított értekezlethez, és kizárhatók azokból az értekezletekből, ahol a gazdagép biztosítani kívánja az identitást.

Kapcsolódó információk

JWE-blobok levezetése

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

  • Webex találkozók 41.7.

  • Felhőalapú webex szoba és Webex Desk sorozatú eszközök, amelyek 10.6.1-RoomOS_August_2021.

  • Felügyeleti hozzáférés az értekezlet helyéhez a Control Hubban az új munkamenettípus felhasználók számára való engedélyezésé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ó: Videorendszerek csatlakozásának engedélyezése Webex-értekezletekhez és eseményekhez a webhelyén.

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

A legmagasabb szintű biztonság és a személyazonosság ellenőrzése érdekében minden eszköznek egyedi tanúsítvánnyal kell rendelkeznie, amelyet egy megbízható nyilvános hitelesítésszolgáltató állít ki.

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 igénylésekor ezek a paraméterek a következők:

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

Kihagyhatja ezt a lépést, ha nem szeretne külsőleg ellenőrzött identitást 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 csak nem is csatlakoztatja őket a hálózathoz.

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

  • Mentse 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 elvégezte ezeket a lépéseket, engedélyezze a videorendszerek számára, hogy csatlakozzanak az Értekezletekhez és eseményekhez a webhelyen.

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 kezelését a JSON webtitkosítás (JWE) használatával.

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őre kell tennie a hangsúlyt:

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

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

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

  • 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 elmagyarázzuk a folyamatot és a (nem titkos) paramétereket, amelyekre szüksége lesz, valamint egy receptet, amelyet követnie kell a választott fejlesztési eszközökben. 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.

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

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

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

  • (Ajánlott) Adjon meg egy felületet az eszközhöz (vagy terjessze) az eszközhöz, amely lehetővé teszi az eszköz felhasználói számára a kezdeti titok módosítását (hogy megvédjék adathordozójukat Ö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.

Hivatkoznia kell a JSON webtitkosításra (JWE)https://datatracker.ietf.org/doc/html/rfc7516 és a JSON webaláírásra (JWS).https://datatracker.ietf.org/doc/html/rfc7515

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

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

      Mi neveztük el. cisco-action a JWE jövőbeli kiterjesztéseivel való esetleges ütközések enyhítése érdekében.

    • "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. Az version Kell 1(a legfontosabb származtatási funkciónk változata). Az érték salt legalább 4 bájtból álló, base64 URL-kódolású sorozatnak kell lennie, amelyet véletlenszerűen kell kiválasztania.

  • JWE titkosított kulcs. Ez a mező üres. Az eszköz a kezdeti ClientSecret.

  • JWE inicializálási 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 Rejtjeltext: Ez az a titkosított hasznos teher, amelyet titokban szeretne tartani.

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

    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ő hasznos terheléseket várnak el, és meg kell adnia a hasznos teher célját a cisco-action gombot, az alábbiak szerint:

    • Val "cisco-action":"populate" A rejtjel az új ClientSecret

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

    • A " "cisco-action":"activate" a rejtjel a tanúsítvány ujjlenyomata (sha-1 hexadecimális ábrázolása) az eszközidentitás ellenőrzéséhez aktivált tanúsítványról

    • A " "cisco-action":"deactivate" a rejtjelszöveg az ujjlenyomat (sha-1 hexadecimális ábrázolása) annak a tanúsítványnak, amelyet hatástalanítunk az eszköz személyazonosságának ellenőrzésére való használattól

  • 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 nyerjük le a titkosítási kulcsot a ClientSecret

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 só legalább 4 bájt véletlenszerű szekvenciája; ugyanazt a salt a cisco-kdf paraméter.

  • 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":"1", amely az egyetlen olyan verzió, amelyet jelenleg 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 példában az ügyfél titka a ossifrage.

  1. Válasszon egy titkosítási titkosítási titkosítást. Ez a példa A128GCM(AES 128 bites kulcsokkal Galois Counter módban). Az eszköz használhatja A256GCM Ha úgy tetszik.

  2. Válasszon egy sót (legalább 4 bájt véletlenszerű szekvenciának kell lennie). Ez a példa (hexat bájt) E5 E6 53 08 03 F8 33 F6. Base64url kódolja a sorozatot, hogy 5eZTCAP4M_Y(távolítsa el a base64 párnázást).

  3. Íme egy minta scrypt a tartalomtitkosítási kulcs (cek) létrehozására vonatkozó felhívás:

    cek=scrypt(password="ossifrage", salt=4-byte-sequence, N=32768, r=8, p=1, keylength=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 base64url kódolja lZ66bdEiAQV4_mqdInj_rA.

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

  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","version":"1"},"enc":"A128GCM"}

    A base64url kódolt JOSE fejléc 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 inicializálási vektor NLNd3V9Te68tkpWD.

  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 teher lesz a hamis PEM blob this is a PEM file

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

    • A hasznos teher this is a PEM file

    • 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 terhelést, ami f5lLVuWNfKfmzYCo1YJfODhQ

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

  9. Base64url kódolja a 8. lépésben létrehozott címkét, ami azt eredményezi, hogy 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 nulla megbízhatóságú értekezletek új munkamenettípusai érhetők el, amelyek felár nélkül minden értekezlethelyen elérhetők lesznek. Az egyik új munkamenettí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 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 megkapja a webhely új képességét, de meg kell adnia az új munkamenettípust (más néven értekezlet-jogosultságot) afelhaszná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 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 Hely konfigurálásaelemre.

4

A Közös beállítások területen kattintson a Munkamenettípusokelemre.

Ezen az oldalon egy vagy több végponttól végpontig titkosítási munkamenettí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: Pro-end-end titkosítás. Ez a munkamenettípus nem titkosított PSTN-hozzáférést tartalmaz az értekezletekhez. Győződjön meg arról, hogy a _VOIPonly verzióval rendelkezik a végpontok közötti titkosítás biztosításához. A munkamenetkód oszlop pro hivatkozása fölé 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_VOIPonly-t E2E Encryption + Identity -ra módosítjuk.

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

Kattintson a Felhasználók elemre, é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öbbben van), majd kattintson a Gazdagépgombra.

4

Jelölje be a Pro-End to End E VOIPonly feliratú Webex Meetings bejegyzés mellettincryption_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 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 helykonfigurációs panel megnyitásához.

3

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

4

Kattintson a Exportáláselemre, é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. (A felugró ablakot manuálisan kell bezárnia, 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 az oszlop vesszővel tagolt listaként tartalmazza a munkamenettípus-beli edeket.

7

Minden olyan felhasználó számára, aki meg kívánja adni az új munkamenettípust, adja hozzá a 1561 új értékként a vesszővel tagolt listában a MeetingPrivilege sejt.

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

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.

Ha az eszközök már be vannak táblázva a Control Hub szervezetbe, és a Webex hitelesítésszolgáltatóval szeretné automatikusan létrehozni azonosító tanúsítványaikat, 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 el a Webexnek, hogy melyik tartomány azonosítja az eszközt, kiválasztunk egyet, és rosszul nézhet ki az értekezlet többi résztvevője számára.

Mielőtt elkezdené

Ha az eszközök még nincsenek a fedélzeten, kövesse az Eszköz regisztrálása a Cisco Webex-be API vagy helyi webes felület vagy cloud onboarding for Devicesparancsot. Ellenőrizze azt a tartományt/tartományt is, amelyet az Eszközök kezelése területen található eszközök azonosításához szeretne használni.

1

Jelentkezzen be a Control Hub (https://admin.webex.com) oldalra, és nyissa meg az Eszközök lapot.

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é

Szükséged van:

  • Ha minden eszközhöz .pem formátumú hitelesítésszolgáltató által aláírt tanúsítványt és személyes kulcsot szeretne kapni.

  • A cikk Előkészítése részben olvasható az Eszközök külső identitásfolyamatának ismertetése című témakörben.

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

  • Egy eszköz, amely véletlenszerű hosszú szekvenciákat hoz létre.

  • A bájtok vagy szövegek alapkódolására.

  • Egy scrypt végrehajtás.

  • Minden eszközhöz egy titkos szó vagy kifejezés.

1

Töltse fel az eszköz ClientSecret egyszerű szöveges titkossággal:

Amikor először tölti be a Secret, egyszerű szöveggel adja meg. Ezért javasoljuk, hogy ezt a fizikai eszközkonzolon tegye meg.

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

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

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

    A fenti példa parancs feltölti a Secret A mondattal 0123456789abcdef. Meg kell választania a sajátját.

A készüléknek megvan a kezdeti titka. Ne felejtsd el ezt, nem tudod visszaállítani, és gyárilag vissza kell állítania az eszközt az újraindításhoz.
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 teherszöveg, amelyet titkosít és elhelyez a JWE blobban)

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. JOSE-fejléc létrehozása, beállítás alg, enc és cisco-kdf kulcsok a Külső identitás folyamatának ismertetése az eszközökhöz című témakörben leírtakszerint. Állítsa be a "hozzáadás" műveletet a key:value használatával "cisco-action":"add" 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 Security Certificates Services Add IsEncrypted: True
your..JWE.str.ing\n
.\n
5

Ellenőrizze, hogy a tanúsítványt a 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ából a tanúsítványból, akár a xcommand Security Certificates Services Show.

  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. JOSE-fejléc létrehozása, beállítás alg, enc és cisco-kdf kulcsok a Külső identitás folyamatának ismertetése az eszközökhöz című témakörben leírtakszerint. Állítsa be az "aktiválás" műveletet a key:value használatával "cisco-action":"activate" 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.EncryptedFingerprint.AuthTag

  10. Nyissa meg a TShellt 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, 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 információ 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

Ahol lehetséges, ellenőrizze a résztvevők/eszköz identitásait a tanúsítványok ellenőrzésével.

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. Előfordulhat, hogy egy biztonságos értekezleten legfeljebb 25 eszköz van. Ha ilyen szintű biztonságra van szüksége, ne engedélyezze az értekezlet-ügyfelek csatlakozását.

A biztonságos eszközökhöz csatlakozó felhasználók számára hagyja, hogy az eszközök csatlakozzanak először, és állítsa be a felhasználói elvárásokat, hogy esetleg nem tudnak csatlakozni, ha későn csatlakoznak.

Ha különböző szintű személyazonosság-ellenőrzéssel rendelkezik, felhatalmazza a felhasználókat arra, hogy tanúsítvány által támogatott 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, 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

Csak E2E titkosítás+VoIP

652

Pro-End to End Encryption_VOIPonly

660

Pro 3 Free-End to End 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 end-to end titkosítás

677

Broadworks Premium plus végponttól végpontig 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 Conference EndToEndEncryption Availability

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 Conference EndToEndEncryption ExternalIdentity Verification

Azt jelzi, hogy az eszköz External(külsőleg kiadott tanúsítvánnyal rendelkezik).

xStatus Conference EndToEndEncryption 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ített parancsban cserélje ki a # a tanúsítvány számával. Csere specificinfo az egyik:

  • Fingerprint

  • NotAfter Érvényességi határidő

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

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

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

  • Validity Megadja a tanúsítvány érvényességi állapotát (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 hitelesítésszolgáltató által kiadott érvényes tanúsítvánnyal.

xStatus Conference EndToEndEncryption 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 olyan szervezetben van, amely több tartományt is rendelkezik, ez az érték a PreferredDomain.

xStatus Conference EndToEndEncryption InternalIdentity CertificateChain Certificate # specificinfo

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

A megjelenített parancsban cserélje ki a # a tanúsítvány számával. Csere specificinfo az egyik:

  • Fingerprint

  • NotAfter Érvényességi határidő

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

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

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

  • Validity Megadja a tanúsítvány érvényességi állapotát (pl. valid vagy expired)

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 ParticipantList ParticipantAdded

xEvent Conference ParticipantList ParticipantUpdated

xEvent Conference ParticipantList ParticipantDeleted

Ez a három esemény most már magában foglalja a 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 Populate Secret: "base64url-encoded"

vagy

xCommand Security ClientSecret Populate Secret: JWEblob

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 Security Certificates Services Add JWEblob

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: JWEblob

Egy adott tanúsítvány aktiválása a WebexIdentity számára. Ehhez Purpose, a parancs megköveteli, hogy az azonosító ujjlenyomatot titkosítsa és szerializálja egy JWE blobban.

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

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