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 8 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 7 godzin temu przez szumacher

[trójkowy]

5 godzin temu, adas13 napisał(a):

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

Nie dojdziesz po materiałach czy ktoś posiada klucz włącz myślenie zacznij od podstaw które panują tu od dawna.

Przypadek 1:

 

-sky de 4k pojawił się w sharingu wszyscy twierdzili że ktoś wytargał klucze plain z dekoderów humax 4k z biegiem czasu okazało się że nikt nigdy nie złamał zabezpieczeń w STIH418 a karty które działają w sharingu korzystają z innych kluczy które zostały wyliczone na starych dekoderach oprócz tego pewna grupa dobrała się do tzw. serwisowych kluczy ale nikt nigdy nie złamał zabezpieczeń w STIH418 to za trudne trzeba by poświęcić na to wiele lat a czas na zarobek jest ograniczony.

 

Przypadek 2:

 

-w forever pojawił się działający operator nova po czasie okazało się że działa ze starych kart bez wymuszonego parowania control words.

 

Przypadek 3:

 

-pojawiło się nagle wiele operatorów korzystających w sharingu z sys. nds jak się pózniej okazało znów nikt żadnego parowania nie złamał tylko wykorzystany został 

błąd umożliwiający wyliczenie kluczy parujących. 

 

Przypadek 4:

 

-znów pojawili się inni operatorzy nds w sharingu jednak u nich stare karty które można było uruchomić z wyliczonymi kluczami został dawno temu wycofane w tym przypadku została wykorzystana metoda dosyłu zdekodowanych control words przez procesor operatora więc wciąż nigdy nikt nie zdekodował żadnych kluczy na broadcomie.

 

Przypadek 5: 

 

W iks forever nagle zaczynają się pojawiać działający operatorzy z sys. irdeto min. ponownie nova czy showtime jednak działają oni tylko przez 12 godzin w ciągu doby 

jak twierdzili operatorzy ich atakują dlatego całość może działać tylko przez 12 godzin i napewno w przyszłości będzie działać cały czas

 

Zdarzały się również przypadki gdzie działały jacyś inni operatorzy komuś jednak okazywało się że ktoś zapłacił pod stołem za aktywację uprawnień na starych dekoderach z STI7105 (przypadek digiturk) czy z STI7111 (przypadek nds w sky italia)

 

Podsumowanie:

Jeśli ktoś wciąż wierzy w to że coś zostało złamane od czasu rozpracowania procesorów z STI71xx jest w błędzie powyższe przypadki jasno pokazują iż zawsze jest inaczej mało tego przypadek 5 jest najbardziej ciekawym przypadkiem co to jest i jak może działać prymitywne wytłumaczenie poniżej:

 

Firma iks forever posiada dostęp do ogromnej mocy obliczeniowej jak może działać przypadek5 poprostu oni są w stanie wyliczyć coś na podstawie jakiś zgromadzonych danych co może być wykorzystane ale tylko każdego kolejnego dnia po zebraniu danych wyłącznie przez 12 godzin - oczywiście napaleńcy z for są zachwyceni twierdząc że iks forever jest atakowany i lada dzień wszystkie kanały które działają po 12 godzin będą działać non-stop.

W jaki sposób to jest obliczane - nie wiem i nie mam czasu zawracać sobie głowy jakimiś bzdurami typu że coś gdzieś działa ale w jaki sposób działa w przypadku tej firmy jestem pewien  że oni nie złamali nigdy na poważnie niczego.

 

Sorry ale ja nie mam czasu na takie bzdury od siebie dodam że jeśli coś działa w iks forever to jest czymś ostatnim w co mógłbym uwierzyć że zostało kiedykolwiek złamane generalnie na rozpracowanie systemu z zabezpieczeniami łącznie z uruchomieniem dostępu wykonania tzw. root jailbreak potrzeba z wielu lat być może dziś da się to wykonać szybciej przy wykorzystaniu pomocy od AI jednak sama sztuczna inteligencja nie będzie w stanie przewidzieć wszystkiego i wykonać całej roboty sama.

Czy wobec tego wszystkiego powinnem uwierzyć że ktoś był w stanie posiąść klucze L1 być może gdybym potrzebował takie klucze pogrzebałbym w zabezpieczeniach starych telefonów z certfykacją widevine. 

 

Czy zrobiłbym to w 2025r ? - nie dlatego że się nie opłaca prawdziwa zabawa zacznie się w przyszłości kiedy aktywują parowanie sprzętowe w HDMI jednak w tych czasach same widevine na 99% zostanie zastąpione czymś nowszym.

 

Edytowane 2 godziny temu przez trójkowy

[adas13]

Widevine vs NDS, SoC jest wszedzie, CC rowniez, pod Andka masz bardzo duzo publik, nawet amlogic SDK znajdziesz, wyzwanie w DRM jest inne, tutaj nic nie liczymy 

 

Narazie Adas

[cezar07]

@trójkowy

- wiesz goście piszą ze z tym forever maja zawsze taka sama drogę czyli jak pojawia się jakaś platforma najpierw jakiś czas tak sobie włączają potem wyłączają aż w końcu działa juz normlanie; było tak z nova sky itd. Wiec wygląda ze nie tylko z nds tak będzie ale z  nagra tez .....

- ty piszesz strikte o wyciąganiu kluczy ale w sumie czy to jest potrzebne ??? jak by sie dalo z oryginalnego boxa/modułu wyciągać cw i potem już słać to po co karta w boxie na enigmie jak byś mógł pytać o cw 10 kanałów na raz box/modul ...

- inna teoria związana z forever jest taka ze oni sa habem czyli ktos cos tam rozkiwał i sle im. Dawniej  takie myślenie bylo bardzo rozpowszechnione zwłaszcza jeśli chodzi o nds. Ciekawe jest to ze najpierw w totaltv można było wyliczyć klucz ale to zmienili niby wprowadzili o wiele dłuższy klucz a teraz ten pakiet znów wrócił 

 

@adas13 i @trójkowy ale wracając do początku tematu to po co nam w domu takowy klucz ?   ze uruchomimy sobie w domu lepsza jakość; ze zamiast oglądania w oryginalnym boxie śmignie nam to w pluginie . Czy o to by to uruchomić w specjalizowanym programie do iptv ale czy nie będziemy mieć ograniczenia co do ilości zapytań kanałów itp ? 

[trójkowy]

@cezar07 

 

Cytat

@trójkowy

- wiesz goście piszą ze z tym forever maja zawsze taka sama drogę czyli jak pojawia się jakaś platforma najpierw jakiś czas tak sobie włączają potem wyłączają aż w końcu działa juz normlanie; było tak z nova sky itd. Wiec wygląda ze nie tylko z nds tak będzie ale z  nagra tez .....

- ty piszesz strikte o wyciąganiu kluczy ale w sumie czy to jest potrzebne ??? jak by sie dalo z oryginalnego boxa/modułu wyciągać cw i potem już słać to po co karta w boxie na enigmie jak byś mógł pytać o cw 10 kanałów na raz box/modul ...

- inna teoria związana z forever jest taka ze oni sa habem czyli ktos cos tam rozkiwał i sle im. Dawniej  takie myślenie bylo bardzo rozpowszechnione zwłaszcza jeśli chodzi o nds. Ciekawe jest to ze najpierw w totaltv można było wyliczyć klucz ale to zmienili niby wprowadzili o wiele dłuższy klucz a teraz ten pakiet znów wrócił

Ja nie mam czasu na takie domysły rozwiązywanie łamigłówek z forum.

 

Cytat

@adas13 i @trójkowy ale wracając do początku tematu to po co nam w domu takowy klucz ?   ze uruchomimy sobie w domu lepsza jakość; ze zamiast oglądania w oryginalnym boxie śmignie nam to w pluginie . Czy o to by to uruchomić w specjalizowanym programie do iptv ale czy nie będziemy mieć ograniczenia co do ilości zapytań kanałów itp ? 

Właśnie pytanie "po co" ponieważ dane zabezpieczenia się łamie tylko gdy jest w tym sens i jest to opłacalne , siła zabezpieczeń opiera się głównie o te dwa czynniki. 

 

@cezar07 - ty piszesz strikte o wyciąganiu kluczy ale w sumie czy to jest potrzebne ??? jak by sie dalo z oryginalnego boxa/modułu wyciągać cw i potem już słać to po co karta w boxie na enigmie jak byś mógł pytać o cw 10 kanałów na raz box/modul ... ------------> gdybym nie był operatorem pay-tv stwierdziłbym że stare wersje kart " " zostały poprostu złamane jest to jak najbardziej możliwe jeśli ktoś posiada dane z tych kart napewno część posiadanych informacji będzie mógł wykorzystać do różnych powiązanych celów. 

 

@cezar07 ostatnia wersja viaccess 2.6 to nie był hack laboratoryjny to wykonały osoby posiadające niewielki budżet i tak ten hack nie było napewno ostatnim śmiem twierdzić że jest ich znacznie więcej dziś już nikt nie zawraca sobie głowy kluczykami z dekoderów.

Edytowane 1 godzinę temu przez trójkowy