Uživatelské prostředí

Uživatelé si při plánování schůzky zvolí typ schůzky. Při přijímání účastníků z předsálí a během schůzky může hostitel zobrazit stav ověření identity 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, který mohou použít k ověření, že jejich schůzka nebyla zachycena nechtěným útokem třetí strany Meddler In The Middle (MITM).

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

Ověření identity s interní nebo externí certifikační autoritou

Ověřit identitu

Šifrování mezi koncovými zařízeními s ověřením identity poskytuje dodatečné zabezpečení schůzky s koncovým šifrováním.

Když se účastníci nebo zařízení připojí ke sdílené skupině MLS (Messaging Layer Security), předají své certifikáty ostatním členům skupiny, kteří pak certifikáty ověří proti vydávajícím certifikačním autoritám (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 se ověří v úložišti identit Webex, což jim při úspěšném ověření vydá přístupový token. Pokud potřebují certifikát k ověření své identity na schůzce s koncovým šifrováním, certifikační autorita Webex jim vydá certifikát na základě přístupového tokenu. V tuto chvíli neposkytujeme uživatelům aplikace 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:

  • Interní certifikační autorita – Webex vydává interní certifikát na základě přístupového tokenu účtu počítače zařízení. Certifikát je podepsán certifikační autoritou Webex. Zařízení nemají uživatelská IDS 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í (obecný název (CN)).

  • Externí certifikační autorita – vyžádejte si a zakupte certifikáty zařízení přímo od vybraného vydavatele. 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ž umožňuje zaručit skutečné šifrování mezi koncovými body a ověřenou identitu a zabránit teoretické možnosti, že by společnost Cisco mohla odposlouchávat vaši schůzku nebo dešifrovat 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 API xConfiguration Conference Endtoendencryption Identity Domain: "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. V uživatelském rozhraní schůzky Webex se zobrazí obecný název (CN) a alternativní název předmětu (SAN), jak je popsáno v části Koncové šifrování s ověřením identity pro aplikaci Webex Meetings.

Doporučujeme použít samostatný certifikát pro každé zařízení a mít jedinečné CN pro každé zařízení. 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 rozhraní xAPI. To je v současné době omezeno na online zařízení.

Služba Webex aktuálně poskytuje příkazy rozhraní API pro tuto správu.

Funkce a omezení

Zařízení

Ke schůzkám E2EE se mohou připojit následující cloudová zařízení řady Webex Room a Webex Desk:

  • Webex Board

  • Webex Desk Pro

  • Webex Desk

  • Webex Room Kit

  • Webex Room Kit Mini

Ke schůzkám E2EE se nemohou připojit následující zařízení:

  • Řada Webex C

  • Řada Webex DX

  • Řada Webex EX

  • Řada Webex MX

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

Softwaroví klienti

  • Aplikace Webex pro stolní počítače a mobilní klienty se mohou připojit ke schůzkám E2EE.

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

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

Identita

  • Z podstaty věci neposkytujeme možnosti prostředí Control Hub pro správu externě ověřené identity zařízení. Pro skutečné šifrování mezi koncovými body byste měli znát/mít přístup k tajnostem a klíčům. Pokud bychom zavedli cloudovou službu pro správu těchto klíčů, existuje šance, že budou zachyceny.

  • V současné době pro vás poskytujeme „recept“ na návrh vlastních nástrojů založených na standardních šifrovacích technikách, které vám pomohou při vyžádání nebo šifrování certifikátů identity zařízení a jejich soukromých klíčů. Nechceme mít žádný skutečný nebo vnímaný přístup k vašim tajemstvím nebo klíčům.

Schůzky

  • Schůzky E2EE v současné době podporují maximálně 1000 účastníků.

  • Nové tabule můžete sdílet na schůzkách E2EE. Při pravidelných schůzkách existují určité rozdíly oproti tabulím:
    • Na schůzkách E2EE nemají uživatelé přístup k tabulím vytvořeným mimo schůzku, včetně soukromých tabulí, tabulí sdílených ostatními a tabulí z prostorů Webex.
    • Tabule vytvořené při schůzkách E2EE jsou k dispozici pouze během schůzky. Po skončení schůzky nejsou uloženy a nejsou přístupné.
    • Pokud někdo sdílí obsah na schůzce E2EE, můžete k němu přidávat poznámky. Další informace o poznámkách naleznete v aplikaci Webex | Označení sdíleného obsahu pomocí poznámek.

Rozhraní pro správu

Důrazně doporučujeme, abyste ke správě webu schůzek používali prostředí Control Hub, protože organizace prostředí Control Hub mají centralizovanou identitu pro celou organizaci.

Další zdroje
Požadavky

  • Schůzky Webex 41.7.

  • Zařízení řady Webex Room a Webex Desk registrovaná v cloudu, s verzí 10.6.1- OS_August_2021.

  • Přístup správce k webu schůzky v prostředí Control Hub.

  • 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 najdete v tématu Povolení videosystémů připojovat se ke schůzkám a událostem na webu služby Webex.

Získat certifikáty zařízení

Tento krok můžete přeskočit, pokud nepotřebujete externě ověřené identity.

Pro nejvyšší úroveň zabezpečení a pro 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 (CA).

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 použijte 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žívat jména jako name.model@example.com.

  • 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 palubní zařízení

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

Pokud používáte nová zařízení, ještě je neregistrujte do SlužbyEx. Abyste byli v bezpečí, v tuto chvíli je nepřipojujte k síti.

Pokud máte stávající zařízení, která chcete upgradovat na použití externě ověřené identity, musíte zařízení obnovit do továrního nastavení.

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

  • 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řipojovat se ke schůzkám a událostem na vašem webu Webex.

Porozumět 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í. Pro zařízení jsme navrhli systémy API, které umožňují 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í, musíte:

  1. Vyžádejte si certifikáty.

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

  3. Vytvořte (a chraňte) počáteční tajný klíč pro každé zařízení, abyste mohli zasít šifrovací schopnost zařízení.

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

    Proces a (netajné) parametry, které budete potřebovat, jsou vysvětleny níže, stejně jako recept na dodržování ve vašich vývojových nástrojích 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í.

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

  6. Nahrajte výsledný objekt blob JWE do zařízení.

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

  8. (Doporučeno) Poskytněte svému nástroji rozhraní (nebo jej distribuujte), aby uživatelé zařízení mohli změnit počáteční tajemství a chránit před vámi svá média.

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íčů.

Viz JSON Web Encryption (JWE) https://datatracker.ietf.org/doc/html/rfc7516 a JSON Web Signature (JWS) https://datatracker.ietf.org/doc/html/rfc7515.

K vytvoření bloků JWE používáme Compact Serialization dokumentu JSON. Parametry, které musíte při vytváření bloků JWE zahrnout, jsou:

  • Hlavička JOSE (chráněná). V hlavičce podepisování a šifrování objektů JSON MUSÍTE zahrnout následující páry klíč-hodnota:

    • "alb":"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":"A GCM" nebo "enc":"A256GCM"

      Podporujeme tyto dva šifrovací algoritmy.

    • "cisco-action": "přidat" nebo "cisco-action": "vyplnit" nebo "cisco-action": "aktivovat" nebo "cisco-action": "deaktivovat"

      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 ji cisco-action pro zmírnění potenciálních střetů s budoucími rozšířeními JWE.

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

      Další proprietární klíč. Hodnoty, které zadáte, používáme jako vstupy pro odvození klíče na zařízení. Verze musí být 1 (verze naší klíčové derivační funkce). Hodnota soli musí být URL kódovaná sekvence alespoň 4 bajtů, kterou musíte zvolit náhodně.

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

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

  • Kódování JWE: Toto je šifrovaná datová část, kterou chcete udržet v tajnosti.

    Datová část MŮŽE být prázdná. Chcete-li například obnovit tajemství klienta, musíte 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é užitečné zatížení a pomocí klíče cisco-action musíte zadat účel užitečné zátěže:

    • S "cisco-action":"vyplnit" je šifrovací text novým Secret.

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

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

    • S ""cisco-action":"deactivate" je šifrovací text otisk prstu (hexadecimální reprezentace sha-1) certifikátu, který deaktivujeme, aby byl 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íč od Secret

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á posloupnost nejméně 4 bajtů; stejnou sůl musíte dodávat při zadání parametru cisco-kdf .

  • 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 aktuálně používaná parametrem cisco-kdf .

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). Tajemství klienta v příkladu je ossifrage.

  1. Zvolte šifrovací šifru. Tento příklad používá A GCM (AES se 128 bitovými klíči v režimu počítadla osnova). Váš nástroj by mohl použít A256GCM , pokud chcete.

  2. Vyberte sůl (musí to být náhodná sekvence alespoň 4 bajty). Tento příklad používá (šestihranné bajty)E5 E6 53 08 03 F8 33 F6. Base64url enkódujte sekvenci, abyste získali 5eZTCAP4M_Y (odstraňte výplň base64).

  3. Zde je ukázkový scrypt volání k 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 , na základě64URL kóduje lz66 EiAQV4_mqdInj_rA.

  4. Vyberte náhodnou sekvenci 12 bajtů, kterou chcete použít jako inicializační vektor. Tento příklad používá (hex) 34 b3 5d dd 5f 53 7b af 2d 92 95 83 , který ze základu64url kóduje 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":"A GCM"}

    Základní64URL kódovaná hlavička JOSE je J GcioiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2F CI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6Ij SwiZW5jIjoiQTEyOEdDTSJ9

    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 blobu JWE je inicializační vektor NLNd3V9Te68tkpWD.

  8. Pomocí šifrovacího nástroje JWE vytvořte šifrovanou datovou část a značku. Pro tento příklad, nešifrovaná datová část bude falešný PEM blob toto je PEM soubor

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

    • Datová část je toto je soubor PEM

    • Šifrovací šifra je AES 128 GCM

    • Hlavička JOSE kódovaná base64url jako další ověřená data (AAD)

    Base64URL kóduje šifrovanou datovou část, která by měla mít za následek f5l uWNfKfmzYCo1YJfODhQ

    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ězněte pět prvků blobu JWE s tečkami (JOSEheader.. IV.Ciphertext.Tag) získáte:

    J GcioijkaxijjaXNjby1hY3Rpb24iOijhZGQILCJjaXNjby1rZGYiionsic2F CI6IjVlwlRDQVA0TV9ZIiwidmVyc2lvbiI6Ij SwiZW5jIjoiqteyoedDTSJ..9NLNd3V9Te68tkpWD.f5l uwnfKfmzYCo1YJfODhQ.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:

    Certifikáty zabezpečení příkazů Přidat J GcioiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiiOnsic2F CI6IjVlwlRDQVA0TV9ZIiwidmVyc2lvbiI6Ij SwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5l UWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

Typy relací pro schůzky s nulovou důvěrou jsou k dispozici pro všechny weby schůzek bez dodatečných nákladů. Jeden z těchto typů relací se nazývá pouze Pro-End to End Encryption_VOIP. 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.

K získání této funkce pro svůj web nemusíte nic dělat. Musíte uživatelům nový typ relace (nazývaný také Meeting Privilege) udělit. Můžete to provést jednotlivě prostřednictvím konfigurační stránky uživatele nebo hromadně pomocí exportu/importu CSV.

Ověřit nový typ relace
1

Přihlaste se do prostředí Control Hub a přejděte do části Služby > Schůzka.

2

Klikněte na možnost Weby, vyberte web Webex, pro který chcete změnit nastavení, a poté klikněte na možnost Nastavení.

3

V části Obecná nastavenívyberte možnost Typy relací.

4
Měli byste vidět jeden nebo více typů relací šifrování mezi koncovými zařízeními. 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: Šifrování Pro-End to End. Tento typ relace zahrnuje nešifrovaný přístup ke schůzce ve veřejné telefonní síti. Ujistěte se, že máte verzi _pouze VOIP pro zajištění šifrování mezi koncovými body. Kontrolu můžete provést umístěním ukazatele na odkaz PRO ve sloupci kódu relace. V tomto případě 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.

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.

Povolit schůzky E2EE pro jednotlivé uživatele
1

Přihlaste se do prostředí Control Hub a přejděte do nabídky Správa > Uživatelé.

2

Vyberte uživatelský účet, který chcete aktualizovat, a poté vyberte možnost Schůzky.

3

V rozevíracím seznamu Nastavení použít vyberte web schůzky, který chcete aktualizovat.

4

Zaškrtněte políčko u položky Pouze pro-End to End Encryption_VOIP.

5

Zavřete panel konfigurace uživatele.

6

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

Chcete-li tuto možnost přiřadit mnoha uživatelům, použijte další možnost – Povolit schůzky E2EE pro více uživatelů.

Povolit schůzky E2EE pro více uživatelů
1

Přihlaste se do prostředí Control Hub a přejděte do části Služby > Schůzka.

2

Klikněte na možnost Weby a vyberte web služby Webex, pro který chcete změnit nastavení.

3

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

4

Klikněte na možnost Generovat zprávu a počkejte, než soubor připravíme.

5

Až bude soubor připravený, klikněte na Exportovat výsledky a pak na Stáhnout. (Toto vyskakovací okno musíte zavřít ručně poté, co kliknete na možnost Stáhnout.)

6

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

Pro každého uživatele je k dispozici řádek a sloupec Privilege obsahuje index IDS 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 novou hodnotu do seznamu odděleného čárkami v buňce Privilege .

Odkaz na formát souboru CSV služby 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.

Přidání zvukového vodoznaku pro vyšší zabezpečení

K záznamům schůzek můžete přidat vodoznak pomocí typu relace Webex Meetings Pro-End to End Encryption_VOIPpouze , což vám umožní identifikovat zdrojového klienta nebo zařízení neoprávněných záznamů důvěrných schůzek.

Když je tato funkce povolena, zvuk schůzky obsahuje jedinečný identifikátor každého zúčastněného klienta nebo zařízení. Zvukové záznamy můžete nahrát do prostředí Control Hub, které poté záznam analyzuje a vyhledá jedinečné identifikátory. Můžete se podívat na výsledky a zjistit, který zdrojový klient nebo zařízení schůzku zaznamenal.

  • Aby mohl být záznam analyzován, musí být soubor AAC, MP3, M4A, WAV, MP4, AVI nebo MOV maximálně 500 MB.
  • Záznam musí být delší než 100 sekund.
  • Můžete analyzovat záznamy pouze pro schůzky hostované lidmi ve vaší organizaci.
  • Informace o vodoznaku jsou uchovávány po stejnou dobu jako informace o schůzce organizace.

Přidání zvukových vodoznaků do schůzek E2EE

  1. Přihlaste se do prostředí Control Hub a v části Management vyberte možnost Nastavení organizace.
  2. V části Vodoznaky schůzky zapněte možnost Přidat zvukový vodoznak.

    Po určitou dobu po zapnutí funkce uvidí uživatelé, kteří plánují schůzky pomocí typu relace Webex Meetings Pro-End to End Encryption_VOIPpouze , možnost Digitální vodoznak v části Zabezpečení.

Nahrát a analyzovat schůzku s vodoznakem

  1. V centru Control Hub v části Monitoring vyberte možnost Řešení potíží.
  2. Klikněte na možnost Analýza vodoznaku.
  3. V seznamu vyhledejte nebo vyberte schůzku a klikněte na tlačítko Analyzovat.
  4. V okně Analyzovat zvukový vodoznak zadejte název analýzy.
  5. (Volitelně) Zadejte poznámku k analýze.
  6. Přetáhněte zvukový soubor, který má být analyzován, nebo klikněte na možnost Vybrat soubor a vyhledejte zvukový soubor.
  7. Klikněte na tlačítko Zavřít.

    Po dokončení analýzy se zobrazí v seznamu výsledků na stránce Analyzovat vodoznak .

  8. Výběrem schůzky v seznamu zobrazíte výsledky analýzy. Kliknutím na tlačítko Tlačítko Stáhnout stáhnete výsledky.

Funkce a omezení

Faktory podílející se na úspěšném dekódování nahraného vodoznaku zahrnují vzdálenost mezi záznamovým zařízením a reproduktorem, hlasitost zvuku, hluk ve venkovním prostředí atd. Naše vodoznaková technologie má dodatečnou odolnost vůči několikanásobnému zakódování, jak se může stát, když je sdílená média.

Tato funkce je navržena tak, aby umožnila úspěšné dekódování identifikátoru vodoznaku v širokém, ale rozumném souboru okolností. Naším cílem je, aby záznamové zařízení, jako je mobilní telefon, který leží na stole v blízkosti osobního koncového bodu nebo notebooku, vždy vytvořilo záznam, který vyústí v úspěšnou analýzu. Když je nahrávací zařízení přesunuto od zdroje nebo je zakryto slyšením plného zvukového spektra, šance na úspěšnou analýzu jsou sníženy.

Aby bylo možné úspěšně analyzovat záznam, je nutné přiměřené zachycení zvuku schůzky. Pokud je zvuk schůzky zaznamenán ve stejném počítači, ve kterém je hostování klienta, neměla by platit omezení.

Palubní zařízení (interní certifikační autorita)

Pokud jsou vaše zařízení již zaregistrována ve vaší organizaci Control Hub a chcete použít certifikační autoritu Webex k automatickému generování identifikačních certifikátů, nemusíte zařízení resetovat do továrního nastavení.

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 aplikaci Webex neřeknete, která doména zařízení identifikuje, jedna je automaticky vybrána a ostatním účastníkům schůzky se může zdát, že je to špatně.

Než začnete

Pokud vaše zařízení ještě nejsou zaregistrována, postupujte podle části Registrace zařízení do služby Cisco Webex pomocí rozhraní API nebo místního webového rozhraní nebo registrace v cloudu pro zařízení řady Board, Desk a Room. V části Správa domén byste také měli ověřit domény, které chcete používat k identifikaci zařízení.

1

Přihlaste se do prostředí Control Hub a v části Management vyberte možnost 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í.

Palubní zařízení (externí certifikační autorita)

Než začnete

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

  • Na kartě Prepare si přečtěte téma Understanding External Identity Process for Devices (Pochopení procesu externí identity pro zařízení),

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

  • Ujistěte se, že máte nástroj pro generování náhodných bajtů zadaných délek.

  • Ujistěte se, že máte nástroj na bázi64URL kódování bajtů nebo textu.

  • Ujistěte se, že máte implementaci scrypt.

  • Ujistěte se, že pro každé zařízení máte tajné slovo nebo frázi.

1

Vyplňte položku Secret zařízení tajným textem:

Když poprvé vyplníte tajemství, poskytnete je prostým textem. To je důvod, proč to doporučujeme provést 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 Secret Populate Secret: "MDEYMZQ1Njc4OWFiY2RlZg"

    Výše uvedený příklad příkazu vyplní tajemství 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 zařízení je nutné obnovit do továrního nastavení, aby se znovu spustil.
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é zátěže, který zašifrujete a vložíte do JWE blob.

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řte hlavičku JOSE a nastavte klíče alg, enc a cisco-kdf podle popisu v dokumentu Understanding External Identity Process for Devices. Akci „přidat“ nastavte pomocí klíče:value "cisco-action":"add" v hlavičce JOSE (protože do zařízení přidáváme certifikát).

  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 Přidat Isšifrované: Opravte si svůj..JWE.str.ing\n .\n
5

Ověřte přidání certifikátu spuštěním služby xcommand Security Certificates Services Zobrazit

Zkopírujte otisk nového certifikátu.

6

Aktivovat certifikát pro účely Webexidentity:

  1. Přečtěte si otisk certifikátu buď ze samotného certifikátu, nebo z výstupu služby 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řte hlavičku JOSE a nastavte klíče alg, enc a cisco-kdf podle popisu v dokumentu Understanding External Identity Process for Devices. V hlavičce JOSE nastavte akci „aktivovat“ pomocí klíče:value "cisco-action":"aktivovat" (protože v zařízení aktivujeme certifikát).

  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.Šifrovanýotisk prstu.Authtag

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

     xcommand Security Certificates Services Aktivovat Účel: 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í.

Otestovat end-to-end šifrování s ověřením 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. Další informace o ikonách 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 zobrazuje v lobby se správnou ikonou identity.

9

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

10

Je-li to možné, ověřte identity účastníka/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.

  • Pokud máte různou úroveň ověřování identity, umožněte uživatelům navzájem ověřovat identitou podporovanou certifikátem. 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í.

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 EVOIPonlyncryption_

660

Pro 3 Free-End na konec EVOIPonlyncryption_

Šifrování E2E + identita

672

Pro 3 Free50-End na konec EVOIPonlyncryption_

673

Instruktor vzdělávání E2E EVOIPonlyncryption_

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 Doména: "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 ověření identity

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

xstatus Conference Endtoendencryption Identity Identity

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

xstatus Conference Endtoendencryption Identity Chain Certificate # specificinfo

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

V zobrazeném příkazu # nahraďte číslem certifikátu. Nahradit specifické informace jedním z následujících způsobů:

  • Otisk prstu

  • Not After Datum ukončení platnosti

  • Ne Počáteční datum platnosti

  • Název

  • Veřejný Keyalgoritmus

  • Číslo

  • Algoritmus

  • Předmět # Název Seznam subjektů certifikátu (např. e-mailová adresa nebo název domény)

  • Platnost Udává stav platnosti tohoto certifikátu (např. platné nebo vypršela platnost)

xstatus Conference Endtoendencryption Stav identity

Stav externí identity zařízení (např. platné nebo chyba).

xstatus Conference Endtoendencryption ověření identity

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

xstatus Conference Endtoendencryption Identity 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 domény Domain.

xstatus Conference Endtoendencryption Identity Chain Certificate # specificinfo

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

V zobrazeném příkazu # nahraďte číslem certifikátu. Nahradit specifické informace jedním z následujících způsobů:

  • Otisk prstu

  • Not After Datum ukončení platnosti

  • Ne Počáteční datum platnosti

  • Název

  • Veřejný Keyalgoritmus

  • Číslo

  • Algoritmus

  • Předmět # Název Seznam subjektů certifikátu (např. e-mailová adresa nebo název domény)

  • Platnost Udává stav platnosti tohoto certifikátu (např. platné nebo vypršela platnost)

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

Volání rozhraní API

Popis

xevent konference Seznam přidán

xevent konference seznam aktualizován

xevent konference seznam odstraněn

Tyto tři události nyní zahrnují EndToEndEncry Status, EndToEndEncry Identity, a EndToEndEncry Certinfo pro dotč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 Secret Populate Secret: "base64url-encoded"

nebo

xcommand Security Tajné vyplnění tajemství: Jweblob (rozcestník)

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.

Služby certifikátů zabezpečení příkazů Přidat 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.

Služby certifikátů zabezpečení příkazu Aktivovat účel:Otisk prstu Webexidentity: Jweblob (rozcestník)

Aktivuje konkrétní certifikát pro WebexIdentity. Pro tento Účel vyžaduje příkaz, aby byl identifikační otisk prstu zašifrován a serializován v bloku JWE.

Deaktivujte Účel: Otisk prstu Webexidentity: Jweblob (rozcestník)

Deaktivuje konkrétní certifikát pro WebexIdentity. Pro tento Účel vyžaduje příkaz, aby byl identifikační otisk prstu zašifrován a serializován v bloku JWE.