Discussion on Purism

Do you still have the Librem 14?

I gave it to my friend as a novelty item :sweat_smile:

1 Like

Yes, it is absolutely true that free software only allows for the potential for these things to happen. We still have to follow up on it as a society. With proprietary software, not even the potential exists.

Defending against this problem is described in this paper. I’ll admit that I don’t know how widely this solution has been deployed, but that’s how security research works: people find problems and describe them, industry takes some time to catch up. Most of the time it works out because newly described problems are generally expensive to exploit and once they become cheap industry has generally caught up.

Yes, they can do that. This is why I replaced the GPG key on my librem key with my own and reflashed the firmware I downloaded using a different device.

The librem key checks a HOTP with the TPM before the key is used. The PGP key is used only for files on the boot partition, not for checking the firmware.

I agree that the attitude that the FSF has towards firmware is unhelpful. I do want my firmware to be free software but that’s not something that we can fix at the level of package management. We need to manufacture Wifi cards that are supported with free software. I am hopeful that Purism will do this at some point because they have already demonstrated a willingness to work with hardware manufacturers with their work on the librem key. Personally, I keep the bluetooth/wifi hardware kill switch on “off” unless I absolutely need to turn it on for some reason - which has only happened once since I started using it.

No, you’re misunderstanding how it works. The librem key only checks a HOTP with the TPM during boot. It also happens to operate as a smart card, so it is common to use it to sign the boot file hashes which are checked by the firmware which is verified by the TPM. But you could sign the hashes with a YubiKey just as easily.

2 Likes

Yes, it is absolutely true that free software only allows for the potential for these things to happen. We still have to follow up on it as a society. With proprietary software, not even the potential exists.

No, this is not how anything remotely works. People can still do security research on proprietary firmware as usual. What do you think Binarly does?

Defending against this problem is described in this paper. I’ll admit that I don’t know how widely this solution has been deployed, but that’s how security research works: people find problems and describe them, industry takes some time to catch up.

No, this is not how anything works. You are misrepresenting what it is saying. You cannot fix the problem without Boot Guard. SRTM relies on having an immutable root of trust, and Boot Guard provides that.

The research paper explicitly spelled it out for you: TPM is a passive chip, it receives measurements given to it - it doesn’t do measurements on its own.

The solution to the problem outlined in there is literally Boot Guard. And yes, it is widely deployed.

I do want my firmware to be free software but that’s not something that we can fix at the level of package management.

Why not? Just load the firmware in with the linux-firmware package.

Personally, I keep the bluetooth/wifi hardware kill switch on “off” unless I absolutely need to turn it on for some reason - which has only happened once since I started using it.

This doesn’t achieve anything.

No, you’re misunderstanding how it works. The librem key only checks a HOTP with the TPM during boot. It also happens to operate as a smart card, so it is common to use it to sign the boot file hashes which are checked by the firmware which is verified by the TPM. But you could sign the hashes with a YubiKey just as easily.

The key doesn’t do verification. This is not how Heads even work. A piece of malicious firmware can just lie about the PGP verification. Himeno understood this correctly - this cannot be achieve with a TPM and a USB connected device. It’s impossible.

1 Like

I’m not saying it’s impossible for any entity to do security research on proprietary code. I’m saying that users can’t examine the code themselves or decide which entity they trust to examine the code. They have to rely on the developers to check the code thoroughly or select a third party to check it for them. In either case, there is a clear bias (note that saying that someone has a bias is not the same thing as saying that someone is acting in bad faith). When the source code is available for public inspection there is the potential for audits from a greater diversity of views with contradictory sets of biases, creating the potential for a more secure system overall.

Additionally, there will always be people who are in peculiar situations with specific needs that are not generally applicable. With free software, those people can choose to do the work themselves or hire some trusted party (potentially in a competitive market) to do the work. With proprietary software, they have to persuade one specific party to do the work. For this set of users free software gives them more options to maintain a secure environment.

It is possible I misunderstood you. I am going to explain my understanding of the problem and the solution proposed in this paper as clearly and succinctly as possible in hopes that we can get back on the same page.

The problem is that the TPM is receiving measurements from an untrusted source (the BIOS), and so the source could lie in order to trick the TPM into thinking that it is valid.

The solution described in the paper is that values which will naturally be in locations which are fast to access (such as the current program counter which is stored in a register) are used as some of the inputs. A program which wants to give inaccurate values needs to pull the fake values from somewhere else which will take longer. Therefore, the TPM can check how long it takes for the untrusted source to produce its values in order to detect whether or not the inputs are real.

The problem that we can’t address is categories of hardware which don’t have FOSS drivers at all. Refusing to ship proprietary updates, and instead relying on the pre-installed proprietary code, does not fix anything. If FOSS drivers are available then shipping them is good. But refusing to ship updated WiFi drivers is not going to make FOSS drivers suddenly appear.

It prevents bugs in the WiFi and Bluteooth drivers from being exploited by remote attackers.

I said that the key doesn’t do PGP verification. It checks a HOTP with the TPM, and the TPM will not unseal the secret required to generate a matching HOTP if an attacker has modified the firmware. (This is obviously related to the above discussion about whether the TPM can actually do this. The discussion about whether or not the key is valid is a separate point, so for the sake of this argument I assume that the TPM has this capability). It’s the same thing as checking an authenticator app on your phone except that the key is comparing the value for you. In fact, when setting it up it gives you a QR code so that you can use an authenticator app if you want. The key just makes the process more convenient and less error-prone.

Once you confirm that the TPM has not detected any tampering the firmware can be trusted to do PGP verification.

2 Likes

This is not how anything works.

The TPM receives measurements from the firmware. The firmware measures itself, see which version it is, what is its loading, etc and report that to the TPM. The TPM releases the secret if the measurements match. The TPM does not do any measurements itself. It is a passive chip. The research paper you linked says as much. This is even in the specs. There is no point speculating about a capability that the TPMs are known to not have.

The threat here is that a malicious actor will flash malicious firmware into the EEPROM, which will lie to the TPM. The firmware you originally have is assumed to be trusted in the threat model.

If an attacker has access to your device, and it does not have Boot Guard, they can just flash malicious firmware that will just submit false measurements to the TPM. The malicious firmware doesn’t need to pull any value from any random source. It just needs to lie. And Heads cannot protect against this.

On a normal set up, you have Boot Guard which has the signature of the OEM fused into the PCH. If an attacker tampers with the boot block which is protected by Boot Guard, the CPU will notice that the OEM doesn’t have the signature of the vendor and refuse to boot. It doesn’t even need to get to the measurement part to get caught. The measurements with PCR0, 1, 2, etc are to make sure that the firmware version has not changed (like in the case of a downgrade attack), that the firmware settings which are not protected by Boot Guard has not changed, etc. This is the defense against an attacker who will try to compromise you with a programmer.

1 Like

The threat here is that a malicious actor will flash malicious firmware into the EEPROM, which will lie to the TPM.

“Technically, the TPM is passive and cannot actively read firmware, bootloaders, or other data. Instead, a read-only component of the BIOS called the CRTM sends a hash of the BIOS to the TPM, starting the chain of trust. This component is read-only to ensure that a modified BIOS cannot lie to the TPM about its hash.

Source:

3 Likes

What are you trying to prove?

What you have done here is linking a post which is correct if Boot Guard exists (as is the case with most modern computers), then try to use it as an argument against my point that the BIOS can be tampered with and lie if there is no Boot Guard, like in the case with existing Heads computers, including the Librem laptops.


The immutable part is the signature fused in the PCH (in the case of Intel Boot Guard) or CPU (in the case of AMD PSB).

The component that does measurements (at least the initial one) is the boot block (a.k.a the CRTM).

Intel Boot Guard and AMD PSB makes sure that certain part of the BIOS is signed by the OEM. This includes the boot block.

And attacker cannot mess with the boot block and make it lie because Boot Guard and AMD PSB are verifying it.

With Heads, there is no Boot Guard, therefore nothing is protecting the boot block, hence the boot block can be tampered with and lie.

1 Like

You may be right, I have not researched that part. The answer and the link in it don’t say anything about Boot Guard. It talks about CRTM. Another answer explaining about CRTM does not mention it either:

If the BIOS can lie about everything (including its own hash), then the TPM is useless.

1 Like

If the BIOS can lie about everything (including its own hash), then the TPM is useless.

The default assumption is that the BIOS from the OEM isn’t malicious so it wouldn’t lie. Boot Guard just verifies that a chunk of the BIOS is actually from the OEM (which includes the boot block), therefore an attacker cannot make it lie.

1 Like

New blog post from Jonathon Hall:

2 Likes

Hmm, the info is good but the font used in that blog entry is atrocious: the “3” looks like an “8”, and I wiped twice my monitor thinking it’s a speck of dust or lint on it! :sweat_smile:

1 Like

I agree with the complaint about 3s looking like 8s (though the top loop is open for me).

I’ve noticed another quirk though, for some reason the lower case t is only X height (i.e. the same as lower case x). This has been true for as long as I’ve been reading their blog.

1 Like

Short video from Jonathon Hall of the Librem 16 using 4 displays:

I understand that the TPM is a passive chip. The point about checking timing does not require that the TPM is active. It can check the time as part of processing the requests it receives.

2 Likes

There is no timing difference to be checked if the firmware already knows which value to use to lie to the TPM

1 Like

The paper describes sending data to the TPM in multiple pieces, not all at once. You can send a value to “extend” a current value which the TPM will combine internally. So the TPM could be programmed to expect that a specific number of values are sent within a specific set of time windows, and that the final value which the TPM calculates based on the series of inputs matches the expected value.

For the benefit of anyone reading this thread, I again want to emphasize that I am speaking only in theory. I do not know whether or not this logic is implemented in Librem hardware and I make no claim that it is or is not implemented.

1 Like

More photos of the Librem 16 prototype:

My response:

This is a ridiculous statement. Everyone has their own threat model and this one can be good enough for some people. Also @marmarek disagrees with you. Also AFAIK it’s the only way to provide security while keeping the user ownership of the hardware without blind trust in any corporation, including Purism.

Discussed here: https://forum.qubes-os.org/t/how-exactly-is-heads-pureboot-secure/23092. Key link from there: Notes on how to audit a maximized flashed firmware image · Issue #107 · linuxboot/heads-wiki · GitHub

This is a ridiculous statement. Everyone has their own threat model and this one can be good enough for some people.

It is objectively worse than Boot Guard, which is available on standard laptops. You haven’t even pointed out how it is not theatre, especially when compared to Boot Guard.

Also @marmarek disagrees with you.

No he doesn’t. You can’t defend an attacker with a programmer. The glitter business is pure luck, and you wouldn’t notice it until it’s too late.

Also AFAIK it’s the only way to provide security while keeping the user ownership of the hardware without blind trust in any corporation, including Purism.

Except its not how the world works, and entities like Intel are still part of the TCB. You just crippled security by making it possible for an attacker to be able to flash malicious firmware and still has it boot normally.

What ownership? You can’t even make the device not boot malicious firmware.

Discussed here: https://forum.qubes-os.org/t/how-exactly-is-heads-pureboot-secure/23092. Key link from there: Notes on how to audit a maximized flashed firmware image · Issue #107 · linuxboot/heads-wiki · GitHub

Exactly. I made that discussion. Nothing in that thread contradicts what I said. This is substantially worse than Boot Guard and cannot protect against tampering like Boot Guard can. Did you even read what you linked?