Pakowanie i dostarczanie zawartości

Podstawową funkcją playReady jest ochrona zawartości przed nieautoryzowanym użyciem. W tym celu zawartość musi być najpierw zaszyfrowana, a skojarzony nagłówek PlayReady musi zostać wstawiony do zawartości. System, który wykonuje tę operację, jest packager, znany również jako szyfrator, który jest czasami zintegrowany z koderem.

W tym temacie opisano różne sposoby szyfrowania i przesyłania zawartości przy użyciu PlayReady.

Pakowanie zawartości PlayReady — szyfrowanie i wstawianie nagłówka DRM

Proces szyfrowania nieszyfrowanej zawartości składa się z definiowania jednego lub kilku kluczy szyfrowania, użycia tych kluczy do szyfrowania bajtów, które tworzą samą zawartość, i dodania nagłówka DRM do zawartości (w plikach zawartości lub w manifeście, jeśli zawartość go posiada).

Cała zaszyfrowana zawartość chroniona przez element PlayReady musi zawierać nagłówek PlayReady wstawiony do zaszyfrowanego pliku. Ten nagłówek PlayReady jest używany przez klienta PlayReady do lokalizowania lub uzyskiwania licencji dla tego konkretnego elementu zawartości. Nagłówek PlayReady składa się z kodu XML zakodowanego w formacie UTF-16. Zawiera on identyfikatory kluczy (KID), które są używane do szyfrowania zawartości, domyślny adres URL, z którego klient będzie korzystać w celu uzyskania licencji, jeśli nie podano żadnych innych, oraz atrybuty niestandardowe.  

Każdy packager, który pakuje przejrzystą zawartość, musi zaimplementować generator nagłówka PlayReady, aby utworzyć nagłówek i osadzić go w zaszyfrowanej zawartości. Nagłówek PlayReady musi być zaimplementowany zgodnie ze specyfikacją nagłówka PlayReady. Istnieje wiele sposobów tworzenia generatora nagłówka PlayReady w pakiecie:

• Opracuj to samodzielnie na podstawie specyfikacji nagłówka PlayReady. 
• Użyj interfejsu API zestawu SDK PlayReady Server, który generuje nagłówek PlayReady. 
• Użyj interfejsu API systemu Windows 10, który generuje nagłówek PlayReady. 

Zaszyfrowana zawartość może zawierać wiele nagłówków DRM, w tym nagłówki PlayReady wraz z nagłówkami DRM innych firm. Aby uzyskać więcej informacji na temat tego, jak to działa, zobacz Korzystanie z narzędzi szyfrowania.

Typ zawartości

Element PlayReady może służyć do ochrony zawartości audio i wideo. Najczęstszymi typami kodowania używanymi z PlayReady są standardy MPEG-4 AVC (H.264), High Efficiency Video Coding (HEVC) H.265 oraz standard AV1. PlayReady nie jest ograniczony do tych standardów i może być używany z dowolnym formatem audio i wideo obsługiwanym przez urządzenie klienckie.

Program PlayReady w wersji 1 i 2 umożliwia utworzenie chronionego pakietu zawierającego zawartość, która nie jest ograniczona do ładunków audio lub wideo. Te pakiety, nazywane kopertami, mogą zawierać pliki, takie jak kolekcja plików danych i plików wykonywalnych (na przykład aplikacja dystrybuowana przez sklep z aplikacjami), obrazy (na przykład tapeta ekranu) lub książki elektroniczne. Ta zawartość jest pakowana przez hermetyzowanie plików do pliku koperty, który można odszyfrować w sposób podobny do zawartości audio/wideo.

Te typy zawartości inne niż audio/wideo nie są już obsługiwane w programie PlayReady 3.0 i nowszych wersjach. 

Narzędzia szyfrowania

Firma Microsoft nie dołącza pakietu jako części elementów dostarczanych PlayReady. PlayReady udostępnia specyfikacje oparte na wspólnych standardach szyfrowania do użycia przez enkodery. Dlatego format szyfrowania nie jest specyficzny dla elementu PlayReady, a raczej jest funkcją formatu pliku. Najczęściej używanym obecnie formatem szyfrowania jest format ISO Standard Common Encryption , ISO/IEC 23001-7.

Zasadniczo możesz utworzyć własny program packager lub pracować z dowolnym typem szyfratora typu open source (np. ffmpeg). Ponadto możesz pracować z profesjonalną firmą zajmującą się kodowaniem, jeśli chcesz zaszyfrować zawartość za pomocą PlayReady (np. Harmonic, Elemental, Ericsson, Wowza, Allegro).

Korzystanie z narzędzi szyfrowania

Usługa PlayReady obsługuje standard wspólnego szyfrowania ISO IEC. Ten proces jest taki sam, jak opisano w Podstawowym procesie szyfrowania i licencjonowania, z wyjątkiem tego, że w przypadku innych DRM nagłówki będą uwzględniane — każdy jako ładunek pole Nagłówka specyficznego dla systemu ochrony ('pssh'), zidentyfikowany przez SystemID tego systemu DRM. Wszystkie te nagłówki będą miały własną składnię, która wyznacza identyfikatory KID lub informacje wymagane do uzyskania dostępu do kluczy zawartości. Klucze zawartości tego zasobu będą identyczne dla wszystkich DRM.

Używanie kluczy szyfrowania

Istnieje wiele różnych sposobów szyfrowania zasobów. Najprostszy z najbardziej zaawansowanych zależy od tego, ile złożoności chcesz zaprojektować w systemie i jakie są potrzeby usługi.

Przyjrzyjmy się na przykład adaptacyjnemu zasobowi przesyłania strumieniowego, jak pokazano na poniższej ilustracji. Ma cztery różne cechy wideo, jedną ścieżkę dźwiękową i jedną ścieżkę podtytułu. Jest on zakodowany w segmentowanych plikach MP4 z segmentami 2,0 sekund. Jest to jeden zasób obsługiwany w wielu formatach w zależności od tego, co klient wolałby odtworzyć. Smooth Streaming, HLS i DASH to najbardziej typowe warianty. Podczas odtwarzania klient (odtwarzacz wideo) będzie kolejno pobierać segmenty elementu zawartości za pośrednictwem sieci, wybierając dla każdego segmentu odtwarzania z odpowiedniej ścieżki wideo, aby zapewnić możliwie wysoką jakość odtwarzania, biorąc pod uwagę ograniczenia przepustowości sieci, szybkość odtwarzania i inne ograniczone zasoby, takie jak możliwości odtwarzacza. Ta logika jest znana jako adaptacyjna transmisja strumieniowa, regulowana przez pewne zasady heurystyczne zaimplementowane w odtwarzaczu. 

Szyfrowanie zasobu przy użyciu tylko jednego klucza

Najprostszym sposobem szyfrowania tych zasobów byłoby użycie jednego klucza zawartości do szyfrowania wszystkich elementów (zazwyczaj napisy nie są szyfrowane — nie jest to reguła, ale zwykle są one przechowywane w przejrzysty sposób). Użycie jednego klucza zawartości ułatwia korzystanie z serwera licencji, ponieważ serwer licencji musi dostarczyć jeden klucz {KID, CK}. Ten klucz zazwyczaj jest uzyskiwany przez klienta przed rozpoczęciem odtwarzania.

Uwaga / Notatka

Klienci PlayReady mogą aktywnie lub reaktywnie uzyskiwać licencje. Aby uzyskać opis tych dwóch trybów, zobacz stronę Pozyskiwanie licencji .

Szyfrowanie zasobu za pomocą dwóch kluczy, przy czym jeden przeznaczony jest do najwyższej jakości.

W ostatnich latach wprowadzono pewne ulepszenia dotyczące używania wielu kluczy na zasób, głównie ze względu na wymóg zezwalania tylko niektórym klientom o najwyższej niezawodności na korzystanie z zawartości najwyższej jakości. Wraz z pojawieniem się zawartości Ultra HD (4K) i z dodaniem wysokiego zakresu dynamicznego (HDR) dla uzyskania lepszej jakości kolorów, studia i usługi potrzebowały umożliwić najwyższą jakość tylko na niektórych klientach, którzy zwykle mają sprzęt DRM wbudowany. W tym scenariuszu zasób jest szyfrowany przy użyciu jednego klucza zawartości {kid1, ck1} dla wszystkich ścieżek, z wyjątkiem ścieżki 4K szyfrowanej przy użyciu innego klucza zawartości {kid2, ck2}. Czyli:

• Klient, który może odtwarzać tylko do Full HD (a nie ścieżki 4K), otrzyma licencję PlayReady, zawierającą tylko {kid1, ck1}. 
• Klient, który może grać do 4K, zostanie dostarczony licencję PlayReady, w tym {kid1, ck1} i {kid2, ck2}.

Korzystając z tej dodatkowej złożoności, usługa może zapewnić, że niektórzy klienci nie będą mogli odszyfrować ścieżki 4K i że ścieżka 4K może być zarezerwowana tylko dla klientów, którym usługa najbardziej ufa. 

Szyfrowanie zasobu przy użyciu jednego klucza na ścieżkę

Usługa może mieć bardziej złożoną mapę praw do wymuszania. Niektórzy klienci, w zależności od rozmiaru ekranu, ich niezawodności, danych wyjściowych i ich lokalizacji, mogą mieć dostęp tylko do niektórych utworów wideo, niektórych cech wideo i niektórych ścieżek dźwiękowych. Aby upewnić się, że usługa ma pełną elastyczność w wymuszaniu dowolnego zestawu ograniczeń w przyszłości, może zaszyfrować zasób przy użyciu klucza zawartości specyficznego dla każdego toru. Na przykład:

• Klient, który może grać tylko 720p, zostanie dostarczony licencję PlayReady, w tym {kid1, ck1}, {kid2, ck2}, i {kidA, ckA}. 
• Klient, który może grać do 4K, zostanie dostarczony licencję PlayReady, w tym {kid1, ck1}, {kid2, ck2}, {kid3, ck3}, {kid4, ck4}, i {kidA, ckA}. 
• Klient, odtwarzający w trybie offline wersję 4K zasobu (wcześniej pobranego), otrzyma licencję PlayReady, w tym {kid4, ck4} i {kidA, ckA}. 

Okresowe zmienianie kluczy szyfrowania (zasób wieloterminowy) — rotacja licencji

W niektórych scenariuszach usługa chce czasami zmieniać klucze szyfrowania, zazwyczaj na granicach programu. Na przykład strumień liniowy na żywo ma wiele okresów z zawartością dostępną na bezpłatnych kanałach, do której każdy powinien mieć dostęp, po której następuje zawartość ograniczona do subskrybentów. Zmiana kluczy szyfrowania na granicach programu umożliwia usłudze dostarczanie bezpłatnych kluczy lotniczych {KIDi1, CKi1} wszystkim użytkownikom bez żadnych ograniczeń i dostarczanie kluczy zawartości {kidi2, cki2} tylko subskrybentom, którzy pomyślnie zalogowali się w usłudze.

Należy pamiętać, że ta rotacja licencji nie jest bardzo skalowalna: za każdym razem, gdy zmieniają się klucze szyfrowania, wszyscy klienci żądają nowych kluczy szyfrowania przy użyciu własnego żądania licencji. Może to spowodować wysoki szczyt żądań licencji w systemach z dużą liczbą klientów. 

Częste zmienianie kluczy szyfrowania — skalowalna rotacja kluczy

PlayReady ma zaawansowany mechanizm, nazywany skalowalną rotacją kluczy (w przeciwieństwie do rotacji licencji). Ta metoda przechowuje Embedded License Store (ELS) w strumieniu właściwej zawartości. W tym mechanizmie klucz używany do szyfrowania samego segmentu A2 jest nazywany kluczem liścia {kidA2, ckA2}, i jest dostarczany w elS segmentu A2, będąc sam zaszyfrowany przy użyciu oddzielnego klucza, który jest taki sam dla wszystkich segmentów ścieżki A, nazywany kluczem głównym {kidRA, ckRA}. Jeśli znasz protokół MPEG-2 TS i szyfrowanie Control Word, jest to podobny mechanizm, ale szyfrowanie jest znacznie silniejsze, a także bardziej elastyczne.

Załóżmy, że ten zasób to telewizja linearna na żywo. Gdy klient próbuje odtworzyć strumień, znajduje kidRA w nagłówku manifestu strumienia PlayReady i żąda licencji dla kidRA. Serwer licencji zwraca licencję bazową dla klucza bazowego {kidRA, ckRA}. Następnie klient analizuje segment A1 i odnajduje elS w nagłówku segmentu. Podczas analizowania tego ELS, znajduje licencję leaf {kidA1, ckA1} w tym ELS. Używając klucza głównego {kidRA, ckRA} i licencji liścia {kidA1, ckA1}, może uzyskać wartość ckA1 i odszyfrować i renderować segment A1. 

Skalowalna funkcja rotacji kluczy PlayReady jest niezwykle skalowalna, ponieważ nie wymaga od klientów kontaktowania się z serwerem licencji za każdym razem, gdy klucze szyfrowania są zmieniane. Utrzymuje ona liczbę żądań licencji do najniższego możliwego poziomu, ponieważ klient potrzebuje tylko jednej licencji głównej z serwera licencji na strumień lub utwór. Umożliwia ona rotację kluczy szyfrowania tak często, jak każdy segment, zazwyczaj co dwie sekundy, jeśli zajdzie taka potrzeba. 

Zobacz także

Klucz i identyfikatory kluczy (KIDs)