How much important is TPM?

[Vít Šesták]

AFAIU, TPM is useful mostly for AEM. But AEM requires Intel TXT (which is missing even on some high-end CPUs). But TXT has various vulnerabilities. How much real protection can it offer? Is it worth the hassle (finding a laptop with both TPM and TXT and installing and using AEM)?

To be honest, I don't know much about TPM/AEM/TXT.

Regards,
Vít Šesták 'v6ak'

[Jean-Philippe Ouellet]

On Tue, Mar 28, 2017 at 2:40 AM, Vít Šesták
<groups-no-private-mail--con...@v6ak.com>
wrote:

> AFAIU, TPM is useful mostly for AEM. But AEM requires Intel TXT (which is missing even on some high-end CPUs). But TXT has various vulnerabilities. How much real protection can it offer? Is it worth the hassle (finding a laptop with both TPM and TXT and installing and using AEM)?
>
> To be honest, I don't know much about TPM/AEM/TXT.

Without directly answering your question (others in this community are
much better qualified to do that), I can offer the following:

See Joanna's "Intel x86 considered harmful" [1], particularly chapter
2 ("The BIOS and boot security").

Since publication of that paper we've seen increased availability of
Intel Boot Guard (moving the CRTM into the CPU rather than on mutable
flash potentially being executed before measurement) although whether
or not this really matters in practice remains unclear given the
typical long and complex chains of trust after that inherent to static
chains of trust to begin with.

Heads [2] is the best attempt I'm aware of to do something about the
"long chains of complex unauditable crap in your TCB for boot security
with a static root of trust" problem, and also did not exist at time
of publication of Joanna's paper.

[1]: https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf
[2]: https://github.com/osresearch/heads

[cooloutac]

if you worried about physical compromise more likely. like if you travel with a laptop probably a good idea. for a home desktop that would depend, but less likely in most cases, because then you got other more important security problems then your computer.

Also i'm not sure but does using a usb boot key affect sys-usb? possibly a tradeoff maybe someone else can chime in.

[Steve Coleman]

Without a TPM you will be limited as to what you can do with any TCG
Opal compliant self encrypting drives (SED), and for a laptop this is a
very interesting feature to loose. Most all SSD's I know are Opal
compliant and many laptop spinning drives are as well. Take a look at
the rpm package sedutil to see the tool description, which under Qubes
would for now only work in Dom0 due to no TPM's, nor Virtual TPMs
(vTPM), being available to the user VM's domains. Just be aware that
sedutil has a steep learning curve, but it is worth it once you get your
brain wrapped around how it works.

I have done many interesting things with these drives that you might not
even think are possible, but with Qubes the best feature I could
envision is having a read-only boot partition where the system
configuration is first measured by the tamper-proof read-only protected
bootstrap kernel via the hardware TPM before the invisible Qubes-OS
partition is even mounted and launched. An AEM on steroids, because you
can not even physically write to the drive, and you can't even inspect
the actual encrypted OS that will boot if everything is
cryptographically matched. I'm working on a similar bootstrap project
configuration in my spare time which one day I would hope to extend to
my Qubes desktop.

Once Xen is launched it should be possible to launch virtual TPM's for
the user domains so that kernel or application keys can be securely
managed to create VLAN's, sign documents, etc. Having a vTPM might even
allow sedutil to be used for storing and locking data or even for
running user VM's (e.g. Offline storage for Tor Network VM's) on Opal
SSD drives, if the commands can pass-through the virtual sata emulation.
I don't know if that will work or not. If it does there are many, many
cool uses to try if I ever have the time to play with that technology
with Qubes. The problem being I only have my one desktop and can't
afford to pull the rug out from under myself here at work where I don't
have the tasking to play with this at the moment.

Anybody out there have any success installing Virtual TPM's under Xen?
If so please ping me offline.

Steve

[Vít Šesták]

Thanks for your responses. p

In this thread, I'd like to discuss how much can it help (i.e., how hard is it to bypass).

On self-encrypting devices: I generally don't trust those implementations to be well-reviewed and well-designed, so SED is not a use case for me.

Regards,
Vít Šesták 'v6ak'

[cooloutac]

I think secure boot would make it better, but maybe a controversial thing to say. I don't know much about this subject myself, but I don't think it actually stops anything. Just lets you know if something has changed. Like a file integrity program kind of.

And if something does change there is no fix so you will have to replace all the hardware. (If thats something you're willing to do).

You can also do other things like nail polish on screws or crevices. photo them before you leave it unattended... strongbox? lol

[cooloutac]

Actually I say all that but supposedly hacking teams insyde bios hack worked remotely also. So maybe physical attack is not only vector, especially now we know that its possible for intel me to turn on wifi when we don't know it. Or some have some cellular connections. Even vpro/ME first came out was always for adminstering pcs remotely if off or crashed os.

[Tai...@gmx.com]

Microsoft's "Secure" boot is made for security, as in - the security of
their income stream.
So what you can't easily mess with the boot loader, well that doesn't
matter as you can still replace critical system files (verifying all
these would take too long and could cause problems)
You aren't allowed to install a new boot loader with a SB system unless
it comes with the disablement option - that's it.

It is a signing key based loader for EFI, but you can do the same thing
with a variety of FOSS boot-loaders just without supporting their bullshit.

One day you won't be allowed to install linux on "your" (theirs)
computer, already 99% of computers are not owner controlled as they were
a decade ago - and secure boot 2.0's spec removes the disablement option
mandate and 3.0 will probably be enforced with some kind of ME/PSP scheme.

[Vít Šesták]

I agree that secure boot is not a good protection against malware. Even if we consider just dom0 protection, without considering AppVMs:

With systems allowing a limited level of customization (e.g., ChromeOS or Android), this might provide a limited level of protection. It can guarantee that you boot a signed image with a signed root filesystem (see dm-verity). On Android (and probably also on ChromeOS), writable (and thus unverifiable) partitions are usually mounted with nosuid and nothing seems to be executed from them with root privileges, so you are *theoretically* protected. But don't overrate this protection: As soon as some suitable vulnerability is found in the kernel or other privileged component, the malware can root the phone on every boot and even take full control and prevent kernel update (blue pill or chainloading). And even if some vulnerability is impractical for rooting on boot (e.g. it takes hours until winning a race condition), the malware could downgrade the kernel to an older version that has more known vulnerabilities.

With system allowing you to install any driver, the first driver that is loaded can contain malware and so on.

Qubes is today the latter case. Maybe ITL with some partner could sell laptops restricted to boot some restricted QubesOS only, so one would not be easily able to run unauthorized software in dom0. This would be essentially the first case where secure boot offers a limited security advantage. But I don't think it is worth the work and the restrictions. QubesOS tries to prevent the attacker from getting into dom0 in the first place, which has better benefit than we can get from secure boot.

When protecting against evil maid, the situation is different a bit. We assume that the attacker has some limited physical access (e.g., she cannot replace your CPU with some backdoored version), maybe she is just able to boot some custom OS image. So the can modify any content on your HDD/SSD. However:

* If she modifies grub or some similar component, she should be caught by AEM.
* If she wants to modify something else (e.g., some bash script in dom0), she will need to alter the encrypted drive. While encryption is not generally a good protection against modification (see malleablity of stream ciphers or CBC mode or some other ciphers), it can provide a poor man's authentication if the cipher is not malleable in a much practical way and/or the attacker does not know the position of the file to alter. Worth to mention, this is the main difference from malware running in dom0 that has also access to a mounted filesystem.

The problem is:

1. The AEM is not perfect. Various vulnerabilities have been published and I am unsure what level of real protection (i.e., not just obscurity) can it provide.
2. AEM is not for free. When filtering only laptops with TXT+TPM, you have quite limited options, selection will take more time and it will probably result in a more expensive laptop. It is really worth the limited protection?

Regards,
Vít Šesták 'v6ak'

[Steve Coleman]

On 04/01/2017 07:31 AM, Vít Šesták wrote:

> The problem is:
>
> 1. The AEM is not perfect. Various vulnerabilities have been published and I am unsure what level of real protection (i.e., not just obscurity) can it provide.
> 2. AEM is not for free. When filtering only laptops with TXT+TPM, you have quite limited options, selection will take more time and it will probably result in a more expensive laptop. It is really worth the limited protection?

This is the problem I was trying to address when talking about the Opal
drive capabilities. Encryption is not the only thing Opal can do, and if
you have an SSD you likely have this extended capability onboard
already. For instance, all Samsung SSD's have Opal onboard, but you may
never know its there unless you activate it. If you have one its already
encrypting by default but using a default key found on the label.

When a range covering the boot partition is marked read only the drive
will prevent _any_ tampering, even using root system privs. Once booted
and everything is properly measured (TPM or home grown) one can then
choose to unlock that ro partition or just grub/chainload into another
rw partition containing a protected system OS. The way I see it, one can
boot Xen from a read-only (aka Xen isofs) partition and then test,
expose, and then load Qubes proper from the next partition.

All this requires hardware wise is buying an off the shelf SSD drive,
and the Opal capability (usually) comes for free, as well as the
additional boot performance of an SSD you might gain. You don't even
need encryption enabled, just a defined region that write protects the
MBR and first boot partition. Using both a read-only partition and
trusted boot measurements is a belt-and-suspenders kind of protection,
up front, before anything even becomes modifiable. This can be used to
test for any extra hardware attached that might be trying to intercept
the boot process aiming to take control at a later point.

From a cold system, if you can't write to the partition, you can't hack
the bootstrap, even after the system gains root privs. If you can't see
the next chain-loaded partition, you can not reverse it to even know how
to hack it. You also can not physically disassemble the device to
recover a key, because its not stored there, only a portion of the
entropy that is required to re-create the key on the fly is in the
device. You will still need a secret to unlock or make it rw for
patching or for permitting upgrades, and that entropy can be encrypted
by the TPM/SRK/KEK, or the user can provide a password for doing those
required updates.

Some coding will be required to make it idiot-proof and easy-to-use, but
the benefits of being nearly tamper-proof would be raising the bar even
for even nation-states to climb over. I really need to make time to get
back into this project.

Steve


> Regards,
> Vít Šesták 'v6ak'
>

[Vít Šesták]

That sounds interesting. Well, I don't think Opal provides a better protection, but it comes with a potentially lower price. I'll try to compare level of protection, correct me if I am wrong:

Persistent malware installed from a running system: Both are rather clueless unless you decide to lock the system very much. In practice, you would have to prevent even autostart of custom bash scripts.

SSD/HDD-based cold Evil Maid attack: Both can protect you from SSD/HDD tampering. (Provided that you consider the poor man's authentication as a real protection, i.e., you believe that the dm-crypt encryption is not *practically* malleable.) Worth noting, this is likely to be the most common scenario, since iit does not need to handle various BIOSes etc.

Tampered firmware combined with DMA attack: TPM theoretically could protect you, Opal cannot.

BIOS-related attacks: It depends. If attacker flashes BIOS, TPM might help you, while Opal cannot. But if attacker tries to maliciously modify some SSD/HDD data that BIOS parses in order to perform buffer overflow in BIOS, Opal could prevent this, while TPM might be clueless.

Copy attack: Attacker might take an identical model of the SSD and copy all data there, effectively disabling the Opal protection. But maybe if attacker has enough time to perform such tampering, you are already out of luck, since she can instal keyloggers etc.

Regards,
Vít Šesták 'v6ak'

[cooloutac]

Yes my board and most let you use custom keys. Its still called secure boot. Yes Gentoo and Fedora has instructions how.

Richard Stallman even concedes now that secure boot is ok to use. Because in its current state and due to the failure of its intended purpose, it actually has a security benefit.

And yes its not perfect. but wouldn't it compliment aem?

[cooloutac]

The hacking teams insyde bios exploit could only have been stopped with secure boot.

[Tai...@gmx.com]

Opal is proprietary garbage, and proprietary crypto schemes are almost
always terrible. (there is also no real way to check that it is actually
working and still working).

TXT is intel marketing, it isn't anything special just DRTM vs regular
TPM SRTM that makes it so something can change slightly without having
to re-do the measurement. Of course there are also no libre devices that
have TXT (purism isn't libre[1])

[1] On the "libreM" no open source hardware init is performed their
"coreboot" is simply a wrapper layer, if you buy from them you get an
overpriced quanta laptop that will never be FSF RYF unless they bribe
someone to modify the certification standards.

[Steve Coleman]

On 04/04/2017 10:29 AM, Tai...@gmx.com wrote:

> Opal is proprietary garbage,

Actually its an open standard, not controlled by any government or
corporation. One link I provided was to the standard which gets down to
the data structure byte memory layout and data interchange requirements.

> and proprietary crypto schemes are almost always terrible.

They use standard encryption algorithms that have to pass very strict
compliance tests before a product is certified. The OEM implementation
inside the drive might be "terrible" but the algorithms will be correct
or it won't pass regression test certification.

> (there is also no real way to check that it is actually
> working and still working).

Difficult, yes, but not impossible. One link I provided was NIST tearing
one apart for deep inspection of the implementation. Governments do this
all the time. Granted you may not want to go to that extreme, but other
people do. Its just that those deep dives generally don't get published.

On the other hand, one should be able to read the firmware off the drive
and then decode it with IDA Pro to see exactly what the drive does, if
you are that interested. I take it your not that motivated to prove its
not garbage. I get that. I happen to have an natural curiosity in that way.

> TXT is intel marketing,

I plead no contest there. It is however better than doing nothing. Each
technology generally raises the bar a few notches. I would not bet my
life on any one technology. The best solution comes from using the
strengths of each technology to make up for the weaknesses of the
others. Understanding how to layer the strengths is the key to a secure
system.


Serious question: Ok, I am curious, if all these technologies you
mentioned are "garbage", then what do you see as the technological
solution to securing your own systems? Do you have one technology in
mind that someone could not find a way to hack through?

thanks in advance for your response,

Steve.

[Steve Coleman]

On 04/04/2017 02:27 AM, Vít Šesták wrote:

> That sounds interesting. Well, I don't think Opal provides a better protection, but it comes with a potentially lower price.
> I'll try to compare level of protection, correct me if I am wrong:

Ok, ;)

> Persistent malware installed from a running system: Both are rather clueless unless you decide to lock the system very much.
> In practice, you would have to prevent even autostart of custom bash scripts.

This startup code is the domain of IMA measurement, TPM or otherwise.
This has to happen before Opal or Software Encryption is unlocked. To
use the TPM your code must be in control to perform the IMA. That code
then must be protected from tampering, like being set read-only in
hardware. Software write protect won't help.

> SSD/HDD-based cold Evil Maid attack: Both can protect you from SSD/HDD tampering. (Provided that
> you consider the poor man's authentication as a real protection, i.e., you believe that the dm-crypt
> encryption is not *practically* malleable.) Worth noting, this is likely to be the most common scenario,
> since iit does not need to handle various BIOSes etc.
> Tampered firmware combined with DMA attack: TPM theoretically could protect you, Opal cannot.
> BIOS-related attacks: It depends. If attacker flashes BIOS, TPM might help you, while Opal cannot.

TPM can help in that the "secrets" are stored in the TPM hardware and
are not accessible to the BIOS or DMA directly. To get into the TPM the
malware would need the TPM administrative password which is not
generally used thus not available to make modifications. During software
updates that modify the IMA PCR value you will likely need the
administrative key to bond the drive to the new PCR value.

It the Opal drive is locked by the TPM PCR registers then the Opal drive
can only be opened for use if the magic value (correct measurement) is
obtained during startup. Once the drive is decrypted and the OS is
loaded then the DMA/BIOS is of course able to continue the attack.
Basically if you have a bad BIOS its game over, so the IMA must be sure
to check for this without relying on the BIOS itself to do it, and
purposely fail to unlock/boot if anything is detected. DMA attacks
likely depend on things like rootkits in your GPU/Network-card that
become resident even before your OS, so those BIOS's must be checked as
well, its debatable as to how effective that would be depending on how
intelligent the malware is.

Opal is designed to prevent you from gaining access to code/data before
the system has been verified, or the password is supplied by the user.
If its the actual boot drive you can load some code called the Pre-Boot
Authorization (PBA) onto the drive, that can be loaded to take care of
collecting keys, authentication, or whatever, before the drive is
unlocked and presents the OS/Data proper.

If the key for software encryption exists on the un/decrypted system
then BIOS/DMA have access to it, but not true for Opal. For either
Software or Opal the key can be stored in/by the TPM so that it is
encrypted by the TPM/KEK or stored in its internal NVRAM where it can
not be touched.

> But if attacker tries to maliciously modify some SSD/HDD data that BIOS parses in order to
> perform buffer overflow in BIOS, Opal could prevent this, while TPM
might be clueless.

I'm not sure I quite follow this line of questioning, so correct me if I
misunderstood you question.

Either SSD or HDD will store what you tell it, and you could tell either
to scramble its MBR, superblock, or any of their filesystem pages
causing the parsing of it troublesome. In the Opal drive these bits
naturally get scrambled and descrambled by using the same key, and for
SSD's they may get cached out to different memory chip pages to level
out the wear on the memory. No surprise there. Garbage in Garbage out.

The TPM is always clueless, because it is not an active processor, but
rather stores the current state derived by prior actions. During IMA for
instance you can tell it to take a hash and cryptographically increment
(extend is the correct term) a PCR value that you can then read but can
not change the value. BIOS nor DMA can overwrite that value but could
reset it back to zero for a denial of service. They can not force it to
take on a magic value that unlocks anything, nor unlock any key when
bound to a PCR. They could continually extend the PCR until it has the
value they want, but that is like trying for a SHA256 hash collision.

> Copy attack: Attacker might take an identical model of the SSD and
> copy all data there, effectively disabling the Opal protection. But
> maybe if attacker has enough time to perform such tampering, you
> are already out of luck, since she can instal keyloggers etc.

Once the data is exposed by unlocking, it is accessible, just like any
other storage device. So naturally malware can copy it elsewhere.

You can however layer a software session key on top of that device
encryption and store data in encrypted application level streams. One
could build an infrastructure such that an API provides an encrypted
streaming capability for subsets of cooperative processes thus making
all data at rest, even on the same drive, all have different sets of
decryption keys. The applications do not need to do more than open a
file while the TPM/API & encrypted Policy selects a descriptor for each
session stream. Obviously encryption hardware would be needed to stop
BIOS/DMA attacks on this. The TPM is far too inefficient to act as a
stream processor, but maybe in TPM 3.0? If so then even the application
would not need to know the key it is using, so buffer overruns won't
help the bad guy steal the key or decrypt that stream.

[cooloutac]

Yes Joanna talks about failure of txt in a paper.

Ya nothing is gonna be 100% libre when it comes to hardware unfortunately. In the 90s computer users were more educated and it was harder for intel and microsoft to get away with even minor changes. Like their processes collecting ids. It beca,e big news, like pentium 3s collecting id numbers hit big commerical news on tv. But nowadays everyone is using a pc and most users don't care or don't believe. Its all politics.

nothing will also be 100% secure, we gotta use what we got though. As long as it does not affect usability or have adverse affect on security, why not?

[Tai...@gmx.com]

On 04/04/2017 10:19 AM, cooloutac wrote:

>
> The hacking teams insyde bios exploit could only have been stopped with secure boot.
>

Uhh no that isn't true, and again you're using microsoft's marketing
name for something that is a generic technology (signing of kernel and
important files) implemented in grub etc.

On my libre coreboot system (not all coreboot is libre) I can use a
signing key mechanism to sign kernels and load them with grub installed
on my motherboards write-locked flash chip.


Do you work for microsoft?

[Tai...@gmx.com]

On 04/04/2017 12:36 PM, Steve Coleman wrote:

> On 04/04/2017 10:29 AM, Tai...@gmx.com wrote:
>
>> Opal is proprietary garbage,
>
> Actually its an open standard, not controlled by any government or
> corporation. One link I provided was to the standard which gets down
> to the data structure byte memory layout and data interchange
> requirements.

Open standards are arbitrary and they mean nothing, the actual
implementation is what matters.
How many drive firmwares are open source? (zero)

I could write up a secure system standard in 5 minutes, it takes no
effort and it isn't special.

>
>> and proprietary crypto schemes are almost always terrible.
>
> They use standard encryption algorithms that have to pass very strict
> compliance tests before a product is certified. The OEM implementation
> inside the drive might be "terrible" but the algorithms will be
> correct or it won't pass regression test certification.

As I sad just because it uses "AES" or whatever doesn't mean it is
secure, using standard algorithms doesn't equal security as the
implementation is always terrible (and if it isn't terrible there is no
way to tell as you don't have the source)
Crypto exploits are not algorithm hacks they're framework exploits 99%
of the time.
I guarantee those "opal" drives already have exploits for them floating
around the darknet.

>
>> (there is also no real way to check that it is actually
>> working and still working).
>
> Difficult, yes, but not impossible. One link I provided was NIST
> tearing one apart for deep inspection of the implementation.
> Governments do this all the time. Granted you may not want to go to
> that extreme, but other people do. Its just that those deep dives
> generally don't get published.

That is impossible, you can't know for sure without the source.
You could pay millions for reverse engineering and still not know for
sure, and of course you would have to pay again every time they release
a new drive or firmware update both of which are a dime a dozen.

>
> On the other hand, one should be able to read the firmware off the
> drive and then decode it with IDA Pro to see exactly what the drive
> does, if you are that interested. I take it your not that motivated to
> prove its not garbage. I get that. I happen to have an natural
> curiosity in that way.
>
>> TXT is intel marketing,
>
> I plead no contest there. It is however better than doing nothing.
> Each technology generally raises the bar a few notches. I would not
> bet my life on any one technology. The best solution comes from using
> the strengths of each technology to make up for the weaknesses of the
> others. Understanding how to layer the strengths is the key to a

> secure system. '
Again TXT is simply convenience, and it is pointless as to have it you
require a closed source BIOS - and every TXT laptop also has ME. there
is no "raising the bar" with anything that intel makes.
TXT is intel's marketing name for DRTM, intel's TPM's don't have user
configurable CRTM anyway so the security is questionable.

>
>
> Serious question: Ok, I am curious, if all these technologies you
> mentioned are "garbage", then what do you see as the technological
> solution to securing your own systems? Do you have one technology in
> mind that someone could not find a way to hack through?
>
> thanks in advance for your response,
>
> Steve.

Uhh you buy a libre native init blob free[1] coreboot system[2], flash
the onboard flash chip with signing keys grub2 loader that loads your
own signed kernels and then you enable write-lock on the chip so that it
cannot be flashed internally.

Problem solved.

What do you need all this security for anyway? (I see .edu maybe you are
a comp-sci student/enthusiast?)

[1] Most "coreboot" systems these days (ex: purism) are not open source,
with them coreboot is simply a wrapper layer that performs not hardware
init everything is done by binary blobs.
[2] There are currently three systems that fit this category which are
available brand new right now.

[Jean-Philippe Ouellet]

On Tue, Apr 4, 2017 at 6:21 PM, Tai...@gmx.com <Tai...@gmx.com> wrote:
> On 04/04/2017 12:36 PM, Steve Coleman wrote:
>
>> On 04/04/2017 10:29 AM, Tai...@gmx.com wrote:
>>
>>> Opal is proprietary garbage,
>>
>>
>> Actually its an open standard, not controlled by any government or
>> corporation. One link I provided was to the standard which gets down to the
>> data structure byte memory layout and data interchange requirements.
>
> Open standards are arbitrary and they mean nothing, the actual
> implementation is what matters.
> How many drive firmwares are open source? (zero)

Counterexample: http://www.openssd-project.org/wiki/The_OpenSSD_Project

[cooloutac]

You disagree with the experts then, not me.

[cooloutac]

On Tuesday, April 4, 2017 at 6:20:35 PM UTC-4, Tai...@gmx.com wrote:

Microsoft didn't create secure boot, intel did. They just tried to monopolize it and failed. Tell all the major linux distros that they work for Microsoft lol...

I see you are Libre guy, that explains alot, but why ignore my comment about what Richard Stallman says about "secure boot"? DOES Richard Stallman work for windows!?!? haha...

[cooloutac]

What you are talking about is "restricted boot" as RMS calls it. not "secure boot". If you control the keys I don't see the problem. You are more worried about what could potentially happen. Even though prior predictions have been wrong. Its good to be aware of the potentials for abuse. But lets not claim abuse when it hasn't even happened yet.

I mean I guess there are UEFI boards out there that don't let you disable secure boot or use custom keys? But I've never seen one.