사용자는 미팅을 미팅 예약하기 할 때 미팅 유형 을 선택합니다. 미팅 중에 뿐만 아니라 로비에서 참가자를 수락할 때 호스트는 각 참가자의 ID 확인 상태를 확인할 수 있습니다. 또한 미팅의 모든 현재 참가자에게 공통적인 미팅 코드가 있으며 이는 참가자들이 서로 확인하는 데 사용할 수 있습니다.

미팅 호스트와 다음 정보를 공유합니다.

신원 확인

ID 확인을 통한 종단 간 암호화는 종단 간 암호화된 미팅에 추가 보안을 제공합니다.

참가자 또는 장치가 공유된 MLS(Messaging Layer Security) 그룹에 참여할 때 다른 그룹 구성원에게 인증서를 제시하면 다른 그룹 구성원이 발급하는 인증 기관(CA)에 대해 인증서의 유효성을 검사합니다. 인증서가 유효한지 확인하여 CA는 참가자의 ID를 확인하고 미팅은 참가자/장치를 확인된 것으로 표시합니다.

Webex 앱 사용자는 인증에 성공할 때 액세스 토큰을 발급하는 Webex ID 저장소에 대해 자신을 인증합니다. 종단 간 암호화된 미팅에서 ID를 확인하기 위해 인증서가 필요한 경우, Webex CA는 액세스 토큰을 기반으로 인증서를 발급합니다. 현재 Webex Meetings 사용자가 타사/외부 CA에서 발급한 인증서를 받을 수 있는 방법은 제공하지 않습니다.

장치는 내부(Webex) CA에서 발급한 인증서 또는 외부 CA에서 발급한 인증서를 사용하여 직접 인증할 수 있습니다.

  • 내부 CA— Webex 는 장치의 컴퓨터 계정에 대한 액세스 토큰을 기반으로 내부 인증서를 발급합니다. 인증서는 Webex CA에서 서명합니다. 장치에는 사용자와 동일한 방식으로 사용자 ID가 없습니다. 따라서 Webex 는 장치 인증서의 ID(일반 이름(CN))를 쓸 때 조직의 도메인(하나)을 사용합니다.

  • 외부 CA—선택한 발급자로부터 직접 장치 인증서를 요청하고 구매합니다. 사용자만 알고 있는 암호를 사용하여 인증서를 암호화하고 직접 업로드하며 인증해야 합니다.

    Cisco 는 참여하지 않습니다. 이는 진정한 종단 간 암호화 및 확인된 ID를 보장하고, Cisco 가 미팅을 도청/미디어 암호 해독할 수 있는 이론적 가능성을 방지하는 방법입니다.

내부에서 발급된 장치 인증서

Webex는 시작 후 등록할 때 장치에 인증서를 발급하고 필요한 경우 갱신합니다. 장치의 경우 인증서에는 계정 ID 및 도메인이 포함됩니다.

조직에 도메인이 없는 경우 Webex CA는 도메인 없이 인증서를 발급합니다.

조직에 여러 도메인이 있는 경우 Control Hub를 사용하여 장치가 ID에 사용할 도메인을 Webex에 알릴 수 있습니다. 또한 API를 사용할 수 있습니다 xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com".

여러 도메인이 있으며 장치의 기본 설정 도메인을 설정하지 않은 경우 Webex가 대신 도메인을 선택합니다.

외부에서 발급된 장치 인증서

관리자는 공용 CA 중 하나로 서명된 자체 인증서를 사용하여 장치를 프로비저닝할 수 있습니다.

인증서는 RSA 키로 서명할 수 있지만 ECDSA P-256 키 쌍을 기반으로 해야 합니다.

인증서의 값은 조직에서 결정합니다. 일반 이름(CN) 및 주체 대체 이름 (SAN)은 에 설명된 대로 Webex 미팅 사용자 인터페이스 에 표시됩니다. Webex Meetings 에 대해 ID 확인을 통한 종단 간 암호화 .

장치마다 별도의 인증서를 사용하고 장치마다 고유한 CN을 사용하는 것이 좋습니다. 예를 들어, "example.com" 도메인을 소유하는 조직의 경우 "meeting-room-1.example.com"입니다.

외부 인증서가 변조되지 않도록 완벽하게 보호하기 위해 클라이언트 암호 기능을 사용하여 다양한 xcommand를 암호화하고 서명합니다.

클라이언트 비밀번호를 사용할 때 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 데스크탑 클라이언트는 종단 간 암호화된 미팅에 참여할 수 있습니다.

  • 조직에서 Meetings 데스크탑 응용프로그램을 실행하여 Webex 앱 이 미팅에 참여하도록 활성화한 경우, 해당 옵션을 사용하여 종단 간 암호화된 미팅에 참여할 수 있습니다.

  • Webex 웹 클라이언트는 종단 간 암호화된 미팅에 참여할 수 없습니다.

  • 타사 SIP 소프트 클라이언트는 종단 간 암호화된 미팅에 참여할 수 없습니다.

ID
  • 설계상 외부에서 확인된 장치 ID를 관리하기 위한 Control Hub 옵션은 제공하지 않습니다. 진정한 종단 간 암호화를 위해서는 비밀 및 키를 알고/액세스해야 합니다. 이러한 키를 관리하기 위해 클라우드 서비스를 도입한 경우 해당 키를 가로채기 당할 수 있습니다.

  • 현재 업계 표준 암호화 기술을 기반으로 자신의 도구를 설계할 수 있는 '레시피'를 제공하여 장치 ID 인증서 및 개인 키를 요청하거나 암호화하는 데 도움을 줍니다. 암호 또는 키에 대한 실제 액세스나 인식된 액세스는 원하지 않습니다.

미팅
  • 종단 간 암호화된 미팅은 현재 최대 200명의 참가자를 지원합니다.

  • 해당 200명의 참가자 중 최대 25개의 외부에서 확인된 장치가 참가할 수 있습니다. 미팅에 참여하는 첫 번째 참가자여야 함 .

    더 많은 수의 장치가 미팅에 참여하는 경우, 백엔드 미디어 서비스는 미디어 스트림을 트랜스코딩하려고 시도합니다. 미디어를 암호 해독, 트랜스코딩 및 다시 암호화할 수 없는 경우(장치의 암호화 키가 없거나 있어서는 안 되기 때문) 트랜스코딩에 실패합니다.

    이 제한을 완화하려면 장치에 대해 소규모 미팅을 권장하거나 장치와 Meetings 클라이언트 간의 초대에 시차를 둡니다.

관리 인터페이스

Control Hub 조직은 전체 조직에 대해 중앙 집중식 ID를 사용하는 반면, 사이트 관리 에서 ID는 사이트별로 제어되므로 Control Hub를 사용하여 미팅 사이트를 관리하는 것이 좋습니다.

사이트 관리 관리에서 관리되는 사용자는 Cisco 인증 ID 옵션을 사용할 수 없습니다. 해당 사용자는 종단 간 암호화된 미팅에 참여하기 위해 익명의 인증서를 발급받으며, 호스트가 신원 확인을 원하는 미팅에서 제외될 수 있습니다.

  • Webex Meetings 41.7.

  • 클라우드에 등록된 Webex Room 및 Webex Desk 시리즈 장치, 실행 중 10.6.1-RoomOS_August_2021.

  • Control Hub의 미팅 사이트에 대한 관리 액세스를 통해 사용자에 대한 새 세션 유형을 활성화합니다.

  • Control Hub 조직에서 확인된 하나 이상의 도메인(Webex CA를 사용하여 확인된 ID에 대한 장치 인증서를 발급하는 경우).

  • 협업 미팅 룸을 사용할 수 있게 하면 사용자가 비디오 시스템에서 참여할 수 있습니다. 자세한 정보는 Webex 사이트에서 비디오 시스템이 Meetings 및 Events에 참여할 수 있게 허용을 참조하십시오.

외부에서 확인된 ID가 필요하지 않은 경우 이 단계를 건너뛸 수 있습니다.

최고 수준의 보안 및 ID 확인을 위해 각 장치에는 신뢰할 수 있는 공용 CA( Certificate Authority )에서 발급한 고유한 인증서가 있어야 합니다.

디지털 인증서를 요청, 구입 및 수신하고 연결된 개인 키를 생성하려면 CA와 상호 작용해야 합니다. 인증서를 요청할 때 다음 파라미터를 사용합니다.

  • 인증서는 잘 알려진 공용 CA에서 발급하고 서명해야 합니다.

  • 고유: 각 장치에 고유한 인증서를 사용하는 것이 좋습니다. 모든 장치에 하나의 인증서를 사용하면 보안 침해가 발생합니다.

  • CN(일반 이름) 및 SAN(주체 대체 이름): 이러한 이름은 Webex에서 중요하지 않지만 사용자가 읽고 장치와 연결할 수 있는 값이어야 합니다. CN은 다른 미팅 참가자에게 장치의 확인된 기본 ID로 표시되며 사용자가 미팅 UI를 통해 인증서를 검사하는 경우 SAN이 표시됩니다. 같은 이름을 사용할 수 있지만 name.model@example.com.

  • 파일 형식: 인증서 및 키는 다음 위치에 있어야 합니다. .pem 형식.

  • 목적: 인증서 목적은 Webex ID여야 합니다.

  • 키 생성: 인증서는 ECDSA P-256 키 쌍(P-256 곡선을 사용하는 타원 곡선 디지털 서명 알고리즘)을 기반으로 해야 합니다.

    이 요구 사항은 서명 키로 확장되지 않습니다. CA는 RSA 키를 사용하여 인증서에 서명할 수 있습니다.

장치에서 외부적으로 확인된 ID를 사용하지 않으려면 이 단계를 건너뛸 수 있습니다.

새 장치를 사용하고 있는 경우 아직 Webex에 등록하지 마십시오. 안전을 위해 이 시점에서 네트워크에 연결하지 마십시오.

외부에서 확인된 ID를 사용하도록 업그레이드하려는 기존 장치가 있는 경우, 장치를 공장 초기화해야 합니다.

  • 기존 구성을 유지하려면 기존 구성을 저장합니다.

  • 장치를 사용하지 않을 때 창을 예약하거나 단계적 접근 방식을 사용합니다. 사용자에게 예상할 수 있는 변경 사항을 알립니다.

  • 장치에 대한 물리적 액세스를 보장합니다. 네트워크를 통해 장치에 액세스해야 하는 경우 암호가 일반 텍스트로 이동하여 보안 침해가 발생할 수 있습니다.

이 단계를 완료하면 비디오 시스템이 Webex 사이트 에서 미팅 및 이벤트에 참여하도록 허용 .

장치를 제외한 모든 사용자가 장치 미디어를 암호화할 수 없도록 하려면 장치의 개인 키를 암호화해야 합니다. JWE(JSON Web Encryption)를 사용하여 암호화된 키 및 인증서를 관리할 수 있도록 디바이스용 API를 설계했습니다.

클라우드를 통해 진정한 종단 간 암호화를 보장하기 위해 인증서 및 키를 암호화하고 업로드하는 데 관여할 수 없습니다. 이 수준의 보안이 필요한 경우 다음을 수행해야 합니다.

  1. 인증서를 요청합니다.

  2. 인증서의 키 쌍을 생성합니다.

  3. 장치의 암호화 기능을 시드하기 위해 각 장치의 초기 암호를 생성(및 보호)합니다.

  4. JWE 표준을 사용하여 파일 암호화를 위한 자체 도구를 개발하고 유지 관리합니다.

    필요한 프로세스 및 (비밀) 매개 변수 및 선택한 개발 도구에서 따라야 하는 방법이 아래에 설명되어 있습니다. 또한 프로세스를 확인하는 데 도움이 되도록 일부 테스트 데이터와 결과 JWE blob를 예상대로 제공합니다.

    Python3 및 JWCrypto 라이브러리를 사용하는 지원되지 않는 참조 구현은 요청 시 Cisco에서 사용할 수 있습니다.

  5. 도구 및 장치의 초기 암호를 사용하여 인증서 및 키를 연결하고 암호화합니다.

  6. 결과 JWE blob를 장치에 업로드합니다.

  7. Webex ID에 사용할 암호화된 인증서의 목적을 설정하고 인증서를 활성화합니다.

  8. (권장) 장치 사용자가 초기 암호를 변경하고 미디어를 보호할 수 있도록 도구에 인터페이스를 제공(또는 배포)합니다.

JWE 형식을 사용하는 방법

이 섹션에서는 JWE가 장치에 대한 입력으로 생성될 것으로 예상하는 방법을 설명하므로 인증서 및 키에서 blob를 생성하는 자체 도구를 빌드할 수 있습니다.

참조 JSON 웹 암호화(JWE)https://datatracker.ietf.org/doc/html/rfc7516그리고 JSON 웹 서명(JWS)https://datatracker.ietf.org/doc/html/rfc7515.

우리는 사용 컴팩트 직렬화 JWE Blob을 생성하기 위한 JSON 문서. JWE Blob을 만들 때 포함해야 하는 매개 변수는 다음과 같습니다.

  • JOSE 헤더(보호). JSON 객체 서명 및 암호화 헤더에 다음 키 값 쌍을 포함해야 합니다.

    • "alg":"dir"

      직접 알고리즘은 페이로드 암호화를 지원하는 유일한 알고리즘이며 장치의 초기 클라이언트 암호를 사용해야 합니다.

    • "enc":"A128GCM" 또는 "enc":"A256GCM"

      다음 두 개의 암호화 알고리즘을 지원합니다.

    • "cisco-action": "add" 또는 "cisco-action": "populate" 또는 "cisco-action": "activate" 또는 "cisco-action": "deactivate"

      이는 독점 키와 사용 가능한 4개의 값입니다. 암호화된 데이터의 목적을 대상 장치에 알리기 위해 이 키를 도입했습니다. 이 값은 암호화된 데이터를 사용하는 장치의 xAPI 명령을 따라 이름이 지정됩니다.

      향후 JWE 확장 프로그램과의 cisco-action 잠재적 충돌을 완화하기 위해 이름을 지정했습니다.

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

      또 다른 독점 키입니다. 제공한 값을 장치의 키 파생을 위한 입력으로 사용합니다. 이 version 반드시 1(키 파생 기능의 버전). 값 salt 최소 4바이트의 base64 URL 인코딩 시퀀스여야 하며 반드시 무작위로 선택해야 합니다.

  • JWE 암호화된 키. 이 필드는 비어 있습니다. 장치는 파생 ClientSecret.

  • JWE 초기화 벡터. 페이로드를 암호 해독하려면 base64url 인코딩 초기화 벡터를 제공해야 합니다. IV는 반드시 임의의 12바이트 값이어야 합니다(IV의 길이가 12바이트여야 하는 AES-GCM 암호 제품군 사용).

  • JWE AAD(추가 인증 데이터). 이 필드는 압축 직렬화에서 지원되지 않으므로 생략해야 합니다.

  • JWE 암호문: 이는 비밀로 유지하려는 암호화된 페이로드입니다.

    페이로드는 비어 있을 수 있습니다(MAY). 예를 들어, 클라이언트 암호를 재설정하려면 빈 값으로 덮어써야 합니다.

    장치에서 수행하려는 작업에 따라 다양한 유형의 페이로드가 있습니다. 다른 xAPI 명령은 다른 페이로드를 예상하며 다음과 같이 키를 사용하여 페이로드의 목적을 cisco-action 지정해야 합니다.

    • 함께 "cisco-action":"populate" 암호문은 새 ClientSecret.

    • 함께 “ "cisco-action":"add" 암호 텍스트는 인증서 및 개인 키(연결됨)를 포함하는 PEM blob입니다.

    • 함께 “ "cisco-action":"activate" 암호 텍스트는 장치 ID 확인을 위해 활성화하는 인증서의 지문(sha-1의 16진수 표현)입니다.

    • 함께 “ "cisco-action":"deactivate" 암호 텍스트는 장치 ID 확인에 사용되지 않도록 비활성화하려는 인증서의 지문(sha-1의 16진수 표현)입니다.

  • JWE 인증 태그: 이 필드에는 압축적으로 직렬화된 전체 JWE blob의 무결성을 확인하기 위한 인증 태그가 포함되어 있습니다.

암호화 키를 파생하는 방법 ClientSecret

암호의 첫 번째 채우기 이후에는 암호를 일반 텍스트로 수락하거나 출력하지 않습니다. 이는 장치에 액세스할 수 있는 사용자의 잠재적인 사전 공격을 방지하기 위한 것입니다.

장치 소프트웨어는 클라이언트 암호를 키 파생 기능(kdf)에 대한 입력으로 사용한 후 장치의 콘텐츠 암호 해독/암호화에 파생된 키를 사용합니다.

따라서 JWE blob를 생성하는 도구는 동일한 절차에 따라 클라이언트 암호에서 동일한 암호화/암호 해독 키를 파생시켜야 합니다.

장치는 다음 파라미터와 함께 키 파생( 참조)에 https://en.wikipedia.org/wiki/Scryptscrypt를 사용합니다.

  • 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 blob를 장치에 추가하는 것입니다(전체 인증서와 키 대신 매우 짧은 문자열로 인증서 추가 모방). 예제의 클라이언트 암호는 다음과 같습니다 ossifrage.

  1. 암호화 암호를 선택합니다. 이 예제는 다음을 사용합니다 A128GCM( Galois 카운터 모드에서 128비트 키를 사용하는 AES ). 도구는 다음을 사용할 수 있습니다 A256GCM 원하는 경우.

  2. 솔트(최소 4바이트의 무작위 시퀀스여야 함)를 선택합니다. 이 예제는 다음을 사용합니다(16진수 바이트) E5 E6 53 08 03 F8 33 F6. Base64url은 시퀀스를 인코딩하여 다음을 얻습니다 5eZTCAP4M_Y(base64 패딩 제거).

  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 Base64url은 다음과 같이 인코딩합니다. lZ66bdEiAQV4_mqdInj_rA.

  4. 초기화 벡터로 사용할 12바이트의 무작위 시퀀스를 선택합니다. 이 예제는 다음을 사용합니다(16진수). 34 b3 5d dd 5f 53 7b af 2d 92 95 83 Base64url은 다음과 같이 인코딩합니다. NLNd3V9Te68tkpWD.

  5. 압축 직렬화를 사용하여 JOSE 헤더를 생성하고(여기서 사용하는 것과 동일한 파라미터 순서를 따름) base64url로 인코딩합니다.

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

    base64url로 인코딩된 JOSE 헤더는 다음과 같습니다. eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

    이는 JWE blob의 첫 번째 요소가 됩니다.

  6. JWE 암호화 키를 제공하지 않기 때문에 JWE blob의 두 번째 요소는 비어 있습니다.

  7. JWE blob의 세 번째 요소는 초기화 벡터입니다 NLNd3V9Te68tkpWD.

  8. JWE 암호화 도구를 사용하여 암호화된 페이로드 및 태그를 생성합니다. 이 예제에서 암호화되지 않은 페이로드는 가짜 PEM blob가 됩니다 this is a PEM file

    사용해야 하는 암호화 파라미터는 다음과 같습니다.

    • 페이로드: this is a PEM file

    • 암호화 암호는 AES 128 GCM입니다

    • AAD(추가 인증 데이터)로서 base64url로 인코딩된 JOSE 헤더

    Base64url은 암호화된 페이로드를 인코딩하며 다음과 같이 됩니다 f5lLVuWNfKfmzYCo1YJfODhQ

    이는 JWE blob의 4번째 요소(JWE 암호문)입니다.

  9. Base64url은 8단계에서 생성한 태그를 인코딩하며 다음과 같이 됩니다 PE-wDFWGXFFBeo928cfZ1Q

    이는 JWE blob의 5번째 요소입니다.

  10. JWE blob의 5가지 요소를 도트(JOSEheader..IV.Ciphertext.Tag)와 연결하여 다음을 얻습니다.

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

  11. 여기에 표시된 것과 동일한 base64url로 인코딩된 값을 파생한 경우 자체 도구를 사용하면 E2E 암호화 및 장치의 확인된 ID를 보호할 준비가 된 것입니다.

  12. 이 예제는 실제로 작동하지 않지만 원칙적으로 다음 단계는 인증서를 추가하는 장치의 xcommand에 대한 입력으로 위에서 생성한 JWE blob를 사용합니다.

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

제로 트러스트 미팅에 대한 세션 유형은 추가 비용 없이 모든 미팅 사이트에서 사용할 수 있습니다. 다음 세션 유형 중 하나를 호출합니다. Pro-End to End Encryption_VOIPonly. 이것은 공공 서비스 이름으로, 앞으로 변경될 수 있습니다. 세션 유형의 현재 이름은 이 문서의 참조 섹션에서 세션 유형 ID를 참조하십시오.

사이트에 대해 이 기능을 얻기 위해 할 필요가 없습니다. 사용자에게 새로운 세션 유형(미팅 권한이라고도 함)을 부여해야 합니다. 사용자의 구성 페이지를 통해 개별적으로 또는 CSV 내보내기/가져오기를 통해 일괄적으로 이 작업을 실행할 수 있습니다.

1

Control Hub에 로그인하고 서비스 > 미팅으로 이동합니다.

2

사이트를 클릭하고 설정을 변경하고자 하는 Webex 사이트를 선택한 후 설정을 클릭합니다.

3

공통 설정 아래에서 세션 유형을 선택합니다.

4
하나 이상의 종단 간 암호화 세션 유형이 표시되어야 합니다. 이 문서의 참조 섹션에서 세션 유형 ID 목록을 참조하십시오. 예를 들어, Pro-End to End Encryption_VOIPonly가 나타날 수도 있습니다.

 

Pro-End to End Encryption과 같이 이름이 매우 비슷한 이전 세션 유형이 있습니다. 이 세션 유형에는 미팅에 대한 암호화되지 않은 PSTN 액세스가 포함되어 있습니다. 다음 항목이 있는지 확인하십시오._ VOIP 전용 엔드-투-엔드 암호화를 보장하는 버전입니다. 세션 코드 열에서 PRO 링크를 마우스로 가리켜서 확인할 수 있습니다. 이 예제에서 링크의 대상은 다음과 같습니다 javascript:ShowFeature(652).

향후 이러한 세션 유형에 대한 공개 서비스 이름을 변경할 수 있습니다.

5

아직 새 세션 유형이 없는 경우 Webex 담당자에게 문의하십시오.

다음에 수행할 작업

일부 또는 모든 사용자에 대한 이 세션 유형 / 미팅 권한을 활성화합니다.

1

로그인 제어 허브 로 이동합니다. 관리 > 사용자 .

2

업데이트할 사용자 계정 을 선택한 후 미팅 .

3

설정이 적용되어 드롭다운에서 업데이트할 미팅 사이트를 선택합니다.

4

옆의 확인란을 선택합니다. Pro-End to End Encryption_ VOIP 전용 .

5

사용자 구성 목록을 닫습니다.

6

필요한 경우 다른 사용자에 대해 반복합니다.

이를 많은 사용자에게 지정하려면 다음 옵션을 사용합니다. 여러 사용자에 대해 E2EE 미팅 활성화 .

1

Control Hub에 로그인하고 서비스 > 미팅으로 이동합니다.

2

사이트를 클릭하고 설정을 변경할 Webex 사이트를 선택합니다.

3

라이센스 및 사용자 섹션에서 일괄 관리를 클릭합니다.

4

보고서 생성을 클릭하고 파일을 준비하는 동안 기다립니다.

5

파일이 준비되면 결과 내보내기다운로드를 차례로 클릭합니다. (다음을 클릭한 후 해당 팝업 창을 수동으로 닫아야 합니다. 다운로드 .)

6

다운로드한 CSV 파일을 열어서 편집합니다.

각 사용자에 대한 행이 있으며 MeetingPrivilege 열에는 세션 유형 ID가 쉼표로 분리된 목록으로 포함되어 있습니다.

7

새 세션 유형을 부여하려는 각 사용자의 경우 1561 셀의 쉼표로 분리된 목록에 새 값으로 MeetingPrivilege 추가합니다.

Webex CSV 파일 형식 참조 CSV 파일 의 목적 및 내용에 대한 세부 정보를 포함합니다.

8

Control Hub에서 미팅 사이트 구성 목록을 엽니다.


 

이미 미팅 사이트 목록 페이지에 있는 경우 새로 고침을 해야 할 수도 있습니다.

9

라이센스 및 사용자 섹션에서 일괄 관리를 클릭합니다.

10

가져오기를 클릭하고 편집한 CSV를 선택한 후 가져오기를 클릭합니다. 파일이 업로드되는 동안 기다립니다.

11

가져오기가 완료되면 결과 가져오기를 클릭하여 오류가 있는지 검토할 수 있습니다.

12

사용자 페이지로 이동하고 사용자 중 하나를 열어 새 세션 유형이 있는지 확인합니다.

미팅 녹화에 워터마크를 추가할 수 있습니다. Webex Meetings Pro-End to End Encryption_VOIPonly 세션 유형을 사용하면 기밀 미팅의 인증되지 않은 녹화의 소스 클라이언트 또는 장치를 식별할 수 있습니다.

이 기능이 활성화되면 미팅 오디오에는 각 참여 클라이언트 또는 장치에 대한 고유한 식별자가 포함됩니다. 오디오 녹화를 Control Hub에 업로드한 후 녹화를 분석하고 고유한 식별자를 조회할 수 있습니다. 결과를 확인하여 어떤 소스 클라이언트 또는 장치가 미팅을 녹화했는지 확인할 수 있습니다.

  • 분석하려면 녹화가 500MB 이하의 AAC, MP3, M4A, WAV, MP4, AVI 또는 MOV 파일이어야 합니다.
  • 녹화는 100초 이상이어야 합니다.
  • 조직의 사용자가 호스트하는 미팅에 대한 녹화만 분석할 수 있습니다.
  • 워터마크 정보는 조직의 미팅 정보와 동일한 기간 동안 유지됩니다.
E2EE 미팅에 오디오 워터마크 추가
  1. Control Hub에 로그인한 후 관리 아래에서 조직 설정을 선택합니다.
  2. 에서 미팅 워터마크 섹션, 토글 오디오 워터마크 추가 .

    이 토글이 켜진 후 잠시 후에 사용자는 Webex Meetings Pro-End to End Encryption_VOIPonly 세션 유형은 보안 섹션에서 디지털 워터마킹 옵션을 참조하십시오.

워터마크된 미팅 업로드 및 분석
  1. Control Hub에서 모니터링 , 선택 문제 해결 .
  2. 클릭 워터마크 분석 .
  3. 목록에서 미팅을 검색하거나 선택한 후 분석을 클릭합니다.
  4. 에서 오디오 워터마크 분석 창에서 분석의 이름을 입력합니다.
  5. (선택 사항) 분석에 대한 메모를 입력합니다.
  6. 분석할 오디오 파일을 드래그 앤 드롭하거나 파일 선택 을(를) 클릭하여 오디오 파일을 찾습니다.
  7. 닫기를 클릭합니다.

    분석이 완료되면 결과 목록에 표시됩니다. 워터마크 분석 페이지.

  8. 목록에서 미팅을 선택하여 분석 결과를 확인합니다. 클릭Download button결과를 다운로드합니다.
기능 및 제한 사항

녹화된 워터마크를 성공적으로 디코딩하는 데 관련된 요소에는 녹화 장치와 스피커가 오디오를 출력하는 거리, 해당 오디오의 볼륨, 환경 소음 등이 포함됩니다. 워터마킹 기술은 미디어가 공유될 때 발생할 수 있는 것처럼 여러 번 인코딩될 수 있는 추가적인 복원력을 갖추고 있습니다.

이 기능은 광범위하지만 합리적인 환경에서 워터마크 식별자를 성공적으로 디코딩할 수 있도록 설계되었습니다. 우리의 목표는 개인 엔드포인트 또는 노트북 클라이언트 근처의 책상에 누워있는 휴대 전화와 같은 녹음 장치를 항상 성공적인 분석으로 이어지는 녹음을 생성하는 것입니다. 녹음 장치가 소스에서 멀리 이동되거나 전체 오디오 스펙트럼이 들리지 않으면 성공적인 분석의 기회가 줄어듭니다.

녹화를 성공적으로 분석하려면 미팅 오디오를 합리적인 수준으로 캡처해야 합니다. 클라이언트를 호스트하는 동일한 컴퓨터에 미팅의 오디오가 녹화된 경우, 제한 사항이 적용되지 않습니다.

장치가 이미 Control Hub 조직에 등록되어 있고 Webex CA를 사용하여 식별 인증서를 자동으로 생성하려는 경우, 장치를 팩토리 설정 하지 않아도 됩니다.

이 절차는 장치가 자신을 식별하는 데 사용하는 도메인을 선택하며 Control Hub 조직에 여러 도메인이 있는 경우에만 필요합니다. 도메인이 두 개 이상인 경우 "Cisco가 확인한" ID를 갖게 될 모든 장치에 대해 이 작업을 수행하는 것이 좋습니다. Webex 에서 장치를 식별하는 도메인을 지정하지 않는 경우, 도메인이 자동으로 선택되며, 다른 미팅 참가자에게 잘못 표시될 수 있습니다.

시작하기 전에

장치가 아직 온보딩되지 않은 경우 다음을 따르십시오. API 또는 로컬 웹 인터페이스를 사용하여 Cisco Webex 에 장치 등록 또는 Board, Desk 및 Room 시리즈에 대한 클라우드 온보딩 . 또한 장치를 식별하는 데 사용할 도메인을 확인해야 합니다. 도메인 관리 .

1

Control Hub에 로그인 , 및 아래 관리 , 선택 장치 .

2

장치를 선택하여 구성 목록을 엽니다.

3

이 장치를 식별하는 데 사용할 도메인을 선택합니다.

4

다른 장치에 대해 반복합니다.

시작하기 전에

수행해야 할 작업:

  • CA 서명된 인증서 및 개인 키를 가져오려면 .pem 각 장치에 대해 형식을 지정합니다.

  • 이 문서의 준비 부분에서 장치에 대한 외부 ID 프로세스 이해 항목을 읽습니다.

  • 해당 정보와 관련하여 JWE 암호화 도구를 준비합니다.

  • 지정된 길이의 무작위 바이트 시퀀스를 생성하는 도구입니다.

  • 바이트 또는 텍스트를 base64url로 인코딩하는 도구입니다.

  • 하나의 scrypt 구현

  • 각 장치에 대한 암호 단어 또는 구문입니다.

1

장치의 ClientSecret 을(를) 일반 텍스트 암호로 채웁니다.

처음 채우는 경우 Secret 일반 텍스트로 제공합니다. 따라서 물리적 장치 콘솔에서 이 작업을 수행하는 것이 좋습니다.

  1. Base64url은 이 장치에 대한 암호 문구를 인코딩합니다.

  2. 장치에서 TShell을 엽니다.

  3. 실행하여 xcommand Security ClientSecret Populate Secret: "MDEyMzQ1Njc4OWFiY2RlZg"

    위의 예제 명령을 실행하면 Secret 구문으로 채웁니다 0123456789abcdef. 직접 선택해야 합니다.

장치에는 초기 암호가 있습니다. 이것을 잊지 마십시오. 복구할 수 없으며 다시 시작하려면 장치를 공장 초기화해야 합니다.
2

인증서 및 개인 키 연결:

  1. 텍스트 편집기를 사용하여 .pem 파일을 열고 키 blob를 인증서 blob에 붙여넣고 새 .pem 파일로 저장합니다.

    (이는 암호화하여 JWE blob에 넣을 페이로드 텍스트입니다)

3

인증서 추가 명령에 대한 입력으로 사용할 JWE blob를 생성합니다.

  1. 최소 4바이트의 무작위 시퀀스를 생성합니다. 이것이 솔트입니다.

  2. scrypt 도구를 사용하여 콘텐츠 암호화 키를 파생합니다.

    이를 위해 선택한 암호화 암호와 일치하는 암호, 솔트 및 키 길이가 필요합니다. 제공할 다른 고정 값이 있습니다(N=32768, r=8, p=1). 장치는 동일한 프로세스 및 값을 사용하여 동일한 콘텐츠 암호화 키를 파생합니다.

  3. 정확히 12바이트의 무작위 시퀀스를 생성합니다. 이것이 초기화 벡터입니다.

  4. JOSE 헤더를 생성합니다 alg, enc, 및 cisco-kdf장치에 대한 외부 ID 프로세스 이해에 설명된 대로 키를 key:value를 사용하여 "추가" 작업을 설정 "cisco-action":"add" JOSE 헤더에서(인증서를 장치에 추가하고 있기 때문).

  5. Base64url은 JOSE 헤더를 인코딩합니다.

  6. 선택한 암호 및 base64url로 인코딩된 JOSE 헤더와 함께 JWE 암호화 도구를 사용하여 연결된 pem 파일의 텍스트를 암호화합니다.

  7. Base64url은 초기화 벡터, 암호화된 PEM 페이로드 및 인증 태그를 인코딩합니다.

  8. 다음과 같이 JWE blob를 구성합니다(모든 값은 base64url로 인코딩됨).

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4

장치에서 TShell을 열고 (여러 라인) 추가 명령을 실행합니다.

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로 해당 시퀀스를 인코딩합니다. 이것이 솔트입니다.

  3. scrypt 도구를 사용하여 콘텐츠 암호화 키를 파생합니다.

    이를 위해 선택한 암호화 암호와 일치하는 암호, 솔트 및 키 길이가 필요합니다. 제공할 다른 고정 값이 있습니다(N=32768, r=8, p=1). 장치는 동일한 프로세스 및 값을 사용하여 동일한 콘텐츠 암호화 키를 파생합니다.

  4. 정확히 12바이트의 무작위 시퀀스를 생성하고 base64url로 해당 시퀀스를 인코딩합니다. 이것이 초기화 벡터입니다.

  5. JOSE 헤더를 생성합니다 alg, enc, 및 cisco-kdf장치에 대한 외부 ID 프로세스 이해에 설명된 대로 키를 key:value를 사용하여 "활성화" 작업을 설정 "cisco-action":"activate" JOSE 헤더에서 (장치에서 인증서를 활성화하고 있기 때문에)

  6. Base64url은 JOSE 헤더를 인코딩합니다.

  7. 선택한 암호 및 base64url로 인코딩된 JOSE 헤더와 함께 JWE 암호화 도구를 사용하여 인증서 지문을 암호화합니다.

    도구는 128 또는 256비트 AES-GCM 및 인증 태그의 선택 여부에 따라 16 또는 32바이트 시퀀스를 출력해야 합니다.

  8. Base64url은 암호화된 지문과 인증 태그를 인코딩합니다.

  9. 다음과 같이 JWE blob를 구성합니다(모든 값은 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

호스트로서 이 장치가 올바른 ID 아이콘과 함께 로비에 나타나는지 확인합니다.

5

외부 CA에서 확인된 ID가 있는 장치에서 미팅에 참여합니다.

6

호스트로서 이 장치가 올바른 ID 아이콘과 함께 로비에 나타나는지 확인합니다. ID 아이콘에 대한 자세한 내용.

7

인증되지 않은 미팅 참가자로 미팅에 참여합니다.

8

호스트로서 이 참가자가 올바른 ID 아이콘과 함께 로비에 나타나는지 확인합니다.

9

호스트로서 사용자 / 장치를 허용하거나 거절합니다.

10

가능한 경우 인증서를 확인하여 참가자/장치 ID를 확인합니다.

11

미팅에 있는 모든 사람들에게 동일한 미팅 보안 코드가 표시되는지 확인합니다.

12

새 참가자와 미팅에 참여합니다.

13

모든 사람들에게 동일한 새 미팅 보안 코드가 표시되는지 확인합니다.

종단 간 암호화된 미팅을 기본 미팅 옵션으로 설정하거나 일부 사용자에 대해서만 활성화하거나 모든 호스트가 결정할 수 있도록 허용합니까? 이 기능을 사용할 방법을 결정했으면 특히 미팅에서 예상되는 사항 및 제한 사항과 관련하여 이 기능을 사용할 사용자를 준비합니다.

Cisco 또는 다른 사용자가 콘텐츠를 암호 해독하거나 장치를 위장할 수 없는지 확인해야 합니까? 그렇다면 공용 CA의 인증서가 필요합니다. 보안 미팅에는 최대 25개의 장치만 있을 수 있습니다. 이 보안 수준이 필요한 경우 미팅 클라이언트의 참여를 허용하지 않아야 합니다.

보안 장치로 참여하는 사용자의 경우 장치가 먼저 참여하도록 하고 늦게 참여하면 참여하지 못할 수 있다는 사용자 기대치를 설정합니다.

다양한 수준의 ID 확인이 있는 경우 사용자가 인증서 기반 ID 및 미팅 보안 코드로 서로를 확인할 수 있도록 합니다. 참가자가 확인되지 않음으로 나타날 수 있는 상황에서도 참가자는 확인 방법을 알고 있어야 하며 확인되지 않은 사람들은 가짜 참가자가 아닐 수도 있습니다.

외부 CA를 사용하여 장치 인증서를 발급하는 경우 인증서를 모니터링, 새로 고침 및 다시 적용해야 합니다.

초기 암호를 생성한 경우 사용자가 장치의 암호를 변경할 수 있습니다. 이 작업을 수행할 수 있으려면 인터페이스를 생성하거나 도구를 배포해야 할 수 있습니다.

표 1. 종단 간 암호화된 미팅에 대한 세션 유형 ID

세션 유형 ID

공용 서비스 이름

638

E2E Encryption+VoIP only

652

Pro-End to End Encryption_VOIPonly

660

Pro 3 Free-End to End Encryption_VOIPonly

E2E Encryption + Identity

672

Pro 3 Free50-End to End Encryption_VOIPonly

673

Education Instructor E2E Encryption_VOIPonly

676

Broadworks Standard 플러스 종단 간 암호화

677

Broadworks Premium 플러스 종단 간 암호화

681

Schoology Free 플러스 종단 간 암호화

이러한 표에서는 종단 간 암호화된 미팅 및 확인된 ID에 대해 추가한 Webex 장치 API 명령을 설명합니다. API를 사용하는 방법에 대한 자세한 정보는 Webex Room, Desk 장치 및 Webex Board에 대해 API에 액세스를 참조하십시오.

해당하는 xAPI 명령어는 다음 중 하나의 장치에서만 사용할 수 있습니다.

  • Webex에 등록됨

  • 온-프레미스 등록 및 장치용 Webex Edge에 Webex 링크됨

표 2. 종단 간 암호화된 미팅 및 확인된 ID에 대한 시스템 수준 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

외부에서 발급된 인증서의 일반 이름에서 읽은 장치의 ID입니다.

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

장치의 외부 아이덴티티의 상태(예: valid 또는 error).

xStatus Conference EndToEndEncryption InternalIdentity Verification

장치에 Webex CA에서 발급된 유효한 인증서가 있는지 여부를 나타냅니다.

xStatus Conference EndToEndEncryption InternalIdentity Identity

Webex에서 발급된 인증서의 일반 이름에서 읽은 장치의 ID입니다.

조직에 도메인이 있는 경우 도메인 이름을 포함합니다.

조직에 도메인이 없는 경우 비어 있습니다.

도메인이 여러 개 있는 조직에 장치가 속한 경우 이는 PreferredDomain.

xStatus Conference EndToEndEncryption InternalIdentity CertificateChain Certificate # specificinfo

Webex에서 발급한 인증서에서 특정 정보를 확인합니다.

명령어가 나타나면 # 을(를) 인증서의 번호로 교체합니다. 교체 specificinfo 을(를) 다음 중 한 개로:

  • Fingerprint

  • NotAfter 유효 종료 날짜

  • NotBefore 유효 시작 날짜

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

  • Subject # Name 인증서에 대한 제목의 목록 (예: 이메일 주소 또는 도메인 이름)

  • Validity 이 인증서의 유효 상태를 제공합니다(예: valid 또는 expired)

표 3. 종단 간 암호화된 미팅 및 확인된 ID에 대한 호출 API

API 호출

설명

xEvent Conference ParticipantList ParticipantAdded

xEvent Conference ParticipantList ParticipantUpdated

xEvent Conference ParticipantList ParticipantDeleted

이제 이러한 세 가지 이벤트에 다음이 포함됩니다 EndToEndEncryptionStatus, EndToEndEncryptionIdentity, 및 EndToEndEncryptionCertInfo 영향을 받는 참가자

표 4. 종단 간 암호화된 미팅 및 확인된 ID에 대한 클라이언트 암호 관련 API

API 호출

설명

xCommand Security ClientSecret Populate Secret: "base64url-encoded"

또는

xCommand Security ClientSecret Populate Secret: JWEblob

처음에 장치의 클라이언트 암호를 시드하기 위해 base64url로 인코딩된 일반 텍스트 값을 허용합니다.

그 이후에 암호를 업데이트하려면 이전 암호로 암호화된 새 암호를 포함하는 JWE blob를 제공해야 합니다.

xCommand Security Certificates Services Add JWEblob

인증서를 추가합니다(개인 키 포함).

암호화된 PEM 데이터를 포함하는 JWE blob를 허용하도록 이 명령을 확장했습니다.

xCommand Security Certificates Services Activate Purpose:WebexIdentity FingerPrint: JWEblob

Webex ID에 대한 특정 인증서를 활성화합니다. 이 경우 Purpose 명령을 사용하려면 JWE blob에서 식별 지문을 암호화하고 직렬화해야 합니다.

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

Webex ID에 대한 특정 인증서를 비활성화합니다. 이 경우 Purpose 명령을 사용하려면 JWE blob에서 식별 지문을 암호화하고 직렬화해야 합니다.