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:

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 hasła.

    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 są w gestii 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 tajnego klienta jest używana do szyfrowania i podpisywania różnych xcommandów.

Podczas korzystania z tajemnicy 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.7 klient stacjonarny Webex Meetings może dołączać do szyfrowanych spotkań end-to-end.

  • Aplikacja Webex nie 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 pomogłyby 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 lokalizacji po lokacji.

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

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 operacyjnego 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).

Możesz pominąć ten krok, jeśli nie potrzebujesz zweryfikowanej zewnętrznie tożsamości.

Aby uzyskać najwyższy poziom bezpieczeństwa i weryfikacji 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ą sanki. Możesz użyć nazw takich jak name.model@example.com ale 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ą przekazywane w postaci zwykłego tekstu i narażasz swoje bezpieczeństwo.

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 zależy, czy:

  • Poproś o certyfikaty.

  • Generowanie par kluczy certyfikatów.

  • Utwórz (i chroń) początkowy klucz tajny dla każdego urządzenia, aby zainicjować możliwości 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 oczekiwaniami, aby pomóc Ci zweryfikować proces.

    Nieobsługiwana implementacja referencyjna wykorzystująca Python3 i bibliotekę JWCrypto jest dostępna w Cisco na żądanie.

  • Złą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 hasła (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 sekretu 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-action w 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 version musi być 1(wersja naszej kluczowej funkcji wyprowadzania). Wartość salt musi być sekwencją zakodowaną w adresie URL base64 o rozmiarze 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 było długie na 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-action klucz, jak następuje:

    • Z "cisco-action":"populate" szyfrogram jest nowy ClientSecret

    • Z " "cisco-action":"add" szyfrogram jest obiektem blob PEM przenoszącym certyfikat i jego klucz prywatny (w zestawieniu)

    • Z " "cisco-action":"activate" szyfrogram to odcisk palca (szesnastkowa reprezentacja sha-1) certyfikatu, który aktywujemy w celu weryfikacji tożsamości urządzenia

    • Z " "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

  • ParallelizationFactor (p) wynosi 1

  • Sól jest losową sekwencją co najmniej 4 bajtów; musisz dostarczyć to samo salt przy określaniu cisco-kdf parametr.

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

  1. 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ć A256GCM jeśli wolisz.

  2. 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).

  3. Oto przykład scrypt wywoł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 (szesnastek) w następujący sposób: 95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac który base64url koduje do lZ66bdEiAQV4_mqdInj_rA.

  4. 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 83 który base64url koduje do NLNd3V9Te68tkpWD.

  5. 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 eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

    Będzie to pierwszy element obiektu blob JWE.

  6. Drugi element obiektu blob JWE jest pusty, ponieważ nie dostarczamy klucza szyfrowania JWE.

  7. Trzecim elementem obiektu blob JWE jest wektor inicjalizacji NLNd3V9Te68tkpWD.

  8. 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 file

    Parametry szyfrowania, których należy użyć, to:

    • Ładunek wynosi this is a PEM file

    • Szyfrowanie szyfru to AES 128 GCM

    • Nagłówek JOSE zakodowany w base64url jako dodatkowe uwierzytelnione dane (AAD)

    Base64url koduje zaszyfrowany ładunek, co powinno skutkować f5lLVuWNfKfmzYCo1YJfODhQ

    Jest to czwarty element (JWE Ciphertext) w kolabie JWE.

  9. Base64url zakoduj znacznik wygenerowany w kroku 8, co powinno spowodować PE-wDFWGXFFBeo928cfZ1Q

    Jest to piąty element w blob JWE.

  10. Łączenie pięciu elementów obiektu blob JWE z kropkami (JOSEheader.. IV.Ciphertext.Tag), aby uzyskać:

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

  11. Jeśli wyprowadził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ń.

  12. 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 Add eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

Istnieją nowe typy sesji dla spotkań o zerowym zaufaniu, które wprowadzamy we wszystkich witrynach 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żesz to zrobić indywidualnie za pośrednictwem strony konfiguracji użytkownika lub zbiorczo za pomocą eksportu / importu CSV w obie strony.

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ć wyświetlony 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że zostać wyświetlony pro-end to end Encryption_VOIPonly.

 

Istnieje starszy typ sesji o bardzo podobnej nazwie: Szyfrowanie Pro-End to End. Ten typ sesji obejmuje nieszyfrowy dostęp PSTN do spotkań. Upewnij się, że masz wersję _VOIPonly, aby zapewnić szyfrowanie end-to-end. Możesz to sprawdzić, najeżdżając kursorem na link PRO w kolumnie kodu sesji; w tym przykładzie celem łącza powinno być javascript:ShowFeature(652).

W przyszłości możemy zmienić nazwy usług publicznych dla tych typów sesji, na przykład planujemy zmienić Pro-End na End Encryption_VOIPonly na E2E Encryption + Identity.

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 MeetingPrivilege zawiera identyfikatory typów sesji jako listę rozdzielaną przecinkami.

7

Dla każdego użytkownika, który chcesz przyznać nowy typ sesji, dodaj 1561 jako nowa wartość na liście rozdzielanej przecinkami w MeetingPrivilege komórka.

Odniesienie do formatu pliku CSV zawiera https://help.webex.com/en-us/5vox83 szczegółowe informacje na temat celu i zawartości pliku CSV.

8

Otwórz panel konfiguracji witryny spotkania w centrum sterowania.

Jeśli byłeś już na stronie listy Witryna spotkania, może być konieczne jej odświeżenie.

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ż prześlemy plik.

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ż włączone do organizacji Control Hub i chcesz użyć Webex CA do automatycznego generowania certyfikatów identyfikacyjnych, nie musisz przywracać ustawień fabrycznych urządzeń.

Ta procedura wybiera domenę używającą urządzenia 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 włączone, możesz obserwować https://help.webex.com/n25jyr8 lub https://help.webex.com/nutc0dy. Należy również zweryfikować domenę,domeny, której chcesz użyć do identyfikacji urządzeń (https://help.webex.com/cd6d84).

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 informacji tam.

  • Narzędzie do generowania losowych sekwencji bajtów o danych długościach.

  • Narzędzie do kodowania bajtów lub tekstu base64url.

  • An scrypt implementacja.

  • Tajne słowo lub fraza dla każdego urządzenia.

1

Wypełnij dane urządzenia ClientSecret z kluczem tajnym w postaci zwykłego tekstu:

Przy pierwszym wypełniniu Secret, podajesz go w postaci zwykłego tekstu. Dlatego zalecamy zrobienie tego na fizycznej konsoli urządzenia.

  1. Base64url koduje tajną frazę dla tego urządzenia.

  2. Otwórz TShell na urządzeniu.

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

    Powyższe przykładowe polecenie wypełnia Secret z frazą 0123456789abcdef. Musisz wybrać własny.

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

Łączenie certyfikatu i klucza prywatnego:

  1. Za pomocą edytora tekstu otwórz pliki pem, wklej kluczowy obiekt blob obiektu blob certyfikatu i zapisz go jako nowy plik pem.

    (Jest to tekst ładunku, który zaszyfrujesz i umieścisz w swoim blob JWE)

3

Utwórz obiekt blob JWE, który będzie używany jako dane wejściowe do polecenia dodawania certyfikatu:

  1. Utwórz losową sekwencję co najmniej 4 bajtów. To jest twoja sól.

  2. Wyjmij klucz szyfrowania zawartości za pomocą narzędzia szyfrującego.

    Do tego potrzebny jest sekret, sól i długość klucza, aby dopasować wybrany szyfr szyfrujący. Istnieje kilka innych stałych wartości do dostarczenia (N = 32768, r = 8, p = 1). Urządzenie używa tego samego procesu i wartości do uzyskania tego samego klucza szyfrowania treści.

  3. Utwórz losową sekwencję dokładnie 12 bajtów. To jest wektor inicjalizacji.

  4. Tworzenie nagłówka JOSE, ustawienie alg, enc i cisco-kdf zgodnie z opisem w temacie Opis procesu tożsamości zewnętrznej dla urządzeń. Ustaw akcję "dodaj" za pomocą klucza:wartość "cisco-action":"add" w nagłówku JOSE (ponieważ dodajemy certyfikat do urządzenia).

  5. Base64url koduje nagłówek JOSE.

  6. Użyj narzędzia szyfrującego JWE z wybranym szyfrem i zakodowanym w base64url nagłówkiem JOSE, aby zaszyfrować tekst ze połączonego pliku pem.

  7. Base64url koduje wektor inicjalizacji, zaszyfrowany ładunek PEM i znacznik uwierzytelniania.

  8. Skonstruuj obiekt blob JWE w następujący sposób (wszystkie wartości są zakodowane w base64url):

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4

Otwórz TShell na urządzeniu i uruchom polecenie (wielowierszowe) add:

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

Sprawdź, czy certyfikat został dodany, uruchamiając xcommand Security Certificates Services Show

Skopiuj odcisk palca nowego certyfikatu.

6

Aktywuj certyfikat w tym celu WebexIdentity:

  1. Odczytaj odcisk palca certyfikatu, albo z samego certyfikatu, albo z danych wyjściowych xcommand Security Certificates Services Show.

  2. Utwórz losową sekwencję co najmniej 4 bajtów, a base64url zakoduj tę sekwencję. To jest twoja sól.

  3. Wyjmij klucz szyfrowania zawartości za pomocą narzędzia szyfrującego.

    Do tego potrzebny jest sekret, sól i długość klucza, aby dopasować wybrany szyfr szyfrujący. Istnieje kilka innych stałych wartości do dostarczenia (N = 32768, r = 8, p = 1). Urządzenie używa tego samego procesu i wartości do uzyskania tego samego klucza szyfrowania treści.

  4. Utwórz losową sekwencję o dokładnie 12 bajtach i base64url zakoduj tę sekwencję. To jest wektor inicjalizacji.

  5. Tworzenie nagłówka JOSE, ustawienie alg, enc i cisco-kdf zgodnie z opisem w temacie Opis procesu tożsamości zewnętrznej dla urządzeń. Ustaw akcję "aktywuj" za pomocą klucza:wartość "cisco-action":"activate" w nagłówku JOSE (ponieważ aktywujemy certyfikat na urządzeniu).

  6. Base64url koduje nagłówek JOSE.

  7. Użyj narzędzia szyfrującego JWE z wybranym szyfrem i zakodowanym w base64url nagłówkiem JOSE, aby zaszyfrować odcisk palca certyfikatu.

    Narzędzie powinno wyprowadzać sekwencję 16 lub 32 bajtów, w zależności od tego, czy wybrano 128 czy 256-bitowy AES-GCM, oraz tag uwierzytelniania.

  8. Base64urkoduj zaszyfrowany odcisk palca i znacznik uwierzytelniania.

  9. Skonstruuj obiekt blob JWE w następujący sposób (wszystkie wartości są zakodowane w base64url):

    JOSEHeader..InitVector.EncryptedFingerprint.AuthTag

  10. Otwórz TShell na urządzeniu i uruchom następujące polecenie aktywacji:

    xcommand Security Certificates Services Activate Purpose: WebexIdentity Fingerprint: "Your..JWE.encrypted.fingerprint"
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

Podłą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.

7

Dołącz do spotkania jako nieuwierzytywiony 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 na spotkaniu 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 zależy, czy będziesz monitorować, odświeżać i ponownie stosować certyfikaty.

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.

Tabela 1. Identyfikatory typów sesji dla kompleksowych zaszyfrowanych spotkań

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 dowiedzieć się więcej o korzystaniu z interfejsu API, zobacz https://help.webex.com/nzwo1ok.

Tabela 2. Interfejsy API na poziomie systemu do kompleksowego szyfrowania spotkań i zweryfikowanej tożsamości

Wywołanie interfejsu API

Opis

xConfiguration Conference EndToEndEncryption Mode: On

Obraca tryb szyfrowania od końca do końca On lub Off.

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

Ta konfiguracja jest dokonywana, 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.

xStatus Conference EndToEndEncryption Availability

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.

xStatus Conference EndToEndEncryption ExternalIdentity Valid

Wskazuje, czy urządzenie ma ważny certyfikat wystawiony zewnętrznie.

xStatus Conference EndToEndEncryption ExternalIdentity Identity

Tożsamość urządzenia odczytana z nazwy pospolitej certyfikatu wystawionego zewnętrznie.

xStatus Conference EndToEndEncryption ExternalIdentity CertInfo

Odczytuje informacje o certyfikacie z certyfikatu wystawionego zewnętrznie i wyprowadza je jako obiekt blob JSON.

xStatus Conference EndToEndEncryption InternalIdentity Valid

Wskazuje, czy urządzenie ma prawidłowy certyfikat wystawiony przez urząd certyfikacji Webex.

xStatus Conference EndToEndEncryption InternalIdentity Identity

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

xStatus Conference EndToEndEncryption InternalIdentity CertInfo

Odczytuje informacje o certyfikacie z certyfikatu wystawionego przez Webex i wyprowadza je jako obiekt blob JSON.

Tabela 3. Interfejsy API w połączeniu dla kompleksowych zaszyfrowanych spotkań i zweryfikowanej tożsamości

Wywołanie interfejsu API

Opis

xStatus Call # ServerEncryption Type

Odczytuje szyfr szyfrujący używany w połączeniu HTTPS z Webex. Jest to wyświetlane użytkownikowi.

xStatus Conference Call # EndToEndEncryption Status

Odczytuje stan szyfrowania end-to-end wywołań. Wyświetlane użytkownikowi jako obecność (lub brak) ikony kłódki.

xStatus Conference Call # EndToEndEncryption SecurityCode

Odczytuje kod zabezpieczający spotkania. Jest ona wyświetlana użytkownikowi i zmienia się wraz z dołączeniem uczestników.

xStatus Conference Call # EndToEndEncryption MediaEncryption Type

Odczytuje szyfr szyfrowania używany w połączeniu nośnika. Jest to wyświetlane użytkownikowi.

xStatus Conference Call # EndToEndEncryption GroupEncryption Type

Odczytuje szyfr szyfrowania używany w aplikacji Messaging Layer Security (MLS).

xStatus Conference Call # EndToEndEncryption Roster Participant

Lista uczestników przyczyniających się do stanu grupy MLS na tym spotkaniu. Lista jest odkrywana przez MLS, a nie Webex.

xStatus Conference Call # EndToEndEncryption Roster Participant # Id

Adres URL WDM określonego uczestnika.

xStatus Conference Call # EndToEndEncryption Roster Participant # Status:

Status weryfikacji określonego uczestnika.

xStatus Conference Call # EndToEndEncryption Roster Participant # Identity:

Podstawowa tożsamość określonego uczestnika, zazwyczaj domena (urządzenie) lub adres e-mail (użytkownik).

xStatus Conference Call # EndToEndEncryption Roster Participant # DisplayName:

Nazwa wyświetlana określonego uczestnika. Podpisane przez uczestnika/urządzenie.

xStatus Conference Call # EndToEndEncryption Roster Participant # CertInfo:

Informacje o certyfikacie z certyfikatu określonego uczestnika jako obiekt blob JSON.

xCommand Conference ParticipantList Search

Rozszerzyliśmy to polecenie o informacje o szyfrowaniu end-to-end dla uczestników.

xCommand Conference ParticipantList Search

Wyszukiwanie na liście uczestników obejmuje teraz EndToEndEncryptionStatus, status weryfikacji tożsamości uczestnika. Ta wartość jest wyświetlana w widać w wirze użytkownika.

xCommand Conference ParticipantList Search

Wyszukiwanie na liście uczestników obejmuje teraz EndToEndEncryptionIdentity, podstawowa tożsamość uczestnika. Zazwyczaj jest to domena lub adres e-mail. Ta wartość jest wyświetlana w widać w wirze użytkownika.

xCommand Conference ParticipantList Search

Wyszukiwanie na liście uczestników obejmuje teraz EndToEndEncryptionCertInfo, obiekt blob JSON zawierający certyfikat uczestnika. Ta wartość jest wyświetlana w widać w wirze użytkownika.

xEvent Conference ParticipantList Participant(Added)

xEvent Conference ParticipantList Participant(Updated)

xEvent Conference ParticipantList Participant(Deleted)

Te trzy wydarzenia obejmują teraz EndToEndEncryptionStatus, EndToEndEncryptionIdentity i EndToEndEncryptionCertInfo dla uczestnika, którego to dotyczy.

Tabela 4. Interfejsy API związane z ClientSecret dla kompleksowych zaszyfrowanych spotkań i zweryfikowanej tożsamości

Wywołanie interfejsu API

Opis

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

Akceptuje zakodowaną w formacie base64url wartość zwykłego tekstu do rozsyłania hasła 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.

xCommand Security Certificates Services Add JWEblob

Dodaje certyfikat (z kluczem prywatnym).

Rozszerzyliśmy to polecenie, aby zaakceptować obiekt blob JWE zawierający zaszyfrowane dane PEM.

xCommand Security Certificates Services Activate Purpose:WebexIdentity FingerPrint: JWEblob

Aktywuje określony certyfikat dla WebexIdentity. W tym celu Purpose, polecenie wymaga, aby identyfikujący odcisk palca był zaszyfrowany i serializowany w obiektach blob JWE.

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

Dezaktywuje określony certyfikat dla WebexIdentity. W tym celu Purpose, polecenie wymaga, aby identyfikujący odcisk palca był zaszyfrowany i serializowany w obiektach blob JWE.