Web-Environment-Integrity VS SupplyChainAttacks

Repo has be archived - "NOTE: This proposal is no longer pursued."

https://github.com/RupertBenWiser/Web-Environment-Integrity

[2] - https://github.com/RupertBenWiser/Web-Environment-Integrity/...

I think the best issue raised is: Why would I, as a user, want this?

https://github.com/RupertBenWiser/Web-Environment-Integrity/...

There were proposals for protecting against this in the WEI explainer under "Open Questions" https://github.com/RupertBenWiser/Web-Environment-Integrity/...

The Web Environment Integrity is yet another Google proposal for making the web worse for everyone but them.

Point me to anything which would give websites access to that information via WEI. There is nothing. I have seen nothing except FUD. Aside from that, this only attests for the device. Ad-blockers can be external. This does nothing for external ad-blockers.

Explicit non-goals for WEI:

"Enforce or interfere with browser functionality, including plugins and extensions."

https://github.com/RupertBenWiser/Web-Environment-Integrity/...

That also applies to Javascript, or being forced to use some form of an up-to-date browser. What is different with WEI?

I didn't see many people debating the actual text of the WEI explainer[0] on the HN posts about WEI, and that's probably because they were links to articles about WEI. The HN post for the explainer with the most upvotes only has 89[1], likely because most of HN treats the upvote as "I agree/like this" instead of "boost this topic for discussion".

0: https://github.com/RupertBenWiser/Web-Environment-Integrity/...

1: https://news.ycombinator.com/item?id=36785516

> If you don't want my browser to render content as it sees fit, don't serve the content over a protocol where that dynamic is inherent.

to play the devil's advocate, this is why google proposed the WEI (https://github.com/RupertBenWiser/Web-Environment-Integrity/...). Be careful what you wish for...

https://github.com/RupertBenWiser/Web-Environment-Integrity/...

I stopped reading after the explainer’s intro section. The first example is making it easier for websites to sell adds (lmao) and the other 3 are extremely questionable whether if the proposed remedy even helps. And it’s presented as a benevolent alternative to browser fingerprinting, as if we must choose between these two awful choices. It’s an absolute joke of a proposal.

Why should anyone trust a remove server providing a signed statement of authenticity when Intel[1], MSI[2], Lenovo[3], NVIDIA[4], Microsoft and others keep losing their keys? Even if they haven't lost their keys recently, technology companies don't have a great track record of producing foolproof hardware designs (e.g. recent case of [5]), if foolproof was ever a reasonable expectation. For starters, it's assuming technology such as ptychographic X-ray computed tomography and focused ion beam machining won't become more commonplace and commercially viable to readily break TPM attestation schemes. Or that with wider use of TPM attestation, more effort will be expended into breaking it whereas for the current state with minimal adoption, few people care.

The issue client-side is that if a single vendor or TPM design is compromised, your threat actors have more motive, resources and ability to exploit this compromised hardware than you do. And critically, you as a user are blocked by your own choice of TPM attestation technology from discovering attacks and auditing your own system security, as you ceded control of your own systems. Instead, your systems are controlled by a few technology companies that have a proven terrible track record of fulfilling their alleged intent of keeping your systems and data secure. Why should they care if it doesn't lead to a higher profit at the end of the year.

[1] https://github.com/binarly-io/SupplyChainAttacks/blob/main/M...

[2] https://github.com/binarly-io/SupplyChainAttacks/blob/main/M...

[3] https://github.com/binarly-io/SupplyChainAttacks/blob/main/L...

[4] https://news.ycombinator.com/item?id=30565985

[5] https://arxiv.org/abs/2304.14717

Money Message has this week claimed that MSI has refused to meet their demands - as a result, an upload of stolen data started on Thursday with files appearing on the group's own website, and spreading to the dark web soon after. Binarly, a cybersecurity firm, has since analyzed the leaked files and discovered the presence of many private code signing keys within the breached data dump. Alex Matrosov, Binarly's CEO states via Twitter: "Recently, MSI USA announced a significant data breach. The data has now been made public, revealing a vast number of private keys that could affect numerous devices. FW Image Signing Keys: 57 products (and) Intel Boot Guard BPM/KM Keys: 166 products." Binary has provided a list of affected MSI devices (gaming laptops & mobile workstations) on their GitHub page.

lol, yes. but not their mobos... mainly laptops: https://github.com/binarly-io/SupplyChainAttacks/blob/main/MSI/MsiImpactedDevices.md

Binarly also posted another set of keys that were apparently leaked in the MSI breach. These aren't Boot Guard keys, but are instead orange unlock keys for Gemini Lake and Apollo Lake systems. Intel CPUs expose various sets of debug capabilities to debug production systems; there are several levels of debug access that are supported, with higher levels requiring authentication. Red unlock is the most powerful state - it lets you access much more than just architectural x86 state, including microarchitectural state [such as the decrypted microcode sequencer ROM]; it also can be used to execute undocumented instructions. It even lets you debug the Intel ME x86 core!

Link: Binarly GitHub

Or the GitHub link below

https://github.com/binarly-io/SupplyChainAttacks/blob/main/M...