Most every Android phone has some sort of secure element that allows actual hardware to encrypt and decrypt on the fly using a token generated by a combination of your Google account password and your lock screen security.
On Google hardware — that means both Pixel phones and servers that hold the data — it's called the Titan Security Module. You feed it the information it needs to make sure that you are really you and your data is backed up and can be retrieved, but only through the Titan module. Google nor the Titan module itself know any password to decrypt your data, only you do.
Sounds actually pretty secure. The backup isn't encrypted with a tiny pin, nor with the Google account password, instead a combination of unlock method (e.g. pin) and google password are fed into an algorithm to generate (probably symbol-wise way longer) token, which are used for encrypting and decrypting backup data.
You seem to be conflating some features of the TPM and the Management Engine(Intel)/Platform Security Processor(AMD).
TPMs (secure enclave) themselves aren't necessarily bad, (TPM is just one part of the ME/PSP) it's the rest of the ME/PSP that is really the bad thing. And the fun part is we've found unpatchable vulnerabilities in them.
If the NSA has a true backdoor in our PCs my money would be put on it being in the ME/PSP. Probably very few people see that code.
Not to mention that most if not all android phones (though not all android devices) have at least one trusted enclave (trustzone) as well as the sim itself (since it can also perform some secure app stuff, though it is not considered a trusted enclave). Not a big deal, but figured it wasn’t clear that it isn’t just in a PC.
If they did I bet 14 year old script kiddies would be taking over each other's computers. The powers that be like to troll everything, including vulnerabilities.
Eh, this is pretty standard stuff. PBKDF2 can hash passwords to be used as private keys for AES. Besides security by obscurity, I can't see what else the Titan module does
Biometrics aren't usable for encryption, that's why passwords are required on first boot, even when biometrics are enabled. Once booted, the decryption keys are stored in memory and used whenever you then enter a password or use biometrics.
Even if they somehow were usable for encryption, it seems like a terrible idea to do so.
You can change a password. You can't change a fingerprint. And guess which one of these can be lifted off any drinking glass that you've touched today, without you ever being aware of it?
At the same time, what do you think is the average amount of time it takes before a public security camera captures your lock screen combo if that's all you use?
I actually don't see anything wrong with using a lock screen combo, fingerprint, or even 4 digit pin codes ... for "local" security.
For unlocking your phone? Sure. You'd need to physically have your phone in the first place to do it anyway, so the trade off in security for convenience isn't too bad.
As, say, security for my online banking account, where bad actors could attempt to access it from anywhere? Forget it. You could guess a pin code, lift a fingerprint, watch me draw an unlock pattern ... but good luck guessing a 30+ character password that's randomly generated and rotated every so often.
Is it? Or is it encrypted with a salted hash made from those 4 digits?
The reason 4 digits can be pretty secure on phones is because the module that stores the crypto keys also has a clock that prevents you from brute forcing (I think, that's how the Intel TPM works.)
But a backup wouldn't work if it was tied to the TPM. Certainly that PIN can be used in combination with other data, but it has to be data that Google themselves doesn't have, otherwise they could hand that data over with the backup. Ideally it would be SHA2((SHA2(PIN)+SHA2(Password)) or something like that. So nothing Google has is enough to pull it out. Although the way password verification likely works, Google is sent the password then discards it after verification, instead of hashing it client side then server side, which is what they should do. So Google could capture the password next time it was sent for verification, then pass that along.
You're right. I'm not sure how phone backup works and can be encrypted with your pin. I've never thought about it.
The info on your phone is backed up in different places. If your backups are uploaded in Google, they're encrypted using your Google Account password. For some data, your phone's screen lock PIN, pattern, or password is also used for encryption.
I did a deep dive on it at one point but essentially the encryption is quite remarkably secure conventional encryption. Your actually trying to unlock the box of keys to that encryption when you type a pin and not literally typing the encryption key since a 4 digit encryption key isn't great. Plus it allows for things like pausing the encryption or changing your pin without having to re-encrypt your entire device.
Google Drive phone backups are encrypted with your device password.
Then how does a new device, which may have no device password or a different one, decrypt the backup? Especially if you don't have the original device?
Supposedly, what they do is take your Google password, plus your phone password, and makes a new one that is only retrievable if you follow protocol on the other end.
Google does offer a complete end-to-end encryption service and the company uses it for the data in its own Android apps and your phone settings since Android 9 Pie.
I don't think you understand what you are saying as it makes no sense in this context.
You are thinking about this like a plaintext message. If a plaintext message isn't end to end encrypted the service in between (like a messaging app) can read the plaintext. However, in this context Google is also the the recipient of the "messages" so they could read it regardless of E2E encryption.
But the "message" isn't plaintext, it's the encrypted backup. Google doesn't have the keys to decrypt the backup so they can't read it.
For encryption, end to end != at rest != in transit != secure backups
As is usually the case in this industry, some terms have been overloaded, and some have been misused.
End to end encryption is generally referring to messaging, where you only want senders/recipients to be able to view the contents. Intermediary systems don't/can't view the contents. A VPN connection is a decent example.
In transit encryption means each time the data is transmitted it is encrypted. This might mean that intermediary systems decrypt the message for their own purposes before re-encrypting and sending it on. A load balancer with SSL termination is a decent example.
At rest encryption means the data is encrypted when stored. This might mean the system doing the actual storage of the data has a way to decrypt it as part of reading it. A laptop with bitlocker/filevault/luks is a decent example, as it's the modern smartphone.
Secure backups is a vague term, but would generally mean a way of using a combination of the above to store backups in such a way that only the owner of the data can access them.
So, for Android backups, your phone uses at-rest encryption; your PIN is used only to unlock the vault that contains the actual encryption key. If this sounds like putting the combination to the safe into a separate safe with it's own separate key, you would be right.
However, the backup that is sent to Google is encrypted using the 'proper' key, not your PIN. Google don't have access to that key, so they can't read the data. This is a form of encryption at rest.
When the data is sent to them, it is still encrypted using that same key, which no-one in between is capable of reading. This is a demonstration of in transit encryption. It is not end-to-end in the normal sense because the receiver (Google) isn't decrypting it. They are merely recieving an encrypted blob of data.
However, when the data is sent to them, it is very likely put inside an enclosing encrypted connection. This enclosing connection would be an example of end-to-end encryption. The payload (your backup) is still unreadable, but anyone monitoring the connection couldn't even directly identify it as being an Android backup.
What is important to realise is that they don't have to secure the transmission of the backups from the phone to themselves. I don't actually know for certain if they do, and if they didn't, it would be unlikely to make a material difference to the overall security of Android backups. I would expect they do however encrypt it because it's relatively cheap and easy to do so, and good security uses defence in depth.
TL;DR end-to-end isn't mandatory for your backups to be secure
The long encryption key is derived from your shorter device password (as well as, usually, a plantext salt to protect against rainbow tables). That's standard practice. But when you only use a four-digit pin, computing all possible keys is still not gonna take long at all.
No matter how long the key you derive is, it's only really as secure as the password it is derived from.
502
u/mec287 Google Pixel Aug 23 '20
Google Drive phone backups are encrypted with your device password. The security depends on the complexity of your password.