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.