ユーザーはミーティングをスケジュールするときに、新しいミーティング タイプを選択します。 ロビーから、およびミーティング中に参加者を受け入れた場合、主催者は各参加者の身元確認ステータスを確認できます。 ミーティングの現在のすべての参加者に共通するミーティング コードも示され、お互いを検証するために使用できます。

ミーティング主催者と次の情報を共有します。

ID を確認しています

エンドツーエンドを確認すると、エンドツーエンド暗号化ミーティングに追加のセキュリティが提供されます。

参加者またはデバイスが共有済み MLS (Messaging Layer Security) グループに参加すると、その証明書を他のグループメンバーに提示し、発行された認証局/ies (CA) に対して証明書を検証します。 証明書が有効な場合、CA は参加者の ID を確認し、ミーティングでは参加者/デバイスが確認済みとして表示されます。

Webex Meetings アプリ のユーザーが成功時にアクセス トークンを発行する Webex アイデンティティ ストアに対して自分自身を認証します。 エンドツーエンド暗号化ミーティングで ID を確認するために証明書が必要な場合、Webex CA はアクセス トークンに基づいて証明書を発行します。 Webex Meetings ユーザーがサード パーティ /外部 CA によって発行された証明書を取得する方法をまだ提供していません。

デバイスは、内部 (Webex) CA が発行する証明書または外部 CA が発行した証明書を使用して、自分自身を認証できます。

  • 内部 CA の場合、Webex はデバイスのマシン アカウントのアクセス トークンに基づいて内部証明書を発行します。 証明書は Webex CA によって署名されています。 デバイスはユーザーと同じ方法でユーザー ID を持たないので、Webex はデバイス証明書の ID (Common Name (CN) を書く時に組織のドメインの (1 つ) を使用します。

  • 外部 CA ケースについては、選択した発行者から直接デバイス証明書をリクエストし、購入します。 あなただけに知られている秘密を使用して証明書を暗号化し、直接アップロードし、承認する必要があります。

    Cisco は関与していないので、これはエンドツーエンドの暗号化と検証された ID を保証する方法であり、Cisco がミーティングを盗聴する可能性やメディアを暗号解読する可能性を防ぐ上で必要があります。

内部で発行されたデバイス証明書

デバイスが起動時に登録すると Webex はデバイスに証明書を発行し、必要に応じて更新します。 デバイスの場合、証明書にはアカウント ID とドメインが含まれます。

組織にドメインがない場合、Webex CA はドメインなしの証明書を発行します。

組織に複数のドメインがある場合は、Control Hub を使用して、デバイスが ID に使用するドメインを Webex に伝えられます。 API を使用することもできます xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

複数のドメインを持ち、デバイスの優先ドメインを設定していない場合、Webex がユーザーに選択します。

外部で発行されたデバイス証明書

管理者は、パブリック CA の 1 つで署名された、独自の証明書を使用してデバイスをプロビジョニングできます。

RSA キーによる署名は可能ですが、証明書は ECDSA P-256 キーペアに基づく必要があります。

証明書の値は組織の裁量で使用できます。 共通名 (CN) および サブジェクト代替名 (SAN) は、Webex ミーティング ユーザー インターフェイスに表示されます。詳細は、「Webex Meetings の ID 検証付きエンドツーエンド暗号化」で説明されています。

デバイスごとに別の証明書を使用し、デバイスごとに固有の CN を持つことを推奨します。 これは、例えば、「meeting-room-1.example.com」ドメインを所有する組織に対して、「example.com」である場合などです。

外部証明書を改めから完全に保護するために、クライアントシークレット機能を暗号化し、さまざまな xcommands に署名するために使用されます。

クライアント シークレットを使用する場合、xAPI 経由で外部 Webex ID 証明書を安全に管理することができます。 これは現在、オンライン デバイスに限定されています。

現在 Webex は、この管理のための API コマンドを提供しています。

デバイス

クラウド登録済みの Webex Room Webex Desk シリーズのデバイスは、以下を含むエンドツーエンド暗号化ミーティングに参加できます。

  • Webex Board

  • Webex Desk Pro

  • Webex Desk

  • Webex Room Kit

  • Webex Room Kit Mini

次のデバイスは、エンド 暗号化されたミーティングを結合して終了することはできません。

  • Webex C シリーズ

  • Webex DX シリーズ

  • Webex EX シリーズ

  • Webex MX シリーズ

  • サードパーティ SIP デバイス

ソフトウェア クライアント

  • 41.7 から、Webex Meetings デスクトップ クライアントはエンドツーエンド暗号化ミーティングに参加できます。

  • Webex アプリは、エンドツーエンドの暗号化されたミーティング に参加することはできません。

    組織で Webex アプリが Meetings デスクトップ アプリケーションを起動してミーティングに参加できる場合、このオプションを使用してエンドツーエンドの暗号化されたミーティングに参加できます。

  • Webex Web クライアントは、エンドツーエンドの暗号化されたミーティング に参加することはできません。

  • サードパーティ SIP クライアントは、エンドツーエンドの暗号化されたミーティングに参加することはできません。

識別

  • 外部検証されたデバイスの ID を管理するための Control Hub オプションは提供されません。 この決定は、設計によるもので、真のエンドツーエンド暗号化のため、あなたのみがシークレットとキーを知る/アクセスする必要があります。 これらのキーを管理するためにクラウド サービスを導入した場合、インターセプトされる可能性があります。

  • 現在、デバイス ID 証明書とそのキーの暗号化のリクエストまたは暗号化を支援するツールは提供していません。 現在当社では、これらのプロセスを支援する、業界標準の暗号化技術に基づいて独自のツールを設計するための「取り組み」を提供しています。 シークレットまたはキーへの実際または認識さるアクセスは持ちたくはないと思います。

Meetings

  • エンドツーエンドミーティングは現在最大 200 人の参加者をサポートしています。

  • これらの 200 人の参加者では、最大 25 台の外部検証済みのデバイスが参加できます。また、ミーティングに最初に参加する参加者である必要があります

    より多くのデバイスがミーティングに参加すると、バックエンド メディア サービスはメディア ストリームをトランスコードしようと試みます。 メディアを解読、トランスコード、再暗号化できない場合 (デバイスの暗号化キーが必要ではないので)、トランスコードは失敗します。

    この制限を緩和するには、デバイスのミーティングを小さくするか、デバイスと Meetings クライアント間の招待を段階的にずらしてください。

管理インターフェース

ミーティング サイトを管理するために、Control Hub を使用することを強くお勧めします。

この主な理由は、Control Hub とアイデンティティを管理する方法サイト管理です。 Control Hub 組織は組織全体のアイデンティティを集中化し、そのサイト管理アイデンティティはサイト別に管理されます。

これは、サイト管理から管理されているユーザーに対して、Cisco が検証したアイデンティティ オプションを持サイト管理。 これらのユーザーは、エンドツーエンド暗号化ミーティングに参加するために匿名の証明書が発行され、ホストがアイデンティティを保証するミーティングから除外される場合があります。

関連情報

サンプル JWE ブロブの導出

指定されたパラメータ (付録) に基づいて、正確に暗号化された JWE のサンプル

  • Webex Meetings 41.7

  • クラウド登録済み Webex Room と Webex Desk シリーズ デバイス、 10.6.1-RoomOS_August_2021 を実行中。

  • Control Hub のミーティング サイトへの管理アクセス、ユーザーに対して新しいセッション タイプ有効にします。

  • Control Hub 組織の 1 つ以上の検証済みドメイン (検証された ID のためにデバイス証明書を発行するために Webex CA を使用している場合)。

外部検証済みの ID が必要ない場合、この手順をスキップできます。

最も高いレベルのセキュリティとアイデンティティ確認のため、各デバイスは信頼されたパブリック証明機関から発行された固有の証明書を持つ必要があります。

デジタル証明書をリクエスト、購入、受信し、関連するプライベート キーを作成するには、CA と対話する必要があります。 証明書を要求する場合、以下が使用するパラメータです。

  • 証明書は、既知のパブリック CA によって発行および署名されている必要があります。

  • 一意: 各デバイスには一意の証明書を使用することを強く推奨します。 すべてのデバイスに対して 1 つの証明書を使用する場合、セキュリティを損なっています。

  • 共通名 (CN) およびサブジェクト代替名/s (SAN/s): これらは Webex にとって重要ではないが、人間がデバイスを読み取り、関連付けできる価値である必要があります。 CN はデバイスのプライマリ検証済み ID として他のミーティング参加者に表示され、ユーザーがミーティング UI を通して証明書を検査する場合、SAN/s が表示されます。 名前は name.model@example.com などを使用する場合がありますが、それは選択できます。

  • ファイル形式: 証明書とキーは .pem 形式 であることが必要です。

  • 目的: 証明書の目的は Webex アイデンティティである必要があります。

  • キーの生成: 証明書は ECDSA P-256 キーペア (P-256 曲線を使用する楕円曲線デジタル署名アルゴリズム) に基づく必要があります。

    この要件は署名キーには拡張されません。 CA は RSA キーを使用して証明書に署名できます。

お使いのデバイスで外部検証済みのアイデンティティを使用しない場合、この手順をスキップできます。

新しいデバイスを使用している場合、Webex にまだ登録しないでください。 ネットワークにさえも接続しないことが最も安全です。

外部検証された ID を使用するためにアップグレードする既存のデバイスがある場合、デバイスを工場出荷時設定にリセットする必要があります。

  • 既存の設定を保存したい場合は保存します。

  • デバイスが使用されていないときにウィンドウをスケジュールするか、段階的に使用します。 ユーザーに期待される変更を通知します。

  • デバイスへの物理的なアクセスを確認します。 ネットワーク上でデバイスにアクセスする必要がある場合、秘密はプレーンテキストで移動し、セキュリティに妥協している点に注意してください。

デバイス以外のユーザーがデバイスのメディアを暗号化できないことを確認するには、デバイスのプライベート キーを暗号化する必要があります。 JSON Web Encryption (JWE) を使用して、暗号化されたキーと証明書の管理を可能にするようにデバイス用に API を設計しました。

クラウドを通じたエンドツーエンドの暗号化を保証するために、証明書と鍵の暗号化とアップロードに関与することはできません。 このレベルのセキュリティが必要な場合は、onus がオンになります。

  • あなたの証明書をリクエストします。

  • あなたの証明書のキー ペアを生成します。

  • 各デバイスの初期シークレットを作成 (および保護) し、デバイスの暗号化機能をシードします。

  • JWE 標準を使用するファイルを暗号化するための独自のツールを開発し、維持します。

    以下に、プロセスとあなたが必要とする(非シークレット)パラメータと、開発ツールの選択に従う指示を示します。 また、当社ではお客様のプロセスの検証に役立て、いくつかのテストデータと結果として得られた JWE を期待通り提供しています。

    Python3 および JWCrypto ライブラリを使用したサポートされていない参照実装はリクエストにより Cisco から利用できます。

  • ツールとデバイスの初期シークレットを使用して、証明書とキーを連結し暗号化します。

  • 結果として生成された JWE ブロブをデバイスにアップロードします。

  • Webex アイデンティティに使用される暗号化された証明書の目的を設定し、証明書をアクティブ化します。

  • (推奨) デバイス ユーザーが初期シークレットを変更 (メディアをあなたから保護する) を可能にするツールにインターフェイスを提供します。

JWE 形式の使用方法

このセクションでは、JWE がデバイスへの入力として作成されると予想される方法について説明します。これにより、証明書とキーからコマンドを作成するための独自のツールを構築できます。

JSON ウェブ暗号化 (JWE)https://datatracker.ietf.org/doc/html/rfc7516 および JSON ウェブ署名 (JWS) https://datatracker.ietf.org/doc/html/rfc7515 を参照する必要があります。

JSON ドキュメントの コンパクトなシリアル化を使用して、JWE ブロブを作成することを選択しました。 JWE ブロブを作成する際に含む必要があるパラメータは、次のとおりです。

  • JOSE ヘッダー (保護されています)。 JSON オブジェクトの署名と暗号化のヘッダーで、次のキー値のペアを含める必要があります。

    • "alg":"dir"

      直接アルゴリズムは、ペイロードの暗号化をサポートしている唯一のものであり、デバイスの最初のクライアント シークレットを使用する必要があります。

    • "enc":"A128GCM" または "enc":"A256GCM"

      これら 2 つの暗号化アルゴリズムをサポートしています。

    • "cisco-action": "add" または "cisco-action": "populate" または "cisco-action": "activate" または "cisco-action": "deactivate"

      これは独自のキーであり、取り込み可能な 4 つの値です。 暗号化されたデータの目的を、ターゲット デバイスに合図するためにこのキーを導入しました。 値は、暗号化されたデータを使用するデバイスで xAPI コマンドにちなんで名前が付けられています。

      名前を cisco-action と付けて、今後の JWE 拡張との重なる可能性のある問題を緩和します。

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

      別の独自のキー。 デバイスでのキーの導出のための入力としてあなたが提供する値を使用します。 この version1(キー導出機能のバージョン)です。 この salt の値は、少なくとも 4 バイトの base64 URL エンコード シーケンスでなければなりません。ランダムに選択する 必要があります

  • JWE 暗号化キー. フィールドが空です。 デバイスは、初期の ClientSecret から導出されます。

  • JWE 初期化ベクトル。 ペイロードを解読するための base64url エンコード初期化ベクトルを提供する必要があります。 IV はランダムな 12 バイト値でなければなりません (当社は AES-GCM 暗号ファミリーを使用しています。IV は 12 バイトの長さでなければなりません )。

  • JWE AAD(追加の認証データ)。 このフィールドは、コンパクトなシリアル化でサポートされていないので、省略する必要があります。

  • JWE Ciphertext: これは、シークレットにしたい暗号化ペイロードです。

    ペイロードが空である場合があります(例えば、クライアント シークレットをリセットするために、空の値で上書きする必要があります)。

    デバイスで行おうとしている内容に応じて、ペイロードには異なるタイプがあります。 xAPI コマンドが異なる場合はペイロードが異なり、次の cisco-action キーで、ペイロードの目的を指定する必要があります。

    • With "cisco-action":"populate" この ciphertext は、新しい ClientSecret

    • With " "cisco-action":"add" この ciphertext は、証明書とそのプライベートキー (連結) を含む PEM ブロブです。

    • With " "cisco-action":"activate" この ciphertext は、デバイスの検証のためにアクティベーションしている証明書の指紋 (sha-1 の 16 進数表示) です

    • With " "cisco-action":"deactivate" この ciphertext は、デバイス ID の検証で無効化している証明書の指紋 (sha-1 の 16 進数表示) です。

  • JWE 認証タグ: このフィールドには、JWE のコンパクトにシリアル化されたブロブ全体の整合性を確認するための認証タグが含まれています

暗号化キーから導出する方法 ClientSecret

シークレットの最初のポピュレーションの後で、プレーン テキストとしてシークレットを受け入れる、または出力しません。 これは、デバイスにアクセスできる誰かによる辞書攻撃を防ぐためです。

デバイス ソフトウェアは、クライアント シークレットをキー導出関数 (kdf) への入力として使用し、デバイスのコンテンツの復号/暗号化のために、取得したキーを使用します。

つまり、JWE ブロブを生成するツールが、同じ手順に従って、クライアント シークレットから同じ暗号化/復号キーを導き出す必要がある、という意味です。

デバイスは、 次のパラメータを使用して、キーの導出に scrypt を使用します (https://en.wikipedia.org/wiki/Scrypt を参照)。

  • CostFactor (N) は 32768 です

  • BlockSizeFactor (r) は 8 です

  • ParallelizationFactor (p) は 1 です

  • これは、少なくとも 4 バイトのランダム シーケンスです。パラメータを指定するときに salt この同じ cisco-kdf を指定する必要があります。

  • キーの長さは、16 バイト (AES-GCM 128 アルゴリズムを選択した場合)、または 32 バイト (AES-GCM 256 アルゴリズムを選択した場合) のいずれかです

  • 最大メモリ上限は 64MB です

このパラメータのセットは、デバイスのキーの導出機能と互換性のある scrypt の唯一の構成です。 デバイス上のこの kdf は、 "version":"1" と呼ばれ、これは、 cisco-kdf パラメータにより現在採用されている唯一のバージョンです。

機能した例

次の例では、JWE 暗号化プロセスがデバイスで作成したプロセスと同じ動作を確認できます。

サンプルのシナリオは、PEM をデバイスに追加しています (完全な cert + キーの代わりに短い文字列で、証明書を追加した例です)。 この例のクライアント シークレットは、 ossifrage です。

  1. 暗号化を選択します。 この例では A128GCM(Galois カウンター モードで 128 ビットキーを持つ AES) を使用します。 ツールは、好みの場合、 A256GCM を使用できます。

  2. Salt を選択します (少なくとも 4 バイトのランダムシーケンスを使用する必要があります)。 この例では (16 進バイト) を使用しています E5 E6 53 08 03 F8 33 F6 。 Base64url シーケンスをエンコードして、 5eZTCAP4M_Y を取得します (ベースの64のパディングを取り除く)。

  3. サンプルは次のとおりです scrypt コールしてコンテンツ暗号化キー (cek) を作成します。

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

    取得されたキーは、次のように 16 バイト (16 進) でなければなりません。 95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac これは lZ66bdEiAQV4_mqdInj_rA に対する base64url エンコードです。

  4. 12 バイトのランダムシーケンスを選択して、初期化ベクトルとして使用します。 この例では (16 進) を使用しています 34 b3 5d dd 5f 53 7b af 2d 92 95 83 これは NLNd3V9Te68tkpWD に対する base64url エンコードです。

  5. コンパクトな一部を持つ JOSE ヘッダーを作成し (ここで使用するパラメータの同じ順番に従います)、base64url エンコードします。

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

    base64url エンコード JOSE ヘッダーは eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

    これは JWE ブロブの最初の要素です。

  6. JWE フィールドの 2 番目の要素は空です。JWE 暗号化キーを指定しないためです。

  7. JWE ブロブの 3 番目の要素は、初期化ベクトルである NLNd3V9Te68tkpWD です。

  8. JWE 暗号化ツールを使用して、暗号化ペイロードとタグを作成します。 この例では、暗号化されていないペイロードは偽の PEM ブロブになります this is a PEM file

    使用すべき暗号化パラメータ:

    • ペイロードは this is a PEM file

    • 暗号化は AES 128 GCM です

    • base64url は、追加認証データ(AAD)として、JOSE ヘッダーをエンコードします。

    Base64url エンコードされたペイロードがエンコードされ、結果として f5lLVuWNfKfmzYCo1YJfODhQ

    これは JWE フィールドの 4 番目の要素 (JWE Ciphertext) です。

  9. ステップ 8 で生成したタグを Base64url エンコードします。結果として PE-wDFWGXFFBeo928cfZ1Q

    これは JWE ブロブの 5 番目の要素です。

  10. JWE ブロブの 5 要素をドットで連結して (JOSEheader..IV.Ciphertext.Tag) 次を取得します。

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

  11. ここに表示されるのと同じ base64url エンコード値を取得した場合は、それらを使用してデバイスの E2E 暗号化と検証済み ID のセキュリティを確保する準備ができています。

  12. この例は実際には機能しませんが、次のステップは、上で作成した JWE グループを、証明書を追加するデバイスの xcommand への入力として使用する方法です。

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

ゼロ信頼ミーティングの新しいセッションタイプが作成され、すべてのミーティングのサイトに対し、追加料金無しで展開されます。 新しいセッションタイプの 1 つは Pro-End to End Encryption_VOIPonly と呼ばれます。 これは、今後変更される可能性がある パブリック サービス名 です。 セッション タイプの現在の名前については、この記事の参照セクションの セッション タイプ ID を参照してください。

サイトの新しい機能を取得するために必要な必要は何もありませんが、ユーザーに新しい セッション タイプ (ミーティング権限) を付与する必要があります。 これは、ユーザーの設定ページから個別に行う、または CSV エクスポート/インポートの往復で一括で行う必要があります。

1

Control Hub にサインインし、[Meetings] ページを開きます。

2

サイト名をクリックしてサイトの設定パネルを開きます。

3

[サイトの設定] をクリックします。

4

[共通設定] 領域で、[セッション タイプ] をクリックします。

そのページで、1 つ以上のエンドツーエンド暗号化セッション タイプが表示されます。 この記事の 参照 セクションにある セッション タイプ ID の一覧を参照してください。 たとえば、Pro-End to End Encryption_VOIPonly を参照することができます。

 

非常に類似する名前の古いセッション タイプがあります。 Pro-End to End Encryption。 このセッション タイプには、ミーティングへのアクセスに非暗号化 PSTN が含まれています。 エンドツーエンド暗号化を確認するために、 _VOIPonly バージョンを使用していることを確認してください。 セッション コード列の PRO リンクの上にカーソルを合わせると、リンクのターゲットが次のようになります。 javascript:ShowFeature(652).

これらのセッション タイプのパブリック サービス名は今後変更する場合があります。たとえば、Pro-End を End Encryption_VOIPonly から Encryption + Identity に変更する予定です。

5

新しいセッション タイプをまだ取得していない場合、Webex 担当者に連絡してください。

次に行うこと

一部のユーザーまたはすべてのユーザーに対して、このセッション タイプ/ミーティング権限を有効にしてください。

1

[ユーザー] をクリックし、ユーザーを選択して、ユーザーの構成パネルを開きます。

2

[サービス] エリアで、[Cisco Webex Meetings] をクリックします。

3

サイトを選択し (ユーザーが複数の場合)、[主催者] をクリックします。

4

[Pro-End to End to End Encryption_VOIPonly] というラベルが付いた Webex Meetings エントリの隣のボックスをオンにします。

5

ユーザー設定パネルを閉じます。

6

必要な場合は、その他のユーザーに対して繰り返します。

これを多くのユーザーに割り当てる場合、CSV 一括オプションを使用します。

1

https://admin.webex.com で Control Hub にサインインし、[Meetings] ページを開きます。

2

サイト名をクリックして、サイト設定パネルを開きます。

3

[ライセンスとユーザー] セクションで、[一括管理] をクリックします。

4

[エクスポート] をクリックして、ファイルの準備が完了するまで待ちます。

5

ファイルの準備ができたら、[結果をエクスポート] をクリックし、次に [ダウンロード] をクリックします。 (ポップアップ ウィンドウは、[ダウンロード] をクリックした後で手動で閉じる必要があります)。

6

編集のためにダウンロードされた CSV ファイルを開きます。

各ユーザーに行があります。 MeetingPrivilege 列には、コンマ区切り形式でセッション タイプ ID が含まれます。

7

新しいパスワードを割り当てしたい各ユーザーセッション タイプについては、 1561MeetingPrivilege セルのコンマ区切りリストの新しい値として追加します。

https://help.webex.com/en-us/5vox83 で参照された CSV ファイル形式の参照には、CSV ファイルの目的と内容についてのいくつかの詳細があります。

8

Control Hub の [ミーティング サイト設定] パネルを開きます。

すでにミーティング サイトのリスト ページを使用している場合は、更新が必要な場合があります。

9

[ライセンスとユーザー] セクションで、[一括管理] をクリックします。

10

[インポート] をクリックし、編集した CSV を選択してから、[インポート] をクリックします。 ファイルをアップロードしている間、しばらくお待ちください。

11

インポートが完了したら、[結果をインポート] をクリックして、エラーの発生した場合に確認できます。

12

[ユーザー] ページに進み、ユーザーの 1 人を開いて、新しいセッション タイプになっていることを確認してください。

デバイスがすでに Control Hub 組織にオンボードであり、Webex CA を使用して識別証明書を自動生成する場合、デバイスを工場出荷時設定にリセットする必要があります。

この手順では、デバイスが自分自身を識別するために使用するドメインを選択し、Control Hub 組織に複数のドメインがある場合にのみ必要です。 複数のドメインがある場合、「Cisco 検証済み」アイデンティティを持つすべてのデバイスに対してこれを実行することをお勧めします。 どのドメインがデバイスを特定 Webex に指定できない場合、1 つを選択すると、他のミーティング参加者には間違って見える可能性があります。

始める前に

デバイスがまだオンボードされていない場合、https://help.webex.com/n25jyr8 または https://help.webex.com/nutc0dy をフォローできます。 また、デバイス (https://help.webex.com/cd6d84) を識別するために使用するドメインを確認する必要があります。

1

Control Hub (https://admin.webex.com) にサインインし、[デバイス] ページを開きます。

2

デバイスを選択して、その構成パネルを開きます。

3

このデバイスを使用するドメインを選択します。

4

他のデバイスでも繰り返します。

始める前に

行う必要があること:

  • 各デバイスについて、.pem 形式で CA の署名付き証明書とプライベート キーを取得する。

  • この記事の「準備」パートのトピック「デバイスの外部アイデンティティ プロセスについて理解する」 の を読む。

  • そこにある情報に関して JWE 暗号化ツールを準備する

  • 指定された長さのランダムなバイト シーケンスを生成するツール。

  • Base64url エンコード バイトまたはテキストのツール。

  • 1個の scrypt 実装。

  • 各デバイスに対するシークレットの単語またはフレーズ。

1

デバイスの ClientSecret をプレーン テキスト シークレットで入力します。

この Secret を初めて入力する時、プレーン テキストで指定します。 物理的なデバイス コンソールでこれを行うのをお勧めするのはこのためです。

  1. Base64url は、このデバイスのシークレット フレーズをエンコードします。

  2. デバイスで TShell を開きます。

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

    上記のコマンド例が、 Secret0123456789abcdef を使用して、入力します。 自分で選択する必要があります。

デバイスには最初のシークレットがあります。 これを忘れないでください。復元ができません。デバイスを工場出荷時設定にリセットして、再び開始する必要があります。
2

証明書とプライベートキーを連結する:

  1. テキストエディタを使って .pem ファイルを開き、pem キー ブロブ証明書ブロブを貼り付け、新しい .pem ファイルとして保存します。

    (これは、暗号化して JWE ブロブを入力するペイロード テキストです)

3

証明書の追加コマンドへの入力として使用する JWE ブロブを作成します。

  1. 少なくとも 4 バイトのランダムシーケンスを作成します。 これがあなたの salt です。

  2. Scrypt ツールで暗号化キーを導き出します。

    このためには、シークレット、salt、およびキー長を使用して、選択した暗号化と一致する必要があります。 指定する他の固定値があります (N=32768、r=8、p=1)。 デバイスは同じプロセスと値を使用して、同じコンテンツを基に暗号化キーを導出します。

  3. 正確に 12 バイトのランダム シーケンスを作成します。 これは初期化ベクトルです。

  4. JOSE ヘッダーを作成し、 alg を設定し、 enc 、および cisco-kdf キーを設定します ( デバイスの外部 ID プロセスの理解を理解するに従って)。 JOSE ヘッダーのkey:value を使用して「追加」アクションを設定します "cisco-action":"add"(デバイスに証明書を追加しているため)。

  5. Base64url は JOSE ヘッダーをエンコードします。

  6. 選択された暗号と base64url エンコード JOSE ヘッダーで JWE 暗号化ツールを使用して、連結された pem ファイルからテキストを暗号化します。

  7. Base64url 初期化ベクトル、暗号化 PEM ペイロード、および認証タグをエンコードします。

  8. 次のように JWE ブロブを構築します (すべての値は base64url エンコードされます)。

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4

デバイスで TShell を開き、 (multiline) add コマンドを実行します。

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

証明書が次を実行して追加されます xcommand Security Certificates Services Show

新しい証明書の指紋をコピーします。

6

目的で証明書を有効にする WebexIdentity:

  1. 証明書自体から、または xcommand Security Certificates Services Show の出力から証明書の諮問を読み取ります。

  2. 少なくとも 4 バイトのランダムシーケンスを作成し、そのシーケンスを base64url エンコードします。 これがあなたの salt です。

  3. Scrypt ツールで暗号化キーを導き出します。

    このためには、シークレット、salt、およびキー長を使用して、選択した暗号化と一致する必要があります。 指定する他の固定値があります (N=32768、r=8、p=1)。 デバイスは同じプロセスと値を使用して、同じコンテンツを基に暗号化キーを導出します。

  4. 正確に 12 バイトのランダム シーケンスと、そのシーケンスを base64url エンコードします。 これは初期化ベクトルです。

  5. JOSE ヘッダーを作成し、 alg を設定し、 enc 、および cisco-kdf キーを設定します ( デバイスの外部 ID プロセスの理解を理解するに従って) 。 JOSE ヘッダーの key:value を使用して「アクティベート」アクションを設定します "cisco-action":"activate"(デバイスに証明書をアクティブ化しているため)。

  6. Base64url は JOSE ヘッダーをエンコードします。

  7. 選択された暗号と base64url エンコード JOSE ヘッダーで JWE 暗号化ツールを使用して、証明書の指紋を暗号化します。

    ツールは、128 または 256 ビット AES-GCM、および認証タグを選択したかどうかに応じて、16 または 32 バイト シーケンスを出力する必要があります。

  8. Base64urlencode 暗号化された指紋認証と認証タグを有効にします。

  9. 次のように JWE ブロブを構築します (すべての値は base64url エンコードされます)。

    JOSEHeader..InitVector.EncryptedFingerprint.AuthTag

  10. デバイスで TShell を開き、 次のアクティビティ コマンドを実行します。

    xcommand Security Certificates Services Activate Purpose: WebexIdentity Fingerprint: "Your..JWE.encrypted.fingerprint"
デバイスには、エンドツーエンド暗号化された Webex ミーティングで識別するために使用される準備ができている、暗号化されたアクティブな CA 発行の証明書があります。
7

デバイスを Control Hub 組織にオンボードします。

1

正しいタイプのミーティングをスケジュールします(Webex Meetings Pro-End to End Encryption_VOIPonly)。

https://help.webex.com/nsj2xpfb を参照してください。

2

Webex Meetings から主催者としてミーティングに参加します。

3

Webex CA によって検証された ID を持つデバイスからミーティングに参加します。

4

主催者として、このデバイスが正しいアイデンティティ アイコンとともにロビーに表示されます。

5

外部 CA によって検証されたアイデンティティを持つデバイスからミーティングに参加します。

6

主催者として、このデバイスが正しいアイデンティティ アイコンとともにロビーに表示されます。

7

未認証のミーティング参加者としてミーティングに参加します。

8

主催者として、この参加者が正しいアイデンティティ アイコンとともにロビーに表示されます。

9

主催者として、ユーザー/デバイスを承認または拒否します。

10

証明書をチェックすることで、可能な限り参加者/デバイスのアイデンティティを検証します。

11

ミーティングの全員に同じミーティング セキュリティ コードが表示されるのを確認してください。

12

新しい参加者とミーティングに参加します。

13

全員に同じ新しいミーティング セキュリティ コードが表示されるのを確認してください。

エンドツーエンド暗号化ミーティングをデフォルトのミーティング オプションにしますか?それとも一部のユーザーに対してだけ有効にしますか?また、すべての主催者が決定しますか? この機能の使い方を決定した時点で、使用するユーザーを準備します。特に、制限やミーティングで期待される点に関してです。

Cisco もしくは他の誰もがコンテンツを解読したり、デバイスを偽装したりできるかを確認する必要がありますか? この場合、パブリック CA の証明書が必要です。 セキュアなミーティングでは、最大 25 台のデバイスを持っている可能性があります。 このレベルのセキュリティが必要な場合は、ミーティング クライアントの参加を許可しない必要があります。

セキュアなデバイスで参加しているユーザーは、デバイスを最初に参加させ、遅れて参加すると参加できないというユーザーの期待を設定します。

ID 検証レベルが異なる場合、ユーザーは、証明書がバックアップされた ID とミーティング セキュリティ コードを使用して、お互いを検証するために権限を与えます。 参加者が未確認と表示される場合があり、チェックの方法を参加者が知っている必要がある場合でも、未確認の人は詐欺的ではない場合があります。

外部 CA を使用してデバイス証明書を発行する場合、onus が証明書を監視、更新、再適用します。

最初のシークレットを作成した場合、ユーザーがデバイスのシークレットを変更する可能性がある可能性を理解します。 インターフェイスを作成し、これを行うツールを配布する必要がある場合があります。

表 1. エンドツーエンド暗号化ミーティングのセッション タイプ ID

セッション タイプ ID

パブリック サービス名

638

E2E 暗号化+VoIPのみ

652

Pro-End to End Encryption_VOIPonly

660

Pro 3 Free-End to End Encryption_VOIPonly

E2E 暗号化+アイデンティティ

672

Pro 3 Free50-End to End Encryption_VOIPonly

673

Education Instructor E2E Encryption_VOIPonly

676

Broadworks Standard + エンドツーエンド暗号化

677

Broadworks Premium + エンドツーエンド暗号化

681

Schoology Free +エンドツーエンド暗号化

以下の表では、エンドツーエンド暗号化ミーティングと検証されたアイデンティティのために追加された Webex デバイス API コマンドについて説明しています。 API の使い方の詳細は、 https://help.webex.com/nzwo1ok を参照してください。

表 2. エンドツーエンド暗号化ミーティングと検証されたアイデンティティのためのシステムレベル API

API コール

説明

xConfiguration Conference EndToEndEncryption Mode: On

エンドツーエンド暗号化モードに切り替えます On または Off.

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

この構成は、管理者が Control Hub からデバイスの優先ドメインを設定するときに行います。 組織に複数のドメインがある場合にのみ必要です。

Webex CA からの証明書を要求すると、デバイスはこのドメインを使用します。 ドメインがデバイスを識別します。

デバイスがアクティブで外部から発行された証明書を持っている場合、この構成は適用されません。

xStatus Conference EndToEndEncryption Availability

デバイスがエンドツーエンド暗号化ミーティングに参加可能かどうかを示します。 クラウド API は、ペアリングされたアプリが参加するためにデバイスを使用できるかどうかを知るように、それを呼び出します。

xStatus Conference EndToEndEncryption ExternalIdentity Valid

デバイスが有効な外部発行証明書を持つかどうかを示します。

xStatus Conference EndToEndEncryption ExternalIdentity Identity

外部に発行された証明書の共通名から読み取りとしてのデバイスのアイデンティティ。

xStatus Conference EndToEndEncryption ExternalIdentity CertInfo

外部発行の証明書から証明書情報を読み取り、JSON 形式で出力します。

xStatus Conference EndToEndEncryption InternalIdentity Valid

デバイスが Webex CA によって発行された有効な証明書を持つかどうかを示します。

xStatus Conference EndToEndEncryption InternalIdentity Identity

Webex の発行された証明書の共通名から読み取りとしてのデバイスのアイデンティティ。

組織がドメインを持っている場合、ドメイン名を含む。

組織にドメインが存在しない場合は空です。

デバイスが複数のドメインを持つ組織に存在する場合、これは PreferredDomain からの値です。

xStatus Conference EndToEndEncryption InternalIdentity CertInfo

Webex 発行の証明書から証明書情報を読み取り、JSON ブロブとして出力します。

表 3. エンドツーエンド暗号化ミーティングと検証されたアイデンティティのための API のコール

API コール

説明

xStatus Call # ServerEncryption Type

Webex への HTTPS 接続で使用される暗号化を読み取ります。 これはユーザーに表示されます。

xStatus Conference Call # EndToEndEncryption Status

エンドツーエンド暗号化ステータスのコールを読み取ります。 ユーザーに、パッドロック アイコンの存在 (または不在) として表示します。

xStatus Conference Call # EndToEndEncryption SecurityCode

ミーティングのセキュリティ コードを読み取ります。 これはユーザーに表示され、参加者が参加すると変わります。

xStatus Conference Call # EndToEndEncryption MediaEncryption Type

メディア接続で使用される暗号化を読み取ります。 これはユーザーに表示されます。

xStatus Conference Call # EndToEndEncryption GroupEncryption Type

Messaging Layer Security (MLS) に使用される暗号化を読み取ります。

xStatus Conference Call # EndToEndEncryption Roster Participant

このミーティングのから MLS グループの状態に貢献している参加者の一覧を表示します。 このリストは、Webex ではなく、MLS により検出されます。

xStatus Conference Call # EndToEndEncryption Roster Participant # Id

指定された参加者の WDM URL。

xStatus Conference Call # EndToEndEncryption Roster Participant # Status:

指定された参加者の確認ステータス。

xStatus Conference Call # EndToEndEncryption Roster Participant # Identity:

特定の参加者のプライマリ アイデンティティ、通常はドメイン (デバイス) またはメール アドレス (ユーザー) です。

xStatus Conference Call # EndToEndEncryption Roster Participant # DisplayName:

指定された参加者の表示名。 参加者/デバイスにより署名済み。

xStatus Conference Call # EndToEndEncryption Roster Participant # CertInfo:

指定された参加者の証明書からの JSON 形式の証明書情報です。

xCommand Conference ParticipantList Search

このコマンドを拡張して参加者のエンドツーエンド暗号化情報を含めました。

xCommand Conference ParticipantList Search

参加者リストの検索には、 EndToEndEncryptionStatus 、参加者のアイデンティティ確認ステータスが含まれます。 この値は UI に表示されます。

xCommand Conference ParticipantList Search

参加者リストの検索には、 EndToEndEncryptionIdentity 、 参加者のプライマリ アイデンティティが含まれます。 これは通常、ドメインまたはな電子メール アドレスです。 この値は UI に表示されます。

xCommand Conference ParticipantList Search

参加者リストの検索には、 EndToEndEncryptionCertInfo 、参加者の証明書を含む JSON ブロブが含まれます。 この値は UI に表示されます。

xEvent Conference ParticipantList Participant(Added)

xEvent Conference ParticipantList Participant(Updated)

xEvent Conference ParticipantList Participant(Deleted)

この 3 つのイベントは現在、影響を受ける参加者の EndToEndEncryptionStatus を設定し、 EndToEndEncryptionIdentity 、および EndToEndEncryptionCertInfo が含まれます。

表 4. エンドツーエンド暗号化ミーティングと検証されたアイデンティティのための ClientSecret 関連 API

API コール

説明

xCommand Security ClientSecret Populate Secret: "base64url-encoded" または xCommand Security ClientSecret Populate Secret: JWEblob

base64url エンコードのプレーン テキスト値を受け付け、初めてデバイスにクライアント シークレットをシードします。

その後、シークレットを更新するには、古いシークレットにより暗号化された新しいシークレットを含む JWE ブロブを指定する必要があります。

xCommand Security Certificates Services Add JWEblob

証明書を追加します (プライベート キーを含む)。

このコマンドを拡張して、暗号化 PEM データを含む JWE ブロブを承認しました。

xCommand Security Certificates Services Activate Purpose:WebexIdentity FingerPrint: JWEblob

WebexIdentity に対して特定の証明書をアクティブ化します。 また、 Purpose を実行するには、指紋認証が暗号化され、JWE ブロブに登録されている必要があります。

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

WebexIdentity に対して特定の証明書をアクティベート解除化します。 また、 Purpose を実行するには、指紋認証が暗号化され、JWE ブロブに登録されている必要があります。