Hacker News Reader

Comment by Karunamon | Hacker News Reader

This was my first thought as well. It seems these management engine tools have only two uses in the real world: enterprise IT, and various forms of DRM.

Both exist to treat the user as a hostile entity.

View on HN

Well it would be nice for cloud servers, so that you wouldn't have to trust the hosting provider. But given the choice of needing to trust (cloud: intel, home: intel), and (cloud: intel+provider, home: nobody), it would be foolish to not choose the latter!

At the individual level, remote attestation has a particularly terrible end game. Think of all those websites that attempt to enforce their desired business whims client-side, that we rightfully laugh at - browser fingerprinting, image save as, anti-adblock, etc. Now imagine they're successful!

Given the presence of 4k web-dls (original, not reencoded content,) somebody must have the key, or they must have managed to pwn the DRM on an even deeper level, like tapping the memory (which is even worse.)

Another possibility is still a source leak, where 4k content gets lifted off Netflixes own internal content storage.

Or a simple HDMI defeat and re-encode. It only takes one guy to put it out on the net. DRM is an inherently flawed concept.

The content is watermarked by the time it is available on HDMI. The guy who re-encoded it would get a knock on the door.

XOR frames captured via two different accounts.

Wouldn't you need three? Or, better still, do a bitwise 3 of 5 / integer median on the pixel values.

Except if the watermark is terribly designed, that will not work. There is a lot of information that you can hide from the eye in a video.

What would that accomplish? If you want to exclude differences, use AND.

No. HDMI/HDCP does not do watermarking or any other modification to content.

Cinema DCP packages, however, do - it's either watermarked at the DCP distributor or in the decryption module, but that stuff is out of reach for most warez crews.

Even if HDMI doesn't do that, the streaming provider just might. It would be feasible to implement, and inconvenience potential pirates quite a bit.

Why? Potential pirates are just gonna steal someone's stolen cc details to open up a netflix account.

That would seem to increase the cost of streaming quite a bit if the provider has to re-encode the content for each streamer to embed a watermark instead of just dumping pre-encoded bits on the wire. And the watermark has to survive a re-encode. All to shut down some guy's account in a foreign country.

You can encode two streams with some detectable difference in them, then switch between them at GOP boundaries. The stream choice per gop gives one bit of data. You only need 33 gops (33 bits) to uniquely identify everyone on earth right now.

It's not HDMI/HDCP that watermarks it, that's not what I said. But by the time you get to an HDCP stripper, it has already been watermarked.

> You only need 33 gops (33 bits) to uniquely identify everyone on earth right now.

But then only ~6 accounts to have >50% probability of seeing every combination of each bit and be able to combine them at random.

You could have the player software insert the watermark after decode.

> if the provider has to re-encode the content for each streamer

There's no need for that, the CENC standard has more robust watermarking support, but it's not really used in practice yet because it's not commonly supported by browsers and possibly other clients.

Even if it's some guy in Malaysia?

I find it hard to believe that a HDCP stripper would then watermark the content and report who bought the equipment to the media cartels.

No, forensic watermarking would be done by the HDMI source (e.g. a PC in this case). I'm not aware of that being done in reality though.

Not if they are located somewhere like Russia or China where the authorities don't care

>The guy who re-encoded it would get a knock on the door.

Assuming there is a watermark, how would you track them down? It's not like you need to register your hdmi capture device.

Just curious, how can one distinguish original content from a full-res re-encode without access to the actual bits of the original file?

This may not be exactly what you're asking for but every re-encode introduces additional noise (generational error). Over many re-encodings (even at same high bitrate/quality) the noise will accumulate in a predictable manner. See [0] for an interesting deep-dive blog post on the subject.

Now, as for whether or not you can distinguish the re-encoding from it's original source.... difficult but plausible in certain scenarios? Perhaps if the content was heavily re-encoded to the point where you can statistically determine the presence of the generational noise. With only a single re-encode it may be impossible to determine.

[0] https://goughlui.com/2016/11/22/video-compression-x264-crf-g...

Hash the file you have, then compare to the hash of the official version.

Cloud computing (SGX).

what about drive encryption? I'm a little un-versed in hardware related to security, but my understanding of the article was that, given the ability to essentially MitM the TPM, anyone could unencrypt the contents of an encrypted drive, potentially even remotely.

if so, that is definitely not a good thing.

The problem with drive encryption at the mainboard level is that it comes with a free side order of vendor lock-in.

Apple is a good example here. You can't even touch the internal storage whether you want it encrypted or not, because all access to the onboard storage is gated by their black box security processor.

I'd rather just forego the silicon and do it all in software, since there's no way to ensure that the OEMs aren't being bastards. Another reason is that the hardware vendor is in a great, centralized position to be backdoored either by hackers or the bad guys with badges.

Reply on news.ycombinator.com