macOS 10.13 with APFS and FileVault2 encryption enabled deletes personal recovery keys in error
Originator: | frogor.fb.openradar | ||
Number: | rdar://34940017 | Date Originated: | 11-Oct-2017 01:16 PM |
Status: | Open | Resolved: | |
Product: | macOS + SDK | Product Version: | 10.13.0 17A365 |
Classification: | Serious Bug | Reproducible: | Always |
Summary: If you have multiple accounts enabled for FileVault2 on 10.13 using APFS, only the account credentials currently logged in as the console/active desktop user can safely change the personal recovery key. Any attempt to use an account other than the one visually logged into the Finder/desktop in an automated fashion will generate an error when attempting to change the recovery key and then - in a completely unexpected/erroneous move - immediately delete the current recovery key. Steps to Reproduce: - Install 10.12.6 - Create two administrative users (test1 and test2) - Enable FileVault encryption - Reboot twice - verifying that both users (test1 and test2) can unlock and log into the device - Upgrade to 10.13 and verify the filesystem was updated from HFS+ to APFS - Reboot twice - verifying that both users (test1 and test2) can unlock and log into the device - Log in with one account (test1) and use: sudo fdesetup changerecovery -personal - Verify that a new recovery key is generated and displayed - Open Terminal and type: login - then log in as the other account (test2) - As the non-console account, use: sudo fdesetup changerecovery -personal Expected Results: A new personal recovery key is generated Actual Results: sudo fdesetup changerecovery -personal Password: <enter second user password> Enter your password: <enter second user password> Error: Unable to change key. The above error message is displayed and no recovery key is generated. Running sudo fdesetup haspersonalrecoverykey now returns false where before it returned true, and the prior recovery key no longer works with fdesetup validaterecovery Version: 10.13.0 17A365 Notes: Number of devices affected: 37000+ This procedure is confirmed to work just fine with 10.12.6. Since 10.13 removed the ability to change the recovery key using the current recovery key (it appears to now require a user's password), if an organization attempted to perform automated recovery key rotation in the background using a FileVault2 enabled account, it will not only fail to do so under 10.13 with APFS, it will also erroneously delete the existing recovery key during the process.
Comments
Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!