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 Identitätsüberprüfungsstatus jedes Teilnehmers sehen. Es gibt auch einen Meeting-Code, der allen aktuellen Teilnehmern des Meetings gemeinsam ist, mit dem sie überprüfen können, ob ihr Meeting nicht von einem unerwünschten Drittanbieter-Meddler-in-the-Middle-Angriff (MITM) abgefangen wurde.

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

Identität überprüfen

Die durchgängige Verschlüsselung mit Identitätsüberprüfung bietet zusätzliche Sicherheit für ein durchgängig verschlüsseltes Meeting.

Wenn Teilnehmer oder Geräte einer gemeinsam genutzten MLS-Gruppe (Messaging Layer Security) beitreten, präsentieren sie ihre Zertifikate den anderen Gruppenmitgliedern, die die Zertifikate anschließend 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.

Benutzer der Webex-App authentifizieren sich im Webex Identity Store und geben ihnen ein Zugriffstoken aus, wenn die Authentifizierung erfolgreich ist. Wenn sie ein Zertifikat benötigen, um ihre Identität in einem durchgängig verschlüsselten Meeting zu überprüfen, gibt die Webex CA ihnen ein Zertifikat basierend auf ihrem Zugriffstoken aus. Derzeit bieten wir Benutzern von Webex Meetings keine Möglichkeit, ein Zertifikat von einer Drittanbieter-/externen Zertifizierungsstelle zu erhalten.

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

  • Interne CA: Webex gibt ein internes Zertifikat basierend auf dem Zugriffstoken des Gerätemaschinenkontos aus. Das Zertifikat wurde von der Webex-Zertifizierungsstelle signiert. Geräte verfügen nicht über dieselbe Benutzer-ID wie Benutzer. Daher verwendet Webex (eine der) Domänen Ihrer Organisation, wenn Sie die Identität des Gerätezertifikats schreiben (Common Name (CN)).

  • Externe CA: Gerätezertifikate direkt beim ausgewählten Aussteller anfordern und erwerben. Sie müssen die Zertifikate verschlüsseln, direkt hochladen und autorisieren, indem Sie ein geheimes, nur Ihnen bekanntes Zertifikat verwenden.

    Cisco ist nicht involviert, was dies zur Garantie einer echten End-to-End-Verschlüsselung und verifizierten Identität macht und die theoretische Möglichkeit verhindert, dass Cisco Ihr Meeting abhören/Ihre Medien entschlüsseln kann.

Intern ausgestelltes Gerätezertifikat

Webex gibt ein Zertifikat für das Gerät aus, wenn es nach dem Start registriert wird, und erneuert es bei Bedarf. Bei Geräten 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 darüber zu informieren, welche Domäne das Gerät für seine Identität verwenden soll. Sie können auch die API xConfiguration Conference EndToEndEncryption Identity PreferredDomain verwenden: "example.com".

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

Extern ausgestelltes Gerätezertifikat

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

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

Die Werte im Zertifikat liegen in der Diskretion der Organisation. Der allgemeine Name (CN) und der alternative Antragstellername (SAN) werden auf der Benutzeroberfläche des Webex-Meetings angezeigt, wie unter End-to-End-Verschlüsselung mit Identitätsüberprüfung 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 geheime Client-Funktion verwendet, um verschiedene xcommands zu verschlüsseln und zu signieren.

Bei Verwendung des Client-Geheimnisses 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 bietet derzeit API-Befehle für die Verwaltung dieser.

Geräte

Die folgenden Cloud-registrierten Geräte der Webex Room- und 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

  • Wir bieten Ihnen standardmäßig 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 Geheimnisse und Schlüssel kennen/darauf zugreifen. Wenn wir einen Clouddienst 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, um bei der Anforderung oder Verschlüsselung Ihrer Geräte-Identitätszertifikate und ihrer privaten Schlüssel zu unterstützen. Wir möchten keinen tatsächlichen oder tatsächlichen Zugriff auf Ihre Geheimen oder Schlüssel 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 regelmäßigen Meetings:
    • In E2EE-Meetings können Benutzer nicht auf Whiteboards zugreifen, die außerhalb des Meetings erstellt wurden, einschließlich privater Whiteboards, von anderen freigegebener 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 dem Ende des Meetings nicht mehr zugänglich.
    • 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 .

Verwaltungsoberfläche

Wir empfehlen Ihnen dringend, Control Hub zu verwenden, um Ihre Meetings-Site zu verwalten, da Control Hub-Organisationen eine zentrale Identität für die gesamte Organisation haben.

  • Webex Meetings 41.7.

  • Cloud-registrierte Geräte der Webex Room- und Webex Desk-Serie mit 10.6.1-RoomOS _ A ugust_ 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 verwenden, um Gerätezertifikate für die verifizierte Identität auszugeben).

  • Zusammenarbeitsräume müssen aktiviert sein, damit Personen von ihrem Videosystem aus beitreten können. Weitere Informationen finden Sie unter Videosysteme dürfen Meetings und Events auf Ihrer Webex-Site beitreten .

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

Für höchste Sicherheit und 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 anfordern, erwerben und empfangen und die zugehörigen privaten Schlüssel erstellen zu können. Verwenden Sie beim Anfordern des Zertifikats die folgenden Parameter:

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

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

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

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

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

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

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

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

Wenn Sie neue Geräte verwenden, registrieren Sie sie noch nicht bei Webex. Um sicher zu sein, verbinden Sie sie nicht mit dem Netzwerk an diesem Punkt.

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 behalten möchten.

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

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

Nachdem Sie diese Schritte abgeschlossen haben, können Videosysteme Meetings und Events auf Ihrer Webex-Site beitreten.

Um sicherzustellen, dass die Medien Ihres Geräts nur von anderen Personen 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, dürfen wir uns nicht in die Verschlüsselung und das Hochladen des Zertifikats und Des-Schlüssels einladen lassen. 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 initiales Schlüssel für jedes Gerät, um die Verschlüsselungsfunktionen des Geräts zu erstellen.

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

    Der Prozess und die (nicht-geheimen) Parameter, die Sie benötigen, werden unten erklärt, sowie ein Rezept, um in Ihrer Entwicklung Tools der Wahl zu folgen. Außerdem stellen wir ihnen einige Testdaten und die sich daraus ergibten JWE-Tests zur Verfügung, um Ihnen zu helfen, Ihren Prozess zu überprüfen.

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

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

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

Verwendung des JWE-Formats

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

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 Compact Serialization eines JSON-Dokuments, um JWE-Blobs zu erstellen. Die Parameter, die Sie beim Erstellen der JWE-Blobs angeben müssen, sind:

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

    • "alg":"dir"

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

    • "enc":"A GCM" oder "enc":"A GCM"

      Wir unterstützen diese beiden Verschlüsselungsalgorithmen.

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

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

      Wir haben es als cisco-action bezeichnet , um potenzielle Konflikte mit zukünftigen JWE-Erweiterungen zu mildern.

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

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

  • 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-verschlüsselten Initialisierungs vektorisieren, um die Nutzdatendaten zu entschlüsseln. Die IV MUSS ein beliebiger Bytewert von 12 Byte sein (wir verwenden die AES-GCM-Cipher-Familie, die erfordert, dass die IV 12 Byte lang ist).

  • JWE AAD (zusätzliche authentifizierte Daten). Sie müssen dieses Feld auslassen, da es bei 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 beispielsweise das Client-Geheimnis zurückzusetzen, müssen Sie es mit einem leeren Wert überschreiben.

    Es gibt unterschiedliche Arten von Nutzdatendaten, je nachdem, 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 Schlüssel „cisco-action“ wie folgt angeben:

    • Mit "cisco-action":"populate" ist der Ciphertext das neue ClientSecret .

    • Mit ""cisco-action":"add" ist der Verschlüsselungstext ein PEM-Blob, der das Zertifikat und seinen privaten Schlüssel (verkettet) trägt.

    • Mit ""cisco-action":"activate" ist der Verschlüsselungstext der Fingerabdruck (hexadezimale Darstellung von sha-1) des Zertifikats, das wir für die Überprüfung der Geräteidentität aktivieren.

    • Mit ""cisco-action":"deactivate" ist der Chiffriertext der Fingerabdruck (hexadezimale Darstellung von sha-1) des Zertifikats, das wir für die Identitätsüberprüfung des Geräts deaktivieren.

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

So leiten wir den Verschlüsselungsschlüssel aus dem ClientSecret ab

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

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

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

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

  • CostFactor (N) ist 32768

  • BlockSizeFactor (r) ist 8

  • ParallelizationFactor (p) ist 1

  • Salz ist eine zufällige Sequenz von mindestens 4 Bytes; Sie müssen dasselbe salt angeben, wenn Sie den Parameter cisco-kdf angeben.

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

  • Maximale Speicher cap ist 64 MB

Diese Reihe von Parametern ist die einzige Konfiguration von Scrypt, die mit der Schlüsselfunktion auf den Geräten kompatibel ist. Diese kdf auf den Geräten heißt "version":"1", das ist die einzige Version, die derzeit vom cisco-kdf -Parameter genommen wird.

Bearbeitetes Beispiel

Hier ein Beispiel, wie Sie nachfolgend sehen können, um zu überprüfen, ob Ihr JWE-Verschlüsselungsverfahren genauso funktioniert wie das verfahren, das wir auf den Geräten erstellt haben.

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

  1. Wählen Sie eine Verschlüsselungsverschlüsselung aus. Dieses Beispiel verwendet A GCM (AES mit 128-Bit-Tasten im Galois Counter Mode). Ihr Tool könnte A GCM verwenden, wenn Sie möchten.

  2. Wählen Sie eine beliebige Folge (muss eine zufällige Sequenz von mindestens 4 Byte sein). Dieses Beispiel verwendet (Hex-Bytes) E5 E6 53 08 03 F8 33 F6 . Base64url codieren die Sequenz um 5eZTCAP4M _ Y zu erhalten (entfernen Sie das base64 Polster).

  3. Hier ist ein Beispielanruf scrypt zum Erstellen des Verschlüsselungsschlüssels für Inhalte (cek):

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

    Der abgeleitete Schlüssel sollte wie folgt 16 Bytes (Hex) sein: 95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac welche base64url kodiert nach lZ66bdEiAQV4 _mqd I nj_r A .

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

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

    {"alg":"dir","cisco-action":"add","cisco-kdf":{"salt":"5eZTCAP4M _ Y","version":"1"},"enc":"A GCM"}

    Die Base64url-codierte JOSE-Kopfzeile ist eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

    Dies ist das erste Element der JWE-Komponente.

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

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

  8. Verwenden Sie Ihr JWE-Verschlüsselungstool, um verschlüsselte Nutzdatendaten und Tags zu erzeugen. In diesem Beispiel wird die unverschlüsselte Nutzlast der gefälschte PEM-Blob sein dies ist eine PEM-Datei

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

    • Nutzlast ist dies ist eine PEM-Datei

    • Verschlüsselungsverschlüsselung ist AES 128 GCM

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

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

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

  9. Base64url codieren Sie den Tag, den Sie in Schritt 8 produziert haben, was zu PE-wDFWGXFFBeo928cfZ1Q führen sollte

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

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

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

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

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

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

Sitzungstypen für Zero-Trust-Meetings stehen allen Meeting-Sites ohne zusätzliche Kosten zur Verfügung. Einer dieser Sitzungstypen heißt Pro-End to End E ncryption_ 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 Referenzabschnitt 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 als Massenvorgang 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

Wählen Sie unter Allgemeine Einstellungensitzungstypen aus.

4
Sie sollten einen oder mehrere Sitzungstypen mit durchgängiger Verschlüsselung sehen. Siehe Liste der Sitzungstyp-IDs im Referenzabschnitt dieses Artikels. EVOIPonly kann beispielsweise als Pro-End-to-End-EVOIPonlyncryption_(Pro-End-zu-Ende) zu sehensein.

Es gibt eine ältere Sitzungstyp mit einem sehr ähnlichen Namen: Pro-End-to-End-Verschlüsselung . Diese Sitzungstyp umfasst einen nicht verschlüsselten PSTN Zugang zu Meetings. Stellen Sie sicher, dass Sie die _ Version VOIPonly haben, um eine durchgängige Verschlüsselung sicherzustellen. Sie können ü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.

5

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

Nächste Schritte

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

1

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

2

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

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 Pro-End to End E ncryption_ VOIPonly .

5

Schließen Sie den Bereich 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 auf Herunterladen. (Sie müssen dieses Popup-Fenster manuell schließen, nachdem Sie auf „Herunterladen“ geklickt haben.)

6

Öffnen Sie die heruntergeladene CSV-Datei zum Bearbeiten.

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

7

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

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

8

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

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

9

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

10

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

11

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

12

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

Sie können Meeting-Aufzeichnungen mit dem folgenden Wasserzeichen versehen: Webex Meetings Pro-End-to-End Encryption_Nur 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.

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

Audio-Wasserzeichen zu E2EE-Meetings hinzufügen

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

    Einige Zeit nach der Aktivierung dieser Option wird Benutzern, die Meetings mit dem Sitzungstyp Webex Meetings Pro-End to End E VOIPonly ncryption_ ansetzen, im Abschnitt „Sicherheit“ die Option Digital Watermarking angezeigt.

Hochladen und Analysieren eines Meetings mit Wasserzeichen

  1. Wählen Sie in Control Hub unter Überwachung die Option 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. 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 zur Audiodatei zu navigieren.
  7. Klicken Sie auf Schließen.

    Wenn die Analyse abgeschlossen ist, wird sie in der Liste der Ergebnisse 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 an der erfolgreichen Entschlüsselung eines aufgezeichneten Wasserzeichens beteiligt sind, gehören der Abstand zwischen dem Aufzeichnungsgerät und dem Lautsprecher, der das Audio ausgibt, die Lautstärke dieses Audios, Umgebungsgeräusche usw. Unsere Wasserzeichen-Technologie hat eine zusätzliche Resilienz, um mehrfach verschlüsselt zu werden, wie dies bei der Freigabe von Medien der Fall sein könnte.

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 Ihre Control Hub-Organisation integriert sind und Sie die Webex CA verwenden möchten, um ihre Identifizierungszertifikate automatisch zu generieren, müssen Sie die Geräte nicht auf die Werkseinstellungen zurücksetzen.

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

Vorbereitungen

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

1

Melden Sie sich bei Control Hub an und wählen Sie unter Management die Option Devices .

2

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

3

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

4

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

Vorbereitungen

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

  • Lesen Sie unter der Registerkarte Vorbereitung das Thema Externe Identitätsprozess für Geräte verstehen ,

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

  • Stellen Sie sicher, dass Sie ein Werkzeug haben, um zufällige Byte-Sequenzen mit bestimmten Längen zu erzeugen.

  • Stellen Sie sicher, dass Sie ein Werkzeug haben, um64url Bytes oder Text zu codieren.

  • Stellen Sie sicher, dass Sie eine scrypt -Implementierung haben.

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

1

Füllen Sie das ClientSecret des Geräts mit einem Nur-Text-Geheimnis aus:

Wenn Sie das Secret zum ersten Mal ausfüllen, geben Sie es in Klartext ein. Deshalb empfehlen wir, dies auf der physischen Gerätekonsole zu tun.

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

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

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

    Der obige Beispielbefehl füllt das Secret mit der Phrase 0123456 789abcdef . Sie müssen ihre eigenen auswählen.

Das Gerät hat seinen anfänglichen Schlüssel. 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

Ihr Zertifikat und Ihren privaten Schlüssel verfeinern:

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

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

3

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

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

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

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

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

  4. Erstellen Sie einen JOSE-Header und legen Sie die Tasten alg , enc und cisco-kdf wie unter Externe Identitätsprozesse für Geräte verstehen beschrieben fest. Legen Sie die Aktion "Hinzufügen" mit dem Schlüssel:value "cisco-action" fest:"add" im JOSE-Header (da wir das Zertifikat zum Gerät hinzufügen).

  5. Base64url kodieren den JOSE-Header.

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

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

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

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4

Öffnen Sie die Shell auf dem Gerät und führen Sie den (mehrstufigen) Add-Befehl aus:

xcommand Security Certificates Services Hinzufügen von IsEncrypted: True your..JWE.str.ing\n .\n
5

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

Kopieren Sie den Fingerabdruck des neuen Zertifikats.

6

Zertifikat für den Zweck aktivieren WebexIdentity :

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

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

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

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

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

  5. Erstellen Sie einen JOSE-Header und legen Sie die Tasten alg , enc und cisco-kdf wie unter Externe Identitätsprozesse für Geräte verstehen beschrieben fest. Legen Sie die Aktion "aktivieren" unter Verwendung des Schlüssels:value"cisco-action" fest:"activate" im JOSE-Header (da wir das Zertifikat auf dem Gerät aktivieren).

  6. Base64url kodieren den JOSE-Header.

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

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

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

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

    JOSEHeader..InitVector.EncryptedFingerprint.AuthTag

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

     xcommand Sicherheitszertifikate Services Aktivieren Zweck: WebexIdentity-Fingerabdruck: „Ihr..JWE.encrypted.Fingerabdruck“ 

Das Gerät verfügt über ein verschlüsseltes, aktives CA-ausgegebenes Zertifikat, das zur Identifizierung in end-to-End-verschlüsselten Webex-Meetings verwendet werden kann.
7

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

1

Hier können Sie ein Meeting vom Typ"Pro-Webex Meetings End to Endncryption_EVOIPonly"anplanen.

2

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

3

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

4

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

5

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

6

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

7

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

8

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

9

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

10

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

11

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

12

Treten Sie dem Meeting mit einem neuen Teilnehmer bei.

13

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

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

  • Müssen Sie sicherstellen, dass weder Cisco noch jemand anderes Ihre Inhalte entschlüsseln oder ihre Geräte nachahmen kann? Wenn ja, benötigen Sie Zertifikate einer öffentlichen Zertifizierungsstelle.

  • Wenn Sie unterschiedliche Identitätsüberprüfungsebenen haben, ermächtigen Sie die Benutzer, sich gegenseitig mit zertifikatgestützter Identität zu verifizieren. Obwohl es Umstände gibt, unter denen Teilnehmer als nicht bestätigt angezeigt werden können und die Teilnehmer wissen sollten, wie sie es überprüfen sollten, sind nicht verifizierte Personen möglicherweise keine Versposer.

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

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

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

Sitzungstyp-ID

Name des öffentlichen Dienstes

638

E2E-Verschlüsselung+ VoIP nur

652

Pro-End-to-End EVOIPonlyncryption_

660

Pro 3 Free-End to End EVOIPonlyncryption_

E2E-Verschlüsselung + Identität

672

Pro 3 Free50-End to End EVOIPonlyncryption_

673

Schulungsleiter E2E EVOIPonlyncryption_

676

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

677

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

681

Kostenlos plus End-to-End-Verschlüsselung

Diese Tabellen enthalten Informationen zu API-Befehlen für Webex-Geräte, die wir für End-to-End-verschlüsselte Meetings und verifizierte Identität hinzugefügt haben. Weitere Informationen zur Verwendung der API finden Sie unter Zugriff auf die API für Webex Room- und Tischgeräte undWebex Boards.

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

  • Bei Webex registriert

  • Vor Ort registriert und mit Webex verknüpft mit Webex Edge für Geräte

Tabelle 2: Systemebene-APIs für End-to-End-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 aus Control Hub vor legt. Nur erforderlich, wenn die Organisation über mehr als eine Domäne verfügt.

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

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

xStatus Conference EndToEndEncryption Verfügbarkeit

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

xStatus Conference EndToEndEncryption ExternalIdentity Verification

Gibt an, ob das Gerät die Überprüfung „Extern“ verwendet (ein extern ausgestelltes Zertifikat hat).

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 spezifische Informationen aus einem extern ausgestellten Zertifikat.

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

  • Fingerabdruck

  • NotAfter Enddatum der Gültigkeit

  • NotBefore Startdatum der Gültigkeit

  • Primarname

  • PublicKeyAlgorithm

  • Seriennummer

  • SignatureAlgorithm

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

  • Gültigkeit Gibt den Gültigkeitsstatus dieses Zertifikats an (z. gültig oder abgelaufen )

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 verfügt, das von der Webex-Zertifizierungsstelle ausgestellt wurde.

xStatus Konferenz EndToEndEncryption InternalIdentity Identity

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

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

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

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

xStatus Conference EndToEndEncryption InternalIdentity CertificateChain Certificate # specificinfo

Liest spezifische Informationen aus dem von Webex ausgestellten Zertifikat.

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

  • Fingerabdruck

  • NotAfter Enddatum der Gültigkeit

  • NotBefore Startdatum der Gültigkeit

  • Primarname

  • PublicKeyAlgorithm

  • Seriennummer

  • SignatureAlgorithm

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

  • Gültigkeit Gibt den Gültigkeitsstatus dieses Zertifikats an (z. gültig oder abgelaufen )

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

API-Aufruf

Beschreibung

xEvent-Konferenzteilnehmerliste Teilnehmer hinzugefügt

xEvent-Konferenzteilnehmerliste Teilnehmer aktualisiert

xEvent-Konferenzteilnehmerliste Teilnehmer gelöscht

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

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

API-Aufruf

Beschreibung

xCommand Security ClientSecret Populate Secret: "base64url-codiert"

oder

xCommand Security ClientSecret Populate Secret: JWEblob

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

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

xCommand Security Certificates Services Hinzufügen JWEblob

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

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

xCommand Security Certificates Services Aktivieren Zweck:WebexIdentity FingerPrint: JWEblob

Aktiviert ein bestimmtes Zertifikat für WebexIdentity. Für diesen Zweck erfordert der Befehl, dass der identifizierende Fingerabdruck in einem JWE-Blob verschlüsselt und serialisiert wird.

xCommand Security Certificates Services Deaktivieren Zweck:WebexIdentity FingerPrint: JWEblob

Deaktiviert ein bestimmtes Zertifikat für WebexIdentity. Für diesen Zweck erfordert der Befehl, dass der identifizierende Fingerabdruck in einem JWE-Blob verschlüsselt und serialisiert wird.