Slashdot Mirror
Security Researcher Cracks Google's Widevine DRM (L3 Only) (zdnet.com)
The L3 protection level of Google's Widevine DRM technology has been cracked by a British security researcher who can now decrypt content transferred via DRM-protected multimedia streams. ZDNet's Catalin Cimpanu notes that while this "sounds very cool," it's not likely to fuel a massive piracy wave because "the hack works only against Widevine L3 streams, and not L2 and L1, which are the ones that carry high-quality audio and video content." From the report: Google designed its Widevine DRM technology to work on three data protection levels --L1, L2, and L3-- each usable in various scenarios. According to Google's docs, the differences between the three protection levels is as follows:
L1 - all content processing and cryptography operations are handled inside a CPU that supports a Trusted Execution Environment (TEE).
L2 - only cryptography operations are handled inside a TEE.
L3 - content processing and cryptography operations are (intentionally) handled outside of a TEE, or the device doesn't support a TEE
"Soooo, after a few evenings of work, I've 100% broken Widevine L3 DRM," [British security researcher David Buchanan] said on Twitter. "Their Whitebox AES-128 implementation is vulnerable to the well-studied DFA attack, which can be used to recover the original key. Then you can decrypt the MPEG-CENC streams with plain old ffmpeg." Albeit Buchanan did not yet release any proof-of-concept code, it wouldn't help anyone if he did. In order to get the DRM-encrypted data blob that you want to decrypt, an attacker would still need "the right/permission" to receive the data blob in the first place. If a Netflix pirate would have this right (being an account holder), then he'd most likely (ab)use it to pirate a higher-quality version of the content, instead of bothering to decrypt low-res video and lo-fi audio. The only advantage is in regards to automating the pirating process, but as some users have pointed out, this isn't very appealing in today's tech scene where almost all devices are capable of playing HD multimedia [1, 2].
L1 - all content processing and cryptography operations are handled inside a CPU that supports a Trusted Execution Environment (TEE).
L2 - only cryptography operations are handled inside a TEE.
L3 - content processing and cryptography operations are (intentionally) handled outside of a TEE, or the device doesn't support a TEE
"Soooo, after a few evenings of work, I've 100% broken Widevine L3 DRM," [British security researcher David Buchanan] said on Twitter. "Their Whitebox AES-128 implementation is vulnerable to the well-studied DFA attack, which can be used to recover the original key. Then you can decrypt the MPEG-CENC streams with plain old ffmpeg." Albeit Buchanan did not yet release any proof-of-concept code, it wouldn't help anyone if he did. In order to get the DRM-encrypted data blob that you want to decrypt, an attacker would still need "the right/permission" to receive the data blob in the first place. If a Netflix pirate would have this right (being an account holder), then he'd most likely (ab)use it to pirate a higher-quality version of the content, instead of bothering to decrypt low-res video and lo-fi audio. The only advantage is in regards to automating the pirating process, but as some users have pointed out, this isn't very appealing in today's tech scene where almost all devices are capable of playing HD multimedia [1, 2].
I imagine that the main area of interest(aside from people doing cryptoanalysis for its own sake or professionally) is in getting output that hasn't been decompressed, potentially resized or munged a bit by the decoding device's particular color profile; and finally grabbed off the HDMI output and recompressed.
If the stream provided to L3 clients is lousy enough you may still come out ahead by qualifying for L1-super-premium-secure and then HDCP stripping; but the clean copy will be worse than what was originally provided.
There's also the matter of convenience: HDMI framegrabbers are much cheaper than they used to be; but setting up a capture arrangement based on one is still way more of a hassle than just being able to clean up a media file with just a little bit of software manipulation. Unless the provider caps the download bitrate to 'just fast enough for real-time, maybe 30-90 seconds of buffer to cover for glitches' the software attack is likely to be faster as well: analog hole or HDCP strip attacks are usually real-time at best(sometimes slower if re encoding is computationally expensive) unless the target can be coaxed to play back at greater than 1x speed and your capture device can cope with it
Probably not going to set the world on fire in the Bluray rip scene; but could be very popular indeed for services that forbid or tightly restrict offline use in favor of streaming only and people who want access to that media when out and about without burning tons of cell data. Small screen makes resolution less of a concern and the fact that most phones don't exactly support simultaneous HDMI output and HDMI capture and encoding makes a pure software attack attractive.