Hacker News Reader

Comment by RandomBK | Hacker News Reader

Every time I hear about the XBox's platform security, I think back to this talk [1] about how Microsoft protected the XBox One. A lot of it boils down to clear requirements and good engineering, and many of these technologies are now showing up via Project Pluton.

[1] https://www.platformsecuritysummit.com/2019/speaker/chen/

View on HN

and many of these technologies are now showing up via Project Pluton.

More awareness needs to be made of how this will have a devestating impact on end-user freedom. They're attacking the PC, one of the last holdouts of general-purpose computing freedom. Remote attestation will make it so you "can" technically run your own hardware and software (and that's what the FUD-spreaders will always say), but you'll be denied access to lots of, increasingly online, services.

Edit: nice, downvotes. Hello corpo-authoritarians, we know what's up :-)

Apple (and to a lesser extent Android) have already gone this route, and Windows 11 originally wanted to push _hard_ on enforcing the presence of more platform security. DRM schemes already perform remote attestation before you can stream 4K Netflix.

Linux and Open Source may be one of the last remaining barriers to this becoming widespread. It's one of the main reasons I whole-heartedly support Valve and their Steam Deck ambitions, and encourage everyone to do the same. Money trumps everything else, so as long as the money to be made from supporting SteamOS > money thought to be saved from piracy, I believe we can still thwart this.

> DRM schemes already perform remote attestation before you can stream 4K Netflix.

On Intel clients, this is done via the Management Engine, bypassing both the CPU and operating system, as the ME can control display output.

Is there any mechanism for it to validate that the thing connected to the display output is an unmodified monitor which also implements DRM? Otherwise it would be almost trivial to have a device with HDMI-in that gets a pixel perfect feed of the protected stream.

Yes, that's called HDCP. The master key was cracked long ago for older versions.

For new versions, you can get a converter; hdcp 2.2 -> hdcp 1.4 and then use whatevee breakage on 1.4. So it's only effective if you don't search.

You can’t produce good quality rips like this, if that was the best solution the DRM people would have won.

You can produce pixel perfect rips. But since the resulting video file is so large you will "need" to compress it, and then you get compression on compression artefacts.

Yes, indeed. Pixel perfect rips of already compressed streams, immensely blowing up the size and requiring another round of lossy compression to actually be useful.

And the result after recompression is impeccable so it is not a big deal. It is just a bit cumbersome.

The result after recompression is far from impeccable.

On high bitrate content you wouldn't notice.

Sure, but you get to push your encoder settings far less than you otherwise could. You always end up with either significantly bigger files or significantly lower quality.

It's significant closer to 5 percent or 50 percent?

It would be really interesting to make a video compressor that specializes in "recompressing" previously compressed data. A simple version could be special handling of common compression artifacts and trying to detect various transforms and trying to take advantage of the detail already removed instead of removing additional detail.

If you knew the codec used originally you could even try to (near) perfectly reconstruct the original bitstream. Especially if you know various codec parameters and some side-channel data (such as which video data is contained in which encrypted blocks) it may be possible to relatively efficiently search for the bitstream that decompresses to the data that you are seeing.

doubt it, should be on OS level, gpu control for all possible vendors and output formats is impossible without gpu driver support.

It's specific to the Intel GPU. Intel PAVP (Protected Audio-Video Path). See page 192 of Intel's "Platform Embedded Security Technology Revealed" (2014), https://link.springer.com/book/10.1007/978-1-4302-6572-6

Not to mention that no design is absolutely safe, and if security enclaves like Pluton get exploited to run backdoor, it'll be a lot harder for end user to detect.

It's worth looking at the multi-year CHERI research project on capabilities, https://news.ycombinator.com/item?id=30007474, which has influenced Arm security features and roadmaps. Pluton could be viewed as a stepping stone to CHERI. From a recent blog post by MS Research, https://saaramar.github.io/memory_safety_blogpost_2022/

> these tiny parts usually run with high privileges and dramatically impact the overall system. In such cases, MTE/CHERI play pretty nicely - they help ensure that whatever bugs we have in these areas are killed at their root cause (probabilistically/deterministically). This is exactly why MSR, MSRC and Azure Silicon pushed for this AMAZING project of CheriIoT ... scaling CHERI down to RISC-V32E, the smallest core RISC-V specification. I’m very excited about this project, and I hope once we will open-source the ISA and the prototype, more folks across the industry could join.

That is a direction that would benefit everyone: open silicon and open firmware for the most security sensitive components. It is technically possible and at least some humans in big companies understand the importance to future would-be-digital civilizations.

See also: Intel Management Engine exploits.

https://kakaroto.ca/2019/11/exploiting-intels-management-eng...

> Remote attestation will make it so you "can" technically run your own hardware and software (and that's what the FUD-spreaders will always say), but you'll be denied access to lots of, increasingly online, services.

It's good to raise awareness of the centralization risks of remote attestation. One pro-security, pro-freedom alternative is local attestation, e.g. to a USB security key running OSS firmware under user control. Widespread use of user-controlled attestations would make it harder for cloud services to impose unilateral requirements, requiring negotiation among competing objectives.

One remote attestation scenario could be disaggregation of critical apps into dedicated on-device VMs which look like cloud lambdas/functions/unikernels. Remote attestation could be done for a special-purpose VM (e.g. banking), leaving other general purpose OS VMs unrestricted. This is possible today with Windows Hyper-V on secured-core x86/Arm hardware, Android 13 with the pKVM hypervisor on Pixel 6/7 hardware, and the HP/Bromium AX hypervisor.

MS/Pluton thread, https://twitter.com/dwizzzlemsft/status/1511440279462563842

> what are they going to say when it's supported in Linux and we open source it ... the Pluton team also uses Linux daily, builds TWO Microsoft Linux distros, and upstreams Linux kernel features.

On servers, a forward-looking approach is being taken with OCP Caliptra, an open root of trust that will precede booting of the main SoC (including Pluton) and mandates open firmware that must be dual-signed by both the OEM and the datacenter owner. It is an early attempt to forestall ME/PSP/BMC Groundhog Day. If it succeeds on OCP servers (where datacenter owners have power to negotiate with OEM/ODMs), perhaps more transparency and owner control/veto can be brought to client devices, https://twitter.com/platformsec/status/1533398356088737793.

One pro-security, pro-freedom alternative is local attestation

What's the point? That's about as useful as running your own CA. The fact is, those pushing remote attestation want remote centralised control and they're going to care that you have your own attestation infrastructure as much as they'll care that you have your own CA, i.e. they're not going to be satisfied because they're trusting their own, and not yours.

the Pluton team also uses Linux daily, builds TWO Microsoft Linux distros, and upstreams Linux kernel features.

That's even scarier. If the only form of "supported" Linux becomes Microsoft Linux (with its own unique brand of spyware and other crap forced on you due to RA), don't say we never saw it coming: Embrace, Extend, Extinguish... or perhaps that last E should now be Enslave.

If it succeeds on OCP servers (where datacenter owners have power to negotiate with OEM/ODMs), perhaps more transparency and owner control/veto can be brought to client devices,

We already had "owner control" until they started trying to take that away from us. We don't need nor want attestation at all. No means NO!

> they're not going to be satisfied because they're trusting their own, and not yours.

This cuts in both directions. Unlike signing certificates, attestation is not a zero-sum fight over a single monolithic measurement attribute that can only be A or B, it can support a goal of having A and B, e.g. as disaggregated VMs. If a cloud wants subset B, then the user/owner/enterprise local attestation can insist that the client must also have subset A, otherwise it can reject subset-B-without-A. Also applies to multiple clouds with conflicting requirements.

Enterprise clients connected to centralized clouds are not the same as consumption-oriented DRM, where the decision is grant/deny. Enterprise client devices generate business data that is sent to the cloud, and they consume data/compute/apps from the cloud. If businesses stop sending data to the cloud, the hybrid workflow breaks down. It's not as one-sided as Netflix DRM.

> We already had "owner control" until they started trying to take that away from us.

With the exception of IBM POWER / Talos servers that have open firmware including the BMC, most servers depend on many blobs, so there has been little transparency for owners, never mind control. One has to start somewhere, and Caliptra starts at the beginning, with an open silicon+firmware RoT that can potentially evaluate some of the myriad blobs and processors and devices needed to bring a server online.

E.g. DMTF SPDM can be used for local PCI (or virtualized I/O like NVMe-over-TCP) device attestation of firmware integrity to the server, before the device is authorized for use in the server, https://www.dmtf.org/standards/SPDM & https://www.platformsecuritysummit.com/2019/speaker/plank

> What's the point? That's about as useful as running your own CA.

Running your own CA IS useful.

The PC will eventually lock up more. Free general-purpose computing will remain on things like Raspberry Pi (and many other variants). There will be Windows computers, like we now have Macs, and Windows-incapable computers to run Linux (or whatever else open OS).

Free general-purpose computing will remain on things like Raspberry Pi

Leaving aside the debatable nature of how open and free a RPi is, what's the point of "general-purpose computing" when it can't actually be used? When/if you need a locked-down machine controlled by some central authority to do what you can still do today with a free and open one, i.e. create and consume media, interact with services, communicate with others, etc., how much value does a truly libre computer have? It's almost like the "just build your own platform" argument when it comes to censorship.

RPi boot path includes the GPU/VPU, which runs a binary blob based on an older version of ThreadX RTOS, whose upstream is now called Azure RTOS ThreadX. Work on an open-source replacement has been slowly inching forward for a few years.

Arm, including the quirky RPi, is not comparable in openness to x86 general purpose desktops, which were a happy confluence of accidents, determined individuals and scrappy businesses. That is still worth defending, if only to slow the slide backwards.

M1 Macs have a unique take on hardware security that can co-exist with general-purpose computing for open-source Linux, and Apple's vertical integration. https://archive.fosdem.org/2022/schedule/speaker/xeno_kovah/. Hopefully Asahi Linux will succeed in creating a relatively maintainable port for multiple generations of Apple Silicon.

The open replacement for the RPi boot blob:

https://github.com/librerpi/

You say this on a forum where the majority probably has an iphone or macbook, of course people are going to be tone-deaf to it.

Not even the HN-audience cares enough to turn down something shiny.

> More awareness needs to be made of how this will have a devestating impact on end-user freedom. They're attacking the PC, one of the last holdouts of general-purpose computing freedom.

This situation reminds me of the fuss around Palladium, a solution which seemed to be abandoned by Microsoft on its merits:

https://en.wikipedia.org/wiki/Next-Generation_Secure_Computi...

> Edit: nice, downvotes. Hello corpo-authoritarians, we know what's up :-)

This also reminds me of the fuss around Palladium:

https://www.penny-arcade.com/comic/2002/07/22/m

This is what I found on "Project Pluton" https://www.microsoft.com/en-us/security/blog/2020/11/17/mee...

There was a PSEC 2019 talk on Azure Sphere (IoT), with some details on Pluton security features and the Microsoft Linux hardened kernel based on OpenEmbedded/Yocto. Briefly mentioned is Microsoft's QEMU emulation of Pluton for CI/CD and their segmented architecture for delivery of 10 years of Linux security updates to the device, even if the IoT vendor goes out of business leaving the application firmware unmaintained.

https://www.platformsecuritysummit.com/2019/speaker/seay/ (click Hardware tag to seek video to the Pluton section)

IEEE paper (2021, paywall) on Pluton, https://ieeexplore.ieee.org/document/9512305

Reply on news.ycombinator.com