Skip to main content
Spelling
Source Link
Bo Lawson
  • 2.6k
  • 20
  • 18

It looks like Google agrees with you and is phasing out "legacy" full disk encryption:

Caution: Support for full-disk encryption is going away. If you're creating a new device, you should use file-based encryption.

Full disk encryption was considered pretty solid uniluntil 2016 because of the hardware backed trusted execution environment. Depending on how the OEM implements the trusted execution environment as hardware or software backed. Ifand if the OEM utilizes the android keystore system. Makes a varying degree of security. If instead it is software backed then not so much.

The encryption keys isare not just sitting in some un-encrypted partition. The encrypted encryption key is stored in theth e crypto metadata. The hardware backed trusted execution environment’s signing capability and if the android keystore system is implemented then the android device as a whole and even the android kernel do not have access to the keymaster within trusted secure enviroment. The keystore system is very intresting but explaining the security and operations behind it involves a multiple page explaination that would be answered best though its own question.

Android devices that support a lock screen and ship with Android 7.0 or higher have a secondary, isolated environment called a Trusted Execution Environment. This enables further separation from any untrusted code. The capability is typically implemented using secure hardware.

Examples of the way a trusted execution environment can be set up are:

A separate virtual machine, hypervisor, or purpose-built trusted execution environment like ARM TrustZone. The isolated environment must provide complete separation from the Android kernel and user space (non-secure world). This separation is so that nothing running in the non-secure-world can observe or manipulate the results of any computation in the isolated environment.

Android 9.0 introduced a hardware backed trusted execution envirementenvironment called a strongbox. The strongbox is a completely separate, purpose-built and certified secure CPUs. Examples of StrongBox devices are embedded Secure Elements (eSE) or on-SoC secure processing units.

A hardware backed trusted secure environment that utilizes the android keystore system can serve as strong protection for the encrypted encryption key. Unless a third party such as Qualcomm (2016) happens to mess up with tmandesign oversite in the implementation of the keymaster.

It looks like Google agrees with you and is phasing out "legacy" full disk encryption:

Caution: Support for full-disk encryption is going away. If you're creating a new device, you should use file-based encryption.

Full disk encryption was considered pretty solid unil 2016 because of the hardware backed trusted execution environment. Depending on how the OEM implements the trusted execution environment as hardware or software backed. If the OEM utilizes the android keystore system. Makes a varying degree of security. If instead it is software backed then not so much.

The encryption keys is not just sitting in some un-encrypted partition. The encrypted encryption key is stored in the crypto metadata. The hardware backed trusted execution environment’s signing capability and if the android keystore system is implemented then the android device as a whole and even the android kernel do not have access to the keymaster within trusted secure enviroment. The keystore system is very intresting but explaining the security and operations behind it involves a multiple page explaination that would be answered best though its own question.

Android devices that support a lock screen and ship with Android 7.0 or higher have a secondary, isolated environment called a Trusted Execution Environment. This enables further separation from any untrusted code. The capability is typically implemented using secure hardware.

Examples of the way a trusted execution environment can be set up are:

A separate virtual machine, hypervisor, or purpose-built trusted execution environment like ARM TrustZone. The isolated environment must provide complete separation from the Android kernel and user space (non-secure world). This separation is so that nothing running in the non-secure-world can observe or manipulate the results of any computation in the isolated environment.

Android 9.0 introduced a hardware backed trusted execution envirement called a strongbox. The strongbox is a completely separate, purpose-built and certified secure CPUs. Examples of StrongBox devices are embedded Secure Elements (eSE) or on-SoC secure processing units.

A hardware backed trusted secure environment that utilizes the android keystore system can serve as strong protection for the encrypted encryption key. Unless a third party such as Qualcomm (2016) happens to mess up with tman oversite in the implementation of the keymaster.

It looks like Google agrees with you and is phasing out "legacy" full disk encryption:

Caution: Support for full-disk encryption is going away. If you're creating a new device, you should use file-based encryption.

Full disk encryption was considered pretty solid until 2016 because of the hardware backed trusted execution environment. Depending on how the OEM implements the trusted execution environment and if the OEM utilizes the android keystore system. Makes a varying degree of security. If instead it is software backed then not so much.

The encryption keys are not just sitting in some un-encrypted partition. The encrypted encryption key is stored in th e crypto metadata. The hardware backed trusted execution environment’s signing capability and if the android keystore system is implemented then the android device as a whole and even the android kernel do not have access to the keymaster within trusted secure enviroment. The keystore system is very intresting but explaining the security and operations behind it involves a multiple page explaination that would be answered best though its own question.

Android devices that support a lock screen and ship with Android 7.0 or higher have a secondary, isolated environment called a Trusted Execution Environment. This enables further separation from any untrusted code. The capability is typically implemented using secure hardware.

Examples of the way a trusted execution environment can be set up are:

A separate virtual machine, hypervisor, or purpose-built trusted execution environment like ARM TrustZone. The isolated environment must provide complete separation from the Android kernel and user space (non-secure world). This separation is so that nothing running in the non-secure-world can observe or manipulate the results of any computation in the isolated environment.

Android 9.0 introduced a hardware backed trusted execution environment called a strongbox. The strongbox is a completely separate, purpose-built and certified secure CPUs. Examples of StrongBox devices are embedded Secure Elements (eSE) or on-SoC secure processing units.

A hardware backed trusted secure environment that utilizes the android keystore system can serve as strong protection for the encrypted encryption key. Unless a third party such as Qualcomm (2016) happens to mess up with design oversite in the implementation of the keymaster.

Source Link
Bo Lawson
  • 2.6k
  • 20
  • 18

It looks like Google agrees with you and is phasing out "legacy" full disk encryption:

Caution: Support for full-disk encryption is going away. If you're creating a new device, you should use file-based encryption.

Full disk encryption was considered pretty solid unil 2016 because of the hardware backed trusted execution environment. Depending on how the OEM implements the trusted execution environment as hardware or software backed. If the OEM utilizes the android keystore system. Makes a varying degree of security. If instead it is software backed then not so much.

The encryption keys is not just sitting in some un-encrypted partition. The encrypted encryption key is stored in the crypto metadata. The hardware backed trusted execution environment’s signing capability and if the android keystore system is implemented then the android device as a whole and even the android kernel do not have access to the keymaster within trusted secure enviroment. The keystore system is very intresting but explaining the security and operations behind it involves a multiple page explaination that would be answered best though its own question.

Android devices that support a lock screen and ship with Android 7.0 or higher have a secondary, isolated environment called a Trusted Execution Environment. This enables further separation from any untrusted code. The capability is typically implemented using secure hardware.

Examples of the way a trusted execution environment can be set up are:

A separate virtual machine, hypervisor, or purpose-built trusted execution environment like ARM TrustZone. The isolated environment must provide complete separation from the Android kernel and user space (non-secure world). This separation is so that nothing running in the non-secure-world can observe or manipulate the results of any computation in the isolated environment.

Android 9.0 introduced a hardware backed trusted execution envirement called a strongbox. The strongbox is a completely separate, purpose-built and certified secure CPUs. Examples of StrongBox devices are embedded Secure Elements (eSE) or on-SoC secure processing units.

A hardware backed trusted secure environment that utilizes the android keystore system can serve as strong protection for the encrypted encryption key. Unless a third party such as Qualcomm (2016) happens to mess up with tman oversite in the implementation of the keymaster.