Dziękujemy za opinię.
Opinia?
Użytkownicy wybierają typ spotkania podczas planowania spotkania. Przyjmując uczestników z lobby, a także podczas spotkania, gospodarz może zobaczyć status weryfikacji tożsamości każdego uczestnika. Istnieje również kod spotkania, który jest wspólny dla wszystkich obecnych uczestników spotkania, który mogą wykorzystać do sprawdzenia, czy ich spotkanie nie zostało przechwycone przez niechciany atak MITM (Meddler In The Middle) strony trzeciej.
Podziel się następującymi informacjami z gospodarzami spotkań:
-
Dołącz do spotkania Webex z szyfrowaniem typu end-to-end
Zweryfikuj tożsamość
Szyfrowanie typu end-to-end z weryfikacją tożsamości zapewnia dodatkowe bezpieczeństwo szyfrowanego spotkania typu end-to-end.
Gdy uczestnicy lub urządzenia dołączają do udostępnionej grupy MLS (Messaging Layer Security), przedstawiają swoje certyfikaty innym członkom grupy, którzy następnie weryfikują certyfikaty w stosunku do wydających certyfikaty (CA). Potwierdzając, że certyfikaty są ważne, CA weryfikuje tożsamość uczestników, a spotkanie pokazuje uczestników/urządzenia jako zweryfikowane.
Użytkownicy aplikacji Webex uwierzytelniają się w sklepie tożsamości Webex, który wydaje im token dostępu, gdy uwierzytelnianie się powiedzie. Jeśli potrzebują certyfikatu, aby zweryfikować swoją tożsamość podczas szyfrowanego spotkania typu end-to-end, urząd certyfikacji Webex wydaje im certyfikat oparty na ich tokenie dostępu. W tej chwili nie zapewniamy Webex Meetings użytkownikom sposobu uzyskania certyfikatu wydanego przez osobę trzecią/zewnętrzną certyfikację certyfikatu.
Urządzenia mogą się uwierzytelnić za pomocą certyfikatu wydanego przez wewnętrzny urząd urzędowy (Webex) lub certyfikatu wydanego przez zewnętrzny urząd certyfikacji:
-
Webex wystawia wewnętrzny certyfikat oparty na tokenie dostępu konta komputera urządzenia. Certyfikat jest podpisany przez Webex CA. Urządzenia nie mają identyfikatorów użytkownika w taki sam sposób jak użytkownicy, dlatego Webex używa (jednej z) domen Twojej organizacji podczas zapisywania tożsamości certyfikatu urządzenia (Common Name (CN)).
-
Zewnętrzny CA — żądaj i kupuj certyfikaty urządzenia bezpośrednio od wybranego emitenta. Musisz zaszyfrować, bezpośrednio przesyłać i autoryzować certyfikaty przy użyciu tajemnicy znanej tylko Tobie.
Cisco nie jest zaangażowane, co sprawia, że jest to sposób na zagwarantowanie prawdziwego szyfrowania typu end-to-end i zweryfikowanej tożsamości, a także uniemożliwia teoretyczną możliwość podsłuchiwania spotkania/odszyfrowania mediów przez Cisco.
Certyfikat urządzenia wydany wewnętrznie
Webex wydaje certyfikat do urządzenia, gdy rejestruje się po uruchomieniu, i odnawia go w razie potrzeby. W przypadku urządzeń certyfikat zawiera identyfikator konta i domenę.
Jeśli Twoja organizacja nie posiada domeny, urząd certyfikacji Webex wydaje certyfikat bez domeny.
Jeśli Twoja organizacja ma wiele domen, możesz użyć Centrum sterowania, aby poinformować Webex, której domeny urządzenie ma używać do celów tożsamości. Można również użyć interfejsu API XConfiguration Conference EndToEndEncryption Identity PreferredDomain: „example.com”.
Jeśli masz wiele domen i nie ustawiasz preferowanej domeny dla urządzenia, Webex wybiera jedną dla Ciebie.
Zewnętrznie wydany certyfikat urządzenia
Administrator może dostarczyć urządzeniu własny certyfikat, który został podpisany z jednym z publicznych urzędów urzędowych.
Certyfikat musi być oparty na parze kluczy ECDSA P-256, chociaż może być podpisany kluczem RSA.
Wartości zawarte w certyfikacie są w gestii organizacji. Nazwa zwyczajowa (CN) i nazwa alternatywna podmiotu (SAN) będą wyświetlane w interfejsie użytkownika spotkania Webex, zgodnie z opisem w szyfrowaniu typu End-to-end z weryfikacją tożsamości. Webex Meetings
Zalecamy stosowanie oddzielnego certyfikatu na urządzenie i posiadanie unikalnego CN na urządzenie. Na przykład „meeting-room-1.example.com” dla organizacji, która jest właścicielem domeny „example.com”.
Aby w pełni chronić zewnętrzny certyfikat przed manipulacją, funkcja tajna klienta jest używana do szyfrowania i podpisywania różnych poleceń xcommand.
Korzystając z tajnego klienta, możliwe jest bezpieczne zarządzanie zewnętrznym certyfikatem tożsamości Webex za pośrednictwem XAPI. Obecnie jest to ograniczone do urządzeń online.
Webex obecnie udostępnia polecenia API do zarządzania tym.
Urządzenia
Urządzenia Cisco Board, Desk i Room Series zarejestrowane w chmurze mogą dołączać do spotkań E2EE.
Następujące urządzenia nie mogą dołączyć do spotkań E2EE:
-
Urządzenia SIP innych firm
Klienci oprogramowania
-
Aplikacja Webex dla klientów stacjonarnych i mobilnych może dołączyć do spotkań E2EE.
-
Klient internetowy Webex nie może dołączyć do spotkań E2EE.
-
Zewnętrzni klienci SOFT SIP nie mogą dołączyć do spotkań E2EE.
Tożsamość
-
Z założenia nie udostępniamy opcji Control Hub umożliwiających zarządzanie zewnętrzną zweryfikowaną tożsamością urządzenia. Aby uzyskać prawdziwe szyfrowanie typu end-to-end, tylko Ty powinieneś znać/uzyskać dostęp do tajemnic i kluczy. Jeśli wprowadziliśmy usługę w chmurze do zarządzania tymi kluczami, istnieje szansa, że zostaną przechwycone.
-
Obecnie zapewniamy Ci „receptę”, aby zaprojektować własne narzędzia, oparte na standardowych branżowych technikach szyfrowania, aby pomóc w żądaniu lub szyfrowaniu certyfikatów tożsamości urządzenia i ich kluczy prywatnych. Nie chcemy mieć żadnego rzeczywistego lub postrzeganego dostępu do Twoich sekretów lub kluczy.
Spotkania
-
Spotkania E2EE obsługują obecnie maksymalnie 1000 uczestników.
- Możesz udostępniać nowe tablice na spotkaniach E2EE. Istnieją pewne różnice w stosunku do tablic na regularnych spotkaniach:
- W spotkaniach E2EE użytkownicy nie mają dostępu do tablic utworzonych poza spotkaniem, w tym do prywatnych tablic, tablic udostępnianych przez innych oraz tablic z przestrzeni Webex.
- Tablice utworzone na spotkaniach E2EE są dostępne tylko podczas spotkania. Nie są zapisywane i nie są dostępne po zakończeniu spotkania.
- Jeśli ktoś udostępnia treści na spotkaniu E2EE, możesz je opisać. Aby uzyskać więcej informacji na temat adnotacji, zobacz Webex App | Oznaczanie udostępnionych treści ad notacjami.
Interfejs zarządzania
Zdecydowanie zalecamy korzystanie z Control Hub do zarządzania witryną Meetings, ponieważ organizacje Control Hub mają scentralizowaną tożsamość dla całej organizacji.
Powiązane informacje
-
Zero-Trust Security for Webex (dokument techniczny dotyczący bezpieczeństwa)
-
Szy@@ frowanie sieci JSON (JWE) (wersja robocza standardu IETF)
-
Webex Meetings41.7.
-
Urządzenia Cisco Board, Desk i Room Series zarejestrowane w chmurze, z systemem
10.6.1-Roomos_August_2021 lub nowszym. -
Dostęp administracyjny do miejsca spotkania w Control Hub.
-
Jedna lub więcej zweryfikowanych domen w organizacji Control Hub (jeśli używasz Webex CA do wydawania certyfikatów urządzenia dla zweryfikowanej tożsamości).
-
Współpraca Sale konferencyjne muszą być włączone, aby ludzie mogli dołączyć z systemu wideo. Aby uzyskać więcej informacji, zobacz Zez walanie systemom wideo na dołączanie do spotkań i wydarzeń w witrynie Webex.
Możesz pominąć ten krok, jeśli nie potrzebujesz zewnętrznie zweryfikowanych tożsamości.
Dla najwyższego poziomu bezpieczeństwa i weryfikacji tożsamości każde urządzenie powinno posiadać unikalny certyfikat wydany przez zaufaną publiczność Certificate Authority (CA).
Aby zażądać, kupić i otrzymać certyfikaty cyfrowe oraz utworzyć powiązane klucze prywatne, musisz wejść w interakcję z urzędem urzędowym. Podczas żądania certyfikatu należy użyć następujących parametrów:
-
Certyfikat musi być wydany i podpisany przez znanego publicznego urzędu certyfikacji.
-
Unikalne: Zdecydowanie zalecamy stosowanie unikalnego certyfikatu dla każdego urządzenia. Jeśli używasz jednego certyfikatu dla wszystkich urządzeń, narażasz swoje bezpieczeństwo.
-
Nazwa zwyczajowa (CN) i nazwa alternatywna podmiotu (San/s): Nie są one ważne dla Webex, ale powinny być wartościami, które ludzie mogą odczytać i kojarzyć z urządzeniem. CN pokaże innym uczestnikom spotkania jako główną zweryfikowaną tożsamość urządzenia, a jeśli użytkownicy sprawdzą certyfikat za pośrednictwem interfejsu użytkownika spotkania, zobaczą SAN/y. Możesz użyć nazw takich jak
name.model@example.com. -
Format pliku: Certyfikaty i klucze muszą być w form
acie.pem. -
Cel: Celem certyfikatu musi być Webex Identity.
-
Generowanie kluczy: Certyfikaty muszą być oparte na parach kluczy ECDSA P-256 (algorytm podpisu cyfrowego krzywej eliptycznej przy użyciu krzywej P-256).
Wymóg ten nie obejmuje klucza podpisującego. Certyfikat urzędowy może użyć klucza RSA do podpisania certyfikatu.
Możesz pominąć ten krok, jeśli nie chcesz używać zewnętrznie zweryfikowanej tożsamości ze swoimi urządzeniami.
Jeśli używasz nowych urządzeń, nie rejestruj ich jeszcze w Webex. Aby być bezpiecznym, nie podłączaj ich do sieci w tym momencie.
Jeśli masz istniejące urządzenia, które chcesz uaktualnić, aby używać zewnętrznie zweryfikowanej tożsamości, musisz przywrócić ustawienia fabryczne urządzenia.
-
Zapisz istniejącą konfigurację, jeśli chcesz ją zachować.
-
Zaplanuj okno, gdy urządzenia nie są używane, lub użyj podejścia etapowego. Powiadom użytkowników o zmianach, których mogą się spodziewać.
-
Zapewnij fizyczny dostęp do urządzeń. Jeśli musisz uzyskać dostęp do urządzeń przez sieć, pamiętaj, że tajemnice podróżują zwykłym tekstem i narażasz swoje bezpieczeństwo.
Po wykonaniu tych kroków zezwolić systemom wideo na dołączanie do spotkań i wydarzeń w witrynie Webex.
Aby upewnić się, że nośnik urządzenia nie może być zaszyfrowany przez nikogo poza urządzeniem, musisz zaszyfrować klucz prywatny na urządzeniu. Zaprojektowaliśmy interfejsy API dla urządzenia, aby umożliwić zarządzanie zaszyfrowanym kluczem i certyfikatem przy użyciu JSON Web Encryption (JWE).
Aby zapewnić prawdziwe szyfrowanie typu end-to-end za pośrednictwem naszej chmury, nie możemy angażować się w szyfrowanie i przesyłanie certyfikatu i klucza. Jeśli potrzebujesz tego poziomu bezpieczeństwa, musisz:
-
Poproś o certyfikaty.
-
Wygeneruj pary kluczy swoich certyfikatów.
-
Utwórz (i chroń) wstępny sekret dla każdego urządzenia, aby zapoczątkować możliwości szyfrowania urządzenia.
-
Opracuj i utrzymuj własne narzędzie do szyfrowania plików przy użyciu standardu JWE.
Proces i (nie-tajne) parametry, których będziesz potrzebować, zostały wyjaśnione poniżej, a także przepis, który należy zastosować w wybranych narzędziach programistycznych. Zapewniamy również niektóre dane testowe i wynikające z nich bloby JWE, zgodnie z oczekiwaniami, aby pomóc Ci zweryfikować proces.
Nieobsługiwana implementacja referencyjna wykorzystująca Python3 i bibliotekę JWCrypto jest dostępna w Cisco na żądanie.
-
Połącz i zaszyfruj certyfikat i klucz za pomocą narzędzia i początkowego sekretu urządzenia.
-
Prześlij wynikową blob JWE do urządzenia.
-
Ustaw cel zaszyfrowanego certyfikatu, który ma być używany dla tożsamości Webex i aktywuj certyfikat.
-
(Zalecane) Zapewnij interfejs (lub rozpowszechniaj) narzędzie, aby umożliwić użytkownikom urządzenia zmianę początkowej tajemnicy i ochronę swoich nośników przed Tobą.
Jak używamy formatu JWE
W tej sekcji opisano, w jaki sposób oczekujemy, że JWE zostanie utworzony jako dane wejściowe do urządzeń, abyś mógł stworzyć własne narzędzie do tworzenia blob z certyfikatów i kluczy.
Patrz JSON Web Encryption (JWE) https://datatracker.ietf.org/doc/html/rfc7516 i JSON Web Signature (JWS) https://datatracker.ietf.org/doc/html/rfc7515.
Używamy kompaktowej serializacji dokumentu JSON do tworzenia blob JWE. Parametry, które musisz uwzględnić podczas tworzenia blobów JWE to:
-
Nagłówek JOSE (chroniony). W nagłówku Podpisywanie i szyfrowanie obiektów JSON NALEŻY dołączyć następujące pary klucz-wartość:
-
„alg” :"dir”Algorytm bezpośredni jest jedynym, który obsługujemy do szyfrowania ładunku, i musisz użyć początkowego sekretu klienta urządzenia.
-
„enc” :"A128GCM” lub„enc” :"A256GCM”Obsługujemy te dwa algorytmy szyfrowania.
-
„cisco-action”: „dodaj” lub „cisco-action”:„wypełnij” lub „cisco-action”: „aktywuj”lub„cisco-action”: „dezaktywuj”Jest to zastrzeżony klucz i cztery wartości, które może przyjąć. Wprowadziliśmy ten klucz, aby zasygnalizować cel zaszyfrowanych danych do urządzenia docelowego. Wartości są nazwane na cześć poleceń xAPI na urządzeniu, na którym używane są zaszyfrowane dane.
Nazwaliśmy to
cisco-action, aby złagodzić potencjalne starcia z przyszłymi rozszerzeniami JWE. -
„cisco-kdf”: {„version”: „1", „salt”: „base64URLENcodeDrandom4+bajty”}Kolejny zastrzeżony klucz. Używamy podanych przez Ciebie wartości jako danych wejściowych do wyprowadzania kluczy na urządzeniu.
Wersjamusi być1(wersja naszej funkcji wyprowadzania klucza). Wartośćsolimusi być sekwencją zakodowaną przez base64 URL co najmniej 4 bajty, którą należy wybrać losowo.
-
-
JWE Zaszyfrowany klucz. To pole jest puste. Urządzenie czerpie go z początkowego
ClientSecret. -
Wektor inicjalizacji J WE. Aby odszyfrować ładunek, musisz dostarczyć wektor inicjalizacji zakodowany base64url. IV MUSI być losową wartością 12 bajtów (używamy rodziny szyfrów AES-GCM, która wymaga, aby IV miał 12 bajtów długości).
-
JWE AAD (dodatkowe uwierzytelnione dane). Należy pominąć to pole, ponieważ nie jest ono obsługiwane w Kompaktowej Serializacji.
-
JWE Cyphertext: Jest to zaszyfrowany ładunek, który chcesz zachować w tajemnicy.
Ładunek może być pusty. Na przykład, aby zresetować sekret klienta, musisz nadpisać go pustą wartością.
Istnieją różne rodzaje ładunków, w zależności od tego, co próbujesz zrobić na urządzeniu. Różne polecenia XAPI oczekują różnych ładunków, a cel ładunku należy określić za pomocą klucza
cisco-action w następujący sposób:-
Dzięki„cisco-action” :"wypełnić” szyfrowany tekst jest nowym ClientSecret. -
W przypadku "
„cisco-action” :"add”szyfrowany tekst jest blobem PEM zawierającym certyfikat i jego klucz prywatny (połączony). -
Przy pomocy "
„cisco-action” :"activate”szyfrowany tekst jest odciskiem palca (szesnastkowa reprezentacja sha-1) certyfikatu, który aktywujemy w celu weryfikacji tożsamości urządzenia. -
W przypadku "
„cisco-action” :"dezaktywuj”szyfrowany tekst jest odciskiem palca (szesnastkowa reprezentacja sha-1) certyfikatu, którego dezaktywujemy do weryfikacji tożsamości urządzenia.
-
-
Tag uwierzytelniania JWE: To pole zawiera tag uwierzytelniania umożliwiający sprawdzenie integralności całego kompaktowo serializowanego blob JWE
Jak wyprowadzamy klucz szyfrowania z ClientSecret
Po pierwszej publikacji tajemnicy nie akceptujemy ani nie wyprowadzamy tajemnicy jako zwykłego tekstu. Ma to na celu zapobieganie potencjalnym atakom słownikowym przez kogoś, kto mógłby uzyskać dostęp do urządzenia.
Oprogramowanie urządzenia wykorzystuje sekret klienta jako dane wejściowe do funkcji wyprowadzania klucza (kdf), a następnie wykorzystuje klucz pochodny do odszyfrowywania/szyfrowania treści na urządzeniu.
Oznacza to dla Ciebie, że Twoje narzędzie do tworzenia blob JWE musi postępować zgodnie z tą samą procedurą, aby wyprowadzić ten sam klucz szyfrowania/deszyfrowania z tajemnicy klienta.
Urządzenia używają scrypt do wyprowadzania kluczy (patrz https://en.wikipedia.org/wiki/Scrypt), z następującymi parametrami:
-
CostFactor (N) wynosi 32768
-
BlocksizeFactor (r) wynosi 8
-
Współczynnik równoległości (p) wynosi 1
-
Sól to losowa sekwencja licząca co najmniej 4 bajty; należy podać tę samą
sólpodczas określania parametrucisco-kdf. -
Długość klucza wynosi 16 bajtów (jeśli wybierzesz algorytm AES-GCM 128) lub 32 bajty (jeśli wybierzesz algorytm AES-GCM 256)
-
Maksymalny limit pamięci wynosi 64 MB
Ten zestaw parametrów jest jedyną konfiguracją scrypt, która jest kompatybilna z funkcją wyprowadzania kluczy na urządzeniach. Ten kdf na urządzeniach nazywa się „version” :"1", co jest jedyną wersją aktualnie przyjętą przez parametr ci sco-kdf.
Pracowany przykład
Oto przykład, który możesz podążać, aby sprawdzić, czy proces szyfrowania JWE działa tak samo, jak proces, który utworzyliśmy na urządzeniach.
Przykładowym scenariuszem jest dodanie blob PEM do urządzenia (naśladuje dodanie certyfikatu, z bardzo krótkim ciągiem zamiast pełnego klucza cert +). Sekretem klienta w przykładzie jest ossifrage.
-
Wybierz szyfr szyfrowania. W tym przykładzie zastosowano
A128GCM(AES z 128-bitowymi kluczami w trybie licznika Galois). Twoje narzędzie może używaćA256GCM, jeśli wolisz. -
Wybierz sól (musi być losową sekwencją co najmniej 4 bajtów). W tym przykładzie zastosowano (bajty heksadecym
alne) E5 E6 53 08 03 F8 33 F6. Base64URL koduje sekwencję, aby uzyskać5eZtCap4m_Y (usuń wyściółkębase64). -
Oto przykładowe wywołanie
scrypt w celuutworzenia klucza szyfrowania treści (cek):cek=scrypt(password="ossifrage", salt=4-byte-sequence, N=32768, r=8, p=1, keylength=16)Klucz pochodny powinien wynosić 16 bajtów (hex) w następujący sposób:95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff acktóry base64url koduje do LZ66bdeiAQV4_MQDINJ_RA. -
Wybierz losową sekwencję 12 bajtów do użycia jako wektor inicjalizacji.
W tym przykładzie wykorzystano (hex)34 b3 5d dd 5f 53 7b af 2d 92 95 83, który base64url koduje do nlnd3v9te68tkpwd. -
Utwórz nagłówek JOSE z kompaktową serializacją (postępuj zgodnie z tą samą kolejnością parametrów, jakiej używamy tutaj), a następnie zakoduj go base64url:
{"alg” :"dir”, "cisco-action” :"dodaj”, "cisco-kdf”: {"salt” :"5eZtCap4m_Y”, "version” :"1"}, "enc” :"A128GCM "}Base64url zakodowany nagłówkiem JOSE jest EYJHBGCioIJkaXiilCJJAxnjBy1HY3rpb24ioIJhzgQilCJJAxnjby1rZgyionsic2fsdci6ijvlwlrdqva0tv9ziiwidmvyc2lvbii6ijeifswizw5jijoiqteyoeddtsj9Będzie to pierwszy element JWE blob.
-
Drugi element blob JWE jest pusty, ponieważ nie dostarczamy klucza szyfrującego JWE.
-
Trzecim elementem blob JWE jest wektor inicjalizacji NLND3v9TE68tkpwd. - Użyj narzędzia szyfrowania JWE, aby wytworzyć zaszyfrowany ładunek i tag. W tym przykładzie niezaszyfrowany ładunek będzie fałszywą blobą PEM,
to jestplik PEMParametry szyfrowania, których powinieneś użyć, to:
Ładunek
to jest to plik PEMSzyfr szyfrowania to AES 128 GCM
Base64url zakodowany nagłówek JOSE jako dodatkowe dane uwierzytelnione (AAD)
Base64URL koduje zaszyfrowany ładunek, co powinno skutkować f5llvUWnfkfmzyCO1yjfodhqJest to czwarty element (JWE Ciphertext) w blobie JWE.
-
Base64URL koduje tag wyprodukowany w kroku 8, co powinno skutkować PE-wdfwgxffbeo928cfz1qJest to piąty element w blobie JWE.
-
Połącz pięć elementów blob JWE kropkami (JoseHeader.. iv.CipherText.tag), aby uzyskać:
EyjHBGCioIJkaXiilCjJAxnjBy1hy3Rpb24ioIJhzgQilcJjaXnjBy1rZgYionsIC2fSDCI6IJvlwlrdqva0tv9ziiwidmvyc2lvbii6ijeifswizw5jijoiqteyoeddtsJ.. 9nlnd3v9te68tkpwd.f5llvUVuUD.f5llvUVuDd FKFmZyCO1yJFODHQ.PE-WDFWGXFFBEO928CFZ1Q -
Jeśli wyprowadziłeś te same wartości zakodowane base64url, które pokazujemy tutaj, używając własnych narzędzi, jesteś gotowy do ich użycia w celu zabezpieczenia szyfrowania E2E i zweryfikowanej tożsamości swoich urządzeń.
-
Ten przykład faktycznie nie zadziała, ale w zasadzie następnym krokiem byłoby użycie utworzonego powyżej bloba JWE jako wejścia do polecenia xna na urządzeniu, które dodaje certyfikat:
Certyfikaty zabezpieczeń XCommand Dodaj EyjHBGCioIJkAxiilCJJAxnjby1hy3rpb24ioijhzgQiLcJjaXnjBy1rZgYionsIC2fsdci6IJvLwlRdqva0tv9ziiwidmvyc2lvbii6ijeifswizw5jiJoiqteYoeddtsJ.. 9nLnd3v9te68pwtkD.tKd.F5LLvUWnfkfmZYCO1yJfodHq.PE-WdfWGxFFBEo928CFz1Q
Typy sesji dla spotkań bez zaufania są dostępne dla wszystkich witryn spotkań bez dodatkowych kosztów. Jeden z tych typów sesji nazywa się Pro-End to End Encryption_VOIPOnly. To jest nazwa usługi publicz nej, którą możemy zmienić w przyszłości. Aby zapoznać się z bieżącymi nazwami typów sesji, z obacz Identyfikatory typów sesji w sekcji Odniesienie tego artykułu.
Nie musisz nic zrobić, aby uzyskać tę funkcję dla swojej witryny; musisz przyznać użytkownikom nowy typ sesji (zwany także uprawnieniami do spotkania). Możesz to zrobić indywidualnie za pośrednictwem strony konfiguracji użytkownika lub zbiorczo za pomocą eksportu/importu CSV.
| 1 |
Zaloguj się do Control Hub i przejdź do opcji . |
| 2 |
Kliknij pozycję Wit ryny, wybierz witrynę Webex, dla której chcesz zmienić ustawienia, a następnie kliknij Ustawienia. |
| 3 |
W obszarze Ustawienia wspól ne wybierz opcję Typy sesji. Powinieneś zobaczyć jeden lub więcej typów sesji szyfrowania typu end-to-end. Zapoznaj się z listą identyfikatorów typów sesji w sekcji Od niesi enie tego artykułu. Na przykład możesz zobaczyć Encryption_VoipOnly od End to End Encryption _VoipOnly.
Istnieje starszy typ sesji o bardzo podobnej nazwie: Pro-End to End End Encryption. Ten typ sesji obejmuje niezaszyfrowany dostęp PSTN do spotkań. Upewnij się, że masz wersję _VoIPOnly, aby zapewnić szyfro wanie typu end-to-end. Możesz to sprawdzić, najechając kursorem na link PRO w kolumnie kodu sesji; w tym przykładzie celem łącza powinien być W przyszłości możemy zmienić nazwy usług publicznych dla tych typów sesji. |
| 4 |
Jeśli nie masz jeszcze nowego typu sesji, skontaktuj się z przedstawicielem Webex. |
Co robić dalej
Włącz ten typ sesji/uprawnienia spotkania dla niektórych lub wszystkich użytkowników.
| 1 |
Zaloguj się do Control Hub i przejdź do menu . |
| 2 |
Wybierz konto użytkownika, które chcesz zaktualizować, a następnie wybierz pozycję S potkania. |
| 3 |
Z listy rozwijanej Ustawienia mają zastosowanie do wybierz witrynę spotkania do aktualizacji. |
| 4 |
Zaznacz pole obok opcji Pro-End to End Encryption_ VoipOnly. |
| 5 |
Zamknij panel konfiguracji użytkownika. |
| 6 |
W razie potrzeby powtórz dla innych użytkowników. Aby przypisać to do wielu użytkowników, użyj następnej opcji W łącz spotkania E2EE dla wielu użytkowników. |
| 1 |
Zaloguj się do Control Hub i przejdź do opcji . |
| 2 |
Kliknij Wit ryny, wybierz witrynę Webex, dla której chcesz zmienić ustawienia. |
| 3 |
W sekcji Licencje i użytkownicy kliknij opcję Zarządzanie zbiorczo. |
| 4 |
Kliknij Generuj raport i poczekaj, aż przygotujemy plik. |
| 5 |
Gdy plik jest gotowy, kliknij Eksportuj wyniki, a następnie Pobierz. (Musisz ręcznie zamknąć to wyskakujące okienko po kliknięciu przycisku Pobierz). |
| 6 |
Otwórz pobrany plik CSV do edycji. Dla każdego użytkownika znajduje się wiersz, a kolumna |
| 7 |
Od niesienie do formatu pliku CSV Webex zawiera szczegółowe informacje na temat celu i zawartości pliku CSV. |
| 8 |
Otwórz panel konfiguracji miejsca spotkania w Centrum sterowania. Jeśli znajdowałeś się już na stronie listy witryn spotkania, może być konieczne jej odświeżenie. |
| 9 |
W sekcji Licencje i użytkownicy kliknij opcję Zarządzanie zbiorczo. |
| 10 |
Kliknij Importu j i wybierz edytowany plik CSV, a następnie kliknij Importuj. Poczekaj, aż plik zostanie przesłany. |
| 11 |
Po zakończeniu importu możesz kliknąć Importuj wyniki, aby sprawdzić, czy wystąpiły jakiekolwiek błędy. |
| 12 |
Przejdź do strony Użytkownicy i otwórz jednego z użytkowników, aby sprawdzić, czy mają nowy typ sesji. |
Możesz dodać znak wodny do nagrań spotkań za pomocą typu sesji Webex MeetingsPro-End to End Encryption_VOIPOn ly, który umożliwia identyfikację źródła klienta lub urządzenia nieautoryzowanych nagrań poufnych spotkań.
Gdy ta funkcja jest włączona, dźwięk spotkania zawiera unikalny identyfikator dla każdego uczestniczącego klienta lub urządzenia. Możesz przesłać nagrania audio do Control Hub, który następnie analizuje nagranie i wyszukuje unikalne identyfikatory. Możesz spojrzeć na wyniki, aby zobaczyć, który klient źródłowy lub urządzenie zarejestrowało spotkanie.
- Aby można było przeanalizować, nagranie musi być plikiem AAC, MP3, M4A, WAV, MP4, AVI lub MOV nie większym niż 500 MB.
- Nagrywanie musi być dłuższe niż 100 sekund.
- Możesz analizować tylko nagrania spotkań prowadzonych przez osoby w Twojej organizacji.
- Informacje o znaku wodnym są przechowywane przez taki sam czas, jak informacje o spotkaniach organizacji.
Dodawanie znaków wodnych audio do spotkań E2EE
- Zaloguj się do Centrum sterowania, a następnie w obszarze Zarządz anie wybierz Ustawienia organizacji.
- W sekcji Z naki wodne spotkania przełącz opcję Dodaj znak wodny audio.
Jakiś czas po włączeniu tego włączenia użytkownicy planujący spotkania z typem sesji
Webex MeetingsPro-End to End Encryption_VOIPOnly widzą opcję Cyfrowy znak wodny w sekcji Zabezpieczenia.
Przesyłanie i analizowanie spotkania ze znakiem wodnym
- W Centrum sterowania w obszarze Monitorowanie wybierz Rozwiązywanie problemów.
- Kliknij opcję Analiza znaku wodnego.
- Wyszukaj lub wybierz spotkanie na liście, a następnie kliknij przycisk Analizuj.
- W oknie Analizuj znak wodny audio wprowadź nazwę analizy.
- (Opcjonalnie) Wprowadź notatkę do analizy.
- Przeciągnij i upuść plik audio do analizy lub kliknij Wybierz plik, aby przejść do pliku audio.
- Kliknij przycisk Zamkni j.
Po zakończeniu analizy zostanie wyświetlona na liście wyników na stronie Analizuj znak wod ny.
- Wybierz spotkanie z listy, aby zobaczyć wyniki analizy. Kliknij
aby pobrać wyniki.
Funkcje i ograniczenia
Czynniki zaangażowane w pomyślne dekodowanie nagranego znaku wodnego obejmują odległość między urządzeniem nagrywającym a głośnikiem wyprowadzającym dźwięk, głośność tego dźwięku, hałas środowiskowy itp. Nasza technologia znakowania wodnego ma dodatkową odporność na wielokrotne kodowanie, jak może się zdarzyć, gdy media są udostępniane.
Ta funkcja ma na celu umożliwienie skutecznego dekodowania identyfikatora znaku wodnego w szerokim, ale rozsądnym zestawie okoliczności. Naszym celem jest, aby urządzenie rejestrujące, takie jak telefon komórkowy, które leży na biurku w pobliżu osobistego punktu końcowego lub klienta laptopa, zawsze tworzyło nagranie, które skutkuje udaną analizą. Gdy urządzenie rejestrujące jest oddalone od źródła lub jest zasłonięte przed słyszeniem pełnego spektrum dźwięku, szanse na udaną analizę są zmniejszone.
Aby pomyślnie przeanalizować nagranie, konieczne jest rozsądne przechwycenie dźwięku spotkania. Jeśli dźwięk spotkania jest nagrywany na tym samym komputerze, na którym znajduje się klient, ograniczenia nie powinny obowiązywać.
Jeśli Twoje urządzenia są już włączone do organizacji Control Hub i chcesz użyć Webex CA do automatycznego generowania ich certyfikatów identyfikacyjnych, nie musisz ustawiać ustawień fabrycznych urządzeń.
Ta procedura wybiera domenę używaną przez urządzenie do identyfikacji i jest wymagana tylko wtedy, gdy w organizacji Control Hub znajduje się wiele domen. Jeśli masz więcej niż jedną domenę, zalecamy zrobienie tego dla wszystkich urządzeń, które będą miały tożsamość „zweryfikowaną przez Cisco”. Jeśli nie powiesz Webex, która domena identyfikuje urządzenie, zostanie wybrana automatycznie i może wyglądać źle dla innych uczestników spotkania.
Zanim zaczniesz
Jeśli Twoje urządzenia nie są jeszcze włączone, kliknij opcję Zarejest ruj urządzenie w celu korzystania Cisco Webex z interfejsu API lub lokalnego interfejsu internetowego lub wdrażania w chmurze dla serii Board, Desk i Room. Powinieneś także zweryfikować domenę, której chcesz użyć do identyfikacji urządzeń w Zarządzaj domenami.
| 1 |
Zaloguj się do Centrum sterowania i w obszarze Zarządz anie wybierz Urządzenia. |
| 2 |
Wybierz urządzenie, aby otworzyć panel konfiguracji. |
| 3 |
Wybierz domenę, której chcesz użyć do identyfikacji tego urządzenia. |
| 4 |
Powtórz dla innych urządzeń. |
Zanim zaczniesz
-
Uzyskaj certyfikat podpisany przez CA i klucz prywatny w form
acie.pemdla każdego urządzenia. -
Na karcie Przygotuj przeczytaj temat Z rozumienie procesu identyfikacji zewnętrznej urządzeń,
-
Przygotuj narzędzie szyfrowania JWE w odniesieniu do informacji znajdujących się tam.
-
Upewnij się, że masz narzędzie do generowania losowych sekwencji bajtów o podanych długościach.
-
Upewnij się, że masz narzędzie do kodowania bajtów lub tekstu base64url.
-
Upewnij się, że masz implementację
scrypt. -
Upewnij się, że masz tajne słowo lub frazę dla każdego urządzenia.
| 1 |
Wypełnij Gdy po raz pierwszy wypełnisz Sek Urządzenie ma swój początkowy sekret. Nie zapomnij o tym; nie możesz go odzyskać i musisz zresetować urządzenie fabrycznie, aby uruchomić ponownie.
|
| 2 |
Połącz swój certyfikat i klucz prywatny: |
| 3 |
Utwórz blob JWE do użycia jako dane wejściowe do polecenia dodawania certyfikatu: |
| 4 |
Otwórz TShell na urządzeniu i uruchom polecenie (wielowierszowe) dodaj: |
| 5 |
Sprawdź, czy certyfikat został dodany, uruchamiając Skopiuj odcisk palca nowego certyfikatu. |
| 6 |
Aktywuj certyfikat w celu Urządzenie posiada zaszyfrowany, aktywny certyfikat wydany przez CA, gotowy do użycia do identyfikacji w szyfrowanych spotkaniach Webex typu end-to-end.
|
| 7 |
Włącz urządzenie do organizacji Control Hub. |
| 1 |
Zaplanuj spotkanie właściwego typu (Webex MeetingsPro-End to End Encryption_ VoipOnly). |
| 2 |
Dołącz do spotkania jako gospodarz, od Webex Meetings klienta. |
| 3 |
Dołącz do spotkania z urządzenia, którego tożsamość została zweryfikowana przez Webex CA. |
| 4 |
Jako host sprawdź, czy to urządzenie pojawia się w holu z prawidłową ikoną tożsamości. |
| 5 |
Dołącz do spotkania z urządzenia, którego tożsamość została zweryfikowana przez zewnętrzny urząd urzędowy. |
| 6 |
Jako host sprawdź, czy to urządzenie pojawia się w holu z prawidłową ikoną tożsamości. Dowiedz się więcej o ikonach tożsamości. |
| 7 |
Dołącz do spotkania jako nieuwierzytelniony uczestnik spotkań. |
| 8 |
Jako gospodarz sprawdź, czy uczestnik pojawia się w holu z prawidłową ikoną tożsamości. |
| 9 |
Jako gospodarz przyjmuj lub odrzucaj osoby/urządzenia. |
| 10 |
W miarę możliwości sprawdź tożsamość uczestników/urządzenia, sprawdzając certyfikaty. |
| 11 |
Sprawdź, czy wszyscy uczestnicy spotkania widzą ten sam kod bezpieczeństwa spotkania. |
| 12 |
Dołącz do spotkania z nowym uczestnikiem. |
| 13 |
Sprawdź, czy wszyscy widzą ten sam, nowy kod bezpieczeństwa spotkania. |
-
Czy zamierzasz ustawić szyfrowane spotkania typu end-to-end jako domyślną opcję spotkania, lub włączyć ją tylko dla niektórych użytkowników, lub zezwolić wszystkim gospodarzom na podjęcie decyzji? Kiedy zdecydujesz, w jaki sposób zamierzasz korzystać z tej funkcji, przygotuj tych użytkowników, którzy będą z niej korzystać, zwłaszcza w odniesieniu do ograniczeń i tego, czego można się spodziewać na spotkaniu.
-
Czy musisz upewnić się, że ani Cisco, ani nikt inny nie będzie mógł odszyfrować Twoich treści ani podszyfrować się pod Twoje urządzenia? Jeśli tak, potrzebujesz certyfikatów z publicznego urzędu certyfikacji.
-
Jeśli masz różne poziomy weryfikacji tożsamości, upoważnij użytkowników do wzajemnej weryfikacji za pomocą tożsamości popartej certyfikatem. Mimo że istnieją okoliczności, w których uczestnicy mogą pojawić się jako niezweryfikowani, a uczestnicy powinni wiedzieć, jak to sprawdzić, niezweryfikowane osoby mogą nie być oszustami.
Jeśli używasz zewnętrznego urzędu certyfikacji do wydawania certyfikatów urządzenia, obowiązek monitorowania, odświeżania i ponownego stosowania certyfikatów spoczywa na użytkowniku.
Jeśli utworzyłeś wstępny sekret, zrozum, że Twoi użytkownicy mogą chcieć zmienić tajemnicę swojego urządzenia. Może być konieczne utworzenie interfejsu/rozpowszechnienie narzędzia, aby umożliwić im to.
|
Identyfikator typu sesji |
Nazwa usługi publicznej |
|---|---|
|
638 |
Szyfrowanie E2E+tylko VoIP |
|
652 |
Encryption_VoipOnly od końca do końca |
|
660 |
Pro 3 Encryption_VoipOnly Szyfrowanie E2E+Tożsamość |
|
672 |
Pro 3 Free50 Encryption od końca do końca _VOIPOnly |
|
673 |
Instruktor edukacji E2E Encryption_VoipOnly |
|
676 |
Broadworks Standard plus szyfrowanie typu end-to-end |
|
677 |
Broadworks Premium plus szyfrowanie typu end-to-end |
|
681 |
Schoology Free plus szyfrowanie typu end-to-end |
Tabele te opisują polecenia interfejsu API urządzeń Webex, które dodaliśmy do szyfrowanych spotkań typu end-to-end i zweryfikowanej tożsamości. Aby uzyskać więcej informacji na temat korzystania z interfejsu API, zobacz Dostęp do interfejsu API dla urządzeń z serii Board, Desk i Room.
Te polecenia XAPI są dostępne tylko na urządzeniach, które są:
-
Zarejestrowany w Webex
-
Zarejestrowany lokalnie i połączony z Webex za pomocą for Devices Webex Edge
|
Wywołanie API |
Opis |
|---|---|
|
|
Ta konfiguracja jest dokonywana, gdy administrator ustawi preferowaną domenę urządzenia z Control Hub. Konieczne tylko wtedy, gdy organizacja ma więcej niż jedną domenę. Urządzenie korzysta z tej domeny, gdy żąda certyfikatu z Webex CA. Następnie domena identyfikuje urządzenie. Ta konfiguracja nie ma zastosowania, gdy urządzenie posiada aktywny, zewnętrzny certyfikat umożliwiający identyfikację. |
|
|
Wskazuje, czy urządzenie może dołączyć do szyfrowanego spotkania typu end-to-end. Interfejs API w chmurze wywołuje go, aby sparowana aplikacja wiedziała, czy może użyć urządzenia do dołączenia. |
|
|
Wskazuje, czy urządzenie korzysta |
|
|
Tożsamość urządzenia odczytana z nazwy wspólnej certyfikatu wydanego zewnętrznie. |
|
|
Odczytuje konkretne informacje z certyfikatu wydanego zewnętrznie. W pokazanym poleceniu zastąp
|
|
|
Stan zewnętrznej tożsamości urządzenia (np. |
|
|
Wskazuje, czy urządzenie posiada ważny certyfikat wydany przez Webex CA. |
|
|
Tożsamość urządzenia odczytana z nazwy wspólnej certyfikatu wydanego przez WebEx. Zawiera nazwę domeny, jeśli organizacja posiada domenę. Jest pusty, jeśli organizacja nie ma domeny. Jeśli urządzenie znajduje się w organizacji, która ma wiele domen, jest to wartość z |
|
|
Odczytuje konkretne informacje z certyfikatu wydanego przez WebEx. W pokazanym poleceniu zastąp
|
|
Wywołanie API |
Opis |
|---|---|
|
|
|
Wywołanie API |
Opis |
|---|---|
albo
| Akceptuje zakodowaną przez base64url wartość zwykłego tekstu do umieszczenia tajemnicy klienta na urządzeniu po raz pierwszy. Aby zaktualizować sekret po tym pierwszym razem, musisz dostarczyć blob JWE zawierający nowy sekret zaszyfrowany przez stary sekret. |
| Dodaje certyfikat (z kluczem prywatnym). Rozszerzyliśmy to polecenie, aby zaakceptować blob JWE zawierający zaszyfrowane dane PEM. |
| Aktywuje określony certyfikat dla WebExIdentity. W tym |
| Dezaktywuje określony certyfikat dla WebExIdentity. W tym |
