Doświadczenie użytkownika

Użytkownicy wybierają typ spotkania podczas planowania spotkania. Przy przyjmowaniu uczestników z poczekalni, jak również podczas spotkania, prowadzący 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, za pomocą którego mogą oni sprawdzić, czy ich spotkanie nie zostało przechwycone przez niechcianą osobę trzecią Meddler W Środku (MITM) ataku.

Udostępnij gospodarzom spotkania następujące informacje:

Weryfikacja tożsamości z wewnętrznym lub zewnętrznym CA

Zweryfikuj tożsamość

Szyfrowanie kompleksowe z weryfikacją tożsamości zapewnia dodatkowe bezpieczeństwo dla spotkania szyfrowanego kompleksowo.

Gdy uczestnicy lub urządzenia dołączają do wspólnej grupy MLS (Messaging Layer Security), przedstawiają swoje certyfikaty pozostałym członkom grupy, którzy następnie weryfikują certyfikaty w stosunku do wydających organów 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 uwierzytelniają się w sklepie tożsamości Webex, który wydaje im token dostępu po pomyślnym uwierzytelnieniu. Jeśli urząd certyfikacji Webex potrzebuje certyfikatu, aby zweryfikować swoją tożsamość podczas spotkania szyfrowanego kompleksowo, wydaje im certyfikat na podstawie tokenu dostępu. W tym momencie nie zapewniamy użytkownikom Webex Meetings możliwości uzyskania certyfikatu wydanego przez 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:

  • Wewnętrzny urząd certyfikacji — Webex wydaje certyfikat wewnętrzny na podstawie tokena dostępu do konta maszyny 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 Twojej organizacji podczas pisania tożsamości certyfikatu urządzenia (Common Name (CN)).

  • Zewnętrzny urząd certyfikacji — żądania i zakup certyfikatów urządzeń bezpośrednio od wybranego emitenta. Certyfikaty należy szyfrować, przesyłać bezpośrednio i autoryzować przy użyciu znanego tylko Użytkownikowi wpisu tajnego.

    Firma Cisco nie uczestniczy w tym procesie, co sprawia, że jest to sposób na zagwarantowanie prawdziwego kompleksowego szyfrowania i zweryfikowanej tożsamości oraz zapobieganie teoretycznej możliwości podsłuchiwania przez firmę Cisco spotkania/odszyfrowania multimediów.

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żna również użyć 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 wspólna (CN) i nazwa alternatywna podmiotu (SAN) będą wyświetlane w interfejsie użytkownika spotkania Webex zgodnie z opisem w szyfrowaniu kompleksowym z weryfikacją tożsamości dla 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ć certyfikat zewnętrzny przed manipulacją, funkcja klucza tajnego klienta jest używana do szyfrowania i podpisywania różnych poleceń xcommand.

Korzystając z sekretu klienta, można bezpiecznie zarządzać zewnętrznym certyfikatem tożsamości Webex za pośrednictwem interfejsu xAPI. Jest to obecnie ograniczone do urządzeń online.

Webex udostępnia obecnie polecenia API do zarządzania tym.

Funkcje i ograniczenia

Urządzenia

Do spotkań E2EE mogą dołączyć następujące zarejestrowane w chmurze urządzenia z serii Webex Room i Webex Desk:

  • 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 spotkań E2EE:

  • Seria Webex C

  • Seria Webex DX

  • Seria Webex EX

  • Seria Webex MX

  • Urządzenia SIP innych firm

Klienci oprogramowania

  • Aplikacja Webex dla klientów stacjonarnych i mobilnych może dołączać do spotkań E2EE.

  • Klient sieciowy Webex nie może dołączyć do spotkań E2EE.

  • Klienci miękcy SIP innych firm nie mogą dołączać do spotkań E2EE.

tożsamość

  • W projekcie nie udostępniamy opcji Control Hub do zarządzania zewnętrznie zweryfikowaną tożsamością urządzenia. Aby uzyskać prawdziwe szyfrowanie kompleksowe, należy 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ą one przechwycone.

  • Obecnie zapewniamy „przepis” na zaprojektowanie własnych narzędzi, w oparciu o standardowe w branży techniki 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.

Meetings

  • Obecnie spotkania E2EE obsługują maksymalnie 1000 uczestników.

  • Nowe tablice można udostępniać podczas spotkań E2EE. Istnieją pewne różnice między tablicami podczas regularnych spotkań:
    • Podczas spotkań E2EE użytkownicy nie mogą uzyskać dostępu do tablic utworzonych poza spotkaniem, w tym prywatnych tablic, tablic udostępnianych przez inne osoby oraz tablic z obszarów Webex.
    • Tablice utworzone w 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 zawartość na spotkaniu E2EE, możesz dodać adnotację. Aby uzyskać więcej informacji na temat adnotacji, zobacz Aplikacja Webex | Oznacz udostępnioną zawartość za pomocą adnotacji.

Interfejs zarządzania

Gorąco zalecamy korzystanie z Control Hub do zarządzania witryną Meetings, ponieważ organizacje Control Hub mają scentralizowaną tożsamość dla całej organizacji.

Dodatkowe zasoby
Warunki wstępne

  • Spotkania Webex 41.7.

  • Urządzenia Webex Room i Webex Desk zarejestrowane w chmurze, z systemem 10.6.1-RoomOS_August_2021.

  • Dostęp administracyjny do witryny spotkania w Control Hub.

  • 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 Zezwalaj systemom wideo na dołączanie do spotkań i wydarzeń w witrynie Webex.

Uzyskiwanie certyfikatów urządzenia

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

W celu zapewnienia najwyższego poziomu bezpieczeństwa i weryfikacji tożsamości każde urządzenie powinno posiadać 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żna użyć nazw takich jak name.model@example.com.

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

Przygotuj się na włączenie urządzeń

Możesz pominąć ten krok, jeśli nie chcesz używać zweryfikowanej na zewnątrz tożsamości z urządzeniami.

Jeśli korzystasz z nowych urządzeń, nie rejestruj ich jeszcze w Webex. Aby być bezpiecznym, nie podłączaj ich w tym momencie do sieci.

Jeśli masz istniejące urządzenia, które chcesz uaktualnić, aby używać zweryfikowanej tożsamości zewnętrznej, musisz fabrycznie zresetować urządzenia.

  • Jeśli chcesz ją zachować, zapisz istniejącą konfigurację.

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

Zrozumieć proces zewnętrznej tożsamości urządzeń

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 szyfrowanym kluczem i certyfikatem za pomocą 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, musisz:

  1. Poproś o certyfikaty.

  2. Generowanie par kluczy certyfikatów.

  3. Utwórz (i chroń) początkowy klucz tajny dla każdego urządzenia, aby uruchomić funkcję szyfrowania urządzenia.

  4. Opracuj i utrzymuj własne narzędzie do szyfrowania plików przy użyciu standardu JWE.

    Proces i (nietajne) parametry, których potrzebujesz, wyjaśniono poniżej, a także przepis, który należy zastosować w wybranych narzędziach rozwojowych. 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.

  5. Połącz i zaszyfruj certyfikat i klucz za pomocą narzędzia i początkowego klucza tajnego urządzenia.

  6. Przekaż wynikowy obiekt blob JWE do urządzenia.

  7. Ustaw przeznaczenie zaszyfrowanego certyfikatu, który ma być używany do identyfikacji Webex, i aktywuj certyfikat.

  8. (Zalecane) Zapewnij interfejs do (lub rozpowszechnij) narzędzia, aby umożliwić użytkownikom urządzenia zmianę początkowego sekretu i chronić swoje media 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.

Zapoznaj się z szyfrowaniem internetowym JSON (JWE) https://datatracker.ietf.org/doc/html/rfc7516 i podpisem internetowym JSON (JWS) https://datatracker.ietf.org/doc/html/rfc7515.

Używamy Compact Serialization dokumentu JSON do tworzenia plam JWE. Parametry, które należy uwzględnić podczas tworzenia migawek 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":"A GCM"

      Obsługujemy te dwa algorytmy szyfrowania.

    • "cisco-action": "add" or "cisco-action": "populate" or "cisco-action": "activate" or "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. Nazwy wartości pochodzą od poleceń xAPI na urządzeniu, na którym są używane zaszyfrowane dane.

      Nazwaliśmy to cisco-action , aby złagodzić potencjalne starcia z przyszłymi przedłużeniami JWE.

    • "cisco-kdf": {"wersja": "1", "sól": "base64URLEncodedRandom4+Bytes" }

      Kolejny zastrzeżony klucz. Używamy wartości, które podajesz jako dane wejściowe do wyprowadzania kluczy na urządzeniu. Wersja musi być 1 (wersja naszej kluczowej funkcji nadawania). Wartość soli musi być sekwencją zawierającą adres URL bazy64 o długości co najmniej 4 bajtów, którą należy wybrać losowo.

  • Klucz Zaszyfrowany JWE. To pole jest puste. Urządzenie wywodzi się z początkowego ClientSecret.

  • JWE Initialization Vector. 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 Ciphertext: Jest to zaszyfrowany ładunek, który chcesz zachować w tajemnicy.

    Ładowność MOŻE być pusta. Na przykład, aby zresetować klucz tajny klienta, należy nadpisać 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 obciążeń i należy określić cel ładunku za pomocą klucza cisco-action , w następujący sposób:

    • Z "cisco-action":"populate" szyfr jest nowy ClientSecret.

    • Z ""cisco-action":"add" szyfr jest blob PEM z certyfikatem i jego klucz prywatny (koncatenated).

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

    • W przypadku ""cisco-action":"dezaktywuj" tekst szyfrowania to odcisk palca (reprezentacja szesnastkowa sha-1) certyfikatu, który dezaktywujemy z którego jest 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 wywodzimy 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; trzeba dostarczyć tę samą sól podczas określania parametru cisco-kdf .

  • 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 nazywany jest "wersją":"1", która jest jedyną wersją aktualnie przyjętą przez parametr cisco-kdf .

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). Tajemnicą klienta w tym przykładzie jest ossifrage.

  1. Wybierz szyfr szyfrujący. W tym przykładzie wykorzystano A128GCM (AES z 128-bitowymi kluczami w trybie licznika Galois). Twoje narzędzie może korzystać z A GCM , jeśli wolisz.

  2. Wybierz sól (musi to być losowa sekwencja co najmniej 4 bajtów). W tym przykładzie wykorzystano (bajty szesnastkowe)E5 E6 53 08 03 F8 33 F6. Base64url koduje sekwencję, aby uzyskać 5eZTCAP4M_Y (usuń podkładkę base64).

  3. Oto przykładowe połączenie szyfrujące w celu utworzenia klucza szyfrowania zawartości (cek):

    cek=scrypt(password="ossifrage", salt=4-bajtowa sekwencja, 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 ac , który koduje telefon bazowy do lZ66bdEiAQV4_mqdInj_rA.

  4. Wybierz losową sekwencję 12 bajtów, która ma być używana jako wektor inicjalizacji. Ten przykład używa (hex) 34 b3 5d dd 5f 53 7b af 2d 92 95 83 które base64url koduje NLNd3V9Te tkpWD.

  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"}

    Podstawą64url kodowany nagłówek JOSE jest 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 bloba JWE jest wektor inicjalizacji NLNd3V9Te tkpWD.

  8. Użyj narzędzia szyfrującego JWE, aby utworzyć zaszyfrowany ładunek i tag. W tym przypadku niezaszyfrowana ładowność będzie fałszywą blob PEM to jest plik PEM

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

    • Ładowność jest to jest plik PEM

    • Szyfrowanie szyfru to AES 128 GCM

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

    Base64url koduje zaszyfrowaną ładunek, co powinno skutkować f5lLVuWNfKfmzYCo1YJfODhQ

    Jest to czwarty element (JWE Ciphertext) w obiekcie blob JWE.

  9. Base64url koduje znacznik wyprodukowany w kroku 8, który powinien skutkować PE-wDFWGXFFBeo928cfZ1Q

    Jest to piąty element w obiekcie blob JWE.

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

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

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

  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..9NLNd3V9Te tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

Typy sesji dla spotkań typu zero-trust 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 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ć tę możliwość dla swojej witryny; musisz przyznać użytkownikom nowy typ sesji (zwany także Meeting Privilege). Można to zrobić indywidualnie za pośrednictwem strony konfiguracji użytkownika lub zbiorczo za pomocą eksportu/importu CSV.

Zweryfikuj nowy typ sesji
1

Zaloguj się do Control Hub, a następnie przejdź do menu Usługi > Spotkanie.

2

Kliknij pozycję Witryny, wybierz witrynę Webex, której ustawienia chcesz zmienić, a następnie kliknij pozycję Ustawienia.

3

W części Wspólne ustawienia wybierz opcję Typy sesji.

4
Powinieneś zobaczyć jeden lub więcej typów sesji szyfrowania kompleksowego. 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.

Istnieje starszy typ sesji o bardzo podobnej nazwie: Szyfrowanie od początku do końca. Ten typ sesji obejmuje nieszyfrowany dostęp PSTN do spotkań. Upewnij się, że masz _wersję VOIPonly , aby zapewnić kompleksowe szyfrowanie. Możesz sprawdzić, unosząc się nad linkiem PRO w kolumnie kodu sesji; na przykład celem łącza powinna być javascript:ShowFeature(652).

W przyszłości możemy zmienić Nazwy usług publicznych dla tych typów sesji.

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.

Włącz spotkania E2EE dla poszczególnych użytkowników
1

Zaloguj się do Control Hub i przejdź do Management > Users.

2

Wybierz konto użytkownika do aktualizacji, a następnie wybierz opcję Spotkania.

3

Z Ustawienia dotyczą listy rozwijanej wybierz witrynę spotkania, aby ją zaktualizować.

4

Zaznacz pole obok opcji 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.

Aby przypisać to do wielu użytkowników, użyj następnej opcji, Włącz spotkania E2EE dla wielu użytkowników.

Włącz spotkania E2EE dla wielu użytkowników
1

Zaloguj się do Control Hub, a następnie przejdź do menu Usługi > Spotkanie.

2

Kliknij Witryny, wybierz witrynę Webex, dla której chcesz zmienić ustawienia.

3

W sekcji Licencje i użytkownicy kliknij pozycję Zarządzaj zbiorczo.

4

Kliknij opcję Wygeneruj raport i poczekaj na przygotowanie pliku.

5

Gdy plik będzie gotowy, kliknij przycisk Eksportuj wyniki, a następnie Pobierz . (Po kliknięciu przycisku Pobierz należy ręcznie zamknąć to wyskakujące okno.)

6

Otwórz pobrany plik CSV do edycji.

Dla każdego użytkownika istnieje wiersz, a kolumna MeetingPrivilege zawiera identyfikatory typu sesji jako listę rozdzieloną przecinkami.

7

Dla każdego użytkownika, któremu chcesz przyznać nowy typ sesji, dodaj 1561 jako nową wartość na liście przecinków w komórce MeetingPrivilege .

Numer referencyjny formatu pliku Webex CSV zawiera 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ż 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.

Dodaj znak wodny audio ze względów bezpieczeństwa

Do nagrań spotkań można dodać znak wodny z typem sesji Webex Meetings Pro-End to End Encryption_VOIPonly , który umożliwia identyfikację klienta źródłowego lub urządzenia nieautoryzowanych nagrań poufnych spotkań.

Gdy ta funkcja jest włączona, dźwięk spotkania zawiera unikatowy identyfikator dla każdego klienta lub urządzenia uczestniczącego. Nagrania audio można przesłać do Control Hub, który następnie analizuje nagranie i wyszukuje unikatowe identyfikatory. Możesz zobaczyć wyniki, aby sprawdzić, który klient źródłowy lub urządzenie nagrywało spotkanie.

  • Aby można było analizować, nagranie musi być plikiem AAC, MP3, M4A, WAV, MP4, AVI lub MOV o rozmiarze nie większym niż 500 MB.
  • Nagranie musi być dłuższe niż 100 sekund.
  • Możesz analizować nagrania tylko dla spotkań prowadzonych przez osoby w Twojej organizacji.
  • Informacje o znaku wodnym są przechowywane przez ten sam czas, co informacje o spotkaniu organizacji.

Dodawanie znaków wodnych audio do spotkań E2EE

  1. Zaloguj się do Control Hub, a następnie w obszarze Zarządzanie wybierz Ustawienia organizacji.
  2. W sekcji Znaczniki wodne spotkania włącz opcję Dodaj znak wodny audio.

    Jakiś czas po włączeniu tej opcji użytkownicy planujący spotkania z typem sesji Webex Meetings Pro-End to End Encryption_VOIPonly zobaczą opcję Digital Watermarking w sekcji Bezpieczeństwo.

Prześlij i przeanalizuj spotkanie oznaczone znakiem wodnym

  1. W Control Hub w obszarze Monitorowanie wybierz Rozwiązywanie problemów.
  2. Kliknij Analiza znaku wodnego.
  3. Wyszukaj lub wybierz spotkanie na liście, a następnie kliknij przycisk Przeanalizuj.
  4. W oknie Analizuj znak wodny audio wprowadź nazwę do analizy.
  5. (Opcjonalnie) Wprowadź notatkę do analizy.
  6. Przeciągnij i upuść plik audio do analizy lub kliknij opcję Wybierz plik , aby przeglądać go do pliku audio.
  7. Kliknij przycisk Zamknij.

    Po zakończeniu analizy zostanie ona wyświetlona na liście wyników na stronie Analizuj znak wodny .

  8. Wybierz spotkanie na liście, aby zobaczyć wyniki analizy. KliknijPrzycisk Pobierz , aby pobrać wyniki.

Funkcje i ograniczenia

Czynniki związane z pomyślnym odkodowaniem zarejestrowanego 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 zakodowanie, co może się zdarzyć, gdy media są udostępniane.

Funkcja ta ma na celu umożliwienie skutecznego dekodowania identyfikatora znaku wodnego w szerokim, ale rozsądnym zestawie okoliczności. Naszym celem jest, aby urządzenie nagrywające, takie jak telefon komórkowy, który leży na biurku w pobliżu osobistego punktu końcowego lub klienta laptopa, zawsze tworzyło nagranie, które skutkuje udaną analizą. Ponieważ urządzenie nagrywające jest odsunięte od źródła lub jest zasłonięte od słyszenia pełnego widma audio, szanse na pomyślną analizę są zmniejszone.

Aby z powodzeniem analizować 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 mieć zastosowania.

Urządzenia pokładowe (Wewnętrzny urząd certyfikacji)

Jeśli Twoje urządzenia są już włączone do organizacji Control Hub i chcesz użyć urzędu certyfikacji Webex do automatycznego generowania certyfikatów identyfikacyjnych, nie musisz fabrycznie resetować 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 powiesz Webex, która domena identyfikuje urządzenie, zostanie ono automatycznie wybrane, a inne osoby uczestniczące w spotkaniu mogą źle wyglądać.

Przed rozpoczęciem

Jeśli Twoje urządzenia nie są jeszcze włączone, przejdź do sekcji Zarejestruj urządzenie w usłudze Cisco Webex za pomocą interfejsu API lub lokalnego interfejsu WWW lub wdrażania w chmurze dla serii Board, Desk i Room. Należy również zweryfikować domenę/domeny, których chcesz użyć, aby zidentyfikować urządzenia w Zarządzaj domenami.

1

Zaloguj się do Control Hub, a w obszarze Management wybierz Devices.

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

Urządzenia pokładowe (Zewnętrzny urząd certyfikacji)

Przed rozpoczęciem

  • Uzyskaj certyfikat podpisany przez urząd certyfikacji i klucz prywatny w formacie .pem dla każdego urządzenia.

  • Na karcie Przygotowanie przeczytaj temat Zrozumienie procesu tożsamości zewnętrznej dla urządzeń,

  • Przygotuj narzędzie szyfrowania JWE w odniesieniu do informacji.

  • Upewnij się, że masz narzędzie do generowania losowych sekwencji bajtów danej długości.

  • Upewnij się, że masz narzędzie do base64url kodowania bajtów lub tekstu.

  • Upewnij się, że wprowadzono szyfrowanie .

  • Upewnij się, że masz tajne słowo lub frazę dla każdego urządzenia.

1

Wypełnij ClientSecret urządzenia prostym sekretem tekstowym:

Gdy po raz pierwszy wypełniasz sekret, dostarczasz go w postaci zwykłego tekstu. Dlatego zalecamy wykonanie tego na konsoli urządzenia fizycznego.

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

  2. Otwórz TShell na urządzeniu.

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

    Polecenie przykładowe powyżej uzupełnia Secret frazą 0123456789abcdef. Musisz wybrać własny.

Urządzenie ma swój początkowy sekret. Nie zapomnij o tym; nie można go odzyskać i musi fabrycznie zresetować urządzenie, aby rozpocząć ponownie.
2

Połącz certyfikat i klucz prywatny:

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

    To jest tekst ładunku, który zaszyfrujesz i umieścisz w blobie 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. Uzyskaj 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. Utwórz nagłówek JOSE, ustawiając klawisze alg, enc i cisco-kdf zgodnie z opisem w sekcji Understanding External Identity Process for Devices (Zrozumienie zewnętrznego procesu tożsamości dla urządzeń). Ustaw akcję „add” przy użyciu klawisza:value „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 skonsolidowanego 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: 

Usługi certyfikatów zabezpieczeń xcommand Dodaj zaszyfrowane: Zgadza się... JWE.str.ing\n.\n
5

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

Skopiuj odcisk palca nowego certyfikatu.

6

Aktywuj certyfikat w celu WebexIdentity:

  1. Odczytaj odcisk palca certyfikatu, albo z samego certyfikatu, albo z wyjścia programu xcommand Security Certicertificates Services Show.

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

  3. Uzyskaj 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. Utwórz nagłówek JOSE, ustawiając klawisze alg, enc i cisco-kdf zgodnie z opisem w sekcji Understanding External Identity Process for Devices (Zrozumienie zewnętrznego procesu tożsamości dla urządzeń). Ustaw akcję „aktywuj” przy użyciu klawisza:wartość „cisco-action”:„aktywuj” 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 wygenerować sekwencję 16 lub 32-bajtową, w zależności od tego, czy wybrano 128- czy 256-bitową AES-GCM, oraz znacznik 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:

     Usługi certyfikatów zabezpieczeń xcommand Aktywuj cel: Odcisk palca WebexIdentity: "Twój..JWE.szyfrowany.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

Dołącz urządzenie do organizacji Control Hub.

Przetestuj kompleksowe szyfrowanie z weryfikacją tożsamości
1

Zaplanuj spotkanie właściwego typu (Webex Meetings Pro-End to End Encryption_VOIPonly).

Zobacz Planowanie spotkania Webex z szyfrowaniem end-to-end.

2

Dołącz do spotkania jako gospodarz z klienta Webex Meetings.

Zobacz Dołączanie do spotkania Webex z szyfrowaniem end-to-end.

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.

Zobacz Dołączanie do spotkania Webex z szyfrowaniem end-to-end.

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 sprawdź 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.

Ustaw zakres i oczekiwania

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

  • Jeśli masz różne poziomy weryfikacji tożsamości, zezwól użytkownikom na weryfikację tożsamości za pomocą certyfikatu. 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.

Zarządzanie tożsamością

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.

Identyfikatory typów sesji
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 EVOIPonlyncryption_

660

Pro 3 Free-End to End EVOIPonlyncryption_

Szyfrowanie E2E + tożsamość

672

Pro 3 Free50-End to End EVOIPonlyncryption_

673

Instruktor edukacji E2E EVOIPonlyncryption_

676

Broadworks Standard plus szyfrowanie end-to-end

677

Broadworks Premium plus szyfrowanie end-to-end

681

Schoology Free plus szyfrowanie end-to-end

Powiązane polecenia xAPI

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

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

Wywołanie interfejsu API

Opis

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

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.

xStatus Conference EndToEndEnSzyfrowanie Dostępności

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 Veriation

Wskazuje, czy urządzenie korzysta z weryfikacji Zewnętrznej (posiada certyfikat wydany zewnętrznie).

xStatus Conference EndToEndEncryption ExternalIdentity Identity

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

xStatus Conference EndToEndEncryption ExternalIdentyfikator Certyfikat łańcucha # informacje szczegółowe

Odczytuje określone informacje z certyfikatu wystawionego zewnętrznie.

W wyświetlonym poleceniu zastąp # liczbą certyfikatu. Zastąp informacje szczegółowe jednym z:

  • Odcisk palca

  • Data zakończenia Ważności NotAfter

  • NotPrzed datą rozpoczęcia ważności

  • Nazwa PrimaryName

  • Algorytm klawiatury publicznej

  • Numer seryjny

  • Algorytm PodpisuAlgorytm

  • Temat # Nazwa Lista uczestników certyfikatu (np. adres e-mail lub nazwa domeny)

  • Ważność Nadaje status ważności tego certyfikatu (np. ważne lub wygasły)

xStatus Conference EndToEndEncryption ExternalIdentity Status

Stan zewnętrznej tożsamości urządzenia (np. prawidłowy lub błąd).

xStatus Conference EndToEndEncryption InternalIdentity Veriation

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 CertificateChain Certificate # informacje szczegółowe

Odczytuje określone informacje z certyfikatu wydanego przez Webex.

W wyświetlonym poleceniu zastąp # liczbą certyfikatu. Zastąp informacje szczegółowe jednym z:

  • Odcisk palca

  • Data zakończenia Ważności NotAfter

  • NotPrzed datą rozpoczęcia ważności

  • Nazwa PrimaryName

  • Algorytm klawiatury publicznej

  • Numer seryjny

  • Algorytm PodpisuAlgorytm

  • Temat # Nazwa Lista uczestników certyfikatu (np. adres e-mail lub nazwa domeny)

  • Ważność Nadaje status ważności tego certyfikatu (np. ważne lub wygasły)

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

Wywołanie interfejsu API

Opis

xEvent Conference ParticipantList ParticipantAdded

xEvent Conference ParticipantList Uczestnik Zaktualizowano

xEvent Conference ParticipantList ParticipantDeleted

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

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 Wypełnia Secret: "base64url-encoded"

lub

xCommand Security ClientSecret Wypełnia Sekret: JWEblob

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.

Usługi certyfikatów zabezpieczeń xCommand Dodaj JWEblob

Dodaje certyfikat (z kluczem prywatnym).

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

Usługi certyfikatów zabezpieczeń xCommand Aktywuj cel:WebexIdentity FingerPrint: JWEblob

Aktywuje określony certyfikat dla WebexIdentity. W tym Celu polecenie wymaga zaszyfrowania i serializacji identyfikującego odcisku palca w bloku JWE.

Usługi certyfikatów zabezpieczeń xCommand Dezaktywuj cel:WebexIdentity FingerPrint: JWEblob

Dezaktywuje określony certyfikat dla WebexIdentity. W tym Celu polecenie wymaga zaszyfrowania i serializacji identyfikującego odcisku palca w bloku JWE.