다음을 통해 공유

라이선스 정책에 대한 모범 사례

  • 아티클

이 섹션에서는 PlayReady 기술을 사용할 때 라이선스 정책을 프로그래밍하는 모범 사례를 설명합니다.

EndDate에서 BeginDate 사용

PlayReady에서 지원하는 많은 비즈니스 모델 중 하나는 콘텐츠 대여입니다. 콘텐츠 대여는 제한된 기간 동안만 사용할 수 있습니다(예: 콘텐츠는 2018년 10월 15일 오후 5시 EST까지 사용할 수 있음). 이 작업은 EndDate가 라이선스가 만료되는 시간과 날짜로 설정된 PlayReady 라이선스를 클라이언트에 발급하여 수행됩니다.

EndDate는 임대 라이선스를 만들기에 충분합니다. 그러나 라이선스에 BeginDate를 포함하는 것이 좋습니다. BeginDate는 지정된 날짜 이전에 연결된 콘텐츠를 사용할 수 없도록 지정합니다. EndDate와 BeginDate의 조합은 사용자가 전체 PlayReady 데이터 저장소를 백업하고 복원하여 클록 롤백 이벤트를 방지하는 클록 롤백 공격에 대한 자연스러운 임피던스입니다.

다음 예제를 참조하세요.

  • 날짜는 08/01/18입니다. 사용자가 Content1에 대한 License1을 획득합니다. License1에 EndDate=08/30/18이 있습니다.

  • 날짜는 09/01/18입니다. 사용자가 Content2용 License2를 획득합니다. License2에 EndDate=09/30/18이 있습니다.

  • 사용자가 PlayReady 데이터 저장소의 복사본을 만듭니다.

  • Content1 또는 Content2를 재생하기 전에 사용자는 시계를 08/01/18로 다시 설정하고 PlayReady 데이터 저장소의 복사본을 복원합니다. 두 콘텐츠 모두 재생할 수 있습니다.

이제 동일한 기본 예제를 고려하지만 라이선스에서 BeginDates를 사용합니다.

  • 날짜는 08/01/18입니다. 사용자가 Content1에 대한 License1을 획득합니다. License1에 BeginDate=08/01/18, EndDate=08/30/18이 있습니다.

  • 날짜는 09/01/18입니다. 사용자가 Content2용 License2를 획득합니다. License2에는 BeginDate=09/01/18, EndDate=09/30/18이 있습니다.

  • 사용자가 PlayReady 데이터 저장소의 복사본을 만듭니다.

  • Content1 또는 Content2를 재생하기 전에 사용자는 08/01/18 이전 날짜로 시계를 다시 설정하고 PlayReady 데이터 저장소의 복사본을 복원합니다. Content1만 재생됩니다.

이 예제에서는 BeginDate가 라이선스 정책을 우회하기 위해 복원되는 데이터 저장소의 타당성을 자연스럽게 줄이는 방법을 보여 줍니다. 사용자는 BeginDate를 해결하기 위해 데이터 저장소의 복사본을 더 많이 만들 수 있지만 콘텐츠 파일 수가 증가함에 따라 라이선스 정책을 해결하는 데 필요한 모든 데이터 저장소의 관리가 비례적으로 증가하여 공격이 훨씬 덜 실현 가능합니다.

요약하자면 PlayReady 라이선스에서 EndDate를 지정하는 경우 BeginDate도 포함하는 것이 좋습니다.

클라이언트에 대해 작동하는 BeginDate 값 설정

라이선스에 BeginDate를 추가할 때 PlayReady 클라이언트 버전 1 또는 2의 경우 과거에 약간 설정하는 것이 좋습니다. 그 이유는 이 라이선스를 생성하는 서버와 라이선스를 수신하는 클라이언트 간에 약간의 시계 차이가 있을 수 있으며, 서버의 의도는 클라이언트가 라이선스를 받는 즉시 클라이언트가 라이선스를 사용할 수 있기 때문입니다.

PlayReady 클라이언트 3 이상의 경우 클라이언트는 라이선스 요청에 따라 해당 시계 값을 라이선스 서버로 보내고, 서버는 라이선스 서버에 알려진 시간 값에 가깝다는 조건 하에 해당 값과 관련하여 BeginDate 및 기타 시간 제한을 설정할 수 있습니다.

PlayReady 클라이언트 버전 2의 일반적인 예는 다음과 같습니다.

  1. 사용자가 PlayReady 2.5에서 빌드된 앱을 실행하는 Android 휴대폰에서 2018년 1월 5일 금요일 오후 8시경에 콘텐츠를 임대합니다.

  2. Android 앱은 라이선스 서버에 대한 라이선스 요청을 시작합니다. 전화 시계는 오후 7시 56분, 라이선스 서버 시계는 8:00PM을 나타냅니다.

  3. 라이선스 서버는 라이선스 요청을 수신하고, 클라이언트가 버전 2임을 감지하고, 다음을 사용하여 라이선스를 생성합니다.

    • 오른쪽 재생

    • 시작 시간 = 로컬 서버 시간 -5분 = 2018년 1월 5일 오후 7:55

    • 만료 시간, 첫 번째 재생 후 만료, 출력 보호와 같은 기타 올바른 제한 사항

    1. 라이선스 서버는 라이선스를 클라이언트로 다시 보냅니다.

    2. 클라이언트가 재생을 시작합니다. 전화 시계는 여전히 7:56PM이며 라이선스의 BeginDate(오후 7시 55분)를 지나서 재생이 실제로 즉시 시작될 수 있습니다.

PlayReady 클라이언트 버전 3의 일반적인 예는 다음과 같습니다.

  1. 사용자가 UWP 앱을 실행하는 Windows 10 컴퓨터에서 2018년 1월 5일 금요일 오후 8시경에 콘텐츠를 대여합니다.

  2. UWP 앱은 라이선스 서버에 대한 라이선스 요청을 시작합니다. PC 클록은 오후 7시 56분, 라이선스 서버 시계는 8:00PM을 나타냅니다.

  3. 라이선스 서버는 라이선스 요청을 받고 PlayReady 클라이언트가 버전 3임을 감지하고 클라이언트 클록의 값을 확인합니다.

    • 클라이언트 클록 값이 라이선스 서버 클록 값보다 1시간 이상 떨어져 있지 않으면 계속 진행하여 라이선스를 생성합니다.

    • 그렇지 않은 경우 라이선스 요청을 거부하고 클라이언트 앱에 메시지를 보내 클록을 올바른 값으로 설정하도록 요청합니다.

  4. 라이선스 서버는 다음을 사용하여 라이선스를 생성합니다.

    • 오른쪽 재생

    • 시작 시간 = 라이선스 요청에 포함된 클라이언트 시간 = 2018년 1월 5일 오후 7:56

    • 만료 시간, 첫 번째 재생 후 만료, 출력 보호와 같은 기타 올바른 제한 사항

    1. 라이선스 서버는 라이선스를 클라이언트로 다시 보냅니다.

    2. 클라이언트가 재생을 시작합니다. PC 시계는 여전히 오후 7시 56분이며 라이선스의 BeginDate(오후 7시 56분)를 같거나 지났으므로 실제로 재생이 즉시 시작될 수 있습니다.

구독 라이선스의 시간 제한

PlayReady는 사용자가 서비스에서 제공하는 대규모 콘텐츠 카탈로그에 액세스하는 대가로 월별 요금을 지불하는 구독 비즈니스 모델을 지원합니다.

이 시나리오에서 PlayReady 라이선스 서버는 각 콘텐츠 파일에 대한 리프 라이선스와 단일 루트 라이선스를 발급합니다. PlayReady가 콘텐츠에 액세스하려면 리프 라이선스와 루트 라이선스(라이선스 체인)가 모두 필요합니다. 두 라이선스 모두 콘텐츠(예: 재생)에서 수행되는 작업을 포함해야 하며 두 라이선스가 모두 유효해야 합니다(만료되지 않음 등).

특정 콘텐츠 카탈로그에 대한 루트 라이선스가 하나만 있고 잠재적으로 수백 또는 수천 개의 리프 라이선스가 있기 때문에 리프 라이선스에는 거의(있는 경우) 제한이 포함되어야 하며, 루트 라이선스에는 시간 제한이 포함되어야 하며 정기적으로 새로 고쳐야 합니다(예: 매월). 구독이 만료되는 경우 라이선스 서버는 하나의 라이선스만 발급하면 되며 모든 콘텐츠는 새 유효 만료 날짜로 업데이트됩니다. 리프 라이선스의 정책에 시간 기반 정책이 포함된 경우 콘텐츠가 만료되지 않도록 모든 리프 라이선스를 다시 발급해야 하며 이는 서버에 대한 큰 성능 요구 사항입니다.

요약하면 라이선스 체인을 사용하여 콘텐츠가 만료되는 경우 루트 라이선스만 시간 기반 정책을 포함해야 합니다.