I've always been pretty skeptical of secure boot and trusted hardware modules since it seems to generally mean "trusted by the manufacturer, not the user". The model feels like the manufacturer owns and controls the device, and the user is just barely trusted enough to press the boot key.
Because of this I appreciated that the article stressed the importance of open-source firmware and called out companies like Intel for user-hostile approaches.
It's been like that since the beginning of "Trusted Computing" --- it was originally for DRM. Only within the last decade(!) has it been advocated strongly as a security feature, and my belief is that the companies (and the government) have realised that security paranoia is a powerful tool of control. Unfortunately most people won't question anything if it's "for security".
I don't think open-source is really all that important, and the article is being very misleading in that respect; in fact, if we don't have the keys, all that being open-source does is to allow us to easily see how they're oppressing us. (Of course, there's also the Ken Thompson Hack --- inspecting the binary is the real way to determine if there's anything unusual.)
I long back to the days when we said security is compromised when a adversary had physical access and that zero point many zero's 1 dollar jumper physically setting things to read only works just fine.
Today I primarily don't trust my systems because of the manufacturers seeing me -the owner- as the #1 security risk and favoring corporate interest over client interest.
You're right to be skeptical, but for the wrong reasons. As others have pointed out, it isn't 1984. Computers are too complicated for users to be trusted.
The real problem here IMHO is that just as the OS is horrendously complex and cannot be left to the user to configure properly, trusted hardware is also broken! For a very recent example, visit https://tpm.fail . The TPMs mentioned in that disclosure passed rigorous CC EAL4+ and FIPS 140-2 certifications. So, even the certifications fail to protect against the very flaws they are testing for. (I haven't studied the matter in detail to determine if the testing regime itself is weak, or if there's a Boeing/FAA level of corruption, or something in between.)
For another recent example, javacard has been proven weak in certain use cases.
The big problem with these hardware flaws is, you end up putting your absolute faith in them since they form the TCB. When the hardware is eventually (and almost certainly) found to contain a flaw, the entire rest of your security tends to fall apart, and generally you are unable to repair it without replacing the device entirely. This might be ok (you will eventually replace the hardware through normal obsolescence) or not (embedded [in your body] medical devices).
What I like about the HP proliant platform is the the TPM chip is an add-on card.
Most users lack a deep enough understanding of security to protect themselves. Also, even if they do have knowledge, they might still ignore it in order to install games or watch dancing pigs or whatever.
I think Google offers a good compromise with the screws in their chromebooks that allow overriding the bootloader.
Reproducible builds of open firmware, BMC and boot components can enable owner-managed keys for verification of platform and application integrity, rooted in (increasingly open) hardware. Recent conference talks on hardware-assisted security and open firmware:
> Most people remember when the FBI wanted a backdoor into iPhones and Tim Cook refused.
Fewer people remember when the CCP wanted a backdoor into iCloud and Apple said yes, for fear of losing its largest growth market. Presently, all iCloud users in China are hosted by a Chinese company, in China, to which the CCP by law has full access.
There is also a claim that Apple cancelled a plan to e2e encrypt iCloud phone backups, which would mean that Apple/FBI could no longer decrypt your phone’s backup. All iPhones logged in to iCloud are backing up to iCloud by default with encryption that Apple/FBI can read. The claim is that the FBI specifically requested that they not further secure this, which would prevent their current methods of easily accessing these backups.
Note that your backups generally contain your complete iMessage and SMS history, including all attached images and videos.
There’s little practical point in denying a backdoor into a seized phone if Apple/FBI already have a copy of everything on it that they can decrypt and read because your backups are encrypted to Apple, not you.
(They do this because many, many people lose their device, and have forgotten their Apple ID password which then needs to be reset. The naïve solution to this is to simply encrypt the backups to an Apple key, which is always decryptable by Apple as required for restore after resetting your password via alternate ID verification. Unfortunately it puts every single user of iCloud backup at risk of bulk surveillance.)
The whole thing is rather performative, like they are showing off for the market. Indeed, people well respected (such as the author of TFA) are repeating this meme without any of the associated caveats.
Make sure you tell your family and friends to disable iCloud and more specifically, iCloud device backups if they value their privacy.
This is an article about securing the boot process on various platforms. Whatever your thoughts on Apple's cloud security practices (I'm not a fan either), it gets tedious to have this brought up every time an article is in any way related to Apple and security. Boot security matters, regardless of whether your cloud backups are end-to-end encrypted or not. I find calling it "rather performative" disingenuous.
Yes, my comment is orthogonal to the topic of the article. I’m just so incredibly tired of seeing people trot out this commonplace and false Tim Cook vs the FBI narrative entirely uncritically, which is precisely what TFA does.
iTunes backups support encryption without your computer needing FDE.
There is also the idevicebackup2 commandline tool from the libimobiledevice suite for doing those backups on linux, mac, or windows hosts. Supports the iOS protocols, including the native backup encryption.
Having a secure iOS device is possible: disable iCloud backups, probably disable messages and photos too, and use a custom numeric pin >10 digits (a lot more if you are using it as T9 input). The secure enclave's kdf is only configured for 100ms of stretching IIRC, but it's sufficient with a long pin code.
That's how they got DFS. Two agents pretended to have a lovers' argument at the library, to distract him, and the third grabbed his laptop.
I don't use laptops anymore. Just host machines for VMs. And I always shut them all down, whenever I leave the building. I have a commercial UPS, with a deadman circuit. So I just cabled that line with the CAT6, and there are motorcycle-style kill switches in key places (desk, bathroom, kitchen and bed).
I've been writing about privacy, anonymity, etc for many years, as Mirimir. And I can't write honestly unless I test stuff.
I don't do anything iffier than many who write using their meatspace identity. But for many years, I wanted to keep that segregated from my professional life. That doesn't matter so much now, but it's Mirimir who I am. So hey.
I didn't take it as bragging; to me it looks like it comes from a position of wanting to teach. Security is basically a collection of things you ought not to forget, so I think exposure is important for people to a hold of it.
I don't do anything cool, at least as of right now, but I still check my locks and I'm happy to impart my knowledge like this. Privacy is a human right! I hope journalists, Uighurs, and whoever else can find their way to decent security information because of mirimir's efforts.