In the absence of any other input, here's what I was able to deduce. Short story: this appears to work fine.
As far as I can see, enabling TDE for a database is a logged operation, but the actual data encryption is not logged (otherwise the transaction log would grow considerably, which it doesn't). I assume there's something like the differential change map, or a flag in the page headers to indicate if a page is encrypted or not, and the storage engine just chews through everything until it's fully encrypted.
When I enable TDE at the primary database, the secondary database ends up encrypted too (I have verified this with a hex editor). While encrypting is in progress, the view sys.dm_database_encryption_keys indicates percent_complete for all the secondary servers is 0, and this value never increases. The primary server updates this column normally. All the replicas tend to finish encrypting at their own pace, at which point encryption_state changes to 3. Seems like everything works normally once it's finished.
OK, In case anyone wants to know, I got to the bottom of this.
The chain is pretty easy to work out:
Create Service Master Key (automatically done upon install)
Create Database Master Key (user creates their own key)
SymetricEncrypt(Service Key,Database Master Key) -> Store Encrypted Master Key into Master DB
Create Certificate
SymetricEncrypt(Database Master Key, Certificate Private Key) -> Store Encrypted private key in Master DB
Create Database Encryption Key (system creates a random key, but must be manually added to database)
ASymetricEncrypt(Certificate, Database Encryption Key) -> Store Encrypted DEK into database.
So, to decrypt the database data, you'll need to:
Use the SMK to decrypt the DMK
Use the DMK to decrypt the cert private key
Use the certificate to decrypt the DEK
Use the DEK to decrypt the database
The starting point is the Service Master Key... how is this stored (if you encrypt it, you can't retrieve data, and if left in plaintext your system is exposed).
The answer is, the SMK is encrypted with Data Protection API, which is a service built into windows.
Basically, data is encrypted with "secrets" from your user profile. So the same user profile must be used to decrypt the SMK.
Now that I know this, I can use DPAPI in my applications to encrypt my encryption keys :)
Best Answer
As Brent points out: real data (if even the smallest part of it is at all sensitive) should not be on dev/test[1] systems at all, even temporarily.
If you do depersonalise real data for use in test environments there are some precautions that we take when we do that:
Again: real data should not be on dev/test systems at all, even temporarily. Restore the copy and depersonalise on signed-off production environments with the full security measures that implies, then move the munged data to your other environments. You may not want this extra load on your main production setup[2] in which case have a separate DB server in that environment just for this task[3].
Make sure that your process fails safe and fails hard, even if that means it fails often. Make it fall over if any new tables or columns are present, until you give it a new list of what to expect, to mitigate against the issue Brent discusses with temporary schema changes. Also make sure any failed step stops the whole process so that any error altering the data will block the move away from production.
Best practise[4] is to generate test data based on patterns seen in production rather than taking production and trying to make it unidentifiable without altering any patterns in the data. As well as removing the risk of accidentally using real data due to a process error, you can include in your test data edge cases that have not occurred in production (yet, that you know of).
Even if your depersonalisation works, you might find that anyone with a little determination can partially undo it if they know a bit about the organisation of your clients.
This is your red flag. Wave it at anyone above you who questions the extra expense and/or hassle of keeping the production data away from non-production environments. Unnecessary copies of keys can greatly enlarge your attack surface area.
[1] Some might suggest an exception with UAT services but I would consider that production anyway.
[2] Unless you serve a fairly specific set of timezones, for instance all your customers and the vast majority of their users are in the US, so have a large window in the night during which a performance hit won't matter
[3] It doesn't necessarily need to be expensive "production grade" kit (high performance drives, enterprise licensed SQL and OS, ...), just enough for this process to be fast enough as you won't be seeing concurrent end-user activity, but there will of course still be a cost involved
[4] Which we have moved to for all recent and future development - we only use the munging of production data like this on certain legacy services that are retiring soon enough that is isn't worth retooling before they are fully obsoleted.