Mode Enkripsi Konten PlayReady

Topik ini memberikan gambaran umum tentang mode enkripsi konten di sistem PlayReady. Untuk gambaran umum tentang PlayReady dan enkripsi konten, lihat Enkripsi Konten PlayReady. Lihat Glosarium untuk istilah dan definisi enkripsi.

PlayReady versi 1.0 memperkenalkan mode enkripsi konten AES-128 CTR, selain mode enkripsi COCKTAIL khusus Microsoft yang sebelumnya digunakan dalam WMDRM (Windows Media Digital Rights Management). Mode enkripsi konten AES-128 CTR menggunakan kunci AES, dengan panjang 128 bit yang digunakan pada file konten dalam Mode Penghitung (CTR).

Dimulai dengan versi 4.0, sistem PlayReady mendukung kunci AES 128 bit dalam mode Counter Mode (CTR) dan Cipher Block Chaining (CBC).

Perubahan ini memastikan bahwa layanan yang menggunakan PlayReady dapat sepenuhnya memanfaatkan aliran unik dan format file di semua perangkat. Selain itu, Microsoft mendukung standar CMAF (Common Media Application Format), seperti yang didefinisikan dalam ISO/IEC FDIS 23000-19.

Mode Enkripsi Umum

ISO/IEC standar ISO 23001-7 mendefinisikan empat mode Enkripsi Umum.

Klien PlayReady yang dimulai dengan versi 4.0 mendukung kunci CBC AES, yang memungkinkan dukungan untuk mode Enkripsi Umum 'cbcs', selain kunci AES CTR untuk mode Enkripsi Umum 'cenc'. Sebelum versi 4.0, AES CTR adalah mode yang terutama didukung oleh Klien PlayReady, yang memungkinkan dukungan untuk mode Enkripsi Umum 'cenc'. Perhatikan bahwa mode Enkripsi Umum 'cens' dan 'cbc1' diizinkan dan dapat dilakukan secara teknis dalam ekosistem PlayReady, tetapi tidak didukung.

Dukungan untuk Skema Enkripsi AES-CBC 'cbcs'

Semua klien yang dibangun di atau setelah PlayReady PK versi 4.0 dapat mendukung kunci CBC. Dukungan bersifat opsional untuk klien, dan disinyalir ke Server Lisensi melalui properti tambahan dalam protokol akuisisi lisensi.

Versi	KOKTAIL	'cenc'	cbcs
PlayReady Client 1.0	Didukung	Didukung	tidak didukung
PlayReady Client 2.0	Didukung	Didukung	tidak didukung
PlayReady Client 2.5	Didukung	Didukung	tidak didukung
PlayReady Client 3.0	tidak didukung	Didukung	tidak didukung
Klien PlayReady 3.3	tidak didukung	Didukung	tidak didukung
PlayReady Client 4.0	tidak didukung	Didukung	Didukung

Nota

• Semua unit Xbox One yang ditingkatkan ke versi 1709 atau versi yang lebih tinggi mendukung 'cbcs'.
• Semua Server Lisensi PlayReady yang dimulai dengan versi 4.0 mendukung penerbitan lisensi dengan kunci CBC.

Menandakan ALGID dalam Header PlayReady

PlayReady Header adalah dokumen XML yang biasanya disertakan dalam header file konten atau stream. Ini menjelaskan atribut PlayReady yang diperlukan klien untuk mendekripsi konten ini. Header PlayReady memiliki spesifikasi dan penversian tersendiri. Untuk informasi selengkapnya, lihat Spesifikasi Header PlayReady.

Versi	PlayReady Header 4.3	Header PlayReady 4.2	PlayReady Header 4.1	Header PlayReady 4.0
PlayReady Client 4.0 (lihat catatan 4)	✔	✔	✔	✔
Klien PlayReady 3.3 (lihat catatan 3)		✔	✔	✔
PlayReady Client 3.0 (lihat catatan 3)		✔	✔	✔
PlayReady Client 2.5 (lihat catatan 2)			✔	✔
PlayReady Client 2.0 (lihat catatan 2)			✔	✔
PlayReady Client 1.0 (lihat catatan 1)				✔

Nota

• (4) Xbox One versi 1709 atau lebih tinggi adalah Klien PlayReady 4.X.
• (3) Windows 10 semua versi dan Xbox One versi 1703 atau yang lebih rendah adalah Klien PlayReady 3.X. Perangkat non-Windows terbaru (misalnya Smart TV) yang dirilis setelah 2017 adalah Klien PlayReady 3.X.
• (2) Silverlight dan Windows 8, 8.1 adalah Klien PlayReady 2.X. Sebagian besar perangkat non-Windows (misalnya, Smart TV) yang dirilis antara 2011 dan 2017 adalah Klien PlayReady 2.X.
• (1) Sebagian besar perangkat non-Windows (misalnya, Smart TV) yang dirilis antara 2008 dan 2011 adalah Klien PlayReady 1.X.

Berikut ini adalah contoh Header PlayReady v4.2.

<WRMHEADER
          version="4.2.0.0"
          xmlns="http://schemas.microsoft.com/DRM/2007/03/PlayReadyHeader">
  <DATA>
    <PROTECTINFO>
      <KIDS>
        <KID ALGID="AESCTR" CHECKSUM="xNvWVxoWk04=" VALUE="0IbHou/5s0yzM80yOkKEpQ=="></KID>
        <KID ALGID="AESCTR" CHECKSUM="GnKaQIRacPU=" VALUE="/qgG2xbs4k2SKCxx6bhWqw=="></KID>
       </KIDS>
    </PROTECTINFO>
    <LA_URL>http://rm.contoso.com/rightsmanager.asmx</LA_URL>
    <DS_ID>AH+03juKbUGbHl1V/QIwRA==</DS_ID>
    <DECRYPTORSETUP>ONDEMAND</DECRYPTORSETUP>
  </DATA>
</WRMHEADER>

ALGID (pengidentifikasi algoritma) adalah properti elemen KID, dan menentukan algoritma enkripsi yang digunakan untuk mengenkripsi konten. Dimulai dengan Header PlayReady versi 4.2, ALGID diperlukan dan harus diatur ke "AESCTR" atau "COCKTAIL". Namun, dimulai dengan versi 4.3, ALGID juga dapat diatur ke nilai "AESCBC" . Contoh berikut menunjukkan Header PlayReady versi 4.3 dengan nilai ALGID diatur ke "AESCBC".

<WRMHEADER
          version="4.3.0.0"
          xmlns="http://schemas.microsoft.com/DRM/2007/03/PlayReadyHeader">
  <DATA>
    <PROTECTINFO>
      <KIDS>
        <KID VALUE="PV1LM/VEVk+kEOB8qqcWDg==" ALGID="AESCBC"/>
        <KID VALUE="tuhDoKUN7EyxDPtMRNmhyA==" ALGID="AESCBC"/>
      </KIDS>
    </PROTECTINFO>
    <LA_URL>http://rm.contoso.com/rightsmanager.asmx</LA_URL>
    <DS_ID>AH+03juKbUGbHl1V/QIwRA==</DS_ID>
    <DECRYPTORSETUP>ONDEMAND</DECRYPTORSETUP>
  </DATA>
</WRMHEADER>

Gambar berikut menunjukkan alur konten, di mana permintaan lisensi didasarkan pada Header PlayReady dan ALGID ditentukan.

ALGID yang hilang

Dimulai dengan Header PlayReady versi 4.3, ALGID mungkin hilang. Contoh berikut menunjukkan Header PlayReady versi 4.3 dengan nilai ALGID hilang.

<WRMHEADER
          version="4.3.0.0"
          xmlns="http://schemas.microsoft.com/DRM/2007/03/PlayReadyHeader">
  <DATA>
    <PROTECTINFO>
      <KIDS>
        <KID VALUE="PV1LM/VEVk+kEOB8qqcWDg=="/>
      </KIDS>
    </PROTECTINFO>
    <LA_URL>http://rm.contoso.com/rightsmanager.asmx</LA_URL>
    <DS_ID>AH+03juKbUGbHl1V/QIwRA==</DS_ID>
    <DECRYPTORSETUP>ONDEMAND</DECRYPTORSETUP>
  </DATA>
</WRMHEADER>

Gambar berikut menunjukkan alur konten, di mana permintaan lisensi menggunakan modul CDMi, dan ALGID hilang.

Nota

Setiap Header PlayReady mungkin memiliki:

• Hanya satu jenis enkripsi. Misalnya, jika ALGID="AESCTR", semua kunci untuk header digunakan dalam mode CTR. Ketika ALGID="AESCBC", semua kunci untuk header ini digunakan dalam mode CBC.
• Ketika ALGID hilang, semua kunci untuk header ini digunakan dalam Mode Penghitung atau Cipher Block Chaining, tetapi nilai tidak dimasukkan ke header.
• Membuat permintaan akuisisi lisensi dengan Header PlayReady v4.3 ke Server Lisensi di bawah v4.0 akan menghasilkan pengecualian.
• Respons lisensi dapat mencakup satu atau banyak lisensi, di mana setiap lisensi berisi satu kunci dan sejumlah kebijakan.

Mengapa nilai ALGID hilang

Microsoft menyarankan agar enkriptor selalu menyertakan nilai ALGID yang sama di Header PlayReady seperti yang mereka sertakan saat memproses konten.

Dalam skenario standar, enkriptor mengenkripsi konten dan menghasilkan Header PlayReady di dalam konten. Peng-enkripsi tahu mode AES mana yang digunakan untuk enkripsi; dengan demikian, informasi ini dimasukkan di properti ALGID dari Header PlayReady. Klien memulai permintaan lisensi berdasarkan Header PlayReady yang diuraikan dari konten nyata, sehingga nilai ALGID ada dan valid.

Dalam beberapa skenario, klien memulai permintaan lisensi berdasarkan nilai KID sederhana (GUID 128-bit). Dalam hal ini, nilai ALGID di Header PlayReady yang dimasukkan dalam permintaan lisensi akan hilang (juga dikenal sebagai tidak ditentukan). Salah satu contohnya adalah ketika klien membuat permintaan lisensi menggunakan HTML5 EME API.

Bagaimana Klien menangani ALGID yang hilang

Jika klien memulai permintaan lisensi berdasarkan Header PlayReady masuk, maka nilai ALGID dalam permintaan lisensi akan mencerminkan nilai yang ditemukan di header karena tantangan akuisisi lisensi menyertakan salinan Header PlayReady. Dalam hal ini:

• Untuk semua Header PlayReady v4.2 atau yang lebih rendah, nilai ALGID diperlukan dan harus valid.
• Untuk Header PlayReady v4.3 atau yang lebih tinggi, nilai ALGID dapat ada dan valid, atau hilang.

Cara Server SDK menangani ALGID yang hilang

Semua lisensi yang dikirimkan melalui respons lisensi HARUS menyertakan nilai ALGID yang valid.

Jika ALGID tidak ditentukan dalam permintaan lisensi masuk, Server Lisensi harus mendapatkan informasi ini dari backend layanan dan menempatkan nilai yang tepat dalam respons lisensi.

Vektor Inisialisasi (IV)

Dalam versi PlayReady 3.3 dan sebelumnya, hanya IV 64-bit (IV 8-byte) yang didukung di mode CTR. Dimulai dengan PlayReady versi 4.0, IV 64-bit dan 128-bit (IV 8-byte dan 16-byte) didukung baik dalam mode CTR maupun CBC.

Contoh:

• Aliran yang mematuhi HLS yang sering menggunakan IV 128-bit dalam mode CBC sekarang didukung.
• Beberapa alur yang sesuai dengan HbbTV yang menggunakan IV 128-bit sekarang didukung dalam mode CTR.

Keterbatasan

• Header PlayReady hanya boleh menggunakan satu nilai ALGID untuk semua elemen KID. Dengan kata lain, semua kunci yang digunakan untuk mengenkripsi jalur dan kualitas aset yang berbeda harus berupa AES CTR atau AES CBC. Jika ALGID hilang pada elemen KID apa pun, itu harus hilang dari semua elemen KID.
• Sebelum PlayReady versi 4.4, menghasilkan lisensi dengan kunci CBC ketika Sertifikat Klien yang masuk adalah Windows dan SL2000 memunculkan pengecualian. Ini karena Klien Windows hanya mendukung CBC pada unit SL3000. Mungkin lisensi dengan kunci CBC dapat diberikan kepada Klien SL2000, namun, jika klien ini adalah versi PlayReady minimal 4.0 dan mendukung mode CBC.
• Menghasilkan lisensi dengan kunci CBC ketika Sertifikat Klien yang masuk adalah dari perangkat yang menggunakan Porting Kit versi sebelum 4.0 akan memunculkan pengecualian.
• Menghasilkan lisensi dengan kunci CBC ketika permintaan lisensi yang masuk tidak menunjukkan dukungan untuk AES CBC, akan memunculkan pengecualian.

Penting

Layanan tidak boleh mengenkripsi satu konten dalam mode CTR dan dalam mode CBC menggunakan {KID, Ck}yang sama.

• Untuk alasan fungsional, klien yang memperoleh lisensi untuk {KID, Ck, AESCTR} dan untuk {KID, Ck, AESCBC} tidak akan berfungsi.
• Untuk alasan ketahanan, penyerang yang memiliki akses ke konten yang sama dienkripsi dengan kunci yang sama baik dalam mode CBC maupun CTR dapat lebih mudah mendekripsi konten tanpa otorisasi.