Hacker News Reader

Comment by trollied | Hacker News Reader

Just goes to show that the DRM is just security through obscurity.

True for Widevine L3, which is what the article is talking about. Not true in general, and not true for L2 or L1.

At the end of the day, the user's hardware/software has to be given a decryption key for the content, and the DRM scheme is all about obfuscating that encryption key so that users can't find it.

I’d say that a key stored on hardware is not merely obfuscated, when that hardware is designed to prevent you from recovering the key.

The hardware ultimately has to decrypt and play the content, so you can use it as a decryption oracle even if you can't extract the key itself.

Sort of, within constraints. L1 both decrypts and decodes, so you can’t really use it as a pure decryption oracle, but it doesn’t matter if you’re going to re-encode it anyway.

Not that it really matters, since HDCP has been cracked. There are a lot of holes here and a lot of problems with DRM.

Eehhh at the end of the day, L1 is still almost impossible to bypass and hasn't been broken in years. So it still works, meaning it doesn't really matter even if it's security by obscurity (I dont think it qualifies for the term but anyways).

If it hasn't been broken, then where do all those 4K HDR torrents come from?

Nvidia Shield[0]

0: https://forum.xda-developers.com/t/nvidia-shield-pro-widevin...

From cracked HDMI HDCP?

Circumventing higher levels of Widevine has been unnecessary until now, since the HDCP protecting the inevitable HDMI video output has been thoroughly cracked. Pristine 1080p and 4k copies of Netflix content is widely available.

> since the HDCP protecting the inevitable HDMI video output has been thoroughly cracked

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.)

You're right that there is plenty of directly stream-ripped content out there, presumably using cracks of various levels of Widevine. The makers of these tools and the groups using them tend to keep quiet about the details of the precise exploits they're using, for obvious reasons. Ultimately, there's no shortage of DRM-free 4K content, whether from streaming services or Blu-Ray, since there's always a weak point in the chain somewhere.

Yeah. With blurays, you can always extract the device key out of some Bluray player. It's an extremely poor user experience for bluray consumers to have their devices stop working for new movies, so my impression is these keys aren't blacklisted all that quickly. For the streaming sites, I have no idea. But, yeah, the cleartext bits need to get in front of the user eventually.

BluRay has two security systems. One is based on key revocation (AACS) and one is based on embedding programs written by companies contracted by the movie studios which do dynamic detection of rippers. AACS failed almost immediately because indeed, keys leaked faster than they could be revoked. BD+ proved much harder, at least in the early years. But it was only ever designed to last about 10 years according even to the sales pitch of the designers and it's older than that now, so I wouldn't expect it to be all that effective anymore especially since Intel pulled SGX from their client chips.

Capturing video via HDMI is less than optimal, since you then have to encode a 2nd generation lossy copy. Ideally, you want to decrypt the original audio and video streams before they've been decoded and sent to the display.

L1 has been bypassed by piracy groups for years (through social engineering). They just don't share the keys publicly because it would give their opponents an advantage. See [1].

[1] https://news.ycombinator.com/item?id=29702110

True, I didn't realize those were l1 keys. I'll have to read up on the revocation mechanism, if there is any. I'm also wondering how those keys usually leak. Is it through vulns, or just exploiting unsecure key handling?

The Nexus 6's L1 keys were dumped through a vulnerability in Qualcomm's trusted code execution environment.

http://bits-please.blogspot.com/2016/05/qsee-privilege-escal...

https://googleprojectzero.blogspot.com/2017/07/trust-issues-...

I'd argue the same goes for L1 and L2. But the obscurity is provided by the silicon packaging process.

Would be nice to crowdfund a lab to break these hardware backed treachery schemes.

When you say “security through obscurity” there’s a certain understanding that we’re drawing a line between implementation secrecy (obscurity / obfuscation) and key secrecy. If we extend the word “obscurity” to include the notion of physical security, I think we’ve gone too far—even if physical security is just the physical security of a secret embedded in silicon that you have physical access to (because it is super difficult to recover secrets from silicon).

With DRM the user who owns the machine is the "attacker". The keys have already been handed to the user, he only needs to get them out. This is like hiding an API key in a public website's javascript with rot13. Very much security by obscurity.

Proper security means that the attacker should never be in possession of the key.

You’re saying that a hardware security module is like rot13?

When you say the attacker “only” needs to get them out, the “only” is doing a lot of work, there.

Yes, but it only has to be done once.

The standard for cryptographic security is that the attacker can do no better than brute force. And the complexity for that is usually set high enough that it is out of range for the entire computational capacity of our civilization for years to come.

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 same goes for the HSMs that power the internet's certificate authorities then. If there were a precise enough CT scan that could read the current state of atoms and flash, we'd have a major security problem.

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).

Ah the Tegra X1 bootrom exploit is the gift that just keeps on giving. I instantly bought a switch when the news came out.

While cracking the hardware is an interesting technical challenge, it is certainly not the only method. Security is only as good as the weakest link -- the human factor. Thus, piracy groups are able to use social engineering to crack Widevine without relying on advanced laboratories. See [1].

[1] https://news.ycombinator.com/item?id=29702110

I believe that L2 would be weaker than L3 in practice, which likely explains why I've also never seen it implemented (If you know about an L2 instance I would be genuinely interested in taking a look)

> I believe that L2 would be weaker than L3 in practice

How come?

According to the descriptions I can find, L2 does cryptography in secure hardware, but video decoding in software. (as opposed to L3 that does both in software, and L1 that does both in hardware).

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)

security through obscurity is generally not about keeping a well known encryption scheme's keys "private". It's generally about not knowing how a system works at all. In this case (and the same for blurays actually), we know exactly how the system works, given the keys we could decrypt the content, but the keys are kept "well" protected (depending on widevine level, different levels of protection). In BluRay land enough player keys have leaked to make it basically irrelevant. It's also harder to determine whose keys are being used to decrypt, making it harder to revoke. In an online widevine world where one has to use one's baked in device keys to get the content key, its much easier to determine if a single device's key is being used an abnormal amount of time and then revoke it.

while one can view the efforts to protect a widevine l3 key as security through obscurity, its mostly there to make the effort hard enough that most people are interested in doing it, than to keep it perfectly secure.

The “security through obscurity” chant needs to die. It’s such a generalized concept it applies too broadly.

Encryption is “security through obscurity”.

Having few admins is security through obscurity; a guessing game of who is the admin?

Reply on news.ycombinator.com