Case study
802.1x Enterprise Ethernet Authentication for AOSP Devices
Plexteq designed and delivered a complete IEEE 802.1X port-based authentication stack for custom AOSP-based signature terminals, building a dedicated wired supplicant subsystem into the Android platform — HIDL HAL, system service, public API surface, SELinux policy and keystore integration, so that several thousand devices could be deployed onto the client's ClearPass-protected corporate LAN across their UK branch network.
Project Highlights
Industry
Digital Trust Services / Financial Services
Market
United Kingdom
Cooperation
2024-2025,
spanning AOSP 7 -> AOSP 9 -> AOSP 11
Expertise
AOSP Platform Engineering, Android Framework & HAL Development, Network Security, IEEE 802.1X / EAP, SELinux, Embedded Linux, Firmware Integration
Technologies
AOSP 7/9/11, HIDL, JNI, Soong & Make, wpa_supplicant, EAP-PEAP / MSCHAPv2, X.509 / PKCS#8, SELinux, Java, C/C++, Rockchip RK33xx / RK35xx, Aruba ClearPass, FreeRADIUS,
Business Challenge
Our client is a UK-based digital signature and document authentication provider that captures legally binding signatures taken at customer-facing counters. Their service runs on Android terminals deployed across the branch network. These terminals capture ID documents and customer signatures and sit within the client's security perimeter.
That perimeter is at the network edge. The client has IEEE 802.1X port-based network access control (NAC) in place on every access port of their enterprise switching infrastructure. Aruba ClearPass is the RADIUS and policy manager. Any device that fails to authenticate is denied the link.
This is a hard blocker. Android has no wired 802.1X support out of the box. The AOSP EthernetService does provide link management, DHCP, and static IP configuration. However, Android's entire EAP supplicant stack is built solely for the Wi-Fi data path, and no vendor extension or OEM BSP closes that gap. Wi-Fi wasn't an option, as the devices are fixed-installation, wired-only, and the client's security policy required them on the wired network.
A Chinese ODM built the client's hardware and maintained the base firmware across several SoC platforms (Rockchip RK33xx, RK35xx, Amlogic T972 and T982), each having its own kernels, Ethernet PHY drivers, and vendor BSP layers. The ODM and the client's engineering team lacked the platform-level Android expertise to build a supplicant into the OS.
Plexteq was engaged to implement the missing capability at the platform level (802.1X EAP with PEAP/MSCHAPv2 and CA certificate verification on the Ethernet interface) across the specified hardware variants and supported AOSP versions.
Key Challenges
#1. No Wired Supplicant Path in Android
AOSP's entire EAP stack, the wpa_supplicant daemon, its HIDL interface, the enterprise configuration model, the supplicant state machine, and the keystore bridge are hard-wired to the Wi-Fi subsystem. Adding 802.1x to Ethernet meant building a second, parallel supplicant subsystem inside the platform rather than configuring an existing one.
#2. Treble, VINTF and SELinux Constraints
On AOSP 9 and 11, any new HAL must be declared in the VINTF device manifest, matched against the framework compatibility matrix, assigned SELinux HAL attributes and domains, and pass the neverallow assertions enforced at build time. A new HAL cannot simply be dropped into a Treble-compliant build; it must be introduced as a first-class platform component.
#3. Five SoC Platforms, Three AOSP Generations
The same capability had to work on Rockchip RK33xx/RK35xx and Amlogic T972/T982, across AOSP 7, 9 and 11. Those three releases do not merely differ in detail - they represent two complete rewrites of how Android talks to hardware. AOSP 7 is pre-Treble, where the correct integration point is a native library and a JNI bridge. AOSP 9 introduced Treble and HIDL, making that approach non-viable. AOSP 11 modularised the networking stack into Mainline/APEX components with signed API surfaces. Each generation changed not just where the code lives, but also what shape it takes.
#4. Three-Party Delivery Coordination
Engineering was distributed across the client's technical team in the UK, the ODM's firmware team in China, and the Plexteq team in Ukraine. Kernel and PHY-level defects belonged to the ODM, network and RADIUS policy belonged to the client, and the platform layer belonged to Plexteq - with time zones, language, and differing engineering processes spanning all three.
#5. Field Provisioning by Non-Engineers
Installation staff had to configure enterprise credentials, identities, and CA certificates per branch without shell access, ADB, or Android engineering knowledge, and they had to survive reboots and OTA updates.
Solution Delivered
A Dedicated Ethernet Supplicant Subsystem
From an architecture perspective, we decided to build a separate supplicant subsystem rather than extend the existing one. Overloading the existing stack would have coupled Ethernet authentication to the existing supplicant lifecycle, broken CTS expectations, and made future AOSP releases expensive to support.
Plexteq introduced a new HAL interface family - android.hardware.ethernet.supplicant built in wired mode, with its own control sockets, runtime state, and configuration. It is registered as a first-class HAL: declared in the device VINTF manifest, matched against the framework compatibility matrix, and discovered through hwservicemanager exactly as a first-party HAL would be. The result is an Ethernet authentication path that operates entirely independently of the Wi-Fi stack.
Re-Architected Across Three Android Generations
The engagement began on AOSP 7, and the platform changed twice underneath it.
On AOSP 7, pre-Treble, the right integration point was the legacy HAL layer. Plexteq implemented a native Ethernet supplicant library in libhardware_legacy - deliberately modeled on the Wi-Fi library alongside it - that manages the wpa_supplicant lifecycle through Android system properties and drives authentication over the wpa_ctrl socket protocol, exposed to the framework through a purpose-built JNI bridge. Configuration, state, and SELinux labeling all lived in the system partition, as that generation expects.
AOSP 9's arrival with Treble and HIDL made that architecture non-viable: vendor and system partitions were separated, direct native calls across the boundary were prohibited, and every hardware interface had to be a versioned, declared HAL. The subsystem was rebuilt around the HIDL model described above.
AOSP 11 then moved core networking into updatable Mainline modules, requiring the framework layer to be re-packaged again as an APEX with a signed, stable API surface.
The same capability, three times, each time in the idiom the platform required - with the provisioning application and the client's operational workflow kept consistent throughout so that branch staff and the client's network team saw continuity rather than churn.
Framework-Level Enterprise Networking for Ethernet
Two integration points mattered most:
-
Connection sequencing. The Ethernet network factory was reworked so authentication happens before IP provisioning - EAP is driven to completion on link-up, and only then does DHCP or static configuration begin, with clean teardown on authentication failure, link loss or supplicant death.
-
A supportable API surface. Enterprise settings are modelled as a first-class, persistable configuration object carried alongside standard IP settings and exposed through the public EthernetManager API, so the client's own developers can build against it rather than against private internals.
Credentials are never held in plaintext configuration. CA certificates, client certificates and private keys live in the Android Keystore under managed aliases and are resolved at connection time.
Platform Compliance: Treble, SELinux and Mainline
Adding a privileged daemon with network and keystore access to an AOSP build entails careful security setup. Plexteq developed the SELinux policy for the new HAL, with its own security domain, services, file permissions, and capabilities. We also configured a restricted access path to the keystore so the wired supplicant could validate PEAP certificates without exposing sensitive keystore functions.
On AOSP 11, where core networking components moved into updatable Mainline modules, we packaged the solution as a com.android.ethernet APEX, following the architecture of com.android.wifi. This included dependency isolation, stub libraries, VNDK registration, and the required signed API definitions to meet Android's API stability requirements.
The result is more than a patch that compiles on one AOSP version. It is a properly integrated platform feature intended to remain secure, compatible, and maintainable as the client continues updating its Android platform.
On-Site and MDM Provisioning
Plexteq delivered a provisioning application that enables branch installers to configure authenticated 802.1X network connections without engineering support. The application supports enterprise mode, EAP and Phase 2 authentication, user credentials, certificates, and DHCP or static IP settings. Real-time connection status and log access let installers identify failures immediately.
For larger deployments, the application supports automated provisioning through a broadcast-based interface. The client's MDM and factory-imaging tools can deliver network profiles and certificates directly, enabling bulk device configuration without user interaction.
Multi-Vendor Delivery Coordination
Plexteq coordinated integration between the client's UK-based network and security team and the ODM's firmware team in China. We turned network and security logs into reproducible test cases, determined whether failures originated in the kernel, Ethernet hardware, RADIUS policies, or the Android platform, and defined integration requirements for the ODM to include the solution in firmware releases across all five hardware platforms.
Testing used the client's production infrastructure, including Cisco and HP switches with ClearPass for authentication and access policies. We verified successful PEAP/MSCHAPv2 authentication with certificate validation, rejected credentials and quarantine VLAN assignment, re-authentication, recovery from network interruptions and supplicant restarts, and configuration persistence across reboots and OTA updates.
To ensure the solution was not tied to a single vendor, Plexteq also tested it with FreeRADIUS and other RADIUS server implementations. This confirmed interoperability in certificate handling, EAP negotiation, and Phase 2 authentication.
The result: a standards-based 802.1X solution that works across different network security environments, allowing the client to deploy the same platform build at partner sites, across acquired infrastructure, and in future customer environments without modifying the supplicant for each deployment.
Key Results
Security posture
Terminals moved to standard 802.1X authentication, allowing them to connect through secured network ports without MAC-based authentication bypass, or security exceptions.
Operational impact
Branch staff can now provision terminals without engineering support. Non-technical installers follow a guided setup screen, while MDM can push network profiles automatically without user interaction.
Engineering durability
Delivered as a versioned HAL with a declared VINTF interface and an APEX-packaged framework module, complete with signed API definitions.
Business Outcome
As a result of the engagement, the client's Android terminals now authenticate to the corporate network the same way managed Windows laptops do. This lets the client unify security policies across distributed branches, harden the security posture, and reduce maintenance costs. Rather than relying on MAC authentication bypass, open VLANs, or security exceptions, the terminals use IEEE 802.1X authentication on secured network ports.
The provisioning application simplified Ethernet 802.1X authentication configuration across the distributed organization. Onsite staff can now configure devices through a UI without engineering support. Alternatively, MDM can centrally manage network profiles.
Plexteq team implemented the solution as a native AOSP platform feature, including a versioned HAL, VINTF interface, SELinux policies, and an APEX-packaged framework module. This enabled seamless evolution through the client's AOSP 7, 9, and 11 upgrades without repeated rewrites. Plexteq also provided integration-ready patches for the ODM to apply consistently across all five hardware platforms.
What the engagement delivered:
-
Enterprise-grade wired authentication: IEEE 802.1X with EAP-PEAP, MSCHAPv2 Phase 2 authentication, and CA certificate authentication on AOSP devices, a function not available out of the box in AOSP.
-
Multi-platform support: Deployment on Rockchip RK33xx, RK35xx, and Amlogic T972 and T982, across AOSP 7, 9, and 11. The architecture evolved from a pre-Treble native/JNI implementation to a HIDL HAL and ultimately a Mainline APEX module.
-
Simplified deployment: Guided on-site provisioning for branch staff and automated configuration through MDM.
-
Production-validated interoperability: End-to-end testing with Cisco and HP switches, Aruba ClearPass, and FreeRADIUS.
Get in touch to discuss your software vision with industry experts
What our customers say
"
It's impressive how they fix difficult issues, and the wide competence in the company. This makes the days much more easy for the product owner when you have a team you can trust on to deliver was is specified even if there can be some hard bumps on the road to a finished product.
