Użytkownicy wybierają typ spotkania podczas planowania spotkania. Podczas przyjmowania uczestników z poczekalni, a także podczas spotkania, prowadzący może zobaczyć stan weryfikacji tożsamości każdego uczestnika. Istnieje również kod spotkania, który jest wspólny dla wszystkich obecnych uczestników spotkania, którego mogą używać do wzajemnej weryfikacji.

Udostępnij następujące informacje prowadzącym spotkanie:

Zweryfikuj tożsamość

Kompleksowe szyfrowanie z weryfikacją tożsamości zapewnia dodatkowe zabezpieczenie spotkania z szyfrowaniem kompleksowym.

Gdy uczestnicy lub urządzenia dołączają do współużytkowanej grupy MLS (Messaging Layer Security), przedstawiają swoje certyfikaty innym członkom grupy, którzy następnie weryfikują certyfikaty względem wystawiających urzędó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 App uwierzytelniają się w magazynie tożsamości Webex , który po pomyślnym uwierzytelnieniu wydaje im token dostępu. Jeśli potrzebują certyfikatu do zweryfikowania swojej tożsamości podczas w pełni zaszyfrowanego spotkania, urząd certyfikacji Webex wystawia im certyfikat na podstawie ich tokenu dostępu. Obecnie nie umożliwiamy użytkownikom aplikacji Webex Meetings uzyskania certyfikatu wystawionego przez zewnętrzny/zewnętrzny urząd certyfikacji.

Urządzenia mogą uwierzytelniać się za pomocą certyfikatu wystawionego przez wewnętrzny urząd certyfikacji (Webex) lub certyfikatu wystawionego przez zewnętrzny urząd certyfikacji:

  • Wewnętrzny urząd certyfikacji — Webex wystawia certyfikat wewnętrzny na podstawie tokenu dostępu 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, dlatego Webex używa (jednej z) domen organizacji podczas zapisywania tożsamości certyfikatu urządzenia (nazwa pospolita (CN)).

  • Zewnętrzny urząd certyfikacji — żądaj i kupuj certyfikaty urządzenia bezpośrednio od wybranego wystawcy. Musisz szyfrować, przesyłać bezpośrednio i autoryzować certyfikaty przy użyciu klucza tajnego znanego tylko Tobie.

    Cisco nie jest zaangażowana, co pozwala zagwarantować prawdziwe szyfrowanie typu end-to-end i zweryfikowaną tożsamość, a także zapobiega teoretycznej możliwości podsłuchiwania przez firmę Cisco spotkania/odszyfrowywania multimediów.

Certyfikat urządzenia wydany wewnętrznie

Webex wystawia certyfikat dla urządzenia po jego zarejestrowaniu po uruchomieniu i odnawia go w razie potrzeby. W przypadku urządzeń certyfikat zawiera identyfikator konta i domenę.

Jeśli Twoja 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 określania tożsamości. Możesz również użyć API xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com".

Jeśli masz wiele domen i nie ustawisz preferowanej domeny dla urządzenia, Webex wybierze jedną za Ciebie.

Certyfikat urządzenia wydany zewnętrznie

Administrator może udostępnić urządzenie przy użyciu własnego certyfikatu, który został podpisany przez jeden 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 Pełne szyfrowanie z weryfikacją tożsamości dla Webex Meetings .

Zalecamy użycie osobnego certyfikatu dla każdego urządzenia i posiadanie unikatowego numeru CN dla każdego urządzenia. Na przykład „sala-konferencyjna-1.example.com” dla organizacji, która jest właścicielem domeny „example.com”.

Aby w pełni chronić certyfikat zewnętrzny przed manipulacją, do szyfrowania i podpisywania różnych poleceń xcommand używana jest funkcja Client-Secret.

Podczas korzystania z klucza tajnego klienta można bezpiecznie zarządzać zewnętrznym certyfikatem tożsamości Webex za pośrednictwem interfejsu xAPI. Obecnie jest to ograniczone do urządzeń online.

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

Urządzenia

Następujące urządzenia z serii Webex Room i Webex Desk zarejestrowane w chmurze mogą dołączać do kompleksowo zaszyfrowanych spotkań:

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

  • Seria Webex C

  • Seria Webex DX

  • Seria Webex EX

  • Seria Webex MX

  • Urządzenia SIP innych firm

Oprogramowanie klienckie
  • Począwszy od wersji 41.6, klient Webex Meetings dla komputerów stacjonarnych może dołączać do zaszyfrowanych spotkań.

  • Jeśli Twoja organizacja umożliwia aplikacji Webex dołączanie do spotkań przez uruchomienie aplikacji komputerowej Spotkania, możesz użyć tej opcji, aby dołączyć do w pełni zaszyfrowanych spotkań.

  • Klient WWW Webex nie może dołączać do w pełni zaszyfrowanych spotkań.

  • Klienty programowe SIP innych firm nie mogą dołączać do zaszyfrowanych spotkań typu end-to-end.

Tożsamość
  • Zgodnie z projektem nie zapewniamy opcji Control Hub do zarządzania tożsamością urządzenia zweryfikowaną zewnętrznie. W przypadku prawdziwego szyfrowania kompleksowego tylko użytkownik powinien znać wpisy tajne i klucze lub mieć do nich dostęp. Jeśli wprowadziliśmy usługę w chmurze do zarządzania tymi kluczami, istnieje ryzyko ich przechwycenia.

  • Obecnie zapewniamy „przepis” na zaprojektowanie własnych narzędzi, opartych na standardowych w branży technikach szyfrowania, aby pomóc w żądaniu lub szyfrowaniu certyfikatów tożsamości urządzenia i ich kluczy prywatnych. Nie chcemy mieć żadnego rzeczywistego ani domniemanego dostępu do Twoich kluczy tajnych lub kluczy.

Spotkania
  • Kompleksowo szyfrowane spotkania obsługują obecnie maksymalnie 200 uczestników.

  • Spośród tych 200 uczestników może dołączyć maksymalnie 25 urządzeń zweryfikowanych zewnętrznie, a oni muszą być pierwszymi uczestnikami, aby dołączyć do spotkania .

    Gdy do spotkania dołącza większa liczba urządzeń, nasze usługi multimedialne zaplecza próbują transkodować strumienie multimediów. Jeśli nie można 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 i klientami Meetings.

Interfejs zarządzania

Zdecydowanie zalecamy użycie Control Hub do zarządzania witryną spotkania, ponieważ organizacje Control Hub mają scentralizowaną tożsamość dla całej organizacji, podczas gdy w administracji witryny tożsamość jest kontrolowana na podstawie poszczególnych witryn.

Użytkownicy zarządzani za pomocą narzędzia Site Administration nie mogą mieć opcji tożsamości zweryfikowanej przez firmę Cisco. Ci użytkownicy otrzymują anonimowy certyfikat umożliwiający dołączenie do w pełni zaszyfrowanego spotkania i mogą zostać wykluczeni ze spotkań, w których prowadzący chce zapewnić weryfikację tożsamości.

Informacje pokrewne
  • Webex Meetings 41.7.

  • Zarejestrowane w chmurze urządzenia z serii Webex Room i Webex Desk, uruchomione 10.6.1-RoomOS_August_2021.

  • Dostęp administracyjny do witryny spotkania w Control Hub, 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 użytkownicy mogli dołączać do nich ze swojego systemu wideo. Aby uzyskać więcej informacji, zobacz Zezwalaj systemom wideo na dołączanie do spotkań i wydarzeń w witrynie Webex .

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

Aby zapewnić najwyższy poziom bezpieczeństwa i weryfikacji tożsamości, każde urządzenie powinno mieć unikalny certyfikat wydany przez zaufany publiczny Certificate Authority (CA).

Należy skontaktować się z urzędem certyfikacji, aby zażądać, kupić i odebrać certyfikaty cyfrowe oraz utworzyć skojarzone klucze prywatne. Podczas żądania certyfikatu użyj następujących parametrów:

  • Certyfikat musi być wystawiony i podpisany przez znany publiczny urząd certyfikacji.

  • Unikatowe: Zdecydowanie zalecamy używanie unikalnego certyfikatu dla każdego urządzenia. Jeśli używasz jednego certyfikatu dla wszystkich urządzeń, zagrażasz bezpieczeństwu.

  • Nazwa pospolita (CN) i alternatywne nazwy podmiotu (SAN): Nie są one ważne dla Webex, ale powinny być wartościami, które ludzie mogą odczytać i powiązać z urządzeniem. Nazwa CN będzie widoczna dla innych uczestników spotkania jako główna zweryfikowana tożsamość urządzenia, a jeśli użytkownicy sprawdzą certyfikat za pomocą interfejsu użytkownika spotkania, zobaczą sieć SAN. Możesz użyć nazw takich jak name.model@example.com.

  • Format pliku: Certyfikaty i klucze muszą znajdować się w .pem format.

  • Cel: Celem certyfikatu musi być tożsamość Webex .

  • Generowanie kluczy: Certyfikaty muszą być oparte na parach kluczy ECDSA P-256 (algorytm podpisu cyfrowego krzywej eliptycznej z wykorzystaniem krzywej P-256).

    To wymaganie nie dotyczy klucza podpisywania. Urząd certyfikacji może użyć klucza RSA do podpisania certyfikatu.

Możesz pominąć ten krok, jeśli nie chcesz używać tożsamości zweryfikowanej zewnętrznie na swoich urządzeniach.

Jeśli używasz nowych urządzeń, nie rejestruj ich jeszcze w Webex . Ze względów bezpieczeństwa nie podłączaj ich teraz do sieci.

Jeśli masz istniejące urządzenia, które chcesz uaktualnić, aby używały tożsamości zweryfikowanej zewnętrznie, musisz przywrócić ustawienia fabryczne tych urządzeń.

  • Zapisz istniejącą konfigurację, jeśli chcesz ją zachować.

  • Zaplanuj okno, gdy urządzenia nie są używane, lub zastosuj podejście etapowe. 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ń za pośrednictwem sieci, pamiętaj, że tajne informacje są przesyłane w postaci zwykłego tekstu, co zagraża bezpieczeństwu.

Po wykonaniu tych czynności Zezwól systemom wideo na dołączanie do spotkań i wydarzeń w witrynie Webex .

Aby upewnić się, że nośniki urządzenia nie mogą być szyfrowane 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 kompleksowe szyfrowanie za pośrednictwem naszej chmury, nie możemy brać udziału w szyfrowaniu i przesyłaniu certyfikatu i klucza. Jeśli potrzebujesz tego poziomu zabezpieczeń, musisz:

  1. Poproś o certyfikaty.

  2. Wygeneruj pary kluczy certyfikatów.

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

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

    Proces i parametry (nie tajne), których będziesz potrzebować, wyjaśniono poniżej, a także przepis, który należy zastosować w wybranych narzędziach programistycznych. Udostępniamy również niektóre dane testowe i wynikające z nich obiekty BLOB JWE zgodnie z oczekiwaniami, aby pomóc Ci zweryfikować proces.

    Nieobsługiwana implementacja referencyjna przy użyciu języka Python3 i biblioteki JWCrypto jest dostępna na żądanie w Cisco .

  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 na urządzenie.

  7. Ustaw cel zaszyfrowanego certyfikatu, który ma być używany dla tożsamości Webex , i aktywuj certyfikat.

  8. (Zalecane) Zapewnij interfejs (lub rozpowszechniaj) swoje narzędzie, aby umożliwić użytkownikom urządzeń zmianę początkowego klucza tajnego i chronić swoje multimedia przed Tobą.

Jak używamy formatu JWE

W tej sekcji opisano, jak oczekujemy utworzenia JWE jako danych wejściowych do urządzeń, dzięki czemu można zbudować własne narzędzie do tworzenia obiektów BLOB na podstawie certyfikatów i kluczy.

Patrz Szyfrowanie sieci JSON (JWE)https://datatracker.ietf.org/doc/html/rfc7516i Podpis sieciowy JSON (JWS)https://datatracker.ietf.org/doc/html/rfc7515.

Używamy Serializacja kompaktowa dokumentu JSON do tworzenia obiektów blob JWE. Parametry, które należy uwzględnić podczas tworzenia obiektów blob JWE, to:

  • Nagłówek JOSE (chronione). W nagłówku JSON Object Signing and Encryption MUSISZ uwzględnić następujące pary klucz-wartość:

    • "alg":"dir"

      Algorytm bezpośredni jest jedynym obsługiwanym przez nas do szyfrowania ładunku i należy 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 klucz zastrzeżony i mogą przyjmować cztery wartości. Wprowadziliśmy ten klucz, aby zasygnalizować cel zaszyfrowanych danych urządzeniu docelowemu. Wartości są nazwane zgodnie z poleceniami xAPI na urządzeniu, na którym są używane zaszyfrowane dane.

      Nazwaliśmy to cisco-action w celu złagodzenia potencjalnych konfliktów z przyszłymi rozszerzeniami JWE.

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

      Kolejny klucz zastrzeżony. Wprowadzone przez Ciebie wartości są używane jako dane wejściowe do wyprowadzania klucza na urządzeniu. Plik version musi być 1(wersja naszej funkcji wyprowadzania klucza). Wartość salt musi być zakodowaną w URL base64 sekwencją co najmniej 4 bajtów, musi wybierz losowo.

  • Zaszyfrowany klucz JWE . To pole jest puste. Urządzenie wyprowadza go z inicjału ClientSecret.

  • Wektor inicjalizacji JWE . Aby odszyfrować ładunek, należy podać wektor inicjujący zakodowany w formacie base64url. IV MUSI być losową wartością 12 bajtów (używamy rodziny szyfrów AES-GCM, która wymaga, aby kod IV miał długość 12 bajtów).

  • JWE AAD (dodatkowe uwierzytelnione dane). Należy pominąć to pole, ponieważ nie jest obsługiwane w przypadku serializacji kompaktowej.

  • Zaszyfrowany tekst JWE : To jest zaszyfrowany ładunek, który chcesz zachować w tajemnicy.

    Ładunek MOŻE być pusty. Na przykład, aby zresetować klucz tajny klienta, należy go zastąpić 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 interfejsu xAPI wymagają różnych ładunków i należy określić cel ładunku za pomocą opcji cisco-action klucz w następujący sposób:

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

    • Z „ "cisco-action":"add" zaszyfrowany tekst to obiekt blob PEM zawierający certyfikat i jego klucz prywatny (połączone).

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

    • Z „ "cisco-action":"deactivate" tekst zaszyfrowany jest odciskiem palca (szesnastkową reprezentacją sha-1) certyfikatu, którego dezaktywujemy, aby był używany do weryfikacji tożsamości urządzenia.

  • Znacznik uwierzytelniania JWE: To pole zawiera znacznik uwierzytelniania, aby potwierdzić integralność całego obiektu BLOB zwartej serializacji JWE

W jaki sposób uzyskujemy klucz szyfrowania z ClientSecret

Po pierwszym wypełnieniu klucza tajnego nie akceptujemy ani nie wyprowadzamy klucza tajnego jako zwykłego tekstu. Ma to na celu zapobieganie potencjalnym atakom słownikowym przez osoby, które mogłyby uzyskać dostęp do urządzenia.

Oprogramowanie urządzenia wykorzystuje klucz tajny klienta jako dane wejściowe do funkcji wyprowadzania klucza (kdf), a następnie używa otrzymanego klucza do odszyfrowywania/szyfrowania zawartości na urządzeniu.

Oznacza to, że narzędzie do tworzenia obiektów blob JWE musi postępować zgodnie z tą samą procedurą, aby uzyskać ten sam klucz szyfrowania/odszyfrowywania z klucza tajnego klienta.

Urządzenia używają zaszyfrować dla wyprowadzania klucza (patrzhttps://en.wikipedia.org/wiki/Scrypt ) z następującymi parametrami:

  • Współczynnik kosztu (N) wynosi 32768

  • BlockSizeFactor (r) wynosi 8

  • Współczynnik równoległości (p) wynosi 1

  • Salt to losowa sekwencja o długości co najmniej 4 bajtów; musisz podać to samo salt podczas określania cisco-kdf parametr.

  • Długość klucza wynosi 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 64 MB

Ten zestaw parametrów jest jedyną konfiguracją zaszyfrować który jest zgodny z funkcją wyprowadzania klucza na urządzeniach. Ten plik KDF na urządzeniach nazywa się "version":"1", która jest jedyną wersją aktualnie używaną przez cisco-kdf parametr.

Przykład pracy

Oto przykład, za pomocą którego możesz 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 dodanie certyfikatu z bardzo krótkim ciągiem zamiast pełnego certyfikatu + klucza). Klucz tajny klienta w przykładzie to ossifrage.

  1. Wybierz szyfr szyfrowania. W tym przykładzie użyto A128GCM(AES z kluczami 128-bitowymi w trybie licznika Galois). Twoje narzędzie może użyć A256GCM jeśli wolisz.

  2. Wybierz sól (musi być losową sekwencją co najmniej 4 bajtów). W tym przykładzie użyto (bajtów szesnastkowych) E5 E6 53 08 03 F8 33 F6. Base64url koduje sekwencję, aby uzyskać 5eZTCAP4M_Y(usuń dopełnienie base64).

  3. Oto próbka 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)

    Wyprowadzony klucz 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 w którym adresie base64url koduje? lZ66bdEiAQV4_mqdInj_rA.

  4. Wybierz losową sekwencję 12 bajtów, która będzie używana jako wektor inicjujący. W tym przykładzie użyto (szesnastkowo) 34 b3 5d dd 5f 53 7b af 2d 92 95 83 w którym adresie base64url koduje? NLNd3V9Te68tkpWD.

  5. Utwórz nagłówek JOSE z serializacją kompaktową (zgodnie z tą samą kolejnością parametrów, której używamy tutaj), a następnie zakoduj go w formacie base64url:

    {"alg":"dir","cisco-action":"add","cisco-kdf":{"salt":"5eZTCAP4M_Y","version":"1"},"enc":"A128GCM"}

    Nagłówek JOSE zakodowany algorytmem base64url: 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 inicjujący NLNd3V9Te68tkpWD.

  8. Użyj narzędzia szyfrującego JWE, aby utworzyć zaszyfrowany ładunek i znacznik. W tym przykładzie niezaszyfrowany ładunek będzie fałszywym obiektem blob PEM this is a PEM file

    Należy użyć następujących parametrów szyfrowania:

    • Ładunek to this is a PEM file

    • Szyfr szyfrowania to AES 128 GCM

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

    Base64url zakoduje zaszyfrowany ładunek, co powinno spowodować: f5lLVuWNfKfmzYCo1YJfODhQ

    Jest to czwarty element (tekst zaszyfrowany JWE) w obiekcie blob JWE.

  9. Base64url zakoduj tag utworzony w kroku 8, co powinno spowodować: PE-wDFWGXFFBeo928cfZ1Q

    Jest to piąty element obiektu blob JWE.

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

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

  11. Jeśli uzyskano te same wartości zakodowane w formacie base64url, które pokazano tutaj, przy użyciu własnych narzędzi, można ich użyć do zabezpieczenia szyfrowania E2E i zweryfikowanej tożsamości urządzeń.

  12. Ten przykład nie będzie działał, ale zasadniczo następnym krokiem będzie użycie utworzonego powyżej obiektu BLOB JWE jako danych wejściowych do polecenia xcommand na urządzeniu, które dodaje certyfikat:

    xCommand Security Certificates Add eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

Typy sesji dla spotkań typu zero-trust są dostępne dla wszystkich witryn spotkań bez dodatkowych kosztów. Nazywa się jeden z tych typów sesji Pro-End to End Encryption_VOIPonly. To jest nazwa usługi publicznej, którą możemy zmienić w przyszłości. Aby uzyskać bieżące nazwy typów sesji, zobacz Identyfikatory typów sesji w Odniesienie sekcji tego artykułu.

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 na stronie konfiguracji użytkownika lub zbiorczo za pomocą eksportu/importu pliku CSV .

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
Powinien być widoczny jeden lub więcej typów sesji szyfrowania kompleksowego. Zapoznaj się z listą Identyfikatory typów sesji w Odniesienie sekcji tego artykułu. Na przykład możesz zobaczyć Pro-End to End Encryption_ Tylko VOIP .

 

Istnieje starszy typ sesji o bardzo podobnej nazwie: Szyfrowanie Pro-End to End . Ten typ sesji obejmuje nieszyfrowany dostęp PSTN do spotkań. Upewnij się, że masz_ Tylko VOIP wersji, aby zapewnić pełne szyfrowanie. Możesz to sprawdzić, najeżdżając kursorem na PRO link 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.

5

Jeśli nie masz jeszcze nowego typu sesji, skontaktuj się z przedstawicielem Webex .

Co zrobić dalej

Włącz ten typ sesji/uprawnienie do spotkania dla niektórych lub wszystkich użytkowników.

1

Zaloguj się do Centrum sterowania i przejdź do Zarządzanie > Użytkownicy .

2

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

3

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

4

Zaznacz pole obok Pro-End to End Encryption_ Tylko VOIP .

5

Zamknij panel konfiguracji użytkownika.

6

W razie potrzeby powtórz dla innych użytkowników.

Aby przypisać to wielu użytkownikom, użyj następnej opcji, 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 Licencje i użytkownicy sekcji, kliknij Zarządzanie zbiorcze .

4

Kliknij opcję Wygeneruj raport i poczekaj na przygotowanie pliku.

5

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

6

Otwórz pobrany plik CSV do edycji.

Dla każdego użytkownika istnieje wiersz, a MeetingPrivilege kolumna zawiera ich identyfikatory typu sesji w postaci listy rozdzielanej przecinkami.

7

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

The Informacje o formacie pliku CSV Webex zawiera szczegółowe informacje na temat celu i zawartości pliku CSV .

8

Otwórz panel konfiguracji witryny spotkania w Control Hub.


 

Jeśli jesteś już na stronie z listą witryn spotkania, może być konieczne jej odświeżenie.

9

W Licencje i użytkownicy sekcji, kliknij Zarządzanie zbiorcze .

10

Kliknij Importuj i wybierz edytowany CSV, a następnie kliknij Importuj . Poczekaj na przesłanie pliku.

11

Po zakończeniu importowania możesz kliknąć Importuj wyniki aby sprawdzić, czy wystąpiły błędy.

12

Przejdź do Użytkownicy i otwórz jednego z użytkowników, aby sprawdzić, czy mają nowy typ sesji.

Do nagrań ze spotkań można dodać znak wodny Webex Meetings Pro-End to End Encryption_VOIPonly typ sesji, 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 nagranie mogło zostać przeanalizowane, musi być plikiem AAC, MP3, M4A, WAV, MP4, AVI lub MOV o rozmiarze nieprzekraczającym 500 MB.
  • Nagranie musi być dłuższe niż 100 sekund.
  • Możesz analizować tylko nagrania spotkań prowadzonych przez osoby w Twojej organizacji.
  • Informacje o znaku wodnym są przechowywane przez 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 sekcji Zarządzanie wybierz Ustawienia organizacji.
  2. W Znaki wodne spotkania sekcja, włącz Dodaj znak wodny audio .

    Jakiś czas po włączeniu tej funkcji użytkownicy planują spotkania z Webex Meetings Pro-End to End Encryption_VOIPonly typ sesji patrz opcja Cyfrowe znakowanie wodne w sekcji Bezpieczeństwo.

Przesyłanie i analizowanie spotkania ze znakiem wodnym
  1. W centrum sterowania, 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 Analizuj znak wodny audio wprowadź nazwę analizy.
  5. (Opcjonalnie) Wprowadź notatkę do analizy.
  6. Przeciągnij i upuść plik audio do analizy lub kliknij Wybierz plik aby przejść do pliku audio.
  7. Kliknij Zamknij .

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

  8. Wybierz spotkanie na liście, aby wyświetlić wyniki analizy. KliknijPrzycisk Pobierz aby pobrać wyniki.
Funkcje i ograniczenia

Czynniki związane z skutecznym dekodowaniem 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 kilkakrotne 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 usł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.

Jeśli Twoje urządzenia są już wprowadzone do organizacji Control Hub i chcesz użyć urzędu certyfikacji Webex do automatycznego wygenerowania ich certyfikatów identyfikujących, nie musisz resetować urządzeń do ustawień fabrycznych.

Ta procedura wybiera domenę, której urządzenie używa do identyfikacji i jest wymagana tylko wtedy, gdy masz wiele domen w organizacji Control Hub. Jeśli masz więcej niż jedną domenę, zalecamy wykonanie tej czynności 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, jedna z nich zostanie wybrana automatycznie i może wyglądać nieprawidłowo dla innych uczestników spotkania.

Przed rozpoczęciem

Jeśli Twoje urządzenia nie zostały jeszcze wprowadzone, wykonaj Zarejestruj urządzenie w Cisco Webex za pomocą API lub lokalnego interfejsu internetowego lub Cloud onboarding dla serii Board, Desk i Room . Należy również zweryfikować domeny, których chcesz użyć do identyfikacji urządzeń w Zarządzaj swoimi domenami .

1

Zaloguj się do Control Hub i poniżej Zarządzanie , wybierz Urządzenia .

2

Wybierz urządzenie, aby otworzyć jego panel konfiguracji.

3

Wybierz domenę, której chcesz użyć do identyfikacji tego urządzenia.

4

Powtórz dla innych urządzeń.

Przed rozpoczęciem

Potrzebujesz:

  • Aby uzyskać certyfikat podpisany przez urząd certyfikacji i klucz prywatny, w .pem format dla każdego urządzenia.

  • Aby przeczytać temat Opis procesu tożsamości zewnętrznej dla urządzeń , w Przygotuj część tego artykułu.

  • Przygotowanie narzędzia szyfrującego JWE w odniesieniu do zawartych w nim informacji.

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

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

  • An scrypt wdrożenie.

  • 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łnieniu pola Secret, należy go podać w postaci zwykłego tekstu. Dlatego zalecamy wykonanie tej czynności w konsoli urządzenia fizycznego.

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

  2. Otwórz program TShell na urządzeniu.

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

    Przykładowe polecenie powyżej wypełnia Secret ze frazą 0123456789abcdef. Musisz wybrać własne.

Urządzenie ma swój początkowy klucz tajny. Nie zapomnij o tym; nie można go odzyskać i należy zresetować urządzenie do ustawień fabrycznych, aby można było rozpocząć ponownie.
2

Połącz certyfikat i klucz prywatny:

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

    (To jest tekst ładunku, który zostanie zaszyfrowany i umieszczony w obiekcie 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. Uzyskaj klucz szyfrowania treści za pomocą narzędzia do szyfrowania.

    W tym celu potrzebny jest klucz tajny, kod dodatkowy i długość klucza pasujące do wybranego szyfru szyfrowania. Istnieje kilka innych wartości stałych do podania (N=32768, r=8, p=1). Urządzenie korzysta z tego samego procesu i wartości w celu uzyskania tego samego klucza szyfrowania treści.

  3. Utwórz losową sekwencję dokładnie 12 bajtów. To jest twój wektor inicjujący.

  4. Utwórz nagłówek JOSE, ustawianie alg, enc i cisco-kdf klawisze zgodnie z opisem w Opis procesu tożsamości zewnętrznej dla urządzeń . Ustaw działanie „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 nagłówkiem JOSE zakodowanym w standardzie base64url, aby zaszyfrować tekst z połączonego pliku pem.

  7. Base64url koduje wektor inicjujący, zaszyfrowany ładunek PEM i tag uwierzytelniania.

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

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4

Otwórz program TShell na urządzeniu i uruchom polecenie (multiline) 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 cyfrowy certyfikatu z samego certyfikatu lub z danych wyjściowych xcommand Security Certificates Services Show.

  2. Utwórz losową sekwencję o długości co najmniej 4 bajtów i zakoduj ją w standardzie base64url. To jest twoja sól.

  3. Uzyskaj klucz szyfrowania treści za pomocą narzędzia do szyfrowania.

    W tym celu potrzebny jest klucz tajny, kod dodatkowy i długość klucza pasujące do wybranego szyfru szyfrowania. Istnieje kilka innych wartości stałych do podania (N=32768, r=8, p=1). Urządzenie korzysta z tego samego procesu i wartości w celu uzyskania tego samego klucza szyfrowania treści.

  4. Utwórz losową sekwencję o długości dokładnie 12 bajtów i zakoduj ją w standardzie base64url. To jest twój wektor inicjujący.

  5. Utwórz nagłówek JOSE, ustawianie alg, enc i cisco-kdf klawisze zgodnie z opisem w Opis procesu tożsamości zewnętrznej dla urządzeń . Ustaw działanie „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 do szyfrowania JWE z wybranym szyfrem i nagłówkiem JOSE zakodowanym w standardzie base64url, aby zaszyfrować odcisk cyfrowy certyfikatu.

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

  8. Base64urlencode zaszyfrowany odcisk palca i znacznik uwierzytelniania.

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

    JOSEHeader..InitVector.EncryptedFingerprint.AuthTag

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

                      xcommand Security Certificates Services Activate Purpose: WebexIdentity Fingerprint: "Your..JWE.encrypted.fingerprint" 
                    
Urządzenie ma zaszyfrowany, aktywny certyfikat wystawiony przez urząd certyfikacji, gotowy do użycia w celu jego identyfikacji podczas kompleksowo zaszyfrowanych spotkań Webex .
7

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

1

Zaplanuj spotkanie odpowiedniego typu ( Webex Meetings Pro-End to End Encryption_ Tylko VOIP ).

2

Dołącz do spotkania jako prowadzący za pomocą 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 prowadzący 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 prowadzący 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 prowadzący sprawdź, czy ten uczestnik jest wyświetlany w poczekalni z poprawną ikoną tożsamości.

9

Jako prowadzący możesz dopuszczać lub odrzucać osoby/urządzenia.

10

Jeśli to możliwe, sprawdź tożsamość uczestników/urządzeń, sprawdzając certyfikaty.

11

Sprawdź, czy wszyscy uczestnicy spotkania widzą ten sam kod zabezpieczeń spotkania.

12

Dołącz do spotkania z nowym uczestnikiem.

13

Sprawdź, czy wszyscy widzą ten sam, nowy kod bezpieczeństwa spotkania.

Czy chcesz, aby całkowicie szyfrowane spotkania były domyślną opcją spotkania, czy włączysz ją tylko dla niektórych użytkowników, czy zezwolisz na decyzję wszystkim prowadzącym? Po podjęciu decyzji, w jaki sposób zamierzasz korzystać z tej funkcji, przygotuj tych użytkowników, którzy będą z niej korzystać, zwłaszcza w odniesieniu do ograniczeń i tego, czego można się spodziewać podczas spotkania.

Czy musisz upewnić się, że ani Cisco , ani nikt inny nie może odszyfrować treści ani podszywać się pod Twoje urządzenia? Jeśli tak, potrzebujesz certyfikatów z publicznego urzędu certyfikacji. W bezpiecznym spotkaniu może być maksymalnie 25 urządzeń. Jeśli wymagany 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óźniej.

Jeśli masz różne poziomy weryfikacji tożsamości, daj użytkownikom możliwość wzajemnej weryfikacji przy użyciu tożsamości opartej na certyfikatach i kodu zabezpieczającego spotkanie. Mimo że istnieją okoliczności, w których uczestnicy mogą pojawiać się jako niezweryfikowani, a uczestnicy powinni wiedzieć, jak to sprawdzić, osoby niezweryfikowane mogą nie być oszustami.

Jeśli do wystawiania certyfikatów urządzeń używasz zewnętrznego urzędu certyfikacji, monitorowanie, odświeżanie i ponowne stosowanie certyfikatów spoczywa na Tobie.

Jeśli utworzono początkowe hasło tajne, należy pamiętać, że użytkownicy mogą chcieć zmienić hasło tajne urządzenia. Może być konieczne utworzenie interfejsu/rozpowszechnianie narzędzia, aby umożliwić im to.

Tabela 1. Identyfikatory typu sesji dla kompleksowo zaszyfrowanych spotkań

Identyfikator typu sesji

Nazwa usługi publicznej

638

Tylko szyfrowanie E2E+ VoIP

652

Pro-End to End Encryption_ Tylko VOIP

660

Pro 3 od końca do końca Encryption_ Tylko VOIP

Szyfrowanie E2E + tożsamość

672

Pro 3 Free50-od końca do końca Encryption_ Tylko VOIP

673

Instruktor edukacji E2E Encryption_ Tylko VOIP

676

Broadworks Standard plus szyfrowanie kompleksowe

677

Broadworks Premium plus kompleksowe szyfrowanie

681

Schoology Free plus kompleksowe szyfrowanie

Te tabele opisują polecenia API urządzeń Webex , które dodaliśmy do zaszyfrowanych spotkań i zweryfikowanej tożsamości. Aby uzyskać więcej informacji na temat korzystania z API, zobacz Uzyskaj dostęp do API dla urządzeń Webex Room and Desk oraz Webex Boards .

Te polecenia interfejsu xAPI są dostępne tylko na urządzeniach, które:

  • Zarejestrowano w Webex

  • Zarejestrowano lokalnie i połączono z Webex za pomocą Webex Edge for Devices

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

Wywołanie API

Opis

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

Ta konfiguracja jest wykonywana, gdy administrator ustawia preferowaną domenę urządzenia z Control Hub. Niezbędne tylko wtedy, gdy organizacja ma więcej niż jedną domenę.

Urządzenie korzysta z tej domeny, gdy żąda certyfikatu od urzędu certyfikacji Webex . Domena następnie identyfikuje urządzenie.

Ta konfiguracja nie ma zastosowania, gdy urządzenie ma aktywny certyfikat wystawiony zewnętrznie do identyfikacji.

xStatus Conference EndToEndEncryption Availability

Wskazuje, czy urządzenie może dołączyć do spotkania zaszyfrowanego kompleksowo. API chmury wywołuje go, aby sparowana aplikacja wiedziała, czy może użyć urządzenia do dołączenia.

xStatus Conference EndToEndEncryption ExternalIdentity Verification

Wskazuje, czy urządzenie używa External weryfikacja (posiada certyfikat wydany przez podmiot zewnętrzny).

xStatus Conference EndToEndEncryption ExternalIdentity Identity

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

xStatus Conference EndToEndEncryption ExternalIdentity CertificateChain Certificate # specificinfo

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

W wyświetlonym poleceniu zastąp # z numerem certyfikatu. Zamień specificinfo z jednym z:

  • Fingerprint

  • NotAfter Data zakończenia ważności

  • NotBefore Data rozpoczęcia ważności

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

  • Subject # Name Lista tematów certyfikatu (np. adres e-mail lub nazwa domeny)

  • Validity Podaje stan ważności tego certyfikatu (np. valid lub expired)

xStatus Conference EndToEndEncryption ExternalIdentity Status

Stan tożsamości zewnętrznej urządzenia (np valid lub error).

xStatus Conference EndToEndEncryption InternalIdentity Verification

Wskazuje, czy urządzenie ma ważny certyfikat wydany przez urząd certyfikacji Webex .

xStatus Conference EndToEndEncryption InternalIdentity Identity

Tożsamość urządzenia odczytana z nazwy pospolitej certyfikatu wystawionego przez Webex.

Zawiera nazwę domeny, jeśli organizacja ma domenę.

Pole puste, jeśli organizacja nie ma domeny.

Jeśli urządzenie znajduje się w organizacji, która ma wiele domen, jest to wartość z pola PreferredDomain.

xStatus Conference EndToEndEncryption InternalIdentity CertificateChain Certificate # specificinfo

Odczytuje określone informacje z certyfikatu wystawionego przez Webex.

W wyświetlonym poleceniu zastąp # z numerem certyfikatu. Zamień specificinfo z jednym z:

  • Fingerprint

  • NotAfter Data zakończenia ważności

  • NotBefore Data rozpoczęcia ważności

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

  • Subject # Name Lista tematów certyfikatu (np. adres e-mail lub nazwa domeny)

  • Validity Podaje stan ważności tego certyfikatu (np. valid lub expired)

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

Wywołanie API

Opis

xEvent Conference ParticipantList ParticipantAdded

xEvent Conference ParticipantList ParticipantUpdated

xEvent Conference ParticipantList ParticipantDeleted

Te trzy wydarzenia obejmują teraz: EndToEndEncryptionStatus, EndToEndEncryptionIdentity i EndToEndEncryptionCertInfo dla danego uczestnika.

Tabela 4. Interfejsy API powiązane z ClientSecret do kompleksowo zaszyfrowanych spotkań i zweryfikowanej tożsamości

Wywołanie API

Opis

xCommand Security ClientSecret Populate Secret: "base64url-encoded"

lub

xCommand Security ClientSecret Populate Secret: JWEblob

Akceptuje wartość tekstową zakodowaną w formacie base64url na potrzeby pierwszego umieszczania klucza tajnego klienta na urządzeniu.

Aby zaktualizować klucz tajny po raz pierwszy, należy dostarczyć obiekt blob JWE zawierający nowy klucz tajny zaszyfrowany starym kluczem tajnym.

xCommand Security Certificates Services Add JWEblob

Dodaje certyfikat (z kluczem prywatnym).

Rozszerzyliśmy to polecenie, aby akceptować 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 zaszyfrowania i serializacji identyfikującego odcisku palca w obiekcie blob JWE.

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

Dezaktywuje określony certyfikat dla WebexIdentity. W tym celu Purpose, polecenie wymaga zaszyfrowania i serializacji identyfikującego odcisku palca w obiekcie blob JWE.