Please enable JavaScript.

Coggle requires JavaScript to display documents.

AndroidSecOverview, PKI, Analyse - Coggle Diagram

- - - - A usage control scheme to allow key usage to be limited, to mitigate the risk of security compromise due to misuse of keys
      - An access control scheme to enable restriction of keys to specified users, clients, and a defined time range
  - - - provides public key certificates that contain a detailed description of the key and its access controls, to make the key's existence in secure hardware and its configuration remotely verifiable.
    - - binds keys to operating system and patch level version. This ensures that an attacker who discovers a weakness in an old version of system or TEE software cannot roll a device back to the vulnerable version and use keys created with the newer version. In addition, when a key with a given version and patch level is used on a device that has been upgraded to a newer version or patch level, the key is upgraded before it can be used, and the previous version of the key invalidated. As the device is upgraded, the keys "ratchet" forward along with the device, but any reversion of the device to a previous release causes the keys to be unusable.
- - - - File-based encryption enables a new feature introduced in Android 7.0 called Direct Boot. Direct Boot allows encrypted devices to boot straight to the lock screen.
        Previously, on encrypted devices using full-disk encryption (FDE), users needed to provide credentials before any data could be accessed, preventing the phone from performing all but the most basic of operations. For example, alarms could not operate, accessibility services were unavailable, and phones could not receive calls but were limited to only basic emergency dialer operations.
      - On an FBE-enabled device, each user of the device has two storage locations available to applications:
        This separation makes work profiles more secure because it allows more than one user to be protected at a time as the encryption is no longer based solely on a boot time password.
        
        Credential Encrypted (CE) storage, which is the default storage location and only available after the user has unlocked the device.
        
        Device Encrypted (DE) storage, which is a storage location available both during Direct Boot mode and after the user has unlocked the device.
    - - To use the AOSP implementation of FBE securely, a device needs to meet the following dependencies:
        
        Kernel Support for Ext4 encryption or F2FS encryption.
        
        Keymaster Support > with a HAL version 1.0 or 2.0. There is no support for Keymaster 0.3 as that does not provide that necessary capabilities or assure sufficient protection for encryption keys.
        
        Hardware Root of Trust and Verified Boot > bound to the keymaster initialisation is required to ensure that Device Encryption credentials are not accessible by an unauthorized operating system.
        
        Keymaster/Keystore and Gatekeeper > must be implemented in a Trusted Execution Environment (TEE) to provide protection for the DE keys so that an unauthorized OS (custom OS flashed onto the device) cannot simply request the DE keys.
    - - Internal storage
      - Adoptable storage
      - Enabling FBE on a device requires enabling it on the internal storage (userdata). This also automatically enables FBE on adoptable storage; however, the encryption format on adoptable storage may be overridden if necessary.
    - - Making applications Direct Boot aware
        To facilitate rapid migration of system apps, there are two new attributes that can be set at the application level. The defaultToDeviceProtectedStorage attribute is available only to system apps. The directBootAware attribute is available to all.
      - Supporting multiple users
        Each user in a multi-user environment gets a separate encryption key. Every user gets two keys: a DE and a CE key. User 0 must log into the device first as it is a special user. This is pertinent for Device Administration uses.
  - - - Created fast encryption, which only encrypts used blocks on the data partition to avoid first boot taking a long time. Only ext4 and f2fs filesystems currently support fast encryption.
      - Added the forceencrypt fstab flag to encrypt on first boot.
      - Added support for patterns and encryption without a password.
      - Added hardware-backed storage of the encryption key using Trusted Execution Environment’s (TEE) signing capability (such as in a TrustZone). See Storing the encrypted key for more details.
    - - Android full-disk encryption is based on dm-crypt, which is a kernel feature that works at the block device layer. Because of this, encryption works with Embedded MultiMediaCard (eMMC) and similar flash devices that present themselves to the kernel as block devices. Encryption is not possible with YAFFS, which talks directly to a raw NAND flash chip.
      - Upon first boot, the device creates a randomly generated 128-bit master key and then hashes it with a default password and stored salt. The default password is: "default_password" However, the resultant hash is also signed through a TEE (such as TrustZone), which uses a hash of the signature to encrypt the master key.
      - enc states
        default
        PIN
        password
        pattern
- - - - Attest to the user's presence and/or successful authentication. Android supports Gatekeeper for PIN/pattern/password authentication and Fingerprint for fingerprint authentication. Devices that ship with Android 9 and higher can use BiometricPrompt as a single integration point for fingerprint and additional biometrics. These components communicate their authentication state with the keystore service through an authenticated channel. (The Android Keystore system at the framework level is also backed by the keystore service.)
    - - Stores cryptographic keys and provides standard crypto routines on top of those keys. Android supports a hardware-backed Keystore and Keymaster for cryptographic services, including hardware-backed cryptography for key storage that might include a Trusted Execution Environment (TEE) or Secure Element (SE), such as Strongbox.
  - - - A user provides an authentication method and the associated service makes a request to the associated daemon. (gatekeeperd/fingerprintd)
      - The daemon sends data to its counterpart, which generates an AuthToken(AT)
      - The daemon receives a signed AuthToken and passes it to the keystore service through an extension to the keystore service's Binder interface. (gatekeeperd also notifies the keystore service when the device is relocked and when the device password changes.)
      - The keystore service passes the AuthTokens to Keymaster and verifies them using the key shared with the Gatekeeper and supported biometric TEE component. Keymaster trusts the timestamp in the token as the last authentication time and bases a key release decision (to allow an app to use the key) on the timestamp.
- - - - The device state indicates how freely software can be flashed to a device and whether verification is enforced. Device states are LOCKED and UNLOCKED. LOCKED devices prevent you from flashing new software to the device, whereas UNLOCKED devices allow modification.
      - When a device powers on, the bootloader first checks if a device is LOCKED or UNLOCKED. If a device is UNLOCKED, the bootloader shows the user a warning and then proceeds to boot even if the loaded OS isn't signed by the root of trust.
      - If the device is LOCKED, the bootloader goes through the steps in Verifying Boot to verify the device's software. LOCKED devices boot only if the loaded OS is properly signed by the root of trust. For more details, see The boot flow.
- - - - If your app needs to share files with another app, use a content provider. Content providers share data with the proper granularity and without the many downsides of world-accessible UNIX permissions (for details, refer to Content provider basics).
      - If your app has files that genuinely should be accessible to the world (such as photos), they must be media-specific (photos, videos, and audio files only) and stored using the MediaStore class. (For more details on how to add a media item, see Access media files from shared storage.)
- - - - APK signing has been a part of Android from the beginning. It is based on signed JAR. For details on using this scheme, see the Android Studio documentation on Signing your app
      - v1 signatures do not protect some parts of the APK, such as ZIP metadata. The APK verifier needs to process lots of untrusted (not yet verified) data structures and then discard data not covered by the signatures. This offers a sizeable attack surface. Moreover, the APK verifier must uncompress all compressed entries, consuming more time and memory. To address these issues, Android 7.0 introduced APK Signature Scheme v2.
    - - Devices running Android 7.0 and later support APK signature scheme v2 (v2 scheme) and later. (v2 scheme was updated to v3 in Android 9 to include additional information in the signing block, but otherwise works the same.) The contents of the APK are hashed and signed, then the resulting APK Signing Block is inserted into the APK. For details on applying the v2+ scheme to an app, see APK Signature Scheme v2.
- - - - ● Dynamic Taint Analysis et Method hooking
      - ● Requiert une version Android modifiée
      - ● Patche la Dalvik et le core system
      - Analyse:
        
        ● Analyse du trafique arrivant/partant
        
        ● Opérations de lecture/écriture de fichiers
        
        ● Envoi de SMS et appels téléphoniques
        
        ● Opérations de chiffrement réalisées
    - - Principe
        
        Injecter du code dans les processus
        
        Intercepter les appels de fonction
        
        Traquer les processus
      - Caractéristqiues:
        
        ● S’attacher à un processus
        
        ● Appel de fonctions
        
        ● Modification des arguments de fonctions
        
        ● Inspection et modification de la mémoire
- - - - – Noeuds = Bloques d’instruction
      - – arcs = flux possibles entre noeuds
  - - - – Source = Localisation utilisateur, carnet d’adresses , caméra
      - – Puits = Internet, SMS, Bluetooth,
      - – Vérifier s’il existe un flux de données entre sources et puits.
    - - – Données sensibles accessibles via méthodes de l’API (Localisation)
        – Des centaines de sources et puits possibles
- - - - Gradle is the official compilation tool of Android, and it is also an open source project on GitHub. As can be seen from the update log of gradle, the current project is still updated very frequently, and there are basically new versions every one or two months. For gradle, I feel the most painful is the preparation of gradle plugin. The main reason is that there is no perfect document in this aspect for gradle, so generally, only the method of source code or breakpoint debugging can be relied on.
    - - From source code to bytecode
        You will need JDK (Java Developer Kit) to compile the Java code of your application.
        Your code and precompiled classes from runtime and custom libraries are compiled first by ‘Javac’ (JIT Compiler/ Standard Java Compiler).
        The Javac outputs a set of Java bytecode files. So far this looks like any Java compiler process but the next compilation step makes the compilation process unique to Android.
      - From minimized bytecode to dex code
        The next step is to take the output files from step number 2 and to turn those files into dex bytecode - Dalvik EXecutable(.DEX).
        The DEX bytecode is a format that is optimized for Android and which can be executed by the older DALVIK runtime or the newer ART runtime.
      - Execution of Machine Code
        The device's runtime read these dex files (output of step number 3) (DEX file + non-Java libraries + zipped resources + Debug or releaseKeystore) and recompile some of the files to machine code for the fastest possible execution.
        On DALVIK this step happens as the app runs using Just-In-Time or JIT architecture.
        On the newer ART, the recompilation (or translation to machine code) happens when the app is first installed, meaning that the app can run faster when the user runs it on his/her device.
        And that's how your Java code turns into something that runs on Android. It starts with Java and after a couple of steps, it is transformed into something which the Android runtime can read and execute.
    - - clang is a C, C++, and Objective-C compiler which encompasses preprocessing, parsing, optimization, code generation, assembly, and linking. Depending on which high-level mode setting is passed, Clang will stop before doing a full link. While Clang is highly integrated, it is important to understand the stages of compilation, to understand how to invoke it. These stages are:
      - Driver
        
        The clang executable is actually a small driver which controls the overall execution of other tools such as the compiler, assembler and linker. Typically you do not need to interact with the driver, but you transparently use it to run the other tools.
      - Preprocessing
        
        This stage handles tokenization of the input source file, macro expansion, #include expansion and handling of other preprocessor directives. The output of this stage is typically called a “.i” (for C), “.ii” (for C++), “.mi” (for Objective-C), or “.mii” (for Objective-C++) file.
      - Parsing and Semantic Analysis
        
        This stage parses the input file, translating preprocessor tokens into a parse tree. Once in the form of a parse tree, it applies semantic analysis to compute types for expressions as well and determine whether the code is well formed. This stage is responsible for generating most of the compiler warnings as well as parse errors. The output of this stage is an “Abstract Syntax Tree” (AST).
      - Code Generation and Optimization
        
        This stage translates an AST into low-level intermediate code (known as “LLVM IR”) and ultimately to machine code. This phase is responsible for optimizing the generated code and handling target-specific code generation. The output of this stage is typically called a “.s” file or “assembly” file.
        
        Clang also supports the use of an integrated assembler, in which the code generator produces object files directly. This avoids the overhead of generating the “.s” file and of calling the target assembler.
      - Assembler
        
        This stage runs the target assembler to translate the output of the compiler into a target object file. The output of this stage is typically called a “.o” file or “object” file.
      - Linker
        
        This stage runs the target linker to merge multiple object files into an executable or dynamic library. The output of this stage is typically called an “a.out”, “.dylib” or “.so” file.
- - - - ● apktool - pour automatiser de nombreuses phase de reverse-engineering et d’analyse statique d’APK pour applications Android.
        
        apktool d -o app - release - apktool app - release . apk
        
        apktool.yml: Un fichier de méta-data décrivant des propriétés de l’application
        
        AndroidManifest.xml: Utilisé par Android pour déterminer comment lancer l’application, configurer l’environnement et demnder des permissions.
        
        res/: ressources packagées pour l’applciation: icônes, HTML
        
        smali/: Le code désassemblé Smali pour chaque classe de l’APK à partir de classes.dex
        
        unknown/: Les fichiers non supportés par apktool mais inclus d’ans l’APK
        
        L’outil dex2jar est utile pour convertir entre formats DEX and JAR.
        
        d2j - dex2jar -o output . jar / mnt / app - release . apk
        
        L’outil apktool a la capacité de reconstruire un APK à partir d’un dossier d’application modifiées et crée par la commande
        
        apktool d ...
      - ● dex2jar - Pour convertir dex file d’un APK en un jar file pour être ensuite analysé par les outils d’analyse JAVA standards
      - ● Anbox - “Android in a Box” pour virtualiser/émuler un matériel et plusieurs OS stacks.
      - ● Android Studio/SDK - permet de développer des applications Android mais aussi d’analyser et de débugguer des applications Android compilées
    - - Generalement un APK est un fichier ZIP basé sur la variant JAR et contenant:
        
        ● META-INF/MANIFEST.MF: peut contenir des paires clé/valeur pour des méta-data spécifiques à Android
        
        ● META-INF/: d’autres fichier (par exemple .version) classes.dex, classes[1-9].dex: des classes Android compilées et groupées
        
        ● *.properties: pour le stockage des paramètres de configuration des applications
        
        ● res/**: Différentes ressources statiques qui pourront être utilisées à l’exécution par l’application
        
        ● resources.arsc: Similaire aux classes.dex pour les ressources non exécutables