Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
[flagged] M1 Macs SSD “Encryption” trivially bypassed unless FileVault is enabled (kolide.com)
40 points by terracatta on Dec 29, 2020 | hide | past | favorite | 26 comments


As mentioned in the article, FileVault is practically enabled by default during setup. IIRC you have to go out of your way not to have it enabled.

> Because users are encouraged during setup to configure FileVault on new devices it is uncommon to see devices without it


I agree, with the caveat that it's worthwhile checking.

My brand new, personal laptop has FileVault enabled, but my work laptop does not. The article title is a bit misleading regardless since it's enabled by default. Should read "Encryption is trivially bypassed if you disable FileVault"... which seems pretty obvious to most people.


See my reply to the parent, FileVault will not be offered if you skip the iCloud setup, which many folks not wanting to mix their personal-life with their work laptop will skip.


If you skip Apple ID (which is an extremely common situation in a privacy conscious employee) you are not offered FileVault.

In my experience, it's extremely common to see FileVault disabled on unmanaged workplace Macs.


I don't get it, what's the problem with this? Did Apple' marketing materials suggest otherwise (ie. your data is safe even without a password)? Also, non-apple SSDs does this as well: https://superuser.com/questions/986387/why-does-my-ssd-inter...


Kolide is a snake oil vendor, so dangerous but ultimately meaningless warnings are their business. That "you have non encrypted SSH keys" warning on their landing page is giving me shivers.


Agree, and Apple seems to be up front about it.

See the last part of https://support.apple.com/en-us/HT208344

"Though the SSD in computers that have the Apple T2 Security Chip is encrypted, you should turn on FileVault so that your Mac requires a password to decrypt your data."

Edit: I do agree with the article's criticism of using a boolean to represent encryption status, but I don't agree with the dire sounding tone. Since you aren't entering a password, you should be aware that the key is hanging around in plaintext somewhere.


The problem is the FileVault is not enabled by default in certain situations (like if you skip iCloud setup when you first turn on a new Mac). Even though FileVault is off, popular tools like osquery will report them as "encrypted".

Yes that's technically correct, but not likely what the person querying means.


This is a non-issue. Submit something to osquery instead of trying to create drama.


.


You have to be pretty blatant and intentional to disable encryption, if you just coast through then FileVault will be enabled, at least as I understand.

Another perspective is it's great Apple doesn't force encryption 100% of the time. There are situations where you wouldn't want it -- very niche ones, granted, but I think the choice is a good thing.


.


Your iPhone is unencrypted in that same sense when you don't have the passcode set.


I'd say yes, albeit only if it's "available" and not something you could accidentally enable, or could be enabled through sabotage.

Having an unencrypted device could make it easier to reverse-engineer, improving consumer control and ownership of the device. Obviously not really Apple's shtick, but I think the choice is good, so long as you have to very specifically ask to disable encryption.


It is a non-issue: FileVault is enabled by default and while you can speculate about what would happen if Apple implemented Health storage without requiring encryption as they do on iOS that doesn't make it an issue until the unlikely event where they actually ship something which does that.


FileVault is not offered to a user setting up their Mac to the first time if they skip iCloud. People in a work setting will often skip this step because they aren't sure...

A) If they are allowed to connect their personal Apple ID to their work laptop

B) If this will sync personal files to their work laptop (which might be undesirable)

For personal devices, FileVault is now often on, but unmanaged devices specifically for work use? A sizable amount do not have FileVault.

In the past this wasn't a big deal, but now we have tools conveying that these devices are encrypted, when in fact, their data can be trivially accessed.


Unless the defaults changed in Big Sur, it's been enabled by default with or without iCloud for many years — perhaps you're referring to the separate option to store your recovery keys on iCloud?

Regarding work devices, do you have any data supporting that assertion? Even the linked article claims this is uncommon and the intersection of people who care about protecting from physical hardware access but choose to disable FileVault is pretty small. It's a good audit point but unless you have data showing this is widespread, consider whether you're doing more than pro bono marketing for Kolide.


I just wiped a new M1 device and set it up from scratch using the latest version of Big Sur. If you skip iCloud setup you are never asked to turn on FileVault. When you skip iCloud you are never told this will result in FileVault being disabled.

I took photographs of the entire process if you'd like me to provide proof.

I am the CEO of Kolide. An employee wrote this article because....of our customers who do not fully manage their Macs, the amount of them without FileVault can be as high as 1/3 of the entire Mac fleet. That number tracks with the UX of the setup screen I mentioned above. Esp for privacy conscious orgs.


> I am the CEO of Kolide.

That seems like an important detail to have disclosed.

I would recommend changing the title of that post to be less provocative and to add supporting data to it with the caveats about the selection bias behind it. It sounds like there was a regression at some point and ⅓ is definitely high enough to warrant attention but as written it sounds like clickbait to say that storage isn't encrypted when the storage encryption system is disabled. Since FileVault has always been the answer to that question, this is really more about understanding that it is still necessary and should be checked.


> It sounds like there was a regression at some point

You are continually asserting incorrect information about this topic.

The behavior I describe where skipping iCloud setup causes FileVault setup screen to not be shown as always been the case. There has been no regression.

Source: https://derflounder.wordpress.com/2014/10/25/new-filevault-2...


You're right about the skipped iCloud path — it's been too long since I've done that without automation (we use separate work iCloud accounts so it normally never comes up).

It doesn't really change the point, though, because this isn't a bypass or flaw in the encryption system but a gap in the initial setup flow. It's an important audit point and definitely good to surface for your customers but it's not exactly a surprise that if you don't enable storage encryption, you don't have encrypted storage. I know that there's a long history of attention-seeking blog posts from companies selling products but you're trying to make a reputation as an honest security company and I think that marketing is a key component of that.


> It doesn't really change the point, though, because this isn't a bypass or flaw in the encryption system

But it does. If what you stated earlier was actually the truth, then FileVault would be enabled on far more devices and your point about the post not really being as big of a deal as we are trumping it up to be would have some merit.

If we had written a blog post saying "Data on Encrypted iPhones can be trivially accessed unless a passcode is enabled", I would agree with your point because...

1) There is no historic context that Passcodes and encryption were considered the same thing.

2) There are no tools that confuse the differences between a passcode being set and encryption being on.

3) It is extremely difficult to set up an iPhone today without a passcode.

But none of those things are true on the Mac. Back in reality, a significant number of devices set up by organizations do not have FileVault enabled by default. Once you take that new fact into consideration and add the facts conveyed in the linked blog post and multiply it by tens of millions of Macs, you now have a high probability outcome that an organization will lose a device, act as if the contents are inaccessible to the thief, and learn later that the were acting on bad information.

It's a big deal to folks who could be caught up in the above scenario. We wrote the post for them.

> I know that there's a long history of attention-seeking blog posts from companies selling products

When you have something important to say, seeking attention is warranted. Just because we sell something doesn't mean it is correct to dismiss everything we say. HN is primarily a community of startups and hackers. Both are folks that may have found this content relevant.

We wrote this post because we have unique visibility into a substantive issue that requires educating MacAdmins about these differences so they don't get tripped up during an incident.

Tools like MunkiReport and Osquery are incredibly popular among these communities for collecting attestations about devices. This is especially true for shops who do not feel comfortable paying for a full MDM solution. The fact that these systems may cause admins to believe their devices have FileVault enabled, when in fact they do not, is a serious problem.

> but you're trying to make a reputation as an honest security company and I think that marketing is a key component of that

It's ok if we don't agree that this post is important or that the level of urgency is warranted (I think it's a super big deal, but I don't think I can convince you of that fact). That said, there is nothing dishonest happening here. We could have easily patched this issue for our customers, explained it only to them and moved on. We wrote the post because it's information we thought needed to be out there.

The error I made was assuming people knew that FileVault is not on by default in very common scenarios. We've amended the post which I think adds valuable context about that.

That said, I appreciate your thoughts.


> We wrote this post because we have unique visibility into a substantive issue that requires educating MacAdmins about these differences so they don't get tripped up during an incident.

I agree — my point is simply that Apple has always said that you need to enable FileVault to protect against physical access to the device and that didn't change with the T2 or newer Mac hardware. The most interesting part here to me is the osquery improvement you contributed since that exposes a situation which became more nuanced than it used to be.

I'm entirely supportive of anything which spread the word that you really want to make sure you confirm that FileVault is enabled. My objection was to the title wording which made it sound like some promised functionality wasn't working was a distraction.


> There is no setup question for the user to have an unencrypted iPhone.

The Mac has a lot of options you don't have on the iPhone, starting with what operating system you want to run. One of the reasons the iPhone and iPad are popular is because they take away a lot of decisions (aka options) which make computers intimidating.


Encryption means speedy deletion so there is still value encrypting even if the key isn't protected. But that's probably not the reason for Apple always encrypting things with the key of the Secure Enclave. I think the reason for this design is to make the full system easier to reason about, which seems like best practice.


Does the encryption on a Mac SSD work as powerfully as on iOS devices? My understanding is that even government agencies can't decrypt iOS devices without the user's pin and it can't be brute forced. Is that true of Macs too?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: