Hacker News Reader

> if we're talking strictly about security of data at rest (i.e. from a powered off state) I trust my rooted Android with a long FDE passphrase over any iPhone.

If you never power-up your phone maybe. But in any realistic usage scenario you're way insecure with a rooted Android phone. Check this link, it's a quick read.

https://madaidans-insecurities.github.io/android.html

That whole article is massive fear mongering.

> If an attacker has managed to compromise the entire system and gain extremely high privileges, verified boot will revert their changes upon reboot and ensure they cannot persist.

Unlocking the bootloader chiefly means you are insecure against evil-maid attacks. If your phone is compromised via software badly enough that they can flash the OS, the attacker has all your data already. And if they pwned you like that, they can pwn you again, and also, who ever powers off their phone except when the battery runs out? Besides, data-only persistence exploits aren't hard to find. Since I use FDE, an evil-maid attack will at least leave behind the evidence of a powered off phone, and if they just steal it they get nothing.

> Verified boot is not just for physical security as many people assume. Its main purpose is protection against remote attackers and the physical security is a nice side-effect.

As I said, that's BS because that assumes people power off their phones, which they don't.

> An attacker can fake user input by for example, clickjacking

That only works if you give apps Accessibility permission. Which nobody sane does for anything but extremely trustworthy apps.

> The majority of custom ROMs ruin the security model by disabling verified boot, using userdebug builds, disabling SELinux, not including firmware updates, and a lot more. A common ROM that does many of these is LineageOS.

LineageOS isn't one ROM, it's many ports for many devices, and as far as I know most of the decent ones include firmware updates and absolutely do not disable SELinux (are there even any that still do that?). I haven't used a LineageOS build without SELinux in at least 6 or 7 years. Verified boot has to be disabled to allow for add-ons, but we've already covered how that isn't that big of a deal except against evil-maid attacks. As for userdebug, the only thing that does is enable root via ADB - but then LineageOS gives you a toggle to disable it in the settings. And since ADB access is secured via a secure key exchange, you can only use it after a permission prompt or from a previously authorized host.

Also, LineageOS doesn't even come with root these days. It's an optional add-on. You can just uninstall it and away goes root.

> It does not implement rollback protection so an attacker can downgrade the OS to an old version and exploit already patched vulnerabilities

Oh, really? Well, I tried downgrading LineageOS recently, and it refused to unlock my FDE, presumably as the Keymaster implementation noticed and said nope.

> It does not include firmware updates which prevents you from getting new patches to fix vulnerabilities.

Again, this is device-specific and a meaningless generalization. LineageOS isn't one ROM, it's many ROMs for many devices. Which one are they talking about? Back when I was using a Nexus device, LineageOS builds didn't include firmware but were tied to certain firmware versions and prompted you to pull those updates from factory builds to match, which I always did to make sure my firmware was up to date.

Yes, there are more security-focused ROMs like GrapheneOS, and yes, Pixel/Nexus devices are usually the reference for serious security in the Android space (I'm actually waiting for LineageOS support to get a Pixel 4a). But saying "rooting your phone kills security" is a fearmongering generalization. Rooting your phone doesn't mean you give every app root access, it means you give yourself root access.

You are not the customer. The customer is someone who needs to roll this out to parts of their organization, they cannot depend on their users being able to setup secure crypto on their own or together with IT. They need something ready to use.

The is also a cover your ass perspective. If their homerolled solution had issues they had the problem, if this usbkey have the issue they can point to that they bought certified parts.

When I was working in the military industrial complex we paid Red Hat for Linux even though we'd never have been able to use their support. The reason was that "Freeware" wasn't allowed on the servers. Sometimes the appearance of propriety to people who don't understand the issue can become very important.

Is it only appearance though ? When using free open-source software, the license always disclaim any warranty or liability related to the use of the software (the famous THE SOFTWARE IS PROVIDED "AS IS"... paragraph).

When buying the same software from a vendor, the contract may include not only warranty & support but also some level of liability in the event of a software/security/design flaw.

> When using free open-source software, the license always disclaim any warranty or liability related to the use of the software

Have you find any proprietary operating system that doesn't come with that phrase? The only pieces of software that don't have something like this are very expensive consulting-first specialized ones.

Isn't it a question of where you put your trust? For the software solution you have to trust the computer and its file encryption utilities. For the hardware solution you have to trust the USB stick.

Although one could assert that data coming from an untrusted computer might be already compromised. It might not be the case for an air gapped system.

Or you can trust different aspects of the computer at a different level. You can trust it for its normal functions but maybe it doesn't get regular updates for file encryption utilities and USB mass storage drivers. Sometimes you still need to fetch data from it using trusted USB devices.

Threat models can be complicated, also it makes sense to apply defense in depth.

If your software is compromised it can already read or write it whatever it wants off of an IronKey, or fire off a passphrase change request behind the scenes and replace your passphrase with an insecure one to render the physical device insecure, at which point it is equivalent to a $27 USB stick.

Perhaps in an enterprise setting with physical controls and air gaps you might be able to have a device require a different admin PIN to change the passphrase, avoiding the latter scenario of data exfiltration, but then the device has to be explicitly designed with this in mind to avoid any other exfiltration channels for the true PIN and I don't think IronKeys claim to do this (I don't even know if they support such a split admin PIN). And besides, you probably have bigger problems if your air gapped computer is compromised anyway.

Really, IronKeys and their ilk cater to corporate and government bureaucracy use cases that have long since been divorced from true trustable security. They are instead a mountain of complexity, and the more complex a system, the less likely it is to be secure.

The thing about software is that you can audit it yourself - it's quite easy to read through the entire source code of a trivial but secure file encryption app and convince yourself that the algorithms match published and industry standard implementations, and that they match test vectors, and that it interoperates with another instance on another machine, or send the files off to someone else to double check. You cannot audit an IronKey yourself.

But yeah, sure, defense in depth is a thing, and if you use an IronKey and software encryption (with different passphrases!) then you probably end up with better security, or at least not worse :-)

More to the point, for the software solution, you have to trust the user to actually do the encryption and to use a strong passphrase.

This is an other good point. Not to mention secure key exchanges between users when necessary.

Then use both: put encrypted files on the encrypted drive.

"The difference is that if you encrypt a file with a strong, industry standard algorithm, with proper key derivation, enough entropy on your passphrase, and stick it on a $27 USB key, you can be personally certain (by most reasonable standards) that your data is secure at rest."

And how much does it cost to convince 100,000 users to do this correctly, consistently? And to convince someone else that your personal certainty is worth a damn?