Użytkownicy wybierają nowy typ spotkania podczas planowania spotkania. Podczas przyjmowania uczestników z lobby i 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 bieżących uczestników spotkania, którego mogą używać do wzajemnej weryfikacji.
Udostępnij gospodarzom spotkania następujące informacje:
Dołączanie do spotkania Webex z szyfrowaniem end-to-end
Weryfikacja tożsamości
Kompleksowa weryfikacja tożsamości zapewnia dodatkowe zabezpieczenia 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 sprawdzają poprawność certyfikatów względem wystawiającego urzędu certyfikacji (CA). Potwierdzając, że certyfikaty są ważne, urząd certyfikacji weryfikuje tożsamość uczestników, a spotkanie pokazuje uczestników / urządzenia jako zweryfikowane.
Użytkownicy aplikacji Webex Meetings uwierzytelniają się w magazynie tożsamości Webex, który wystawia im token dostępu, gdy im się powiedzie. Jeśli potrzebują certyfikatu do weryfikacji swojej tożsamości - na szyfrowanym spotkaniu end-to-end - urząd certyfikacji Webex wystawia im certyfikat na podstawie tokenu dostępu. Nie zapewniamy jeszcze użytkownikom Webex Meetings możliwości uzyskania certyfikatu wydanego przez zewnętrzny / zewnętrzny urząd certyfikacji.
Urządzenia mogą uwierzytelniać się przy użyciu certyfikatu wystawionego przez wewnętrzny urząd certyfikacji (Webex) lub certyfikatu wystawionego przez zewnętrzny urząd certyfikacji:
W przypadku wewnętrznego urzędu certyfikacji Webex wystawia certyfikat wewnętrzny na podstawie tokenu dostępu do konta komputera urządzenia. Certyfikat jest podpisany przez urząd certyfikacji Webex. Urządzenia nie mają identyfikatorów użytkowników w taki sam sposób jak użytkownicy, więc Webex używa (jednej z) domen organizacji podczas zapisywania tożsamości certyfikatu urządzenia (Common Name (CN)).
W przypadku zewnętrznego urzędu certyfikacji należy żądać i kupować certyfikaty urządzeń bezpośrednio od wybranego wystawcy. Certyfikaty należy szyfrować, przesyłać bezpośrednio i autoryzować przy użyciu znanego tylko Użytkownikowi wpisu tajnego.
Cisco nie jest zaangażowane, co sprawia, że jest to sposób na zagwarantowanie prawdziwego szyfrowania end-to-end i zweryfikowanej tożsamości oraz zapobieganie teoretycznej możliwości, że Cisco może podsłuchiwać spotkanie / odszyfrowywać multimedia.
Wewnętrznie wydany certyfikat urządzenia
Webex wydaje certyfikat urządzeniu podczas rejestracji po uruchomieniu i odnawia go w razie potrzeby. W przypadku urządzeń certyfikat zawiera identyfikator konta i domenę.
Jeśli organizacja nie ma domeny, urząd certyfikacji Webex wystawia certyfikat bez domeny.
Jeśli Twoja organizacja ma wiele domen, możesz użyć Control Hub, aby poinformować Webex, której domeny urządzenie ma używać do swojej tożsamości. Możesz także 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 wybierze jedną dla Ciebie.
Certyfikat urządzenia wystawiony zewnętrznie
Administrator może aprowizować urządzenie z własnym certyfikatem, który został podpisany za pomocą jednego z publicznych urzędów certyfikacji.
Certyfikat musi być oparty na parze kluczy ECDSA P-256, chociaż może być podpisany kluczem RSA.
Wartości w certyfikacie zależą od uznania organizacji. Nazwa pospolita (CN) i alternatywna nazwa podmiotu (SAN) będą wyświetlane w interfejsie użytkownika spotkania Webex, zgodnie z opisem w sekcji Szyfrowanie end-to-end z weryfikacją tożsamości dla spotkań Webex.
Zaleca się stosowanie oddzielnego certyfikatu dla każdego urządzenia i posiadanie unikalnego CN dla każdego urządzenia. Może to być na przykład "meeting-room-1.example.com" dla organizacji, która jest właścicielem domeny "example.com".
Aby w pełni chronić certyfikat zewnętrzny przed manipulacją, funkcja klucza tajnego klienta jest używana do szyfrowania i podpisywania różnych poleceń xcommand.
Podczas korzystania z klucza tajnego klienta możliwe jest bezpieczne zarządzanie zewnętrznym certyfikatem tożsamości webex za pośrednictwem xAPI. Jest to obecnie ograniczone do urządzeń online.
Obecnie Webex udostępnia polecenia API do zarządzania tym.
Urządzenia
Zarejestrowane w chmurze urządzenia z serii Webex Room i Webex Desk mogą dołączać do szyfrowanych spotkań end-to-end, w tym:
Tablica Webex Board
Webex Desk Pro
Biurko Webex
Webex Room Kit
Webex Room Kit Mini
Następujące urządzenia nie mogą dołączać do szyfrowanych spotkań end-to-end:
Seria Webex C
Seria Webex DX
Seria Webex EX
Seria Webex MX
Urządzenia SIP innych firm
Klienci oprogramowania
Od wersji 41.6 klient stacjonarny Webex Meetings może dołączać do szyfrowanych spotkań end-to-end.
Jeśli Twoja organizacja umożliwia aplikacji Webex dołączanie do spotkań przez uruchomienie aplikacji klasycznej Spotkania, możesz użyć tej opcji, aby dołączyć do zaszyfrowanych spotkań end-to-end.
Klient internetowy Webex nie może dołączać do szyfrowanych spotkań end-to-end.
Klienci programowi SIP innych firm nie mogą dołączać do szyfrowanych spotkań typu end-to-end.
tożsamość
Nie udostępniamy żadnych opcji Control Hub do zarządzania tożsamością urządzenia zweryfikowanego zewnętrznie. Ta decyzja jest zgodna z projektem, ponieważ w przypadku prawdziwego szyfrowania end-to-end tylko Ty powinieneś znać / uzyskiwać dostęp do tajemnic i kluczy. Jeśli wprowadziliśmy usługę w chmurze do zarządzania tymi kluczami, istnieje szansa, że zostaną one przechwycone.
Obecnie nie udostępniamy żadnych narzędzi, które mogłyby pomóc Ci w żądaniu lub szyfrowaniu certyfikatów tożsamości urządzenia i ich kluczy prywatnych. Obecnie zapewniamy "przepis" na zaprojektowanie własnych narzędzi, opartych na standardowych technikach szyfrowania, aby pomóc w tych procesach. Nie chcemy mieć żadnego rzeczywistego lub postrzeganego dostępu do Twoich sekretów lub kluczy.
Meetings
Szyfrowane spotkania typu end-to-end obsługują obecnie maksymalnie 200 uczestników.
Z tych 200 uczestników może dołączyć maksymalnie 25 zweryfikowanych zewnętrznie urządzeń i muszą to być pierwsi uczestnicy, którzy dołączą do spotkania.
Gdy większa liczba urządzeń dołącza do spotkania, nasze usługi multimedialne zaplecza próbują transkodować strumienie multimediów. Jeśli nie możemy odszyfrować, transkodować i ponownie zaszyfrować nośnika (ponieważ nie mamy i nie powinniśmy mieć kluczy szyfrowania urządzeń), transkodowanie nie powiedzie się.
Aby złagodzić to ograniczenie, zalecamy mniejsze spotkania dla urządzeń lub rozłożenie zaproszeń między urządzeniami a klientami aplikacji Spotkania.
Interfejs zarządzania
Zdecydowanie zalecamy używanie centrum sterowania do zarządzania witryną spotkania.
Głównym tego powodem jest różnica między sposobem, w jaki Control Hub i Administracja witryny zarządzają tożsamością. Organizacje Control Hub mają scentralizowaną tożsamość dla całej organizacji, podczas gdy w administracji lokacji tożsamość jest kontrolowana na podstawie poszczególnych witryn.
Oznacza to, że nie można mieć opcji tożsamości zweryfikowanej przez Cisco dla użytkowników, którzy są zarządzani z poziomu administracji witryny. Użytkownicy ci otrzymują anonimowy certyfikat, aby dołączyć do szyfrowanego spotkania end-to-end, i mogą zostać wykluczeni ze spotkań, na których gospodarz chce zapewnić tożsamość.
Informacje pokrewne
Zero-Trust Security for Webex (dokument techniczny dotyczący bezpieczeństwa): https://www.cisco.com/c/en/us/solutions/collateral/collaboration/white-paper-c11-744553.html
Prezentacja Cisco Live 2021 (wymagana jest rejestracja Cisco Live): https://www.ciscolive.com/2021/learn/session-catalog.html?tab.digitalbundle=Anytime21&search.sessiontype=BRK&search.learningmap=1614364767910003wzD6#/session/16106298425360015zrh
JSON Web Encryption (JWE) (projekt standardu IETF): https://datatracker.ietf.org/doc/html/rfc7516
Dokumentacja skierowana do użytkownika: https://help.webex.com/5h5d8ab
Wyprowadzanie przykładowych obiektów blob JWE
Próbka poprawnie zaszyfrowanego JWE na podstawie podanych parametrów (załącznik)
Spotkania Webex 41.7.
Zarejestrowane w chmurze urządzenia z serii Webex Room i Webex Desk, z systemem operacyjnym
10.6.1-RoomOS_August_2021.Dostęp administracyjny do witryny spotkania w centrum sterowania, aby włączyć nowy typ sesji dla użytkowników.
Co najmniej jedna zweryfikowana domena w organizacji Control Hub (jeśli używasz urzędu certyfikacji Webex do wystawiania certyfikatów urządzeń dla zweryfikowanej tożsamości).
Sale konferencyjne współpracy muszą być włączone, aby inne osoby mogły dołączać z poziomu systemu wideo. Aby uzyskać więcej informacji, zobacz Zezwalanie systemom wideo na dołączanie do spotkań i wydarzeń Webex w witrynieWebex.
Możesz pominąć ten krok, jeśli nie potrzebujesz zweryfikowanej zewnętrznie tożsamości.
Aby zapewnić najwyższy poziom bezpieczeństwa i weryfikację tożsamości, każde urządzenie powinno mieć unikatowy certyfikat wydany przez zaufany publiczny urząd certyfikacji.
Musisz wchodzić w interakcje z urzędem certyfikacji, aby żądać, kupować i odbierać certyfikaty cyfrowe oraz tworzyć skojarzone klucze prywatne. Podczas żądania certyfikatu należy użyć następujących parametrów:
Certyfikat musi być wystawiony i podpisany przez znany publiczny urząd certyfikacji.
Niepowtarzalny: Zdecydowanie zalecamy używanie 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 alternatywna nazwa/nazwy podmiotu (SAN/s): Nie są one ważne dla Webex, ale powinny być wartościami, które ludzie mogą odczytać i skojarzyć z urządzeniem. CN pokaże innym uczestnikom spotkania jako podstawową zweryfikowaną tożsamość urządzenia, a jeśli użytkownicy sprawdzą certyfikat za pośrednictwem interfejsu użytkownika spotkania, zobaczą sieć SAN. Możesz użyć nazw takich jak
name.model@example.comale to twój wybór.Format pliku: Certyfikaty i klucze muszą być w formacie .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 wykorzystujący krzywą P-256).
To wymaganie nie obejmuje klucza podpisywania. Urząd certyfikacji może podpisać certyfikat za pomocą klucza RSA.
Możesz pominąć ten krok, jeśli nie chcesz używać zweryfikowanej zewnętrznie tożsamości na swoich urządzeniach.
Jeśli korzystasz z nowych urządzeń, nie rejestruj ich jeszcze w Webex. Najbezpieczniej jest nawet nie podłączyć ich jeszcze do sieci.
Jeśli masz istniejące urządzenia, które chcesz uaktualnić, aby korzystały ze zweryfikowanej zewnętrznie tożsamości, musisz przywrócić ustawienia fabryczne urządzeń.
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 wpisy tajne są przesyłane w postaci zwykłego tekstu i narażasz swoje bezpieczeństwo.
Po wykonaniu tych kroków zezwól systemom wideo na dołączanie do spotkań i wydarzeń w witrynieWebex.
Aby mieć pewność, że nośnik urządzenia nie może zostać zaszyfrowany przez nikogo poza urządzeniem, należy 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 szyfrowania JSON Web Encryption (JWE).
Aby zapewnić prawdziwe szyfrowanie end-to-end za pośrednictwem naszej chmury, nie możemy być zaangażowani w szyfrowanie i przesyłanie certyfikatu i klucza. Jeśli potrzebujesz tego poziomu bezpieczeństwa, na Tobie spoczywa obowiązek:
Poproś o certyfikaty.
Generowanie par kluczy certyfikatów.
Utwórz (i chroń) początkowy klucz tajny dla każdego urządzenia, aby uruchomić funkcję szyfrowania urządzenia.
Opracuj i utrzymuj własne narzędzie do szyfrowania plików przy użyciu standardu JWE.
Poniżej wyjaśniamy proces i (nietajne) parametry, których będziesz potrzebować, oraz przepis do naśladowania w wybranych narzędziach programistycznych. Udostępniamy również niektóre dane testowe i wynikowe obiekty blob JWE zgodnie z naszymi 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 klucza tajnego urządzenia.
Przekaż wynikowy obiekt blob JWE do urządzenia.
Ustaw przeznaczenie zaszyfrowanego certyfikatu, który ma być używany do identyfikacji Webex, i aktywuj certyfikat.
(Zalecane) Zapewnij interfejs (lub rozpowszechnij) swoje narzędzie, aby umożliwić użytkownikom urządzeń zmianę początkowego klucza tajnego (aby chronić swoje multimedia przed Tobą!).
Jak korzystamy z formatu JWE
W tej sekcji opisano, w jaki sposób oczekujemy, że JWE zostanie utworzony jako dane wejściowe do urządzeń, dzięki czemu można zbudować własne narzędzie do tworzenia obiektów blob z certyfikatów i kluczy.
Musisz odwołać się do JSON Web Encryption (JWE)https://datatracker.ietf.org/doc/html/rfc7516 i JSON Web Signature (JWS)https://datatracker.ietf.org/doc/html/rfc7515.
Zdecydowaliśmy się użyć kompaktowej serializacji dokumentu JSON do utworzenia obiektów blob JWE. Parametry, które należy uwzględnić podczas tworzenia obiektów blob JWE, to:
Nagłówek JOSE (chroniony). W nagłówku JSON Object Signing and Encryption NALEŻY uwzględnić następujące pary klucz-wartość:
"alg":"dir"Algorytm bezpośredni jest jedynym obsługiwanym przez nas do szyfrowania ładunku i musisz użyć początkowego klucza tajnego klienta urządzenia.
"enc":"A128GCM"lub"enc":"A256GCM"Obsługujemy te dwa algorytmy szyfrowania.
"cisco-action": "add"lub"cisco-action": "populate"lub"cisco-action": "activate"lub"cisco-action": "deactivate"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. Nazwy wartości pochodzą od poleceń xAPI na urządzeniu, na którym są używane zaszyfrowane dane.
Nazwaliśmy go
cisco-actionw celu złagodzenia potencjalnych kolizji z przyszłymi rozszerzeniami JWE."cisco-kdf": { "version": "1", "salt": "base64URLEncodedRandom4+Bytes" }Kolejny zastrzeżony klucz. Używamy wartości, które podajesz jako dane wejściowe do wyprowadzania kluczy na urządzeniu. Ten
versionmusi być1(wersja naszej kluczowej funkcji wyprowadzania). Wartośćsaltmusi być sekwencją zakodowaną w adresie URL base64 o długości co najmniej 4 bajtów, którą należy wybrać losowo.
Zaszyfrowany klucz JWE. To pole jest puste. Urządzenie wywodzi go z początkowego
ClientSecret.Wektor inicjalizacji JWE. Musisz podać zakodowany wektor inicjalizacji base64url do odszyfrowania ładunku. IV MUSI być losową wartością 12 bajtów (używamy rodziny szyfrów AES-GCM, która wymaga, aby IV miał długość 12 bajtów).
JWE AAD (dodatkowe uwierzytelnione dane). To pole należy pominąć, ponieważ nie jest ono obsługiwane w serializacji kompaktowej.
JWE Szyfrogram: Jest to zaszyfrowany ładunek, który chcesz zachować w tajemnicy.
Ładunek MOŻE być pusty (na przykład, aby zresetować klucz tajny klienta, należy zastąpić go pustą wartością).
Istnieją różne typy ładunków, w zależności od tego, co próbujesz zrobić na urządzeniu. Różne polecenia xAPI oczekują różnych ładunków i należy określić przeznaczenie ładunku za pomocą
cisco-actionklucz, jak następuje:Z
"cisco-action":"populate"szyfrogram jest nowyClientSecretZ "
"cisco-action":"add"szyfrogram jest obiektem blob PEM zawierającym certyfikat i jego klucz prywatny (połączony)Z "
"cisco-action":"activate"szyfrogram to odcisk palca (szesnastkowa reprezentacja sha-1) certyfikatu, który aktywujemy w celu weryfikacji tożsamości urządzeniaZ "
"cisco-action":"deactivate"szyfrogram to odcisk palca (szesnastkowa reprezentacja sha-1) certyfikatu, który dezaktywujemy, aby nie był używany do weryfikacji tożsamości urządzenia
Tag uwierzytelniania JWE: To pole zawiera znacznik uwierzytelniania w celu ustalenia integralności całego kompaktowo serializowanego obiektu blob JWE
W jaki sposób uzyskujemy klucz szyfrowania z ClientSecret
Po pierwszym zaludnieniu tajemnicy nie akceptujemy ani nie wyprowadzamy sekretu 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 używa klucza tajnego klienta jako danych wejściowych do funkcji wyprowadzania klucza (kdf), a następnie używa klucza pochodnego do odszyfrowywania/szyfrowania zawartości na urządzeniu.
Oznacza to, że narzędzie do tworzenia obiektów blob JWE musi wykonać tę samą procedurę, aby uzyskać ten sam klucz szyfrowania/odszyfrowywania z klucza tajnego klienta.
Urządzenia używają scrypt do wyprowadzania klucza (patrz https://en.wikipedia.org/wiki/Scrypt), z następującymi parametrami:
CostFactor (N) jest 32768
BlockSizeFactor (r) jest 8
Współczynnik równoległości (p) wynosi 1
Sól jest losową sekwencją co najmniej 4 bajtów; musisz dostarczyć to samo
saltprzy określaniucisco-kdfparametr.Długości kluczy to 16 bajtów (w przypadku wybrania algorytmu AES-GCM 128) lub 32 bajty (w przypadku wybrania algorytmu AES-GCM 256).
Maksymalny limit pamięci to 64MB
Ten zestaw parametrów jest jedyną konfiguracją scrypt, która jest kompatybilna z funkcją wyprowadzania klucza na urządzeniach. Ten kdf na urządzeniach nazywa się "version":"1", która jest jedyną wersją obecnie przyjmowaną przez cisco-kdf parametr.
Przykład pracy
Oto przykład, który możesz wykonać, aby sprawdzić, czy proces szyfrowania JWE działa tak samo, jak proces, który utworzyliśmy na urządzeniach.
Przykładowym scenariuszem jest dodanie obiektu blob PEM do urządzenia (naśladuje dodawanie certyfikatu z bardzo krótkim ciągiem zamiast pełnego certyfikatu + klucza). Klucz tajny klienta w przykładzie to ossifrage.
Wybierz szyfr szyfrujący. W tym przykładzie użyto
A128GCM(AES ze 128-bitowymi w trybie licznika Galois). Twoje narzędzie może użyćA256GCMjeśli wolisz.Wybierz sól (musi to być losowa sekwencja co najmniej 4 bajtów). W tym przykładzie użyto (bajty szesnastkowe)
E5 E6 53 08 03 F8 33 F6. Base64url koduje sekwencję, aby uzyskać5eZTCAP4M_Y(zdejmij wyściółkę base64).Oto przykład
scryptwywołanie w celu utworzenia klucza szyfrowania treści (cek):cek=scrypt(password="ossifrage", salt=4-byte-sequence, N=32768, r=8, p=1, keylength=16)Klucz pochodny powinien mieć 16 bajtów (szesnastkowych) 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 dolZ66bdEiAQV4_mqdInj_rA.Wybierz losową sekwencję 12 bajtów, która ma być używana jako wektor inicjalizacji. W tym przykładzie użyto (szesnastkowego)
34 b3 5d dd 5f 53 7b af 2d 92 95 83który base64url koduje doNLNd3V9Te68tkpWD.Utwórz nagłówek JOSE z kompaktową serializacją (postępuj zgodnie z tą samą kolejnością parametrów, której używamy tutaj), a następnie zakoduj go base64url:
{"alg":"dir","cisco-action":"add","cisco-kdf":{"salt":"5eZTCAP4M_Y","version":"1"},"enc":"A128GCM"}Nagłówek JOSE zakodowany w formacie base64url to
eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9Będzie to pierwszy element obiektu blob JWE.
Drugi element obiektu blob JWE jest pusty, ponieważ nie dostarczamy klucza szyfrowania JWE.
Trzecim elementem obiektu blob JWE jest wektor inicjalizacji
NLNd3V9Te68tkpWD.- Użyj narzędzia szyfrującego JWE, aby utworzyć zaszyfrowany ładunek i tag. W tym przykładzie niezaszyfrowany ładunek będzie fałszywym obiektem blob PEM
this is a PEM fileParametry szyfrowania, których należy użyć, to:
Ładunek wynosi
this is a PEM fileSzyfrowanie szyfru to AES 128 GCM
Nagłówek JOSE zakodowany w base64url jako dodatkowe uwierzytelnione dane (AAD)
Base64url koduje zaszyfrowany ładunek, co powinno skutkować
f5lLVuWNfKfmzYCo1YJfODhQJest to czwarty element (JWE Ciphertext) w obiekcie blob JWE.
Base64url zakoduj znacznik utworzony w kroku 8, co powinno spowodować
PE-wDFWGXFFBeo928cfZ1QJest to piąty element w obiekcie blob JWE.
Połącz pięć elementów obiektu blob JWE z kropkami (JOSEheader.. IV.Ciphertext.Tag), aby uzyskać:
eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1QJeśli uzyskałeś te same wartości zakodowane w base64url, co pokazujemy tutaj, używając własnych narzędzi, jesteś gotowy do użycia ich do zabezpieczenia szyfrowania E2E i zweryfikowanej tożsamości swoich urządzeń.
Ten przykład w rzeczywistości nie zadziała, ale w zasadzie następnym krokiem byłoby użycie obiektu blob JWE utworzonego powyżej jako danych wejściowych do xcommand na urządzeniu, które dodaje certyfikat:
xCommand Security Certificates AddeyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q
Istnieją nowe typy sesji dla spotkań o zerowym zaufaniu, które będą dostępne dla wszystkich witryn spotkań bez dodatkowych kosztów. Jeden z nowych typów sesji nosi nazwę Pro-End to End Encryption_VOIPonly. Jest to nazwa usługi publicznej, którą możemy zmienić w przyszłości. Aby zapoznać się z bieżącymi nazwami typów sesji, zobacz Identyfikatory typów sesji w sekcji Informacje w tym artykule.
Nie musisz nic robić, aby uzyskać nową funkcję dla swojej witryny, ale musisz przyznać użytkownikom nowy typ sesji (zwany także uprawnieniem do spotkania). Można to zrobić indywidualnie za pośrednictwem strony konfiguracji użytkownika lub zbiorczo za pomocą eksportu/importu CSV.
| 1 | Zaloguj się do centrum sterowania i otwórz stronę Spotkanie. |
||
| 2 | Kliknij nazwę witryny, aby otworzyć panel konfiguracji witryny. |
||
| 3 | Kliknij przycisk Konfiguruj witrynę. |
||
| 4 | W obszarze Ustawienia wspólne kliknij pozycję Typy sesji. Na tej stronie powinien być widoczny co najmniej jeden typ sesji szyfrowania end-to-end. Zapoznaj się z listą identyfikatorów typów sesji w sekcji Informacje w tym artykule. Na przykład możesz zobaczyć Pro-End to End Encryption_VOIPonly.
|
||
| 5 | Jeśli nie masz jeszcze nowego typu sesji, skontaktuj się z przedstawicielem Webex. |
Co dalej?
Włącz ten typ sesji / uprawnienia do spotkania dla niektórych lub wszystkich użytkowników.
| 1 | Kliknij Użytkownicy i wybierz użytkownika, aby otworzyć panel konfiguracji użytkownika. |
| 2 | W obszarze Usługi kliknij pozycję Cisco Webex Meetings. |
| 3 | Wybierz witrynę (jeśli użytkownik jest w więcej niż jednej) i kliknij hostuj. |
| 4 | Zaznacz pole wyboru obok wpisu Webex Meetings oznaczonego Pro-End to End Encryption_VOIPonly. |
| 5 | Zamknij panel konfiguracji użytkownika. |
| 6 | W razie potrzeby powtórz tę czynność dla innych użytkowników. Jeśli chcesz przypisać to do wielu użytkowników, użyj opcji zbiorczej CSV. |
| 1 | Zaloguj się do centrum sterowania https://admin.webex.com i otwórz stronę Spotkanie. |
||
| 2 | Kliknij nazwę serwisu, aby otworzyć panel konfiguracji serwisu. |
||
| 3 | W sekcji Licencje i użytkownicy kliknij opcję Zarządzajzbiorczo. |
||
| 4 | Kliknij Eksportuj, i poczekaj, aż przygotujemy plik. |
||
| 5 | Gdy plik będzie gotowy, kliknij przycisk Eksportuj wyniki, a następnie Pobierz . (Musisz ręcznie zamknąć to wyskakujące okno po kliknięciu Pobierz.) |
||
| 6 | Otwórz pobrany plik CSV do edycji. Istnieje wiersz dla każdego użytkownika, a |
||
| 7 | Dla każdego użytkownika, któremu chcesz przyznać nowy typ sesji, dodaj Cisco Webex CSV File Format Reference zawiera szczegółowe informacje na temat celu i zawartości pliku CSV. |
||
| 8 | Otwórz panel konfiguracji witryny spotkania w centrum sterowania.
|
||
| 9 | W sekcji Licencje i użytkownicy kliknij pozycję Zarządzaj zbiorczo. |
||
| 10 | Kliknij w Importuj i wybierz edytowany plik CSV, a następnie kliknij w Importuj. Poczekaj, aż plik zostanie przesłany. |
||
| 11 | Po zakończeniu importowania można kliknąć przycisk Importuj wyniki, aby sprawdzić, czy wystąpiły błędy. |
||
| 12 | Przejdź do strony Użytkownicy i otwórz jednego z użytkowników, aby sprawdzić, czy mają nowy typ sesji. |
Jeśli Twoje urządzenia są już dołączone do organizacji Control Hub i chcesz użyć Urzędu Certyfikacji Webex do automatycznego generowania certyfikatów identyfikacyjnych, nie musisz przywracać ustawień fabrycznych urządzeń.
Ta procedura wybiera domenę używaną przez urządzenie do identyfikowania się i jest wymagana tylko wtedy, gdy w organizacji Control Hub jest 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 poinformujesz Webex, która domena identyfikuje urządzenie, wybierzemy jedną z nich i może to wyglądać źle dla innych uczestników spotkania.
Przed rozpoczęciem
Jeśli Twoje urządzenia nie są jeszcze dołączone, możesz śledzić opcję Zarejestruj urządzenie w Cisco Webex za pomocą interfejsu API lub lokalnego interfejsu internetowego lub dołączania do chmury dla urządzeń. Należy również zweryfikować domeny, których chcesz użyć do identyfikacji urządzeń w obszarze Zarządzanie urządzeniami.
| 1 | Zaloguj się do control hub (https://admin.webex.com) i otwórz stronę Urządzenia. |
| 2 | Wybierz urządzenie, aby otworzyć jego panel konfiguracyjny. |
| 3 | Wybierz domenę, której chcesz użyć do zidentyfikowania tego urządzenia. |
| 4 | Powtórz tę czynność dla innych urządzeń. |
Przed rozpoczęciem
Potrzebujesz:
Aby uzyskać certyfikat podpisany przez urząd certyfikacji i klucz prywatny w formacie .pem dla każdego urządzenia.
Aby przeczytać temat Opis procesu tożsamości zewnętrznej dla urządzeń, w części Przygotowywanie tego artykułu.
Przygotowanie narzędzia szyfrującego JWE w odniesieniu do zawartych tam informacji.
Narzędzie do generowania losowych sekwencji bajtów o danych długościach.
Narzędzie do kodowania bajtów lub tekstu base64url.
An
scryptimplementacja.Tajne słowo lub fraza dla każdego urządzenia.
| 1 | Wypełnij dane urządzenia Przy pierwszym wypełnieniu Urządzenie ma swój początkowy sekret. Nie zapomnij o tym, nie możesz go odzyskać i musisz przywrócić ustawienia fabryczne urządzenia, aby uruchomić je ponownie.
|
| 2 | Połącz certyfikat i klucz prywatny: |
| 3 | Utwórz obiekt blob JWE, który będzie używany jako dane wejściowe do polecenia dodawania certyfikatu: |
| 4 | Otwórz TShell na urządzeniu i uruchom polecenie (wielowierszowe) add: |
| 5 | Sprawdź, czy certyfikat został dodany, uruchamiając Skopiuj odcisk palca nowego certyfikatu. |
| 6 | Aktywuj certyfikat w tym celu Urządzenie posiada zaszyfrowany, aktywny certyfikat wydany przez urząd certyfikacji, gotowy do użycia do jego identyfikacji w szyfrowanych spotkaniach Webex end-to-end.
|
| 7 | Dołącz urządzenie do organizacji Control Hub. |
| 1 | Zaplanuj spotkanie właściwego typu (Webex Meetings Pro-End to End Encryption_VOIPonly). |
| 2 | Dołącz do spotkania jako gospodarz z klienta Webex Meetings. |
| 3 | Dołącz do spotkania z urządzenia, którego tożsamość została zweryfikowana przez urząd certyfikacji Webex. |
| 4 | Jako host sprawdź, czy to urządzenie jest wyświetlane w poczekalni z poprawną ikoną tożsamości. |
| 5 | Dołącz do spotkania z urządzenia, którego tożsamość została zweryfikowana przez zewnętrzny urząd certyfikacji. |
| 6 | Jako host sprawdź, czy to urządzenie jest wyświetlane w poczekalni z poprawną ikoną tożsamości. Dowiedz się więcej o ikonach tożsamości. |
| 7 | Dołącz do spotkania jako nieuwierzytelniony uczestnik spotkania. |
| 8 | Jako gospodarz sprawdź, czy ten uczestnik pojawia się w lobby z poprawną ikoną tożsamości. |
| 9 | Jako gospodarz dopuszczaj lub odrzucaj osoby / urządzenia. |
| 10 | W miarę możliwości weryfikuj tożsamość uczestnika/urządzenia, sprawdzając certyfikaty. |
| 11 | Sprawdź, czy wszyscy uczestnicy spotkania widzą ten sam kod zabezpieczający spotkania. |
| 12 | Dołącz do spotkania z nowym uczestnikiem. |
| 13 | Sprawdź, czy wszyscy widzą ten sam, nowy kod zabezpieczający spotkania. |
Czy zamierzasz uczynić szyfrowane spotkania end-to-end domyślną opcją spotkania, czy włączyć ją tylko dla niektórych użytkowników, lub pozwolić wszystkim hostom decydować? Kiedy już zdecydujesz, w jaki sposób zamierzasz korzystać z tej funkcji, przygotuj tych użytkowników, którzy będą z niej korzystać, szczególnie w odniesieniu do ograniczeń i tego, czego możesz się spodziewać na spotkaniu.
Czy musisz upewnić się, że ani Cisco, ani nikt inny nie może odszyfrować Twojej zawartości ani podszyć się pod Twoje urządzenia? Jeśli tak, potrzebne są certyfikaty z publicznego urzędu certyfikacji. Możesz mieć tylko do 25 urządzeń na bezpiecznym spotkaniu. Jeśli potrzebny jest ten poziom zabezpieczeń, nie należy zezwalać klientom na dołączanie do spotkań.
W przypadku użytkowników, którzy dołączają za pomocą bezpiecznych urządzeń, pozwól urządzeniom dołączyć jako pierwsze i ustaw oczekiwania użytkowników, że mogą nie być w stanie dołączyć, jeśli dołączą późno.
Jeśli masz różne poziomy weryfikacji tożsamości, upoważnij użytkowników do wzajemnego weryfikowania tożsamości za pomocą tożsamości popartej certyfikatem i kodu zabezpieczeń spotkania. Mimo że istnieją okoliczności, w których uczestnicy mogą pojawiać się jako niezweryfikowani, a uczestnicy powinni wiedzieć, jak to sprawdzić, niezweryfikowane osoby mogą nie być oszustami.
Jeśli do wystawiania certyfikatów urządzeń jest używany zewnętrzny urząd certyfikacji, to na Tobie spoczywa obowiązek monitorowania, odświeżania i ponownego stosowania certyfikatów.
Jeśli początkowy klucz tajny został utworzony, zrozum, że użytkownicy mogą chcieć zmienić klucz tajny urządzenia. Może być konieczne utworzenie interfejsu/dystrybucji narzędzia, aby umożliwić im to.
Wkrótce.
Identyfikator typu sesji |
Nazwa usługi publicznej |
|---|---|
638 |
Tylko szyfrowanie E2E + VoIP |
652 |
Pro-End to End Encryption_VOIPonly |
660 |
Pro 3 Free-End to End Encryption_VOIPonly Szyfrowanie E2E + tożsamość |
672 |
Pro 3 Free50-End to End Encryption_VOIPonly |
673 |
Instruktor edukacji E2E Encryption_VOIPonly |
676 |
Broadworks Standard plus szyfrowanie end-to-end |
677 |
Broadworks Premium plus szyfrowanie end-to-end |
681 |
Schoology Free plus szyfrowanie end-to-end |
Te tabele opisują polecenia interfejsu API urządzeń Webex, które dodaliśmy dla szyfrowanych spotkań end-to-end i zweryfikowanej tożsamości. Aby uzyskać więcej informacji na temat korzystania z interfejsu API, zobacz Uzyskiwanie dostępu do interfejsu API dla urządzeń Webex Room i Desk oraz tablic Webex.
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ą Webex Edge for Devices
Wywołanie interfejsu API |
Opis |
|---|---|
|
Ta konfiguracja jest tworzona, gdy administrator ustawia preferowaną domenę urządzenia z Control Hub. Jest to konieczne tylko wtedy, gdy organizacja ma więcej niż jedną domenę. Urządzenie używa tej domeny, gdy żąda certyfikatu od urzędu certyfikacji Webex. Następnie domena identyfikuje urządzenie. Ta konfiguracja nie ma zastosowania, gdy urządzenie ma aktywny, wystawiony zewnętrznie certyfikat do identyfikacji. |
|
Wskazuje, czy urządzenie może dołączyć do szyfrowanego spotkania end-to-end. Interfejs API chmury wywołuje go, aby sparowana aplikacja wiedziała, czy może użyć urządzenia do dołączenia. |
|
Wskazuje, czy urządzenie używa |
|
Tożsamość urządzenia odczytana z nazwy pospolitej certyfikatu wystawionego zewnętrznie. |
|
Odczytuje określone informacje z certyfikatu wystawionego zewnętrznie. W wyświetlonym poleceniu zamień
|
|
Stan zewnętrznej tożsamości urządzenia (np. |
|
Wskazuje, czy urządzenie ma prawidłowy certyfikat wystawiony przez urząd certyfikacji Webex. |
|
Tożsamość urządzenia odczytana z nazwy pospolitej certyfikatu wydanego przez Webex. Zawiera nazwę domeny, jeśli organizacja ma 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 określone informacje z certyfikatu wydanego przez Webex. W wyświetlonym poleceniu zamień
|
Wywołanie interfejsu API |
Opis |
|---|---|
|
Te trzy wydarzenia obejmują teraz |
Wywołanie interfejsu API |
Opis |
|---|---|
lub
|
Akceptuje zakodowaną w formacie base64url wartość zwykłego tekstu do rozsyłania klucza tajnego klienta na urządzeniu po raz pierwszy. Aby zaktualizować klucz tajny po tym pierwszym raz, należy podać obiekt blob JWE zawierający nowy klucz tajny zaszyfrowany przez stary klucz tajny. |
|
Dodaje certyfikat (z kluczem prywatnym). Rozszerzyliśmy to polecenie, aby zaakceptować obiekt blob JWE zawierający zaszyfrowane dane PEM. |
|
Aktywuje określony certyfikat dla WebexIdentity. W tym celu |
|
Dezaktywuje określony certyfikat dla WebexIdentity. W tym celu |
