Where is the Option to Encrypt the Phone on a Sasung A7, Oreo 8.0.0?

This should help " 
https://www.hardreset.info/devices/samsung/samsung-g570f-galaxy-j5-prime/faq/faq/how-to-permanently-delete-data-from-phone/

Encrypting the data on SAMSUNG G570F Galaxy J5 Prime could be done in a few steps: go to Settings, then Security, choose Encrypt Device and Set Screen Lock type. Make sure that your device is fully charged or is currently charging as this process on G570F Galaxy J5 Prime could take a long time {even up to one hour).

Hi,

Can't reach those settings on the A7, Android 9, Pie

Saw this.  Is it true?  Has activating encryption been made obsolete = now it is by default for Android 8 Oreo, and higher?

...I can tell you your data is safe & encrypted by default, that is why you can't find an encryption setting.

Source: https://forum.xda-developers.com/general/security/phone-encryption-android-8-oreo-huawei-t3851446

Thanks!

OT

Hi oaktrees,

When you go to Settings, do you see the option for Security at all?

Under the Security menu you should be able to find the option to view Encryption (& Credentials). My phone runs plain Android so its probably a little bit different, but you should still be able to get to Settings -> Security -> Encryption or something similar along that path.

Regarding the data being safe and encrypted by default, it appears Google has required disk encryption for all devices since version 6.0. If you buy a budget phone it may not support encryption, but your A7 doesn't fall in that category. So your phone's internal storage is encrypted, but you can follow the above steps to find an option to encrypt the SD card if you use one.

Hi Martin,

You wrote:

...your phone's internal storage is encrypted...

and

Google has required disk encryption for all devices since version 6.0.

Any links about that?

Encrypting the SD Card - yep!  Got that done straight out of the box.  Even DE-crypted it from the last phone, and then encrypted again on new phone.

Still can't find a place to encrypt the PHONE, itself among the many settings.

Any links about that?

Read "9.9. Data Storage Encryption" from the link below.

https://source.android.com/compatibility/8.0/android-8.0-cdd

Read also the link below.

https://source.android.com/security/encryption

The keyword is MUST. If the above document says MUST, the phone manufacturer must follow what the above document say in order to make the device compatible.

Finally, if you want deeper understanding, read the link below also which is a comprehensive guide to the built-in encryption for Android OS.

https://www.androidauthority.com/how-to-encrypt-android-device-326700/

Hi,

So, sounds like, from 6.0 forward, the phone, with a password, is encrypted?

Sincerely,

OT

So, sounds like, from 6.0 forward, the phone, with a password, is encrypted?

Not exactly the case. If the device is upgraded to 6.0 and cannot meet hardware requirement (50mb/s data transfer speed for internal storage), encryption will just not be practical to perform.

If the device is designed for 6.0 and did meet hardware requirement, full disk encryption must be enabled after user has completed the out-of-the-box setup experience.

https://www.extremetech.com/mobile/216560-android-6-0-marshmallow-makes-full-disk-encryption-mandatory-for-most-new-devices

Great link, Jackie! Thank you so much!

There's a lot of discussion inside the article about different chipset configurations, is there any way to tell if my Samsung A7, 2018 - bought new just this week (I usually buy a new version of last year's models to save a little $!! :D) - and which came with Oreo installed, is there any way to tell if this one has full disk encryption enabled?

Many thanks,

OT

Octa-core (2x2.2 GHz Cortex-A73 & 6x1.6 GHz Cortex-A53)

Source: https://www.gsmarena.com/samsung_galaxy_a7_(2018)-9340.php

The CPU of your phone should be able to handle encryption and the FDE must be enabled for its internal storage unless you have not enabled a password, PIN or pattern to logon to your phone.

Hi Jackie,

You wrote:

The CPU of your phone should be able to handle encryption...

Need to know if, by activating a password on my phone, that ALSO encrypts it?  Put another way: in previous models of Android, one would need to actually take several steps to encrypt the phone.  Seems like the answer here is, since Android 6, the phones themselves - if password protected - are encrypted by default.

Am I right?

Many thanks,

OT

Need to know if, by activating a password on my phone, that ALSO encrypts it?  

For Android 6, No. Adding a password will only encrypt the encryption key as there is no need (no way) to do encryption of the internal storage which has been enabled by default.

When you factory reset your phone, the encryption key will be deleted only. No matter whether you have set a password or not, the content inside the internal storage will not be recoverable as the encryption key is gone.

Android does not offer anything that can approach iOS in terms of encryption. Instead, Android employs a straightforward block-level encryption of the data partition. Pre-Lollipop devices were using the old insecure encryption scheme that was relatively easy to break. Since Android 5.0, Google switched to new full-disk encryption that became significantly more secure.

By default, the decryption key is stored in the hardware-backed storage using Trusted Execution Environment’s (TEE) signing capability (such as in a TrustZone). The data partition is decrypted with that key automatically once the device reboots. While this may sound lame (what’s the purpose of encryption anyway if the data can be decrypted without user interaction?), bear in mind that extracting the decryption key via chip-off or any other low-level method is not possible, so if you do a chip-off you won’t get the decryption key and won’t be able to decrypt the data.

Users who require additional security can activate boot-level protection by setting the requirement of typing a passcode or password in order to allow the device to continue booting. In this case, the encryption key is created dynamically based on user input as well as device data. There is no official data about the number of users who enabled this feature. Our guess is it is not a lot.

Source: https://blog.elcomsoft.com/2017/05/android-encryption-demystified/

Hi Jackie,

You posted:

Need to know if, by activating a password on my phone, that ALSO encrypts it?  

For Android 6, No.

How about Android 9?

Many thanks,

OT

The above is the screenshot of my Android phone running Android One (Android 9 lite version).

Android devices are designed for end consumers and encryption is only one of many measures for security. Android OS 9 is more secure by design than previous version Android OS. End users will not care on how the encryption works but if you want to know the details, please read the following which are extracted from the Android 9 Compatibility Definition Document.

https://source.android.com/compatibility/9/android-9-cdd.pdf

9.9. Data Storage Encryption
If Advanced Encryption Standard (AES) crypto performance, measured with the most performant AES
technology available on the device (e.g. the ARM Cryptography Extensions), is above 50 MiB/sec,
device implementations:
[C-1-1] MUST support data storage encryption of the application private data (/data
partition), as well as the application shared storage partition ( /sdcard partition) if it is a
permanent, non-removable part of the device, except for device implementations that are
typically shared (e.g. Television).
[C-1-2] MUST enable the data storage encryption by default at the time the user has
completed the out-of-box setup experience, except for device implementations that are
typically shared (e.g. Television).
If the AES crypto performance is at or below 50 MiB/sec, device implementations MAY use
Adiantum-XChaCha12-AES instead of the form of AES listed in any of the following: AES-256-XTS in
Section 9.9.2 [C-1-5]; AES-256 in CBS-CTS mode in Section 9.9.2 [C-1-6]; AES in Section 9.9.3 [C-1-
1]; AES in Section 9.9.3 [C-1-3].
If device implementations are already launched on an earlier Android version and cannot meet the
requirement through a system software update, they MAY be exempted from the above requirements.
Device implementations:
SHOULD meet the above data storage encryption requirement via implementing File
Based Encryption (FBE).

9.9.1. Direct Boot
Device implementations:
[C-0-1] MUST implement the Direct Boot mode APIs even if they do not support Storage
Encryption.
[C-0-2] The ACTION_LOCKED_BOOT_COMPLETED and ACTION_USER_UNLOCKED Intents
MUST still be broadcast to signal Direct Boot aware applications that Device Encrypted
(DE) and Credential Encrypted (CE) storage locations are available for user

9.9.2. File Based Encryption

If device implementations support FBE, they:
[C-1-1] MUST boot up without challenging the user for credentials and allow Direct Boot
aware apps to access to the Device Encrypted (DE) storage after the
ACTION_LOCKED_BOOT_COMPLETED message is broadcasted.
[C-1-2] MUST only allow access to Credential Encrypted (CE) storage after the user has
unlocked the device by supplying their credentials (eg. passcode, pin, pattern or
fingerprint) and the ACTION_USER_UNLOCKED message is broadcasted.
[C-1-3] MUST NOT offer any method to unlock the CE protected storage without either the
user-supplied credentials or a registered escrow key.
[C-1-4] MUST support Verified Boot and ensure that DE keys are cryptographically bound
to the device's hardware root of trust.
[C-1-5] MUST support encrypting file contents using AES-256-XTS. AES-256-XTS refers
to the Advanced Encryption Standard with a 256-bit key length, operated in XTS mode.
The full length of the XTS key is 512 bits.
[C-1-6] MUST support encrypting file names using AES-256 in CBC-CTS mode.
The keys protecting CE and DE storage areas:
[C-1-7] MUST be cryptographically bound to a hardware-backed Keystore.
[C-1-8] CE keys MUST be bound to a user's lock screen credentials.
[C-1-9] CE keys MUST be bound to a default passcode when the user has not specified
lock screen credentials.
[C-1-10] MUST be unique and distinct, in other words no user's CE or DE key matches any
other user's CE or DE keys.
[C-1-11] MUST use the mandatorily supported ciphers, key lengths and modes by default.
[C-SR] Are STRONGLY RECOMMENDED to encrypt file system metadata, such as file
sizes, ownership, modes, and Extended attributes (xattrs), with a key cryptographically
bound to the device's hardware root of trust.
SHOULD make preinstalled essential apps (e.g. Alarm, Phone, Messenger) Direct Boot
aware.
MAY support alternative ciphers, key lengths and modes for file content and file name
encryption.
The upstream Android Open Source project provides a preferred implementation of this feature
based on the Linux kernel ext4 encryption feature.
9.9.3. Full Disk Encryption
If device implementations support full disk encryption (FDE), they:
[C-1-1] MUST use AES in a mode designed for storage (for example, XTS or CBC-ESSIV),
and with a cipher key length of 128 bits or greater.
[C-1-2] MUST use a default passcode to wrap the encryption key and MUST NOT write the
encryption key to storage at any time without being encrypted.
[C-1-3] MUST AES encrypt the encryption key by default unless the user explicitly opts
out, except when it is in active use, with the lock screen credentials stretched using a
slow stretching algorithm (e.g. PBKDF2 or scrypt).
[C-1-4] The above default password stretching algorithm MUST be cryptographically
bound to that keystore when the user has not specified a lock screen credentials or has
disabled use of the passcode for encryption and the device provides a hardware-backed keystore.

[C-1-5] MUST NOT send encryption key off the device (even when wrapped with the user
passcode and/or hardware bound key).
The upstream Android Open Source project provides a preferred implementation of this feature,
based on the Linux kernel feature dm-crypt.
9.10. Device Integrity
The following requirements ensures there is transparency to the status of the device integrity. Device
implementations:
[C-0-1] MUST correctly report through the System API method
PersistentDataBlockManager.getFlashLockState() whether their bootloader state permits flashing
of the system image. The FLASH_LOCK_UNKNOWN state is reserved for device
implementations upgrading from an earlier version of Android where this new system API
method did not exist.
[C-0-2] MUST support Verified Boot for device integrity.
If device implementations are already launched without supporting Verified Boot on an earlier version
of Android and can not add support for this feature with a system software update, they MAY be
exempted from the requirement.
Verified Boot is a feature that guarantees the integrity of the device software. If device
implementations support the feature, they:
[C-1-1] MUST declare the platform feature flag android.software.verified_boot .
[C-1-2] MUST perform verification on every boot sequence.
[C-1-3] MUST start verification from an immutable hardware key that is the root of trust
and go all the way up to the system partition.
[C-1-4] MUST implement each stage of verification to check the integrity and authenticity
of all the bytes in the next stage before executing the code in the next stage.
[C-1-5] MUST use verification algorithms as strong as current recommendations from
NIST for hashing algorithms (SHA-256) and public key sizes (RSA-2048).
[C-1-6] MUST NOT allow boot to complete when system verification fails, unless the user
consents to attempt booting anyway, in which case the data from any non-verified storage
blocks MUST not be used.
[C-1-7] MUST NOT allow verified partitions on the device to be modified unless the user
has explicitly unlocked the bootloader.
[C-SR] If there are multiple discrete chips in the device (e.g. radio, specialized image
processor), the boot process of each of those chips is STRONGLY RECOMMENDED to
verify every stage upon booting.
[C-1-8] MUST use tamper-evident storage: for storing whether the bootloader is unlocked.
Tamper-evident storage means that the boot loader can detect if the storage has been
tampered with from inside Android.
[C-1-9] MUST prompt the user, while using the device, and require physical confirmation
before allowing a transition from boot loader locked mode to boot loader unlocked mode.
[C-1-10] MUST implement rollback protection for partitions used by Android (e.g. boot,
system partitions) and use tamper-evident storage for storing the metadata used for
determining the minimum allowable OS version.
[C-SR] Are STRONGLY RECOMMENDED to verify all privileged app APK files with a chain
of trust rooted in /system , which is protected by Verified Boot.
[C-SR] Are STRONGLY RECOMMENDED to verify any executable artifacts loaded by a
privileged app from outside its APK file (such as dynamically loaded code or compiled code) before executing them or STRONGLY RECOMMENDED not to execute them at all.
SHOULD implement rollback protection for any component with persistent firmware (e.g. modem, camera) and SHOULD use tamper-evident storage for storing the metadata used
for determining the minimum allowable version.
If device implementations are already launched without supporting C-1-8 through C-1-10 on an
earlier version of Android and can not add support for these requirements with a system software
update, they MAY be exempted from the requirements.
The upstream Android Open Source Project provides a preferred implementation of this feature in the
external/avb/ repository, which can be integrated into the boot loader used for loading Android.
Device implementations:
[C-R] Are RECOMMENDED to support the Android Protected Confirmation API .
If device implementations support the Android Protected Confirmation API they:
[C-3-1] MUST report true for the ConfirmationPrompt.isSupported() API.
[C-3-2] MUST ensure that secure hardware takes full control of display in such a way that
Android OS cannot block it without detection by the secure hardware.
[C-3-3] MUST ensure that secure hardware takes full control of the touch screen.

Outstanding help and details, as always!  EE!