Benutzererfahrung

Benutzer wählen beim Ansetzen eines Meetings den Meeting-Typ aus. Beim Zulassen von Teilnehmern aus der Lobby sowie während des Meetings kann der Gastgeber den Status der Identitätsüberprüfung der einzelnen Teilnehmer sehen. Es gibt auch einen Meeting-Code, der allen aktuellen Meeting-Teilnehmern gemeinsam ist und mit dem sie überprüfen können, ob ihr Meeting nicht von einem unerwünschten Meddler-in-the-Middle-Angriff (MITM) eines Drittanbieters abgefangen wurde.

Teilen Sie die folgenden Informationen mit Ihren Meeting-Gastgebern:

Identitätsüberprüfung mit interner oder externer Zertifizierungsstelle

Identität überprüfen

Durchgängige Verschlüsselung mit Identitätsverifizierung bietet zusätzliche Sicherheit für Meetings mit durchgängiger Verschlüsselung.

Wenn Teilnehmer oder Geräte einer gemeinsam genutzten MLS-Gruppe (Messaging Layer Security) beitreten, legen sie ihre Zertifikate den anderen Gruppenmitgliedern vor, die die Zertifikate anschließend mit den ausstellenden Zertifizierungsstellen (CA) validieren. Durch die Bestätigung, dass die Zertifikate gültig sind, überprüft die Zertifizierungsstelle die Identität der Teilnehmer, und das Meeting zeigt die Teilnehmer/Geräte als verifiziert an.

Benutzer der Webex-App authentifizieren sich beim Webex Identity Store, der ihnen bei erfolgreicher Authentifizierung ein Zugriffs-Token ausgibt. Wenn sie ein Zertifikat benötigen, um ihre Identität in einem durchgängig verschlüsselten Meeting zu verifizieren, stellt ihnen die Webex-Zertifizierungsstelle basierend auf ihrem Zugriffstoken ein Zertifikat aus. Derzeit bieten wir Benutzern von Webex Meetings keine Möglichkeit, ein von einer externen/externen Zertifizierungsstelle ausgestelltes Zertifikat zu erhalten.

Geräte können sich mithilfe eines von einer internen (Webex-)Zertifizierungsstelle oder eines von einer externen Zertifizierungsstelle ausgestellten Zertifikats authentifizieren:

  • Interne CA: Webex stellt ein internes Zertifikat aus, das auf dem Zugriffstoken des Gerätecomputerkontos basiert. Das Zertifikat wird von der Webex CA signiert. Geräte besitzen keine Benutzer-IDs auf dieselbe Weise wie Benutzer. Daher verwendet Webex (eine der) Domänen Ihrer Organisation, wenn die Identität des Gerätezertifikats (Allgemeiner Name (CN)) geschrieben wird.

  • Externe CA: Gerätezertifikate direkt vom ausgewählten Aussteller anfordern und kaufen. Sie müssen die Zertifikate mit einem geheimen Schlüssel verschlüsseln, direkt hochladen und autorisieren, der nur Ihnen bekannt ist.

    Cisco ist nicht beteiligt, was auf diese Weise eine echte End-to-End-Verschlüsselung und verifizierte Identität gewährleistet und die theoretische Möglichkeit verhindert, dass Cisco Ihr Meeting abhören/Ihre Medien entschlüsseln könnte.

Intern ausgestelltes Gerätezertifikat

Webex stellt ein Zertifikat an das Gerät aus, wenn es sich nach dem Start registriert, 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, 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 mitzuteilen, 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" verwenden.

Wenn Sie über mehrere Domänen verfügen 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 einem Gerät sein eigenes Zertifikat bereitstellen, das mit einer der öffentlichen Zertifizierungsstellen 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 alternative Antragstellername (SAN) werden auf der Benutzeroberfläche des Webex-Meetings angezeigt, wie unter End-to-End-Verschlüsselung mit Identitätsverifizierung für Webex Meetings beschrieben.

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 Manipulationen zu schützen, wird eine Client-Geheimfunktion zum Verschlüsseln und Signieren verschiedener xcommands verwendet.

Wenn Sie den Client-Geheimschlüssel verwenden, 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 bereit.

Funktionen und Einschränkungen

Geräte

Die folgenden in der Cloud registrierten Geräte der Webex Room-Serie und der Webex Desk-Serie können E2EE-Meetings beitreten:

  • Webex Board

  • Webex Desk Pro

  • Webex Desk

  • Webex Room Kit

  • Webex Room Kit Mini

Die folgenden Geräte können E2EE-Meetings nicht beitreten:

  • Webex C-Serie

  • Webex DX-Serie

  • Webex EX-Serie

  • Webex MX-Serie

  • SIP-Geräte von Drittanbietern

Software-Clients

  • Die Webex-App für Desktop- und mobile Clients kann E2EE-Meetings beitreten.

  • Der Webex-Web-Client kann E2EE-Meetings nicht beitreten.

  • SIP-Soft-Clients von Drittanbietern können E2EE-Meetings nicht beitreten.

Identität

  • Standardmäßig bieten wir keine Control Hub-Optionen zur Verwaltung einer extern verifizierten Geräteidentität an. Für eine echte End-to-End-Verschlüsselung sollten nur Sie die geheimen Schlüssel und Schlüssel kennen bzw. darauf zugreifen. Wenn wir einen Cloud-Dienst zur Verwaltung dieser Schlüssel eingeführt haben, besteht die Möglichkeit, dass sie abgefangen werden.

  • Derzeit bieten wir ein „Rezept“ für Sie, um Ihre eigenen Tools zu entwerfen, basierend auf branchenüblichen Verschlüsselungstechniken, die bei der Anforderung oder Verschlüsselung Ihrer Geräteidentitätszertifikate und ihrer privaten Schlüssel helfen. Wir wollen keinen echten oder wahrgenommenen Zugang zu Ihren Geheimnissen oder Schlüsseln haben.

Meetings

  • E2EE-Meetings unterstützen derzeit maximal 1000 Teilnehmer.

  • Sie können neue Whiteboards in E2EE-Meetings freigeben. Es gibt einige Unterschiede zu Whiteboards in regulären Meetings:
    • In E2EE-Meetings können Benutzer nicht auf Whiteboards zugreifen, die außerhalb des Meetings erstellt wurden, einschließlich privater Whiteboards, von anderen geteilte Whiteboards und Whiteboards aus Webex-Bereichen.
    • In E2EE-Meetings erstellte Whiteboards sind nur während des Meetings verfügbar. Sie werden nicht gespeichert und sind nach Ende des Meetings nicht mehr verfügbar.
    • Wenn jemand Inhalte in einem E2EE-Meeting teilt, können Sie diese kommentieren. Weitere Informationen zu Kommentaren finden Sie unter Webex-App | Freigegebene Inhalte mit Kommentaren markieren.

Verwaltungsschnittstelle

Wir empfehlen Ihnen dringend, Control Hub zur Verwaltung Ihrer Meetings-Site zu verwenden, da Control Hub-Organisationen über eine zentralisierte Identität für die gesamte Organisation verfügen.

Zusätzliche Ressourcen
Voraussetzungen

  • Webex Meetings 41.7.

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

  • Administrativer Zugriff auf die Meeting-Site in Control Hub.

  • 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 Personen über ihr Videosystem beitreten können. Weitere Informationen finden Sie unter Zulassen, dass Videosysteme Meetings und Events auf Ihrer Webex-Site beitreten.

Gerätezertifikate abrufen

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

Für höchste Sicherheitsstufe und zur Identitätsüberprüfung sollte jedes Gerät über ein eindeutiges Zertifikat verfügen, das von einer vertrauenswürdigen öffentlichen Zertifizierungsstelle (CA) ausgestellt wird.

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

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

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

  • Allgemeiner Name (CN) und Subject Alternate Name(s) (SAN/s): Diese sind für Webex nicht wichtig, sollten aber Werte sein, die der Mensch lesen und mit dem Gerät assoziieren kann. 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 prüfen, sehen sie die SAN(s). Möglicherweise möchten Sie Namen wie name.model@example.com verwenden.

  • Dateiformat: Die Zertifikate und Schlüssel müssen im .pem -Format vorliegen.

  • 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 unter Verwendung der P-256-Kurve).

    Diese Anforderung erstreckt sich nicht auf den Signierungsschlüssel. Die Zertifizierungsstelle kann das Zertifikat mit einem RSA-Schlüssel signieren.

Das Onboarding von Geräten vorbereiten

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

Registrieren Sie neue Geräte, wenn Sie diese noch nicht bei Webex. Um sicher zu sein, verbinden Sie sie zu diesem Zeitpunkt nicht mit dem Netzwerk.

Wenn Sie über vorhandene Geräte verfügen, die Sie 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.

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

  • Stellen Sie den physischen Zugang zu den Geräten sicher. Wenn Sie über das Netzwerk auf Geräte zugreifen müssen, sollten Sie sich bewusst sein, dass Geheimnisse im reinen Textformat verkehren und Ihre Sicherheit gefährdet ist.

Sobald Sie diese Schritte abgeschlossen haben, erlauben Sie Videosystemen, Meetings und Events auf Ihrer Webex-Site beizutreten.

Den externen Identitätsprozess für Geräte verstehen

Um sicherzustellen, dass Ihre Gerätemedien von niemandem außer 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 des verschlüsselten Zertifikats mithilfe von JSON Web Encryption (JWE) zu ermöglichen.

Um eine echte End-to-End-Verschlüsselung über unsere Cloud sicherzustellen, können wir nicht an der Verschlüsselung und dem Upload des Zertifikats und des Schlüssels beteiligt sein. Wenn Sie dieses Sicherheitsniveau 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 erstes Geheimnis für jedes Gerät, um die Verschlüsselungsfunktion des Geräts auszurichten.

  4. Entwickeln und pflegen Sie Ihr eigenes Tool zur Verschlüsselung von Dateien mit dem JWE-Standard.

    Der Prozess und die (nicht geheimen) Parameter, die Sie benötigen, werden im Folgenden erläutert, sowie ein Rezept, das Sie in Ihren Entwicklungstools Ihrer Wahl befolgen müssen. Wir stellen auch einige Testdaten und die daraus resultierenden JWE-Blobs bereit, wie wir sie erwarten, um Ihnen bei der Überprüfung Ihres Prozesses zu helfen.

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

  5. Verknüpfen und verschlüsseln Sie das Zertifikat und den Schlüssel mit Ihrem Tool und dem ursprünglichen Gerätegeheimnis.

  6. Laden Sie den resultierenden 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 Oberfläche für Ihr Tool bereit (oder verteilen), damit Gerätebenutzer das ursprüngliche Geheimnis ändern und ihre Medien vor Ihnen schützen können.

Wie wir das JWE-Format verwenden

In diesem Abschnitt wird beschrieben, wie wir erwarten, dass die JWE als Eingabe für die Geräte erstellt wird, so dass 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/rfc7516 und JSON Web Signature (JWS) https://datatracker.ietf.org/doc/html/rfc7515.

Wir verwenden die kompakte Serialisierung eines JSON-Dokuments, um JWE-Blobs zu erstellen. Die folgenden Parameter müssen Sie beim Erstellen der JWE-Blobs berücksichtigen:

  • JOSE Header (geschützt). In der JSON-Objektsignatur und -verschlüsselung MÜSSEN Sie die folgenden Schlüssel-Wert-Paare enthalten:

    • "alg":"dir"

      Der direkte Algorithmus ist der einzige, den wir für die Verschlüsselung der Nutzlast unterstützen. Sie müssen den ursprü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 sind nach den xAPI-Befehlen auf dem Gerät benannt, auf dem Sie die verschlüsselten Daten verwenden.

      Wir haben es benannt, cisco-action um mögliche Konflikte mit zukünftigen JWE-Erweiterungen zu vermeiden.

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

      Ein anderer proprietärer Schlüssel. Wir verwenden die von Ihnen angegebenen Werte als Eingaben für die Schlüsselableitung auf dem Gerät. Der version muss sein 1 (die Version unserer wichtigsten Ableitungsfunktion). 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 vom ursprünglichen ClientSecret ab.

  • JWE-Initialisierungsvektor. Sie müssen einen base64url-codierten Initialisierungsvektor für die Entschlüsselung der Nutzlast bereitstellen. Die IV MUSS ein zufälliger 12-Byte-Wert sein (wir verwenden die AES-GCM-Verschlüsselungsfamilie, für die die IV 12 Byte lang sein muss).

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

  • JWE-Schlüssel-Text: Dies ist die verschlüsselte Nutzlast, die Sie geheim halten möchten.

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

    Es gibt verschiedene Arten von Nutzlasten, abhängig davon, was Sie auf dem Gerät zu tun versuchen. Verschiedene xAPI-Befehle erwarten unterschiedliche Nutzlasten, und Sie müssen den Zweck der Nutzlast mit dem cisco-action Schlüssel wie folgt angeben:

    • Mit "cisco-action":"populate" dem Schlüssel-Text ist der neue ClientSecret.

    • Bei ""cisco-action":"add" ist der Schlüssel-Text ein PEM-Blob mit dem Zertifikat und seinem privaten Schlüssel (verkettet).

    • Bei „"cisco-action":"activate" ist der Verschlüsseltext der Fingerabdruck (hexadezimale Darstellung von sha-1) des Zertifikats, das wir für die Verifizierung der Geräteidentität aktivieren.

    • Bei „"cisco-action":"deactivate" ist der Verschlüsseltext der Fingerabdruck (hexadezimale Darstellung von sha-1) des Zertifikats, das wir für die Verifizierung der Geräteidentität deaktivieren.

  • JWE-Authentifizierung-Tag: Dieses Feld enthält das Authentifizierungs-Tag, um die Integrität des gesamten kompakt serialisierten JWE-Blobs zu ermitteln

Wie wir den Verschlüsselungsschlüssel aus dem ClientSecret

Nach der ersten Population des Geheimnisses akzeptieren oder geben wir das Geheimnis nicht als Klartext aus. Dies dient dazu, potenzielle Wörterbuchangriffe durch jemanden zu verhindern, der auf das Gerät zugreifen könnte.

Die Gerätesoftware verwendet den Client-Geheimschlüssel als Eingabe in eine Schlüsselableitungsfunktion (kdf) und verwendet dann den abgeleiteten Schlüssel zur Entschlüsselung/Verschlüsselung des Inhalts auf dem Gerät.

Das bedeutet für Sie, dass Ihr Tool zur Erzeugung von JWE-Blobs die gleiche Prozedur befolgen muss, um den gleichen Verschlüsselungs-/Entschlüsselungsschlüssel aus dem Client-Geheimschlüssel abzurufen.

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

  • CostFactor (N) ist 32768

  • Blockgrößenfaktor (r) beträgt 8

  • Parallelisierungsfaktor (p) beträgt 1

  • Salt ist eine zufällige Abfolge von mindestens 4 Byte; Sie müssen das gleiche angeben, salt wenn Sie den Parameter cisco-kdf angeben.

  • Die Schlüssellänge beträgt entweder 16 Byte (wenn Sie den AES-GCM 128-Algorithmus auswählen) oder 32 Byte (wenn Sie den AES-GCM 256-Algorithmus auswählen).

  • Die maximale Speicherkapazität beträgt 64 MB

Dieser Parametersatz ist die einzige Konfiguration von scrypt , die mit der Funktion zur Schlüsselableitung auf den Geräten kompatibel ist. Dieses KDF auf den Geräten heißt "version":"1" und ist die einzige Version, die derzeit vom Parameter cisco-kdf verwendet wird.

Bearbeittes Beispiel

Nachfolgend finden Sie ein Beispiel, dem Sie folgen können, um zu überprüfen, ob Ihr JWE-Verschlüsselungsprozess mit dem auf den Geräten erstellten Prozess identisch ist.

Das Beispielszenario ist das Hinzufügen eines PEM-Blob zum Gerät (imitiert das Hinzufügen eines Zertifikats mit einer sehr kurzen Zeichenfolge anstelle eines vollständigen Zertifikats + Schlüssels). Der Client-Geheimschlüssel im Beispiel ist ossifrage.

  1. Wählen Sie eine Verschlüsselungsverschlüsselung aus. In diesem Beispiel wird A128GCM (AES mit 128-Bit-Schlüsseln im Galois-Zählermodus) verwendet. Ihr Tool könnte A256GCM verwenden, wenn Sie möchten.

  2. Wählen Sie ein Salz (muss eine zufällige Sequenz von mindestens 4 Byte sein). In diesem Beispiel werden (Hex-Bytes)E5 E6 53 08 03 F8 33 F6 verwendet. Base64url codiert die Sequenz, um 5eZTCAP4M_Y zu erhalten (Entfernen Sie die base64-Füllung).

  3. Hier ist ein Beispiel scrypt für den Aufruf zum Erstellen des Content-Encryption-Codes (cek):

    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 (Hex) umfassen:95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac welche Basis64url kodiert zu lZ66bdEiAQV4_mqdInj_rA.

  4. Wählen Sie eine zufällige Folge von 12 Byte aus, die als Initialisierungsvektor verwendet werden soll. In diesem Beispiel wird (Hex) verwendet, 34 b3 5d dd 5f 53 7b af 2d 92 95 83 welche Basis64url für NLNd3V9Te68tkpWD codiert.

  5. Erstellen Sie den JOSE-Header mit kompakter Serialisierung (folgen Sie der gleichen Reihenfolge der Parameter, die wir hier verwenden) und codieren Sie ihn dann mit base64url:

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

    Der für die Basis64url kodierte JOSE-Header ist eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

    Dies wird das erste Element des JWE-Blobs sein.

  6. Das zweite Element des JWE-Blob ist leer, da wir keinen JWE-Chiffrierschlüssel bereitstellen.

  7. Das dritte Element des JWE Blob ist der Initialisierungsvektor NLNd3V9Te68tkpWD.

  8. Verwenden Sie Ihr JWE-Verschlüsselungstool, um eine verschlüsselte Nutzlast und ein verschlüsseltes Tag zu erzeugen. In diesem Beispiel wird die unverschlüsselte Nutzlast der falsche PEM-Blob sein this is a PEM file

    Folgende Verschlüsselungsparameter sollten Sie verwenden:

    • Nutzlast beträgt this is a PEM file

    • Verschlüsselungsschlüssel ist AES 128 GCM

    • Der Basis64url kodierte JOSE-Header als zusätzliche authentifizierte Daten (AAD)

    Basis64url codiert die verschlüsselte Nutzlast, was dazu führen sollte, dass f5lLVuWNfKfmzYCo1YJfODhQ

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

  9. Base64url codiert das Tag, das Sie in Schritt 8 erstellt haben. Dies sollte dazu führen, dass 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, sind Sie bereit, diese zu verwenden, um die E2E-Verschlüsselung und die verifizierte Identität Ihrer Geräte zu sichern.

  12. Dieses Beispiel funktioniert nicht, aber im Prinzip ist der nächste Schritt, den oben erstellten JWE-Blob als Eingabe zum 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 sind für alle Meeting-Sites ohne zusätzliche Kosten verfügbar. Einer dieser Sitzungstypen heißt 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 Abschnitt Referenz dieses Artikels.

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

Neuen Sitzungstyp überprüfen
1

Melden Sie sich bei Control Hub an und gehen Sie zu Dienste > Meeting.

2

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

3

Wählen Sie unter Allgemeine Einstellungen die Option Sitzungstypen.

Sie sollten einen oder mehrere Sitzungstypen mit End-to-End-Verschlüsselung sehen. Weitere Informationen finden Sie in der Liste der Sitzungstyp-IDs im Abschnitt Referenz dieses Artikels. Beispielsweise wird Ihnen möglicherweise Pro-End to End Encryption_VOIPonly angezeigt.

Es gibt einen älteren Sitzungstyp mit einem sehr ähnlichen Namen: Pro-End to End-Verschlüsselung. Dieser Sitzungstyp umfasst nicht verschlüsselten PSTN-Zugriff auf Meetings. Stellen Sie sicher, dass Sie über die _VOIPonly -Version verfügen, um eine durchgängige Verschlüsselung sicherzustellen. Sie können dies überprüfen, indem Sie den Mauszeiger über den Link PRO in der Spalte „Sitzungscode“ bewegen. In diesem Beispiel sollte das Ziel des Links javascript:ShowFeature(652) sein.

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

4

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

Nächste Schritte

Aktivieren Sie diesen Sitzungstyp/Meeting-Privileg für einige oder alle Ihre Benutzer.

E2EE-Meetings für einzelne Benutzer aktivieren
1

Melden Sie sich bei Control Hub an und gehen Sie zu Verwaltung > Benutzer.

2

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

3

Wählen Sie in der Dropdown-Liste Einstellungen anwenden auf die zu aktualisierende Meeting-Site aus.

4

Aktivieren Sie das Kontrollkästchen neben Pro-End to End Encryption_VOIPonly.

5

Schließen Sie den Bereich „Benutzerkonfiguration“.

6

Bei Bedarf für andere Benutzer wiederholen.

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

E2EE-Meetings für mehrere Benutzer aktivieren
1

Melden Sie sich bei Control Hub an und gehen Sie zu Dienste > Meeting.

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 Abschnitt Lizenzen und Benutzer auf Massenverwaltung.

4

Klicken Sie auf Bericht generieren und warten Sie, bis die Datei vorbereitet wird.

5

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

6

Öffnen Sie die heruntergeladene CSV-Datei zur Bearbeitung.

Es gibt eine Zeile für jeden Benutzer, und die Spalte MeetingPrivilege enthält die IDs des Sitzungstyps als durch Komma getrennte Liste.

7

Fügen Sie für jeden Benutzer, den Sie den neuen Sitzungstyp erteilen möchten, 1561 als neuen Wert in die durch Kommas getrennte Liste in der MeetingPrivilege Zelle hinzu.

Die Referenz zum Webex-CSV-Dateiformat enthält Details zum Zweck und zum Inhalt der CSV-Datei.

8

Öffnen Sie den Konfigurationsbereich für die Meeting-Site in Control Hub.

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

9

Klicken Sie im Abschnitt Lizenzen und Benutzer auf Massenverwaltung.

10

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

11

Nach Abschluss des Imports können Sie auf Importresultate 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 er über den neuen Sitzungstyp verfügt.

Audio-Wasserzeichen für Sicherheit hinzufügen

Sie können mit dem Sitzungstyp Webex Meetings Pro-End to End Encryption_VOIPonly ein Wasserzeichen zu Meeting-Aufzeichnungen hinzufügen, 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 Gerät. Sie können Audioaufzeichnungen in Control Hub hochladen, der die Aufzeichnung analysiert und die eindeutigen Kennungen sucht. Sie können sich die Ergebnisse ansehen, um zu sehen, welcher Quell-Client oder welches Gerät das Meeting aufgezeichnet hat.

  • Um analysiert zu werden, muss die Aufzeichnung eine AAC-, MP3-, M4A-, WAV-, MP4-, AVI- oder MOV-Datei sein, die nicht größer als 500 MB ist.
  • Die Aufzeichnung muss länger als 100 Sekunden dauern.
  • Sie können nur Aufzeichnungen für Meetings analysieren, die von Personen in Ihrer Organisation abgehalten werden.
  • Wasserzeicheninformationen werden für die gleiche Dauer gespeichert wie die Meeting-Informationen der Organisation.

Audio-Wasserzeichen zu E2EE-Meetings hinzufügen

  1. Melden Sie sich bei Control Hub an und wählen Sie dann unter Verwaltung die Option Organisationseinstellungen aus.
  2. Aktivieren Sie im Abschnitt Meeting-Wasserzeichen die Option Audio-Wasserzeichen hinzufügen.

    Einige Zeit nach der Aktivierung wird Benutzern, die Meetings mit dem Webex Meetings Pro-End to End Encryption_VOIPonly Sitzungstyp ansetzen, die Option Digitale Wasserzeichen im Abschnitt „Sicherheit“ angezeigt.

Hochladen und Analysieren eines mit Wasserzeichen versehenen Meetings

  1. Wählen Sie in Control Hub unter Überwachung die Option Fehlerbehebung aus.
  2. Klicken Sie auf Wasserzeichen-Analyse.
  3. Suchen Sie in der Liste nach dem Meeting oder wählen Sie es aus, und klicken Sie auf Analysieren.
  4. Geben Sie im Fenster 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 zu der Audiodatei zu navigieren.
  7. Klicken Sie auf Schließen.

    Nach Abschluss der Analyse wird sie in der Ergebnisliste auf der Seite Wasserzeichen analysieren angezeigt.

  8. Wählen Sie das Meeting in der Liste aus, um die Ergebnisse der Analyse anzuzeigen. Klicken Sie auf Schaltfläche „Herunterladen“ , um die Ergebnisse herunterzuladen.

Funktionen und Einschränkungen

Zu den Faktoren, die bei der erfolgreichen Entschlüsselung eines aufgezeichneten Wasserzeichens beteiligt sind, gehören der Abstand zwischen dem Aufzeichnungsgerät und dem Sprecher, der das Audio ausgibt, die Lautstärke dieses Audios, Umgebungsgeräusche usw. Unsere Wasserzeichen-Technologie bietet eine zusätzliche Widerstandsfähigkeit, um mehrfach codiert zu werden, wie dies beim Teilen von Medien der Fall sein kann.

Diese Funktion wurde entwickelt, um eine erfolgreiche Entschlüsselung des Wasserzeichen-Identifikators unter einer breiten, aber vernünftigen Anzahl von Umständen zu ermöglichen. Unser Ziel ist es, dass ein Aufzeichnungsgerät wie ein Mobiltelefon, das auf einem Schreibtisch in der Nähe eines persönlichen Endpunkts liegt, oder ein Laptop-Client immer eine Aufzeichnung erstellt, die zu einer erfolgreichen Analyse führt. Wenn sich das Aufzeichnungsgerät von der Quelle entfernt oder vor dem Hören des vollen Audiospektrums verdeckt wird, sinkt die Wahrscheinlichkeit einer erfolgreichen Analyse.

Für eine erfolgreiche Analyse einer Aufzeichnung ist eine angemessene Erfassung 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.

Geräte integrieren (interne CA)

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

Dieses Verfahren wählt aus, welche Domäne das Gerät verwendet, um sich selbst zu identifizieren. Dies ist nur erforderlich, wenn Sie in Ihrer Control Hub-Organisation über mehrere Domänen verfügen. Wenn Sie über mehr als eine Domäne verfügen, empfehlen wir Ihnen, dies für alle Geräte zu tun, die eine „Cisco-verifizierte“ Identität aufweisen. Wenn Sie Webex nicht mitteilen, welche Domäne das Gerät identifiziert, wird eines automatisch ausgewählt, und andere Meeting-Teilnehmer sehen möglicherweise falsch aus.

Vorbereitungen

Wenn Ihre Geräte noch nicht integriert sind, folgen Sie Gerät über die API oder die lokale Weboberfläche für Cisco Webex registrieren oder Cloud-Onboarding für die Board-, Desk- und Room-Serie. Überprüfen Sie auch die Domäne(n), die Sie zum Identifizieren der Geräte in Domänen verwalten verwenden möchten.

1

Melden Sie sich bei Control Hub an und wählen Sie unter VerwaltungGeräte aus.

2

Wählen Sie ein Gerät aus, um dessen Konfigurationsbereich zu öffnen.

3

Wählen Sie die Domäne aus, die Sie zum Identifizieren dieses Geräts verwenden möchten.

4

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

Integrierte Geräte (externe CA)

Vorbereitungen

  • Rufen Sie ein CA-signiertes Zertifikat und einen privaten Schlüssel im .pem Format für jedes Gerät ab.

  • Lesen Sie auf der Registerkarte Vorbereiten das Thema Verstehen des externen Identitätsprozesses für Geräte,

  • Bereiten Sie ein JWE-Verschlüsselungstool in Bezug auf die dort enthaltenen Informationen vor.

  • Stellen Sie sicher, dass Sie über ein Tool verfügen, um zufällige Byte-Folgen bestimmter Längen zu generieren.

  • Stellen Sie sicher, dass Sie ein Tool haben, um 64 URL-Codierungsbytes oder -Text zu verwenden.

  • Stellen Sie sicher, dass Sie über eine scrypt Implementierung verfügen.

  • Stellen Sie sicher, dass Sie ein geheimes Wort oder einen geheimen Satz für jedes Gerät haben.

1

Füllen Sie das Gerät ClientSecret mit einem reinen Textgeheimnis aus:

Wenn Sie das Secret zum ersten Mal ausfüllen, stellen Sie es im reinen Textformat bereit. Deshalb empfehlen wir, dies über die Konsole des physischen Geräts zu tun.

  1. Basis64URL codiert den geheimen Ausdruck für dieses Gerät.

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

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

    Der obige Beispielbefehl füllt Secret mit dem Ausdruck 0123456789abcdef aus. Wählen Sie Ihre eigene aus.

Das Gerät hat sein ursprüngliches Geheimnis. Vergessen Sie dies 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 mit einem Texteditor, fügen Sie den Schlüssel-BLOB und das Zertifikat-BLOB ein und speichern Sie ihn als neue PEM-Datei.

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

3

Erstellen Sie ein JWE-Blob, das als Eingabe für den Befehl „Zertifikat hinzufügen“ verwendet werden soll:

  1. Erstellen Sie eine zufällige Abfolge von mindestens 4 Byte. Das ist dein Salz.

  2. Leiten Sie mit Ihrem scrypt-Tool einen Content-Chiffrierschlüssel ab.

    Dazu benötigen Sie das Geheimnis, das Salz und eine Schlüssellänge, die Ihrem gewählten Verschlüsselungscode entsprechen. Es gibt noch einige andere feste Werte (N=32768, r=8, p=1). Das Gerät verwendet den gleichen Prozess und die gleichen Werte, um den gleichen Inhaltsverschlüsselungsschlüssel abzuleiten.

  3. Erstellen Sie eine zufällige Abfolge von genau 12 Byte. Dies ist Ihr Initialisierungsvektor.

  4. Erstellen Sie eine JOSE-Kopfzeile, Einstellung alg, enc und cisco-kdf -Tasten, wie unter Verstehen des externen Identitätsprozesses für Geräte beschrieben. Legen Sie die Aktion „Hinzufügen“ mithilfe des Schlüssels:value "cisco-action":"add" in Ihrer JOSE-Kopfzeile fest (weil wir das Zertifikat dem Gerät hinzufügen).

  5. Basis64url codiert die JOSE-Kopfzeile.

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

  7. Basis64url codiert den Initialisierungsvektor, die verschlüsselte PEM-Nutzlast und das Authentifizierungs-Tag.

  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 Befehl hinzufügen (mehrzeilig) 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 xcommand Security Certificates Services Show

Kopieren Sie den Fingerabdruck des neuen Zertifikats.

6

Aktivieren Sie das Zertifikat für den folgenden Zweck WebexIdentity:

  1. Lesen Sie den Fingerabdruck des Zertifikats, 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 Byte und codieren Sie diese Sequenz mit base64url. Das ist dein Salz.

  3. Leiten Sie mit Ihrem scrypt-Tool einen Content-Chiffrierschlüssel ab.

    Dazu benötigen Sie das Geheimnis, das Salz und eine Schlüssellänge, die Ihrem gewählten Verschlüsselungscode entsprechen. Es gibt noch einige andere feste Werte (N=32768, r=8, p=1). Das Gerät verwendet den gleichen Prozess und die gleichen Werte, um den gleichen Inhaltsverschlüsselungsschlüssel abzuleiten.

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

  5. Erstellen Sie eine JOSE-Kopfzeile, Einstellung alg, enc und cisco-kdf -Tasten, wie unter Verstehen des externen Identitätsprozesses für Geräte beschrieben. Legen Sie die Aktion „Aktivieren“ mithilfe des Key:Value "cisco-action":"activate" in Ihrer JOSE-Kopfzeile fest (da wir das Zertifikat auf dem Gerät aktivieren).

  6. Basis64url codiert die JOSE-Kopfzeile.

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

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

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

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

Durchgängige Verschlüsselung mit Identitätsverifizierung testen
1

Setzen Sie ein Meeting des korrekten Typs an (Webex Meetings Pro-End to End Encryption_VOIPonly).

Siehe Webex-Meeting mit End-to-End-Verschlüsselung ansetzen.

2

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

Siehe Einem Webex-Meeting mit End-to-End-Verschlüsselung beitreten.

3

Treten Sie dem Meeting über ein Gerät bei, dessen Identität durch die Webex CA verifiziert wurde.

4

Überprüfen Sie als Gastgeber, ob dieses Gerät mit dem richtigen Identitätssymbol in der Lobby angezeigt wird.

Siehe Einem Webex-Meeting mit End-to-End-Verschlüsselung beitreten.

5

Treten Sie dem Meeting über ein Gerät bei, dessen Identität durch eine externe Zertifizierungsstelle verifiziert wurde.

6

Überprüfen Sie als Gastgeber, ob dieses Gerät mit dem richtigen Identitätssymbol in der Lobby angezeigt wird. Erfahren Sie mehr über Identitätssymbole.

7

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

8

Überprüfen Sie als Gastgeber, ob dieser Teilnehmer mit dem richtigen Identitätssymbol in der Lobby angezeigt wird.

9

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

10

Validieren Sie nach Möglichkeit die Teilnehmer-/Geräteidentitäten, indem Sie die Zertifikate überprüfen.

11

Stellen Sie sicher, dass alle Teilnehmer des Meetings denselben Meeting-Sicherheitscode sehen.

12

Treten Sie dem Meeting mit einem neuen Teilnehmer bei.

13

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

Umfang und Erwartungen festlegen

  • Werden Sie durchgängig verschlüsselte Meetings zur Standard-Meeting-Option machen oder diese nur für einige Benutzer aktivieren oder allen Gastgebern erlauben, darüber zu entscheiden? Wenn Sie sich entschieden haben, wie Sie diese Funktion verwenden möchten, bereiten Sie die Benutzer vor, die sie verwenden werden, insbesondere in Bezug auf die Einschränkungen und was im Meeting zu erwarten ist.

  • Müssen Sie sicherstellen, dass weder Cisco noch jemand anderes Ihre Inhalte entschlüsseln oder sich für Ihre Geräte ausgeben kann? Wenn dies der Fall ist, benötigen Sie Zertifikate von einer öffentlichen Zertifizierungsstelle.

  • Wenn Ihre Identität auf unterschiedlichen Ebenen verifiziert wird, können Benutzer sich gegenseitig mit zertifikatsgestützten Identitäten verifizieren. Auch wenn es Umstände gibt, in denen Teilnehmer als nicht verifiziert erscheinen können und die Teilnehmer wissen sollten, wie sie es überprüfen müssen, sind nicht verifizierte Personen möglicherweise keine Betrüger.

Identitätsmanagement

Wenn Sie eine externe Zertifizierungsstelle zum Ausstellen Ihrer Gerätezertifikate verwenden, müssen Sie die Zertifikate überwachen, aktualisieren und erneut anwenden.

Wenn Sie den ursprünglichen Geheimschlüssel erstellt haben, müssen Sie wissen, dass Ihre Benutzer möglicherweise den Geheimschlüssel ihres Geräts ändern möchten. Möglicherweise müssen Sie eine Schnittstelle erstellen/ein Tool verteilen, damit diese Benutzer dies tun können.

Sitzungstypkennungen
Tabelle 1: Sitzungstyp-IDs für durchgängig verschlüsselte Meetings

Sitzungstyp-ID

Name des öffentlichen Dienstes

638

E2E-Verschlüsselung + nur VoIP

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

Bildungslehrer E2E Encryption_VOIPonly

676

BroadWorks-Standard plus durchgängige Verschlüsselung

677

BroadWorks Premium plus durchgängige Verschlüsselung

681

Schoology Free plus durchgängige Verschlüsselung

Verwandte xAPI-Befehle

In diesen Tabellen werden die API-Befehle für Webex-Geräte beschrieben, die wir für durchgängig verschlüsselte Meetings und die verifizierte Identität hinzugefügt haben. Weitere Informationen zur Verwendung der API finden Sie unter Zugriff auf die API für Webex Room- und Schreibtischgeräte und Webex Boards.

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

  • Bei Webex registriert

  • Lokal registriert und mit Webex Edge für Geräte mit Webex 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 wird vorgenommen, wenn der Administrator die bevorzugte Domäne des Geräts in 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 selbst zu identifizieren.

xStatus Conference EndToEndEncryption Availability

Gibt an, ob das Gerät einem durchgängig verschlüsselten Meeting beitreten kann. Die Cloud-API ruft sie auf, sodass 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 die External Verifizierung verwendet (verfügt über ein extern ausgestelltes Zertifikat).

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 CertificateChain Certificate # specificinfo

Liest bestimmte Informationen aus einem extern ausgestellten Zertifikat.

Ersetzen Sie im angezeigten Befehl # durch die Nummer des Zertifikats. Ersetzen Sie specificinfo durch einen der folgenden Werte:

  • Fingerprint

  • NotAfter Gültigkeitsenddatum

  • NotBefore Startdatum der Gültigkeit

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

  • Subject # Name Eine Liste der Themen 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. valid oder error).

xStatus Conference EndToEndEncryption InternalIdentity Verification

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

xStatus Conference EndToEndEncryption InternalIdentity Identity

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

Enthält einen Domänennamen, 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 von PreferredDomain.

xStatus Conference EndToEndEncryption InternalIdentity CertificateChain Certificate # specificinfo

Liest bestimmte Informationen aus dem von Webex ausgestellten Zertifikat.

Ersetzen Sie im angezeigten Befehl # durch die Nummer des Zertifikats. Ersetzen Sie specificinfo durch einen der folgenden Werte:

  • Fingerprint

  • NotAfter Gültigkeitsenddatum

  • NotBefore Startdatum der Gültigkeit

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

  • Subject # Name Eine Liste der Themen 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-Anruf-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

Zu diesen drei Events gehören jetzt EndToEndEncryptionStatus, EndToEndEncryptionIdentity und EndToEndEncryptionCertInfo für den betroffenen Teilnehmer.

Tabelle 4: Mit ClientSecret verbundene 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 für Basis64url codierten Nur-Text-Wert, um den Client-Geheimschlüssel zum ersten Mal auf dem Gerät auszusäen.

Um das Geheimnis nach diesem ersten Mal zu aktualisieren, müssen Sie einen JWE-Blob mit dem neuen Geheimnis bereitstellen, das durch das alte Geheimnis verschlüsselt wurde.

xCommand Security Certificates Services Add JWEblob

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

Wir haben diesen Befehl erweitert, um ein JWE-Blob mit den verschlüsselten PEM-Daten zu akzeptieren.

xCommand Security Certificates Services Activate Purpose:WebexIdentity FingerPrint: JWEblob

Aktiviert ein bestimmtes Zertifikat für WebexIdentity. Für diesen Purpose muss der Befehl den identifizierenden Fingerabdruck verschlüsselt und in einem JWE-Blob serialisiert werden.

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

Deaktiviert ein bestimmtes Zertifikat für WebexIdentity. Für diesen Purpose muss der Befehl den identifizierenden Fingerabdruck verschlüsselt und in einem JWE-Blob serialisiert werden.