콘텐츠 패키징 및 배달
PlayReady의 기본 기능은 무단 사용으로부터 콘텐츠를 보호하는 것입니다. 이렇게 하려면 먼저 콘텐츠를 암호화하고 연결된 PlayReady 헤더를 콘텐츠에 삽입해야 합니다. 이 작업을 수행하는 시스템은 때때로 인코더와 통합되는 암호화자라고도 하는 패키지입니다.
이 항목에서는 PlayReady를 사용하여 콘텐츠를 암호화하고 전달하는 다양한 방법을 설명합니다.
PlayReady 콘텐츠 패키징 - DRM 헤더 암호화 및 삽입
명확한 콘텐츠를 암호화하는 프로세스는 하나 또는 여러 개의 암호화 키를 정의하고, 이러한 키를 사용하여 콘텐츠 자체를 구성하는 바이트를 암호화하고, 콘텐츠의 파일 또는 콘텐츠가 있는 경우 매니페스트에 DRM 헤더를 삽입하는 것으로 구성됩니다.
PlayReady로 보호되는 모든 암호화된 콘텐츠에는 암호화된 파일에 PlayReady 헤더가 삽입되어 있어야 합니다. 이 PlayReady 헤더는 PlayReady 클라이언트에서 특정 콘텐츠에 대한 라이선스를 찾거나 획득하는 데 사용됩니다. PlayReady 헤더는 UTF-16으로 인코딩된 XML로 구성됩니다. 여기에는 콘텐츠를 암호화하는 데 사용되는 KID(키 식별자), 다른 항목이 제공되지 않은 경우 클라이언트가 라이선스를 획득하는 데 사용할 기본 URL 및 사용자 지정 특성이 포함됩니다.
콘텐츠를 지우는 패키지는 헤더를 빌드하고 암호화된 콘텐츠에 포함하기 위해 PlayReady 헤더 생성기를 구현해야 합니다. PlayReady 헤더는 PlayReady 헤더 사양에 따라 구현되어야 합니다. 패키지에서 PlayReady 헤더 생성기를 만드는 방법에는 여러 가지가 있습니다.
- PlayReady 헤더 사양에 따라 직접 개발합니다.
- PlayReady 헤더를 생성하는 PlayReady 서버 SDK API를 사용합니다.
- PlayReady 헤더를 생성하는 Windows 10 API를 사용합니다.
암호화된 콘텐츠에는 타사 DRM 헤더와 함께 PlayReady 헤더를 비롯한 여러 DRM 헤더가 포함될 수 있습니다. 이 작동 방식에 대한 자세한 내용은 암호화 도구 사용을 참조하세요.
콘텐츠 유형
PlayReady를 사용하여 오디오 및 비디오 콘텐츠를 보호할 수 있습니다. PlayReady에서 사용되는 인코딩의 가장 일반적인 유형은 MPEG-4 AVC(H.264), HEVC(고효율 비디오 코딩) H.265 표준 및 AV1 표준입니다. PlayReady는 이러한 표준에 국한되지 않으며 클라이언트 디바이스에서 지원되는 오디오 및 비디오 형식과 함께 사용할 수 있습니다.
PlayReady 버전 1 및 2를 사용하면 오디오 또는 비디오 페이로드로 제한되지 않는 콘텐츠가 포함된 보호된 패키지를 만들 수 있습니다. 봉투라고 하는 이러한 패키지에는 데이터 파일 및 실행 파일 컬렉션(예: 애플리케이션 저장소에서 배포하는 애플리케이션), 그림(예: 화면 배경 화면) 또는 전자책과 같은 파일이 포함될 수 있습니다. 이 콘텐츠는 파일을 봉투 파일에 캡슐화하여 패키지됩니다. 이 파일은 오디오/비디오 콘텐츠와 유사한 방식으로 해독할 수 있습니다.
이러한 비 오디오/비디오 콘텐츠 형식은 PlayReady 3.0 이상에서 더 이상 지원되지 않습니다.
암호화 도구
Microsoft는 PlayReady 결과물의 일부로 패키지자를 포함하지 않습니다. 대신 PlayReady는 인코더에서 사용하기 위한 일반적인 암호화 표준을 기반으로 하는 사양을 제공합니다. 따라서 암호화 형식은 PlayReady에 한정되지 않고 파일 형식의 함수입니다. 오늘날 가장 널리 사용되는 암호화 형식은 일반 암호화 ISO 표준 형식인 ISO/IEC 23001-7입니다.
기본적으로 사용자 고유의 패키지러를 만들거나 모든 유형의 오픈 소스 암호화기(예: ffmpeg)로 작업할 수 있습니다. 또한 PlayReady(예: 하모닉, 요소, 에릭슨, 와우자, 알레그로)를 사용하여 콘텐츠를 암호화하려는 경우 전문 인코더 회사와 함께 작업할 수 있습니다. Azure Media Services 명확한 콘텐츠에 대한 패키징 기능도 제공합니다.
암호화 도구 사용
PlayReady는 ISO IEC 일반 암호화 표준을 지원합니다. 이 프로세스는 기본 암호화 및 라이선스 프로세스에서 설명한 것과 동일합니다. 단, 헤더는 다른 DRM에 포함됩니다. 각 헤더는 해당 DRM의 SystemID로 식별되는 보호 시스템 특정 헤더('pssh') 상자의 페이로드로 포함됩니다. 이러한 모든 헤더에는 궁극적으로 콘텐츠 키에 액세스하는 데 필요한 KID 또는 정보를 지정하는 고유한 구문이 있습니다. 또한 이 자산의 콘텐츠 키는 모든 DRM에 대해 동일합니다.
암호화 키 사용
자산을 암호화하는 방법에는 여러 가지가 있습니다. 가장 정교한 것 중 가장 간단한 것은 시스템에서 디자인하려는 복잡성과 서비스의 요구 사항에 따라 달라집니다.
예를 들어 아래 그림과 같이 적응 스트리밍 자산을 살펴보겠습니다. 그것은 네 가지 비디오 자질, 하나의 오디오 트랙, 하나의 자막 트랙이 있습니다. 세그먼트가 각각 2.0초인 분할된 MP4 파일로 인코딩됩니다. 클라이언트가 재생하려는 항목에 따라 여러 형식으로 제공되는 하나의 자산입니다. 부드러운 스트리밍, HLS 및 DASH가 가장 일반적인 변형입니다. 재생 중에 클라이언트(비디오 플레이어)는 네트워크 대역폭, 재생 속도 및 플레이어 기능과 같은 기타 제한된 리소스의 제약을 감안할 때 재생 품질을 가능한 한 높게 유지하기 위해 적절한 비디오 트랙에서 비디오 세그먼트를 각 재생 시간에 대해 선택하여 네트워크를 통해 자산 세그먼트를 연속적으로 다운로드합니다. 이 논리를 적응 스트리밍 재생이라고 하며 플레이어에서 구현된 일부 추론 규칙에 의해 제어됩니다.
하나의 키로 자산 암호화
이러한 자산을 암호화하는 가장 간단한 방법은 단일 콘텐츠 키를 사용하여 모든 항목을 암호화하는 것입니다(일반적으로 자막은 암호화되지 않습니다. 규칙에 위배되지는 않지만 일반적으로 명확하게 유지됨). 라이선스 서버가 하나의 키 {KID, CK}을(를) 제공해야 하므로 하나의 콘텐츠 키를 사용하면 라이선스 서버의 수명이 쉬워집니다. 이 키는 일반적으로 재생이 발생하기 전에 클라이언트에서 획득합니다.
참고
PlayReady 클라이언트는 사전에 또는 사후적으로 라이선스를 획득할 수 있습니다. 이러한 두 모드에 대한 설명은 라이선스 취득 페이지를 참조하세요.
두 개의 키로 자산 암호화, 최고 품질에 1개 헌정
지난 몇 년 동안 자산당 여러 키를 사용하는 몇 가지 개선 사항이 있었는데, 주로 특정 최고 견고성 클라이언트만 최고 품질의 콘텐츠를 소비할 수 있도록 하기 위한 요구 사항에 의해 좌우됩니다. Ultra HD(4K) 콘텐츠가 등장하고 더 높은 색 콘텐츠를 위한 HDR(고동역폭)이 추가된 상황에서 스튜디오와 서비스는 일반적으로 하드웨어 DRM이 내장된 특정 클라이언트에서만 최고 품질을 허용해야 했습니다. 이 시나리오에서 자산은 다른 콘텐츠 키 {kid2, ck2}를 사용하여 암호화된 4K 트랙을 제외하고 모든 트랙에 대해 하나의 콘텐츠 키 {kid1, ck1}을 사용하여 암호화됩니다. 구체적인 요건은 다음과 같습니다.
- 전체 HD(4K 트랙 아님)까지만 재생할 수 있는 클라이언트는 {kid1, ck1}만 포함한 PlayReady 라이선스를 제공합니다.
- 최대 4K까지 플레이할 수 있는 클라이언트에는 {kid1, ck1} 및 {kid2, ck2}를 포함한 PlayReady 라이선스가 제공됩니다.
이 추가 복잡성을 사용하여 서비스는 일부 클라이언트가 4K 트랙의 암호를 해독할 수 없으며 서비스가 가장 신뢰하는 클라이언트에만 4K 트랙을 예약할 수 있도록 할 수 있습니다.
트랙당 하나의 키로 자산 암호화
서비스에 적용할 권한의 더 복잡한 맵이 있을 수 있습니다. 일부 클라이언트는 화면 크기, 견고성, 출력 및 위치에 따라 일부 비디오 트랙, 일부 비디오 품질 및 일부 오디오 트랙에만 액세스할 수 있습니다. 서비스가 향후 임의 제한 집합을 유연하게 적용할 수 있도록 각 트랙에 특정한 콘텐츠 키를 사용하여 자산을 암호화할 수 있습니다. 예를 들어:
- 720p만 플레이할 수 있는 클라이언트는 {kid1, ck1}, {kid2, ck2} 및 {kidA, ckA}를 포함한 PlayReady 라이선스를 제공합니다.
- 최대 4K까지 플레이할 수 있는 클라이언트에는 {kid1, ck1}, {kid2, ck2}, {kid3, ck3}, {kid4, ck4}, {kidA, ckA}를 포함한 PlayReady 라이선스가 제공됩니다.
- 4K 버전의 자산을 오프라인으로 플레이하는 클라이언트(이전에 다운로드됨)에는 {kid4, ck4} 및 {kidA, ckA}를 포함한 PlayReady 라이선스가 제공됩니다.
암호화 키를 주기적으로 변경(다중 기간 자산) - 라이선스 회전
일부 시나리오에서 서비스는 일반적으로 프로그램 경계에서 암호화 키를 변경하려고 합니다. 예를 들어 라이브 선형 스트림에는 모든 사용자가 액세스할 수 있는 무료 방송 콘텐츠와 구독자로 제한되는 일부 콘텐츠가 있는 여러 기간이 있습니다. 프로그램 경계에서 암호화 키를 변경하면 서비스에서 제한 없이 모든 사용자에게 무료 대기 키 {KIDi1, CKi1}를 제공하고, 서비스에 성공적으로 로그인한 구독자에게만 콘텐츠 키 {kidi2, cki2}를 제공할 수 있습니다.
이 라이선스 회전은 매우 확장성이 없습니다. 암호화 키가 변경 될 때마다 모든 클라이언트는 자체 라이선스 요청을 사용하여 새 암호화 키를 요청합니다. 이로 인해 클라이언트 수가 많은 시스템에서 라이선스 요청이 최고조에 달할 수 있습니다.
암호화 키 자주 변경 - 확장 가능한 키 회전
PlayReady에는 확장 가능한 키 회전이라는 고급 메커니즘이 있습니다(라이선스 회전과 반대). 이 메서드는 실제 콘텐츠 스트림에 ELS(Embedded License Microsoft Store)를 저장합니다. 이 메커니즘에서 A2 세그먼트 자체를 암호화하는 데 사용되는 키를 리프 키 {kidA2, ckA2}라고 하며, 루트 키 {kidRA, ckRA}라고 하는 트랙 A의 모든 세그먼트에 대해 동일한 별도의 키로 자체 암호화되는 세그먼트 A2의 ELS에 전달됩니다. MPEG-2 TS 및 Control Word 암호화에 익숙한 경우 암호화가 훨씬 더 강력하고 더 유연하다는 점을 제외하면 유사한 메커니즘입니다.
이 자산이 라이브 선형 TV라고 가정해 보겠습니다. 클라이언트가 재생을 시도하면 스트림 매니페스트의 PlayReady 헤더에서 kidRA를 찾고 kidRA에 대한 라이선스를 요청합니다. 라이선스 서버는 루트 키 {kidRA, ckRA}에 대한 루트 라이선스를 반환합니다. 그런 다음 클라이언트는 세그먼트 A1을 구문 분석하고 세그먼트의 헤더에서 ELS를 검색합니다. 이 ELS를 구문 분석하면 이 ELS에서 리프 라이선스 {kidA1, ckA1}을 찾습니다. 루트 키 {kidRA, ckRA} 및 리프 라이선스 {kidA1, ckA1}을 사용하여 ckA1 값을 얻고 세그먼트 A1의 암호를 해독하고 렌더링할 수 있습니다.
PlayReady 확장 가능한 키 회전 기능은 암호화 키가 변경 될 때마다 클라이언트가 라이선스 서버에 연결할 필요가 없기 때문에 매우 확장 가능합니다. 클라이언트는 스트림당 라이선스 서버에서 하나의 루트 라이선스만 필요하거나 추적하면 되므로 라이선스 요청 볼륨을 가능한 가장 낮은 수준으로 유지합니다. 암호화 키를 모든 세그먼트만큼 자주 회전할 수 있으며, 일반적으로 필요한 경우 2초마다 회전할 수 있습니다.
