On 12/6/19 11:40 AM, John M. Harris Jr
wrote:
Means, if someone steals the device, he can boot a system. Even if we assume that the systemcode is safe and there is no way to interrupt the bootprocess, we are now able to attack the login, which will be much easier than the encryption key, which is massive compared to the passwords in use.Yeah, there are a contingent here that believe that it's not necessary to ensure the person booting the device is actually authorized to access the content of the laptop.. Which threat model do you consider here? I don't remember anyone
suggesting that the person who physically boots the machine gets
unimpeded access to the contents, without any authentication: the
assumption is that system boots into an authentication login
prompt. We discussed the following threats: - removing the physical unencrypted (or encrypted) disk, and reading and even modifying it in another system - interrupting the boot process and bypassing authentication - bypassing or bruteforcing the login authentication (Marius' concern) Each threat requires a different mitigation. The Android model
depends on the fact that the storage media is not easily
removable, and is encrypted with securely stored keys (a la TPM),
and the fact that the boot process is secure so you can't break
into it after the storage is decrypted, so then the remaining
threat vector is breaking the user login authentication shown when
the system completes the boot process. At some point you said that you don't believe that Android model
is secure -- could you explain why do you believe that? This is
relevant to our discussion because I believe that we should follow
the Android/IOS model. |
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx