The Secure Enclave on the T2 chip was used to store secrets that were supposed to stay inaccessible, even to someone with physical access.

If you use a strong password to encrypt your drive you should still be safe, unless Apple did something really stupid. The password is used as a one-way hash to generate the key.

However if you can login with Touch ID and they find a way to use known SE exploits, it's compromised. Your fingerprint isn't a secret that gets hashed – instead it's verified by the SE which also holds the secret key for the drive.

Isn't a password always required to decrypt on a cold boot?

Yes, but that doesn't help you if someone steals your MacBook when it's asleep.

Someone would have to DFU your laptop before hand and jailbreak the chip, since booting into DFU requires shutting the system down.

Wouldn't this mean the 'secure' values for these two processes within are now visible/ readable with the right tool/protocol availability?

Some one from Apple, I'm sure you read this. Please answer this ASAP. I rely on mac and FileValute for professional use at work. Need to know the state of this exploit.

lol good luck and god bless with all that.

> I rely on Mac and FileVault for professional use

... then phase out your use, because proprietary systems will always get cracked given enough time.

Good point, let’s switch to unbreakable open source systems based on OpenSSL instead.

This kind of advocacy is not only unhelpful but actually counterproductive

Software encryption is very often much easier to rotate than integrated solutions. When all the TPM chips were broken, Windows stopped using them for BitLocker, but didn't reencrypt any of the affected disks. They're just as vulnerable as they were.

Software encryption is also harder to protect without a trusted boot path. My point was just that this isn't a simple binary decision but rather something which requires review and defense in depth.

>FileVault for professional use

Probably not the best choice :) you never want to use proprietary software if security is a concern

Go count how many CVEs have come out for OpenSSL, GNUTLS, LUKS, etc. and ask whether you’re offering helpful advice. Security is expensive and there are no silver bullets: at the end of the day you need a lot of skilled work and being open source doesn’t magically get that for free.

That's apples and oranges.

Counting published vulnerabilities in open source systems vs closed source systems says nothing about the relative true ratio of vulnerabilities.

Are you seriously claiming that anything short of omniscience is useless? In most fields people deal with incomplete data on a daily basis and this is no different. CVEs don’t tell you everything but they definitely give you more than zero, and more to the point, the many vulnerabilities in open source projects suggests that the very broad but completely unsupported claim I was responding to is based on ideology rather than reasoned analysis.

> the many vulnerabilities in open source projects suggests that the very broad but completely unsupported claim I was responding to is based on ideology rather than reasoned analysis

Does it? In order to claim that, one would have to have some idea of (a) the ratio of disclosed vulnerabilities to true vulnerabilities discovered in both open source, accessible code vs closed source, hardware locked code, and (b) the relative ratios of disclosed vulnerabilities.

Do you have any idea what either ratio might be? 1:1? 4:1? 1:4? 100:1?

Again, the comment I responded to made an absolute claim but, like you, had no supporting evidence. Unless one of you can produce some evidence it’s hard to support the belief that this is based on data.

If you read the thread, note that I’m not taking a side other than finding it absurd to claim that all open source products are inherently better than all proprietary products with no analysis or data.

Unless you know the true ratio, you can't claim that open source projects are better either. Or that one has advantages over the other when it comes to cryptographic security.

I'm not GP and I'm not arguing for either side, just pointing i tout.

I disagree. There are times when either no open-source solution is available, or the open-source solution is unmaintained, or not popular (thus not under much scrutiny) and you don't have the resources (time and skill) to audit it yourself.

As long as the incentives of the developer of the security scheme and the end-user are aligned (so no backdoors), I would trust a widespread, proprietary solution which appears to stand up to significant attacks (the solution being widespread means there are lots of efforts underway to crack it) more than an open-source implementation that nobody uses.

As it stands now, from my understanding, the failure case of the proprietary solution is the same level of security as the best case of the open source solution. So I don't see your point. Open source isn't any better.

Open source full disk encryption can be password cracked without limitations just like a hacked T2 chip. A sleeping open source full disk encryption machine can be accessed with enough skill to pull things out of frozen ram, etc.

What is a non-proprietary solution for full-disk encryption?

luks

luks or zfs.

I want not note, that ZFS is not full disk encryption. ZFS native encryption was designed to allow secure backups via "zfs send | zfs receive" mechanism, so it encrypt only data blocks, and not metadata.

LUKS and GEIL are full-disk encryption systems, and if you need FDE, you must use them under ZFS, not ZFS native encryption.

>LUKS and GEIL

GELI ;)

ZFS native encryption on Root is ~IS full disk encryption minus the boot-loader, i would say that's "full" interesting data encryption.

Technically true but what is the situation that become problem?

Or Veracrypt.