Would be nice to crowdfund a lab to break these hardware backed treachery schemes.
Proper security means that the attacker should never be in possession of the key.
When you say the attacker “only” needs to get them out, the “only” is doing a lot of work, there.
I'd say handing the key to the attacker in a package that requires somewhere between a skilled reverse-engineer and a semiconductor lab to untangle falls far short of that standard.
The only reason L1 doesn't prevent people from pirating 4K HDR movies is because the Nvidia Shield has a bypass, and Google is too afraid to revoke its keys (or maybe Nvidia is paying millions of dollars a year to rights holders for their 'lost sales' from pirated movies at the hands of the Nvidia Shield).
Not that it really matters, since HDCP has been cracked. There are a lot of holes here and a lot of problems with DRM.
0: https://forum.xda-developers.com/t/nvidia-shield-pro-widevin...
My impression is the stuff coming from the various streaming services is not captured and reencoded, but direct bit-for-bit copy of the original H.264 (or H.265) encoding (sans DRM). (Yeah, others will do reencodes later but quite a bit of the source material encoding comes directly from the streaming sites.)
http://bits-please.blogspot.com/2016/05/qsee-privilege-escal...
https://googleprojectzero.blogspot.com/2017/07/trust-issues-...
How come?
In L3, you can obfuscate the cryptography and the video codecs together as a unit, blurring any defined border between them. A determined reverse-engineer can inevitably unravel that obfuscation, but it's non-trivial.
In L2, there must be some interface between the hardware and software components. That interface presents itself as a very obvious weak point. As an attacker, all you'd have to do is watch the data flowing out of the cryptography hardware, and into the video decoder software, and you'd be able to siphon out the plaintext video data.
(To be clear, this is entirely "in theory" because I've never seen an L2 implementation)