Uživatelské prostředí

Uživatelé při plánování schůzky zvolí nový typ 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ý pro všechny aktuální účastníky schůzky, který mohou použít k vzájemnému ověření.

Sdílejte s hostiteli schůzky následující informace:

Ověření identity u interní nebo externí certifikační autority

Ověření totožnosti

Komplexní ověření identity poskytuje další zabezpečení pro šifrovanou schůzku typu end-to-end.

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 ověří certifikáty proti vydávající certifikační autoritě (CA). Potvrzením platnosti certifikátů certifikační autorita ověří identitu účastníků a schůzka zobrazí účastníky / zařízení jako ověřené.

Uživatelé aplikace Webex Meetings se ověřují proti úložišti identit Webex, které jim po úspěchu vydá přístupový token. Pokud potřebují certifikát k ověření své identity – v end-to-end šifrované schůzce – certifikační autorita Webex jim vydá certifikát na základě jejich přístupového tokenu. Zatím neposkytujeme uživatelům webex Meetings způsob, jak získat certifikát vydaný třetí stranou / externí certifikační autoritou.

Zařízení se můžou ověřit pomocí certifikátu vydaného interní certifikační autoritou (Webex) nebo certifikátu vydaného externí certifikační autoritou:

  • 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 zápisu identity certifikátu zařízení (běžný název (CN)).

  • V případě externí certifikační autority si vyžádáte a zakoupíte certifikáty zařízení přímo od vybraného vystavitele. Certifikáty musíte zašifrovat, přímo nahrát a autorizovat pomocí tajného klíče, který znáte jenom vy.

    Společnost Cisco není zapojena, což z něj činí způsob, jak zaručit skutečné šifrování end-to-end a ověřenou identitu a zabránit teoretické možnosti, že by společnost Cisco mohla odposlouchávat vaši schůzku / dešifrovat vaše média.

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

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

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

Pokud má vaše organizace více domén, můžete pomocí Control Hub 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 nenastavujete preferovanou doménu pro zařízení, Webex vybere jednu pro vás.

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

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

Certifikát musí být založen na páru 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 subjektu (SAN) se zobrazí v uživatelském rozhraní schůzky Webex, jak je popsáno v tématu End-to-End šifrování s ověřením identity pro schůzky Webex.

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

Aby byl externí certifikát plně chráněn před neoprávněnou manipulací, používá se k šifrování a podepisování různých příkazů xcommand funkce tajného klíče klienta.

Při použití tajného klíče klienta je možné bezpečně spravovat externí certifikát identity webex 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.

Funkce a omezení

Zařízení

Zařízení řady Webex Room registrovaných v cloudu a zařízení řady Webex Desk se mohou připojit k šifrovaným schůzkám mezi koncovými body, včetně:

  • Webex Board

  • Webex Desk Pro

  • Pracovní stůl Webex

  • Webex Room Kit

  • Webex Room Kit Mini

Následující zařízení se nemohou připojit ke koncovým šifrovaným schůzkám:

  • Řada Webex C

  • Řada Webex DX

  • Řada Webex EX

  • Řada Webex MX

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

Softwaroví klienti

  • Od verze 41.6 se desktopový klient Webex Meetings může připojovat k end-to-end š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 Meetings, můžete tuto možnost použít k připojení k úplným šifrovaným schůzkám.

  • Webový klient Webex se nemůže připojit k end-to-end šifrovaným schůzkám.

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

Identita

  • Neposkytujeme vám žá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 pouze k tajným kódům a klíčům. Pokud bychom zavedli cloudovou službu pro správu těchto klíčů, existuje šance, že budou zachyceny.

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

Schůzky

  • End-to-end šifrované schůzky 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édia (protože nemáme a neměli bychom mít šifrovací klíče zařízení), pak překódování selže.

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

Rozhraní pro správu

Důrazně doporučujeme použít Control Hub ke správě webu schůzek.

Hlavním důvodem je rozdíl mezi způsobem, jakým Control Hub a Site Administration spravují identitu. Organizace Centra řízení mají centralizovanou identitu pro celou organizaci, zatímco ve Správě webu je identita řízena na základě jednotlivých lokalit.

To znamená, že nemůžete mít možnost identity ověřené společností 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 koncové šifrované schůzce a mohou být vyloučeni ze schůzek, kde chce hostitel zajistit identitu.

Další zdroje informací

Související informace

Odvození ukázkových objektů blob JWE

Ukázka správně šifrovaného JWE na základě zadaných parametrů (příloha)

Požadavky

  • Schůzky Webex 41.7.

  • Zařízení řady Webex Room a Webex Desk registrovaná v cloudu, se spuštěným 10.6.1-RoomOS_August_2021.

  • Přístup pro správu 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).

  • Zasedací místnosti pro spolupráci musí být zapnuté, aby se lidé mohli připojit ze svého videosystému. Další informace naleznete v tématu Povolení videosystémům připojovat se ke schůzkám a událostem Webex na vašem webu Webex.

Získat certifikáty zařízení

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

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

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

  • Certifikát musí být vydán a podepsán známou veřejnou certifikační autoritou.

  • 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 (CN) a alternativní název/názvy subjektů (SAN/s): Pro Webex to nejsou důležité, ale měly by to být hodnoty, které mohou lidé číst a přidružit k zařízení. CN se zobrazí ostatním účastníkům schůzky 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í síť SAN/s. Možná budete chtít použít názvy jako name.model@example.com ale je to vaše volba.

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

  • Účel: Účelem certifikátu musí být identita Webex.

  • Generování klíčů: Certifikáty musí být založeny na párech klíčů ECDSA P-256 (Elliptical Curve Digital Signature Algorithm používající křivku P-256).

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

Příprava na připojení zařízení

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

Pokud používáte nová zařízení, ještě je neregistrujte do SlužbyEx. Nejbezpečnější je ještě ani nepřipojit k síti.

Pokud máte stávající zařízení, která chcete upgradovat, aby používala externě ověřenou identitu, budete muset zařízení obnovit do továrního nastavení.

  • Uložte existující konfiguraci, pokud ji chcete zachovat.

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

  • Zajistěte fyzický přístup k zařízením. Pokud musíte přistupovat k zařízením přes síť, uvědomte si, že tajné klíče se šíří prostým textem a ohrožujete svou bezpečnost.

Po dokončení těchto kroků povolte videosystémům připojit se ke schůzkám a událostem na vašem webu Webex.

Vysvětlení procesu externí identity pro zařízení

Chcete-li zajistit, aby média vašeho zařízení nemohl šifrovat nikdo jiný než zařízení, musíte zašifrovat soukromý klíč v zařízení. Navrhli jsme rozhraní API pro zařízení, která umožňují správu šifrovaného klíče a certifikátu pomocí šifrování 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 mohli zasít šifrovací schopnost 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 podle vašeho výběru. 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í Python3 a knihovny JWCrypto je k dispozici od společnosti Cisco na vyžádání.

  • Zřetěď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 Webex, a aktivujte certifikát.

  • (Doporučeno) Poskytněte rozhraní (nebo distribuujte) svůj nástroj, abyste uživatelům zařízení umožnili změnit počáteční tajný klíč (chránit tak svá média před vámi!).

Jak používáme formát JWE

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

Budete se muset podívat na JSON Web Encryption (JWE)https://datatracker.ietf.org/doc/html/rfc7516 a JSON 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:

  • Záhlaví JOSE (chráněné). V hlavičce podepisování a šifrování objektů JSON 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í tajný klíč klienta 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 mít. Tento klíč jsme zavedli pro signalizaci účelu šifrovaných dat cílovému zařízení. Hodnoty jsou pojmenovány po příkazech xAPI na zařízení, kde používáte šifrovaná data.

      Pojmenovali jsme to cisco-action zmírnit potenciální střety s budoucími rozšířeními JWE.

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

      Další proprietární klíč. Hodnoty, které zadáte, používáme jako vstupy pro odvození klíče na zařízení. Ten version musí být 1(verze naší klíčové derivační funkce). Hodnota salt musí se jednat o sekvenci kódování BASE64 URL o velikosti nejméně 4 bajtů, kterou musíte vybrat náhodně.

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

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

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

  • JWE šifrovaný text: Toto je šifrovaná datová část, kterou chcete udržet v tajnosti.

    Datová část MŮŽE být prázdná (například pro resetování tajného klíče klienta je třeba jej přepsat prázdnou hodnotou).

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

    • S "cisco-action":"populate" Šifrovaný text je nový ClientSecret

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

    • S " "cisco-action":"activate" šifrovaný text je otisk prstu (hexadecimální reprezentace sha-1) certifikátu, který aktivujeme pro ověření identity zařízení

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

  • Autentizační značka 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ím naplnění tajemství tajemství nepřijmeme ani nevydáváme tajemství jako prostý text. To má zabránit potenciálním slovníkovým útokům někoho, kdo by mohl získat přístup k zařízení.

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

To pro vás znamená, že váš nástroj pro vytváření objektů blob JWE musí postupovat stejným postupem, 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 totéž salt při zadává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í limit paměti je 64 MB

Tato sada parametrů je jedinou konfigurací scryptu, která je kompatibilní s funkcí odvození klíče 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.

Zpracovaný příklad

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

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

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

  2. Vyberte sůl (musí to být náhodná sekvence alespoň 4 bajty). Tento příklad používá (hexadecimální bajty) E5 E6 53 08 03 F8 33 F6. Base64url kódovat sekvenci získat 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) následujícím způsobem: 95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac který base64url kóduje do lZ66bdEiAQV4_mqdInj_rA.

  4. Vyberte náhodnou sekvenci 12 bajtů, kterou chcete použít jako inicializační vektor. Tento příklad používá (hexadecimální) 34 b3 5d dd 5f 53 7b af 2d 92 95 83 který base64url kóduje do NLNd3V9Te68tkpWD.

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

    {"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 neposkytujeme šifrovací klíč JWE.

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

  8. Pomocí šifrovacího nástroje JWE vytvořte šifrovanou datovou část a značku. V tomto příkladu bude nešifrovaná datová část falešným objektem blob 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

    • Hlavička JOSE kódovaná base64url 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 zakó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ězněte pět prvků blobu JWE s tečkami (JOSEheader.. IV.Ciphertext.Tag) získáte:

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

  11. Pokud jste odvodili stejné hodnoty kódované base64url, jaké zde uvádíme, 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 nebude ve skutečnosti fungovat, ale v zásadě by dalším krokem bylo použití objektu blob JWE, který jste vytvořili výše, jako vstup do příkazu xcommand na zařízení, které přidá certifikát:

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

Existují nové typy relací pro schůzky s nulovou důvěrou, které budou k dispozici pro všechny weby 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í naleznete v části ID typů relací v části Odkaz v tomto článku.

Není třeba nic dělat, abyste získali nové funkce pro váš web, ale budete muset uživatelům udělit nový typ relace (nazývaný také oprávnění ke schůzce). Můžete to provést jednotlivě prostřednictvím konfigurační stránky uživatele nebo hromadně pomocí exportu/importu CSV.

Ověření nového typu relace

1

Přihlaste se k Centru řízení a otevřete stránku Schůzka.
2

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

Klikněte na Konfigurovat lokalitu.
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ů relací šifrování typu end-to-end. Seznam ID typu relace naleznete v části Odkazy 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: Pro-End to End šifrování. Tento typ relace zahrnuje nešifrovaný přístup ke schůzce ve veřejné telefonní síti. Ujistěte se, že máte _verzi VOIPonly, abyste zajistili šifrování od začátku do konce. Můžete to zkontrolovat tak, že najedete myší na odkaz PRO ve sloupci kódu relace; v tomto příkladu by cíl odkazu měl být javascript:ShowFeature(652).

V budoucnu můžeme změnit názvy veřejných služeb pro tyto typy relací, například plánujeme změnit Pro-End na End Encryption_VOIPonly na E2E Encryption + Identity.
5

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

Co dělat dál

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

Povolení schůzek E2EE pro jednotlivé uživatele

1

Klikněte na Uživatelé a výběrem uživatele otevřete konfigurační panel uživatele.
2

V oblasti Služby klikněte na položku Schůzky Cisco 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 Webex Meetings označené Pro-End to End Encryption_VOIPonly.
5

Zavřete panel konfigurace 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 hromadnou možnost CSV.

Povolení schůzek E2EE pro více uživatelů

1

Přihlaste se k Centru řízení na https://admin.webex.com a otevřete stránku Schůzka.
2

Kliknutím na název webu otevřete panel konfigurace lokality.
3

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

Klikněte na Exportovata počkejte, než soubor připravíme.
5

Až bude soubor připravený, klikněte na Exportovat výsledky a pak na Stáhnout. (Musíte ručně zavřít toto vyskakovací okno po kliknutí na tlačítko Stáhnout.)
6

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

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

7

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

Referenční dokumentace formátu souboru CSV Cisco Webex obsahuje podrobnosti o účelu a obsahu souboru CSV.
8

Otevřete konfigurační panel webu schůzek v Centru řízení.


 

Pokud jste již byli na stránce se seznamem webu schůzky, možná ji budete muset aktualizovat.
9

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

Klikněte na Importovat, vyberte upravený soubor CSV a potom klikněte na Importovat. Počkejte, než se soubor nahraje.
11

Po dokončení importu můžete klepnutím na tlačítko Importovat výsledky zkontrolovat, zda nedoš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.

Integrovaná zařízení (interní certifikační autorita)

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

Tento postup vybere, kterou doménu zařízení používá k identifikaci sebe sama, a je 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 provést pro všechna zařízení, která budou mít identitu ověřenou společností Cisco. Pokud společnosti Webex neřeknete, která doména identifikuje zařízení, vybereme jednu a pro ostatní účastníky schůzky to může vypadat špatně.

Než začnete

Pokud vaše zařízení ještě nejsou připojena, můžete sledovat registrace zařízení do Cisco Webex pomocí rozhraní API nebo místního webového rozhraní nebo CloudOnboarding for Devices. Měli byste také ověřit doménu, kterou chcete použít k identifikaci zařízení v části Správa zařízení.

1

Přihlaste se do Centra řízení (https://admin.webex.com) a otevřete stránku Zařízení.
2

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

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

Opakujte pro ostatní zařízení.

Integrovaná zařízení (externí certifikační autorita)

Než začnete

Potřebuješ:

  • Pokud chcete získat certifikát podepsaný certifikační autoritou a soukromý klíč ve formátu .pem pro každé zařízení.

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

  • Připravit šifrovací nástroj JWE s ohledem na informace tam.

  • Nástroj pro generování náhodných bajtových sekvencí daných délek.

  • Nástroj pro kódování bajtů nebo textu base64url.

  • Jakýsi scrypt implementace.

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

1

Naplnění zařízení ClientSecret s prostým textovým tajemstvím:

Při prvním naplnění Secret, zadáte jej ve formátu prostého textu. Proto doporučujeme, abyste to udělali na konzole 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 příkazu naplní Secret s frází 0123456789abcdef. Musíte si vybrat vlastní.

Zařízení má své počáteční tajemství. Nezapomeňte na to, nemůžete jej obnovit a musíte obnovit tovární nastavení zařízení, aby se znovu spustilo.
2

Zřetězení certifikátu a soukromého klíče:

  1. Pomocí textového editoru otevřete soubory .pem, vložte objekt blob klíče do objektu 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 alespoň 4 bajtů. To je vaše sůl.

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

    K tomu potřebujete tajemství, sůl a délku klíče, aby odpovídaly zvolené šifrovací šifře. K dispozici jsou některé další pevné hodnoty, které je třeba dodat (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ů. Toto je váš inicializační vektor.

  4. Vytvoření záhlaví JOSE, nastavení alg, enc a cisco-kdf, jak je popsáno v tématu Principy procesu externí identity pro zařízení. Nastavte akci "add" pomocí key:value "cisco-action":"add" v hlavičce JOSE (protože certifikát přidáváme 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. Objekt blob JWE sestavte následujícím způsobem (všechny hodnoty jsou kódované base64url):

    JOSEHeader..InitVector.EncryptedPEM.AuthTag
4

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

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

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

Zkopírujte otisk nového certifikátu.
6

Aktivace certifikátu pro daný účel WebexIdentity:

  1. Načtěte otisk 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 o velikosti alespoň 4 bajtů a base64url tuto sekvenci zakódujte. To je vaše sůl.

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

    K tomu potřebujete tajemství, sůl a délku klíče, aby odpovídaly zvolené šifrovací šifře. K dispozici jsou některé další pevné hodnoty, které je třeba dodat (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. Toto je váš inicializační vektor.

  5. Vytvoření záhlaví JOSE, nastavení alg, enc a cisco-kdf, jak je popsáno v tématu Principy procesu externí identity pro zařízení. Nastavte akci "aktivovat" pomocí key:value "cisco-action":"activate" v hlavičce JOSE (protože aktivujeme certifikát v zařízení).

  6. Base64url kóduje hlavičku JOSE.

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

    Nástroj by měl vytvořit 16 nebo 32bajtovou sekvenci v závislosti na tom, zda jste zvolili 128 nebo 256 bit AES-GCM a ověřovací značku.

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

  9. Objekt blob JWE sestavte následujícím způsobem (všechny hodnoty jsou kódované base64url):

    JOSEHeader..InitVector.EncryptedFingerprint.AuthTag

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

    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 v end-to-end šifrovaných schůzkách Webex.
7

Připojte zařízení k organizaci Centra řízení.

Testování šifrování E2EE a ověřené identity

1

Naplánujte schůzku správného typu (Webex Meetings Pro-End to End Encryption_VOIPonly).

Viz Naplánování schůzky Webex s end-to-endšifrováním .
2

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

Viz Připojení ke schůzce Webex pomocí šifrování end-to-end.
3

Připojte se ke schůzce ze zařízení, jehož identita je ověřena certifikační autoritou Webex.
4

Jako hostitel ověřte, zda se toto zařízení zobrazuje v předsálí se správnou ikonou identity.

Viz Připojení ke schůzce Webex pomocí šifrování end-to-end.
5

Připojte se ke schůzce ze zařízení, jehož identita je ověřena externí certifikační autoritou.
6

Jako hostitel ověřte, zda se toto zařízení zobrazuje v předsálí se správnou ikonou identity. Přečtěte si další informace o ikonách identit.
7

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

Jako hostitel ověřte, zda se tento účastník zobrazuje v lobby se správnou ikonou identity.
9

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

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

Zkontrolujte, zda všichni účastníci schůzky vidí 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.

Nastavit rozsah a očekávání

Chystáte se nastavit end-to-end šifrované schůzky jako výchozí možnost schůzky, nebo ji povolit pouze pro některé uživatele, nebo nechat všechny hostitele rozhodnout? Když jste se rozhodli, jak budete tuto funkci používat, připravte ty uživatele, kteří ji budou používat, zejména s ohledem na omezení a co očekávat na schůzce.

Potřebujete zajistit, aby společnost Cisco ani nikdo jiný nemohl dešifrovat váš obsah ani se vydávat za vaše zařízení? Pokud ano, potřebujete certifikáty od veřejné certifikační autority. V zabezpečené schůzce můžete mít maximálně 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í pomocí zabezpečených zařízení, nechte zařízení připojit se jako první a nastavte očekávání uživatelů, že se nemusí 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 podložené certifikátem a bezpečnostního kódu schůzky. I když existují okolnosti, kdy se účastníci mohou objevit jako neověření a účastníci by měli vědět, jak zkontrolovat, neověření lidé nemusí být podvodníci.

Správa identit

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

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

Nejčastější dotazy ke schůzkám s nulovou důvěrou

Již brzy.

ID typu relace

Tabulka 1. ID typu relace pro end-to-end šifrované schůzky

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 Free50-End to End Encryption_VOIPonly

673

Instruktor vzdělávání E2E Encryption_VOIPonly

676

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

677

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

681

Schoology Free plus end-to-end šifrování

Související příkazy xAPI

Tyto tabulky popisují příkazy rozhraní API zařízení Webex, které jsme přidali pro end-to-end šifrované schůzky a ověřenou identitu. Další informace o tom, jak používat rozhraní API, naleznete v tématu Přístup k rozhraní API pro zařízení Webex Room and Desk a WebexBoards .

Tyto příkazy xAPI jsou k dispozici pouze na zařízeních, která jsou buď:

  • Registrováno ve Webexu

  • Registrovaný místně a propojený s Webexem pomocí Webex Edge pro zařízení

Tabulka 2. Rozhraní API na úrovni systému pro end-to-end šifrované schůzky a ověřenou identitu

Volání rozhraní API

Popis

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

Tato konfigurace se provede, když správce nastaví upřednostňovanou doménu zařízení z Centra řízení. 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 certifikační autority Webex. Doména pak identifikuje zařízení.

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

xStatus Conference EndToEndEncryption Availability

Označuje, jestli se zařízení může připojit k end-to-end šifrované schůzce. Cloudové rozhraní API ho volá, aby spárovaná aplikace věděla, jestli se může pomocí zařízení připojit.

xStatus Conference EndToEndEncryption ExternalIdentity Verification

Označuje, zda zařízení používá External ověření (má externě vydaný certifikát).

xStatus Conference EndToEndEncryption ExternalIdentity Identity

Identita zařízení přečtená z běžného názvu externě vystaveného certifikátu.

xStatus Conference EndToEndEncryption ExternalIdentity CertificateChain Certificate # specificinfo

Přečte konkrétní informace z externě vydaného certifikátu.

V zobrazeném příkazu nahraďte # s číslem certifikátu. Nahradit specificinfo s jedním z:

  • Fingerprint

  • NotAfter Datum ukončení platnosti

  • NotBefore Datum zahájení platnosti

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

  • Subject # Name Seznam subjektů certifikátu (např. e-mailová adresa nebo název domény)

  • Validity Udává stav platnosti tohoto certifikátu (např. valid nebo expired)

xStatus Conference EndToEndEncryption ExternalIdentity Status

Stav externí identity zařízení (např. valid nebo error).

xStatus Conference EndToEndEncryption InternalIdentity Verification

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

xStatus Conference EndToEndEncryption InternalIdentity Identity

Identita zařízení přečtená 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 je zařízení v organizaci, která má více domén, jedná se o hodnotu z PreferredDomain.

xStatus Conference EndToEndEncryption InternalIdentity CertificateChain Certificate # specificinfo

Přečte konkrétní informace z certifikátu vydaného Webexem.

V zobrazeném příkazu nahraďte # s číslem certifikátu. Nahradit specificinfo s jedním z:

  • Fingerprint

  • NotAfter Datum ukončení platnosti

  • NotBefore Datum zahájení platnosti

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

  • Subject # Name Seznam subjektů certifikátu (např. e-mailová adresa nebo název domény)

  • Validity Udává stav platnosti tohoto certifikátu (např. valid nebo expired)

Tabulka 3. Rozhraní API pro volání pro end-to-end šifrované schůzky a ověřenou identitu

Volání rozhraní API

Popis

xEvent Conference ParticipantList ParticipantAdded

xEvent Conference ParticipantList ParticipantUpdated

xEvent Conference ParticipantList ParticipantDeleted

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

Tabulka 4. Rozhraní API související s ClientSecret pro end-to-end šifrované schůzky a ověřenou identitu

Volání rozhraní API

Popis

xCommand Security ClientSecret Populate Secret: "base64url-encoded"

nebo

xCommand Security ClientSecret Populate Secret: JWEblob

Přijímá hodnotu prostého textu s kódováním base64url pro první nasazení tajného klíče klienta na zařízení.

Pokud chcete tajný klíč aktualizovat po tomto prvním použití, musíte zadat 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 účelem Purpose, příkaz vyžaduje, aby byl identifikační otisk prstu zašifrován a serializován v objektu blob JWE.

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

Deaktivuje konkrétní certifikát pro WebexIdentity. Za tímto účelem Purpose, příkaz vyžaduje, aby byl identifikační otisk prstu zašifrován a serializován v objektu blob JWE.