How is it possible for user's password to be changed after storage was encrypted? (on OS X, Android)Are 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

What would the Romans have called "sorcery"?

Validation accuracy vs Testing accuracy

Should I join office cleaning event for free?

Compute hash value according to multiplication method

How do we improve the relationship with a client software team that performs poorly and is becoming less collaborative?

How can I fix this gap between bookcases I made?

What defenses are there against being summoned by the Gate spell?

How to add power-LED to my small amplifier?

Pronouncing Dictionary.com's W.O.D "vade mecum" in English

What Brexit solution does the DUP want?

Is Social Media Science Fiction?

Set-theoretical foundations of Mathematics with only bounded quantifiers

How can the DM most effectively choose 1 out of an odd number of players to be targeted by an attack or effect?

Do airline pilots ever risk not hearing communication directed to them specifically, from traffic controllers?

Download, install and reboot computer at night if needed

Example of a relative pronoun

I’m planning on buying a laser printer but concerned about the life cycle of toner in the machine

What do you call something that goes against the spirit of the law, but is legal when interpreting the law to the letter?

Can I make popcorn with any corn?

Japan - Plan around max visa duration

Draw simple lines in Inkscape

Why are 150k or 200k jobs considered good when there are 300k+ births a month?

"You are your self first supporter", a more proper way to say it

How much RAM could one put in a typical 80386 setup?



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


Are 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;








6















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 encription 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 via current user password (sort of like encrypting an arhive) and if password is changed — the whole storage must be re-encrypted. This (apparenty 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.


























    6















    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 encription 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 via current user password (sort of like encrypting an arhive) and if password is changed — the whole storage must be re-encrypted. This (apparenty 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.






















      6












      6








      6








      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 encription 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 via current user password (sort of like encrypting an arhive) and if password is changed — the whole storage must be re-encrypted. This (apparenty 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 encription 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 via current user password (sort of like encrypting an arhive) and if password is changed — the whole storage must be re-encrypted. This (apparenty 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 1 hour ago









      Moshe Katz

      486311




      486311






      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 10 hours ago









      Filipp W.Filipp W.

      1335




      1335




      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 Answers
          2






          active

          oldest

          votes


















          7














          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


















          • 3





            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
            9 hours ago











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

            – AndrolGenhald
            8 hours ago











          • That, I do not disagree with :)

            – vidarlo
            8 hours ago


















          2














          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.




















            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









            7














            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


















            • 3





              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
              9 hours ago











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

              – AndrolGenhald
              8 hours ago











            • That, I do not disagree with :)

              – vidarlo
              8 hours ago















            7














            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


















            • 3





              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
              9 hours ago











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

              – AndrolGenhald
              8 hours ago











            • That, I do not disagree with :)

              – vidarlo
              8 hours ago













            7












            7








            7







            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 9 hours ago









            AndrolGenhaldAndrolGenhald

            12k52837




            12k52837







            • 3





              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
              9 hours ago











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

              – AndrolGenhald
              8 hours ago











            • That, I do not disagree with :)

              – vidarlo
              8 hours ago












            • 3





              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
              9 hours ago











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

              – AndrolGenhald
              8 hours ago











            • That, I do not disagree with :)

              – vidarlo
              8 hours ago







            3




            3





            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
            9 hours ago





            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
            9 hours ago













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

            – AndrolGenhald
            8 hours ago





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

            – AndrolGenhald
            8 hours ago













            That, I do not disagree with :)

            – vidarlo
            8 hours ago





            That, I do not disagree with :)

            – vidarlo
            8 hours ago













            2














            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.
























              2














              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.






















                2












                2








                2







                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 6 hours ago





















                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 6 hours ago









                f9c69e9781fa194211448473495534f9c69e9781fa194211448473495534

                212




                212




                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.




















                    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

                    How to create a command for the “strange m” symbol in latex? Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern)How do you make your own symbol when Detexify fails?Writing bold small caps with mathpazo packageplus-minus symbol with parenthesis around the minus signGreek character in Beamer document titleHow to create dashed right arrow over symbol?Currency symbol: Turkish LiraDouble prec as a single symbol?Plus Sign Too Big; How to Call adfbullet?Is there a TeX macro for three-legged pi?How do I get my integral-like symbol to align like the integral?How to selectively substitute a letter with another symbol representing the same letterHow do I generate a less than symbol and vertical bar that are the same height?

                    Българска екзархия Съдържание История | Български екзарси | Вижте също | Външни препратки | Литература | Бележки | НавигацияУстав за управлението на българската екзархия. Цариград, 1870Слово на Ловешкия митрополит Иларион при откриването на Българския народен събор в Цариград на 23. II. 1870 г.Българската правда и гръцката кривда. От С. М. (= Софийски Мелетий). Цариград, 1872Предстоятели на Българската екзархияПодмененият ВеликденИнформационна агенция „Фокус“Димитър Ризов. Българите в техните исторически, етнографически и политически граници (Атлас съдържащ 40 карти). Berlin, Königliche Hoflithographie, Hof-Buch- und -Steindruckerei Wilhelm Greve, 1917Report of the International Commission to Inquire into the Causes and Conduct of the Balkan Wars

                    Чепеларе Съдържание География | История | Население | Спортни и природни забележителности | Културни и исторически обекти | Религии | Обществени институции | Известни личности | Редовни събития | Галерия | Източници | Литература | Външни препратки | Навигация41°43′23.99″ с. ш. 24°41′09.99″ и. д. / 41.723333° с. ш. 24.686111° и. д.*ЧепелареЧепеларски Linux fest 2002Начало на Зимен сезон 2005/06Национални хайдушки празници „Капитан Петко Войвода“Град ЧепелареЧепеларе – народният ски курортbgrod.orgwww.terranatura.hit.bgСправка за населението на гр. Исперих, общ. Исперих, обл. РазградМузей на родопския карстМузей на спорта и скитеЧепеларебългарскибългарскианглийскитукИстория на градаСки писти в ЧепелареВремето в ЧепелареРадио и телевизия в ЧепелареЧепеларе мами с родопски чар и добри пистиЕвтин туризъм и снежни атракции в ЧепелареМестоположениеИнформация и снимки от музея на родопския карст3D панорами от ЧепелареЧепелареррр