How is it possible for user's password to be changed after storage was encrypted? (on OS X, Android) The 2019 Stack Overflow Developer Survey Results Are In Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern)DEK, KEK and Master key - simple explanationAre there actually any advantages to Android full-disk encryption?Android / CyanogenMod encryption vs GNU/LinuxEncrypted files storage. How to simplify the password management scheme?How is the FileVault master key protected?Is it possible to retrieve flash-based encrypted disks content (SSD, cellphones, USB sticks, …) after password wipe/replacement?How to correctly handle passwords for an Android appBest practice for securing encrypted content on Android appHow does Android 6 full encryption work … when it doesn't ask for the password at start time?How can Android encryption be so fast?Connection between PIN/password and encryption keys in Android

Is there a writing software that you can sort scenes like slides in PowerPoint?

"... to apply for a visa" or "... and applied for a visa"?

Wall plug outlet change

What aspect of planet Earth must be changed to prevent the industrial revolution?

Can smartphones with the same camera sensor have different image quality?

Road tyres vs "Street" tyres for charity ride on MTB Tandem

Who or what is the being for whom Being is a question for Heidegger?

I could not break this equation. Please help me

In horse breeding, what is the female equivalent of putting a horse out "to stud"?

Make it rain characters

ELI5: Why do they say that Israel would have been the fourth country to land a spacecraft on the Moon and why do they call it low cost?

Why does the Event Horizon Telescope (EHT) not include telescopes from Africa, Asia or Australia?

Arduino Pro Micro - switch off LEDs

Did the UK government pay "millions and millions of dollars" to try to snag Julian Assange?

How is simplicity better than precision and clarity in prose?

Match Roman Numerals

Typeface like Times New Roman but with "tied" percent sign

What are these Gizmos at Izaña Atmospheric Research Center in Spain?

What's the point in a preamp?

Simulation of a banking system with an Account class in C++

Why can't wing-mounted spoilers be used to steepen approaches?

How can I define good in a religion that claims no moral authority?

system() function string length limit

How should I replace vector<uint8_t>::const_iterator in an API?



How is it possible for user's password to be changed after storage was encrypted? (on OS X, Android)



The 2019 Stack Overflow Developer Survey Results Are In
Announcing the arrival of Valued Associate #679: Cesar Manara
Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern)DEK, KEK and Master key - simple explanationAre there actually any advantages to Android full-disk encryption?Android / CyanogenMod encryption vs GNU/LinuxEncrypted files storage. How to simplify the password management scheme?How is the FileVault master key protected?Is it possible to retrieve flash-based encrypted disks content (SSD, cellphones, USB sticks, …) after password wipe/replacement?How to correctly handle passwords for an Android appBest practice for securing encrypted content on Android appHow does Android 6 full encryption work … when it doesn't ask for the password at start time?How can Android encryption be so fast?Connection between PIN/password and encryption keys in Android



.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;








28















There are built-in functionalities to encrypt a storage on OS X (FileVault) and Android.



On OS X: to enable encryption current user must have a password protected account. After enabling the encryption, recovery key is generated (something like HHWj-Y8DK-ODO4-BQEN-FQ4V-M4O8). After the encryption is finished (and in all probability before that as well) user is able to change his password, without the need to re-encrypt the storage.



On Android: user is required to set lockscreen protection to either pin or password. After storage encryption is done (again, probably before that as well), user is able to change password, and even switch from password to pin and vice versa.



Now here is what puzzles me: my understanding is that when storage is encrypted, it is done with current user password (sort of like encrypting an archive) and if password is changed — the whole storage must be re-encrypted. This (apparently incorrect) understanding brings me to following questions:



  1. Based on what "key" (since it is not the password itself) encryption is done then?

    • For OS X, I am guessing, it's the recovery key, but how is it connected to the user's password then?


  2. If password is not the basis for encryption, why is it required to set one before encrypting your storage?

  3. How is ability to decrypt storage is maintained (without re-encrypting) after password is changed?









share|improve this question









New contributor




Filipp W. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.















  • 2





    I'm pretty sure this is a duplicate, but I can't find the question I'm thinking of...

    – forest
    Apr 8 at 2:46











  • @forest It could be a duplicate of this, but honestly I think that this question is better than that one. I also think I remember a question about why a user's encrypted drive was "deleted" so quickly, and it's because just the key was deleted, but I can't find it.

    – mbomb007
    Apr 8 at 14:40












  • Related (Superuser): Does changing the encryption password imply rewriting all the data?

    – Marc.2377
    Apr 8 at 23:41











  • @forest, (before I posted this question) I was pretty sure as well, that such question already have been asked. Though — I was not able to find it :-)

    – Filipp W.
    Apr 9 at 6:37

















28















There are built-in functionalities to encrypt a storage on OS X (FileVault) and Android.



On OS X: to enable encryption current user must have a password protected account. After enabling the encryption, recovery key is generated (something like HHWj-Y8DK-ODO4-BQEN-FQ4V-M4O8). After the encryption is finished (and in all probability before that as well) user is able to change his password, without the need to re-encrypt the storage.



On Android: user is required to set lockscreen protection to either pin or password. After storage encryption is done (again, probably before that as well), user is able to change password, and even switch from password to pin and vice versa.



Now here is what puzzles me: my understanding is that when storage is encrypted, it is done with current user password (sort of like encrypting an archive) and if password is changed — the whole storage must be re-encrypted. This (apparently incorrect) understanding brings me to following questions:



  1. Based on what "key" (since it is not the password itself) encryption is done then?

    • For OS X, I am guessing, it's the recovery key, but how is it connected to the user's password then?


  2. If password is not the basis for encryption, why is it required to set one before encrypting your storage?

  3. How is ability to decrypt storage is maintained (without re-encrypting) after password is changed?









share|improve this question









New contributor




Filipp W. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.















  • 2





    I'm pretty sure this is a duplicate, but I can't find the question I'm thinking of...

    – forest
    Apr 8 at 2:46











  • @forest It could be a duplicate of this, but honestly I think that this question is better than that one. I also think I remember a question about why a user's encrypted drive was "deleted" so quickly, and it's because just the key was deleted, but I can't find it.

    – mbomb007
    Apr 8 at 14:40












  • Related (Superuser): Does changing the encryption password imply rewriting all the data?

    – Marc.2377
    Apr 8 at 23:41











  • @forest, (before I posted this question) I was pretty sure as well, that such question already have been asked. Though — I was not able to find it :-)

    – Filipp W.
    Apr 9 at 6:37













28












28








28


2






There are built-in functionalities to encrypt a storage on OS X (FileVault) and Android.



On OS X: to enable encryption current user must have a password protected account. After enabling the encryption, recovery key is generated (something like HHWj-Y8DK-ODO4-BQEN-FQ4V-M4O8). After the encryption is finished (and in all probability before that as well) user is able to change his password, without the need to re-encrypt the storage.



On Android: user is required to set lockscreen protection to either pin or password. After storage encryption is done (again, probably before that as well), user is able to change password, and even switch from password to pin and vice versa.



Now here is what puzzles me: my understanding is that when storage is encrypted, it is done with current user password (sort of like encrypting an archive) and if password is changed — the whole storage must be re-encrypted. This (apparently incorrect) understanding brings me to following questions:



  1. Based on what "key" (since it is not the password itself) encryption is done then?

    • For OS X, I am guessing, it's the recovery key, but how is it connected to the user's password then?


  2. If password is not the basis for encryption, why is it required to set one before encrypting your storage?

  3. How is ability to decrypt storage is maintained (without re-encrypting) after password is changed?









share|improve this question









New contributor




Filipp W. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.












There are built-in functionalities to encrypt a storage on OS X (FileVault) and Android.



On OS X: to enable encryption current user must have a password protected account. After enabling the encryption, recovery key is generated (something like HHWj-Y8DK-ODO4-BQEN-FQ4V-M4O8). After the encryption is finished (and in all probability before that as well) user is able to change his password, without the need to re-encrypt the storage.



On Android: user is required to set lockscreen protection to either pin or password. After storage encryption is done (again, probably before that as well), user is able to change password, and even switch from password to pin and vice versa.



Now here is what puzzles me: my understanding is that when storage is encrypted, it is done with current user password (sort of like encrypting an archive) and if password is changed — the whole storage must be re-encrypted. This (apparently incorrect) understanding brings me to following questions:



  1. Based on what "key" (since it is not the password itself) encryption is done then?

    • For OS X, I am guessing, it's the recovery key, but how is it connected to the user's password then?


  2. If password is not the basis for encryption, why is it required to set one before encrypting your storage?

  3. How is ability to decrypt storage is maintained (without re-encrypting) after password is changed?






encryption passwords android disk-encryption macosx






share|improve this question









New contributor




Filipp W. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question









New contributor




Filipp W. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question








edited Apr 8 at 7:08







Filipp W.













New contributor




Filipp W. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked Apr 7 at 15:15









Filipp W.Filipp W.

24838




24838




New contributor




Filipp W. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





Filipp W. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






Filipp W. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.







  • 2





    I'm pretty sure this is a duplicate, but I can't find the question I'm thinking of...

    – forest
    Apr 8 at 2:46











  • @forest It could be a duplicate of this, but honestly I think that this question is better than that one. I also think I remember a question about why a user's encrypted drive was "deleted" so quickly, and it's because just the key was deleted, but I can't find it.

    – mbomb007
    Apr 8 at 14:40












  • Related (Superuser): Does changing the encryption password imply rewriting all the data?

    – Marc.2377
    Apr 8 at 23:41











  • @forest, (before I posted this question) I was pretty sure as well, that such question already have been asked. Though — I was not able to find it :-)

    – Filipp W.
    Apr 9 at 6:37












  • 2





    I'm pretty sure this is a duplicate, but I can't find the question I'm thinking of...

    – forest
    Apr 8 at 2:46











  • @forest It could be a duplicate of this, but honestly I think that this question is better than that one. I also think I remember a question about why a user's encrypted drive was "deleted" so quickly, and it's because just the key was deleted, but I can't find it.

    – mbomb007
    Apr 8 at 14:40












  • Related (Superuser): Does changing the encryption password imply rewriting all the data?

    – Marc.2377
    Apr 8 at 23:41











  • @forest, (before I posted this question) I was pretty sure as well, that such question already have been asked. Though — I was not able to find it :-)

    – Filipp W.
    Apr 9 at 6:37







2




2





I'm pretty sure this is a duplicate, but I can't find the question I'm thinking of...

– forest
Apr 8 at 2:46





I'm pretty sure this is a duplicate, but I can't find the question I'm thinking of...

– forest
Apr 8 at 2:46













@forest It could be a duplicate of this, but honestly I think that this question is better than that one. I also think I remember a question about why a user's encrypted drive was "deleted" so quickly, and it's because just the key was deleted, but I can't find it.

– mbomb007
Apr 8 at 14:40






@forest It could be a duplicate of this, but honestly I think that this question is better than that one. I also think I remember a question about why a user's encrypted drive was "deleted" so quickly, and it's because just the key was deleted, but I can't find it.

– mbomb007
Apr 8 at 14:40














Related (Superuser): Does changing the encryption password imply rewriting all the data?

– Marc.2377
Apr 8 at 23:41





Related (Superuser): Does changing the encryption password imply rewriting all the data?

– Marc.2377
Apr 8 at 23:41













@forest, (before I posted this question) I was pretty sure as well, that such question already have been asked. Though — I was not able to find it :-)

– Filipp W.
Apr 9 at 6:37





@forest, (before I posted this question) I was pretty sure as well, that such question already have been asked. Though — I was not able to find it :-)

– Filipp W.
Apr 9 at 6:37










2 Answers
2






active

oldest

votes


















47














At a high level, disk encryption is implemented using a data encryption key (DEK) and a key encryption key (KEK). The DEK is generated randomly and used to encrypt the drive, the KEK is derived from the user's password using a KDF like PBKDF2 or Argon2 and then used to encrypt the DEK.



When changing the password, the DEK is simply encrypted with a new KEK derived from the new password.



Encrypting without a password is likely prohibited to avoid a false sense of security. It'd be a bit like locking your door but leaving the key in the lock.



Of course, if you're changing your password because you believe someone figured it out, and that person also had access to the encrypted device, it's possible they stored a copy of the DEK. In this case it may be necessary to re-encrypt the entire drive, though doing so will likely take some time.






share|improve this answer


















  • 24





    It should be noted that encryption without encrypting the DEK may be useful. It allows for extremely quick secure deletion of content of the drive. Wipe they DEK, and the information stored is effectively wiped as well.

    – vidarlo
    Apr 7 at 16:25






  • 4





    @vidarlo True, but I wouldn't expect the average user to understand this, or to need it.

    – AndrolGenhald
    Apr 7 at 16:32











  • That, I do not disagree with :)

    – vidarlo
    Apr 7 at 16:33






  • 1





    They don't need to understand it, but they experience crypto data wipe when they reset their iOS device, even if they don't have a passcode set. It is also useful to encrypt before a password is set to ensure that when the user enables encryption, there isn't any residual unencrypted data on disk, and the enablement is much faster. This is what Windows Bitlocker does when compatible hardware encryption is available.

    – user71659
    Apr 8 at 16:29


















15














I completely agree with AndrolGenhald's high-level answer. In case you are interested in a complementary low-level walk-through of Android's storage encryption implementation:



Android can do File-Based Encryption (FBE) and Full-Disc Encryption (FDE), with "disc" referring to the /data partition. I will focus on FDE to illustrate the principle. The set-up is done by the Volume Daemon (Vold), specifically in system/vold/cryptfs.cpp.




  • cryptfs_enable_internal(int crypt_type, const char* passwd, ...) starts the storage encryption, with crypt_type specifying if a pin or password is used (to determine which keyboard to show on the unlock screen) and passwd giving the actual user pin/password. It will set up a footer crypt_ftr to be stored along the encrypted partition, then it calls create_encrypted_random_key to populate the crypt_ftr.




    • create_encrypted_random_key generates a random master key and a random salt and passes them on to encrypt_master_key.


    • encrypt_master_key uses a key-derivation function (e.g. scrypt), that takes the salt and the user pin/password as an input and deterministically derives an intermediate key. The master key is then encrypted with the intermediate key using AES-128-CBC. The encrypted master key and the salt are stored in crypt_ftr, but not the user pin/password.

    • Back in cryptfs_enable_internal, the crypt_ftr is written to the disc. Then the actual storage encryption via Linux' dm-crypt is triggered using the decrypted master key.


  • cryptfs_check_passwd(const char* passwd) starts storage decryption by backtracking the above steps to obtain the decrypted master key. The crypt_ftr has to be read from the disc, containing the encrypted master key and the salt. The user-supplied pin/password plus salt are fed into the key derivation function. This results in an intermediate key that can decrypt the master key (most of this happens in decrypt_master_key_aux).



  • cryptfs_changepw(int crypt_type, const char* newpw) handles changing the user pin/password. It will not generate a new master key, it just encrypts the existing master key via encrypt_master_key using the new user pin/password.

Based on this information, the answers to your questions would be:



  1. The randomly generated master key is used for the actual storage encryption.


  2. We need a user pin/password to encrypt the master key. Thus the user pin/password is needed to later retrieve the master key for decrypting the storage.


  3. Changing the user pin/password will not change the master key, only the encryption of the master key.






share|improve this answer










New contributor




f9c69e9781fa194211448473495534 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




















  • Thanks for elaborate 'under the hood' explanation for Android!

    – Filipp W.
    Apr 9 at 6:32












Your Answer








StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "162"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);






Filipp W. is a new contributor. Be nice, and check out our Code of Conduct.









draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f206979%2fhow-is-it-possible-for-users-password-to-be-changed-after-storage-was-encrypted%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes









47














At a high level, disk encryption is implemented using a data encryption key (DEK) and a key encryption key (KEK). The DEK is generated randomly and used to encrypt the drive, the KEK is derived from the user's password using a KDF like PBKDF2 or Argon2 and then used to encrypt the DEK.



When changing the password, the DEK is simply encrypted with a new KEK derived from the new password.



Encrypting without a password is likely prohibited to avoid a false sense of security. It'd be a bit like locking your door but leaving the key in the lock.



Of course, if you're changing your password because you believe someone figured it out, and that person also had access to the encrypted device, it's possible they stored a copy of the DEK. In this case it may be necessary to re-encrypt the entire drive, though doing so will likely take some time.






share|improve this answer


















  • 24





    It should be noted that encryption without encrypting the DEK may be useful. It allows for extremely quick secure deletion of content of the drive. Wipe they DEK, and the information stored is effectively wiped as well.

    – vidarlo
    Apr 7 at 16:25






  • 4





    @vidarlo True, but I wouldn't expect the average user to understand this, or to need it.

    – AndrolGenhald
    Apr 7 at 16:32











  • That, I do not disagree with :)

    – vidarlo
    Apr 7 at 16:33






  • 1





    They don't need to understand it, but they experience crypto data wipe when they reset their iOS device, even if they don't have a passcode set. It is also useful to encrypt before a password is set to ensure that when the user enables encryption, there isn't any residual unencrypted data on disk, and the enablement is much faster. This is what Windows Bitlocker does when compatible hardware encryption is available.

    – user71659
    Apr 8 at 16:29















47














At a high level, disk encryption is implemented using a data encryption key (DEK) and a key encryption key (KEK). The DEK is generated randomly and used to encrypt the drive, the KEK is derived from the user's password using a KDF like PBKDF2 or Argon2 and then used to encrypt the DEK.



When changing the password, the DEK is simply encrypted with a new KEK derived from the new password.



Encrypting without a password is likely prohibited to avoid a false sense of security. It'd be a bit like locking your door but leaving the key in the lock.



Of course, if you're changing your password because you believe someone figured it out, and that person also had access to the encrypted device, it's possible they stored a copy of the DEK. In this case it may be necessary to re-encrypt the entire drive, though doing so will likely take some time.






share|improve this answer


















  • 24





    It should be noted that encryption without encrypting the DEK may be useful. It allows for extremely quick secure deletion of content of the drive. Wipe they DEK, and the information stored is effectively wiped as well.

    – vidarlo
    Apr 7 at 16:25






  • 4





    @vidarlo True, but I wouldn't expect the average user to understand this, or to need it.

    – AndrolGenhald
    Apr 7 at 16:32











  • That, I do not disagree with :)

    – vidarlo
    Apr 7 at 16:33






  • 1





    They don't need to understand it, but they experience crypto data wipe when they reset their iOS device, even if they don't have a passcode set. It is also useful to encrypt before a password is set to ensure that when the user enables encryption, there isn't any residual unencrypted data on disk, and the enablement is much faster. This is what Windows Bitlocker does when compatible hardware encryption is available.

    – user71659
    Apr 8 at 16:29













47












47








47







At a high level, disk encryption is implemented using a data encryption key (DEK) and a key encryption key (KEK). The DEK is generated randomly and used to encrypt the drive, the KEK is derived from the user's password using a KDF like PBKDF2 or Argon2 and then used to encrypt the DEK.



When changing the password, the DEK is simply encrypted with a new KEK derived from the new password.



Encrypting without a password is likely prohibited to avoid a false sense of security. It'd be a bit like locking your door but leaving the key in the lock.



Of course, if you're changing your password because you believe someone figured it out, and that person also had access to the encrypted device, it's possible they stored a copy of the DEK. In this case it may be necessary to re-encrypt the entire drive, though doing so will likely take some time.






share|improve this answer













At a high level, disk encryption is implemented using a data encryption key (DEK) and a key encryption key (KEK). The DEK is generated randomly and used to encrypt the drive, the KEK is derived from the user's password using a KDF like PBKDF2 or Argon2 and then used to encrypt the DEK.



When changing the password, the DEK is simply encrypted with a new KEK derived from the new password.



Encrypting without a password is likely prohibited to avoid a false sense of security. It'd be a bit like locking your door but leaving the key in the lock.



Of course, if you're changing your password because you believe someone figured it out, and that person also had access to the encrypted device, it's possible they stored a copy of the DEK. In this case it may be necessary to re-encrypt the entire drive, though doing so will likely take some time.







share|improve this answer












share|improve this answer



share|improve this answer










answered Apr 7 at 16:23









AndrolGenhaldAndrolGenhald

12.3k53138




12.3k53138







  • 24





    It should be noted that encryption without encrypting the DEK may be useful. It allows for extremely quick secure deletion of content of the drive. Wipe they DEK, and the information stored is effectively wiped as well.

    – vidarlo
    Apr 7 at 16:25






  • 4





    @vidarlo True, but I wouldn't expect the average user to understand this, or to need it.

    – AndrolGenhald
    Apr 7 at 16:32











  • That, I do not disagree with :)

    – vidarlo
    Apr 7 at 16:33






  • 1





    They don't need to understand it, but they experience crypto data wipe when they reset their iOS device, even if they don't have a passcode set. It is also useful to encrypt before a password is set to ensure that when the user enables encryption, there isn't any residual unencrypted data on disk, and the enablement is much faster. This is what Windows Bitlocker does when compatible hardware encryption is available.

    – user71659
    Apr 8 at 16:29












  • 24





    It should be noted that encryption without encrypting the DEK may be useful. It allows for extremely quick secure deletion of content of the drive. Wipe they DEK, and the information stored is effectively wiped as well.

    – vidarlo
    Apr 7 at 16:25






  • 4





    @vidarlo True, but I wouldn't expect the average user to understand this, or to need it.

    – AndrolGenhald
    Apr 7 at 16:32











  • That, I do not disagree with :)

    – vidarlo
    Apr 7 at 16:33






  • 1





    They don't need to understand it, but they experience crypto data wipe when they reset their iOS device, even if they don't have a passcode set. It is also useful to encrypt before a password is set to ensure that when the user enables encryption, there isn't any residual unencrypted data on disk, and the enablement is much faster. This is what Windows Bitlocker does when compatible hardware encryption is available.

    – user71659
    Apr 8 at 16:29







24




24





It should be noted that encryption without encrypting the DEK may be useful. It allows for extremely quick secure deletion of content of the drive. Wipe they DEK, and the information stored is effectively wiped as well.

– vidarlo
Apr 7 at 16:25





It should be noted that encryption without encrypting the DEK may be useful. It allows for extremely quick secure deletion of content of the drive. Wipe they DEK, and the information stored is effectively wiped as well.

– vidarlo
Apr 7 at 16:25




4




4





@vidarlo True, but I wouldn't expect the average user to understand this, or to need it.

– AndrolGenhald
Apr 7 at 16:32





@vidarlo True, but I wouldn't expect the average user to understand this, or to need it.

– AndrolGenhald
Apr 7 at 16:32













That, I do not disagree with :)

– vidarlo
Apr 7 at 16:33





That, I do not disagree with :)

– vidarlo
Apr 7 at 16:33




1




1





They don't need to understand it, but they experience crypto data wipe when they reset their iOS device, even if they don't have a passcode set. It is also useful to encrypt before a password is set to ensure that when the user enables encryption, there isn't any residual unencrypted data on disk, and the enablement is much faster. This is what Windows Bitlocker does when compatible hardware encryption is available.

– user71659
Apr 8 at 16:29





They don't need to understand it, but they experience crypto data wipe when they reset their iOS device, even if they don't have a passcode set. It is also useful to encrypt before a password is set to ensure that when the user enables encryption, there isn't any residual unencrypted data on disk, and the enablement is much faster. This is what Windows Bitlocker does when compatible hardware encryption is available.

– user71659
Apr 8 at 16:29













15














I completely agree with AndrolGenhald's high-level answer. In case you are interested in a complementary low-level walk-through of Android's storage encryption implementation:



Android can do File-Based Encryption (FBE) and Full-Disc Encryption (FDE), with "disc" referring to the /data partition. I will focus on FDE to illustrate the principle. The set-up is done by the Volume Daemon (Vold), specifically in system/vold/cryptfs.cpp.




  • cryptfs_enable_internal(int crypt_type, const char* passwd, ...) starts the storage encryption, with crypt_type specifying if a pin or password is used (to determine which keyboard to show on the unlock screen) and passwd giving the actual user pin/password. It will set up a footer crypt_ftr to be stored along the encrypted partition, then it calls create_encrypted_random_key to populate the crypt_ftr.




    • create_encrypted_random_key generates a random master key and a random salt and passes them on to encrypt_master_key.


    • encrypt_master_key uses a key-derivation function (e.g. scrypt), that takes the salt and the user pin/password as an input and deterministically derives an intermediate key. The master key is then encrypted with the intermediate key using AES-128-CBC. The encrypted master key and the salt are stored in crypt_ftr, but not the user pin/password.

    • Back in cryptfs_enable_internal, the crypt_ftr is written to the disc. Then the actual storage encryption via Linux' dm-crypt is triggered using the decrypted master key.


  • cryptfs_check_passwd(const char* passwd) starts storage decryption by backtracking the above steps to obtain the decrypted master key. The crypt_ftr has to be read from the disc, containing the encrypted master key and the salt. The user-supplied pin/password plus salt are fed into the key derivation function. This results in an intermediate key that can decrypt the master key (most of this happens in decrypt_master_key_aux).



  • cryptfs_changepw(int crypt_type, const char* newpw) handles changing the user pin/password. It will not generate a new master key, it just encrypts the existing master key via encrypt_master_key using the new user pin/password.

Based on this information, the answers to your questions would be:



  1. The randomly generated master key is used for the actual storage encryption.


  2. We need a user pin/password to encrypt the master key. Thus the user pin/password is needed to later retrieve the master key for decrypting the storage.


  3. Changing the user pin/password will not change the master key, only the encryption of the master key.






share|improve this answer










New contributor




f9c69e9781fa194211448473495534 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




















  • Thanks for elaborate 'under the hood' explanation for Android!

    – Filipp W.
    Apr 9 at 6:32
















15














I completely agree with AndrolGenhald's high-level answer. In case you are interested in a complementary low-level walk-through of Android's storage encryption implementation:



Android can do File-Based Encryption (FBE) and Full-Disc Encryption (FDE), with "disc" referring to the /data partition. I will focus on FDE to illustrate the principle. The set-up is done by the Volume Daemon (Vold), specifically in system/vold/cryptfs.cpp.




  • cryptfs_enable_internal(int crypt_type, const char* passwd, ...) starts the storage encryption, with crypt_type specifying if a pin or password is used (to determine which keyboard to show on the unlock screen) and passwd giving the actual user pin/password. It will set up a footer crypt_ftr to be stored along the encrypted partition, then it calls create_encrypted_random_key to populate the crypt_ftr.




    • create_encrypted_random_key generates a random master key and a random salt and passes them on to encrypt_master_key.


    • encrypt_master_key uses a key-derivation function (e.g. scrypt), that takes the salt and the user pin/password as an input and deterministically derives an intermediate key. The master key is then encrypted with the intermediate key using AES-128-CBC. The encrypted master key and the salt are stored in crypt_ftr, but not the user pin/password.

    • Back in cryptfs_enable_internal, the crypt_ftr is written to the disc. Then the actual storage encryption via Linux' dm-crypt is triggered using the decrypted master key.


  • cryptfs_check_passwd(const char* passwd) starts storage decryption by backtracking the above steps to obtain the decrypted master key. The crypt_ftr has to be read from the disc, containing the encrypted master key and the salt. The user-supplied pin/password plus salt are fed into the key derivation function. This results in an intermediate key that can decrypt the master key (most of this happens in decrypt_master_key_aux).



  • cryptfs_changepw(int crypt_type, const char* newpw) handles changing the user pin/password. It will not generate a new master key, it just encrypts the existing master key via encrypt_master_key using the new user pin/password.

Based on this information, the answers to your questions would be:



  1. The randomly generated master key is used for the actual storage encryption.


  2. We need a user pin/password to encrypt the master key. Thus the user pin/password is needed to later retrieve the master key for decrypting the storage.


  3. Changing the user pin/password will not change the master key, only the encryption of the master key.






share|improve this answer










New contributor




f9c69e9781fa194211448473495534 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




















  • Thanks for elaborate 'under the hood' explanation for Android!

    – Filipp W.
    Apr 9 at 6:32














15












15








15







I completely agree with AndrolGenhald's high-level answer. In case you are interested in a complementary low-level walk-through of Android's storage encryption implementation:



Android can do File-Based Encryption (FBE) and Full-Disc Encryption (FDE), with "disc" referring to the /data partition. I will focus on FDE to illustrate the principle. The set-up is done by the Volume Daemon (Vold), specifically in system/vold/cryptfs.cpp.




  • cryptfs_enable_internal(int crypt_type, const char* passwd, ...) starts the storage encryption, with crypt_type specifying if a pin or password is used (to determine which keyboard to show on the unlock screen) and passwd giving the actual user pin/password. It will set up a footer crypt_ftr to be stored along the encrypted partition, then it calls create_encrypted_random_key to populate the crypt_ftr.




    • create_encrypted_random_key generates a random master key and a random salt and passes them on to encrypt_master_key.


    • encrypt_master_key uses a key-derivation function (e.g. scrypt), that takes the salt and the user pin/password as an input and deterministically derives an intermediate key. The master key is then encrypted with the intermediate key using AES-128-CBC. The encrypted master key and the salt are stored in crypt_ftr, but not the user pin/password.

    • Back in cryptfs_enable_internal, the crypt_ftr is written to the disc. Then the actual storage encryption via Linux' dm-crypt is triggered using the decrypted master key.


  • cryptfs_check_passwd(const char* passwd) starts storage decryption by backtracking the above steps to obtain the decrypted master key. The crypt_ftr has to be read from the disc, containing the encrypted master key and the salt. The user-supplied pin/password plus salt are fed into the key derivation function. This results in an intermediate key that can decrypt the master key (most of this happens in decrypt_master_key_aux).



  • cryptfs_changepw(int crypt_type, const char* newpw) handles changing the user pin/password. It will not generate a new master key, it just encrypts the existing master key via encrypt_master_key using the new user pin/password.

Based on this information, the answers to your questions would be:



  1. The randomly generated master key is used for the actual storage encryption.


  2. We need a user pin/password to encrypt the master key. Thus the user pin/password is needed to later retrieve the master key for decrypting the storage.


  3. Changing the user pin/password will not change the master key, only the encryption of the master key.






share|improve this answer










New contributor




f9c69e9781fa194211448473495534 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.










I completely agree with AndrolGenhald's high-level answer. In case you are interested in a complementary low-level walk-through of Android's storage encryption implementation:



Android can do File-Based Encryption (FBE) and Full-Disc Encryption (FDE), with "disc" referring to the /data partition. I will focus on FDE to illustrate the principle. The set-up is done by the Volume Daemon (Vold), specifically in system/vold/cryptfs.cpp.




  • cryptfs_enable_internal(int crypt_type, const char* passwd, ...) starts the storage encryption, with crypt_type specifying if a pin or password is used (to determine which keyboard to show on the unlock screen) and passwd giving the actual user pin/password. It will set up a footer crypt_ftr to be stored along the encrypted partition, then it calls create_encrypted_random_key to populate the crypt_ftr.




    • create_encrypted_random_key generates a random master key and a random salt and passes them on to encrypt_master_key.


    • encrypt_master_key uses a key-derivation function (e.g. scrypt), that takes the salt and the user pin/password as an input and deterministically derives an intermediate key. The master key is then encrypted with the intermediate key using AES-128-CBC. The encrypted master key and the salt are stored in crypt_ftr, but not the user pin/password.

    • Back in cryptfs_enable_internal, the crypt_ftr is written to the disc. Then the actual storage encryption via Linux' dm-crypt is triggered using the decrypted master key.


  • cryptfs_check_passwd(const char* passwd) starts storage decryption by backtracking the above steps to obtain the decrypted master key. The crypt_ftr has to be read from the disc, containing the encrypted master key and the salt. The user-supplied pin/password plus salt are fed into the key derivation function. This results in an intermediate key that can decrypt the master key (most of this happens in decrypt_master_key_aux).



  • cryptfs_changepw(int crypt_type, const char* newpw) handles changing the user pin/password. It will not generate a new master key, it just encrypts the existing master key via encrypt_master_key using the new user pin/password.

Based on this information, the answers to your questions would be:



  1. The randomly generated master key is used for the actual storage encryption.


  2. We need a user pin/password to encrypt the master key. Thus the user pin/password is needed to later retrieve the master key for decrypting the storage.


  3. Changing the user pin/password will not change the master key, only the encryption of the master key.







share|improve this answer










New contributor




f9c69e9781fa194211448473495534 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this answer



share|improve this answer








edited Apr 7 at 19:09





















New contributor




f9c69e9781fa194211448473495534 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









answered Apr 7 at 18:45









f9c69e9781fa194211448473495534f9c69e9781fa194211448473495534

1595




1595




New contributor




f9c69e9781fa194211448473495534 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





f9c69e9781fa194211448473495534 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






f9c69e9781fa194211448473495534 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.












  • Thanks for elaborate 'under the hood' explanation for Android!

    – Filipp W.
    Apr 9 at 6:32


















  • Thanks for elaborate 'under the hood' explanation for Android!

    – Filipp W.
    Apr 9 at 6:32

















Thanks for elaborate 'under the hood' explanation for Android!

– Filipp W.
Apr 9 at 6:32






Thanks for elaborate 'under the hood' explanation for Android!

– Filipp W.
Apr 9 at 6:32











Filipp W. is a new contributor. Be nice, and check out our Code of Conduct.









draft saved

draft discarded


















Filipp W. is a new contributor. Be nice, and check out our Code of Conduct.












Filipp W. is a new contributor. Be nice, and check out our Code of Conduct.











Filipp W. is a new contributor. Be nice, and check out our Code of Conduct.














Thanks for contributing an answer to Information Security Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f206979%2fhow-is-it-possible-for-users-password-to-be-changed-after-storage-was-encrypted%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

រឿង រ៉ូមេអូ និង ហ្ស៊ុយលីយេ សង្ខេបរឿង តួអង្គ បញ្ជីណែនាំ

Crop image to path created in TikZ? Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern)Crop an inserted image?TikZ pictures does not appear in posterImage behind and beyond crop marks?Tikz picture as large as possible on A4 PageTransparency vs image compression dilemmaHow to crop background from image automatically?Image does not cropTikzexternal capturing crop marks when externalizing pgfplots?How to include image path that contains a dollar signCrop image with left size given

Romeo and Juliet ContentsCharactersSynopsisSourcesDate and textThemes and motifsCriticism and interpretationLegacyScene by sceneSee alsoNotes and referencesSourcesExternal linksNavigation menu"Consumer Price Index (estimate) 1800–"10.2307/28710160037-3222287101610.1093/res/II.5.31910.2307/45967845967810.2307/2869925286992510.1525/jams.1982.35.3.03a00050"Dada Masilo: South African dancer who breaks the rules"10.1093/res/os-XV.57.1610.2307/28680942868094"Sweet Sorrow: Mann-Korman's Romeo and Juliet Closes Sept. 5 at MN's Ordway"the original10.2307/45957745957710.1017/CCOL0521570476.009"Ram Leela box office collections hit massive Rs 100 crore, pulverises prediction"Archived"Broadway Revival of Romeo and Juliet, Starring Orlando Bloom and Condola Rashad, Will Close Dec. 8"Archived10.1075/jhp.7.1.04hon"Wherefore art thou, Romeo? To make us laugh at Navy Pier"the original10.1093/gmo/9781561592630.article.O006772"Ram-leela Review Roundup: Critics Hail Film as Best Adaptation of Romeo and Juliet"Archived10.2307/31946310047-77293194631"Romeo and Juliet get Twitter treatment""Juliet's Nurse by Lois Leveen""Romeo and Juliet: Orlando Bloom's Broadway Debut Released in Theaters for Valentine's Day"Archived"Romeo and Juliet Has No Balcony"10.1093/gmo/9781561592630.article.O00778110.2307/2867423286742310.1076/enst.82.2.115.959510.1080/00138380601042675"A plague o' both your houses: error in GCSE exam paper forces apology""Juliet of the Five O'Clock Shadow, and Other Wonders"10.2307/33912430027-4321339124310.2307/28487440038-7134284874410.2307/29123140149-661129123144728341M"Weekender Guide: Shakespeare on The Drive""balcony"UK public library membership"romeo"UK public library membership10.1017/CCOL9780521844291"Post-Zionist Critique on Israel and the Palestinians Part III: Popular Culture"10.2307/25379071533-86140377-919X2537907"Capulets and Montagues: UK exam board admit mixing names up in Romeo and Juliet paper"Istoria Novellamente Ritrovata di Due Nobili Amanti2027/mdp.390150822329610820-750X"GCSE exam error: Board accidentally rewrites Shakespeare"10.2307/29176390149-66112917639"Exam board apologises after error in English GCSE paper which confused characters in Shakespeare's Romeo and Juliet""From Mariotto and Ganozza to Romeo and Guilietta: Metamorphoses of a Renaissance Tale"10.2307/37323537323510.2307/2867455286745510.2307/28678912867891"10 Questions for Taylor Swift"10.2307/28680922868092"Haymarket Theatre""The Zeffirelli Way: Revealing Talk by Florentine Director""Michael Smuin: 1938-2007 / Prolific dance director had showy career"The Life and Art of Edwin BoothRomeo and JulietRomeo and JulietRomeo and JulietRomeo and JulietEasy Read Romeo and JulietRomeo and Julieteeecb12003684p(data)4099369-3n8211610759dbe00d-a9e2-41a3-b2c1-977dd692899302814385X313670221313670221