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

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

ID 확인

종단 간 ID 인증을 통해 종단 간 암호화된 미팅의 보안을 강화할 수 있습니다.

참가자 또는 장치는 공유 MLS(Messaging Layer Security) 그룹에 참여할 때 다른 그룹 멤버에게 인증서를 제공한 후 발급 CA(인증 기관)에 대해 인증서의 유효성을 검사합니다. CA는 인증서가 유효한지 확인하는 방식으로 참가자의 ID를 확인하며 미팅에는 참가자 / 장치가 확인됨으로 표시됩니다.

Webex Meetings 앱의 사용자는 성공 시 액세스 토큰을 발급하는 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 Meetings에 대한 ID 인증으로 종단 간 암호화에 설명된 대로 Webex 미팅 사용자 인터페이스에 표시됩니다.

장치별로 개별 인증서와 고유한 CN을 사용하는 것이 좋습니다. 예를 들어 “example.com” 도메인을 소유한 조직의 경우 “meeting-room-1.example.com”일 수 있습니다.

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

클라이언트 암호를 사용할 경우 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 앱은 종단 간 암호화된 미팅에 참여할 수 없습니다.

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

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

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

ID

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

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

미팅

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

  • 이러한 200명의 참가자 중 최대 25개의 외부에서 확인된 장치가 참여할 수 있으며 이 장치는 미팅에 참여하는 첫 번째 참가자여야 합니다.

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

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

관리 인터페이스

Control Hub를 사용하여 미팅 사이트를 관리하는 것이 좋습니다.

이에 대한 주된 이유는 Control Hub와 사이트 관리가 ID를 관리하는 방법의 차이에 있습니다. Control Hub 조직에는 전체 조직에 대한 중앙 집중식 ID가 있지만 사이트 관리에서는 ID가 사이트별로 제어됩니다.

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

관련 정보

샘플 JWE blob 추출

지정된 파라미터에 따라 올바르게 암호화된 JWE의 샘플(부록)

  • Webex Meetings 41.7.

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

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

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

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

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

디지털 인증서를 요청, 구입 및 수신하고 연결된 개인 키를 생성하려면 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를 사용하기 위해 업그레이드하려는 기존 장치가 있는 경우 장치를 공장 초기화해야 합니다.

  • 유지하려는 기존 구성은 저장합니다.

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

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

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

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

  • 인증서를 요청합니다.

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

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

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

    아래에서는 필요한 프로세스 및 (비암호) 파라미터와 선택한 개발 도구에서 따라야 할 레시피를 설명합니다. 또한 프로세스를 확인하는 데 도움이 되도록 일부 테스트 데이터와 결과 JWE blob를 예상대로 제공합니다.

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

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

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

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

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

JWE 형식을 사용하는 방법

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

JWE(JSON Web Encryption)https://datatracker.ietf.org/doc/html/rfc7516JWS(JSON Web Signature)https://datatracker.ietf.org/doc/html/rfc7515를 참조해야 합니다.

JSON 문서의 압축 직렬화를 사용하여 JWE blob를 생성하도록 선택했습니다. 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 암호문: 이는 비밀로 유지하려는 암호화된 페이로드입니다.

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

    장치에서 수행하려는 작업에 따라 다양한 유형의 페이로드가 있습니다. 다른 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 Counter Mode에서 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

사이트 이름을 클릭하여 사이트의 구성 목록을 엽니다.

3

사이트 구성을 클릭합니다.

4

공통 설정 영역에서 세션 유형을 클릭합니다.

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

 

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

향후에 이러한 세션 유형에 대한 공용 서비스 이름을 변경할 수 있습니다. 예를 들어 Pro-End to End Encryption_VOIPonlyE2E Encryption + Identity로 변경할 예정입니다.

5

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

다음에 수행할 작업

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

1

사용자를 클릭하고 사용자를 선택하여 사용자의 구성 목록을 엽니다.

2

서비스 영역에서 Cisco Webex Meetings를 클릭합니다.

3

사이트(사용자가 둘 이상인 경우)를 선택하고 호스트를 클릭합니다.

4

Pro-End to End Encryption_VOIPonly라는 Webex Meetings 항목 옆에 있는 확인란을 선택합니다.

5

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

6

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

여러 사용자에게 이 옵션을 지정하려는 경우 CSV 일괄 옵션을 사용합니다.

1

https://admin.webex.com에서 Control Hub에 로그인하고 미팅 페이지를 엽니다.

2

사이트 이름을 클릭하여 사이트 구성 목록을 엽니다.

3

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

4

내보내기를 클릭하고 파일을 준비하는 동안 기다립니다.

5

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

6

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

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

7

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

https://help.webex.com/en-us/5vox83의 CSV 파일 형식 참조에는 CSV 파일의 목적과 내용에 대한 일부 세부 정보가 있습니다.

8

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

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

9

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

10

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

11

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

12

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

장치가 이미 Control Hub 조직에 등록되어 있으며 Webex CA를 사용하여 식별 인증서를 자동 생성하려는 경우 장치를 공장 초기화할 필요가 없습니다.

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

시작하기 전에

장치가 아직 등록되지 않은 경우 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에서 서명한 인증서 및 개인 키를 얻습니다.

  • 이 문서의 준비 부분에서 장치에 대한 외부 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, enccisco-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, enccisco-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).

https://help.webex.com/nsj2xpfb을(를) 참조하십시오.

2

Webex Meetings 클라이언트에서 호스트로 미팅에 참여합니다.

3

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

4

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

5

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

6

호스트로서 이 장치가 올바른 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 사용 방법에 대한 자세한 내용은 https://help.webex.com/nzwo1ok을(를) 참조하십시오.

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

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

xStatus Conference EndToEndEncryption ExternalIdentity CertInfo

외부에서 발급된 인증서에서 인증서 정보를 읽고 JSON blob로 출력합니다.

xStatus Conference EndToEndEncryption InternalIdentity Valid

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

xStatus Conference EndToEndEncryption InternalIdentity Identity

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

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

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

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

xStatus Conference EndToEndEncryption InternalIdentity CertInfo

Webex에서 발급된 인증서에서 인증서 정보를 읽고 JSON blob로 출력합니다.

표 3. 종단 간 암호화된 미팅 및 확인된 ID에 대한 호출 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

MLS(Messaging Layer Security)에 사용되는 암호화 암호를 읽습니다.

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:

지정된 참가자의 기본 ID입니다(일반적으로 도메인(장치) 또는 이메일 주소(사용자)).

xStatus Conference Call # EndToEndEncryption Roster Participant # DisplayName:

지정된 참가자의 표시 이름입니다. 참가자/장치에서 서명합니다.

xStatus Conference Call # EndToEndEncryption Roster Participant # CertInfo:

지정된 참가자의 인증서에서 JSON blob로서 인증서 정보입니다.

xCommand Conference ParticipantList Search

참가자에 대한 종단 간 암호화 정보를 포함하도록 이 명령을 확장했습니다.

xCommand Conference ParticipantList Search

이제 참가자 목록 검색에는 다음이 포함됩니다 EndToEndEncryptionStatus 참가자의 ID 확인 상태. 이 값은 UI에 표시됩니다.

xCommand Conference ParticipantList Search

이제 참가자 목록 검색에는 다음이 포함됩니다 EndToEndEncryptionIdentity 참가자의 기본 ID 이는 일반적으로 도메인 또는 이메일 주소입니다. 이 값은 UI에 표시됩니다.

xCommand Conference ParticipantList Search

이제 참가자 목록 검색에는 다음이 포함됩니다 EndToEndEncryptionCertInfo 참가자의 인증서를 포함하는 JSON blob 이 값은 UI에 표시됩니다.

xEvent Conference ParticipantList Participant(Added)

xEvent Conference ParticipantList Participant(Updated)

xEvent Conference ParticipantList Participant(Deleted)

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

표 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에서 식별 지문을 암호화하고 직렬화해야 합니다.