Introduction: Securing the Internet of Things

The proliferation of IoT devices has brought unprecedented convenience, but also significant security challenges. Android Things, Google’s embedded operating system built on Android, offers a robust platform for developing connected devices. However, default configurations are often insufficient for the stringent security requirements of many industrial, medical, or consumer applications. Building a custom Android Things image allows developers to tailor the OS to specific hardware and application needs, crucially enabling the integration of advanced security features from the ground up. This article delves into the methodologies for implementing such features, ensuring a “secure by design” approach for your custom Android Things deployments.

The Foundation of Trust: Secure Boot and Verified Boot

At the heart of a secure embedded system lies a trusted boot process. Android Things leverages the Android Verified Boot (AVB) mechanism to ensure that the entire software stack, from the bootloader to the system image, has not been tampered with. This process cryptographically verifies each stage of the boot sequence before execution.

Understanding Android Verified Boot (AVB)

AVB operates on the principle of a Root of Trust, typically a hardware-backed immutable key burned into the device during manufacturing. This key is used to verify the bootloader, which in turn verifies the kernel, and so on, up to the system partition. Any unauthorized modification detected during this chain of trust will prevent the device from booting or trigger a recovery mode, safeguarding against malicious firmware injections.

Implementing Secure Boot in Custom Images

To enable AVB for your custom Android Things image, you need to sign your bootloader and system partitions with your own keys. This typically involves:

1. Generating Signing Keys: Create a set of cryptographic keys (RSA recommended) for your project.
2. Configuring Build System: Integrate these keys into your Android Things build system (e.g., AOSP source tree). In your device’s BoardConfig.mk, you might specify:

   BOARD_AVB_ENABLE := trueBOARD_AVB_ALGORITHM := SHA256_RSA4096BOARD_AVB_KEY_PATH := build/make/target/product/security/avb.pemBOARD_AVB_ROLLBACK_INDEX := 1

3. Signing Images: During the build process, the images (boot.img, system.img, etc.) will be signed with your provided keys. When flashing your custom image, the device’s bootloader will use its pre-programmed public key to verify these signatures.

Furthermore, Android Things supports A/B (seamless) updates, which significantly enhance security by allowing updates to be applied to an inactive partition while the device is running, then swapped upon reboot. This minimizes downtime and provides a fallback in case of a failed update, further bolstering the integrity of the system.

Hardware-Backed Security: Trusted Execution Environment (TEE)

A Trusted Execution Environment (TEE) provides an isolated, secure environment on the main processor, separate from the rich execution environment (REE) where the Android OS runs. The TEE is designed to protect sensitive operations, such as cryptographic key management and secure authentication, even if the main OS is compromised.

Leveraging TEE with Android Keymaster HAL

Android Things utilizes the Android Keymaster Hardware Abstraction Layer (HAL) to interface with the TEE. Keymaster provides strong security guarantees for cryptographic keys:

• Hardware-backed Key Storage: Keys generated and stored within the TEE are never exposed to the Android OS.
• Key Attestation: Allows verification that a key resides in secure hardware and possesses specific properties (e.g., usage restrictions, security level).
• Anti-rollback Protection: Prevents unauthorized downgrade of key security properties.

When developing applications for Android Things that handle sensitive data, always prefer using the Android KeyStore API, which leverages the underlying Keymaster HAL and TEE where available. This ensures your keys are protected by the strongest available hardware security.

// Example (conceptual) of generating a hardware-backed keytry {    KeyGenParameterSpec spec = new KeyGenParameterSpec.Builder(            "my_secure_key",            KeyProperties.PURPOSE_ENCRYPT | KeyProperties.PURPOSE_DECRYPT)            .setBlockModes(KeyProperties.BLOCK_MODE_GCM)            .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)            .setKeySize(256)            .setIsUserAuthenticationRequired(true)            .setUserAuthenticationValidityDurationSeconds(300)            .build();    KeyPairGenerator keyPairGenerator = KeyPairGenerator.getInstance(            KeyProperties.KEY_ALGORITHM_AES, "AndroidKeyStore");    keyPairGenerator.initialize(spec);    keyPairGenerator.generateKeyPair();} catch (Exception e) {    // Handle exceptions}

Data at Rest: Full Disk Encryption (FDE) and File-Based Encryption (FBE)

Protecting data stored on the device's flash memory is paramount, especially for devices that might be physically compromised. Android Things supports both Full Disk Encryption (FDE) and File-Based Encryption (FBE).

Enabling Encryption During Image Build

For custom images, you can configure encryption settings during the build process. FDE encrypts the entire user data partition, typically requiring a boot-time password or unlock gesture. FBE, introduced in Android 7.0, allows individual files to be encrypted, enabling finer-grained control and support for direct boot.

To enable FDE in your build, ensure your device configuration supports it. For FBE, you might add these to your device.mk or BoardConfig.mk:

PRODUCT_PROPERTY_OVERRIDES += oot_img_header_version := 2
o.crypto.type=file
o.crypto.state=encrypted
o.crypto.volume_key.method=inline_encryption

After building and flashing an encrypted image, the device will prompt for a password or require a secure unlock method before accessing user data. This is crucial for safeguarding sensitive configurations, logs, and application data.

Fine-Grained Access Control: SELinux Policies

SELinux (Security-Enhanced Linux) provides mandatory access control (MAC) over all processes, files, and resources in the Android system. It operates on a principle of least privilege, meaning that everything is denied unless explicitly permitted by a policy. While Android Things comes with robust default SELinux policies, custom hardware and specific application requirements often necessitate policy adjustments.

Customizing SELinux Policies

When creating a custom Android Things image, you might encounter situations where a peripheral device, a custom driver, or a unique application feature requires permissions not covered by the default policies. Modifying SELinux involves:

1. Understanding Audit Logs: Use adb logcat | grep "avc:" or inspect dmesg to identify denied operations (avc: denied messages).
2. Writing New Rules: Create .te (type enforcement) files for your custom domains or types. For example, to allow a specific service to access a custom hardware device:

   # In a custom .te file (e.g., custom_hal.te)type custom_hal_service, domain;type custom_hal_device, dev_type;init_daemon_domain(custom_hal_service)allow custom_hal_service custom_hal_device:chr_file { rw_file_perms };

3. Compiling and Integrating: Compile your new policies using the SELinux policy language (SEPOL) tools and integrate them into your device's sepolicy directory in the AOSP source tree.
4. Testing: Thoroughly test your device to ensure the new policies grant necessary access without introducing undue vulnerabilities.

Customizing SELinux requires careful consideration to avoid weakening the system's overall security posture. Always grant the minimum necessary permissions.

Application-Level Security: KeyStore and Network Best Practices

While platform-level security is vital, application-level practices complete the secure ecosystem. Android Things applications must also adhere to best security practices.

Secure Credential Storage with Android KeyStore

As mentioned with TEEs, the Android KeyStore System allows applications to store cryptographic keys in a secure container. Using KeyStore is critical for protecting user credentials, API keys, and other sensitive information that an application might need. Always prefer KeyStore over storing keys directly in application preferences or hardcoding them.

Robust Network Security

IoT devices are inherently network-connected, making network security a top priority:

• TLS/SSL Everywhere: All communication with backend services, cloud platforms, or other devices should use TLS/SSL with strong cipher suites.
• Certificate Pinning: To mitigate Man-in-the-Middle (MITM) attacks, implement certificate pinning in your applications. This ensures that your device only communicates with servers presenting a specific, known certificate.

  // Conceptual example for OkHttp certificate pinningOkHttpClient client = new OkHttpClient.Builder()    .certificatePinner(new CertificatePinner.Builder()        .add("your.backend.com", "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=")        .build())    .build();

• Firewall Rules: Configure device-level firewall rules to restrict outbound and inbound connections to only essential services and ports.

Conclusion

Building secure Android Things devices requires a multi-layered approach, starting from the foundational boot process up to application-level practices. By meticulously implementing Secure Boot, leveraging the Trusted Execution Environment, enabling disk encryption, fine-tuning SELinux policies, and adhering to robust application security standards, developers can create custom Android Things images that are truly "secure by design." This comprehensive strategy is not just a feature, but a necessity for ensuring the integrity, confidentiality, and reliability of IoT deployments in an increasingly interconnected world.