Benutzer wählen die neue Option Meeting-Typ, wenn sie ein Meeting anplanen. Beim Zulassen von Teilnehmern aus der Lobby und während des Treffens kann der Gastgeber den Identitätsverifizierungsstatus jedes Teilnehmers sehen. Außerdem gibt es einen Meeting-Code, den alle aktuellen Teilnehmer im Meeting gemeinsam nutzen können, um sich gegenseitig zu überprüfen.

Geben Sie die folgenden Informationen an die Gastgeber Ihres Meeting weiter:

Identität wird überprüft

durchgängig Identitätsverifizierung bietet zusätzliche Sicherheit für ein End-to-End verschlüsseltes Meeting.

Wenn Teilnehmer oder Geräte einer geteilten TIBS (Messaging Layer Security)-Gruppe beitreten, präsentieren sie ihre Zertifikate den anderen Gruppenmitgliedern, die die Zertifikate dann gegen die Ausstellende Certificate Authority/ies (CA) validieren. Durch die Bestätigung, dass die Zertifikate gültig sind, überprüft die CA die Identität der Teilnehmer und das Meeting zeigt die Teilnehmer / Geräte als verifiziert an.

Benutzer des Webex Meetings-App sich gegenüber dem Webex-Identitätsspeicher authentifizieren, der ihnen ein Zugriffstoken aus gibt, wenn sie erfolgreich sind. Wenn sie ein Zertifikat benötigen, um ihre Identität zu überprüfen – in einem End-to-End-verschlüsselten Meeting – gibt die Webex-Zertifizierungsstelle ein Zertifikat basierend auf ihrem Zugriffstoken aus. Es ist noch nicht so, dass benutzer Webex Meetings ein Zertifikat erhalten können, das von einer externen Zertifizierungsstelle ausgestellt wurde.

Geräte können sich selbst mit einem Zertifikat authentifizieren, das von einer internen (Webex)-Zertifizierungsstelle ausgestellt wurde, oder mit einem Zertifikat, das von einer externen Zertifizierungsstelle ausgestellt wurde:

  • Für den internen CA-Fall gibt Webex ein internes Zertifikat aus, das auf dem Zugriffstoken des Computerkontos des Geräts basiert. Das Zertifikat wurde von der Webex-Zertifizierungsstelle signiert. Geräte haben keine Benutzer-IDs auf die gleiche Weise wie Benutzer, daher verwendet Webex (eine der) Domänen Ihrer Organisation beim Schreiben der Identität des Gerätezertifikats (Common Name (CN)).

  • Für den externen CA-Fall fordern Sie Gerätezertifikate direkt beim ausgewählten Aussteller an und erwerben diese. Sie müssen die Zertifikate verschlüsseln, direkt hochladen und autorisieren, indem Sie ein geheimes, nur Ihnen bekanntes Zertifikat verwenden.

    Cisco ist nicht beteiligt. Auf diese Weise kann eine echte End-to-End-Verschlüsselung und verifizierte Identität garantiert werden, und es wird verhindert, dass Cisco das Meeting abhören oder Ihre Medien entschlüsseln könnte.

Intern ausgestelltes Gerätezertifikat

Webex gibt ein Zertifikat für das Gerät aus, wenn es nach dem Start registriert wird, und erneuert es bei Bedarf. Bei Geräten umfasst das Zertifikat die Konto-ID und eine Domäne.

Wenn Ihre Organisation über keine Domäne verfügt, gibt die Webex-Zertifizierungsstelle das Zertifikat ohne Domäne aus.

Wenn Ihre Organisation über mehrere Domänen verfügt, können Sie Control Hub verwenden, um Webex darüber zu informieren, welche Domäne das Gerät für seine Identität verwenden soll. Sie können auch die API xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com" definiert.

Wenn Sie mehrere Domänen haben und keine bevorzugte Domäne für das Gerät festlegen, wählt Webex eine für Sie aus.

Extern ausgestelltes Gerätezertifikat

Ein Administrator kann ein Gerät mit einem eigenen Zertifikat bereitstellen, das mit einer der öffentlichen Zertifizierungsstelle signiert wurde.

Das Zertifikat muss auf einem ECDSA P-256-Schlüsselpaar basieren, obwohl es mit einem RSA-Schlüssel signiert werden kann.

Die Werte im Zertifikat liegen in der Diskretion der Organisation. Der allgemeine Name (CN) und Betreff für alternativen Namen (SAN) werden in der Webex-Meeting-Benutzeroberfläche angezeigt, wie unter End-to-End-Verschlüsselung mit Identitätsverifizierung fürWebex Meetings.

Es wird empfohlen, ein separates Zertifikat pro Gerät zu verwenden und einen eindeutigen CN pro Gerät zu verwenden. Dies wäre beispielsweise ein "meeting-room-1.example.com" für die Organisation, die die Domäne "example.com" besitzt.

Um das externe Zertifikat vollständig vor Manipulationen zu schützen, wird eine geheime Client-Funktion verwendet, um verschiedene xcommands zu verschlüsseln und zu signieren.

Beim Verwenden des Client-Schlüssels ist es möglich, das externe Webex-Identitätszertifikat über xAPI sicher zu verwalten. Dies ist derzeit auf Online-Geräte beschränkt.

Derzeit bietet Webex API-Befehle zur Verwaltung dieses Themas.

Geräte

Cloud-registrierte Webex Room serie und Webex Desk-Serie können End-to-End-verschlüsselte Meetings beitreten, darunter:

  • Webex Board

  • Webex Desk Pro

  • Webex-Tisch

  • Webex Room Kit

  • Webex Room Kit Mini

Die folgenden Geräte können dem Ende nicht beitreten, um verschlüsselte Meetings zu beenden:

  • Webex C-Serie

  • Webex DX-Serie

  • Webex EX-Serie

  • Webex MX-Serie

  • SIP-Geräte von Drittanbietern

Software-Clients

  • Ab 41.7 kann Webex Meetings Desktop-Client End-to-End-verschlüsselten Meetings beitreten.

  • Die Webex-App kann end-to-End-verschlüsselten Meetings nicht beitreten.

    Wenn Ihre Organisation die Webex-App zum Beitreten zu Meetings über das Starten der Meetings-Desktopanwendung ermöglicht, können Sie diese Option verwenden, um end-to-End-verschlüsselten Meetings beizunehmen.

  • Der Webex-Web-Client kann nicht an End-to-End-verschlüsselten Meetings teilnehmen.

  • SIP-Soft-Clients von Drittanbietern können nicht an End-to-End-verschlüsselten Meetings teilnehmen.

Identität

  • Wir bieten keine Control Hub-Optionen für Sie, um extern verifizierte Geräteidentitäten zu verwalten. Diese Entscheidung ist von Entwurf, da für eine echte End-to-End-Verschlüsselung nur Sie sollten die geheimen Informationen und Schlüssel kennen/zugreifen. Wenn wir einen Clouddienst zur Verwaltung dieser Schlüssel eingeführt haben, besteht die Möglichkeit, dass sie abgefangen werden.

  • Derzeit stehen Ihnen keine Tools zur Verfügung, mit deren Hilfe Sie Geräteidentitätszertifikate und deren private Schlüssel anfordern oder verschlüsseln können. Im Moment bieten wir ein Rezept für Sie an, um Ihre eigenen Tools zu entwickeln, die auf den Industriestandard-Verschlüsselungstechniken basieren, um sie bei diesen Prozessen zu unterstützen. Wir möchten keinen tatsächlichen oder tatsächlichen Zugriff auf Ihre Geheimen oder Schlüssel haben.

Meetings

  • durchgängig verschlüsselte Meetings unterstützen derzeit bis zu 200 Teilnehmer.

  • Von diesen 200 Teilnehmern können maximal 25 extern verifizierte Geräte beitreten, und sie müssen die ersten Teilnehmer sein, die dem Meeting beitretenkönnen.

    Wenn mehr Geräte einem Meeting beitreten, versuchen unsere Backend-Mediendienste, die Medienstreams zu transkodieren. Wenn wir die Medien nicht entschlüsseln, transkodieren und erneut verschlüsseln können (da die Verschlüsselungsschlüssel der Geräte nicht verfügbar sind und sollten), dann schlägt die Transkodierung fehl.

    Um diese Einschränkung zu minimieren, empfehlen wir kleinere Meetings für Geräte oder die Einladungen zwischen Geräten und Meetings-Clients zu sggern.

Verwaltungsoberfläche

Wir empfehlen Ihnen dringend, Control Hub zu verwenden, um Ihre Meeting-Site zu verwalten.

Der Hauptgrund dafür ist der Unterschied zwischen der Art und Weise, wie Control Hub und Site-Administration Verwalten der Identität. Control Hub-Organisationen haben eine zentrale Identität für die gesamte Organisation, während Site-Administration Identität auf Site-Basis gesteuert wird.

Dies bedeutet, dass Sie die Option von Cisco-verifizierter Identität für Benutzer, die von einem Unternehmen verwaltet werden, nicht Site-Administration. Diese Benutzer erhalten ein anonymes Zertifikat, um an einem End-to-End-verschlüsselten Meeting teilzunehmen, und sie können von Meetings ausgeschlossen werden, in denen der Gastgeber die Identität sicherstellen möchte.

Verwandte Informationen

Abwöhnung von Beispielen für JWE-Test

Beispiel für korrekt verschlüsselte JWE basierend auf bestimmten Parametern (Anhang)

  • Webex Meetings 41.7.

  • Cloud-registrierte Webex Room- und Webex Desk-Serie, ausgeführt 10.6.1-RoomOS_August_2021 definiert.

  • Administrativer Zugriff auf die Meeting-Site in Control Hub, um die neue Sitzungstyp für Benutzer zu aktivieren.

  • Eine oder mehrere verifizierte Domänen in Ihrer Control Hub-Organisation (wenn Sie die Webex-CA verwenden, um Gerätezertifikate für die verifizierte Identität auszugeben).

Sie können diesen Schritt überspringen, wenn Sie keine extern verifizierte Identität benötigen.

Für ein Höchstmaß an Sicherheit und Identitätsverifizierung sollte jedes Gerät über ein eindeutiges Zertifikat verfügen, das von einer vertrauenswürdigen öffentlichen Zertifizierungsstelle ausgestellt wurde.

Sie müssen mit der Zertifizierungsstelle interagieren, um die digitalen Zertifikate anfordern, erwerben und empfangen und die zugehörigen privaten Schlüssel erstellen zu können. Beim Anfordern des Zertifikats müssen die folgenden Parameter verwendet werden:

  • Das Zertifikat muss von einer bekannten öffentlichen Zertifizierungsstelle ausgestellt und signiert sein.

  • Einzigartige: Wir empfehlen dringend, für jedes Gerät ein eindeutiges Zertifikat zu verwenden. Wenn Sie für alle Geräte ein Zertifikat verwenden, wird Ihre Sicherheit beeinträchtigt.

  • Gemeinsamer Name (CN) und Subject Alternate Name/s (SAN/s): Dies ist für Webex nicht wichtig, sondern sollte Werte sein, die Menschen lesen und sich mit dem Gerät verbinden können. Der CN wird anderen Meeting-Teilnehmern als primäre verifizierte Identität des Geräts angezeigt. Wenn Benutzer das Zertifikat über die Meeting-Benutzeroberfläche überprüfen, wird die SAN/s angezeigt. Vielleicht möchten Sie Namen wie name.model@example.com aber Sie haben die Wahl.

  • Dateiformat: Die Zertifikate und Schlüssel müssen das Format .pem haben.

  • Zweck: Der Zweck des Zertifikats muss Webex Identity sein.

  • Schlüssel werden generiert: Die Zertifikate müssen auf ECDSA P-256-Schlüsselpaaren basieren (Elliptical Curve Digital Signature Algorithm mit P-256-Taste).

    Diese Anforderung erstreckt sich nicht über den Signierschlüssel. Die CA kann zum Signieren des Zertifikats einen RSA-Schlüssel verwenden.

Sie können diesen Schritt überspringen, wenn Sie keine extern verifizierte Identität mit Ihren Geräten verwenden möchten.

Wenn Sie neue Geräte verwenden, registrieren Sie sie noch nicht bei Webex. Es ist am einfachsten, sie noch nicht einmal mit dem Netzwerk zu verbinden.

Wenn Sie vorhandene Geräte haben, die Sie aktualisieren möchten, um extern verifizierte Identität zu verwenden, müssen Sie die Geräte auf die Werkseinstellungen zurücksetzen.

  • Speichern Sie die vorhandene Konfiguration, wenn Sie sie behalten möchten.

  • Setzen Sie ein Fenster an, wenn die Geräte nicht verwendet werden, oder setzen Sie einen schrittweisen Ansatz ein. Informieren Sie die Benutzer über die zu erwartenden Änderungen.

  • Stellen Sie den physischen Zugriff auf Geräte sicher. Wenn Sie über das Netzwerk auf Geräte zugreifen müssen, beachten Sie, dass Geheimreisen im Klartext sind und Ihre Sicherheit beeinträchtigt wird.

Um sicherzustellen, dass Ihre Gerätemedien nicht von anderen Personen als dem Gerät verschlüsselt werden können, müssen Sie den privaten Schlüssel auf dem Gerät verschlüsseln. Wir haben APIs für das Gerät entwickelt, um die Verwaltung des verschlüsselten Schlüssels und Zertifikats mittels JSON Web Encryption (JWE) zu ermöglichen.

Um eine echte End-to-End-Verschlüsselung über unsere Cloud zu gewährleisten, dürfen wir uns nicht in die Verschlüsselung und das Hochladen des Zertifikats und des Schlüssels engagieren. Wenn Sie diese Sicherheitsstufe benötigen, sollten Sie:

  • Fordern Sie Ihre Zertifikate an.

  • Generieren Sie die Schlüsselpaare Ihrer Zertifikate.

  • Erstellen (und schützen) Sie ein initiales Schlüssel für jedes Gerät, um die Verschlüsselungsfunktionen des Geräts zu erstellen.

  • Entwickeln und pflegen Sie Ihr eigenes Tool zum Verschlüsseln von Dateien mit dem JWE-Standard.

    Unten werden der Prozess und die (nicht geheimen) Parameter erläutert, die Sie benötigen, und ein Rezept, dass Sie in Ihren Entscheidungstools befolgen können. Außerdem stellen wir ihnen einige Testdaten und die sich daraus ergibten JWE-Tests zur Verfügung, um Ihnen zu helfen, Ihren Prozess zu überprüfen.

    Eine nicht unterstützte Referenzimplementierung mit Python3 und der JWCrypto-Bibliothek ist bei Cisco auf Anfrage verfügbar.

  • Erstellen Sie mit Ihrem Tool und dem initialen Schlüssel des Geräts eine Verbindung zu Zertifikat und Schlüssel und verschlüsseln Sie diese.

  • Laden Sie die resultierende JWE-Datei auf das Gerät hoch.

  • Legen Sie den Zweck des verschlüsselten Zertifikats fest, das für die Webex-Identität verwendet werden soll, und aktivieren Sie das Zertifikat.

  • (Empfohlen) Stellen Sie eine Schnittstelle für (oder verteilung) Ihres Tools bereit, über die Gerätebenutzer die anfänglichen Geheimen ändern können (um ihre Medien vor Ihnen zu schützen!).

Verwendung des JWE-Formats

Dieser Abschnitt beschreibt, wie die JWE als Input für die Geräte erstellt wird, sodass Sie Ihr eigenes Tool erstellen können, um die Werkzeuge aus Ihren Zertifikaten und Schlüsseln zu erstellen.

Sie müssen auf JSON Web Encryption (JWE) undhttps://datatracker.ietf.org/doc/html/rfc7516 JSON Web Signature (JWS)https://datatracker.ietf.org/doc/html/rfc7515verweisen.

Wir haben uns entschieden, die kompakte Serialisierung eines JSON-Dokuments zur Erstellung von JWE-Dateien zu verwenden. Folgende Parameter müssen beim Erstellen von JWE-Einstellungen verwendet werden:

  • JOSE Header (geschützt). In der JSON-Objektsignier- und Verschlüsselungskopfzeile müssen Sie die folgenden Schlüsselwert-Paare enthalten:

    • "alg":"dir"

      Der direkte Algorithmus ist der einzige Algorithmus, den wir zur Verschlüsselung der Nutzlast unterstützen. Sie müssen den anfänglichen Clientschlüssel des Geräts verwenden.

    • "enc":"A128GCM" oder "enc":"A256GCM"

      Wir unterstützen diese beiden Verschlüsselungsalgorithmen.

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

      Dabei handelt es sich um einen proprietären Schlüssel und vier wichtige Werte. Wir haben diesen Schlüssel eingeführt, um den Zweck der verschlüsselten Daten an das Zielgerät zu signalisieren. Die Werte werden nach den xAPI-Befehlen auf dem Gerät benannt, auf dem Sie die verschlüsselten Daten verwenden.

      Wir haben ihn benannt cisco-action um potenzielle Konflikts mit zukünftigen JWE-Erweiterungen zu minimieren.

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

      Ein anderer proprietärer Schlüssel. Wir verwenden die von Ihnen angegebenen Werte als Eingänge für die Tastenzung auf dem Gerät. Das Symbol version muss 1(die Version unserer Schlüsselfunktion). Der Wert von salt muss eine base64-URL-codierte Sequenz von mindestens 4 Byte sein, die Sie nach dem Zufallsprinzip auswählen müssen.

  • JWE Verschlüsselter Schlüssel. Dieses Feld ist leer. Das Gerät leitet es von der Initiale ab ClientSecret definiert.

  • JWE Initialisierungs-Vektor. Sie müssen einen base64url-verschlüsselten Initialisierungs vektorisieren, um die Nutzdatendaten zu entschlüsseln. Die IV MUSS ein beliebiger Bytewert von 12 Byte sein (wir verwenden die AES-GCM-Cipher-Familie, die erfordert, dass die IV 12 Byte lang ist).

  • JWE AAD (zusätzliche authentifizierte Daten). Sie müssen dieses Feld auslassen, da es in der kompakten Serialisierung nicht unterstützt wird.

  • JWE-Verschlüsselung: Dies ist die verschlüsselte Nutzlast, die Sie geheim halten möchten.

    Die Nutzlast ist möglicherweise leer (Um beispielsweise den Client-Schlüssel zurückzusetzen, müssen Sie ihn mit einem leeren Wert überschreiben).

    Je nachdem, was Sie auf dem Gerät zu tun versuchen, gibt es unterschiedliche Arten von Nutzdaten. Verschiedene xAPI-Befehle erwarten unterschiedliche Nutzdatendaten, und Sie müssen den Zweck der Nutzlast mit dem cisco-action Schlüssel, wie folgt:

    • Mit "cisco-action":"populate" Der Verschlüsselungstext ist das neue ClientSecret

    • Mit " "cisco-action":"add" Der Verschlüsselungstext ist ein PEM-Schlüssel, der das Zertifikat und seinen privaten Schlüssel (zusammengekniffen) enthält.

    • Mit " "cisco-action":"activate" Der Verschlüsselungstext ist der Fingerabdruck (Hexadezimale Darstellung von Sha-1) des Zertifikats, das wir für die Verifizierung der Geräteidentität aktivieren

    • Mit " "cisco-action":"deactivate" Der Verschlüsselungstext ist der Fingerabdruck (Hexadezimale Wiedergabe von Sha-1) des Zertifikats, das wir für die Geräteidentitätsüberprüfung deaktivieren.

  • JWE-Authentifizierungs-Tag: Dieses Feld enthält das Authentifizierungs-Tag, um die Integrität der gesamten kompakt serialisierten JWE-Serie zu gewährleisten.

Wie wir den Chiffrierschlüssel von ClientSecret

Nach der ersten Einwohner des Geheimen akzeptieren oder geben wir das Geheime nicht als Klartext an oder geben es aus. Damit verhindern Sie potenzielle Wörterbuch-Attacken von jemandem, der auf das Gerät zugreifen konnte.

Die Gerätesoftware verwendet den Clientschlüssel als Input für eine Schlüsselfunktion (kdf) und verwendet dann den abgeleiteten Schlüssel für die Entschlüsselung/Verschlüsselung von Inhalten auf dem Gerät.

Das bedeutet für Sie, dass Ihr Tool zur Erstellung von JWE-Dateien dasselbe Verfahren befolgen muss, um denselben Verschlüsselungs-/Entschlüsselungsschlüssel aus dem Clientschlüssel zu erhalten.

Die Geräte verwenden Scrypt für Schlüsselinzug (siehe https://en.wikipedia.org/wiki/Scrypt) mit den folgenden Parametern:

  • CostFactor (N) ist 32768

  • BlockSizeFactor (r) ist 8

  • ParallelizationFactor (p) ist 1

  • Es handelt sich um eine zufällige Folge von mindestens 4 Byte; Sie müssen dies auch tun salt beim Festlegen des cisco-kdf verwenden.

  • Schlüssellängen sind entweder 16 Byte (wenn Sie den AES-GCM 128-Algorithmus auswählen) oder 32 Byte (wenn Sie den Algorithmus AES-GCM 256 auswählen)

  • Maximale Speicher cap ist 64 MB

Diese Reihe von Parametern ist die einzige Konfiguration von Scrypt, die mit der Schlüsselfunktion auf den Geräten kompatibel ist. Dieses kdf-Gerät wird auf den Geräten angerufen "version":"1", die aktuell von der cisco-kdf verwenden.

Bearbeitetes Beispiel

Hier ein Beispiel dafür, wie Sie überprüfen können, ob das JWE-Verschlüsselungsverfahren genauso funktioniert wie das auf den Geräten erstellte Verfahren.

Das Beispielszenario ist das Hinzufügen eines PEM-Schlüssels zum Gerät (imitiert das Hinzufügen eines Zertifikats, mit einem sehr kurzen String anstelle eines vollständigen Zertifikats + Schlüssels). Der geheime Client in dem Beispiel ist ossifrage definiert.

  1. Wählen Sie eine Verschlüsselungsverschlüsselung aus. In diesem Beispiel wird A128GCM(AES mit 128-Bit-Tasten im Galois-Zählermodus). Ihr Tool könnte A256GCM wenn Sie es bevorzugen.

  2. Wählen Sie eine Beliebige (muss eine zufällige Sequenz von mindestens 4 Byte sein). In diesem Beispiel wird (Hex-Bytes) verwendet E5 E6 53 08 03 F8 33 F6 definiert. Base64url kodieren die Sequenz, um 5eZTCAP4M_Y(entfernen Sie die Basis-64-Platte).

  3. Hier ein Beispiel scrypt Anrufen, um die Inhalte zu Chiffrierschlüssel (cek):

    cek=scrypt(password="ossifrage", salt=4-byte-sequence, N=32768, r=8, p=1, keylength=16)

    Der abgeleitete Schlüssel sollte 16 Bytes (Hex) wie folgt sein: 95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac mit dem base64url kodiert lZ66bdEiAQV4_mqdInj_rA definiert.

  4. Wählen Sie eine zufällige Sequenz von 12 Byte, die als Initialisierungsvektor verwendet werden soll. In diesem Beispiel wird (Hex) verwendet. 34 b3 5d dd 5f 53 7b af 2d 92 95 83 mit dem base64url kodiert NLNd3V9Te68tkpWD definiert.

  5. Erstellen Sie den JOSE-Header mit kompakter Serialisierung (folgen Sie der Reihenfolge der Parameter, die wir hier verwenden) und verschlüsseln Sie ihn anschließend base64url:

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

    Der base64url-codierte JOSE-Header ist eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

    Dies ist das erste Element der JWE-Website.

  6. Das zweite Element des JWE-Feldes ist leer, da wir keine JWE-Komponente Chiffrierschlüssel.

  7. Das dritte Element des JWE-Vektors ist der Initialisierungs vektor NLNd3V9Te68tkpWD definiert.

  8. Verwenden Sie Ihr JWE-Verschlüsselungstool, um verschlüsselte Nutzdatendaten und Tags zu erzeugen. Bei der unverschlüsselten Nutzlast handelt es sich in diesem Beispiel um die falsche PEM-Datei. this is a PEM file

    Zu den Verschlüsselungsparametern, die Sie verwenden sollten, gehören:

    • Nutzlast ist this is a PEM file

    • Verschlüsselungsverschlüsselung ist AES 128 GCM

    • Der base64url-kodierte JOSE-Header als Zusätzliche authentifizierte Daten (AAD)

    Base64url kodieren die verschlüsselte Nutzlast, was dazu führen sollte, dass f5lLVuWNfKfmzYCo1YJfODhQ

    Dies ist das vierte Element (JWE Ciphertext) in der JWE-Komponente.

  9. Base64url kodieren den tag, den Sie in Schritt 8 erstellt haben, was dazu führen sollte, PE-wDFWGXFFBeo928cfZ1Q

    Dies ist das fünfte Element in der JWE-Klasse.

  10. Verfeinern Sie die fünf Elemente der JWE-Matrix mit Punkten (JOSEheader.. IV.Ciphertext.Tag) erhalten Sie:

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

  11. Wenn Sie die hier gezeigten base64url-verschlüsselten Werte anhand Ihrer eigenen Tools abgeleitet haben, können Sie diese verwenden, um die E2E-Verschlüsselung und die verifizierte Identität Ihrer Geräte zu sichern.

  12. Dieses Beispiel wird nicht wirklich funktionieren, aber im nächsten Schritt würden Sie im nächsten Schritt die oben erstellte JWE als Eingabe für das xcommand auf dem Gerät verwenden, das das Zertifikat hinzufügt:

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

Es gibt neue Sitzungstypen für Zero-Trust-Meetings, die wir ohne Zusätzliche Kosten auf allen Meeting-Sites ausrollen. Einer der neuen Sitzungstypen heißt Pro-End to End Encryption_VOIPonly definiert. Dies ist der Name des öffentlichen Dienstes, den wir in Zukunft ändern können. Die aktuellen Namen der Sitzungstypen finden Sie unter Sitzungstyp-IDs imReferenzabschnitt dieses Artikels.

Sie müssen nichts tun, um die neue Funktion für Ihre Site zu erhalten, aber Sie müssen den Benutzern die neue Sitzungstyp (auch Meeting-Privileg genannt) erteilen. Sie können dies einzeln über die Konfigurationsseite des Benutzers oder als Massenvorgang mit einem CSV-Export/-Import-Roundtrip tun.

1

Melden Sie sich bei Control Hub an und öffnen Sie die Meeting-Seite.

2

Klicken Sie auf Ihren Site-Namen, um den Konfigurationsbereich der Site zu öffnen.

3

Klicken Sie auf Site konfigurieren.

4

Klicken Sie im Bereich Allgemeine Einstellungen aufSitzungstypen.

Auf dieser Seite sollten mindestens einer der End-to-End-Verschlüsselungssitzungstypen angezeigt werden. Siehe Liste der Sitzungstyp-IDs im Referenzabschnitt dieses Artikels. Ihnen wird beispielsweise "Pro-End zu Ende"Encryption_VOIPonly.

 

Es gibt eine ältere Sitzungstyp mit einem sehr ähnlichen Namen: Pro-End-to-End-Verschlüsselung. Diese Sitzungstyp umfasst einen nicht verschlüsselten Zugang PSTN Meetings. Stellen Sie sicher, dass Sie über _VOIPonly verfügen, um ein Ende der Verschlüsselung sicherzustellen. Sie können dies überprüfen, indem Sie in der Spalte "Sitzungscode" über den Link PRO fahren. Für dieses Beispiel sollte der Link als Ziel verwendet werden. javascript:ShowFeature(652) definiert.

Wir können zukünftig die Namen der öffentlichen Dienste für diese Sitzungstypen ändern, zum Beispiel möchten wir Pro-End zu End Encryption_VOIPonlyE2E Encryption + Identityändern.

5

Wenn Sie das neue Produkt noch nicht Sitzungstyp, wenden Sie sich an Ihren Webex-Vertreter.

Nächste Schritte

Aktivieren Sie Sitzungstyp Privileg für einige oder alle Ihrer Benutzer oder für das Meeting.

1

Klicken Sie auf Benutzer und wählen Sie einen Benutzer aus, um den Konfigurationsbereich des Benutzers zu öffnen.

2

Klicken Sie im Bereich Dienste aufCisco Webex Meetings.

3

Wählen Sie die -Site aus (wenn der Benutzer mehr als einen Benutzer hat) und klicken Sie auf Hosten .

4

Aktivieren Sie das Kontrollkästchen neben dem Webex Meetings mit der Bezeichnung Pro-End bis End fürEncryption_VOIPonly.

5

Schließen Sie den Bereich Benutzerkonfiguration.

6

Wiederholen Sie diesen Vorgang bei Bedarf für andere Benutzer.

Wenn Sie dies vielen Benutzern zuweisen möchten, verwenden Sie die CSV-Massenoption.

1

Melden Sie sich bei Control Hub unter https://admin.webex.com an und öffnen Sie die Meeting-Seite.

2

Klicken Sie auf Ihren Site-Namen, um den Site-Konfigurationsbereich zu öffnen.

3

Klicken Sie im Abschnitt Lizenzen und Benutzer auf Massen verwalten.

4

Klicken Sie aufExportieren, und warten Sie, bis die Datei vorbereitet ist.

5

Wenn die Datei bereit ist, klicken Sie auf Ergebnisse exportieren und dann aufHerunterladen. (Sie müssen dieses Pop-up-Fenster manuell schließen, nachdem Sie auf Herunterladen.)

6

Öffnen Sie die heruntergeladene CSV-Datei zum Bearbeiten.

Für jeden Benutzer wird eine Zeile angezeigt, und das MeetingPrivilege Spalte enthält ihre Sitzungstyp-IDs als durch Kommas getrennte Liste.

7

Fügen Sie jedem Benutzer, dem Sie den neuen Benutzernamen Sitzungstyp, hinzu. 1561 als neuer Wert in der Liste mit durch Kommas getrennten Zeichen im MeetingPrivilege Zelle.

Die CSV-Dateiformatreferenz unter enthält einige Details zum Zweck https://help.webex.com/en-us/5vox83 und Inhalt der CSV-Datei.

8

Öffnen Sie den Konfigurationsbereich der Meeting-Site im Control Hub.

Wenn Sie bereits auf der Listenseite der Meeting-Site waren, müssen Sie sie aktualisieren.

9

Klicken Sie im Bereich Lizenzen und Benutzer auf Sammelaktion zum Verwalten.

10

Klicken Sie auf Importieren, wählen Sie die bearbeitete CSV-Datei aus, und klicken Sie dann auf Importieren. Warten Sie, bis die Datei hochgeladen wurde.

11

Wenn der Import abgeschlossen ist, können Sie auf Importergebnisse klicken, um zu überprüfen, ob Fehler aufgetreten sind.

12

Gehen Sie zur Seite Benutzer und öffnen Sie einen der Benutzer, um zu überprüfen, ob sie über die neue Version Sitzungstyp.

Wenn Ihre Geräte bereits mit Ihrer Control Hub-Organisation integriert sind und Sie die Webex-ZERTIFIZIERUNG verwenden möchten, um die identifizierenden Zertifikate automatisch zu generieren, müssen Sie die Geräte nicht auf die Werkseinstellungen zurücksetzen.

Mit diesem Verfahren wird ausgewählt, welche Domäne das Gerät verwendet, um sich selbst zu identifizieren, und ist nur erforderlich, wenn Sie in Ihrer Control Hub-Organisation über mehrere Domänen verfügen. Wenn Sie mehr als eine Domäne haben, empfehlen wir Ihnen, dies für alle Ihre Geräte zu tun, die über eine "cisco-verifizierte" Identität verfügen. Wenn Sie Webex nicht mitteilen, welche Domäne das Gerät identifiziert, wählen wir ein Gerät aus und es könnte anderen Meeting-Teilnehmern falsch aussehen.

Vorbereitungen

Wenn Ihre Geräte noch nicht integriert sind, können Sie folgen oder https://help.webex.com/n25jyr8https://help.webex.com/nutc0dy. Sie sollten auch die Domäne/n überprüfen, die Sie zur Identifizierung der Geräte verwenden möchten (https://help.webex.com/cd6d84).

1

Melden Sie sich bei Control Hubhttps://admin.webex.com() an und öffnen Sie die Seite Geräte.

2

Wählen Sie ein Gerät aus, um das Konfigurationsfenster zu öffnen.

3

Wählen Sie die Domäne aus, die Sie verwenden möchten, um dieses Gerät zu identifizieren.

4

Wiederholen Sie den Vorgang für andere Geräte.

Vorbereitungen

Du brauchst:

  • Um ein CA-signiertes Zertifikat und einen privaten Schlüssel im .pem-Format für jedes Gerät zu erhalten.

  • Informationen zum Lesen des Themas Externer Identitätsprozess für Geräte finden Sieim Vorbereiten des Teils dieses Artikels.

  • Die Vorbereitung eines JWE-Verschlüsselungstools bezüglich der dort erhaltenen Informationen.

  • Ein Tool zum Erzeugen zufälliger Byte-Sequenzen einer bestimmten Länge.

  • Ein Tool zur Basis64URL-Codierung von Byte oder Text.

  • Eine scrypt Umsetzung.

  • Ein geheimes Wort oder Ausdruck für jedes Gerät.

1

Des Geräts befüllen ClientSecret mit einem Klartext-Geheimen:

Wenn Sie das erste Mal das Secret, geben Sie sie als Nur-Text-Text an. Aus diesem Grund empfehlen wir Ihnen, dies über die physische Gerätekonsole zu tun.

  1. Base64url kodieren Sie den geheimen Satz für dieses Gerät.

  2. Öffnen Sie die Shell auf dem Gerät.

  3. Ausführen xcommand Security ClientSecret Populate Secret: "MDEyMzQ1Njc4OWFiY2RlZg"

    Der oben genannte Beispielbefehl füllt die Secret mit dem Satz 0123456789abcdef definiert. Sie müssen ihre eigenen auswählen.

Das Gerät hat seinen anfänglichen Schlüssel. Vergessen Sie nicht, dass Sie es nicht wiederherstellen können und das Gerät auf die Werkseinstellungen zurücksetzen müssen, um neu zu starten.
2

Ihr Zertifikat und Ihren privaten Schlüssel verfeinern:

  1. Öffnen Sie in einem Texteditor die .pem-Dateien, fügen Sie den Schlüssel des Zertifikats-Feldes ein, und speichern Sie ihn als neue .pem-Datei.

    (Dies ist der Nutzdatentext, den Sie verschlüsseln und in Ihre JWE-Datei speichern möchten.)

3

Erstellen Sie JWE als Eingabe für den Befehl zum Hinzufügen des Zertifikats:

  1. Erstellen Sie eine zufällige Folge von mindestens 4 Byte. Das ist Ihr Thema.

  2. Erstellen Sie mit Chiffrierschlüssel Scrypt-Tool eine Inhalts-E-Mail.

    Dazu benötigen Sie das Geheimschlüssel, das Programm und eine Schlüssellengthe, die Ihrer ausgewählten Verschlüsselungsverschlüsselung passen. Es gibt noch weitere feste Werte für die Bereitstellung (N=32768, r=8, p=1). Das Gerät verwendet dieselben Prozesse und Werte, um dieselben Inhalte und Chiffrierschlüssel.

  3. Erstellen Sie eine zufällige Folge von genau 12 Byte. Dies ist Ihr Initialisierungs vektor.

  4. Jose-Kopfzeile erstellen, einstellen alg, enc, und cisco-kdf Schlüssel wie unter Externer Identitätsprozess für Gerätebeschrieben. Legen Sie die Aktion "Hinzufügen" mithilfe des Schlüssels:Werts fest. "cisco-action":"add" in Ihrem JOSE-Header (da wir dem Gerät das Zertifikat hinzufügen).

  5. Base64url kodieren den JOSE-Header.

  6. Verwenden Sie Ihr JWE-Verschlüsselungstool mit der ausgewählten Verschlüsselung und dem base64url-verschlüsselten JOSE-Header, um den Text aus der concatenated pem-Datei zu verschlüsseln.

  7. Base64url kodieren den Initialisierungsvektor, die verschlüsselte PEM-Nutzlast und den Authentifizierungs-Tag.

  8. Erstellen Sie JWE wie folgt (alle Werte werden base64url-verschlüsselt):

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4

Öffnen Sie die Shell auf dem Gerät und führen Sie den Befehl Hinzufügen (mehrkanal) aus:

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

Stellen Sie sicher, dass das Zertifikat hinzugefügt wurde, indem Sie xcommand Security Certificates Services Show

Kopieren Sie den Fingerabdruck des neuen Zertifikats.

6

Aktivieren Sie das Zertifikat zu diesem Zweck WebexIdentity:

  1. Lesen Sie den Fingerabdruck des Zertifikats, entweder aus dem Zertifikat selbst oder aus der Ausgabe von xcommand Security Certificates Services Show definiert.

  2. Erstellen Sie eine zufällige Folge von mindestens 4 Byte und kodieren Sie diese Sequenz mit base64url. Das ist Ihr Thema.

  3. Erstellen Sie mit Chiffrierschlüssel Scrypt-Tool eine Inhalts-E-Mail.

    Dazu benötigen Sie das Geheimschlüssel, das Programm und eine Schlüssellengthe, die Ihrer ausgewählten Verschlüsselungsverschlüsselung passen. Es gibt noch weitere feste Werte für die Bereitstellung (N=32768, r=8, p=1). Das Gerät verwendet dieselben Prozesse und Werte, um dieselben Inhalte und Chiffrierschlüssel.

  4. Erstellen Sie eine zufällige Folge von genau 12 Byte und kodieren Sie diese Sequenz mit base64url. Dies ist Ihr Initialisierungs vektor.

  5. Jose-Kopfzeile erstellen, einstellen alg, enc, und cisco-kdf Schlüssel wie unter Externer Identitätsprozess für Gerätebeschrieben. Legen Sie die "Aktivierung"-Aktion mithilfe des Schlüssels:Werts fest. "cisco-action":"activate" in Ihrem JOSE-Header (da das Zertifikat auf dem Gerät aktiviert wird).

  6. Base64url kodieren den JOSE-Header.

  7. Verwenden Sie Ihr JWE-Verschlüsselungstool mit der ausgewählten Verschlüsselung und dem base64url-verschlüsselten JOSE-Header, um den Zertifikat-Fingerabdruck zu verschlüsseln.

    Das Tool sollte eine 16- oder 32-Byte-Sequenz abhängig davon, ob Sie ein 128- oder 256-Bit-AES-GCM ausgewählt haben, und ein Authentifizierungs-Tag ausgabe.

  8. Base64urlencode den verschlüsselten Fingerabdruck und das Authentifizierungs-Tag.

  9. Erstellen Sie JWE wie folgt (alle Werte werden base64url-verschlüsselt):

    JOSEHeader..InitVector.EncryptedFingerprint.AuthTag

  10. Öffnen Sie die Shell auf dem Gerät und führen Sie den folgenden Aktivierungsbefehl aus:

    xcommand Security Certificates Services Activate Purpose: WebexIdentity Fingerprint: "Your..JWE.encrypted.fingerprint"
Das Gerät verfügt über ein verschlüsseltes, aktives CA-ausgegebenes Zertifikat, das zur Identifizierung in end-to-End-verschlüsselten Webex-Meetings verwendet werden kann.
7

Integrieren Sie das Gerät mit Ihrer Control Hub-Organisation.

1

Planen Sie ein Meeting vom korrekten Typ (Webex Meetings Pro-End-to-End-Encryption_VOIPonly).

2

Treten Sie dem Meeting als Gastgeber über einen Webex Meetings bei.

3

Treten Sie dem Meeting über ein Gerät bei, dessen Identität von der Webex-Zertifizierungsstelle verifiziert wurde.

4

Stellen Sie als Gastgeber sicher, dass dieses Gerät mit dem richtigen Identitätssymbol in der Lobby angezeigt wird.

5

Treten Sie dem Meeting über ein Gerät bei, dessen Identität von einer externen ZERTIFIZIERUNGsstelle verifiziert wurde.

6

Stellen Sie als Gastgeber sicher, dass dieses Gerät mit dem richtigen Identitätssymbol in der Lobby angezeigt wird.

7

Treten Sie dem Meeting als nicht authentifizierter Meeting-Teilnehmer bei.

8

Stellen Sie als Gastgeber sicher, dass dieser Teilnehmer mit dem korrekten Identitätssymbol in der Lobby angezeigt wird.

9

Als Gastgeber können Sie Personen/Geräte zulassen oder ablehnen.

10

Validieren Sie Teilnehmer-/Geräteidentitäten, wenn möglich, indem Sie die Zertifikate überprüfen.

11

Überprüfen Sie, ob alle Meeting-Mitglieder den gleichen Sicherheitscode sehen.

12

Treten Sie dem Meeting mit einem neuen Teilnehmer bei.

13

Stellen Sie sicher, dass alle den gleichen neuen Meeting-Sicherheitscode sehen.

Werden Sie End-to-End-verschlüsselte Meetings zur Standard-Meeting-Option machen, oder sie nur für einige Benutzer aktivieren oder allen Gastgebern erlauben, zu entscheiden? Nachdem Sie sich dafür entschieden haben, wie Sie diese Funktion nutzen werden, bereiten Sie die Benutzer vor, die sie verwenden werden, insbesondere hinsichtlich der Einschränkungen und des zu erwartenden Meeting-Ziels.

Müssen Sie sicherstellen, dass weder Cisco noch jemand anderes Ihre Inhalte entschlüsseln oder ihre Geräte nachahmen kann? Wenn ja, benötigen Sie Zertifikate einer öffentlichen Zertifizierungsstelle. Sie können nur über bis zu 25 Geräte in einem sicheren Meeting verfügen. Wenn Sie diese Sicherheitsstufe benötigen, sollten Sie Meetings-Clients den Beitritt nicht erlauben.

Für Benutzer, die mit sicheren Geräten beitreten, lassen Sie Geräte zuerst beitreten, und legen Sie die Erwartungen der Benutzer fest, dass sie möglicherweise nicht beitreten können, wenn sie zu spät beitreten.

Bei unterschiedlichen Identitätsverifizierungsebenen können sich die Nutzer mit einer zertifikatgesicherungsbasierten Identität und dem Meeting-Sicherheitscode gegenseitig verifizieren. Obwohl es Umstände gibt, unter denen Teilnehmer als nicht bestätigt angezeigt werden können und die Teilnehmer wissen sollten, wie sie es überprüfen sollten, sind nicht verifizierte Personen möglicherweise keine Versposer.

Wenn Sie ihre Gerätezertifikate über eine externe ZERTIFIZIERUNGsstelle aus ausgaben, können Sie Zertifikate überwachen, aktualisieren und erneut installieren.

Wenn Sie den anfänglichen Schlüssel erstellt haben, müssen Sie wissen, dass Ihre Benutzer möglicherweise die geheimen Daten ihres Geräts ändern möchten. Möglicherweise müssen Sie eine Schnittstelle erstellen/ein Tool verteilen, um dies zu ermöglichen.

Tabelle 1: Sitzungstyp-IDs für End-to-End-verschlüsselte Meetings

Sitzungstyp-ID

Name des öffentlichen Dienstes

638

E2E-Verschlüsselung + VoIP nur

652

Pro-End-to-End-Encryption_VOIPonly

660

Pro 3 Free-End-to-End-Encryption_VOIPonly

E2E-Verschlüsselung + Identität

672

Pro 3 Free50-End-to-End-Encryption_VOIPonly

673

Schulungsleiter E2E Encryption_VOIPonly

676

Broadworks Standard plus End-to-End-Verschlüsselung

677

Broadworks Premium plus End-to-End-Verschlüsselung

681

Kostenloses Plus Ende-zu-Ende-Verschlüsselung

Diese Tabellen enthalten Informationen zu API-Befehlen für Webex-Geräte, die wir für End-to-End-verschlüsselte Meetings und verifizierte Identität hinzugefügt haben. Weitere Informationen zur Verwendung der API finden Sie unter https://help.webex.com/nzwo1ok.

Tabelle 2: APIs auf Systemebene für End-to-End-verschlüsselte Meetings und verifizierte Identität

API-Aufruf

Beschreibung

xConfiguration Conference EndToEndEncryption Mode: On

Schaltet den Verschlüsselungsmodus von Ende zu Ende um On oder Off definiert.

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

Diese Konfiguration wird vorgenommen, wenn der Administrator die bevorzugte Domäne des Geräts aus Control Hub vor legt. Nur erforderlich, wenn die Organisation über mehr als eine Domäne verfügt.

Das Gerät verwendet diese Domäne, wenn es ein Zertifikat von der Webex-Zertifizierungsstelle an fordert. Die Domäne identifiziert dann das Gerät.

Diese Konfiguration kann nicht verwendet werden, wenn das Gerät über ein aktives, extern ausgegebenes Zertifikat verfügt, um sich selbst zu identifizieren.

xStatus Conference EndToEndEncryption Availability

Gibt an, ob das Gerät einem End-to-End-verschlüsselten Meeting beitreten kann. Die Cloud-API ruft es auf, damit eine gekoppelte App weiß, ob sie das Gerät zum Beitreten verwenden kann.

xStatus Conference EndToEndEncryption ExternalIdentity Valid

Gibt an, ob das Gerät über ein gültiges extern ausgestelltes Zertifikat verfügt.

xStatus Conference EndToEndEncryption ExternalIdentity Identity

Die Identität des Geräts wie aus dem allgemeinen Namen des extern ausgestellten Zertifikats gelesen.

xStatus Conference EndToEndEncryption ExternalIdentity CertInfo

Liest die Zertifikatsinformationen aus dem extern ausgestellten Zertifikat und gibt es als JSON-Json-Feld aus.

xStatus Conference EndToEndEncryption InternalIdentity Valid

Gibt an, ob das Gerät über ein gültiges Zertifikat verfügt, das von der Webex-Zertifizierungsstelle ausgestellt wurde.

xStatus Conference EndToEndEncryption InternalIdentity Identity

Die Identität des Geräts wie aus dem allgemeinen Namen des Webex-zertifikats ausgegebenen Zertifikats.

Enthält einen Domänennamen, wenn die Organisation über eine Domäne verfügt.

Ist leer, wenn die Organisation keine Domäne hat.

Wenn sich das Gerät in einer Organisation mit mehreren Domänen befindet, ist dies der Wert aus der PreferredDomain definiert.

xStatus Conference EndToEndEncryption InternalIdentity CertInfo

Liest die Zertifikatsinformationen aus dem von Webex ausgestellten Zertifikat und gibt es als JSON-Json-Feld aus.

Tabelle 3. In Call-APIs für End-to-End-verschlüsselte Meetings und verifizierte Identität

API-Aufruf

Beschreibung

xStatus Call # ServerEncryption Type

Liest die Verschlüsselungsverschlüsselung, die in der HTTPS-Verbindung zu Webex verwendet wird. Dies wird dem Benutzer angezeigt.

xStatus Conference Call # EndToEndEncryption Status

Liest den End-to-End-Verschlüsselungsstatus der Anrufe. Wird dem Benutzer als Anwesenheit (oder Abwesenheit) des Schloss-Symbols angezeigt.

xStatus Conference Call # EndToEndEncryption SecurityCode

Lesen des Sicherheitscodes für das Meeting. Diese Wird dem Benutzer angezeigt und ändert sich, wenn Teilnehmer beitreten.

xStatus Conference Call # EndToEndEncryption MediaEncryption Type

Liest die Verschlüsselungsverschlüsselung, die in der Medienverbindung verwendet wird. Dies wird dem Benutzer angezeigt.

xStatus Conference Call # EndToEndEncryption GroupEncryption Type

Liest die Verschlüsselungsverschlüsselung, die für Messaging Layer Security (TIBS) verwendet wird.

xStatus Conference Call # EndToEndEncryption Roster Participant

Listet die Teilnehmer auf, die in diesem Meeting den STATUS der GRUPPE ODER DES ODER DER GRUPPE TRAGEN. Die Liste wird von SCHONTE gefunden, nicht von Webex.

xStatus Conference Call # EndToEndEncryption Roster Participant # Id

Die WDM-URL eines angegebenen Teilnehmers.

xStatus Conference Call # EndToEndEncryption Roster Participant # Status:

Der Verifizierungsstatus des angegebenen Teilnehmers.

xStatus Conference Call # EndToEndEncryption Roster Participant # Identity:

Die primäre Identität des angegebenen Teilnehmers, in der Regel eine Domäne (Gerät) oder E-Mail-Adresse (Benutzer).

xStatus Conference Call # EndToEndEncryption Roster Participant # DisplayName:

Der Anzeigename des angegebenen Teilnehmers. Vom Teilnehmer/Gerät signiert.

xStatus Conference Call # EndToEndEncryption Roster Participant # CertInfo:

Die Zertifikatsinformationen aus dem Zertifikat des angegebenen Teilnehmers als JSON-Datei.

xCommand Conference ParticipantList Search

Wir haben diesen Befehl auf End-to-End-Verschlüsselungsinformationen für Teilnehmer erweitert.

xCommand Conference ParticipantList Search

Die Suche in der Teilnehmerliste enthält jetzt EndToEndEncryptionStatus, der Identitätsverifizierungsstatus des Teilnehmers. Dieser Wert wird auf der Benutzeroberfläche angezeigt.

xCommand Conference ParticipantList Search

Die Suche in der Teilnehmerliste enthält jetzt EndToEndEncryptionIdentity, die primäre Identität des Teilnehmers. Dies ist in der Regel eine Domäne oder eine E-Mail-Adresse. Dieser Wert wird auf der Benutzeroberfläche angezeigt.

xCommand Conference ParticipantList Search

Die Suche in der Teilnehmerliste enthält jetzt EndToEndEncryptionCertInfo, JSON weiter, das das Zertifikat des Teilnehmers enthält. Dieser Wert wird auf der Benutzeroberfläche angezeigt.

xEvent Conference ParticipantList Participant(Added)

xEvent Conference ParticipantList Participant(Updated)

xEvent Conference ParticipantList Participant(Deleted)

Diese drei Events umfassen jetzt EndToEndEncryptionStatus, EndToEndEncryptionIdentity, und EndToEndEncryptionCertInfo für den betroffenen Teilnehmer.

Tabelle 4. ClientSecret-bezogene APIs für End-to-End-verschlüsselte Meetings und verifizierte Identität

API-Aufruf

Beschreibung

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

Akzeptiert einen base64url-verschlüsselten Klartextwert für die erstmalige Aussaat des Clientschlüssels auf dem Gerät.

Um das Geheimschlüssel nach diesem Zeitpunkt zu aktualisieren, müssen Sie JWE eine JWE-Website liefern, die das neue Geheimschlüssel enthält, das mit dem alten Geheimen verschlüsselt wird.

xCommand Security Certificates Services Add JWEblob

Fügt ein Zertifikat (mit privatem Schlüssel) hinzu.

Wir haben diesen Befehl erweitert, um eine JWE-Datei zu akzeptieren, die die verschlüsselten PEM-Daten enthält.

xCommand Security Certificates Services Activate Purpose:WebexIdentity FingerPrint: JWEblob

Aktiviert ein bestimmtes Zertifikat für WebexIdentity. Dafür Purpose, erfordert der Befehl, dass der Identifizieren-Fingerabdruck verschlüsselt und in einer JWE-Serie serialisiert wird.

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

Deaktiviert ein bestimmtes Zertifikat für WebexIdentity. Dafür Purpose, erfordert der Befehl, dass der Identifizieren-Fingerabdruck verschlüsselt und in einer JWE-Serie serialisiert wird.