## 2 Related Works and State of the Art Review
### Using Encryption on Android  
According to [PERSON] and [PERSON] [33], Google has made available since version 3.0 (Honeycomb) of Android, the Full-Disk encryption (FDE) encryption model, which allows encrypting the _/data_ partition, also called \"user data\". After turning on the device, all data in the _/data_ partition are inaccessible until the user provides authentication credentials. Even using such advances, this has not prevented attacks such as _Evil Maid Attack_ and _Cold Boot_ from succeeding against FDE. From a security and forensic perspective, there are still other drawbacks arising from the use of the FDE. For example, after rebooting, several critical functions of the device cannot be used without user interaction; as an example, we can mention the inability to receive calls after an unexpected restart.  
Yet, according to [PERSON] and [PERSON] [33], File-Based Encryption (FBE) was introduced to overcome this problem as part of the launch of Android 7.0 (Nougat). FBE protects user data by encrypting each file with a unique key, which consists of a hardware key with the user's input (alphanumeric password, PIN, etc.) associated with the Secure Boot protection (Direct Boot). Nevertheless, it also has the convenience of not suffering limitations, correcting the mentioned flaw of the FDE, besides allowing a more refined control of what is encrypted.  
Direct Boot can be set during the initial setup and while specifying the lock screen password. When the secure boot option is enabled, and the user informs their password, the data partition is mounted and decrypted during initialization, and some applications can start and access their data, even if the screen is not unlocked. The credential request occurs before most Android services and applications are allowed to start. The credential is required to generate the actual encryption key.  
Some cases of apps that run in secure boot mode include apps with scheduled notifications (e.g., alarm clock, SMS) and that provide accessibility services, such as Talkback. According to [PERSON] [34], this security mechanism can be circumvented.  
On devices manufactured by Samsung, FBE encryption is present only on Samsung Galaxy devices with Android 9.0 or higher, or with Knox 3.3 or higher. In the others, the encryption is still FDE [35].  
According to [PERSON] et al. [36], the coexistence of critical and non-critical applications is becoming usual on mobile devices. Critical applications must be run separately in the Trusted Execution Environment (TEE) so that the code and associated data can be protected against malicious applications.  
So as to [PERSON] et al. [37], the Trusted Execution Environment (TEE) was created to improve security within the SoC based on the ARM architecture. It offers a compromise between the functionality of the Rich Operating System (Rich OS), such as Android, and the safety of a Secure Element (SE). ARM TrustZone separates SoC between two environments, one considered secure and the other not-as-secure.  
The keys are derived from the information stored in the TEE, as well as the user credentials (PIN, password, etc.) used to unlock the phone. If file-based encryption is used, the phone can initialize and access data stored in the device's specific encrypted area, protected with hardware keys. Most of the information, however, is stored in the encrypted area with various credentials. This area is protected with keys based on the user's credentials.  
Thus, an acquisition made through the software of a Box, either by ISP or by Chip-Off, will not bring satisfactory results, as the device is turned off and, consequently, encrypted.