Benutzer wählen den Meeting-Typ aus, wenn sie ein Meeting ansetzen. Beim Einlassen von Teilnehmern aus der Lobby sowie während des Meetings kann der Gastgeber den Status der Identitätsüberprüfung jedes Teilnehmers sehen. Es gibt auch einen Meeting-Code, den alle aktuellen Meeting-Teilnehmer verwenden können, um sich gegenseitig zu verifizieren.

Geben Sie die folgenden Informationen an Ihre Meeting-Gastgeber weiter:

Identität überprüfen

Die durchgängige Verschlüsselung mit Identitätsüberprüfung bietet zusätzliche Sicherheit für Meetings mit durchgängiger Verschlüsselung.

Wenn Teilnehmer oder Geräte einer freigegebenen MLS-Gruppe (Nachrichten Layer Security) beitreten, präsentieren sie ihre Zertifikate den anderen Gruppenmitgliedern, die die Zertifikate dann anhand der ausstellenden Zertifizierungsstellen (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.

Webex -App-Benutzer authentifizieren sich über den Webex -Identitätsspeicher, der ihnen bei erfolgreicher Authentifizierung ein Zugriffstoken ausgibt. Wenn sie ein Zertifikat benötigen, um ihre Identität in einem durchgängig verschlüsselten Meeting zu verifizieren, stellt die Webex CA ihnen ein Zertifikat basierend auf ihrem Zugriffstoken aus. Zu diesem Zeitpunkt bieten wir keine Möglichkeit für Webex Meetings -Benutzer, ein Zertifikat zu erhalten, das von einer externen Zertifizierungsstelle (CA) ausgestellt wurde.

Geräte können sich selbst mit einem von der internen (Webex) CA ausgestellten Zertifikat oder einem von einer externen CA ausgestellten Zertifikat authentifizieren:

  • Interne Zertifizierungsstelle – Webex stellt ein internes Zertifikat basierend auf dem Zugriffstoken des Computerkontos des Geräts aus. Das Zertifikat wird von der Webex CA signiert. Geräte verfügen nicht über dieselben Benutzer-IDs wie Benutzer. Daher verwendet Webex die Domänen Ihrer Organisation, wenn die Identität des Gerätezertifikats (Common Name (CN)) geschrieben wird.

  • Externe CA – Fordern und erwerben Sie Gerätezertifikate direkt vom Aussteller Ihrer Wahl. Sie müssen die Zertifikate mit einem nur Ihnen bekannten Geheimnis verschlüsseln, direkt hochladen und autorisieren.

    Cisco nicht involviert ist, ist dies der Weg, eine echte End-to-End-Verschlüsselung und verifizierte Identität zu garantieren und die theoretische Möglichkeit zu verhindern, dass Cisco Ihr Meeting abhört/Ihre Medien entschlüsselt.

Intern ausgestelltes Gerätezertifikat

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

Wenn Ihre Organisation über keine Domäne verfügt, stellt die Webex CA das Zertifikat ohne Domäne aus.

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

Wenn Sie mehrere Domänen haben und die bevorzugte Domäne für das Gerät nicht festgelegt haben, 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 CAs signiert wurde.

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

Die Werte im Zertifikat liegen im Ermessen der Organisation. Der allgemeine Name (CN) und der Betreff für alternativen Namen (SAN) werden in der Webex-Konferenz Benutzeroberfläche angezeigt, wie unter . beschrieben Durchgängige Verschlüsselung mit Identitätsüberprüfung für Webex Meetings .

Wir empfehlen die Verwendung eines separaten Zertifikats pro Gerät und einen eindeutigen CN pro Gerät. Beispiel: „meeting-room-1.example.com“ für die Organisation, die die Domäne „example.com“ besitzt.

Um das externe Zertifikat vollständig vor Manipulation zu schützen, werden verschiedene XCommands mithilfe einer Client-Secret-Funktion verschlüsselt und signiert.

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

Webex stellt derzeit API -Befehle für die Verwaltung dieses Problems bereit.

Geräte

Die folgenden Cloud-registrierten Geräte der Webex Room-Serie und Webex Desk-Serie können Meetings mit durchgängiger Verschlüsselung beitreten:

  • Webex Board

  • Webex Desk Pro

  • Webex Desk

  • Webex Room Kit

  • Webex Room Kit Mini

Die folgenden Geräte können nicht an Meetings mit durchgängiger Verschlüsselung teilnehmen:

  • Webex C-Serie

  • Webex DX-Serie

  • Webex EX-Serie

  • Webex MX-Serie

  • SIP -Geräte von Drittanbietern

Software-Clients
  • Ab Version 41.6 kann der Webex Meetings -Desktop-Client Meetings mit End-to-End-Verschlüsselung beitreten.

  • Wenn Ihre Organisation die Webex-App , um Meetings durch Starten der Meetings-Desktopanwendung beizutreten, können Sie diese Option verwenden, um Meetings mit durchgängiger Verschlüsselung beizutreten.

  • Der Webex -Web-Client kann keinen Meetings mit durchgängiger Verschlüsselung beitreten.

  • SIP -Soft-Clients von Drittanbietern können Meetings mit End-to-End-Verschlüsselung nicht beitreten.

Identität
  • Wir bieten konstruktionsbedingt keine Control Hub-Optionen zur Verwaltung der extern verifizierten Geräteidentität. Für eine echte End-to-End-Verschlüsselung sollten nur Sie die Secrets und Schlüssel kennen und darauf zugreifen. Wenn wir einen Clouddienst zur Verwaltung dieser Schlüssel einführen, besteht die Möglichkeit, dass sie abgefangen werden.

  • Derzeit stellen wir Ihnen ein „Rezept“ zur Verfügung, mit dem Sie basierend auf Verschlüsselungstechniken nach Industriestandard Ihre eigenen Tools entwickeln können, um Sie bei der Anforderung oder Verschlüsselung Ihrer Geräteidentitätszertifikate und der zugehörigen privaten Schlüssel zu unterstützen. Wir möchten keinen echten oder vermeintlichen Zugriff auf Ihre Secrets oder Schlüssel haben.

Meetings
  • Durchgängig verschlüsselte Meetings unterstützen derzeit maximal 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 beitreten .

    Wenn eine größere Anzahl von Geräten einem Meeting beitritt, versuchen unsere Back-End-Mediendienste, die Medienstreams zu transkodieren. Wenn wir die Medien nicht entschlüsseln, transcodieren und erneut verschlüsseln können (weil wir die Verschlüsselungsschlüssel der Geräte nicht haben und nicht haben sollten), dann schlägt die Transcoding fehl.

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

Verwaltungsoberfläche

Wir empfehlen Ihnen dringend, Control Hub zu verwenden, um Ihre Meeting-Site zu verwalten, da Control Hub-Organisationen über eine zentralisierte Identität für die gesamte Organisation verfügen, während in Site-Administration die Identität Site für Site kontrolliert wird.

Benutzer, die über Site-Administration verwaltet werden, dürfen nicht über die Option „Von Cisco verifizierte Identität“ verfügen. Diesen Benutzern wird ein anonymes Zertifikat für den Beitritt zu einem durchgängig verschlüsselten Meeting ausgestellt, und sie können von Meetings ausgeschlossen werden, bei denen der Gastgeber eine Identitätsverifizierung wünscht.

Verwandte Informationen
  • Webex Meetings 41.7.

  • Cloud-registrierte Geräte der Webex Room- und Webex Desk-Serien 10.6.1-RoomOS_August_2021.

  • Administratorzugriff auf die Konferenzstandort in Control Hub, um den neuen Sitzungstyp für Benutzer zu aktivieren.

  • Eine oder mehrere verifizierte Domänen in Ihrer Control Hub-Organisation (wenn Sie die Webex CA zum Ausstellen von Gerätezertifikaten für die verifizierte Identität verwenden).

  • Zusammenarbeitsräume müssen aktiviert sein, damit Teilnehmer über ihr Videosystem beitreten können. Weitere Informationen finden Sie unter Zulassen, dass Videosysteme Meetings und Events auf Ihrer Webex-Seite beitreten .

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

Für ein Höchstmaß an Sicherheit und Identitätsüberprüfung sollte jedes Gerät über ein eindeutiges Zertifikat verfügen, das von einer vertrauenswürdigen öffentlichen Certificate Authority (CA) ausgestellt wurde.

Sie müssen mit der Zertifizierungsstelle interagieren, um die digitalen Zertifikate anzufordern, zu erwerben und zu erhalten und die zugehörigen privaten Schlüssel zu erstellen. Verwenden Sie beim Anfordern des Zertifikats die folgenden Parameter:

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

  • Eindeutig: Wir empfehlen dringend, für jedes Gerät ein eindeutiges Zertifikat zu verwenden. Wenn Sie ein Zertifikat für alle Geräte verwenden, gefährden Sie Ihre Sicherheit.

  • Allgemeiner Name (CN) und alternativer Antragstellername (SAN/s): Diese sind für Webex nicht wichtig, sondern sollten Werte sein, die Menschen lesen und mit dem Gerät assoziieren können. Der CN wird anderen Meeting-Teilnehmern als primäre verifizierte Identität des Geräts angezeigt, und wenn Benutzer das Zertifikat über die Meeting-Benutzeroberfläche überprüfen, sehen sie die SAN/s. Sie können Namen wie verwenden name.model@example.com.

  • Dateiformat: Die Zertifikate und Schlüssel müssen sich in der Datei .pem Format.

  • Zweck: Der Zweck des Zertifikats muss Webex Identität sein.

  • Schlüssel werden generiert: Die Zertifikate müssen auf ECDSA P-256-Schlüsselpaaren basieren (Elliptical Curve Digital Signature Algorithm, der die P-256-Kurve verwendet).

    Diese Anforderung gilt nicht für den Signaturschlüssel. Die CA kann einen RSA -Schlüssel verwenden, um das Zertifikat zu signieren.

Sie können diesen Schritt überspringen, wenn Sie keine extern verifizierte Identität für Ihre Geräte verwenden möchten.

Wenn Sie neue Geräte verwenden, registrieren Sie diese noch nicht in Webex . Verbinden Sie sie sicherheitshalber zu diesem Zeitpunkt nicht mit dem Netzwerk.

Wenn Sie vorhandene Geräte aktualisieren möchten, um eine 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 beibehalten möchten.

  • Legen Sie ein Fenster an, in dem die Geräte nicht verwendet werden, oder wählen Sie einen schrittweisen Ansatz. Benachrichtigen Sie die Benutzer über die Änderungen, die sie erwarten können.

  • Stellen Sie den physischen Zugriff auf Geräte sicher. Wenn Sie über das Netzwerk auf Geräte zugreifen müssen, beachten Sie, dass Secrets im Nur-Text-Format übertragen werden und Sie Ihre Sicherheit gefährden.

Wenn Sie diese Schritte abgeschlossen haben, zulassen, dass Videosysteme Meetings und Events auf Ihrer Webex-Seite beitreten .

Um sicherzustellen, dass Ihre Gerätemedien nur durch das 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 mithilfe von JSON Web Encryption (JWE) zu ermöglichen.

Um eine echte End-to-End-Verschlüsselung über unsere Cloud zu gewährleisten, können wir nicht an der Verschlüsselung und dem Hochladen des Zertifikats und Schlüssels beteiligt sein. Wenn Sie diese Sicherheitsstufe benötigen, müssen Sie:

  1. Fordern Sie Ihre Zertifikate an.

  2. Generieren Sie die Schlüsselpaare Ihrer Zertifikate.

  3. Erstellen (und schützen) Sie ein Initial Secret für jedes Gerät, um die Verschlüsselungsfunktion des Geräts zu aktivieren.

  4. Entwicklung und Pflege Ihres eigenen Tools zum Verschlüsseln von Dateien mit dem JWE-Standard.

    Der Prozess und die (nicht geheimen) Parameter, die Sie benötigen, werden unten erläutert, ebenso wie ein Rezept, das Sie in den Entwicklungstools Ihrer Wahl befolgen können. Wir stellen auch einige Testdaten und die resultierenden JWE-Blobs wie erwartet bereit, um Sie bei der Überprüfung Ihres Prozesses zu unterstützen.

    Eine nicht unterstützte Referenzimplementierung mit Python3 und der JWCrypto-Bibliothek ist auf Anfrage von Cisco erhältlich.

  5. Verknüpfen und verschlüsseln Sie das Zertifikat und den Schlüssel mit Ihrem Tool und dem Initial Secret des Geräts.

  6. Laden Sie das resultierende JWE-Blob auf das Gerät hoch.

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

  8. (Empfohlen) Stellen Sie eine Schnittstelle zu Ihrem Tool bereit (oder verteilen Sie es), damit Gerätebenutzer den Initial Secret ändern und ihre Medien vor Ihnen schützen können.

So verwenden wir das JWE-Format

In diesem Abschnitt wird beschrieben, wie die JWE voraussichtlich als Eingabe für die Geräte erstellt wird, damit Sie Ihr eigenes Tool erstellen können, um die Blobs aus Ihren Zertifikaten und Schlüsseln zu erstellen.

Siehe JSON Web Encryption (JWE)https://datatracker.ietf.org/doc/html/rfc7516und JSON-Websignatur (JWS)https://datatracker.ietf.org/doc/html/rfc7515.

Wir verwenden das Kompakte Serialisierung eines JSON-Dokuments, um JWE-Blobs zu erstellen. Die Parameter, die Sie beim Erstellen der JWE-Blobs einschließen müssen, sind:

  • Jose-Kopfzeile (geschützt). Im JSON Object Signing and Encryption-Header MÜSSEN Sie die folgenden Schlüssel/Wert-Paare einfügen:

    • "alg":"dir"

      Der direkte Algorithmus ist der einzige, der für die Verschlüsselung der Nutzlast unterstützt wird, und Sie müssen den anfänglichen Client-Geheimschlü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"

      Dies ist ein proprietärer Schlüssel und vier Werte, die er annehmen kann. Wir haben diesen Schlüssel eingeführt, um dem Zielgerät den Zweck der verschlüsselten Daten zu signalisieren. Die Werte werden nach den xAPI-Befehlen auf dem Gerät benannt, auf dem Sie die verschlüsselten Daten verwenden.

      Wir haben es getauft cisco-action um mögliche Konflikte mit zukünftigen JWE-Erweiterungen zu minimieren.

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

      Ein weiterer proprietärer Schlüssel. Wir verwenden die von Ihnen angegebenen Werte als Eingaben für die Schlüsselableitung auf dem Gerät. Die Datei version muss sein 1(die Version unserer Schlüsselableitungsfunktion). Der Wert von salt muss eine Base64- URL-codierte Sequenz von mindestens 4 Bytes sein, die von Ihnen muss zufällig auswählen.

  • Verschlüsselter JWE-Schlüssel . Dieses Feld ist leer. Das Gerät leitet ihn vom Initialen ab ClientSecret.

  • JWE-Initialisierungsvektor . Sie müssen einen Base64url-codierten Initialisierungsvektor zum Entschlüsseln der Nutzlast angeben. Die Infusionslösung MUSS ein zufälliger 12-Byte-Wert sein (wir verwenden die AES-GCM-Verschlüsselungsfamilie, für die der IV 12 Byte lang sein muss).

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

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

    Die Nutzlast KANN leer sein. Um den Client-Geheimschlüssel zurückzusetzen, müssen Sie ihn beispielsweise mit einem leeren Wert überschreiben.

    Es gibt verschiedene Arten von Nutzlasten, je nachdem, was Sie auf dem Gerät tun möchten. Verschiedene xAPI-Befehle erwarten unterschiedliche Nutzlasten, und Sie müssen den Zweck der Nutzlast mit angeben cisco-action wie folgt:

    • Mit "cisco-action":"populate" der Geheimtext ist das Neue ClientSecret.

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

    • Mit „ "cisco-action":"activate" Der verschlüsselte Text ist der Fingerabdruck (Hexadezimaldarstellung von sha-1) des Zertifikats, das wir für die Überprüfung der Geräteidentität aktivieren.

    • Mit „ "cisco-action":"deactivate" Der verschlüsselte Text ist der Fingerabdruck (hexadezimale Darstellung von sha-1) des Zertifikats, das für die Überprüfung der Geräteidentität verwendet wird, das wir deaktivieren.

  • JWE-Authentifizierungs Etikett / "Beschriftung": Dieses Feld enthält das Authentifizierungs Etikett / "Beschriftung" , um die Integrität des gesamten JWE-Compact-Serialized-Blobs zu überprüfen

So leiten wir den Verschlüsselungscode vom ClientSecret

Nach dem ersten Auffüllen des Secrets wird das Secret weder akzeptiert noch als Nur-Text ausgegeben. Dies dient dazu, potenzielle Wörterbuchangriffe durch eine Person zu verhindern, die auf das Gerät zugreifen könnte.

Die Gerätesoftware verwendet das Client-Geheimnis als Eingabe für eine Schlüsselableitungsfunktion (KDF) und verwendet den abgeleiteten Schlüssel dann für die Inhaltsentschlüsselung/-verschlüsselung auf dem Gerät.

Das bedeutet für Sie, dass Ihr Tool zum Erstellen von JWE-Blobs dem gleichen Verfahren folgen muss, um den gleichen Verschlüsselungs-/Entschlüsselungsschlüssel vom Client-Geheimschlüssel abzuleiten.

Die verwendeten Geräte scrypt für die Schlüsselableitung (siehehttps://en.wikipedia.org/wiki/Scrypt ) mit den folgenden Parametern:

  • CostFactor (N) ist 32768

  • BlockSizeFactor (r) ist 8 Zoll

  • ParallelizationFactor (p) ist 1

  • „Salt“ ist eine zufällige Sequenz von mindestens 4 Byte; Sie müssen dieses angeben. salt beim Festlegen des cisco-kdf verwenden.

  • Schlüssellängen sind entweder 16 Byte (bei Auswahl des AES-GCM 128-Algorithmus) oder 32 Byte (bei Auswahl des AES-GCM 256-Algorithmus).

  • Max. Speicherkapazität beträgt 64 MB

Dieser Parametersatz ist die einzige Konfiguration von scrypt die mit der Schlüsselableitungsfunktion auf den Geräten kompatibel ist. Diese KDF-Datei auf den Geräten heißt "version":"1", die einzige Version, die derzeit von den cisco-kdf verwenden.

Beispiel funktioniert

Hier ist ein Beispiel, das Sie befolgen können, um zu überprüfen, ob Ihr JWE-Verschlüsselungsprozess mit dem Prozess übereinstimmt, den wir auf den Geräten erstellt haben.

In diesem Beispielszenario wird ein PEM-Blob zum Gerät hinzugefügt (ähnt dem Hinzufügen eines Zertifikats mit einer sehr kurzen Zeichenfolge anstelle eines vollständigen Zertifikats + Schlüssels). Der geheime Clientschlüssel in diesem Beispiel ist ossifrage.

  1. Wählen Sie einen Verschlüsselungscode aus. In diesem Beispiel wird A128GCM(AES mit 128-Bit-Schlüsseln im Galois-Zählermodus). Das könnte Ihr Tool gebrauchen A256GCM wenn Sie möchten.

  2. Wählen Sie ein Salt aus (muss eine zufällige Sequenz von mindestens 4 Byte sein). In diesem Beispiel wird (Hexadezimal-Byte) verwendet. E5 E6 53 08 03 F8 33 F6. Base64url-Codierung der zu erhaltenden Sequenz 5eZTCAP4M_Y(Entfernen Sie die Base64-Auffüllung).

  3. Hier ist ein Beispiel scrypt Aufruf zum Erstellen des Inhaltsverschlüsselungsschlüssels ( Verschlüsselungscode ):

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

    Der abgeleitete Schlüssel sollte wie folgt 16 Byte (Hexadezimal) umfassen: 95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac welche base64url codiert zu lZ66bdEiAQV4_mqdInj_rA.

  4. Wählen Sie eine zufällige Sequenz von 12 Bytes als Initialisierungsvektor aus. In diesem Beispiel wird (Hex) verwendet. 34 b3 5d dd 5f 53 7b af 2d 92 95 83 welche base64url codiert zu NLNd3V9Te68tkpWD.

  5. Erstellen Sie den Jose-Header mit kompakter Serialisierung (folgen Sie der Reihenfolge der Parameter, die wir hier verwenden), und codieren Sie ihn 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 des JWE-Blobs.

  6. Das zweite Element des JWE-Blobs ist leer, da wir keinen JWE- Verschlüsselungscode bereitstellen.

  7. Das dritte Element des JWE-Blobs ist der Initialisierungsvektor NLNd3V9Te68tkpWD.

  8. Verwenden Sie Ihr JWE-Verschlüsselungstool, um eine verschlüsselte Nutzlast zu erstellen und zu Etikett / "Beschriftung". In diesem Beispiel ist die unverschlüsselte Nutzlast der gefälschte PEM-Blob this is a PEM file

    Die folgenden Verschlüsselungsparameter sollten verwendet werden:

    • Nutzlast ist this is a PEM file

    • Verschlüsselungscode ist AES 128 GCM

    • Der Base64url-codierte Jose-Header als zusätzliche authentifizierte Daten (AAD)

    Base64url codiert die verschlüsselte Nutzlast, was zu führen sollte f5lLVuWNfKfmzYCo1YJfODhQ

    Dies ist das vierte Element (JWE Ciphertext) im JWE-Blob.

  9. Base64url-Codierung des Etikett / "Beschriftung" , das Sie in Schritt 8 erstellt haben, was zu führen sollte PE-wDFWGXFFBeo928cfZ1Q

    Dies ist das fünfte Element im JWE-Blob.

  10. Verketten Sie die fünf Elemente des JWE-Blobs mit Punkten (Joseheader..IV.Ciphertext.Tag), um Folgendes zu erhalten:

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

  11. Wenn Sie die gleichen base64url-codierten Werte wie hier gezeigt mit Ihren eigenen Tools abgeleitet haben, können Sie sie verwenden, um die E2E-Verschlüsselung und verifizierte Identität Ihrer Geräte zu sichern.

  12. Dieses Beispiel funktioniert nicht wirklich, aber im Prinzip besteht Ihr nächster Schritt darin, das oben erstellte JWE-Blob als Eingabe für den xcommand auf dem Gerät zu verwenden, das das Zertifikat hinzufügt:

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

Sitzungstypen für Zero-Trust-Meetings stehen allen Meeting-Sites ohne zusätzliche Kosten zur Verfügung. Einer dieser Sitzungstypen wird als Pro-End to End Encryption_VOIPonly. Dies ist der Name des öffentlichen Dienstes , den wir in Zukunft ändern können. Die aktuellen Namen der Sitzungstypen finden Sie unter Sitzungstyp-IDs im Referenz Abschnitt dieses Artikels.

Sie müssen nichts tun, um diese Funktion für Ihre Site zu erhalten; Sie müssen den neuen Sitzungstyp (auch genannt Meeting Privilege ) Benutzern gewähren. Sie können dies einzeln über die Konfigurationsseite des Benutzers oder in großen Mengen mit einem CSV -Export/-Import tun.

1

Melden Sie sich bei Control Hub an, und rufen Sie Dienste > Meeting auf.

2

Klicken Sie auf Sites, wählen Sie die Webex-Seite aus, für die Sie die Einstellungen ändern möchten, und klicken Sie dann auf Einstellungen.

3

Unter Allgemeine Einstellungen , auswählen Sitzungstypen .

4
Es sollte mindestens ein Sitzungstyp für die End-to-End-Verschlüsselung angezeigt werden. Siehe die Liste der Sitzungstyp-IDs im Referenz Abschnitt dieses Artikels. Sie sehen beispielsweise End-to-End-Encryption_ Nur VOIP .

 

Es gibt einen älteren Sitzungstyp mit einem sehr ähnlichen Namen: End-to-End-Verschlüsselung . Dieser Sitzungstyp umfasst den unverschlüsselten Amtszugang auf Meetings. Stellen Sie sicher, dass Sie die_ Nur VOIP um eine durchgängige Verschlüsselung sicherzustellen. Sie können es überprüfen, indem Sie den Mauszeiger über die PRO Link in der Spalte mit dem Sitzungscode; In diesem Beispiel sollte das Ziel des Links sein javascript:ShowFeature(652).

Wir können die öffentlichen Dienstnamen für diese Sitzungstypen in Zukunft ändern.

5

Wenn Sie den neuen Sitzungstyp noch nicht haben, wenden Sie sich an Ihren Webex -Vertreter.

Nächste Schritte

Aktivieren Sie diese Sitzungstyp /Meeting-Berechtigung für einige oder alle Benutzer.

1

Anmelden bei Control Hub , und gehen Sie zu Verwaltung > Benutzer .

2

Wählen Sie ein zu aktualisierendes Benutzerkonto und anschließend Meetings .

3

Wählen Sie in der Dropdown-Liste Einstellungen gelten für die zu aktualisierende Meeting-Site aus.

4

Aktivieren Sie das Kontrollkästchen neben End-to-End-Encryption_ Nur VOIP .

5

Schließen Sie den Benutzerkonfiguration“ .

6

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

Um dies vielen Benutzern zuzuweisen, verwenden Sie die nächste Option, E2EE-Meetings für mehrere Benutzer aktivieren .

1

Melden Sie sich bei Control Hub an, und rufen Sie Dienste > Meeting auf.

2

Klicken Sie auf Sites , wählen Sie die Webex-Site aus, für die Sie die Einstellungen ändern möchten.

3

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

4

Klicken Sie auf Bericht erstellen und warten Sie, während wir die Datei vorbereiten.

5

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

6

Öffnen Sie die heruntergeladene CSV-Datei zur Bearbeitung.

Es gibt eine Zeile für jeden Benutzer und das Symbol MeetingPrivilege enthält die Sitzungstyp IDs als kommagetrennte Liste.

7

Fügen Sie für jeden Benutzer, dem Sie den neuen Sitzungstyp zuweisen möchten, 1561 als neuen Wert in der durch Kommas getrennten Liste im MeetingPrivilege Zelle.

Das Webex CSV -Dateiformatreferenz enthält Details zum Zweck und Inhalt der CSV-Datei.

8

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


 

Wenn Sie sich bereits auf der Seite Meeting-Site-Liste befanden, müssen Sie sie möglicherweise aktualisieren.

9

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

10

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

11

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

12

Gehen Sie zum Benutzer Seite und öffnen Sie einen der Benutzer, um zu überprüfen, ob er über den neuen Sitzungstyp.

Sie können Meeting-Aufzeichnungen mit dem folgenden Wasserzeichen versehen: Webex Meetings Pro-End to End Encryption_VOIPonly Sitzungstyp, mit dem Sie den Quell-Client oder das Gerät für nicht autorisierte Aufzeichnungen vertraulicher Meetings identifizieren können.

Wenn diese Funktion aktiviert ist, enthält das Meeting-Audio eine eindeutige Kennung für jeden teilnehmenden Client oder jedes Gerät. Sie können Audioaufzeichnungen in Control Hub hochladen, der dann die Aufzeichnung analysiert und nach den eindeutigen IDs sucht. Sie können die Ergebnisse anzeigen, um zu sehen, welcher Quell-Client oder welches Gerät das Meeting aufgezeichnet hat.

  • Die Aufzeichnung muss für die Analyse im Format AAC, MP3, M4A, WAV, MP4, AVI oder MOV vorliegen und darf nicht größer als 500 MB sein.
  • Die Aufzeichnung muss länger als 100 Sekunden sein.
  • Sie können nur Aufzeichnungen von Meetings analysieren, die von Personen in Ihrer Organisation abgehalten werden.
  • Wasserzeicheninformationen werden für die gleiche Dauer wie die Meeting-Informationen der Organisation aufbewahrt.
Hinzufügen von Audio- Wasserzeichen zu E2EE-Meetings
  1. Melden Sie sich bei Control Hub an, und wählen Sie dann unter Verwaltung die Organisationseinstellungen aus.
  2. Im Wasserzeichen für Meetings Abschnitt, aktivieren Wasserzeichen .

    Einige Zeit nachdem diese Option aktiviert wurde, setzen Benutzer Meetings mit dem Webex Meetings Pro-End to End Encryption_VOIPonly Sitzungstyp siehe die Option Digitales Wasserzeichen im Abschnitt Sicherheit.

Hochladen und Analysieren eines mit Wasserzeichen versehenen Meetings
  1. In Control Hub, unter Überwachung , auswählen Fehlerbehebung .
  2. Klicken Sie auf Wasserzeichenanalyse .
  3. Suchen Sie das Meeting in der Liste oder wählen Sie es aus, und klicken Sie dann auf „Analysieren“ .
  4. Im Audio- Wasserzeichen analysieren einen Namen für Ihre Analyse ein.
  5. (Optional) Geben Sie einen Hinweis für Ihre Analyse ein.
  6. Ziehen Sie die zu analysierende Audiodatei per Drag-and-Drop oder klicken Sie auf Datei auswählen um zur Audiodatei zu navigieren.
  7. Auf Schließen.

    Wenn die Analyse abgeschlossen ist, wird sie in der Liste der Ergebnisse auf dem Wasserzeichen analysieren Seite.

  8. Wählen Sie das Meeting in der Liste aus, um die Ergebnisse der Analyse anzuzeigen. Klicken Sie aufSchaltfläche „Herunterladen“ um die Ergebnisse herunterzuladen.
Funktionen und Einschränkungen

Faktoren, die an der erfolgreichen Dekodierung eines aufgezeichneten Wasserzeichens beteiligt sind, sind der Abstand zwischen dem Aufzeichnungsgerät und dem Lautsprecher, der das Audio ausgibt, die Lautstärke dieses Audios, Umgebungsgeräusche usw. Unsere Wasserzeichentechnologie hat zusätzliche Widerstandsfähigkeit, mehrmals codiert zu werden, wie es bei der Medienfreigabe passieren kann.

Diese Funktion wurde entwickelt, um eine erfolgreiche Dekodierung des Wasserzeichenbezeichners in einem breiten, aber angemessenen Satz von Umständen zu ermöglichen. Unser Ziel ist es, dass ein Aufzeichnungsgerät, z. B. ein Mobiltelefon, das auf einem Schreibtisch in der Nähe eines persönlichen Endpunkts oder eines Laptop-Clients liegt, immer eine Aufzeichnung erstellt, die zu einer erfolgreichen Analyse führt. Wenn das Aufzeichnungsgerät von der Quelle entfernt oder das gesamte Audiospektrum nicht mehr gehört wird, sinken die Chancen auf eine erfolgreiche Analyse.

Um eine Aufzeichnung erfolgreich analysieren zu können, ist eine angemessene Aufzeichnung des Meeting-Audios erforderlich. Wenn das Audio eines Meetings auf demselben Computer aufgezeichnet wird, auf dem der Client gehostet wird, sollten keine Einschränkungen gelten.

Wenn Ihre Geräte bereits in Ihrer Control Hub-Organisation integriert sind und Sie die Webex CA verwenden möchten, um ihre identifizierenden Zertifikate automatisch zu generieren, müssen Sie die Geräte nicht auf die Werkseinstellung .

Mit diesem Verfahren wird ausgewählt, welche Domäne das Gerät verwendet, um sich selbst zu identifizieren. Es ist nur erforderlich, wenn Ihre Control Hub-Organisation über mehrere Domänen verfügt. Wenn Sie mehr als eine Domäne haben, empfehlen wir Ihnen, dies für alle Ihre Geräte zu tun, die über eine von Cisco verifizierte Identität verfügen. Wenn Sie Webex nicht mitteilen, welche Domäne das Gerät identifiziert, wird automatisch eine ausgewählt und kann für andere Meeting-Teilnehmer falsch dargestellt werden.

Vorbereitungen

Wenn Ihre Geräte noch nicht integriert sind, folgen Sie Registrieren eines Geräts in Cisco Webex über die API oder die lokale Weboberfläche oder Cloud-Onboarding für Board-, Desk- und Room-Serien . Sie sollten auch die Domäne(n) verifizieren, die Sie verwenden möchten, um die Geräte in zu identifizieren Domänen verwalten .

1

Bei Control Hub anmelden , und unter Verwaltung , auswählen Geräte .

2

Wählen Sie ein Gerät aus, um seinen Konfigurationsbereich 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

Sie benötigen:

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

  • Um das Thema zu lesen Grundlegendes zum externen Identitätsprozess für Geräte , im Vorbereiten Teil dieses Artikels.

  • Vorbereitung eines JWE-Verschlüsselungstools in Bezug auf die darin enthaltenen Informationen.

  • Ein Tool zum Generieren zufälliger Bytesequenzen einer bestimmten Länge.

  • Ein Tool zur Base64url-Codierung von Bytes oder Text.

  • An scrypt Implementierung.

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

1

Füllen Sie die ClientSecret mit einem Nur-Text-Geheimschlüssel:

Beim ersten Ausfüllen des Felds Secret, geben Sie ihn im Klartext an. Aus diesem Grund empfehlen wir, dass Sie dies an der physischen Gerätekonsole tun.

  1. Base64url-Codierung der geheimen Phrase für dieses Gerät.

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

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

    Der obige Beispielbefehl füllt das Secret mit dem Begriff 0123456789abcdef. Sie müssen Ihre eigenen auswählen.

Das Gerät verfügt über einen Initial Secret. Vergessen Sie Folgendes nicht. Sie können es nicht wiederherstellen und müssen das Gerät auf die Werkseinstellungen zurücksetzen, um erneut zu starten.
2

Verknüpfen Sie Ihr Zertifikat und Ihren privaten Schlüssel:

  1. Öffnen Sie die PEM-Dateien in einem Text- Editor, fügen Sie das Schlüsselblob in das Zertifikatblob ein und speichern Sie es als neue PEM-Datei.

    (Dies ist der Nutzlasttext, den Sie verschlüsseln und in Ihr JWE-Blob einfügen.)

3

Erstellen Sie ein JWE-Blob, das als Eingabe für den Befehl zum Hinzufügen von Zertifikaten verwendet werden soll:

  1. Erstellen Sie eine zufällige Sequenz von mindestens 4 Bytes. Das ist Ihr Salz.

  2. Leiten Sie einen Inhaltsverschlüsselungsschlüssel mit Ihrem Verschlüsselungscode -Tool ab.

    Dazu benötigen Sie das Secret, das Salt und eine Schlüssellänge, die mit dem von Ihnen ausgewählten Verschlüsselungsverfahren übereinstimmt. Es müssen noch einige andere feste Werte angegeben werden (N=32768, r=8, p=1). Das Gerät verwendet den gleichen Prozess und die gleichen Werte, um den gleichen Inhaltsverschlüsselungsschlüssel Verschlüsselungscode.

  3. Erstellen Sie eine zufällige Sequenz von genau 12 Bytes. Dies ist Ihr Initialisierungsvektor.

  4. Jose-Kopfzeile erstellen, Einstellung alg, enc, und cisco-kdf Tasten wie beschrieben unter Grundlegendes zum externen Identitätsprozess für Geräte . Legen Sie die Aktion "Hinzufügen" mit dem Schlüssel:Wert . fest "cisco-action":"add" in Ihrer Jose-Kopfzeile einzugeben (weil wir das Zertifikat zum Gerät hinzufügen).

  5. Base64url-Codierung des Jose-Headers.

  6. Verwenden Sie Ihr JWE-Verschlüsselungstool mit der ausgewählten Verschlüsselung und dem base64url-codierten Jose-Header, um den Text aus der verketteten PEM-Datei zu verschlüsseln.

  7. Base64url codiert den Initialisierungsvektor, die verschlüsselte PEM-Nutzlast und das Authentifizierungs Etikett / "Beschriftung".

  8. Konstruieren Sie das JWE-Blob wie folgt (alle Werte sind base64url-codiert):

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4

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

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

Überprüfen Sie, ob das Zertifikat hinzugefügt wurde, indem Sie Folgendes ausführen: xcommand Security Certificates Services Show

Kopieren Sie den Fingerabdruck des neuen Zertifikats.

6

Aktivieren Sie das Zertifikat für diesen Zweck WebexIdentity:

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

  2. Erstellen Sie eine zufällige Sequenz von mindestens 4 Bytes und codieren Sie diese Sequenz mit base64url. Das ist Ihr Salz.

  3. Leiten Sie einen Inhaltsverschlüsselungsschlüssel mit Ihrem Verschlüsselungscode -Tool ab.

    Dazu benötigen Sie das Secret, das Salt und eine Schlüssellänge, die mit dem von Ihnen ausgewählten Verschlüsselungsverfahren übereinstimmt. Es müssen noch einige andere feste Werte angegeben werden (N=32768, r=8, p=1). Das Gerät verwendet den gleichen Prozess und die gleichen Werte, um den gleichen Inhaltsverschlüsselungsschlüssel Verschlüsselungscode.

  4. Erstellen Sie eine zufällige Sequenz von genau 12 Bytes, und codieren Sie diese Sequenz mit base64url. Dies ist Ihr Initialisierungsvektor.

  5. Jose-Kopfzeile erstellen, Einstellung alg, enc, und cisco-kdf Tasten wie beschrieben unter Grundlegendes zum externen Identitätsprozess für Geräte . Legen Sie die Aktion "Aktivieren" mithilfe des Schlüssels:Wert . fest "cisco-action":"activate" in Ihrer Jose-Kopfzeile einzugeben (weil wir das Zertifikat auf dem Gerät aktivieren).

  6. Base64url-Codierung des Jose-Headers.

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

    Das Tool sollte eine 16- oder 32-Byte-Sequenz sowie ein Authentifizierungs Etikett / "Beschriftung" ausgeben, je nachdem, ob Sie 128- oder 256-Bit- AES -GCM ausgewählt haben.

  8. Base64urlencode des verschlüsselten Fingerabdrucks und das Authentifizierungs Etikett / "Beschriftung".

  9. Konstruieren Sie das JWE-Blob wie folgt (alle Werte sind base64url-codiert):

    JOSEHeader..InitVector.EncryptedFingerprint.AuthTag

  10. Öffnen Sie die TShell auf dem Gerät und führen Sie den folgenden activate-Befehl aus:

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

Integrieren Sie das Gerät in Ihre Control Hub-Organisation.

1

Setzen Sie ein Meeting des richtigen Typs an ( Webex Meetings Pro – End-to-End Encryption_ Nur VOIP ).

2

Treten Sie dem Meeting als Gastgeber über einen Webex Meetings -Client 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 in der Lobby mit dem richtigen Identitätssymbol 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 in der Lobby mit dem richtigen Identitätssymbol angezeigt wird. Weitere Informationen zu Identitätssymbolen .

7

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

8

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

9

Lassen Sie als Gastgeber Personen/Geräte zu oder lehnen Sie sie ab.

10

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

11

Überprüfen Sie, ob allen Meeting-Teilnehmern derselbe Meeting-Sicherheitscode angezeigt wird.

12

Treten Sie dem Meeting mit einem neuen Teilnehmer bei.

13

Überprüfen Sie, ob allen Benutzern derselbe neue Meeting-Sicherheitscode angezeigt wird.

Möchten Sie durchgängig verschlüsselte Meetings als Standardoption für Meetings festlegen oder sie nur für einige Benutzer aktivieren oder allen Gastgebern die Entscheidung ermöglichen? Wenn Sie sich entschieden haben, wie Sie diese Funktion verwenden möchten, bereiten Sie die Benutzer vor, die sie verwenden werden, insbesondere im Hinblick auf die Einschränkungen und den Ablauf des Meetings.

Müssen Sie sicherstellen, dass weder Cisco noch ein anderer Benutzer Ihre Inhalte entschlüsseln oder die Identität Ihrer Geräte imitieren können? In diesem Fall benötigen Sie Zertifikate von einer öffentlichen Zertifizierungsstelle. Sie können maximal 25 Geräte in einem sicheren Meeting verwenden. Wenn Sie diese Sicherheitsstufe benötigen, sollten Sie nicht zulassen, dass Meeting-Clients beitreten.

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

Wenn Sie unterschiedliche Ebenen der Identitätsverifizierung haben, ermöglichen Sie es den Benutzern, sich gegenseitig mit einer zertifikatgestützten Identität und dem Meeting-Sicherheitscode zu verifizieren. Auch wenn es Umstände gibt, unter denen Teilnehmer als nicht verifiziert angezeigt werden können und sie sollten wissen, wie man sie überprüft, können nicht verifizierte Personen keine Betrüger sein.

Wenn Sie eine externe CA zum Ausstellen Ihrer Gerätezertifikate verwenden, liegt es bei Ihnen, Zertifikate zu überwachen, zu aktualisieren und erneut anzuwenden.

Wenn Sie das Initial Secret erstellt haben, sollten Sie sich darüber im Klaren sein, dass Ihre Benutzer möglicherweise das Secret für ihre Geräte ändern möchten. Möglicherweise müssen Sie eine Benutzeroberfläche erstellen/ein Tool verteilen, um dies zu ermöglichen.

Tabelle 1: Sitzungstyp-IDs für Meetings mit durchgängiger Verschlüsselung

Sitzungstyp- ID

Name des öffentlichen Dienstes

638

Nur E2E-Verschlüsselung + VoIP

652

End-to-End-Encryption_ Nur VOIP

660 °C

Pro 3 Free-End-to-End-Encryption_ Nur VOIP

E2E-Verschlüsselung + Identität

672

Pro 3 Free50-End-to-End Encryption_ Nur VOIP

673

Education Kursleiter E2E Encryption_ Nur VOIP

676

BroadWorks-Standard plus Ende-zu-Ende-Verschlüsselung

677

Broadworks Premium plus Ende-zu-Ende-Verschlüsselung

681

Schoology Free plus Ende-zu-Ende-Verschlüsselung

In diesen Tabellen werden die API -Befehle für Webex -Geräte beschrieben, die wir für Meetings mit durchgängiger Verschlüsselung und Identitätsverifizierung hinzugefügt haben. Weitere Informationen zur Verwendung der API finden Sie unter Zugriff auf die API für Webex Room und Desk Devices und Webex Boards .

Diese xAPI-Befehle sind nur auf Geräten verfügbar, die entweder:

  • Registriert bei Webex

  • Lokal registriert und mit Webex über Webex Edge für Geräte verknüpft

Tabelle 2: APIs auf Systemebene für durchgängig verschlüsselte Meetings und verifizierte Identität

API-Aufruf

Beschreibung

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

Diese Konfiguration erfolgt, wenn der Administrator die bevorzugte Domäne des Geräts über Control Hub festlegt. 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 CA anfordert. Die Domäne identifiziert dann das Gerät.

Diese Konfiguration ist nicht anwendbar, wenn das Gerät über ein aktives, extern ausgestelltes Zertifikat verfügt, um sich zu identifizieren.

xStatus Conference EndToEndEncryption Availability

Gibt an, ob das Gerät einem Meeting mit durchgängiger Verschlüsselung beitreten kann. Die Cloud- API ruft sie auf, damit eine gekoppelte App weiß, ob sie das Gerät für den Beitritt verwenden kann.

xStatus Conference EndToEndEncryption ExternalIdentity Verification

Gibt an, ob das Gerät External Verifizierung (verfügt über ein extern ausgestelltes Zertifikat).

xStatus Conference EndToEndEncryption ExternalIdentity Identity

Die Identität des Geräts gemäß dem allgemeinen Namen des extern ausgestellten Zertifikats.

xStatus Conference EndToEndEncryption ExternalIdentity CertificateChain Certificate # specificinfo

Liest bestimmte Informationen aus einem extern ausgestellten Zertifikat.

Im angezeigten Befehl ersetzen # durch die Nummer des Zertifikats. Replace specificinfo mit einer der folgenden Optionen:

  • Fingerprint

  • NotAfter Enddatum der Gültigkeit

  • NotBefore Startdatum der Gültigkeit

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

  • Subject # Name Eine Liste der Antragsteller für das Zertifikat (z. B. E-Mail-Adresse oder Domänenname)

  • Validity Gibt den Gültigkeitsstatus dieses Zertifikats an (z. B valid oder expired)

xStatus Conference EndToEndEncryption ExternalIdentity Status

Der Status der externen Identität des Geräts (z. B valid oder error).

xStatus Conference EndToEndEncryption InternalIdentity Verification

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

xStatus Conference EndToEndEncryption InternalIdentity Identity

Die Identität des Geräts, wie sie aus dem allgemeinen Namen des von Webex ausgestellten Zertifikats gelesen wird.

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

Ist leer, wenn die Organisation über keine Domäne verfügt.

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

xStatus Conference EndToEndEncryption InternalIdentity CertificateChain Certificate # specificinfo

Liest bestimmte Informationen aus dem von Webex ausgestellten Zertifikat.

Im angezeigten Befehl ersetzen # durch die Nummer des Zertifikats. Replace specificinfo mit einer der folgenden Optionen:

  • Fingerprint

  • NotAfter Enddatum der Gültigkeit

  • NotBefore Startdatum der Gültigkeit

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

  • Subject # Name Eine Liste der Antragsteller für das Zertifikat (z. B. E-Mail-Adresse oder Domänenname)

  • Validity Gibt den Gültigkeitsstatus dieses Zertifikats an (z. B valid oder expired)

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

API-Aufruf

Beschreibung

xEvent Conference ParticipantList ParticipantAdded

xEvent Conference ParticipantList ParticipantUpdated

xEvent Conference ParticipantList ParticipantDeleted

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

Tabelle 4. ClientSecret-bezogene APIs für durchgängig 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-codierten Nur-Text-Wert für das erstmalige Seeding des Client-Geheimschlüssels auf dem Gerät.

Wenn Sie das Secret nach dem ersten Mal aktualisieren möchten, müssen Sie ein JWE-BLOB angeben, das das neue und durch das alte Secret verschlüsselte Secret enthält.

xCommand Security Certificates Services Add JWEblob

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

Wir haben diesen Befehl erweitert, um ein JWE-Blob zu akzeptieren, das 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 identifizierende Fingerabdruck verschlüsselt und in einem JWE-BLOB 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 identifizierende Fingerabdruck verschlüsselt und in einem JWE-BLOB serialisiert wird.