> The vulnerability is not in how many keys you need to open a lock, the vulnerability is in requiring the same keys to open all locks.
And why would you use the same keys to open all locks? Here's a quick off-the-top of my head solution:
The device manufacturer creates a public/private key pair - maybe they make a new one for each device, or maybe for efficiency they make a new pair for each batch or once a month or whatever they deem acceptable. The point is to change it regularly. The court system creates its own public/private keys, changed every two months or so. The FBI creates their own as well, let's say changed every three months.
When the device is manufactured, the current public keys for the manufacturer, court and FBI all go on the device. When the disk is first encrypted by the user, a key is generated, encrypted by the FBI, manufacturer and court in that order, then stored in a separate location on the disk. Later on when the FBI gets its hands on the phone and wants to decrypt it, they send the encrypted key to the court along with the warrant application; if the court approves, they decrypt it and it gets sent on to the device manufacturer. They look up the serial number of the device and decrypt with the appropriate key, then send it on to the FBI. The FBI finally decrypts using their private key and can subsequently get the initial key used to encrypt the hard drive.
In order to decrypt a device without going through this process, you would have to get physical access to phone and also compromise all three private keys. If you did somehow manage to get all three of the keys, you'd only be able to decrypt devices manufactured within at most a two-month time frame. If that's still not an acceptable level of risk, it can be further limited by increasing the frequency at which keys are replaced, creating multiple keys for each window, adding additional agencies with their own keys into the process, etc.
> An attacker who can copy the encrypted contents of your disk and later compromises your key then won't be able to decrypt the copied data with it
I'm trying to imagine a situation where this is actually an issue... the closest I can come up with is: a cop arrests me, fails to get a warrant, illegally copies the encrypted data off my cell phone and retains the encrypted data anyways. I'm let go and my phone is returned, and I subsequently delete all of the incriminating evidence from my phone (overlooking the fact that destroying evidence is a crime). The police later arrest me for something else, confiscate my phone and this time they do get a warrant to search it. Now they decrypt their old data and discover the files I deleted, none of which is admissible in court because it was illegally acquired.
I personally think it's a little far fetched for your average criminal suspect, but I'll play along and say that it's maybe within the realm of possibility for someone high-value enough. I suppose the simple solution would be to do something like use a file system that keeps some sort of hash of the file structure and last modification time, so that you could prove that the file in question didn't come from the data they were authorized to collect. I think that's probably going too deep into performance trade-offs for something that's unlikely to occur.
If you're that worried about incriminating evidence that was left undiscovered on your phone, the simpler solution is to just get a new phone. I wouldn't trust any device that an adversary had physical control over then handed back to me. In this case, why would someone risk eventual conviction to save $400 for a new phone?