Certyfikat Widevine L1 DRM

[trójkowy]

@szumacher nie rozumie wciąż że L1 to rozwiązanie sprzętowe dokładny algorytm nie jest znany a do dekrypcji strumienia audio-vizualnego potrzebne są sprzętowe klucze z TEE i tego że wszystkie rozwiązania do ochrony treści są sprzętowe od przeszło 15 lat.

Z ciekawości zapytałem oto prosta odpowiedz sztucznej inteligencji:

 

Widevine L1 jest rozwiązaniem sprzętowym (hardware-based) i to kluczowa cecha odróżniająca je od niższych poziomów zabezpieczeń. Oto szczegółowe wyjaśnienie:

Czym jest Widevine?
Widevine to technologia DRM (Digital Rights Management) należąca do Google, używana do ochrony treści wideo przed nielegalnym kopiowaniem. Jest stosowana m.in. przez Netflixa, YouTube Premium, Disney+ i innych dostawców treści.

Poziomy Widevine: L1, L2, L3
Widevine ma trzy poziomy zabezpieczeń, gdzie L1 jest najwyższy (i najbezpieczniejszy):

Widevine L1 (Hardware-backed):

Deszyfrowanie i przetwarzanie wideo odbywa się w sprzętowym bezpiecznym środowisku (TEE - Trusted Execution Environment).

TEE to izolowany obszar procesora/układu SoC, niedostępny dla systemu operacyjnego ani aplikacji. Klucze szyfrujące i operacje kryptograficzne są tam chronione.

Wymagany do odtwarzania treści w ultra HD (4K) i HDR.

Widevine L2/L3 (Software-based):

L3: Deszyfrowanie odbywa się całkowicie w oprogramowaniu (bez izolacji sprzętowej). Klucze są łatwiejsze do wycieku.

L2: Mieszane (częściowo sprzętowe, ale słabsze niż L1).

Treści są często ograniczone do rozdzielczości HD (1080p) lub niższej.

Dlaczego L1 jest sprzętowe?
Bezpieczne środowisko (TEE): Procesor musi mieć dedykowany hardware (np. TrustZone w ARM) do izolacji krytycznych operacji.

Certyfikacja: Producent urządzenia (np. telefonu, telewizora) musi uzyskać certyfikat od Google potwierdzający poprawną implementację TEE.

Klucze sprzętowe: Klucze szyfrujące są powiązane z konkretnym urządzeniem i przechowywane w TEE.

Jak to działa w praktyce?
Aplikacja (np. Netflix) żąda odtworzenia treści.

System Widevine sprawdza poziom zabezpieczeń urządzenia.

Dla L1:

Klucz deszyfrujący jest przesyłany do TEE.

TEE deszyfruje strumień wideo i renderuje go bez udostępniania danych do głównego systemu.

Ekran musi być chroniony przed przechwytywaniem (HDCP).

Skąd wiesz, jaki poziom ma twoje urządzenie?
Na Androidzie: Ustawienia > Informacje o telefonie > Widevine DRM.

Aplikacje typu DRM Info pokazują szczegóły.

Podsumowanie:
L1 = Sprzętowe zabezpieczenia (TEE) + najwyższa jakość wideo (4K/HDR).

L3 = Programowe zabezpieczenia (brak izolacji sprzętowej) + ograniczenia jakości.

L1 wymaga certyfikowanego hardware'u, więc nie da się go "dodać" softwarem na starszym urządzeniu.

Ja > Czy L1 wykorzystuje jakies klucze sprzetowe do dekrypcji strumienia audio video ? 

Odp:

Tak, Widevine L1 bezpośrednio wykorzystuje sprzętowe klucze kryptograficzne do dekrypcji strumienia audio-wideo. Jest to kluczowy element jego architektury zabezpieczeń. Poniżej znajduje się szczegółowe wyjaśnienie:

Rola kluczy sprzętowych w Widevine L1:
Trusted Execution Environment (TEE):

Widevine L1 działa w sprzętowo izolowanym środowisku (TEE), które jest oddzielone od głównego systemu operacyjnego.

TEE ma własny procesor, pamięć i zasoby kryptograficzne, niedostępne dla zewnętrznego oprogramowania.

Klucze urządzenia (Device Keys):

Każde urządzenie z Widevine L1 posiada unikalne klucze sprzętowe (np. zapisane w bezpiecznej pamięci SoC lub modułu TPM).

Klucze te są trwale powiązane z hardware’em i nie można ich wyodrębnić ani zmodyfikować.

Proces dekrypcji:

Serwer DRM (np. Netflix) dostarcza zaszyfrowany klucz treści (Content Key), który jest używany do odszyfrowania strumienia wideo.

Klucz treści jest odszyfrowywany wewnątrz TEE za pomocą kluczy sprzętowych urządzenia.

Odszyfrowany strumień wideo jest renderowany bezpośrednio w TEE, a dane nigdy nie trafiają do pamięci systemowej w formie niezaszyfrowanej.

Dlaczego to jest bezpieczne?
Izolacja sprzętowa: TEE uniemożliwia aplikacjom lub systemowi OS dostęp do kluczy lub odszyfrowanych danych.

Certyfikacja sprzętu: Producent urządzenia musi spełnić rygorystyczne wymogi Google dotyczące implementacji TEE i przechowywania kluczy.

Atesty hardware’u: Klucze są chronione przed fizycznymi atakami (np. side-channel attacks) dzięki specjalistycznym układom kryptograficznym.

Analogia:
Wyobraź sobie sejf (TEE) wbudowany w ścianę (urządzenie). Tylko sejf ma klucz (klucz sprzętowy) do otwarcia zaszyfrowanej paczki (klucz treści). Paczka jest otwierana wewnątrz sejfu, a jej zawartość (wideo) jest przekazywana bezpośrednio do ekranu, bez wystawienia jej na zewnątrz.

Różnica między L1 a L3:
Widevine L3 używa kluczy przechowywanych w software’cie (np. w pamięci systemowej), które są podatne na ekstrakcję przez zhakowanie systemu.

Widevine L1 uniemożliwia to dzięki sprzętowej izolacji.

Podsumowanie:
Widevine L1 opiera się na kluczach sprzętowych i TEE do ochrony zarówno kluczy treści, jak i samego strumienia multimedialnego. Jest to standard wymagany do odtwarzania treści 4K/HDR w serwisach takich jak Netflix czy Disney+.

 

Znając analogie i strukture zabezpieczeń stosowanych przez producentów stwierdziłem już na początku że to rozwiązanie sprzętowe. Twierdzę również iż nikt nie posiada sprzętowego algorytmu i kluczy do dekrypcji strumienia audio-video a zwykły pirat prędzej wykorzysta port HDMI odbiornika zamiast zawracać sobie głowę jakimś kluczykiem L1 w 2025r. Parcie na klucze pojawi się w przyszłości gdy uruchomią długo oczekiwane parowanie sprzętowe pomiędzy telewizorami a urządzeniami z portem HDMI takie rozwiązania są wdrażane od wielu lat w dzisiejszych telewizorach tylko do dziś nie zostały jeszcze uruchomione.

 

Nie twierdzę również że klucze sprzętowe są nie do odczytu a algorytmy nie do poznania jednak w ostatnich latach poziom zabezpieczeń z EAL5 wzrósł sprzętowe moduły kryptograficzne w procesorach są projektowane przez AI na zlecenie producentów i pomimo iż procesory te nie posiadają wysokich poziomów zabezpieczeń jak te występujące w dzisiejszych kartach inteligentnych e-dowodach e-paszportach to wciąż przy niskim budżecie jest ciężko rozpracować ich zabezpieczenia. 

Edytowane 5 godzin temu przez trójkowy

[adas13]

Ludzie posiadaja klucze L1 jak i PR3K, przeciez to widac po materialach ktore sa dostepne , ale czasami z dobrym "mod-em" mozna sie pogubic  (pluginy pod E2) (publiczna dyskusja, wiec nie mozna inaczej).

 

Narazie Adas

[jacek_kc]

Proponuję najpierw rozdzielić pojęcia, bo mieszacie provisioning/attestation z kluczami treści:

1) Certyfikat urządzenia ≠ klucze licencyjne ≠ klucze treści.
W Widevine L1 cała wrażliwa kryptografia (unwrapping licencji, klucze sesji) dzieje się w TEE (TrustZone) w ramach zaufanej aplikacji (TA/CDM). Certyfikat urządzenia służy do attestation/provisioningu, a nie do „wyliczania” kluczy treści.

2) Jak trafia certyfikat?
Historycznie bywał keybox w fabryce; współcześnie urządzenie generuje parę kluczy wewnątrz TEE, wysyła CSR i dostaje łańcuch certyfikatów podpisany przez Google. To, że payload jest dodatkowo szyfrowany kluczem provisioningu/OEM (związanym z SoC/HUK), dotyczy transportu i składowania, a nie udostępniania „w plain” poza TEE.

3) „Leży w plain” – ale gdzie?
„Plain” istnieje tylko w pamięci procesu TA w secure world podczas użycia. REE (normalny świat) nie ma do tego dostępu. Niezależnie od tego, czy RAM secure jest sprzętowo szyfrowany, izolacja TEE + weryfikacja podpisów kodu są głównym mechanizmem bezpieczeństwa.

4) „Jak zhackujesz TA, to masz dostęp do sekretów.”
Zgadza się — ale to oznacza kompromitację TEE/TA, czyli wyjście poza zakładany model zagrożeń. Wtedy w grę wchodzą: revokacje certów, aktualizacje TA/TEE, anti-rollback, blacklisty po stronie licencjodawcy. To nie jest to samo co „to wszystko jest w plain i każdy może sobie wziąć”.

5) STB vs Android.
Implementacje różnią się szczegółami (key-ladder vendorów, secure video path), ale zasada jest ta sama: sekrety nie opuszczają TEE, a ścieżka obrazu jest zabezpieczona. Publiczne „sample TAs” nie są produkcyjnymi binarkami; bez podpisu OEM/TEE nie uruchomisz ich w secure world.

Wniosek: certyfikat urządzenia służy do bezpiecznego provisioningu i attestation, a klucze treści pozostają w TEE. Twierdzenie, że „cert jest plain, więc to bez znaczenia”, jest błędne — „plain” jest dostępny wyłącznie dla zaufanej aplikacji w TEE. Jeśli uważacie inaczej, pokażcie realny model ataku bez kompromitacji TA/TEE i rollbacku — to zupełnie inna klasa problemu.

 

[szumacher]

@trójkowy

 

Przestań już bredzić!

 

Sprzętowe ale ty o trust zone nie masz pojęcia!

W trust zone działa pod kontrolą secure os ma aplikacje moduły itd 

 

Ty piszesz takie bzdury, że uszy więdną, a ja wiem co piszę!

 

Te brednie nikt nie posiada algorytmów do deskrypcji audio/video!

 

To zwykły AES! Przestań już bredzić bo nie ręczę za siebie.

 

@jacek_kc

Dokładnie tak dlatego jak się znajdzie dziurę to się tym nie chwali. 

 

A co do STB to tak jeśli to Android.

Ale @trójkowyżyje STB z ST.

 

Tam był firmware code do secure procka. Do którego dokumentacji brak.  Dużo ciężej zaatakować było ten firmware. 

 

A tu masz TA aplikacje dla ARM gdzie masz pełnie dokumentacji pełno narzędzi do dekompilacji disasemblacji. 

Tak aplikacje TA skompilowane gcc dla architektury ARM, są podpisywane/szyfrowane. Ale wszystko da się złamać.

 

A @trójkowy nie przyswoił nawet tego co w sieci lata. Czyli znane backdoory itd. inna sprawa, że jak to wyszło public to zostało załatane, a certyfikaty trafiły na black listę.

 

Jeszcze te głupoty, że algorytmy nie są znane litości. 

 

Przecież są nawet dokumentację do DASH, HLS, smooth streaming.

 

Co więcej mamy już klika aplikacji pod E2 obsługujące DRM, a E2IPLAYER pozwala na pobieranie treści  zapieczonych DRM i po pobraniu ma się je plain.

 

A ten dalej takie banialuki pociska...

Ile można takie brednie czytać?

 

Jak już wiele razy pisałem ja nie zamierzam się chwalić co mam. 

 

 

@jacek_kcmyślisz, że znalezienie dziury jest tak mega ciężkie tylko, że każdy producent ma pełno dziur. 

 

A to mają jakiś interfejs udostępniający interfejs do szyfrowania / deszyfrowania czegoś master key i nawet nie zdają sobie sprawy, że można go użyć do szyfrowania / deszyfrowania innych danych itd.

Mają zaimplementowane mechanizmy debug aplikacji TA.

Niby wyłączone w release ale tak nie do końca.  Łącznie z wypluwaniem certyfikatów plain w logach na serial. No tak logi szyfrowane, ale co z tego jak już wspominałem...

Mają mechanizmy debugowe by ładować TA niepodpisane niby nie w sofcie który idzie na produkcję no ale z kodu nie usunięte tylko softwareowo wyłączone.

Nie będę tu pisał nic więcej bo sensu to wielkiego nie ma.

@jacek_kc

A co do tej kompromitacji to ci powiem tak dopóki to nie jest publick, to nawet jak dasz znać producentowi, że coś tam odkryłem to po trzech latach w nowych produktach dziura dalej jest.

 

Jak jest publick i Google banuje całe urządzenia to dopiero producent zaczyna się interesować.

Tak to wygląda od strony praktycznej.

Edytowane 3 godziny temu przez szumacher