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

[Luke]

No. What you are saying is wrong on two points:

1. The second party doesn't have to trust that you have put the TPM into your computer. If you didn't put the TPM in the socket, the second party (e.g. Netflix) simply detects that the TPM is not there and refuses to provide you the requested content or service.

2. There can not be a fully "open-hardware" TPM. The point of a TPM is that a part of the implementation is secret, otherwise it can't be a TPM (it can't perform its basic function).

In terms of point 1, I have never intended to support Netflix or any other provider of DRM media on my devices. I have never even seen their homepages and don't want to. I do not watch TV and refuse DRM'ed media. They don't need to trust my computer and are never asked to.

2: A cipher implementation is only considered secure if it is secure when ONLY the key is private. As soon as implementation details also have to be private, they become in essence a part of the key that is common to all users, an actual security risk. Any nation-state level attacker can X-ray a TPM, count the zeros and ones and draw the schematic, thus reverse engineer every detail of the implementation.

3: Main plus of a TPM on my box would be use as 1/2 of 2FA disk encryption, with key recovery difficult but not impossible for an attacker. Passphrase is other half, but making the encrypted (w the pasphrase) LUKS key hard to get reduces the number of attackers capable of even beginning an attack. Probably locks out local and state police departments, probably does not lock out FBI and Secret Service, definately does not lock out NSA, but all of those still have to try the dictionary attacks etc, and that comes down to how important you are and how many more important machines they have waiting in line for supercomputer time. A quantum computer kills PGP but does NOT kill symmetrical disk encryption or any other symmetrical cipher, just cuts the effective keyspace in half. This is because factoring large primes is not part of the task.

Downside is a closed TPM could be set by its maker to send that key to a remote attacker, running the number of potential attackers back up, and raising the risk of a one-visit attack (e.g. a single raid) scoring after remote preparation. An Evil Maid is a two visit attack, first visit has to be covert. There's a lot to be said for never having the board connected to any network it can read or write too without a key stored on the encrypted disk, unless networking is only physically plugged in post-boot. That could be worked around,but would require the makers of a malicious TPM or CPU to expect and prepare for use of that defense.

[Luke]

No. What you are saying is wrong on two points:

1. The second party doesn't have to trust that you have put the TPM into your computer. If you didn't put the TPM in the socket, the second party (e.g. Netflix) simply detects that the TPM is not there and refuses to provide you the requested content or service.

2. There can not be a fully "open-hardware" TPM. The point of a TPM is that a part of the implementation is secret, otherwise it can't be a TPM (it can't perform its basic function).

Original answer unapproved:

In terms of point 1, I have never intended to support Netflix or any other provider of DRM media on my devices. I have never even seen their homepages and don't want to.

2: A cipher implementation is only considered secure if it is secure when ONLY the key is private. Any nation-state level attacker can X-ray a TPM, count the zeros and ones and draw the schematic, thus reverse engineer every detail of the implementation.

3: Main plus of a TPM on my box would be use as 1/2 of 2FA disk encryption, with key recovery difficult but not impossible for an attacker. Passphrase is other half

Downside is a closed TPM could be set by its maker to send that key to a remote attacker

[F.Ultra]

Regarding evil maids and the need for a computer to authenticate itself to the user before the user types in the hardware unlocking password:



That USB dongle is actually creating and authenticating a secure pair dongle-computer. If both the USB dongle and the computer are tampered, this scheme will fail. I think it is not really more secure or less secure than the two-passwords method, but it is different and has some drawbacks and some benefits.

It is a really nice idea, except for some small problems, that can usually be avoided:
- You need a programmable (microcontroller) USB dongle with an indicator on it. Is anyone selling those?
- You need to keep that USB dongle with you all the time (you can't go play a waterpolo game).
- It can be defeated in the same way as the two-passwords scheme. The latency test makes this harder, but not impossible.
- For full security, the user still needs to type in one password (to authenticate himself, to discourage attempts of evil maid to gain full access to the computer by simply stealing the USB dongle).

Edit: I forgot, the problem of falling asleep: When the user falls asleep, how can he be sure that the USB dongle was not tampered while he was sleeping? This is similar to the "waterpolo" problem.

I didn't say that such a device exists, just that it would be more secure since you now bypass the problems that you listed with the dual password thing in that the input value cannot be observed by any other means that also creating a new fake USB port that remotely transfers the challenge to the real computer. If this is implemented on the computer, not as software running on the cpu, but in something like the TPM chip talking directly to the USB-port then we have deterministic latency which any wireless networking would skew.

Just for kicks we could also design the dongle and the thing inside the computer to do millions of these filling the 20Gbps bandwidth (or close to), good luck being able to shrink down a 20Gbps wireless device to the size of a USB hub inside a laptop.

Add a pin or password requirement on the dongle and we solve the problem of losing the device and it being stolen in the sleep. But you covered this already. Preventing tampering is of course a problem as it is with every kind of key, so there have to be some kind of tamper proving going on, eg fill it with inert gas and a sensitive pressure sensor, if the pressure changes then clear the nvram, vary the pressure in each device so that you can't just put it inside a box with the same pressure and open it there. But yes the complexity quickly escalates.

I think we can go on all day since this is basically an insolvable problem, all you can do is shift the cost for an adversary enough so that it's cheaper to not attack the system.

[F.Ultra]

I wasn't reffering to a particular TPM implementation, I was refereing to any TPM from a theoretical standpoint.

Also, there are other potentially malicious actors besides MS in the TPM/Pluton chip production chain.

Also, a backdoor hidden inside a TPM would be very hard to detect. Worse, it would be very hard to prove that a backdoor exists inside a TPM if that backdoor is not being actively used. Software backdoors are much more risky: if someone finds it by inspecting the code, MS would end up in sued in court.

There are others in the TPM community yes, I was mostly replying to (which is not an argument that you made specifically) the fear of Pluton which is a MS invention even though they have outsourced the actual creation to the chip makers such as Intel and AMD.

Finding a backdoor inside a TPM would be hard but not for the intended target, I mean the intended target for something like this would be a foreign government or security agency by orders of CIA/NSA and those should have the capability of inspecting TPM chips on commodity hardware. Which is of course why they wouldn't target them in this generic way making the whole idea even less credible.

Also we have other actors like AMD and Intel creating their own security chips and making them TPM compatible so now you have to convince several companies to implement the backdoor and also hope that their thousands of engineers are keeping their mouth shut (completely impossible). Which of course is not to say that some particular manufacturer of a TPM chip goes rouge and decides to implement their own backdoor into their own chip, so of course this is not an argument that there cannot be a TPM chip out there with a backdoor, just that I have a hard time seeing it being done on a wide scale and being the deliberate design by the creators.

In the end I don't think that we really are in disagreement :-)

No. What you are saying is wrong on two points:

1. The second party doesn't have to trust that you have put the TPM into your computer. If you didn't put the TPM in the socket, the second party (e.g. Netflix) simply detects that the TPM is not there and refuses to provide you the requested content or service.

2. There can not be a fully "open-hardware" TPM. The point of a TPM is that a part of the implementation is secret, otherwise it can't be a TPM (it can't perform its basic function).

Regarding 2. he is not wrong. All that is needed to be kept secret is the internal encryption key of the TPM, not the implementation. So we can have an open design and an open firmware as long as we then have a means to burn a secret key into it. Since that key have to be burned into the chip at production to keep it tamper-resistant there is of course a practical problem for a "do it at home" solution here. But the manufacturers could be way more open with their design and especially their firmware.

[Old Grouch]

From what I can figure out, there are 3 classes of "TPMs":

1. write-only storage (nvRAM) - A TPM has some flash (nvRAM) memory on board to store a private key, and a crypto processor that can encrypt data using that private key. This kind of TPM is sufficient for a secure boot (the assumption is that the attacker cannot get the keys from the write-only storage).

2. "authenticable" TPM - a second party (e.g. Netflix) can verify that a TPM is a genuine TPM by verifying that the public part of a TPM's endorsement key (generated and burned-in during manufacturing) is one of the "trusted" public keys. I didn't know that this class of TPMs exists, but this is, apparently, the current-generation of TPMs.

3. "tamper-proof" TPM - it is a bit harder to define whether the implementaion of this kind of TPM is secret or not. To simplify, this TPM can have a fully open implementation, except for a secret that is burned in during manufacturing, but thic secret cannot be extracted from the TPM by X-rays or any similar technology. This kind of TPM would provide unbreakable DRM, and lead us to all the good and bad implications of that (read: https://www.cl.cam.ac.uk/~rja14/tcpa-faq.html).

I'm not following what you mean by 'write-only storage', which is /dev/null. I don't see how that helps. I think you mean storage in an enclave only accessible by a crypto processor. The (enclaved) storage is for holding keys/certificates, such as public keys, which can be used to confirm that a signature has been produced by the corresponding private key that is held by somebody else. The reason you hold the key in enclaved storage is to prevent a malicious actor from replacing a legitimate public key with a different public key and thereby misleading you into thinking that code signed by the corresponding private key is legitimate. The crypto-processor and key storage still need to be secure.

[Old Grouch]

I think you need to do a bit more background reading regarding TPMs, enclaves, public key cryptography, password verification, key expansion, and how the linux kernel goes about using (long) keys such as where it stores them, how it computes with them, and the concept of memory (page) protection.

As for authenticating things: people don't use encrypted banknotes. On the other hand, they are very interested in assuring that the banknotes they use are authentic.

The same is true for software: in general, you are interested in running the same software as whoever you trust to provide it to you, so you can be sure it has not been maliciously tampered with. You do that by authenticating the software to be the same as the provider's. You are not looking to keep it secret, which is what encrypting it will do.

Now encryption <i>can</i> be used as an anti-tamper mechanism: for someone to tamper with your encrypted software, they would need a decryption key, so for as long as you are sure that your key has not been compromised, you can be sure that your encrypted software has not been tampered with. However, encryption does not tell you if the software is the same as the original. Somebody <i>could</i> have decrypted it, altered it, and re-encrypted it, and you would be none the wiser. This is why you need authentication, to make sure that that has not happened.

[Old Grouch]

... you just claim that I'm not sufficiently knowledgeable.

I'm really not an expert on this stuff, just a hobyist. But, you seem to be much less knowledgeable then me, judging from your comment.

That's my opinion, but it could be wrong. If you believe yourself to be sufficiently knowledgeable, that's fine.

Perhaps I am less knowledgeable on this topic than you. Certainly, if your judgement is sound, in which case you can gain nothing more from me. Thank for your comments, and this thread is at an end.

[F.Ultra]

Also, I'm not exactly sure what would be the point of autheticating a bootloader, a kernel and initrd, without encrypting them?

Perhaps you can leave your root fs unencrypted or some other partition unencrypted, but that makes you really vulnerable. The bootloader, kernel and initrd should definitively be encrypted.

EDIT: Oh, I got it: you need to prove that you don't have some illegal software on your computer. Perhaps you are at the customs or something. So you can't have the kernel encrypted, thus you only need certificates and public keys in the TPM.

Is that what this misunderstanding was all about?

But wait, in that case, you can still encrypt just the bootloader, or a very small part of it. Also, how does the customs know that you don't have the illegal software hidden inside the TPM? Or, hidden in a WAV file (steganography), or in an empty partition?

The key point is that since the bootloader, the kernel and the initrd are all public knowledge already so encrypting them give no advantage. They are authenticated not so that customs can check that you have no illegal software hidden but so that you the user an rest assure that you are booting the kernel that you think that you are booting.

Encrypt your root fs with the hardest key on earth and your whole system is still compromised if an attacker can switch out the kernel or the initrd from under your feet. And it doesn't have to be a compromised kernel, it can just be an older one with a known vulnerability that the attacker uses later to gain access to your system.

I don't know of any DRM scheme on a PC that uses any TPM chip for anything, not really sure how it would work either. For that you instead need a Trusted Execution Environment like the Intel SGX or AMD PSP. The TPM chip does not provide a TEE, Pluton might but I have no idea.

[F.Ultra]

The problem is that you are not reading the discussion carefully enough

That might be true, I only replied to your comment as it was quoted in my reply, if what you wrote there was some out of context reply to Old Grouch in a way that didn't really represent a question or state of fact from your side then I'm sorry if I replied to the wrong thing.

[F.Ultra]

Yes, it was a reply to something that Old Grouch implied, but he didn't actually say it. I prefer to have the bootloader, the kernel and the initrd encrypted, not just authenticated, even when I'm not going to encrypt the rootfs, and even when I haven't made any changes to them.

Ok, well can't argue against that. My only grief was that it looked like encryption vs signing, but as long as it's signed, adding encryption of course does nothing bad. There are though a few people out there that believe that encryption will suffice over signing and that was what I reacted to.