This is a wonderful example of how deeply ingrained Hollywood is into design cultures. The whole reason for this is to preserve the 'security' of HDCP – an anti-consumer technology at its finest.
Note that, despite this, you can still find basically any movie you want on popular websites – the only people who suffer are paying consumers.
DRM is a lot more about manufacturers than consumers. This isn't a justification, but rather adding a wider view of the issue.
See the licensing costs here.
What is the cost for express processing?
$5,000 USD per "Multiplier".
What is the smallest number of Device Key sets that can be purchased?
The quantities and prices for key orders are listed below:
Description Cost (USD)
HDCP 1.x Transmitter or Receiver Key - Qty of 10,000 $2,000 USD
HDCP 1.x Transmitter or Receiver Key - Qty of 100,000 $5,000 USD
HDCP 1.x Transmitter or Receiver Key - Qty of 1,000,000 $10,000 USD
HDCP 2.x Annual Source Key Fee - Up to 100/year $500 USD
HDCP 2.x Annual Source Key Fee - Up to 1K per year $1,000 USD
HDCP 2.x Annual Source Key Fee - Up to 10K per year $2,000 USD
HDCP 2.x Annual Source Key Fee - Up to 100K per year $5,000 USD
HDCP 2.x Annual Source Key Fee - Up to 1M per year $10,000 USD
HDCP 2.x Annual Source Key Fee - For quantities over 1M per year $20,000 USD
HDCP 2.x Receiver Key - Qty of 10,000 $2,000 USD
HDCP 2.x Receiver Key - Qty of 100,000 $5,000 USD
HDCP 2.x Receiver Key - Qty of 1,000,000 $10,000 USD
The licensing costs you list are tiny and irrelevant as a revenue stream, and seem just like something in the ballpark to cover the overhead (legal, etc) of that licensing and distribution. For a manufacturer making a million devices, a literal 1 cent per device is not a major change, and on Hollywood scale collecting a five-figure amount per manufacturer isn't meaningful either.
Heh, yeah. But one form of cp isn't socially accepted at all, while the other one is. The one which is, is much much much easier to find.
Now that I think of it: it (rampant piracy of audio and video) is a great practical example to teens why they should not share pictures of themselves naked. If someone wants to, it gets spread. Even if there's 'copyright protection'. In some circles, Snapchat is seen as seriously private. Which is very ignorant, and has lead to situations like blackmailing and retaliation porn.
My previous company made monitors, and my chinese colleague told me this rumor that some of the mainboard vendors would offer "real" or "fake" HDCP, fake meaning that you could turn the monitor mainboard into a HDCP stripper.
Now I don't know how they could offer this, and I don't know how a new HDCP key is issued when a leaked one is blacklisted. I assume the engineer just didn't care or maybe the key was already old.
HDCP is broken so thoroughly that keys don't matter any more, and revoking them would break hardware on a scale that would put the F00F bug remediation cost to shame.
Some HDMI splitters commonly sold online are reportedly capable of stripping HDCP protection. I could never verify that, so I cannot point to a specific model, but a simple search seems to confirm that.
Why does this also affect Display Port? Is the document elsewhere stating that both are intertwined?
It is depressing how “intellectual property” damaged computing. Just imaging a critical bug needs fixed in 15 years and the key signing utility is not available because ${RANDOM_CORP} disappeared. Don’t say that couldn’t happen: Nokia, Sun, DEC, Apple (nearly bankrupt 1998), 3DFX, Aureal and so on. And this lists only the ones where the employees are no longer available. Other just cancel support. Broadcom - which I know avoid - doesn’t care anymore about their BLE 4.0 chips and the (security) issues.
Seeing how Netflix and others succeeded with a flatrate model - which is the actual solution - this is completely unnecessary. The authorities missed to create institutional ways for creators to collect money, just awkward unfair taxes on harddisks and VHS-Tapes. Which streaming did?
Both HDMI and DisplayPort can use HDCP. The authors of the DisplayPort standard also invented their own clone of HDCP called DPCP, but you can also use HDCP over DP, and it seems like HDCP is a lot more popular(?). In any case the DRM implications (in terms of lockdown and code signing) are the same. Though not explicitly mentioned in the screenshots of the i.MX8M reference manual shown in the article, reading the rest of the manual it's clear DP is affected too. (Which, again, is why the MNT Reform forewent the use of the DP interface to attach their eDP internal display in favour of a MIPI DSI to eDP bridge.)
I certainly agree that restrictive code signing practices like these are completely unacceptable. In my view, the 'right to repair' movement should encompass a right to any keys needed to fix bugs, though I am not optimistic about 'right to repair' being interpreted in this way.
Worth noting that while we usually think of DRM as a (patently ineffective) way to prevent piracy, in reality it seems to be much more about controlling end devices and the manufacturers of end devices. I explain more about this here: https://news.ycombinator.com/item?id=17588610
> (Which, again, is why the MNT Reform forewent the use of the DP interface to attach their eDP internal display in favour of a MIPI DSI to eDP bridge.)
There's only one display interface capable of driving DP/HDMI on i.MX8M, so if they didn't do that they wouldn't have external HDMI port.
Don't forget how they killed DAT before it even had a chance to get going. Consumers were stuck with analog casette mixtapes for another decade or more unnecessarily.
The worst part is what it did to indie/amateur musicians. The only models allowed to record at 44.1 were "professional" that cost a lot more than the very few consumer models that were only allowed to do 32k and 48k.
If the end user is going to play it at 48k (trivial today) then it is absolutely better.
Back in the 1990's independent/aspiring musicians needed to make CD's to send out to labels/radio stations/sell to fans. CD Audio is fixed at 44.1KHz. Transcoding 48k to 44.1 generates undesirable artifacts, especially back then when you likely had to convert to analog first.
> Just imaging a critical bug needs fixed in 15 years and the key signing utility is not available because ${RANDOM_CORP} disappeared.
It doesn't even need to be a corporation disappeared; it could be they decide they don't want to sign things anymore. As a application developer you have to make a choice --- how long do you want your last and final build to work, knowing it's impossible to fix any client side issues after that, and you can't extend it later.
> Therefore, it is impossible to ever replace the HDMI blob used by this device. The device could be used without this blob, but you then forego use of the HDMI (or DisplayPort) functionality.
> Note about the MNT Reform: The MNT Reform went out of its way to avoid relying on this blob for its internal display. Rather than doing the obvious thing and connecting the i.MX8M's DisplayPort interface to the Embedded DisplayPort (eDP) display panel, they connected the internal display by using the i.MX8M's MIPI DSI interface (which is unaffected by this blob) to connect to a MIPI DSI to eDP converter chip, and then to the display (indeed, the fact that they went out of their way to ensure people can use the laptop without the blob certainly warrants praise). The external HDMI port can't be used without the blob, however.
Just a note: i.MX8MQ has only two display interfaces - one (less power hungry) is only capable to drive MIPI-DSI, and another bigger one that can drive either MIPI-DSI or HDMI/DP. If a i.MX8MQ system wants to support both eDP and external HDMI at the same time, it simply has to use MIPI-DSI with a converter on one of its outputs, there's no way around it.
Some, probably. But that firmware is self-contained to the converter chip, and doesn't have the ability to interact with your CPU's various subsystems.
The i.MX8's HDMI core has independent access to the DDR memory, peripheral buses, timers, DMAs, and who knows what else. It's probably even running an RTOS of some kind, which might or might not include network drivers. Malicious firmware could compromise the security of your entire device.
It's kind of the same problem that some folks have with Intel's IME. It could be fine and secure. Or maybe not, we just don't know.
Nobody's saying that the i.MX8's HDMI firmware is malicious. It's probably fine. But we also don't know, because we can't inspect it. So if you were designing that chip into a security-critical setting, you'd have to wonder what might be running without your knowledge.
There really is no way out of this beyond regulation? Yet I doubt governments will side with consumers on this one (even in Europe) given their stance on copyright on behalf of ip holders, so there is no way out.
The thing I keep thinking about are things like pace makers and other medical devices that become useless implants once biotech companies go under. May be today it seems like the company you're getting the blobs from will be around but one day it won't be (or won't care to be) and then what are you going to do? May be something like this or an SBC doesn't matter as severely as a pace maker but anytime anyone builds something with these socs they run the risk that their product will be a dead weight in 10 years.
But of course, that doesn't matter for most developers, just those of us who want to stop the endless technopollution in tech, make things that last, you know.
Europe, and the EU to be more accurate, is rabidly pro copyright. They might also be pro consumer, usually, but not when discussing copyright. Just look at the EU copyright laws that were recently pased. Or the stranglehold copyright lobbies have on member states (the music industry in Germany, for example)
In general, the US is more lenient and has a broader definition of fair use.
Germany doesn't even have a general fair use doctrine in the first place! It's really horrendous.
Most countries' governments outside the US also assert copyright on their own works, which is ridiculous IMO, but is a good representation of the entire concept of the US: legitimacy is derived from the people themselves. The government can't have copyright because The People as a whole own the work.
Unless there is an exploitable bug in the bootloader, or the HDMI memory locking logic, or someone leaks the key.
Or, cleaner but less "realistic", the people making these things just sit down and decide to release the key, or make chips without the limitation. I mean it is all man-made, there is no physical law saying this can't be done. If you ignore the financial and IP dimensions for a second, just on technical merits, it is a no-brainer.
In a mystical insekai style other world SoC makers should be have to release their keys once they decide to discontinue their chips or not recommend them for new designs, but alas we live in this world.
Copyright is supposed to be public protection in exchange for works entering the public domain.
Copyright is an automatic right (though I understand you still have registration in USA which increases damages available) but should not be applied to DRM works that haven't had DRM-free copies lodged with a government or authority (eg WIPO).
DRM encumbered works cannot ever enter the public domain and so cannot fulfill the requirements for copyright.
This is of course my own personal opinion, unrelated to my employment.
> Copyright is supposed to be public protection in exchange for works entering the public domain.
That's a curious legal theory. What evidence do you have for it being shared by anyone else, yet alone the legal system? What jurisdiction is it supposed to apply in?
Since the MNT Reform was mentioned in the article, it's worth pointing out that the way they handled this was to have HDMI disabled by default, and the user can then run a script to re-enable HDMI and reboot.
When HDMI is disabled, the only non-free blob left is the DDR4 controller training blob.
Author here. MNT actually went out of their way to make sure you could use the device without this blob: rather than do the obvious thing and wire up HDMI or DP to the laptop's internal display (both of which require the blob), they used the MIPI DSI interface and a DSI to eDP converter chip.
But yeah, if you want to use the external HDMI port on the laptop, you need the blob.
It's times like this when I think we could only proceed if someone working there "leaked" the code (or, more precisely, a functional representation of its logic) to a group of secretive reverse-engineers and they came up with a credible clean room implementation
Author here. As the comment above notes, it's a leak of the signing keys which would be needed to free this. The actual blob itself can be reversed and replaced with enough of someone's time. The only other prospect is a flaw in the code which verifies the signature. The PS3 ECDSA break was an amusing example of this (though technically in that case, actually a flaw in the signing code, not the verifying code).
But the thing is, if those keys were to be leaked the damage would be irrepairable. You could legally donwload the reverse engineered firmware and then "acquire" the key and plug it in.
They won't be leaked, though. With a large western coompany like NXP, especially being that it's one with crypto-related business units, it's basically guaranteed that the keys will be in an HSM. There's always a slight chance they're inept and the private key is sitting in someone's home directory and they could decide to leak it, but in this case the chances seem very low.
Might have better luck with the Taiwanese hardware vendors - as I recall a major Taiwanese PC motherboard maker got hacked recently and UEFI secure boot keys were taken, so they probably weren't storing them in an HSM and don't have proper security practices in place for cryptographic material.
The code is useless without the keys used to sign it; even if you get a custom blob, you are unable to have it recognized by the device in question. This is tivoization at its finest.
Author here. Yes - the obvious way to wire up the internal display of the MNT Reform would have been to use eDP directly, but since that would require use of the blob, they used the i.MX8M's MIPI DSI interface instead and used a DSI to eDP converter.
Shouldn't you have mentioned this in your article? The way the article is written makes it sound like the MNT Reform is flawed in a way this clarifies it is not.
Not sure what you're referring to. As I state in the article:
>Therefore, it is impossible to ever replace the HDMI blob used by this device. The device could be used without this blob, but you then forego use of the HDMI (or DisplayPort) functionality.
If you use the MNT Reform without the blob you can never use certain features of the device, namely the external HDMI port, so it's not as though the MNT Reform is without flaws. In any case the article is about the i.MX8M, not any specific device.
You explicitly mention the MNT Reform and the Librem 5, which use this chip. I agree that you never say that any given device can't work around this, but that is what I understood from the way this was presented. I was vaguely familiar with the MNT Reform and went looking for that converter chip because I thought they had a solution to this, which they do.
Perhaps if the last bullet point in the article said something about not being able to use HDMI or displayport without a converter chip, it would have been clearer to me.
Author here. Not all HDMI/HDCP implementations work like this. Basically, the designer of the SoC (NXP) will have licenced an HDMI/HDCP IP block from some company selling such IP. It looks like NXP licenced their HDMI/HDCP IP from Cadence in this case, a major provider of silicon IP.
So this particular HDMI/HDCP implementation is designed to require this signed blob in order for it to function. Could Cadence have designed it so you can use it without HDCP without this blob, or use an unsigned blob and forego HDCP support, probably. But they didn't, so that's the situation.
I would assume it’s because the i.MX8 has no path to not support HDCP, so if you’re using it your choices are not “nothing, HDMI, or HDMI + HDCP” it’s “nothing, or HDMI + HDCP”.
You can find old posts on the NXP forums talking about how disabling HDCP kills HDMI.
If the chip can do TB / DisplayPort, you could add a separate DP -> HDMI converter, but obviously that increases your costs.
So it's impossible to get a HDMI signal out of the chip which can be read by a regular monitor or capture card without decryption keys, even for displaying non-movie images and GUIs? This is utterly disgusting. Or does HDCP turn off when talking to a non-HDCP (eg. DVI) display?
Note that, despite this, you can still find basically any movie you want on popular websites – the only people who suffer are paying consumers.