If the data on a device (e.g. a phone) is encrypted, then the encryption key is needed to decrypt the data as you use the device. How is this key stored or what is the security policy so that it is safe from being stolen by malware?
-
That depends on the key management, and key management is usually described in books, rather than answers on stackoverflow. – Maarten Bodewes Feb 15 '17 at 00:44
-
I agree, but if you don't know where to start or the specific name for the topic StackOverflow can be a good way to get names of useful books on the matter. – diegomontoyas Feb 15 '17 at 01:04
1 Answers
Devices typically contain enough storage that needs protection to warrant the use of a symmetric key algorithm. Public key crypto is way too slow for large amounts of data. If it's e.g. a harddisk, even a block chaining of the encryption is quite counterproductive.
However, to protect that symmetric key a number of techniques can be used. But while the key is used it is going to be stored in memory on the device.
Most used are ways to store the symmetric key in a way that it is protected by a password, pin code or so.
In it simplest form, it's actually not that hard: let's say you have a 256bit symmetric key that needs protection all you need is a cryptographic hash of a password that generates the same 256bit result (or longer) and store XORed result. Without the password, you can't calculate the hash and can't access the symmetric encryption key.
Still, if you seek protection from malware that might be actively monitoring the device while the encryption key is used, you're essentially out of luck unless you have hardware doing the encryption as the software encryption will have to have the key in memory while it is encrypting or decrypting. And malware could access memory. Also note that wiping the symmetric key without accessing it (in it's protective storage) essentially will make the entire disk wiped unless there's a backup. So while Confidentiality and Integrity are threatened by malware, Availability is even more.
-
The "XORed" process is essentially encrypting the key with a password and could be more clearly stated as such. But the scheme is weak because it suffers the same vunerability as CTR mode when the same counter is reused. – zaph Feb 15 '17 at 12:57
-
I fully agree that the XOR essentially encrypts the key. But "encrypt" is a bit overly hyped.and makes people think this is some magical thing that builds a bulletproof solution. It's not. Also As I stated: "in it's simplest form", real world implementations are a bit more complex as this indeed can have major vulnerabilities - e.g. you really want a really slow hash or somebody with e.g. a GPU rig breaks any typically used passwords in mere seconds. – Feb 16 '17 at 01:39