So I only worked on the ext4 encryption feature in the Linux kernel which was used to implement Android FBE, and so I'm not an expert on vold, but there shouldn't be a reason why vold needs to hang on to the key. Vold is responsible for pushing the keys into the kernel, but what ext4 uses to do the per-file encryption is stored on a kernel keyring, not in userspace. So vold should be destroying the key after it loads it into memory --- it certainly can't use the key for anything useful.
As far as being able to remove the keys while the phone is locked --- I can't comment on future product directions, but it's fair to say that the people working on the upper layers of the Android security system aren't idiots, and the limitations of what was landed in the Android N release was known to them. It is no worse than what we had in older versions of Android (with FDE, we were using dm-crypt, and the keys were living in the kernel as well), and while it doesn't help improve security with respect to the "evil maid" attack, it does significantly improve the user experience.
I agree that there is certainly room to improve, and note that future changes will require applications to make changes in how they access files, which does make it a much trickier change to introduce into the ecosystem without breaking backwards compatibility with existing applications.
As far as why different keys are being used for different profiles --- this makes it much easier to securely remove a corporate, "work" profile from a phone without needing to do a secure erase on the entire flash device --- either because an employee is leaving their existing employer and there is corp data on a BYOD phone/tablet, or because the phone has been lost, and corporate security policy about how quickly corp data should be zapped from the phone might be different from what the user might want to exercise when they have temporarily misplaced the phone. (e.g., you might have a different tradeoff of losing unbacked-up data from your personal files versus their getting compromised while you hope that someone turns in your phone to lost+found than your company's security policies might require.)
Looking at the code, it seems to keep the keys in a map called s_ce_keys, though there is a comment referencing b/26948053 which presumably is a bug to stop it doing that.
As far as being able to remove the keys while the phone is locked --- I can't comment on future product directions, but it's fair to say that the people working on the upper layers of the Android security system aren't idiots, and the limitations of what was landed in the Android N release was known to them. It is no worse than what we had in older versions of Android (with FDE, we were using dm-crypt, and the keys were living in the kernel as well), and while it doesn't help improve security with respect to the "evil maid" attack, it does significantly improve the user experience.
I agree that there is certainly room to improve, and note that future changes will require applications to make changes in how they access files, which does make it a much trickier change to introduce into the ecosystem without breaking backwards compatibility with existing applications.
As far as why different keys are being used for different profiles --- this makes it much easier to securely remove a corporate, "work" profile from a phone without needing to do a secure erase on the entire flash device --- either because an employee is leaving their existing employer and there is corp data on a BYOD phone/tablet, or because the phone has been lost, and corporate security policy about how quickly corp data should be zapped from the phone might be different from what the user might want to exercise when they have temporarily misplaced the phone. (e.g., you might have a different tradeoff of losing unbacked-up data from your personal files versus their getting compromised while you hope that someone turns in your phone to lost+found than your company's security policies might require.)