The source blog post suggests it's exactly that. Whether that's scary or not depends on your perspective - I doubt it will prevent any material from leaking out, but it certainly could encourage companies to restrict video playback to devices that support the feature, which would be rather annoying for users of other devices. That is, if manufacturers bother to actually use it...
At this point in the development of ARM, an argument against TZ-aware video blocks is basically an argument that ARMH should deliberately hamstring its IP blocks to prevent them from being used to implement content protection, right? TZ isn't spooky DRM technology.
TZ in video decoders has little use other than content protection, and ARM is explicitly positioning it for use as such. While the article is certainly very hyperbolic, and many more steps will need to be taken before an annoying scenario of the type I described is likely to come to pass, I think it is a valid concern.
Any security feature in a video decoder is going to be designed for rightsholders. :)
If you're concerned about content protection, the inevitability of hardware-assisted content protection as hardware security improves is a valid concern.
But since TZ is (a) a technology with more non-DRM uses than DRM uses and (b) a fundamental part of the overall ARM architecture, not extending it to other ARM IP blocks would have been an odd choice. That's all I'm saying.
> it certainly could encourage companies to restrict video playback to devices that support the feature
So if I want to buy a legal download, I'll have all sorts of hassle along the lines of "will it work on my hardware?", but if I get a pirate Torrent, then I know it'll work? If that's the scenario, I won't even consider going the legal route.
it sounds like the gpu basically has some keys and does the decryption before sending the stream to the screen.
ie you'd need to dump the keys from the hardware or find a flaw in the implementation or dump what the screen gets, basically.
the last one always works, although its not very neat.
The best way to understand TZ is to understand how virtualization works (that's not what TZ is, but still); think of it like a hardware chroot(2) jail.
So we can expect a break (possibly via PubKey replacement) for it by some hacker adept at machine code in 10... 9... 8...
Meanwhile, what would really determine whether or not this is scary is adoption. Until a fair number of TVs, set top boxes, smartphones or what have you, actually start to carry the thing, there's nothing to worry about yet.
As long as the device is properly integrated, TZ provides protection against software attacks - the hardware prevent accesses to sensitive areas by the regular OS. Machine code skills won't help unless the implementation is flawed.
It doesn't sound like anything new. The current SoC specific solutions typically have dynamic firewalls configured on a per IP block basis interacting with some crap in trustzone.
I suppose the thing that is new is ARM offering this kind of IP off the shelf (maybe).
Even when they're right about how heinous the latest legal and/or technical stunt the Copyrights Über Alles crowd has gotten up to is, when is Torrentfreak not hyperventilating?
Their reason for hyperventilating is ad impressions. Their business model is telling (former) digg users how awesome they are and how evil the xxAA's are.
It is not about cracking. It is about control. The ability to third party to execute code on your device without your knowledge or oversight makes the world more insecure place.
This definitely doesn't sit right with me, and it will hurt sales if they move forward with hardware DRM. Is it going to allow me to play content that I purchased physically and ripped? If I can run a ripped version, what stops me from running a friend's ripped version?
Either it will lock people out of their own stuff, or it will be totally useless. I hope for ARM's sake that it's ineffective.
Yes, you can play your own media. What this does is to keep the entire process of media decryption outside of the control envelope available to the (regular) OS, so not only are keys not visible but also decrypted content is also not exposed outside the secure environment. But this is only for encrypted media from a organisation that is using a TrustZone infrastructure - all other media will continue to work as today.
At some point the decrypted content has to be exposed outside of a secure environment in order for us to see it. Could you possibly intercept the signals sent to individual pixels, or would you have to actually film your screen?
HDMI out is pretty common on the types of high end phones and tablets that this sort of chip would target. HDCP is long-since broken, so none of this matters to pirates unless the content people also force the device makers to kill HDMI out as a feature which seems untenable. But the pirates are just going to keep ripping the Bluray discs leaked out a month or more prior to retail release anyway since that's even easier. As with the vast majority of DRM, this will only fuck over legitimate users. Pirates will still download the torrent, whether it comes from a Bluray rip, captured HDMI or as a last resort the analog hole.
That makes no sense. You might not be able to get at the decrypted pathway from software, but at some point there's got to be a decrypted linear buffer to drive the pixel array.
Large American institution with a history of infringing on people's rights attempts to enforce a design of a commercial computer chip? Hmm, where have I heard of that before...?
Who, other than the copyright lobby, would be demanding this technology? Users are not going, "Gee, I wish my computer would stop me from committing piracy!"
But if you're writing about one entity doing something, you have to at least give me the right name of said entity. You can't write with the informal definition.
When I saw this I remembered about the time Netflix launched on Android, and how they only made the app available only on certain devices with "hardware DRM" [1], at least initially.
So I don't think ARM was the first to do this. Both Qualcomm and TI seemed to have some kind of hardware DRM before, although ARM may try to "out-compete" them in this department now, and offer a more advanced/harder to crack solution, which can only mean Qualcomm and Nvidia will probably offer something similar in the future.
> available only on certain devices with "hardware DRM" [1], at least initially.
> So I don't think ARM was the first to do this.
There's two things going on here, the "old" thing is secure boot / secure os, which is a hardware/software solution that only allows signed code to be run on devices. I think this is what was meant by the original Netflix announcement.
The "new" thing here is hardware memory protection for video data that is there to prevent the CPU, GPU or other engines on the SoC from accessing protected memory and only the display controller is allowed to read it.
Even if it is still hardware-based, they must download a movie definition file somewhere for future movie reference. If not, then it seems that the only movie segment they would be comparing the signatures to is the intro credits or at the last part of the credit scene. This is just my speculation of how this might work.
Curious about this article I went on a short research trip down content protection lane. Now, if I understand correctly, high-definition media is re-encrypted at each link in the chain from origin to display device (let's not mislabel this as "end-to-end encryption"), which is why HDCP has to be as much a legal construct as it is an engineering one (and broken in both domains).
Since unlicensed HDCP strippers (basically counter-encryption devices that take encrypted HDMI in and talk unencumbered HDMI out) can be ordered straight off Alibaba, I don't see how this processor is any further impediment to the systematic bootleggers of high-definition content and its redistribution in alternative forms.
I concluded that the practical application is therefore limited to impeding the casual viewer from cloning original media files or streams.
What it further provides is another sterling opportunity for interoperability failure between devices.
How do "casual viewers" clone media streams anyways? They aren't so casual at that point. Whatever hacks a casual viewer needs in order to copy a stream, they could just as easily download a DRM-stripped one. So, on the surface, it does not seem like this helps anything at all.
The only effect of HDCP I've ever seen is sometimes AppleTV can't stream Netflix because of an HDCP error.
48 comments
[ 3.9 ms ] story [ 83.2 ms ] threadIf you're concerned about content protection, the inevitability of hardware-assisted content protection as hardware security improves is a valid concern.
But since TZ is (a) a technology with more non-DRM uses than DRM uses and (b) a fundamental part of the overall ARM architecture, not extending it to other ARM IP blocks would have been an odd choice. That's all I'm saying.
So if I want to buy a legal download, I'll have all sorts of hassle along the lines of "will it work on my hardware?", but if I get a pirate Torrent, then I know it'll work? If that's the scenario, I won't even consider going the legal route.
ie you'd need to dump the keys from the hardware or find a flaw in the implementation or dump what the screen gets, basically. the last one always works, although its not very neat.
Meanwhile, what would really determine whether or not this is scary is adoption. Until a fair number of TVs, set top boxes, smartphones or what have you, actually start to carry the thing, there's nothing to worry about yet.
I suppose the thing that is new is ARM offering this kind of IP off the shelf (maybe).
The notion of hardware DRM -- the movie industry controlling your device at a hardware level is frustrating enough to me.
Either it will lock people out of their own stuff, or it will be totally useless. I hope for ARM's sake that it's ineffective.
http://en.wikipedia.org/wiki/Clipper_chip
Unless it's tinfoil hatism, he must provide at least one credible source other than "Hollywood approved"
And nobody but them have interest of that.
But if you're writing about one entity doing something, you have to at least give me the right name of said entity. You can't write with the informal definition.
So I don't think ARM was the first to do this. Both Qualcomm and TI seemed to have some kind of hardware DRM before, although ARM may try to "out-compete" them in this department now, and offer a more advanced/harder to crack solution, which can only mean Qualcomm and Nvidia will probably offer something similar in the future.
http://blog.laptopmag.com/netflix-for-android-demoed-on-qual...
There's two things going on here, the "old" thing is secure boot / secure os, which is a hardware/software solution that only allows signed code to be run on devices. I think this is what was meant by the original Netflix announcement.
The "new" thing here is hardware memory protection for video data that is there to prevent the CPU, GPU or other engines on the SoC from accessing protected memory and only the display controller is allowed to read it.
Since unlicensed HDCP strippers (basically counter-encryption devices that take encrypted HDMI in and talk unencumbered HDMI out) can be ordered straight off Alibaba, I don't see how this processor is any further impediment to the systematic bootleggers of high-definition content and its redistribution in alternative forms.
I concluded that the practical application is therefore limited to impeding the casual viewer from cloning original media files or streams.
What it further provides is another sterling opportunity for interoperability failure between devices.
The only effect of HDCP I've ever seen is sometimes AppleTV can't stream Netflix because of an HDCP error.
Phones are harder to control than laptops? That seems unlikely.