No Rescue Mode

[Patrick]

@nurmagoz

@Patrick

Yes, people should be able to change the software on the same device that they purchased. They shouldn’t need to purchase another device specifically sold as unlocked.

If there is a secure way to do that, i think we gonna have happy world.

This is what we’ll hopefully figure out here one day.

@nurmagoz

@Patrick

vendor lock: Analysis of suspected infected device is hindered. (Not completely perfectly prevented. But it can be compared and one state - ease of analysis of rootkits - is better than the other - obfuscation.)

Its like something from reality, like having a door for your home, harder to see inside and harder to enter, but essential for keeping unwanted visitors out. However, very rarely but possible (some people never had it) weak spots like windows, broken walls, or poor door implementation could still let a thief sneak in. Outsiders also can’t easily tell if something’s wrong inside the house. Yet despite these risks, this protection remains absolutely necessary.

Not much point for me replying to an analogy.

Why am I using analogies myself? I am using these in addition to technical explanations which are hard/impossible to understand for non-programmers but I am not using purely analogies.

@nurmagoz

@Patrick

With vendor lock, you’re at the complete mercy of the vendor.

This is the unavoidable big picture - the product user is under the product maker. It’s a reality everywhere, every day. The freedom just eases the forking if you want to do it your way.

The best and only thing hardware buyers can do is purchase devices that support user unlock/relock. Every purchase of a device that does not support unlock is a vote towards the end of general purpose computing access for mere morals.

@nurmagoz

@Patrick

What we don’t have - according to my knowledge - at time of writing:

Legal limitation according to my investigation for this case.

I couldn’t find any references for this.

But I found a much more detailed report:

lookout-pegasus-technical-analysis.pdf

Hence, wiki table replaced.

@nurmagoz

@Patrick

Such attacks are mitigated with full verified boot.

Full verified boot doesn’t protect you if the device is taken, a chip is decapped, malware firmware is installed, or if it can be applied to an SSD or USB ports changed with BadUSB ports or xyz (Check COTTONMOUTH or HOWLERMONKEY… here). This doesn’t contradict OS-BIOS verification.

So hardware must be a full circle - leaving xyz areas unchecked - then it can be easily taken, played with, and put back again. So only signed software must be interacting with each other.

Its like a chain of trust, or what so called HRoT (Hardware root of trust).

Note: This probably will also require some software to be burned into the hardware that can’t be changed or removed. Future upgrade to the hardware would be needed to make such core changes, but this is normal anyway - not for the sake of more profits, but for improving security.

Indeed, Intel Boot Guard or an equivalent such as AMD Platform Secure Boot (PSB) or similar is required. A public key must be fused into Intel Guard or alike.

The processor will then verify the (EFI) BIOS.

So while user unlock/relock can be provided for the level of which operating system to boot, it cannot be provided securely against physical attacks for the firmware itself.

BYOB (bring your own bios) - a system architecture where the device’s essential firmware is not stored in a fixed, soldered chip on the motherboard (as is typical in most modern computers), but instead resides on a removable storage medium like an SD card - might require more work to be secure from the physical attacks that you mentioned.

It may not be impossible to secure that either. But BYOB will probably not happen anytime soon (as no hardware vendor indicated interest) anyhow so there’s no need to develop a concept on how to secure that at this point.

So some things like the firmware can be firmware vendor controlled. However, freedom can be securely provided at the level of the operating system choice.

@nurmagoz

@Patrick

A) In a situation asked to provide the password (key disclosure law) under the threat of indefinite detention… Bad luck. It’s hard for technology to provide solutions.

Authority of xyz country can access the OS of specific user/s, but they can’t implement anything widely on every device entering their country, for example.

They can require that devices must be unlocked on demand from select people and if they don’t comply, they’re threatened with detention. I don’t see how technology can solve that.

@nurmagoz

Attack scenario: Unlock the bootloader, load a malware custom ROM that looks like Google, lock the bootloader, then send the device to the customer. How many users will notice the difference or reinstall the original OS as a security precaution?

Compare this to Apple - I think Apple is the only one taking pioneering, advanced steps to solve these issues (but sadly all in nonfree way).

Supply Chain Attacks (new wiki chapter created just now) are an issue indeed but in any case, vendor lock-in or no vendor lock-in.

How does one now they got an original iPhone from Apple or one that has been tampered with?

The problem with hardware is, it cannot be hashed. With software it’s possible to calculate as has an compare but with hardware this is impossible. See https://www.youtube.com/watch?v=Fw5FEuGRrLE on the topic of hashing (checksumming) hardware.

Since forbes (Fresh Wikileaks Dump Shows CIA Was Hacking iPhones A Year After Launch) is linking to wikilleaks, I think I can too.

Quote https://wikileaks.org/vault7/document/NightSkies_v1_2_User_Guide/NightSkies_v1_2_User_Guide.pdf

(S) NightSkies (NS) version 1.2 is a beacon/loader/implant tool for the Apple iPhone 3G v2.1. The tool operates in the background providing upload, download and execution capability on the device. NS is installed via physical access to the device and will wait for user activity before beaconing.

(S) Features:
• Retrieves files from iPhone including Address Book, SMS, Call Logs (when available), etc.
• Sends files and binaries to the iPhone such as future tools
• Executes arbitrary commands on the iPhone
• Grants full remote command and control
• Masquerades as standard HTTP protocol for communications
• Uses XXTEA block encryption to provide secure communications
• Provides self-upgrade capability

Can I detect a firmware toolkit like NightSkies on my iPhone?

The only real way to compare if a firmware image has been modified is to be able to take the firmware from the device, take a hash of it, and compare it to the hash of a known good copy.

The image taken from the device must be obtained in such a way that any malware on the device can’t tamper with the image being exported (i.e. obtain the image before the system boots). I’m not too familiar with iPhone forensic tools, so I couldn’t tell you the cost to do something like this.

So once a user receives a vendor locked device that has been compromised through a supply chain attack, they cannot even find out that the device has been compromised.

BYOB (bring your own BIOS) - where one can easily extract, checksum and/or replace the firmware by replacing the sd card sounds not so bad after all.

In any case, when someone receives a device, how can they be really sure they received a real device and not a fake device? Ok, it’s not so easy to copycat the latest, fastest device on the market. Maybe it’s just a thin client combined with a relay attack.

woot17-paper-shwartz.pdf

Hacking a Phone Through a Replacement Touchscreen - Schneier on Security

Hardware wallets also have this issue. Is it a real hardware wallet, have malicious parts been added?

https://support.ledger.com/article/4404389367057-zd

Supply chain attacks, malicious parts are a hard one. Hardware implants, hardware replacements, and whatnot.

@nurmagoz

Attack scenario: Unlock the bootloader, load a malware custom ROM that looks like Google, lock the bootloader, then send the device to the customer.

We can refer to this as the following:

• Forged Verified Boot Attack: Re-locks bootloader using attacker’s key to fake a secure boot state. Device appears secure but isn’t. A variant of phishing where the OS mimics a trusted UI (e.g., “Google Pixel” lookalike with backdoors).
• Relocking Attack: synonym, same as above
• Malicious Bootloader Re-lock Attack: synonym, same as above

Solution?

• Tamper-Evident Verified Boot: Makes any modification to the boot chain detectable to the user. See:
  • Boot flow  |  Android Open Source Project
  • Device state  |  Android Open Source Project
  • User Notified of Changes: During boot, if the device detects enrollment of a non-stock key, it shows a distinct warning screen and reveals the public key fingerprint. This makes faked stock ROMs with re-locked bootloader keys highly detectable.
• Remote Attestation: Potentially, in addition, but not as a primary defense.

Counter attacks to that solution:

• Boot User Interface Spoofing Attack
• fake device + relay attacks

I think verified boot for the forseeable future will be primiarily useful against remote, software based attacks. Not against hardware implants, fake hardware.

Verified boot can:

• 1. Verified boot makes sure that the boot process has not been tampered with. (So if previously malware modified the system, it can be spotted and boot aborted before executing the malicious code.) And;
• 2. Detect unauthorized, unexpected write access by malware. Quote Verify Boot  |  Android Open Source Project

  • verification is a continuous process happening as data is loaded into memory

(related: When the verification is over?)

Depending on the availability of funding, one day we might formalize the threat model, discuss this with a firmware / hardware vendor and see what can be done.

Complex supply chain attacks: At this point, we have much lower hanging fruit to pick. That is, Verified Boot on traditional Linux.