Lennart Poettering Talks Up A "Brave New Trusted Boot World" For Linux

[F.Ultra]

Yes. I usually just say "encrypted" when I actully mean "encrypted and verified", because when you have something encrypted, verification can be trivially added.

Now, I have a question. In fact, it is more like a challenge or test, because I already know the answer (more precisely, I think that I know the answer).

In the two-passwords (at power on) scheme, the computer is supposed to present an image IM1 to the user after the first password P0 is entered. An evil maid installs an evil emulator on the machine. When the user turns on the computer, the evil emulator asks the user for the password P0, then the evil emulator decrypts the image IM1 with the password P0, displays IM1 to the user, and the user gives out the short password P1 to the evil emulator, at which point the evil emulator and evil maid have won.

How to prevent this kind of attack? Can anybody here give me the correct answer? Is it even possible to stop the evil maid (assuming that she cannot use wireless communications)?

Good question. In the communications world (so this should be quite similar) we can only do this with mathematics, e.g Diffie-Hellman key exchange. I have a hard time seeing how we could do something similar with our puny human brain, hence my first though with the usb dongle before (which of course moves the target to the dongle itself).

The two-passwords scheme is as far as I can tell as susceptible to a simple man in the middle attack as just using a single password (and case in point is the very question that you just asked that uses a MiM attack on the scheme), it proves to the user that the part of the computer doing the logon is not compromised (at least once since it only presents an image, after getting P0 the attacker now have P0 for ever) but it does not prove nor set up a secure communications channel between the user and the logon process of the computer and this is where the attack venue lies.

[ll1025]

That articles looks like a M$ PR, half of the technologies described are made in Redmond...

Anyway I am still trying to understand why do we need SecureBoot in the first place?

What a bunch of bullshit!

"I dont understand a security technology; therefore it sucks."

About 10 years ago I was doing some charity work prepping BYOD volunteer laptops for secure usage overseas. Several of them had bootkits on them. That is: there was a virus on Windows, but attempts to remove it would fail / it would come back because the NT bootloader had been infected and would reinstall the active code at boot. Removing them was possible because it was early in the arms race and there were still good removal tools that the bootkit was not designed to counter; today I would expect most removal tools to fail.

These sorts of attacks are juicy to malicious actors because if you get your code running early in the boot chain you can circumvent every protection the kernel can throw at you-- antivirus, hypervisors, disk encryption, all irrelevant. If you want a glimpse of what is possible, check out Kon Boot-- a solution for bypassing windows passwords without touching disk by using a pre-boot attack.

Secure Boot prevents these attacks.

[bob l'eponge]

- You don't need a TPM for that. A CPU with some on-board write-only flash is as secure as a TPM for the task that you are describing.

A write only flash ? How useful is that ?

I can sell you a 100Tb write only flash chip for $10 if you are interested. Please contact me if you want some. They don't even have pins, and don't consume any power. It's a wireless write only flash.

[Danielsan]

"I dont understand a security technology; therefore it sucks."

Experience already taught us that when we do not understand technology this is used against us...

By the way it is always a Windows problem, and this problem was raised by a M$ employee what incredible coincidence...

[Luke]

1. You can get the exact same benefits with the scheme I have described, like this:
- You don't encrypt a bootloader, you just encrypt the public keys and (public) certificates. That is sufficient to authenticate those public keys and certificates. Then the computer proceeds the same as with a standard TPM. No significant amount of data has been encrypted, so the customs is satisfied.<snip>.

In some environments (mine included) you are NOT permitted to allow customs in any country to examine your real data. They can look over the turned-off hardware for bombs, watch you turn it on, let it post, and NOT unlock it, but that's it: any further demands you are obligated to defy at any cost. You are advised to leave your electronics home, buy local replacements while abroad, and destroy those literal "burners" before returning home. At a mimimum phones should be factory reset. If you cannot afford a burnphone and a burn laptop, you cannot afford an airline ticket or thousands of miles worth of gas. An old protocol was a laptop with NO storage, and a non-persistant bootable USB stick or a live CD.

If you do not follow this requirement, you get the choice between letting officials of hostile governments examine your data(which in my world puts people in danger) or having to abandon the hardware to them permanently and hope your encryption key is strong enough to defeat them. The US cannot deny its own citizens re-entry over this, but outbound travel might be a do-over or even a permanent removal of the offending country from future travel plans. If the purpose of your trip is itself arrestable(e.g assisting antiwar saboteurs in Russia), traveling with zero electronics may itself attract dangerous attention. In that case a 3ed set of devices may be needed, you travel with dummies full of plausable fake vacation photos and fake shopping records.Add a few more to them on the trip, they are part of your cover. The "spicier" your mission, the more like a "normal" tourist the fake devices must look.

[F.Ultra]

That is a very nice analysis.

Let me, at this point, add another question:

How do you prevent an evil maid attack on a common computer with a common discrete TPM chip? Probable attack routes:

The attack AR1: The evil maid unsolders the boot EEPROM chip (SPI flash), and replaces it with her own boot EEPROM, on which she installs an evil emulator.

The attack AMM1: The evil maid replaces the motherboard. She keeps the old TPM (keeps the same keys) and keeps the old CPU. This time she replaces the boot EEPROM (as in the attack AR1), but she also install another chip that intercepts (as a MitM) all communications between the TPM and the CPU.

Hint 1: How do you normally prevent an MitM (man-in-the-middle) attack?

Hint 2: all current common discrete TPMs are vulnerable to AMM1, and they are likely also vulnerable to AR1. Both attacks can be prevented. You mentioned Diffie-Hellman (DH), that's good thinking, but you also need another small addition.

EDIT: Just one more clarification: By assumptions of the scenario, the evil maid cannot eavesdrop (or perform MitM) between keyboard keys and the keyboard controller chip (perhaps because the keyboard is transparent). Also, she cannot eavesdrop or perform MitM between LCD panel and the panel's controller chip.

I would say that with current technology, aka how commodity computers are currently built, there are no way to prevent an evil maid with that kind of resources. The attack scenario of an evil maid that a TPM is secure against is the one that will just try to install something on your computer with say a flash drive. Not some one that can or will perform alterations to the actual hardware that also leave no visible trace.

But let us not fall into a nirvana fallacy here, the kind of evil maid that can perform the hw trick is far and few between, and would be a government agent targeting you or your organization specifically. My best advice in that kind of situation would be to not leave your computer in a hotel room at all

[Luke]

That is a very nice analysis.

Let me, at this point, add another question:

How do you prevent an evil maid attack on a common computer with a common discrete TPM chip? Probable attack routes:

The attack AR1: The evil maid unsolders the boot EEPROM chip (SPI flash), and replaces it with her own boot EEPROM, on which she installs an evil emulator.

The attack AMM1: The evil maid replaces the motherboard. She keeps the old TPM (keeps the same keys) and keeps the old CPU. This time she replaces the boot EEPROM (as in the attack AR1), but she also install another chip that intercepts (as a MitM) all communications between the TPM and the CPU.

Hint 1: How do you normally prevent an MitM (man-in-the-middle) attack?

Hint 2: all current common discrete TPMs are vulnerable to AMM1, and they are likely also vulnerable to AR1. Both attacks can be prevented. You mentioned Diffie-Hellman (DH), that's good thinking, but you also need another small addition.

EDIT: Just one more clarification: By assumptions of the scenario, the evil maid cannot eavesdrop (or perform MitM) between keyboard keys and the keyboard controller chip (perhaps because the keyboard is transparent). Also, she cannot eavesdrop or perform MitM between LCD panel and the panel's controller chip.

You can't, because none of these fancy scenarios are even needed. Simplest attack on a laptop (known to be used by China's MSS) is a simple inline hardware keylogger. Remove the keyboard and unplug it from the board. Plug the keyboard into the logger and the logger into the board. Close up and you are done. MSS got caught doing this when some businessman on his way back to his hotel room considered a sudden approach by a sex worker suspicious (this tactic normally gets root on the "cishit male" brain) and raced back to his hotel room.

Problem with any software or firmware evil maid is having to predict the system you will be working with. Both desktop and laptop keyboards though use only a few common connectors both inside and out. A sack with a variety of keylogger devices can cover them all

[F.Ultra]

The attack you are describing won't work because I have said:
- all communications between the keyboard controller chip and the CPU are encrypted
- the user can verify that the original keyboard controller chip has not been replaced (perhaps because the keyboard is transparent and the original keyboard controller chip is marked by scratches and sprinkled with fingernail glitter; but there are other means of ensuring it)

But, thanks for the attempt.

Now you should say "but it doesn't matter whether the communications from the keyboard controller are encrypted, because..." Then I am going to reply that you forgot to consider...

Which can be defeated by applying something on top of the keys, aka you don't have to attack the keyboard controller to read what is being typed. There are even attack venues where a mere listening device can be used since different keys makes different sounds and the time between key pressed can be used to determine which keys where pressed with quite great efficiency. To beat this 100% we would need to have a secure encryption channel all the way between the CPU and our brain, at which point the attack venue changes to performing brain surgery on us when we sleep

[ll1025]

Well, that's the thing I have been discussing here all the time, but it is still unclear whether SecureBoot prevents the attacks, or just makes them harder, or it doesn't help at all.

So, I suggest that you join the discussion, but with arguments and proofs, not just unsubstantiated claims of the manufacturer.

Why don't you provide arguments and proofs that AES makes MITMs more difficult? This smells like sealioning.

Secure Boot very plainly works as shown by the need to sign a boot shim or disable secure boot for systems like *BSD or Linux distros. As far as I am aware there are no easy workarounds for this BUT to use a signed shim.

Are they foolproof? Of course not, a signed shim could be used for evil purposes, but the signature for the shim could also be revoked. But it's much more complicated than shoving whatever code into the bootloader, and those attacks it does stop.

It is part of a complete system for securing the boot chain, and if parts of that system are missing you will obviously have attack vectors that bypass things like Secure Boot; maybe thats a really good argument for Linux to start taking seriously the push to secure the boot chain, as Poettering has detailed.

[ll1025]

There is no known method of breaking AES (a symetric cypher) by MITM attacks. Would that suffice?

This is not true, there are known attacks on AES. Like secureboot, they're non-trivial; like secureboot, it offers good (but not perfect) security.

The question boils down to a cost-benefit analysis, and the sorts of attacks that secureboot thwarts were absolutely rampant 10 years ago before secureboot became commonplace.