Uživatelé zvolí nový typ schůzky při plánování schůzky. Při přijímání účastníků z lobby a během schůzky může hostitel vidět stav ověření totožnosti každého účastníka. K dispozici je také kód schůzky, který je společný všem aktuálním účastníkům schůzky a který mohou použít k ověření.

S hostiteli schůzky sdílejte následující informace:

Ověření identity

Komplexní ověření identity poskytuje další zabezpečení pro komplexní šifrovanou schůzku.

Když se účastníci nebo zařízení připojí ke sdílené skupině MLS (Messaging Layer Security), předloží své certifikáty ostatním členům skupiny, kteří pak certifikáty ověří proti vydávajícímu certifikačnímu úřadu (CA). Potvrzením platnosti certifikátů certifikační úřad ověří identitu účastníků a schůzka zobrazí účastníky / zařízení jako ověřené.

Uživatelé aplikace Webex Meetings se ověřují proti webexu identit, který jim vydá přístupový token, když uspějí. Pokud potřebují certifikát k ověření své identity - v end-to-end šifrované schůzce - webex ca jim vydá certifikát založený na jejich přístupovém tokenu. Dosud neposkytujeme uživatelům webexových schůzek způsob, jak získat certifikát vydaný externím certifikačním úřadem třetí strany.

Zařízení se mohou ověřit pomocí certifikátu vydaného interním certifikačním úřadem (Webex) nebo certifikátu vydaného externím certifikačním úřadem:

  • V případě interní certifikační autority webex vydá interní certifikát založený na přístupovém tokenu účtu počítače zařízení. Certifikát je podepsán certifikační autoritou Webex. Zařízení nemají ID uživatelů stejným způsobem jako uživatelé, takže Webex používá (jednu z) domén vaší organizace při psaní identity certifikátu zařízení (Běžný název (CN)).

  • V případě externí certifikační autority požadujete a zakoupíte certifikáty zařízení přímo od vybraného vyděděče. Certifikáty je nutné zašifrovat, přímo odeslat a autorizovat pomocí tajného klíče, který znáte pouze vy.

    Cisco není zapojeno, což z toho dělá způsob, jak zaručit skutečné end-to-end šifrování a ověřenou identitu, a zabránit teoretické možnosti, že cisco by mohl odposlouchávat vaši schůzku / dešifrovat vaše média.

Interně vydaný certifikát zařízení

Webex vydá zařízení certifikát při registraci po spuštění a v případě potřeby jej obnoví. U zařízení obsahuje certifikát ID účtu a doménu.

Pokud vaše organizace nemá doménu, vydá certifikační úřad Webex certifikát bez domény.

Pokud má vaše organizace více domén, můžete pomocí Ovládacího centra sdělit Webexu, kterou doménu má zařízení použít pro svou identitu. Můžete také použít rozhraní API xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com".

Pokud máte více domén a nesnadílíte upřednostňovanou doménu pro zařízení, webex vybere jednu pro vás.

Externě vydaný certifikát zařízení

Správce může zřídit zařízení s vlastním certifikátem, který byl podepsán jedním z veřejných certifikačních autorit.

Certifikát musí být založen na dvojici klíčů ECDSA P-256, i když může být podepsán klíčem RSA.

Hodnoty v certifikátu jsou na uvážení organizace. Běžný název (CN) a alternativní název předmětu (SAN) se zobrazí v uživatelském rozhraní schůzky Webex, jak je popsáno v části End-to-End Encryption with Identity Verification for Webex Meetings.

Doporučuje se používat samostatný certifikát na zařízení a mít jedinečnou cn na zařízení. To může být například "meeting-room-1.example.com" pro organizaci, která vlastní doménu example.com".

Za účelem úplné ochrany externího certifikátu před manipulací se funkce tajného klienta používá k šifrování a podepisování různých xcommandů.

Při použití tajného klíče klienta je možné bezpečně spravovat externí certifikát identity webexu prostřednictvím xAPI. To je v současné době omezeno na online zařízení.

V současné době webex poskytuje příkazy rozhraní API pro správu tohoto.

Zařízení

Cloudem registrovaná řada Webex Room a zařízení řady Webex Desk se mohou připojit ke koncovým šifrovaným schůzkám, mezi které můžete:

  • Webex Board

  • Webex Desk Pro

  • Webex Desk

  • Webex Room Kit

  • Webex Room Kit Mini

Následující zařízení se nemohou připojit ke konci a ukončit šifrované schůzky:

  • Řada Webex C

  • Řada Webex DX

  • Řada Webex EX

  • Řada Webex MX

  • SIP zařízení třetích stran

Softwarové klienty

  • Od 41.7 se desktopový klient Webex Meetings může připojit ke šifrovaným schůzkám od začátku do konce.

  • Aplikace Webex se nemůže připojit ke koncovým šifrovaným schůzkám.

    Pokud vaše organizace povolí aplikaci Webex připojit se ke schůzkám spuštěním desktopové aplikace Schůzky, můžete tuto možnost použít k připojení se ke šifrovaným schůzkám mezi koncovými stránkami.

  • Webový klient Webex se nemůže připojit ke koncovým šifrovaným schůzkám.

  • Měkcí klienti SIP třetích stran se nemohou připojit ke koncovým šifrovaným schůzkám.

Identita

  • Neposkytujeme žádné možnosti Control Hubu pro správu externě ověřené identity zařízení. Toto rozhodnutí je záměrné, protože pro skutečné end-to-end šifrování byste měli znát/ přistupovat k tajným kódům a klíčům. Pokud jsme zavedli cloudovou službu pro správu těchto klíčů, je možné, že budou zachyceny.

  • V současné době neposkytujeme žádné nástroje, které by vám pomohly požádat o nebo zašifrovat certifikáty identity vašeho zařízení a jejich soukromé klíče. V současné době vám poskytujeme "recept", který vám pomůže navrhnout vlastní nástroje založené na standardních šifrovacích technikách, které vám pomohou s těmito procesy. Nechceme mít žádný skutečný nebo vnímaný přístup k vašim tajemstvím nebo klíčům.

Schůzky

  • Šifrované schůzky od ukončení v současné době podporují maximálně 200 účastníků.

  • Z těchto 200 účastníků se může připojit maximálně 25 externě ověřených zařízení a musí být prvními účastníky, kteří se připojí ke schůzce.

    Když se ke schůzce připojí větší počet zařízení, naše back-endové mediální služby se pokusí překódovat datové proudy médií. Pokud nemůžeme dešifrovat, překódovat a znovu zašifrovat médium (protože nemáme a neměli bychom mít šifrovací klíče zařízení), překódování se nezdaří.

    Chcete-li toto omezení zmírnit, doporučujeme menší schůzky pro zařízení nebo rozmíscení pozvánek mezi zařízeními a klienty schůzek.

Rozhraní pro správu

Důrazně doporučujeme, abyste ke správě webu schůzky používali Control Hub.

Hlavním důvodem je rozdíl mezi způsobem správy ovládacího centra a správy webu. Organizace Centra řízení mají centralizovanou identitu pro celou organizaci, zatímco ve správě webu je identita řízena na webu podle webu.

To znamená, že nemůžete mít možnost identity ověřené cisco pro uživatele, kteří jsou spravováni ze správy webu. Těmto uživatelům je vydán anonymní certifikát pro připojení ke šifrované schůzce mezi koncovými soubory a mohou být vyloučeni ze schůzek, kde chce hostitel zajistit identitu.

Související informace

Odvození ukázkových objektů BLOB JWE

Vzorek správně zašifrovaného JWE na základě daného parametru (dodatek)

  • Webex Schůzky 41.7.

  • Zařízení řady Webex a Webex Desk registrovaná v cloudu, která jsou spuštěna 10.6.1-RoomOS_August_2021.

  • Přístup správce k webu schůzky v Centru řízení, aby bylo možné povolit nový typ relace pro uživatele.

  • Jedna nebo více ověřených domén ve vaší organizaci Control Hub (pokud používáte certifikační autoritu Webex k vydávání certifikátů zařízení pro ověřenou identitu).

Tento krok můžete přeskočit, pokud nepotřebujete externě ověřenou identitu.

Pro nejvyšší úroveň zabezpečení a ověřování identity by každé zařízení mělo mít jedinečný certifikát vydaný důvěryhodným veřejným certifikačním úřadem.

Chcete-li požádat o digitální certifikáty, zakoupit je a obdržet a vytvořit přidružené soukromé klíče, musíte s certifikační autoritou spolupracovat. Při žádosti o certifikát se použijí tyto parametry:

  • Certifikát musí být vydán a podepsán známým veřejným certifikačním úřadem.

  • Jedinečný: Důrazně doporučujeme použít jedinečný certifikát pro každé zařízení. Pokud používáte jeden certifikát pro všechna zařízení, ohrožujete zabezpečení.

  • Běžný název (KN) a alternativní název/názvy předmětů (SAN/s): Ty nejsou pro Webex důležité, ale měly by to být hodnoty, které lidé mohou číst a přidružovat k zařízení. Cn se ostatním účastníkům schůzky zobrazí jako primární ověřená identita zařízení, a pokud uživatelé zkontrolují certifikát prostřednictvím uživatelského rozhraní schůzky, uvidí san/s. Možná budete chtít použít názvy jako name.model@example.com Ale je to tvoje volba.

  • Formát souboru: Certifikáty a klíče musí být ve formátu PEM.

  • Účel: Účelem certifikátu musí být webex identity.

  • Generování klíčů: Certifikáty musí být založeny na párech klíčů ECDSA P-256 (algoritmus digitálního podpisu eliptické křivky pomocí křivky P-256).

    Tento požadavek se nevztahuje na podpisový klíč. Certifikační úřad může k podpisu certifikátu použít klíč RSA.

Tento krok můžete přeskočit, pokud nechcete se zařízeními používat externě ověřenou identitu.

Pokud používáte nová zařízení, ještě je neregistrovat na webex. Nejbezpečnější je ještě ani nepřipojit k síti.

Pokud máte existující zařízení, která chcete upgradovat, abyste mohli používat externě ověřenou identitu, budete muset zařízení obnovit z výroby.

  • Chcete-li zachovat stávající konfiguraci, uložte ji.

  • Naplánujte okno, když zařízení nepoužívala, nebo použijte fázovaný přístup. Upozorněte uživatele na změny, které mohou očekávat.

  • Zajistěte fyzický přístup k zařízením. Pokud potřebujete přistupovat k zařízením v síti, uvědomte si, že tajné klíče cestují ve formátu prostého textu a ohrožujete zabezpečení.

Chcete-li zajistit, aby média zařízení nemohl zašifrovat nikdo jiný než zařízení, je nutné zašifrovat soukromý klíč v zařízení. Rozhraní API pro zařízení jsme navrhli tak, aby umožňovala správu šifrovaného klíče a certifikátu pomocí JSON Web Encryption (JWE).

Abychom zajistili skutečné end-to-end šifrování prostřednictvím našeho cloudu, nemůžeme se podílet na šifrování a nahrávání certifikátu a klíče. Pokud potřebujete tuto úroveň zabezpečení, je na vás, abyste:

  • Vyžádejte si certifikáty.

  • Vygenerujte páry klíčů certifikátů.

  • Vytvořte (a chraňte) počáteční tajný klíč pro každé zařízení, abyste se zmýlili v šifrovací schopnosti zařízení.

  • Vyvíjejte a udržujte svůj vlastní nástroj pro šifrování souborů pomocí standardu JWE.

    Níže vysvětlujeme proces a (netajné) parametry, které budete potřebovat, a recept, který je třeba dodržovat ve vašich vývojových nástrojích. Poskytujeme také některá testovací data a výsledné objekty blob JWE, jak je očekáváme, abychom vám pomohli ověřit váš proces.

    Nepodporovaná referenční implementace pomocí Pythonu3 a knihovny JWCrypto je k dispozici od Cisco na vyžádání.

  • Zřetědněte a zašifrujte certifikát a klíč pomocí nástroje a počátečního tajného klíče zařízení.

  • Nahrajte výsledný objekt BLOB JWE do zařízení.

  • Nastavte účel šifrovaného certifikátu, který se má použít pro identitu webexu, a aktivujte certifikát.

  • (Doporučeno) Poskytněte rozhraní k nástroji (nebo ho distribuujte), aby uživatelé zařízení mohli změnit počáteční tajný klíč (aby před vás chránili svá média!).

Jak používáme formát JWE

Tato část popisuje, jak očekáváme, že JWE bude vytvořen jako vstup do zařízení, abyste mohli vytvořit vlastní nástroj pro vytvoření objektů BLOB z certifikátů a klíčů.

Budete muset odkazovat na JSON Web Encryption (JWE) ahttps://datatracker.ietf.org/doc/html/rfc7516JSON Web Signature (JWS)https://datatracker.ietf.org/doc/html/rfc7515.

Rozhodli jsme se použít kompaktní serializaci dokumentu JSON k vytvoření objektů BLOB JWE. Parametry, které budete muset zahrnout při vytváření objektů BLOB JWE, jsou:

  • Hlavička JOSE (chráněná). Do hlavičky JSON Object Signing and Encryption MUSÍTE zahrnout následující páry klíč-hodnota:

    • "alg":"dir"

      Přímý algoritmus je jediný, který podporujeme pro šifrování datové části, a musíte použít počáteční klientský tajný klíč zařízení.

    • "enc":"A128GCM" nebo "enc":"A256GCM"

      Podporujeme tyto dva šifrovací algoritmy.

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

      Jedná se o proprietární klíč a čtyři hodnoty, které může přijmout. Tento klíč jsme zavedli, abychom signalizovali účel šifrovaných dat cílovému zařízení. Hodnoty jsou pojmenovány po příkazech xAPI v zařízení, kde používáte šifrovaná data.

      Pojmenovali jsme ho cisco-action ke zmírnění potenciálních střetů s budoucími rozšířeními JWE.

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

      Další proprietární klíč. Hodnoty, které poskytnete, používáme jako vstupy pro odvození klíče v zařízení. Ten version musí být 1(verze naší funkce odvození klíče). Hodnota salt musí se jednat o sekvenci kódovaná adresou URL base64 o 4 bajtech, kterou musíte zvolit náhodně.

  • Šifrovaný klíč JWE. Toto pole je prázdné. Zařízení je odvozeno od počátečního ClientSecret.

  • Inicializační vektor JWE. Pro dešifrování datové části je nutné zadávat inicializační vektor kódovaný base64url. IV MUSÍ být náhodná 12bajtová hodnota (používáme rodinu šifr AES-GCM, která vyžaduje, aby IV byla dlouhá 12 bajtů).

  • JWE AAD (další ověřená data). Toto pole je nutné vyzýt, protože není podporováno v kompaktní serializaci.

  • Šifrovaný text JWE: Toto je zašifrovaná datová část, kterou chcete uchovat v tajnosti.

    Datová část může být prázdná (Například chcete-li resetovat tajný klíč klienta, musíte ji přepsat prázdnou hodnotou).

    Existují různé typy dat v závislosti na tom, co se pokoušíte udělat v zařízení. Různé příkazy xAPI očekávají různé datové části a je nutné zadat účel datové části pomocí cisco-action klíč, takto:

    • Houžev "cisco-action":"populate" šifrovaný text je nový ClientSecret

    • S " "cisco-action":"add" šifrovaný text je PEM blob nesoucí certifikát a jeho soukromý klíč (zřetězený)

    • S " "cisco-action":"activate" šifrovaný text je otisk prstu (šestnáctkové znázornění sha-1) certifikátu, který aktivujete pro ověření identity zařízení

    • S " "cisco-action":"deactivate" šifrovaný text je otisk prstu (šestnáctkové znázornění sha-1) certifikátu, který deaktivujeme z použití pro ověření identity zařízení

  • Značka ověřování JWE: Toto pole obsahuje ověřovací značku pro zjištění integrity celého kompaktně serializovaného objektu BLOB JWE.

Jak odvozujeme šifrovací klíč z ClientSecret

Po první populaci tajemství nepřijímáme ani nevysíláme tajemství jako prostý text. Tím se zabrání potenciálním slovníkovým útokům někoho, kdo by mohl přistupovat k zařízení.

Software zařízení používá tajný klíč klienta jako vstup do funkce odvození klíče (kdf) a pak používá odvozený klíč pro dešifrování/šifrování obsahu v zařízení.

To pro vás znamená, že váš nástroj pro vytvoření objektů BLOB JWE musí postupovat stejným způsobem, aby odvodil stejný šifrovací/dešifrovací klíč z tajného klíče klienta.

Zařízení používají scrypt pro odvození klíče (viz https://en.wikipedia.org/wiki/Scrypt), s následujícími parametry:

  • CostFactor (N) je 32768

  • BlockSizeFactor (r) je 8

  • ParallelizationFactor (p) je 1

  • Sůl je náhodná sekvence nejméně 4 bajtů; musíte dodat stejné salt při specifikování cisco-kdf parametr.

  • Délky klíčů jsou buď 16 bajtů (pokud vyberete algoritmus AES-GCM 128), nebo 32 bajtů (pokud vyberete algoritmus AES-GCM 256)

  • Maximální paměťové víčko je 64MB

Tato sada parametrů je jedinou konfigurací scryptu, která je kompatibilní s funkcí odvození klíčů na zařízeních. Tento kdf na zařízeních se nazývá "version":"1", což je jediná verze, kterou v současné době používá cisco-kdf parametr.

Příklad opracované

Zde je příklad, který můžete sledovat, abyste ověřili, že proces šifrování JWE funguje stejně jako proces, který jsme vytvořili na zařízeních.

Příkladem scénáře je přidání objektu BLOB PEM do zařízení (napodobuje přidání certifikátu s velmi krátkým řetězcem namísto úplného klíče certifikát + ). Tajný klíč klienta v příkladu je ossifrage.

  1. Zvolte šifrovací šifru. Tento příklad používá A128GCM(AES se 128bitovým klíčem v režimu Galois Counter). Váš nástroj by mohl používat A256GCM pokud chcete.

  2. Vyberte sůl (musí to být náhodná sekvence nejméně 4 bajtů). Tento příklad používá (hex bajty) E5 E6 53 08 03 F8 33 F6. Base64url kóduje sekvenci, aby se 5eZTCAP4M_Y(odstraňte polstrování base64).

  3. Zde je ukázka scrypt volání pro vytvoření šifrovacího klíče obsahu (cek):

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

    Odvozený klíč by měl být 16 bajtů (hex) takto: 95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac které base64url kóduje lZ66bdEiAQV4_mqdInj_rA.

  4. Zvolte náhodnou sekvenci 12 bajtů, která se použije jako inicializační vektor. Tento příklad používá (hex) 34 b3 5d dd 5f 53 7b af 2d 92 95 83 které base64url kóduje NLNd3V9Te68tkpWD.

  5. Vytvořte hlavičku JOSE s kompaktní serializací (postupujte podle stejného pořadí parametrů, které používáme zde) a pak ji base64url kódujte:

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

    Hlavička JOSE kódovaná base64url je eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

    Toto bude první prvek objektu BLOB JWE.

  6. Druhý prvek objektu BLOB JWE je prázdný, protože dodáme šifrovací klíč JWE.

  7. Třetím prvkem objektu BLOB JWE je inicializační vektor NLNd3V9Te68tkpWD.

  8. Pomocí šifrovacího nástroje JWE můžete vytvořit šifrovanou datovou část a značku. V tomto příkladu bude nezašifrovaná datová část falešným objektem PEM this is a PEM file

    Parametry šifrování, které byste měli použít, jsou:

    • Datová část je this is a PEM file

    • Šifrovací šifra je AES 128 GCM

    • Base64url zakódoval hlavičku JOSE jako další ověřená data (AAD)

    Base64url kóduje šifrovanou datovou část, což by mělo mít za následek f5lLVuWNfKfmzYCo1YJfODhQ

    Toto je čtvrtý prvek (JWE Ciphertext) v objektu BLOB JWE.

  9. Base64url kóduje značku, kterou jste vytvořili v kroku 8, což by mělo mít za následek PE-wDFWGXFFBeo928cfZ1Q

    Toto je pátý prvek v objektu BLOB JWE.

  10. Zřetězte pět prvků objektu BLOB JWE tečkami (JOSEheader.. IV.Ciphertext.Tag) pro získání:

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

  11. Pokud jste odvodili stejné hodnoty kódované base64url, jak zde ukazujeme, pomocí vlastních nástrojů jste připraveni je použít k zabezpečení šifrování E2E a ověřené identity vašich zařízení.

  12. Tento příklad ve skutečnosti nebude fungovat, ale v zásadě by vaším dalším krokem bylo použití objektu BLOB JWE, který jste vytvořili výše, jako vstup do xcommandu na zařízení, které přidává certifikát:

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

Existují nové typy relací pro schůzky s nulovou důvěryhodností, které zavádíme na všechna místa schůzek bez dalších nákladů. Jeden z nových typů relací se nazývá Pro-End to End Encryption_VOIPonly. Toto je název veřejné služby, který můžeme v budoucnu změnit. Aktuální názvy typů relací viz ID typu relace v části Reference v tomto článku.

Není třeba nic dělat, abyste získali novou funkci pro svůj web, ale budete muset uživatelům udělit nový typ relace (nazývaný také Oprávnění keschůzce). Můžete to udělat individuálně prostřednictvím konfigurační stránky uživatele nebo hromadně s zpáteční cestou exportu / importu CSV.

1

Přihlaste se k Ovládacímu centru a otevřete stránku Schůzka.

2

Klepnutím na název webu otevřete konfigurační panel webu.

3

Klepněte na tlačítko Konfigurovat web.

4

V oblasti Společná nastavení klepněte na položku Typy relací.

Na této stránce byste měli vidět jeden nebo více typů koncových relací šifrování. Seznam ÍD typu relace naleznete v části Reference v tomto článku. Může se například zobrazit pro-end to-end Encryption_VOIPonly.

 

Existuje starší typ relace s velmi podobným názvem: Šifrování pro-end to-end. Tento typ relace zahrnuje nešifrovaný přístup k schůzkám ve SSD. Ujistěte se, že máte _VOIPonly, která zajišťuje šifrování end-to-end. Můžete to zkontrolovat tak, že najedete myší na odkaz PRO ve sloupci kódu relace; v tomto příkladu by měl být cíl odkazu javascript:ShowFeature(652).

Názvy veřejných služeb pro tyto typy relací můžeme v budoucnu změnit, například plánujeme změnit pro-end na konec Encryption_VOIPonly na šifrování E2E + identitu.

5

Pokud nový typ relace ještě nemáte, obraťte se na zástupce webexu.

Co dělat dál

Povolte toto oprávnění typu relace / schůzky některým nebo všem uživatelům.

1

Klepněte na Uživatelé a vyberte uživatele, chcete-li otevřít konfigurační panel uživatele.

2

V oblasti Služby klepněte na položku Schůzky společnostiCisco Webex.

3

Vyberte web (pokud je uživatel ve více než jednom) a klepněte na tlačítko Hostitel.

4

Zaškrtněte políčko vedle položky Schůzky Webex s označením Pro-End to End Encryption_VOIPonly.

5

Zavřete konfigurační panel uživatele.

6

V případě potřeby opakujte pro ostatní uživatele.

Pokud to chcete přiřadit mnoha uživatelům, použijte možnost hromadného csv.

1

Přihlaste se k Ovládacímu centru https://admin.webex.com na stránce Schůzka a otevřete ji.

2

Klepnutím na název webu otevřete panel konfigurace webu.

3

V části Licence a uživatelé klikněte naHromadná správa.

4

Klepněte natlačítko Exportovat a počkejte, než soubor připravíme.

5

Až bude soubor připraven, klikněte na Exportovat výsledky a potom na Stáhnout. (Po kliknutí na tlačítko je nutné toto vyskakovací okno zavřít ručně Stáhnout.)

6

Otevřete stažený soubor CSV pro úpravy.

Pro každého uživatele existuje řádek a MeetingPrivilege sloupec obsahuje jejich ÍD typu relace jako seznam oddělený čárkami.

7

Pro každého uživatele, který chcete udělit nový typ relace, přidejte 1561 jako nová hodnota v seznamu odděleném čárkami v seznamu MeetingPrivilege buňka.

Odkaz na formát souboru CSV https://help.webex.com/en-us/5vox83 na místě obsahuje určité podrobnosti o účelu a obsahu souboru CSV.

8

Otevřete konfigurační panel Web schůzky v Ovládacím centru.

Pokud jste již byli na stránce seznamu webů schůzky, bude možná nutné ji aktualizovat.

9

V části Licence a uživatelé klikněte naHromadná správa.

10

Klikněte na Importovat a vyberte upravené CSV a potom klikněte na Importovat . Počkejte, než nahrajeme soubor.

11

Po dokončení importu můžete klepnutím na tlačítko Importovat výsledky zkontrolovat, zda došlo k chybám.

12

Přejděte na stránku Uživatelé a otevřete jednoho z uživatelů, abyste ověřili, že mají nový typ relace.

Pokud jsou vaše zařízení již připojena k organizaci Centra řízení a chcete použít certifikační autoritu Webex k automatickému generování jejich identifikačních certifikátů, není nutné zařízení resetovat z výroby.

Tento postup vybere doménu, kterou zařízení používá k identifikaci, a bude vyžadován pouze v případě, že máte v organizaci Control Hub více domén. Pokud máte více než jednu doménu, doporučujeme to udělat pro všechna vaše zařízení, která budou mít identitu ověřenou cisco. Pokud neřeknete webexu, která doména zařízení identifikuje, vybereme jednu a ostatním účastníkům schůzky to může při vypadat špatně.

Než začnete

Pokud vaše zařízení ještě nejsou připojena, můžete je sledovat https://help.webex.com/n25jyr8 nebo https://help.webex.com/nutc0dy. Měli byste také ověřit domény, které chcete použít k identifikaci zařízení (https://help.webex.com/cd6d84).

1

Přihlaste se k Ovládacímu centru (https://admin.webex.com) a otevřete stránku Zařízení.

2

Vyberte zařízení, které chcete otevřít konfigurační panel.

3

Vyberte doménu, kterou chcete použít k identifikaci tohoto zařízení.

4

Opakujte pro jiná zařízení.

Než začnete

Potřebuješ:

  • Získání certifikátu podepsaného certifikační autoritou a soukromého klíče ve formátu PEM pro každé zařízení.

  • Chcete-li si přečíst téma Principy procesu externíidentity pro zařízení , přečtěte si v části Příprava tohoto článku.

  • Příprava šifrovacího nástroje JWE s ohledem na informace, které jsou zde k dispozici.

  • Nástroj pro generování náhodných sekvencí bajtů dané délky.

  • Nástroj pro base64url encode bajty nebo text.

  • Jakýsi scrypt implementace.

  • Tajné slovo nebo fráze pro každé zařízení.

1

Naplnění zařízení ClientSecret s tajným kódem ve formátu prostého textu:

Při prvním naplnění Secret, zadávat ve formátu prostého textu. Proto doporučujeme, abyste to udělali na konzoli fyzického zařízení.

  1. Base64url kóduje tajnou frázi pro toto zařízení.

  2. Otevřete TShell na zařízení.

  3. Spustit xcommand Security ClientSecret Populate Secret: "MDEyMzQ1Njc4OWFiY2RlZg"

    Výše uvedený příklad naplní Secret s frází 0123456789abcdef. Musíš si vybrat vlastní.

Zařízení má své počáteční tajemství. Nezapomeňte na to, nemůžete ji obnovit a musíte zařízení obnovit z výroby, aby se znovu spusťte.
2

Zřetědněte certifikát a soukromý klíč:

  1. Pomocí textového editoru otevřete soubory PEM, vložte objekt BLOB certifikátu a uložte ho jako nový soubor PEM.

    (Toto je text datové části, který zašifrujete a vložíte do objektu BLOB JWE)

3

Vytvořte objekt BLOB JWE, který se použije jako vstup do příkazu pro přidání certifikátu:

  1. Vytvořte náhodnou sekvenci nejméně 4 bajtů. Tohle je tvoje sůl.

  2. Odvozujte šifrovací klíč obsahu pomocí nástroje scrypt.

    K tomu potřebujete tajemství, sůl a klíč, aby odpovídaly zvolené šifrovací šifře. Existují některé další pevné hodnoty, které mají být dodávány (N=32768, r=8, p=1). Zařízení používá stejný proces a hodnoty k odvození stejného šifrovacího klíče obsahu.

  3. Vytvořte náhodnou sekvenci přesně 12 bajtů. Tohle je váš inicializační vektor.

  4. Vytvoření záhlaví JOSE, nastavení alg, enc a cisco-kdf klíče popsané v popisu procesu externí identity pro zařízení. Nastavení akce "přidat" pomocí klíče:hodnota "cisco-action":"add" v záhlaví JOSE (protože přidáváme certifikát do zařízení).

  5. Base64url kóduje hlavičku JOSE.

  6. Pomocí šifrovacího nástroje JWE s vybranou šifrou a hlavičkou JOSE kódovanou base64url zašifrujte text ze zřetězeného souboru PEM.

  7. Base64url kóduje inicializační vektor, šifrovanou datovou část PEM a ověřovací značku.

  8. Vytvořte objekt BLOB JWE následujícím způsobem (všechny hodnoty jsou kódovány base64url):

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4

Otevřete TShell na zařízení a spusťte příkaz (víceřádkový) přidat:

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

Ověření, zda je certifikát přidán spuštěním xcommand Security Certificates Services Show

Zkopírujte otisk nového certifikátu.

6

Aktivovat certifikát pro tento účel WebexIdentity:

  1. Přečtěte si otisk prstu certifikátu, a to buď ze samotného certifikátu, nebo z výstupu xcommand Security Certificates Services Show.

  2. Vytvořte náhodnou sekvenci nejméně 4 bajtů a base64url tuto sekvenci zakódujte. Tohle je tvoje sůl.

  3. Odvozujte šifrovací klíč obsahu pomocí nástroje scrypt.

    K tomu potřebujete tajemství, sůl a klíč, aby odpovídaly zvolené šifrovací šifře. Existují některé další pevné hodnoty, které mají být dodávány (N=32768, r=8, p=1). Zařízení používá stejný proces a hodnoty k odvození stejného šifrovacího klíče obsahu.

  4. Vytvořte náhodnou sekvenci přesně 12 bajtů a base64url tuto sekvenci zakódujte. Tohle je váš inicializační vektor.

  5. Vytvoření záhlaví JOSE, nastavení alg, enc a cisco-kdf klíče popsané v popisu procesu externí identity pro zařízení. Nastavení akce "aktivovat" pomocí klíče:hodnota "cisco-action":"activate" v záhlaví JOSE (protože aktivujeme certifikát v zařízení).

  6. Base64url kóduje hlavičku JOSE.

  7. Pomocí šifrovacího nástroje JWE s vybranou šifrou a hlavičkou JOSE kódovanou base64url zašifrujte otisk certifikátu.

    Nástroj by měl vysunutí 16 nebo 32 bajtové sekvence v závislosti na tom, zda jste zvolili 128 nebo 256 bitový AES-GCM a ověřovací značku.

  8. Base64urlencode šifrovaný otisk prstu a ověřovací značka.

  9. Vytvořte objekt BLOB JWE následujícím způsobem (všechny hodnoty jsou kódovány base64url):

    JOSEHeader..InitVector.EncryptedFingerprint.AuthTag

  10. Otevřete TShell na zařízení a spusťte následující příkaz activate:

    xcommand Security Certificates Services Activate Purpose: WebexIdentity Fingerprint: "Your..JWE.encrypted.fingerprint"
Zařízení má šifrovaný, aktivní certifikát vydaný certifikační autoritou, který je připraven k jeho identifikaci při koncových šifrovaných schůzkách webexu.
7

Naložte zařízení do organizace Control Hub.

1

Naplánování schůzky správného typu (Webex Meetings Pro-End to End Encryption_VOIPonly).

2

Připojte se ke schůzce jako hostitel z klienta schůzek Webex.

3

Připojte se ke schůzce ze zařízení, jehož identitu ověřuje certifikační úřad Webex.

4

Jako hostitel ověřte, zda se toto zařízení zobrazí ve vstupní hale se správnou ikonou identity.

5

Připojte se ke schůzce ze zařízení, jehož identitu ověřuje externí certifikační úřad.

6

Jako hostitel ověřte, zda se toto zařízení zobrazí ve vstupní hale se správnou ikonou identity.

7

Připojte se ke schůzce jako neověřený účastník schůzky.

8

Jako hostitel ověřte, zda se tento účastník zobrazí ve vstupní hale se správnou ikonou identity.

9

Jako hostitel přijměte nebo odmítejte lidi / zařízení.

10

Pokud je to možné, ověřte identity účastníků/zařízení kontrolou certifikátů.

11

Zkontrolujte, zda všichni na schůzce uvidí stejný bezpečnostní kód schůzky.

12

Připojte se ke schůzce s novým účastníkem.

13

Zkontrolujte, zda všichni vidí stejný nový bezpečnostní kód schůzky.

Chcete nastavit šifrované schůzky mezi koncovými soubory jako výchozí možnost schůzky nebo ji povolit pouze pro některé uživatele nebo povolit rozhodnutí všem hostitelům? Až se rozhodnete, jak budete tuto funkci používat, připravte si uživatele, kteří ji budou používat, zejména s ohledem na omezení a to, co můžete na schůzce očekávat.

Potřebujete zajistit, aby cisco ani nikdo jiný nemůže dešifrovat váš obsah nebo se vydávat za vaše zařízení? Pokud ano, potřebujete certifikáty od veřejného certifikačního úřadu. V zabezpečené schůzce můžete mít jenom 25 zařízení. Pokud potřebujete tuto úroveň zabezpečení, neměli byste klientům schůzek povolit připojení.

Pro uživatele, kteří se připojují k zabezpečeným zařízením, nechte zařízení, aby se připojila jako první, a nastavte očekávání uživatelů, že se nemusí být schopni připojit, pokud se připojí pozdě.

Pokud máte různé úrovně ověřování identity, umožněte uživatelům vzájemně se ověřovat pomocí identity podporované certifikátem a bezpečnostního kódu schůzky. I když existují okolnosti, kdy se účastníci mohou jevit jako neověření a účastníci by měli vědět, jak to zkontrolovat, neověření lidé nemusí být podvodníci.

Pokud k vydávání certifikátů zařízení používáte externí certifikační autoritu, je na vás, abyste certifikáty monitorovali, obnovovali a znovu používali.

Pokud jste vytvořili počáteční tajný klíč, pochopte, že uživatelé mohou chtít změnit tajný klíč svého zařízení. Možná budete muset vytvořit rozhraní nebo distribuovat nástroj, který jim to umožní.

Tabulka 1. ID typu relace pro šifrované schůzky mezi koncovými soubory

ID typu relace

Název veřejné služby

638

Pouze šifrování E2E+VoIP

652

Pro-End to End Encryption_VOIPonly

660

Pro 3 Free-End to End Encryption_VOIPonly

Šifrování E2E + identita

672

Pro 3 Zdarma50-End to End Encryption_VOIPonly

673

Instruktor vzdělávání E2E Encryption_VOIPonly

676

Šifrování Broadworks Standard plus end-to-end

677

Šifrování Broadworks Premium plus end-to-end

681

Schoology Free plus šifrování od konce do konce

Tyto tabulky popisují příkazy rozhraní API zařízení Webex, které jsme přidali pro šifrované schůzky a ověřenou identitu mezi koncovými účely. Další informace o používání rozhraní API viz https://help.webex.com/nzwo1ok.

Tabulka 2. Rozhraní API na úrovni systému pro šifrované schůzky mezi koncovými soubory a ověřenou identitu

Volání rozhraní API

Popis

xConfiguration Conference EndToEndEncryption Mode: On

Režim šifrování od konce do konce On nebo Off.

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

Tato konfigurace se spustí, když správce nastaví upřednostňovanou doménu zařízení z Ovládacího centra. Je to nutné pouze v případě, že organizace má více než jednu doménu.

Zařízení používá tuto doménu, když požaduje certifikát od služby Webex CA. Doména pak zařízení identifikuje.

Tato konfigurace není použitelná, pokud má zařízení aktivní, externě vydaný certifikát k identifikaci.

xStatus Conference EndToEndEncryption Availability

Označuje, zda se zařízení může připojit ke šifrované schůzce mezi koncovými soubory. Cloudové rozhraní API ho volá, aby spárovaná aplikace věděla, jestli se může připojit k zařízení.

xStatus Conference EndToEndEncryption ExternalIdentity Valid

Označuje, zda má zařízení platný externě vydaný certifikát.

xStatus Conference EndToEndEncryption ExternalIdentity Identity

Identita zařízení načetná z běžného názvu externě vydaného certifikátu.

xStatus Conference EndToEndEncryption ExternalIdentity CertInfo

Přečte informace o certifikátu z externě vydaného certifikátu a vysídlí je jako objekt BLOB JSON.

xStatus Conference EndToEndEncryption InternalIdentity Valid

Označuje, zda má zařízení platný certifikát vydaný certifikační autoritou Webex.

xStatus Conference EndToEndEncryption InternalIdentity Identity

Identita zařízení načetná z běžného názvu certifikátu vydaného webexem.

Obsahuje název domény, pokud má organizace doménu.

Je prázdná, pokud organizace nemá doménu.

Pokud se zařízení nachází v organizaci, která má více domén, jedná se o hodnotu z PreferredDomain.

xStatus Conference EndToEndEncryption InternalIdentity CertInfo

Přečte informace o certifikátu z certifikátu vydaného webexem a vysunutí je jako objekt BLOB JSON.

Tabulka 3. V rozhraních API pro koncové šifrované schůzky a ověřenou identitu

Volání rozhraní API

Popis

xStatus Call # ServerEncryption Type

Přečte šifrovací šifru použitou v připojení HTTPS k webexu. Zobrazí se uživateli.

xStatus Conference Call # EndToEndEncryption Status

Přečte stav šifrování mezi koncovými hovory. Zobrazí se uživateli jako přítomnost (nebo absence) ikony visacího zámku.

xStatus Conference Call # EndToEndEncryption SecurityCode

Přečte bezpečnostní kód schůzky. Zobrazí se uživateli a změní se, když se účastníci připojí.

xStatus Conference Call # EndToEndEncryption MediaEncryption Type

Přečte šifrovací šifru použitou v připojení k médiu. Zobrazí se uživateli.

xStatus Conference Call # EndToEndEncryption GroupEncryption Type

Přečte šifrovací šifru používanou pro zabezpečení vrstvy zasílání zpráv (MLS).

xStatus Conference Call # EndToEndEncryption Roster Participant

Uvádí seznam účastníků přispívajících do stavu skupiny MLS na této schůzce. Seznam je zjištěn v MLS, nikoli webexu.

xStatus Conference Call # EndToEndEncryption Roster Participant # Id

Adresa URL služby WDM zadaného účastníka.

xStatus Conference Call # EndToEndEncryption Roster Participant # Status:

Stav ověření zadaného účastníka.

xStatus Conference Call # EndToEndEncryption Roster Participant # Identity:

Primární identita zadaného účastníka, obvykle domény (zařízení) nebo e-mailové adresy (uživatele).

xStatus Conference Call # EndToEndEncryption Roster Participant # DisplayName:

Zobrazované jméno zadaného účastníka. Podepsáno účastníkem/zařízením.

xStatus Conference Call # EndToEndEncryption Roster Participant # CertInfo:

Informace o certifikátu ze zadaného certifikátu účastníka jako objekt BLOB JSON.

xCommand Conference ParticipantList Search

Tento příkaz jsme rozšířili tak, aby zahrnoval informace o šifrování mezi koncovými technologiemi pro účastníky.

xCommand Conference ParticipantList Search

Hledání seznamu účastníků nyní zahrnuje EndToEndEncryptionStatus, stav ověření totožnosti účastníka. Tato hodnota se zobrazí v uživatelském rozhraní.

xCommand Conference ParticipantList Search

Hledání seznamu účastníků nyní zahrnuje EndToEndEncryptionIdentity, primární identitu účastníka. Obvykle se jedná o doménu nebo e-mailovou adresu. Tato hodnota se zobrazí v uživatelském rozhraní.

xCommand Conference ParticipantList Search

Hledání seznamu účastníků nyní zahrnuje EndToEndEncryptionCertInfo, objekt BLOB JSON obsahující certifikát účastníka. Tato hodnota se zobrazí v uživatelském rozhraní.

xEvent Conference ParticipantList Participant(Added)

xEvent Conference ParticipantList Participant(Updated)

xEvent Conference ParticipantList Participant(Deleted)

Tyto tři události nyní zahrnují EndToEndEncryptionStatus, EndToEndEncryptionIdentity a EndToEndEncryptionCertInfo pro dotčeného účastníka.

Tabulka 4. Rozhraní API související s klientemSecret pro šifrované schůzky mezi koncovými soubory a ověřenou identitu

Volání rozhraní API

Popis

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

Přijme hodnotu prostého textu zakódovaná base64url pro první nasazení tajného kódu klienta v zařízení.

Chcete-li aktualizovat tajný klíč po tomto prvním datu, musíte dodat objekt BLOB JWE obsahující nový tajný klíč zašifrovaný starým tajným kódem.

xCommand Security Certificates Services Add JWEblob

Přidá certifikát (se soukromým klíčem).

Tento příkaz jsme rozšířili tak, aby přijímal objekt BLOB JWE obsahující šifrovaná data PEM.

xCommand Security Certificates Services Activate Purpose:WebexIdentity FingerPrint: JWEblob

Aktivuje konkrétní certifikát pro WebexIdentity. Za tímto způsobem Purpose, příkaz vyžaduje, aby identifikační otisk prstu byl zašifrován a serializován v objektu BLOB JWE.

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

Deaktivuje určitý certifikát pro WebexIdentity. Za tímto způsobem Purpose, příkaz vyžaduje, aby identifikační otisk prstu byl zašifrován a serializován v objektu BLOB JWE.