Yes you can do key escrow via PGP (so you could, in theory, have a sound encryption algorithm at work) but you have multiple sets of issues with this idea.
First the way this escrow works is you encrypt the file system with a randomly generated key. This key is then encrypted by using this escrow key the manufacturer keeps along with another copy of the key being encrypted by some random, initial password which is kept in plaintext or somehow already known to the user (gotta be able to decrypt the encrypted filesystem when the user first gets the phone). At that point the default password is used, the user re-encrypted the key for the data using their own passcode. Now you have two keys that can unlock the phone. This ignores the whole issue of being able to access that data's initial key the entire time during transport but how else are you going to give the user the ability to decrypt the data key so they can even access the device?
Then what do you do with the keys? Phones are made in China so there would be zero stopping China from forcing all companies to provide this escrow key. But let's say you got around that, how do you respond to lawful requests for these keys? You either need to move them all to the United States or keep them in China; either way they're sitting somewhere, at least, where attackers could attempt to gain access to.
Second, and honestly the biggest issue here, is the UX of this flat out sucks. So now if you forget your password you either have to format the phone (thusly destroying the original escrow key) or the phone is simply bricked and there is no way to recover.
There is simply not a mathamatically way to provide multiple parties access to an encrypted piece of data / volume without decreasing its security.
This simply isn't feasible.
Yes you can do key escrow via PGP (so you could, in theory, have a sound encryption algorithm at work) but you have multiple sets of issues with this idea.
First the way this escrow works is you encrypt the file system with a randomly generated key. This key is then encrypted by using this escrow key the manufacturer keeps along with another copy of the key being encrypted by some random, initial password which is kept in plaintext or somehow already known to the user (gotta be able to decrypt the encrypted filesystem when the user first gets the phone). At that point the default password is used, the user re-encrypted the key for the data using their own passcode. Now you have two keys that can unlock the phone. This ignores the whole issue of being able to access that data's initial key the entire time during transport but how else are you going to give the user the ability to decrypt the data key so they can even access the device?
Then what do you do with the keys? Phones are made in China so there would be zero stopping China from forcing all companies to provide this escrow key. But let's say you got around that, how do you respond to lawful requests for these keys? You either need to move them all to the United States or keep them in China; either way they're sitting somewhere, at least, where attackers could attempt to gain access to.
Second, and honestly the biggest issue here, is the UX of this flat out sucks. So now if you forget your password you either have to format the phone (thusly destroying the original escrow key) or the phone is simply bricked and there is no way to recover.
There is simply not a mathamatically way to provide multiple parties access to an encrypted piece of data / volume without decreasing its security.