1

We are focusing on mobile phone and hard drive encryptions. This idea can be extended to any data encryption also.

iPhone and recent Androids are all encrypted. We know that changing the password will not change the encrypted data. It only changes the Encrypted Masker Key. For instance:

  • Master Key is used to encrypt/decrypt the data. That is decrypt_01(Master_Key,Encrypted_Data) = Plain_Data.
  • Master Key is not permanently stored in the phone. Master Key is only available in RAM while the phone is working.
  • Encrypted Master Key is stored in the phone permanently.
  • User Password is used to decrypt the Encrypted Master Key to Master Key, which decrypt_02(User_Password,Encrypted_Master_Key) = Master_Key.

In case of security breach, the attacker recorded the Master Key. Even if we change the password, the attacker will always be able to decrypt the data (including old and even new data).

Similar case applies to encrypted storage hard drives (e.g. cold storage or NAS) and encrypted server hard drives (e.g. using LUKS). I have never heard of any encryption scheme that changing the password will lead to a re-encryption.

For mobile phone, we can perform re-encryption and generate a new Master Key by factory reset the phone.

For hard drives, we may move the data to another encrypted hard drive with a different master key.

I did some researches but could not find anyone suggesting re-encryption in every certain period to tighten security. However this logic makes sense. The longer time the same Master Key is using, the more the risk to have it compromised. Is it just too tedious that no one would bother it? For critical servers or confidential storages, I am sure the effort is worth. Automated scripts can help also.

Improve this question
5
  • Do you think that an online attacker will steal your Master_Key? Then why not the key of the second encryption?
    – kelalaka
    Dec 8, 2021 at 23:09
  • @kelalaka - Perhaps a security patch is applied and the attacker is no longer able to steal the second key.
    – midnite
    Dec 8, 2021 at 23:17
  • If the attacker can extract master key, it can start extracting data almost immediately. One can also silently disable data encryption with that level of security breach.
    – defalt
    Dec 14, 2021 at 19:16
  • @defalt - Very likely, but not exactly. In case of a detached header LUKS, the header USB key in addition to the user password could be compromised (but user does not know it yet), while the actual encrypted hard drives could be not found at the moment. And in some cases, attacker may not break the system immediately, but keep the key and aim to retrieve the future data.
    – midnite
    Dec 14, 2021 at 20:21
  • Archlinux wiki mentions about this concern, and explains the steps to do it. LUKS2 even ables to re-encrypt online. ArchWiki: One application of re-encryption may be to secure the data again after a passphrase or keyfile has been compromised and one cannot be certain that no copy of the LUKS header has been obtained. For example, if only a passphrase has been shoulder-surfed but no physical/logical access to the device happened, it would be enough to change the respective passphrase/key only (#Key management).
    – midnite
    Mar 18, 2022 at 6:10

1 Answer 1

Reset to default
1

IMHO for most purposes periodic reencryption is a pain for very little if any security gain. If a breach has already occurred you have already lost data and it is also very likely malware has been planted. Reencrypting in the hopes to stop future breaches after the breach has happened will likely be ineffective.

If you have reason to suspect a breach you may want to reencrypt but also along with other mothers, e.g Install a clean copy from a trusted source only to move needed data, avoid executables and scanning files that may have vulnerabilities placed in them, possibly doing format conversions in an isolated environment.

We should remember sometimes the efforts we do to protect ourselves are exactly what allows the attack, for instance, if we are trying to mount a supply chain attack on installing new software, reinstalling everything periodically makes the attack far easier, especially if we pull software from multiple sources.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .