If I want a secure computer should I go with an older one with no intel ME or a newer one with secure boot and TPM?

  • Registration closed, comedy forum, Internet drama, Sneed, etc.

Likely

kiwifarms.net
Joined
Dec 29, 2013
all this stuff about bootloaders can be circumvented with rubber hose cryptography.
i hate to be a buzzkill but boot attacks are most useful for when you dont want the victim to know they've been compromised
encryption and obfuscation is defeated by rubber hose
 

byuu

Non-binary they/them
kiwifarms.net
Joined
Aug 17, 2018
Yes, and kernel driver signing cannot be trusted without full boot chain of trust.

If someone compromises the bootloader, they have compromised the kernel.
If they have compromised the kernel, they have compromised driver verification.
And I've talked about the whole chain in the post above yours.

It's still wrong to say that Secure Boot stopped drivers being a common target to infect.
Driver signing is much older (since Vista) and more widespread than Secure Boot (since Windows 8 ). This plus putting more drivers into user space is the actual reason drivers were less targeted.

The actual motivation for Secure Boot was to avoid someone defeating full-disk-encryption by hooking into the boot loader and injecting a fake password prompt. In a so-called Evil Maid Attack. Not to avoid kernel drivers getting infected.
Persistence after a simple reboot once the whole system is already compromised was never a hard problem for an attacker.
 
Last edited:

Scumhook

kiwifarms.net
Joined
Aug 13, 2015
I've talked about the whole chain
dude

wtf

fuck

there is something so fucking innately sexy about this i just can't

from now on @byuu you fucking own my soul bb. IT's yours. Better or worse. Richer or kek even moar richer dw bb i'm fucking loaded.

And whatever else comes our way, bb
We'll face it, head on
well
ass onn
given the physics of things etc

dm me bb
 

Bat Dad

Do not cross the Bat Daaad!
True & Honest Fan
kiwifarms.net
Joined
Aug 9, 2019
Persistence after a simple reboot once the whole system is already compromised was never a hard problem for an attacker
I disagree with this. Today, even when you have physical access to a device, persistence is often hard to achieve. That's why, with a lot of console hacks/iOS JB's, you have to reapply it on boot each time. Achieving persistence is always a goal. Sometimes it takes years to get there, or it just never happens at all, and you wind up with a tethered jailbreak or whatever.
 

Scumhook

kiwifarms.net
Joined
Aug 13, 2015
I disagree with this. Today, even when you have physical access to a device, persistence is often hard to achieve. That's why, with a lot of console hacks/iOS JB's, you have to reapply it on boot each time. Achieving persistence is always a goal. Sometimes it takes years to get there, or it just never happens at all, and you wind up with a tethered jailbreak or whatever.
what in the liveing fucking shit are you fucking talking about ou fucking cunt

do you understtand what's at stake here????!?!?????!??!

FUCKING SHIT, WAKE THE FUCK UP!!!!
 

byuu

Non-binary they/them
kiwifarms.net
Joined
Aug 17, 2018
I disagree with this. Today, even when you have physical access to a device, persistence is often hard to achieve. That's why, with a lot of console hacks/iOS JB's, you have to reapply it on boot each time. Achieving persistence is always a goal. Sometimes it takes years to get there, or it just never happens at all, and you wind up with a tethered jailbreak or whatever.
Yes, that is true for a totally locked system like an Apple iPhone or a console where even the owner needs Apple's permission to run any bit of code. And I do believe that this is Microsoft's end goal but even Windows 11 is not at that level yet.

Personally I despise this model but it seems to work for some people.
 

Bat Dad

Do not cross the Bat Daaad!
True & Honest Fan
kiwifarms.net
Joined
Aug 9, 2019
what in the liveing fucking shit are you fucking talking about ou fucking cunt

do you understtand what's at stake here????!?!?????!??!

FUCKING SHIT, WAKE THE FUCK UP!!!!
Semper-Fi noble re.tard, I salute your dedication to the cause.
 

Scumhook

kiwifarms.net
Joined
Aug 13, 2015
Semper-Fi noble exceptional individual, I salute your dedication to the cause.
mate that is a fucking awesomep post

SEMPER-FI MY FUCKING BROTHER

FUCKING RIDE OR DIE, YOU AND ME BB





* this opingon may change tomrorow when i sover up lol icant read this stupid tiny text
 

Likely

kiwifarms.net
Joined
Dec 29, 2013
It's still wrong to say that Secure Boot stopped drivers being a common target to infect.
Without a full chain of trust, you can't protect against this threat

Not to avoid kernel drivers getting infected.
Again, wrong. The point of secure boot is to help establish a chain of trust. Part of that chain is an uncompromised boot process. Microsoft's own documentation counters what you've said. But also now it's kinda clear you have a poor understanding of computer security and defense in depth.
 

byuu

Non-binary they/them
kiwifarms.net
Joined
Aug 17, 2018
Without a full chain of trust, you can't protect against this threat
Without completely airgapping your computer in a safe deep in the ocean you can't protect against this threat.
How about doing more to protect your computer getting compromised in the first place?

Again, wrong. The point of secure boot is to help establish a chain of trust. Part of that chain is an uncompromised boot process. Microsoft's own documentation counters what you've said. But also now it's kinda clear you have a poor understanding of computer security and defense in depth.
Saying "Secure Boot defends against kernel driver infection" is like saying a locked window protects against someone breaking in through your door because when the window isn't locked you can enter through it and then open the door from the inside.
It's just stupid.

And additionally you tried to paint Secure Boot as a proven deterrent for kernel driver infection even though that is not true at all.
Far fewer people use the whole chain of trust with TPM and Secure Boot and everything than people using just kernel driver signing which almost every Windows user has used since Vista.

Oh and Microsoft's own documentation says TPM isn't required for Secure Boot. There goes your chain of trust.
 

SandyCat

Send cat pics
True & Honest Fan
kiwifarms.net
Joined
Apr 15, 2021
If you're looking for something secure for more short term use you can use the tails operating system on a USB stick. But that's not really meant to be a replacement for casual use, its more so for short term stuff when you need more security for what ever it is you're doing.

But if you're looking for a every day use computer your options are pretty much don't use computers at all or come to terms with the fact that almost *everything* is going to mass farm your data
 

Likely

kiwifarms.net
Joined
Dec 29, 2013
Without completely airgapping your computer in a safe deep in the ocean you can't protect against this threat.
Useless whataboutism. Nothing is perfect. More controls and depth raises the difficult for attackers and the effectiveness of the security model. But the baseline protection of this threat is ensuring that no untrusted code is run in kernelspace under normal operation. Any broken link from start to userspace execution violates this.

Saying "Secure Boot defends against kernel driver infection" is like saying a locked window protects against someone breaking in through your door because when the window isn't locked you can enter through it and then open the door from the inside.
It's just stupid.
Lmao wrong

You're applying a completely different analogy to a process that is NAMED after an analogy: a chain (of trust) is only as strong as its weakest link.

And additionally you tried to paint Secure Boot as a proven deterrent for kernel driver infection even though that is not true at all.
Lmao wrong

I don't know why you have such a difficult time with understanding the concept of a "chain of trust".

If you're really interested in not looking like a dumbass, take a look at these docs that explain implementations of modern chains of trust in boot processes. The apple stuff is actually quite good docs
https://koansoftware.com/secure-boot-and-chain-of-trust/
https://css.csail.mit.edu/6.858/2014/readings/ios-security-may12.pdf pg 4
https://support.apple.com/guide/sec...r-ios-and-ipados-devices-secb3000f149/1/web/1
https://support.apple.com/guide/security/boot-process-secac71d5623/1/web/1
https://www.apple.com/ca/business/mac/pdf/aaw-platform-security.pdf pg 26

(Actually, Apple is using their TPM-style equivalent to do boot process verification, although still in a relatively limited capacity. But that's also for other reasons than just "trusted boot".)

Far fewer people use the whole chain of trust with TPM and Secure Boot and everything than people using just kernel driver signing which almost every Windows user has used since Vista.
this betrays a fundamental misunderstanding of the place the TPM has in the Windows/eUFI security model. Also saying that "far fewer" people use Secure boot than they do kernel driver signing is unambiguously wrong.

Correct that the TPM is not required for secure boot/trusted boot, sad that you think saying it is some sort of revelation . The TPM's actually not really REQUIRED for anything that most users will do - almost every feature that "requires" it can be configured to use less user friendly or inferior options. You don't seem to have a good grasp on the role of the TPM/SE in a secured computing environment.

Also, literally every mainstream OEM windows PC and most self-built ones as well has shipped with "secure boot and everything", not to mention the vast majority of OEM built made since 2016 or so ship with a TPM.

It's a pretty safe bet to say MOST people use the whole chain of trust with TPM and Secure Boot and everything.

Oh and Microsoft's own documentation says TPM isn't required for Secure Boot. There goes your chain of trust.
fundamental misunderstanding of the place the TPM has in the Windows/eUFI security model. It's not really used for cryptographic operations except when those operations are using protected key material. Such as: BitLocker keys or protected applications such as DRM (applying a KEK to yield a DEK (in the tpm) and then send that DEK to kernelspace for further decryption).

In fact, considering the speed of the TPM and the capabilities (mailbox style api over spi), doing secure boot or trusted boot operations with it would probably add minutes, if not hours to a boot process.
 
Last edited:

Rusty Crab

cowboy hats are crab hats
kiwifarms.net
Joined
Jun 20, 2020
I am NOT jumping into this pool of spergery, but I got curious and started doing some research on ME today.

There's lots of resources available, and hacker conferences about messing with it.
The long story short is that if it were malicious, you would not expect it to be designed the way it is. It's a modular system and different parts can be turned off (and by that I mean completely wiped out) independently without interfering with the boot process. It's not tamperproof in the way that you would expect an espionage system to be. On newer generations it can be turned off easily(ish) if you have the right equipment.

Despite all the claims I've heard, it's not encrypted, just encoded to save space. People have gotten around this without too much headache.

I am NOT making the claim that it's not a backdoor. I am saying that it's a very oddly designed backdoor if it is one.