Środowisko użytkownika

Podczas planowania spotkania użytkownicy wybierają typ spotkania. Podczas wpuszczania 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żyć do zweryfikowania, czy ich spotkanie nie zostało przechwycone przez niepożądany atak strony trzeciej Meddler In The Middle (MITM).

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

Weryfikacja tożsamości z wewnętrznym lub zewnętrznym urzędem certyfikacji

Zweryfikuj tożsamość

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

Gdy uczestnicy lub urządzenia dołączają do wspólnej grupy MLS (Messaging Layer Security), prezentują swoje certyfikaty innym członkom grupy, którzy następnie sprawdzają poprawność certyfikatów względem wystawiających urzędów certyfikacji. Potwierdzając, że certyfikaty są ważne, CA weryfikuje tożsamość uczestników, a spotkanie pokazuje uczestników/urządzenia jako zweryfikowanych.

Użytkownicy aplikacji Webex uwierzytelniają się w magazynie tożsamości Webex, który po pomyślnym uwierzytelnieniu wydaje im token dostępu. Jeśli potrzebują oni certyfikatu w celu weryfikacji tożsamości podczas spotkania szyfrowanego kompleksowo, urząd certyfikacji Webex wydaje im certyfikat na podstawie ich tokenu dostępu. Obecnie nie udostępniamy użytkownikom aplikacji Webex Meetings sposobu na uzyskanie certyfikatu wydawanego przez zewnętrzny/zewnętrzny urząd certyfikacji.

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

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

  • Zewnętrzny urząd certyfikacji — żądanie i zakup certyfikatów urządzeń bezpośrednio od wybranego wystawcy. Musisz zaszyfrować, bezpośrednio przesłać i autoryzować certyfikaty przy użyciu klucza tajnego znanego tylko Tobie.

    Firma Cisco nie uczestniczy w tym procesie, co pozwala zagwarantować prawdziwe szyfrowanie kompleksowe i zweryfikowaną tożsamość oraz zapobiec teoretycznej możliwości nasłuchiwania przez firmę Cisco spotkania/odszyfrowywania multimediów.

Wystawiony wewnętrznie certyfikat urządzenia

Webex wydaje certyfikat do urządzenia podczas rejestracji po uruchomieniu i w razie potrzeby odnawia go. W przypadku urządzeń certyfikat zawiera identyfikator konta i domenę.

Jeśli Twoja organizacja nie ma domeny, urząd certyfikacji Webex wydaje certyfikat bez domeny.

Jeśli Twoja organizacja ma wiele domen, możesz użyć Control Hub, aby powiedzieć Webex, której domeny urządzenie ma użyć dla 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 ustawisz preferowanej domeny dla urządzenia, usługa Webex wybiera jedną dla Ciebie.

Certyfikat urządzenia wydany zewnętrznie

Administrator może zainicjować obsługę administracyjną urządzenia z własnym certyfikatem, który został podpisany przez jeden z publicznych urzędów certyfikacji.

Certyfikat musi być oparty na parze kluczy ECDSA P-256, ale może być podpisany kluczem RSA.

Wartości w certyfikacie zależą od decyzji organizacji. Nazwa pospolita (CN) i nazwa alternatywna podmiotu (SAN) będą wyświetlane w interfejsie użytkownika spotkania Webex, jak opisano w części Szyfrowanie kompleksowe z weryfikacją tożsamości dla spotkań Webex.

Zalecamy stosowanie oddzielnego certyfikatu dla każdego urządzenia oraz posiadanie unikatowego kodu CN dla każdego urządzenia. Na przykład „meeting-room-1.example.com” dla organizacji, która jest właścicielem domeny „example.com”.

W celu pełnej ochrony zewnętrznego certyfikatu przed zmanipulowaniem do szyfrowania i podpisywania różnych poleceń xcommand jest używana funkcja tajna klienta.

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.

Funkcje i ograniczenia

Urządzenia

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

  • Tablica Webex

  • Webex Desk Pro

  • Biurko Webex

  • Zestaw Webex Room

  • Zestaw Webex Room 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

Klienty oprogramowania

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

  • Klient internetowy Webex nie może dołączać do spotkań E2EE.

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

Tożsamość

  • W projekcie nie udostępniamy opcji Control Hub umożliwiających zarządzanie zewnętrznie zweryfikowaną tożsamością urządzenia. W przypadku szyfrowania kompleksowego tylko Ty powinieneś znać/uzyskać dostęp do sekretów i kluczy. Jeśli wprowadziliśmy usługę w chmurze do zarządzania tymi kluczami, istnieje prawdopodobieństwo, że zostaną one przechwycone.

  • Obecnie zapewniamy „przepis” na projektowanie 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 ani postrzeganego dostępu do Twoich sekretów lub kluczy.

Spotkania

  • Spotkania E2EE obsługują obecnie maksymalnie 1000 uczestników.

  • Nowe tablice można udostępniać podczas spotkań E2EE. W regularnych spotkaniach można zauważyć pewne różnice w stosunku do tablic:
    • W spotkaniach E2EE użytkownicy nie mają dostępu do tablic utworzonych poza spotkaniem, w tym do tablic prywatnych, tablic udostępnionych przez inne osoby oraz tablic z obszarów Webex.
    • Tablice utworzone w spotkaniach E2EE są dostępne tylko podczas spotkania. Nie są one zapisywane i nie są dostępne po zakończeniu spotkania.
    • Jeśli ktoś udostępnia zawartość podczas spotkania E2EE, możesz dodawać do niej adnotacje. Aby uzyskać więcej informacji na temat adnotacji, zobacz Aplikacja Webex | Oznaczanie udostępnianej zawartości za pomocą adnotacji.

Interfejs zarządzania

Zdecydowanie zalecamy używanie Control Hub do zarządzania witryną spotkań, ponieważ organizacje Control Hub scentralizowały tożsamość całej organizacji.

Dodatkowe zasoby
Wymagania wstępne

  • Webex Meetings 41.7.

  • Zarejestrowane w chmurze urządzenia serii Webex Room i Webex Desk, 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 wydawania certyfikatów urządzeń w celu zweryfikowanej tożsamości).

  • Pokoje spotkań CMR muszą być włączone, aby osoby mogły dołączać z ich systemu wideo. Aby uzyskać więcej informacji, zobacz Zezwalanie systemom wideo na dołączanie do spotkań i wydarzeń w witrynie Webex.

Pobierz certyfikaty urządzeń

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

W celu zapewnienia najwyższego poziomu bezpieczeństwa i weryfikacji tożsamości każde urządzenie powinno mieć unikatowy certyfikat wydany przez zaufany publiczny urząd certyfikacji (CA).

Musisz współpracować z urzędem certyfikacji, aby żądać, kupować i odbierać certyfikaty cyfrowe oraz tworzyć powiązane klucze prywatne. W przypadku żądania certyfikatu użyj następujących parametrów:

  • Certyfikat musi zostać wydany i podpisany przez dobrze znany publiczny urząd certyfikacji.

  • Unikalne: Zdecydowanie zalecamy używanie unikatowego certyfikatu dla każdego urządzenia. Jeśli używasz jednego certyfikatu dla wszystkich urządzeń, narażasz na szwank swoje bezpieczeństwo.

  • Nazwa pospolita (CN) i nazwy alternatywne podmiotu (SAN): Nie są one ważne dla Webex, ale powinny być wartościami, które ludzie mogą odczytywać i kojarzyć z urządzeniem. CN będzie wyświetlana innym uczestnikom spotkania jako podstawowa zweryfikowana tożsamość urządzenia, a jeśli użytkownicy sprawdzą certyfikat za pośrednictwem interfejsu użytkownika spotkania, zobaczą sieci SAN/s. Można używać nazw, takich jak name.model@example.com.

  • Format pliku: Certyfikaty i klucze muszą mieć .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 wykorzystujący krzywą P-256).

    Wymóg ten nie obejmuje klucza podpisywania. Urząd certyfikacji może podpisać certyfikat za pomocą klucza RSA.

Przygotuj się do wdrażania urządzeń

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

Jeśli korzystasz z nowych urządzeń, nie rejestruj ich jeszcze w usłudze Webex. Aby zapewnić bezpieczeństwo, nie łącz ich obecnie z siecią.

Jeśli masz istniejące urządzenia, które chcesz uaktualnić, aby korzystać z tożsamości zweryfikowanej zewnętrznie, musisz przywrócić je fabrycznie.

  • 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 sekrety podróżują zwykłym tekstem i narażasz swoje bezpieczeństwo.

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

Zapoznaj się z procesem tożsamości zewnętrznej urządzeń

Aby mieć pewność, że multimedia urządzenia nie będą mogły zostać zaszyfrowane przez nikogo oprócz urządzenia, 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 sieci Web JSON (JWE).

Aby zapewnić prawdziwe szyfrowanie kompleksowe za pośrednictwem naszej chmury, nie możemy angażować się w szyfrowanie i przesyłanie certyfikatu i klucza. Jeśli potrzebujesz tego poziomu bezpieczeństwa, musisz:

  1. Poproś o certyfikaty.

  2. Wygeneruj pary kluczy swoich certyfikatów.

  3. Utwórz (i zabezpiecz) wstępny klucz tajny dla każdego urządzenia, aby nasilić możliwości szyfrowania urządzenia.

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

    Proces i parametry (nietajne), których będziesz potrzebować, są wyjaśnione poniżej, a także receptura do zastosowania w wybranych narzędziach programistycznych. Udostępniamy również pewne dane testowe i wynikające z nich kopie 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 firmie Cisco na żądanie.

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

  6. Prześlij wynikowy blob JWE do urządzenia.

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

  8. (Zalecane) Zapewnij interfejs do (lub dystrybuuj) swojego narzędzia, aby umożliwić użytkownikom urządzeń zmianę początkowego klucza tajnego i ochronę ich multimediów przed Tobą.

Jak używać formatu JWE

W tej sekcji opisano, jak oczekujemy, że interfejs JWE będzie tworzony jako dane wejściowe do urządzeń, aby można było zbudować własne narzędzie do tworzenia pęcherzyków na podstawie certyfikatów i kluczy.

Patrz Szyfrowanie sieci Web JSON (JWE) https://datatracker.ietf.org/doc/html/rfc7516 i Podpis sieci Web JSON (JWS) https://datatracker.ietf.org/doc/html/rfc7515.

Używamy Kompaktowej serializacji dokumentu JSON do tworzenia blobs JWE. Parametry, które należy uwzględnić podczas tworzenia arkuszy JWE, to:

  • JOSE Header (chroniony). W nagłówku Podpisywanie i szyfrowanie obiektów JSON NALEŻY uwzględnić następujące pary klucz-wartość:

    • "alg":"dir"

      Algorytm bezpośredni jest jedynym, który obsługujemy do szyfrowania ładunku i musisz użyć początkowego klucza klienta urządzenia.

    • "enc":"A128GCM" lub "enc":"A256GCM"

      Obsługujemy te dwa algorytmy szyfrowania.

    • "cisco-action": "add" lub "cisco-action": "populate""cisco-action": "activate" lub "cisco-action": "deactivate"

      Jest to klucz zastrzeżony i cztery wartości, które może przyjąć. Wprowadziliśmy ten klucz, aby sygnalizować cel zaszyfrowanych danych do urządzenia docelowego. Wartości te są nazwane na podstawie poleceń xAPI na urządzeniu, na którym używane są zaszyfrowane dane.

      Nazwaliśmy ją 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. Podane wartości używamy jako danych wejściowych do pochodnej klucza na urządzeniu. version musi być 1 (wersja naszej kluczowej funkcji pochodnej). Wartość salt musi być sekwencją zakodowaną w formacie BASE64 o długości co najmniej 4 bajtów, którą należy wybrać losowo.

  • Klucz zaszyfrowany JWE. To pole jest puste. Urządzenie uzyskuje ją na podstawie początkowego ClientSecret.

  • Wektor inicjalizacji JWE. Do odszyfrowania ładunku należy podać wektor inicjalizacyjny zakodowany przez base64url. Wartość IV MUSI być losową wartością 12 bajtów (używamy rodziny szyfrów AES-GCM, która wymaga, aby długość IV wynosiła 12 bajtów).

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

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

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

    • Z "cisco-action":"populate" szyfrowaniem to nowa wersja ClientSecret.

    • Z „"cisco-action":"add" szyfrowaniem jest blob PEM przenoszący certyfikat i jego klucz prywatny (połączony).

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

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

  • Znacznik uwierzytelniania JWE: To pole zawiera znacznik uwierzytelniania w celu sprawdzenia integralności całego pliku blob z zwartą serializacją JWE

Jak uzyskujemy klucz szyfrowania z ClientSecret

Po pierwszej populacji tajemnicy nie akceptujemy ani nie wydajemy tajemnicy jako zwykłego tekstu. Ma to na celu zapobieganie potencjalnym atakom słownikowym przez osobę, która ma dostęp do urządzenia.

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

Oznacza to dla Ciebie, że Twoje narzędzie do produkcji blobs JWE musi postępować zgodnie z tą samą procedurą, aby uzyskać ten sam klucz szyfrowania/odszyfrowywania z tajnego klienta.

Urządzenia używają scrypt do pochodnej klucza (patrz https://en.wikipedia.org/wiki/Scrypt) z następującymi parametrami:

  • Współczynnik kosztów (N) to 32768

  • BlockSizeFactor (r) ma wartość 8

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

  • Sól to losowa sekwencja o długości co najmniej 4 bajtów; tę samą sekwencję należy podać salt podczas określania cisco-kdf parametru.

  • Długość klucza to 16 bajtów (jeśli wybierzesz algorytm AES-GCM 128) lub 32 bajty (jeśli wybierzesz algorytm AES-GCM 256)

  • Maks. czapka pamięci to 64 MB

Ten zestaw parametrów jest jedyną konfiguracją scrypt zgodną z funkcją pochodnej klucza na urządzeniach. Ten kdf na urządzeniach nosi nazwę "version":"1", która jest jedyną wersją aktualnie używaną przez cisco-kdf parametr.

Przykład przepracowany

Oto przykład, który można podać, aby zweryfikować, czy proces szyfrowania JWE działa tak samo, jak proces utworzony na urządzeniach.

Przykładowy scenariusz to dodanie blob PEM do urządzenia (naśladuje dodanie certyfikatu z bardzo krótkim ciągiem zamiast pełnego certyfikatu + klucz). Klucz tajny klienta w przykładzie to ossifrage.

  1. Wybierz szyfrowanie. W tym przykładzie użyto A128GCM (AES z 128-bitowymi kluczami w trybie licznika Galois). Możesz użyć tego narzędzia, 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. Adres URL Base64 zakoduj sekwencję, aby uzyskać 5eZTCAP4M_Y (usuń dopasowanie base64).

  3. Oto przykładowe scrypt połączenie w celu utworzenia klucza szyfrowania zawartoś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 (szesnastkowo) następująco:95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac , który base64 koduje adres lZ66bdEiAQV4_mqdInj_rA.

  4. Wybierz losową sekwencję 12 bajtów, która ma być użyta jako wektor inicjacyjny. W tym przykładzie użyto wartości szesnastkowej (szesnastkowej), 34 b3 5d dd 5f 53 7b af 2d 92 95 83 której base64url koduje adres NLNd3V9Te68tkpWD.

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

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

    Nagłówek JOSE zakodowany base64 to eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

    Będzie to pierwszy element blob JWE.

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

  7. Trzecim elementem blob JWE jest wektor inicjacyjny NLNd3V9Te68tkpWD.

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

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

    • Ładunek to this is a PEM file

    • Szyfrowanie: AES 128 GCM

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

    Adres URL Base64koduje zaszyfrowany ładunek, co powinno spowodować f5lLVuWNfKfmzYCo1YJfODhQ

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

  9. Base64url koduje znacznik utworzony w kroku 8, co powinno spowodować PE-wDFWGXFFBeo928cfZ1Q

    Jest to piąty element blob JWE.

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

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

  11. Jeśli uzyskasz te same wartości zakodowane base64url, jak pokazano tutaj, używając własnych narzędzi, możesz je wykorzystać do zabezpieczenia szyfrowania E2E i weryfikacji tożsamości Twoich urządzeń.

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

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

Typy sesji spotkań typu „brak zaufania” są dostępne dla wszystkich witryn spotkań bez dodatkowych kosztów. Jeden z tych typów sesji nosi nazwę Pro-End to End Encryption_VOIPonly. To jest nazwa usługi publicznej, którą możemy w przyszłości zmienić. Aby uzyskać bieżące nazwy typów sesji, zobacz Identyfikatory typów sesji w sekcji Odwołanie w tym artykule.

Nie musisz nic robić, aby uzyskać tę możliwość dla swojej witryny; musisz przydzielić użytkownikom nowy typ sesji (nazywany również uprawnieniami do spotkania). Możesz to zrobić indywidualnie na stronie konfiguracji użytkownika lub zbiorczo za pomocą eksportu/importu pliku CSV.

Zweryfikuj nowy typ sesji
1

Zaloguj się do Control Hub i wybierz kolejno pozycje Usługi > Spotkanie.

2

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

3

W części Ustawienia ogólne wybierz opcję Typy sesji.

Powinien być wyświetlany co najmniej jeden typ sesji szyfrowania kompleksowego. Zapoznaj się z listą identyfikatorów typów sesji w sekcji Odwołanie w tym artykule. Może to być na przykład opcja Pro-End to End Encryption_VOIPonly.

Istnieje starszy typ sesji o bardzo podobnej nazwie: Szyfrowanie Pro-End to End. Ten typ sesji obejmuje nieszyfrowany dostęp do spotkań przez sieć PSTN. Aby zapewnić kompleksowe szyfrowanie, upewnij się, że masz wersję _VOIPonly . To pole można sprawdzić, najeżdżając kursorem na łącze PRO w kolumnie kodu sesji; w tym przykładzie celem łącza powinno być javascript:ShowFeature(652).

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

4

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

Co zrobić 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 wybierz kolejno opcje Zarządzanie > Użytkownicy.

2

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

3

Z listy rozwijanej Ustawienia Zastosuj do wybierz witrynę spotkania do aktualizacji.

4

Zaznacz pole obok opcji Pro-End to End Encryption_VOIPonly.

5

Zamknij panel konfiguracji użytkownika.

6

W razie potrzeby powtórz tę czynność dla innych użytkowników.

Aby przypisać ją 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 i wybierz kolejno pozycje Usługi > Spotkanie.

2

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

3

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

4

Kliknij opcję Generuj raport i poczekaj na przygotowanie pliku.

5

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

6

Otwórz pobrany plik CSV do edycji.

Każdy użytkownik ma wiersz, a MeetingPrivilege kolumna zawiera identyfikatory typu sesji w postaci listy rozdzielonej przecinkami.

7

Dla każdego użytkownika, któremu chcesz nadać nowy typ sesji, dodaj 1561 jako nową wartość do listy rozdzielonej przecinkami w MeetingPrivilege .

Odwołanie do formatu pliku CSV usługi 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 była już na stronie Lista witryn spotkań, może być konieczne odświeżenie tej strony.

9

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

10

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

11

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

12

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

Dodaj znak wodny audio dla bezpieczeństwa

Do nagrań spotkań typu Webex Meetings Pro-End to End Encryption_VOIPonly sesji można dodać znak wodny, 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 uczestniczącego klienta lub urządzenia. Możesz przesłać nagrania audio do Control Hub, który następnie analizuje nagranie i wyszukuje unikatowe identyfikatory. Możesz przejrzeć wyniki, aby sprawdzić, który klient lub urządzenie źródłowe zarejestrowało spotkanie.

  • Aby mogło zostać przeanalizowane, nagranie musi być plikiem AAC, MP3, M4A, WAV, MP4, AVI lub MOV o rozmiarze nieprzekraczającym 500 MB.
  • Długość nagrania musi przekraczać 100 sekund.
  • Można 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 obszarze Zarządzanie wybierz pozycję Ustawienia organizacji.
  2. W sekcji Znaki wodne spotkania włącz opcję Dodaj znak wodny audio.

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

Przesyłanie i analizowanie spotkania oznaczonego wodnym

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

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

  8. Wybierz spotkanie z listy, aby zobaczyć wyniki analizy. Kliknij Przycisk Pobierz , aby pobrać wyniki.

Funkcje i ograniczenia

Czynniki uczestniczące w pomyślnym dekodowaniu nagranego znaku wodnego to odległość między urządzeniem nagrywającym a głośnikiem, głośność tego dźwięku, hałas otoczenia itp. Nasza technologia znakowania wodnego ma dodatkową odporność na wielokrotne kodowanie, co może się zdarzyć, gdy media są udostępniane.

Funkcja ta ma na celu umożliwienie pomyślnego 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óre leży na biurku w pobliżu osobistego punktu końcowego lub klienta laptopa, zawsze mogło utworzyć nagranie, które daje pomyślną analizę. Gdy urządzenie nagrywające odsuwa się od źródła lub jest przysłonięte od słyszenia pełnego spektrum dźwięku, zmniejsza się prawdopodobieństwo udanej analizy.

Aby skutecznie przeanalizować nagranie, potrzebne jest rozsądne przechwytywanie dźwięku ze spotkania. Jeśli dźwięk spotkania jest nagrywany na tym samym komputerze, na którym znajduje się klient, ograniczenia nie powinny mieć zastosowania.

Wdróż urządzenia (wewnętrzny urząd certyfikacji)

Jeśli Twoje urządzenia są już dołączone do organizacji Control Hub i chcesz użyć urzędu certyfikacji Webex do automatycznego generowania swoich certyfikatów identyfikacyjnych, nie musisz przywracać ustawień fabrycznych urządzeń.

Ta procedura wybiera domenę używane przez urządzenie do identyfikacji siebie i jest wymagana tylko wtedy, gdy w organizacji Control Hub jest wiele domen. Jeśli masz więcej niż jedną domenę, zalecamy wykonanie tej operacji dla wszystkich urządzeń, które będą miały tożsamość „zweryfikowaną przez Cisco”. Jeśli nie powiesz firmie Webex, która domena identyfikuje urządzenie, jedna z nich jest wybierana automatycznie i może wyglądać źle dla innych uczestników spotkania.

Przed rozpoczęciem

Jeśli Twoje urządzenia nie zostały jeszcze wdrożone, przejdź do sekcji Zarejestruj urządzenie w usłudze Cisco Webex za pomocą interfejsu API lub lokalnego interfejsu WWW lub Wdrażanie w chmurze dla urządzeń z serii Board, Desk i Room. Należy również zweryfikować domeny, których chcesz użyć do identyfikacji urządzeń w sekcji Zarządzaj swoimi domenami.

1

Zaloguj się do Control Hub i w obszarze Zarządzanie wybierz opcję Urządzenia.

2

Wybierz urządzenie, aby otworzyć panel konfiguracji.

3

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

4

Powtórz tę czynność dla innych urządzeń.

Dołączanie urządzeń (zewnętrzny urząd certyfikacji)

Przed rozpoczęciem

  • Uzyskaj certyfikat podpisany przez urząd certyfikacji i klucz prywatny w .pem formacie 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 dotyczące tam informacji.

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

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

  • Upewnij się, że masz scrypt wdrożenie.

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

1

Wypełnij elementy ClientSecret urządzenia zwykłym tekstem tajnym:

Przy pierwszym wypełnieniu pola Secret należy go podać zwykłym tekstem. Dlatego zalecamy uruchomienie tej funkcji w konsoli urządzeń fizycznych.

  1. Adres URL Base64koduje tajną frazę dla tego urządzenia.

  2. Otwórz TShell na urządzeniu.

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

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

Urządzenie ma swój początkowy klucz tajny. Nie zapomnij o tym; nie możesz go odzyskać i aby ponownie uruchomić urządzenie, konieczne jest przywrócenie ustawień fabrycznych.
2

Połącz certyfikat i klucz prywatny:

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

    To jest tekst ładunku, który zostanie zaszyfrowany i umieszczony w pliku JWE.

3

Utwórz blok JWE, który będzie używany jako dane wejściowe do polecenia dodaj certyfikat:

  1. Utwórz losową sekwencję o długości co najmniej 4 bajtów. To jest twoja sól.

  2. Uzyskiwanie klucza szyfrowania treści za pomocą narzędzia scrypt.

    W tym celu potrzebny jest klucz tajny, sól i długość klucza, które pasują do wybranego szyfrowania. Istnieją inne stałe wartości do podania (N=32768, r=8, p=1). W celu uzyskania tego samego klucza szyfrowania zawartości urządzenie korzysta z tego samego procesu i wartości.

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

  4. Utwórz nagłówek JOSE, ustawienie alg, enc i cisco-kdf klucze zgodnie z opisem w Zrozumienie procesu tożsamości zewnętrznej dla urządzeń. Ustaw czynność „dodaj” przy użyciu klucza:wartość "cisco-action":"add" w nagłówku JOSE (ponieważ dodajemy certyfikat do urządzenia).

  5. Nagłówek JOSE jest kodowany przez Base64url.

  6. Użyj narzędzia szyfrowania JWE z wybranym nagłówkiem JOSE zakodowanym przez base64url do szyfrowania tekstu z połączonego pliku pem.

  7. Adres URL Base64koduje wektor inicjacyjny, zaszyfrowany ładunek PEM i znacznik uwierzytelniania.

  8. Skonfiguruj blok JWE w następujący sposób (wszystkie wartości są zakodowane jako base64url):

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4

Otwórz TShell na urządzeniu i uruchom polecenie dodawania (wieloliniowego): 

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

Sprawdź, czy certyfikat został dodany przez uruchomienie xcommand Security Certificates Services Show

Skopiuj odcisk palca nowego certyfikatu.

6

Aktywuj certyfikat w celu WebexIdentity:

  1. Odcisk palca certyfikatu należy odczytywać z samego certyfikatu lub z wyniku działania aplikacji xcommand Security Certificates Services Show.

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

  3. Uzyskiwanie klucza szyfrowania treści za pomocą narzędzia scrypt.

    W tym celu potrzebny jest klucz tajny, sól i długość klucza, które pasują do wybranego szyfrowania. Istnieją inne stałe wartości do podania (N=32768, r=8, p=1). W celu uzyskania tego samego klucza szyfrowania zawartości urządzenie korzysta z tego samego procesu i wartości.

  4. Utwórz losową sekwencję dokładnie 12 bajtów i zakoduj tę sekwencję base64url. To jest twój wektor inicjacyjny.

  5. Utwórz nagłówek JOSE, ustawienie alg, enc i cisco-kdf klucze zgodnie z opisem w Zrozumienie procesu tożsamości zewnętrznej dla urządzeń. Ustaw akcję „aktywuj” przy użyciu klucza:wartość "cisco-action":"activate" w nagłówku JOSE (ponieważ aktywujemy certyfikat na urządzeniu).

  6. Nagłówek JOSE jest kodowany przez Base64url.

  7. Do szyfrowania odcisku palca certyfikatu użyj narzędzia szyfrowania JWE z wybranym szyfrowaniem i nagłówkiem JOSE zakodowanym przez base64url.

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

  8. Kod URL Base64 zaszyfrowany odcisk palca i znacznik uwierzytelniania.

  9. Skonfiguruj blok JWE w następujący sposób (wszystkie wartości są zakodowane jako 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 ma zaszyfrowany, aktywny, wystawiony przez urząd certyfikacji certyfikat, gotowy do użycia do identyfikacji go w spotkaniach Webex z kompleksowym szyfrowaniem.
7

Dodaj urządzenie do organizacji Control Hub.

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

Zaplanuj spotkanie poprawnego typu (Webex Meetings Pro-End to End Encryption_VOIPonly).

Zobacz Planowanie spotkania Webex z szyfrowaniem kompleksowym.

2

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

Zobacz Dołączanie do spotkania Webex z szyfrowaniem kompleksowym.

3

Dołącz do spotkania z urządzenia, które ma tożsamość zweryfikowaną przez urząd certyfikacji Webex.

4

Jako prowadzący sprawdź, czy to urządzenie jest wyświetlane w poczekalni przy użyciu poprawnej ikony tożsamości.

Zobacz Dołączanie do spotkania Webex z szyfrowaniem kompleksowym.

5

Dołącz do spotkania przy użyciu urządzenia, które ma tożsamość zweryfikowaną przez zewnętrzny urząd certyfikacji.

6

Jako prowadzący sprawdź, czy to urządzenie jest wyświetlane w poczekalni przy użyciu poprawnej ikony tożsamości. Dowiedz się więcej o ikonach tożsamości.

7

Dołącz do spotkania jako nieuwierzytelniony uczestnik spotkań.

8

Jako prowadzący sprawdź, czy ten uczestnik jest wyświetlany w poczekalni przy użyciu ikony poprawnej tożsamości.

9

Jako gospodarz wpuszczaj lub odrzucaj osoby/urządzenia.

10

W miarę możliwości weryfikuj tożsamości uczestników/urządzeń, sprawdzając certyfikaty.

11

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

12

Dołącz do spotkania z nowym uczestnikiem.

13

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

Ustaw zakres i oczekiwania

  • Czy chcesz, aby spotkania z szyfrowaniem kompleksowym były domyślną opcją spotkań, czy włączyć ją tylko dla niektórych użytkowników, czy zezwolić wszystkim prowadzącym na podejmowanie decyzji? Po podjęciu decyzji o sposobie użycia tej funkcji przygotuj użytkowników, którzy będą z niej korzystać, zwłaszcza jeśli chodzi o ograniczenia i oczekiwania podczas spotkania.

  • Czy musisz mieć pewność, że ani firma Cisco, ani inne osoby nie będą mogły odszyfrować Twojej zawartości ani podszywać się pod Twoje urządzenia? W takim przypadku wymagane są certyfikaty z publicznego urzędu certyfikacji.

  • Jeśli masz różne poziomy weryfikacji tożsamości, upoważnij użytkowników do wzajemnej weryfikacji za pomocą tożsamości wspieranej certyfikatem. Mimo że istnieją okoliczności, w których uczestnicy mogą wydawać się niezweryfikowani, a uczestnicy powinni wiedzieć, jak to sprawdzić, niezweryfikowani ludzie mogą nie być oszustami.

Zarządzanie tożsamościami

Jeśli używasz zewnętrznego urzędu certyfikacji do wystawiania certyfikatów urządzeń, ciężar monitorowania, odświeżania i ponownego stosowania certyfikatów spoczywa na Tobie.

Jeśli utworzono początkowy klucz tajny, należy pamiętać, że użytkownicy mogą zmienić klucz tajny swojego urządzenia. Aby to umożliwić, może być konieczne utworzenie interfejsu/udostępnienie narzędzia.

Identyfikatory typów sesji
Tabela 1. Identyfikatory typu sesji w przypadku spotkań z szyfrowaniem kompleksowym

Identyfikator typu sesji

Nazwa usługi publicznej

638

Szyfrowanie E2E i tylko VoIP

652

Tylko Encryption_VOIPonly w trybie „pro-end”

660

Wersja Pro 3 Bezpłatna obsługa tylko VOIPncryption_od końca do końca

Szyfrowanie E2E + tożsamość

672

Pro 3 Free50-End to End Encryption_VOIPonly

673

Instruktor edukacji E2E Encryption_VOIPonly

676

Szyfrowanie kompleksowe BroadWorks Standard oraz

677

Szyfrowanie kompleksowe BroadWorks Premium plus

681

Schoology Free oraz szyfrowanie kompleksowe

Powiązane polecenia xAPI

W tych tabelach opisano polecenia interfejsu API urządzeń Webex dodane do spotkań z szyfrowaniem kompleksowym 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 Webex Board.

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

  • Zarejestrowane w Webex

  • Zarejestrowane w siedzibie i połączone z Webex za pomocą Webex Edge for Devices

Tabela 2. Interfejsy API poziomu systemu do spotkań z szyfrowaniem kompleksowym i zweryfikowanej tożsamości

Wywołanie API

Opis

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

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

Urządzenie używa tej domeny podczas żądania certyfikatu z urzędu certyfikacji Webex. Następnie domena identyfikuje urządzenie.

Ta konfiguracja nie ma zastosowania, gdy urządzenie ma aktywny, wydany zewnętrznie certyfikat umożliwiający własną identyfikację.

xStatus Conference EndToEndEncryption Availability

Określa, czy urządzenie może dołączyć do spotkania z szyfrowaniem kompleksowym. Interfejs API chmury dzwoni do niego, aby sparowana aplikacja wiedziała, czy może użyć urządzenia, aby dołączyć.

xStatus Conference EndToEndEncryption ExternalIdentity Verification

Wskazuje, czy urządzenie korzysta z funkcji External weryfikacji (ma certyfikat wydany zewnętrznie).

xStatus Conference EndToEndEncryption ExternalIdentity Identity

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

xStatus Conference EndToEndEncryption ExternalIdentity CertificateChain Certificate # specificinfo

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

W wyświetlonym poleceniu zamień # na numer certyfikatu. Zastąp specificinfo jednym z następujących elementów:

  • 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 zewnętrznej tożsamości urządzenia (np. valid lub error).

xStatus Conference EndToEndEncryption InternalIdentity Verification

Określa, 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 wydanego przez Webex.

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

Pole jest puste, jeśli organizacja nie ma domeny.

Jeśli urządzenie należy do organizacji mającej wiele domen, jest to wartość z PreferredDomain.

xStatus Conference EndToEndEncryption InternalIdentity CertificateChain Certificate # specificinfo

Odczytuje określone informacje z certyfikatu wystawionego przez Webex.

W wyświetlonym poleceniu zamień # na numer certyfikatu. Zastąp specificinfo jednym z następujących elementów:

  • 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. W interfejsach API połączeń do spotkań z szyfrowaniem kompleksowym i zweryfikowanej tożsamości

Wywołanie API

Opis

xEvent Conference ParticipantList ParticipantAdded

xEvent Conference ParticipantList ParticipantUpdated

xEvent Conference ParticipantList ParticipantDeleted

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

Tabela 4. Interfejsy API związane z ClientSecret do spotkań z szyfrowaniem kompleksowym i zweryfikowaną tożsamością

Wywołanie API

Opis

xCommand Security ClientSecret Populate Secret: "base64url-encoded"

lub

xCommand Security ClientSecret Populate Secret: JWEblob

Akceptuje zwykły tekst zakodowany w standardzie base64url służący do umieszczenia klucza tajnego klienta na urządzeniu po raz pierwszy.

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

xCommand Security Certificates Services Add JWEblob

Dodaje certyfikat (z kluczem prywatnym).

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

xCommand Security Certificates Services Activate Purpose:WebexIdentity FingerPrint: JWEblob

Aktywuje określony certyfikat dla usługi WebexIdentity. W tym celu Purposepolecenie wymaga zaszyfrowania i serializacji identyfikacyjnego odcisku palca w pliku JWE.

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

Dezaktywuje określony certyfikat dla usługi WebexIdentity. W tym celu Purposepolecenie wymaga zaszyfrowania i serializacji identyfikacyjnego odcisku palca w pliku JWE.