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!