-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update Firmware/Full Disk Encryption Sections #433
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Line 392
You should set firmware security settings to [Full Security]
this is the default state. Better text would be:
„You should check your firmware security settings“
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The clean-up is appreciated, but I think more details can be preserved or added to demonstrate Filevault capabilities.
README.md
Outdated
|
||
> For users who want no one but themselves to remove their Firmware Password by software means, the -disable-reset-capability option has been added to the firmwarepasswd command-line tool in macOS 10.15. Before setting this option, users must to acknowledge that if the password is forgotten and needs removal, the user must bear the cost of the motherboard replacement necessary to achieve this. | ||
All Mac models with Apple silicon are encrypted by default. Enabling [FileVault](https://support.apple.com/en-au/guide/mac-help/mh11785/mac) makes it so that you need to enter a password in order to access the data on your drive. Your FileVault password acts as a firmware password as well. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's make these instructions explicit on how to enable FileVault with a strong password.
Can the firmware password statement be cited or explained in more detail?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the feedback, I added a link to the official documentation where the firmware claim is stated and I linked to the EFF's article on strong Diceware passwords. I didn't want to add explicit step-by-step instructions in case it becomes outdated, I figured linking to Apple's instructions would be better since they'll be kept updated. But I can do that if you'd prefer.
README.md
Outdated
|
||
See [LongSoft/UEFITool](https://github.com/LongSoft/UEFITool), [chipsec/chipsec](https://github.com/chipsec/chipsec) and discussion in [issue #213](https://github.com/drduh/macOS-Security-and-Privacy-Guide/issues/213) for more information. | ||
You'll have the option use your iCloud account for recovery; this option is more convenient than keeping track of your own recovery key, but Apple and law enforcement could potentially be able to access your drive so consult your threat model to determine if this is acceptable. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feels vague and uncertain, let's instead clearly present the options and leave the decision to the reader.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tried to clarify it a bit. It's literally a binary choice between using your iCloud account as a recovery option or generating a recovery key that you have to keep track of.
README.md
Outdated
|
||
Newer Mac models (Mac Pro, iMac Pro, Macbook with TouchBar) with [Apple T2](https://en.wikipedia.org/wiki/Apple-designed_processors#Apple_T2) chips, which provide a secure enclave for encrypted keys, lessen the risk of EFI firmware attacks. See [this blog post](https://michaellynn.github.io/2018/07/27/booting-secure/) for more information. | ||
FileVault protects data at rest and hardens against someone with physical access stealing data or tampering with your Mac. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does it do this? There are some prior resources about the specific threats and mechanisms (cold boot attacks, filevault analysis paper, etc) which could help demonstrate the point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These details should also be checked if they’re still relevant to Apple Silicion chips as many attacks are outdated/ Intel related
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed it to describe exactly what it does. I looked back at the things that are linked currently and they're covered now mostly by new hardware features. This one uses DMA, but Apple silicon Macs protect memory with an IOMMU where every device is prevented from seeing memory for any other device.
The FileVault analysis paper is about 12 years out of date so I feel like it's not a great resource to link to. If there's a more recent one I'd be ok with linking that, otherwise I'd like to just stick with official documentation.
Evicting the hardware keys isn't relevant since the Secure Enclave has its own encrypted memory that it uses for sensitive things like FileVault keys, so the raw key itself never leaves the Secure Enclave. So anything about cold boot attacks is pretty much out the door.
I'd probably rather cover this stuff in a Hardware section, but lemme know your thoughts.
This looks great. Thanks again for working on this change. |
closes #411, closes #382