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

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

本人確認

アイデンティティ確認によるエンドツーエンド暗号化は、エンドツーエンド暗号化ミーティングに追加のセキュリティを提供します。

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

Webexアプリのユーザーは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のアイデンティティ確認でのエンドツーエンド暗号化を選択します。

デバイスごとに別の証明書を使用し、デバイスごとに固有の CN を持つことをお勧めします。 たとえば、「example.com」ドメインを所有する組織の「meeting-room-1.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.6 から、 Webex Meetingsデスクトップクライアントはエンドツーエンド暗号化ミーティングに参加できます。

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

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

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

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

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

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

  • これらの200人の参加者のうち 最大で25人の外部検証済みのデバイスが参加しは、ミーティングに参加する最初の参加者でなければなりませんを選択します。

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

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

管理インターフェース

Control Hub の組織は組織全体を管理する一元化された ID であるため、Control Hub を使用してミーティング サイトを管理することを強くお勧めします。一方、サイトの管理では、ID はサイトごとに管理されます。

サイトの管理管理から管理されるユーザーには、Cisco が検証したアイデンティティオプションを持つことはできません。 これらのユーザーは、エンドツーエンド暗号化ミーティングに参加するために匿名の証明書が発行され、主催者がアイデンティティ確認を行うミーティングから除外される場合があります。

関連情報
  • Webex Meetings 41.7

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

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

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

  • ユーザーがビデオ システムから参加するには、コラボレーション ミーティング ルームをオンにする必要があります。 詳細については「ビデオ システムが Webex サイトでミーティングとイベントに参加することを許可する」をご覧ください。

外部検証されたアイデンティティが必要ない場合、この手順をスキップできます。

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

デジタル証明書をリクエスト、購入、受信し、関連するプライベート キーを作成するには、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 を使用するためにアップグレードする既存のデバイスがある場合、デバイスを初期化する必要があります。

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

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

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

これらの手順が完了したらビデオ システムがWebexサイト上のミーティングとイベントに参加することを許可するを選択します。

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

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

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

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

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

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

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

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

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

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

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

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

JWE 形式の使用方法

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

参照先: JSON ウェブ暗号化 (JWE)https://datatracker.ietf.org/doc/html/rfc7516およびJSON ウェブ署名(JWS)https://datatracker.ietf.org/doc/html/rfc7515を選択します。

Cisco では、コンパクトなシリアル化を 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 です。

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

  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 にサインインし、[サービス] > [ミーティング] に移動します。

2

[サイト] をクリックし、設定を変更する Webex サイトを選択して、[設定] をクリックします。

3

[共通設定] の下で、[セッション タイプ] を選択します。

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

 

非常に類似する名前の古いセッション タイプがあります。 Pro-End to End Encryption。 このセッション タイプには、ミーティングへのアクセスに非暗号化 PSTN が含まれています。 Webex ハイブリッド サービスをセットアップする_VOIPのみエンドツーエンドの暗号化を保証するバージョン。 セッション コード列の PRO リンクの上にカーソルを合わせると、リンクのターゲットが次のようになります。 javascript:ShowFeature(652) です。

これらのセッション タイプのパブリック サービス名は今後変更する場合があります。

5

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

次に行うこと

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

1

まずコントロールハブを選択し、次に移動します:管理次のリンクをクリックしてください:ユーザーを選択します。

2

更新するユーザー アカウントを選択してから、ミーティングを選択します。

3

[Settings apply to ] ドロップダウンから、更新するミーティング サイトを選択します。

4

以下のチェックボックスをオンにします。 Pro-End to End Encryption_ VOIPのみを選択します。

5

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

6

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

これを多くのユーザーに割り当てるには、次のオプションを使用します複数ユーザーの E2EE ミーティングを有効にするを選択します。

1

Control Hub にサインインし、[サービス] > [ミーティング] に移動します。

2

[サイト] をクリックし、設定を変更する Webex サイトを選択します。

3

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

4

[レポートの生成]をクリックし、ファイルの準備を待ちます。

5

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

6

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

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

7

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

このWebex CSVファイル形式のリファレンスには、 CSVファイルの目的と内容についての詳細が含まれています。

8

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


 

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

9

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

10

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

11

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

12

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

次の方法でミーティング録画に透かしを追加できます: Webex Meetings Pro-End to End Encryption_VOIPonly 機密ミーティングの未許可録画のソース クライアントまたはデバイスを識別できるセッション タイプ。

この機能が有効になっている場合、ミーティングの音声には各参加クライアントまたはデバイスの一意の識別子が含まれます。 音声録音を Control Hub にアップロードして、録音を分析し、一意の識別子を検索できます。 結果を確認して、ミーティングを録画したソース クライアントまたはデバイスを確認できます。

  • 分析されるには、録画は AAC、MP3、M4A、WAV、MP4、AVI、または MOV ファイルであり、500MB を超えてはなりません。
  • 録画は 100 秒以上でなければなりません。
  • 組織のユーザーによって主催されたミーティングの録画のみを分析できます。
  • 透かし情報は、組織のミーティング情報と同じ期間保持されます。
E2EE ミーティングに音声すかしを追加する
  1. Control Hub にサインインし、[管理][組織設定] を選択します。
  2. [ミーティングのウォーターマークセクション、トグルオン音声のウォーターマークの追加を選択します。

    これがオンに切り替わってからしばらくすると、ユーザーは Webex Meetings Pro-End to End Encryption_VOIPonly セッション タイプには、[セキュリティ] セクションの [ デジタル透かし] オプションを参照してください。

ウォーターマークされたミーティングをアップロードおよび分析する
  1. Control Hub の [監視中を選択し、トラブルシューティングを選択します。
  2. クリックウォーターマーク分析を選択します。
  3. リストからミーティングを検索または選択し、[分析] をクリックします。
  4. [音声ウォーターマークの分析分析の名前を入力します。
  5. (オプション)分析のメモを入力します。
  6. 分析する音声ファイルをドラッグアンドドロップするか、ファイルを選択を参照して、音声ファイルを参照します。
  7. [閉じる] をクリックします。

    分析が完了すると、ウォーターマークの分析] ページからいつでも確認できます。

  8. リストからミーティングを選択し、分析結果を確認します。 クリックダウンロードボタンを選択し、結果をダウンロードします。
機能と制限

記録された透かしを正常にデコードする要因には、記録デバイスと音声を出力するスピーカー間の距離、その音声のボリューム、環境ノイズなどが含まれます。当社の透かし技術は、メディアが共有されたときに発生する可能性があるように、複数回エンコードされることにさらなる耐性を備えています。

この機能は、透かし識別子を広範囲かつ合理的な状況で正常にデコードできるように設計されています。 私たちの目標は、個人のエンドポイントまたはラップトップクライアントの近くのデスクに横たわっている携帯電話などの記録デバイスが、常に分析を成功させる記録を作成することです。 録音デバイスがソースから離れるか、完全なオーディオスペクトルを聴くことで不明瞭になるため、分析が成功する可能性は低下します。

録画の分析を成功させるには、ミーティングの音声の合理的なキャプチャが必要です。 ミーティングの音声がクライアントをホストしているコンピューターに録音されている場合、制限は適用されません。

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

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

始める前に

デバイスがまだオンボードされていない場合は、次の手順に従ってくださいAPIまたはローカル Web インターフェイスを使用したCisco Webexへのデバイスの登録またはBoard、Desk、Room Series 向けのクラウド オンボーディングを選択します。 内のデバイスを識別するために使用するドメインを確認する必要もありますドメインを管理するを選択します。

1

Control Hub にサインインおよびその下管理を選択し、デバイスを選択します。

2

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

3

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

4

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

始める前に

行う必要があること:

  • CA の署名付き証明書とプライベート キーを取得するには、 .pem フォーマットします。

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

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

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

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

  • 1個の scrypt 実装。

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

1

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

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

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

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

  3. コマンド 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 ヘッダーを作成し、 algenc 、および 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 ヘッダーを作成し、 algenc 、および 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) をスケジュールします。

2

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

3

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

4

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

5

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

6

主催者として、このデバイスが正しいアイデンティティ アイコンとともにロビーに表示されます。 ID アイコンの詳細をご確認ください

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

教育インストラクタ E2E Encryption_VOIPonly

676

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

677

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

681

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

以下の表では、エンドツーエンド暗号化ミーティングと検証されたアイデンティティのために追加された Webex デバイス API コマンドについて説明しています。 API の使用方法の詳細については、「Webex Room およびデスク デバイス、Webex Board の API にアクセスする」を参照してください。

これらの xAPI コマンドは、次のいずれかのデバイスでのみ使用できます。

  • Webex に登録されているデバイス

  • オンプレミスで登録され、デバイス用の Webex Edge を使って Webex にリンクされているデバイス

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

API コール

説明

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

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

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

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

xStatus Conference EndToEndEncryption Availability

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

xStatus Conference EndToEndEncryption ExternalIdentity Verification

デバイスが External 認証を使用するかどうか (外部発行の証明書があるかどうか) を示します。

xStatus Conference EndToEndEncryption ExternalIdentity Identity

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

xStatus Conference EndToEndEncryption ExternalIdentity CertificateChain Certificate # specificinfo

外部発行された証明書から特定の情報を読み取ります。

表示されたコマンドの # を証明書の番号に置き換えます。 以下を置換: specificinfo 置換対象:

  • Fingerprint

  • NotAfter 有効終了日

  • NotBefore 有効開始日

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

  • Subject # Name 証明書のタイトルの一覧 (メール アドレスやドメイン名など)

  • Validity この証明書の有効性を示します (例: valid または expired

xStatus Conference EndToEndEncryption ExternalIdentity Status

デバイスの外部 ID のステータス (例: valid または error) として共有する必要があります。

xStatus Conference EndToEndEncryption InternalIdentity Verification

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

xStatus Conference EndToEndEncryption InternalIdentity Identity

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

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

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

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

xStatus Conference EndToEndEncryption InternalIdentity CertificateChain Certificate # specificinfo

Webex が発行する証明書から特定の情報を読み取ります。

表示されたコマンドの # を証明書の番号に置き換えます。 以下を置換: specificinfo 置換対象:

  • Fingerprint

  • NotAfter 有効終了日

  • NotBefore 有効開始日

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

  • Subject # Name 証明書のタイトルの一覧 (メール アドレスやドメイン名など)

  • Validity この証明書の有効性を示します (例: valid または expired

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

API コール

説明

xEvent Conference ParticipantList ParticipantAdded

xEvent Conference ParticipantList ParticipantUpdated

xEvent Conference ParticipantList ParticipantDeleted

この 3 つのイベントは現在、影響を受ける参加者の EndToEndEncryptionStatusEndToEndEncryptionIdentity 、および 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 ブロブに登録されている必要があります。