How is it possible for user's password to be changed after storage was encrypted? (on OS X, Android)
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}
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:
- 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?
- If password is not the basis for encryption, why is it required to set one before encrypting your storage?
- How is ability to decrypt storage is maintained (without re-encrypting) after password is changed?
encryption passwords android disk-encryption macosx
New contributor
add a comment |
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:
- 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?
- If password is not the basis for encryption, why is it required to set one before encrypting your storage?
- How is ability to decrypt storage is maintained (without re-encrypting) after password is changed?
encryption passwords android disk-encryption macosx
New contributor
2
I'm pretty sure this is a duplicate, but I can't find the question I'm thinking of...
– forest
yesterday
@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
12 hours ago
Related (Superuser): Does changing the encryption password imply rewriting all the data?
– Marc.2377
3 hours ago
add a comment |
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:
- 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?
- If password is not the basis for encryption, why is it required to set one before encrypting your storage?
- How is ability to decrypt storage is maintained (without re-encrypting) after password is changed?
encryption passwords android disk-encryption macosx
New contributor
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:
- 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?
- If password is not the basis for encryption, why is it required to set one before encrypting your storage?
- How is ability to decrypt storage is maintained (without re-encrypting) after password is changed?
encryption passwords android disk-encryption macosx
encryption passwords android disk-encryption macosx
New contributor
New contributor
edited 19 hours ago
Filipp W.
New contributor
asked yesterday
Filipp W.Filipp W.
22328
22328
New contributor
New contributor
2
I'm pretty sure this is a duplicate, but I can't find the question I'm thinking of...
– forest
yesterday
@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
12 hours ago
Related (Superuser): Does changing the encryption password imply rewriting all the data?
– Marc.2377
3 hours ago
add a comment |
2
I'm pretty sure this is a duplicate, but I can't find the question I'm thinking of...
– forest
yesterday
@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
12 hours ago
Related (Superuser): Does changing the encryption password imply rewriting all the data?
– Marc.2377
3 hours ago
2
2
I'm pretty sure this is a duplicate, but I can't find the question I'm thinking of...
– forest
yesterday
I'm pretty sure this is a duplicate, but I can't find the question I'm thinking of...
– forest
yesterday
@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
12 hours ago
@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
12 hours ago
Related (Superuser): Does changing the encryption password imply rewriting all the data?
– Marc.2377
3 hours ago
Related (Superuser): Does changing the encryption password imply rewriting all the data?
– Marc.2377
3 hours ago
add a comment |
2 Answers
2
active
oldest
votes
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.
20
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
yesterday
4
@vidarlo True, but I wouldn't expect the average user to understand this, or to need it.
– AndrolGenhald
yesterday
That, I do not disagree with :)
– vidarlo
yesterday
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
10 hours ago
add a comment |
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, withcrypt_type
specifying if a pin or password is used (to determine which keyboard to show on the unlock screen) andpasswd
giving the actual user pin/password. It will set up a footercrypt_ftr
to be stored along the encrypted partition, then it callscreate_encrypted_random_key
to populate thecrypt_ftr
.
create_encrypted_random_key
generates a random master key and a random salt and passes them on toencrypt_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 incrypt_ftr
, but not the user pin/password.- Back in
cryptfs_enable_internal
, thecrypt_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. Thecrypt_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 indecrypt_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 viaencrypt_master_key
using the new user pin/password.
Based on this information, the answers to your questions would be:
The randomly generated master key is used for the actual storage encryption.
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.
Changing the user pin/password will not change the master key, only the encryption of the master key.
New contributor
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
20
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
yesterday
4
@vidarlo True, but I wouldn't expect the average user to understand this, or to need it.
– AndrolGenhald
yesterday
That, I do not disagree with :)
– vidarlo
yesterday
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
10 hours ago
add a comment |
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.
20
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
yesterday
4
@vidarlo True, but I wouldn't expect the average user to understand this, or to need it.
– AndrolGenhald
yesterday
That, I do not disagree with :)
– vidarlo
yesterday
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
10 hours ago
add a comment |
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.
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.
answered yesterday
AndrolGenhaldAndrolGenhald
12.2k53138
12.2k53138
20
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
yesterday
4
@vidarlo True, but I wouldn't expect the average user to understand this, or to need it.
– AndrolGenhald
yesterday
That, I do not disagree with :)
– vidarlo
yesterday
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
10 hours ago
add a comment |
20
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
yesterday
4
@vidarlo True, but I wouldn't expect the average user to understand this, or to need it.
– AndrolGenhald
yesterday
That, I do not disagree with :)
– vidarlo
yesterday
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
10 hours ago
20
20
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
yesterday
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
yesterday
4
4
@vidarlo True, but I wouldn't expect the average user to understand this, or to need it.
– AndrolGenhald
yesterday
@vidarlo True, but I wouldn't expect the average user to understand this, or to need it.
– AndrolGenhald
yesterday
That, I do not disagree with :)
– vidarlo
yesterday
That, I do not disagree with :)
– vidarlo
yesterday
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
10 hours ago
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
10 hours ago
add a comment |
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, withcrypt_type
specifying if a pin or password is used (to determine which keyboard to show on the unlock screen) andpasswd
giving the actual user pin/password. It will set up a footercrypt_ftr
to be stored along the encrypted partition, then it callscreate_encrypted_random_key
to populate thecrypt_ftr
.
create_encrypted_random_key
generates a random master key and a random salt and passes them on toencrypt_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 incrypt_ftr
, but not the user pin/password.- Back in
cryptfs_enable_internal
, thecrypt_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. Thecrypt_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 indecrypt_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 viaencrypt_master_key
using the new user pin/password.
Based on this information, the answers to your questions would be:
The randomly generated master key is used for the actual storage encryption.
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.
Changing the user pin/password will not change the master key, only the encryption of the master key.
New contributor
add a comment |
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, withcrypt_type
specifying if a pin or password is used (to determine which keyboard to show on the unlock screen) andpasswd
giving the actual user pin/password. It will set up a footercrypt_ftr
to be stored along the encrypted partition, then it callscreate_encrypted_random_key
to populate thecrypt_ftr
.
create_encrypted_random_key
generates a random master key and a random salt and passes them on toencrypt_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 incrypt_ftr
, but not the user pin/password.- Back in
cryptfs_enable_internal
, thecrypt_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. Thecrypt_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 indecrypt_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 viaencrypt_master_key
using the new user pin/password.
Based on this information, the answers to your questions would be:
The randomly generated master key is used for the actual storage encryption.
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.
Changing the user pin/password will not change the master key, only the encryption of the master key.
New contributor
add a comment |
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, withcrypt_type
specifying if a pin or password is used (to determine which keyboard to show on the unlock screen) andpasswd
giving the actual user pin/password. It will set up a footercrypt_ftr
to be stored along the encrypted partition, then it callscreate_encrypted_random_key
to populate thecrypt_ftr
.
create_encrypted_random_key
generates a random master key and a random salt and passes them on toencrypt_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 incrypt_ftr
, but not the user pin/password.- Back in
cryptfs_enable_internal
, thecrypt_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. Thecrypt_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 indecrypt_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 viaencrypt_master_key
using the new user pin/password.
Based on this information, the answers to your questions would be:
The randomly generated master key is used for the actual storage encryption.
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.
Changing the user pin/password will not change the master key, only the encryption of the master key.
New contributor
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, withcrypt_type
specifying if a pin or password is used (to determine which keyboard to show on the unlock screen) andpasswd
giving the actual user pin/password. It will set up a footercrypt_ftr
to be stored along the encrypted partition, then it callscreate_encrypted_random_key
to populate thecrypt_ftr
.
create_encrypted_random_key
generates a random master key and a random salt and passes them on toencrypt_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 incrypt_ftr
, but not the user pin/password.- Back in
cryptfs_enable_internal
, thecrypt_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. Thecrypt_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 indecrypt_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 viaencrypt_master_key
using the new user pin/password.
Based on this information, the answers to your questions would be:
The randomly generated master key is used for the actual storage encryption.
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.
Changing the user pin/password will not change the master key, only the encryption of the master key.
New contributor
edited yesterday
New contributor
answered yesterday
f9c69e9781fa194211448473495534f9c69e9781fa194211448473495534
1194
1194
New contributor
New contributor
add a comment |
add a comment |
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.
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
2
I'm pretty sure this is a duplicate, but I can't find the question I'm thinking of...
– forest
yesterday
@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
12 hours ago
Related (Superuser): Does changing the encryption password imply rewriting all the data?
– Marc.2377
3 hours ago