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 digital signature and document authentication provider whose business depends on capturing legally binding signatures at customer-facing counters. Their service is delivered on purpose-built Android terminals installed across branch locations nationwide - devices that handle identity documents and signature artefacts and therefore sit squarely inside the client's regulated security perimeter.
That perimeter is enforced at the network edge. The client protects every access port on their Cisco and HP Aruba switching infrastructure with IEEE 802.1X port-based network access control, backed by Aruba ClearPass as the RADIUS and policy manager. A device that cannot authenticate to ClearPass is not merely restricted, it is placed on a quarantine VLAN or denied link entirely.
This created a hard blocker. Android has no wired 802.1X support. The AOSP EthernetService provides link management, DHCP and static IP configuration, but the entire EAP supplicant stack in Android - wpa_supplicant, the supplicant HIDL HAL, WifiEnterpriseConfig, keystore-backed certificate handling, supplicant state tracking - is built exclusively for the Wi-Fi data path. There is no vendor extension, no configuration flag and no OEM BSP that closes this gap. Wi-Fi was not an option: the terminals are fixed-installation, wired-only devices, and the client's security policy required them on the wired network.
The client's hardware was manufactured and its base firmware maintained by a Chinese ODM, working across five distinct SoC platforms - Rockchip RK3399, RK3566 and RK3568, and Amlogic T972 and T982 - with different kernels, Ethernet PHY drivers and vendor BSP layers. Neither the ODM nor the client's own engineering team had platform-level Android expertise deep enough to build a supplicant subsystem into the OS.
Plexteq was engaged to implement the missing capability at the platform level: 802.1X EAP with PEAP/MSCHAPv2 and CA certificate validation on the Ethernet interface, exposed through a supportable Android API, deployable across every hardware variant and every AOSP generation in the client's fleet, and provisionable by non-engineering branch staff on site.
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 - is hard-wired to the Wi-Fi subsystem and the wlan0 data path. 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 and by CTS/VTS. A new HAL cannot simply be dropped into a Treble-compliant build — it has to be introduced as a first-class platform component.
#3. Five SoC Platforms, Three AOSP Generations
The same capability had to work on Rockchip RK3399/RK3566/RK3568 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 what shape it has to take.
#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 Plexteq. 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 process spanning all three.
#5. Field Provisioning by Non-Engineers
Enterprise credentials, identities and CA certificates had to be configured per branch by installation staff without shell access, ADB or Android engineering knowledge - and had to survive reboots and OTA updates.
Solution Delivered
A Dedicated Ethernet Supplicant Subsystem
The decision that shaped the entire engagement was to build a second, independent supplicant subsystem rather than extend the Wi-Fi one. Overloading the existing stack would have coupled Ethernet authentication to Wi-Fi lifecycle, broken CTS expectations and made every future AOSP upgrade a rewrite.
Plexteq introduced a new HAL interface family - android.hardware.ethernet.supplicant, versioned 1.0 through 1.3 to mirror the platform's own supplicant contract - served by a separate wpa_supplicant instance 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 starts, fails and recovers entirely independently of the Wi-Fi stack - essential on devices where Ethernet is the only network.
Re-Architected Across Three Android Generations
The engagement began on AOSP 7, and the platform changed underneath it twice.
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 modelled 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 labelling 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
On top of the HAL, Plexteq implemented the Java framework layer that AOSP provides for Wi-Fi but not for Ethernet - around 33k platform SLOC covering the enterprise configuration model, the HIDL client layer, supplicant event handling and state tracking, and keystore-backed credential management.
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
Introducing a privileged native daemon with network and keystore access into a modern AOSP build is as much a security-policy exercise as a coding one. Plexteq authored the full SELinux policy set for the new HAL - its own domain, HAL attributes, service contexts and file labelling, granting only the capabilities the wired supplicant requires, and opening a narrowly scoped path from the supplicant to the keystore so PEAP CA validation works without broadening keystore access. Because AOSP validates policy against historical snapshots, the same definitions were backported across five prior policy versions to keep CTS and VTS clean.
On AOSP 11, where core networking moved into updatable Mainline modules, the stack was packaged as a com.android.ethernet APEX paralleling com.android.wifi - with dependency namespacing, stub libraries, VNDK registration and the complete signed API files required to pass the platform's API-stability gates.
This is the difference between a patch that compiles on one tree and a platform feature that survives the client's ongoing AOSP maintenance.
On-Site and MDM Provisioning
Plexteq delivered a platform-signed, privileged provisioning application that gives branch installers a guided path to a working authenticated connection with no engineering involvement: enterprise mode selection, EAP and Phase 2 method pickers constrained to valid combinations, identity and credential entry, certificate selection, and DHCP or static IP configuration - with live connection status so failures surface immediately rather than silently.
Alongside the interactive UI, a broadcast-driven provisioning interface accepts configuration and certificate material from the client's MDM and factory-imaging tooling, allowing enterprise profiles to be pushed at scale with no user interaction.
Multi-Vendor Delivery Coordination
Plexteq acted as the technical integration point between the client's network and security team in the UK and the ODM's firmware team in China — translating ClearPass and switch-side observations into precise reproduction cases, isolating whether a failure belonged to the kernel and Ethernet PHY layer, the RADIUS policy, or the platform stack, and specifying the integration contract so the ODM could fold the work into their per-SoC firmware releases across all five hardware platforms.
Verification ran against the client's production infrastructure - Cisco and HP Aruba access switches with Aruba ClearPass as RADIUS and policy manager, covering successful PEAP/MSCHAPv2 authentication with CA validation, credential rejection and quarantine VLAN behaviour, re-authentication, link-flap and supplicant-restart recovery, and persistence across reboot and OTA update.
Because the supplicant implements standard IEEE 802.1X and EAP rather than anything vendor-specific, Plexteq deliberately validated beyond the client's own estate. The stack was tested against FreeRADIUS and other RADIUS server implementations in addition to ClearPass, confirming that certificate handling, EAP negotiation and Phase 2 behaviour are interoperable rather than tuned to one policy engine. This matters commercially as well as technically: it means the same platform build can be deployed into partner sites, acquired estates or future customer environments running a different NAC stack, without returning to the supplicant layer.
Key Results
Security posture
Terminals moved from network exceptions to standard 802.1X supplicants on standard authenticated ports - no MAC authentication bypass, no dedicated open VLAN, no documented security waiver
Operational impact
Branch installation no longer requires an engineer with ADB or shell access - non-technical staff provision a terminal through a guided screen, or receive a profile pushed silently by MDM
Engineering durability
Shipped as a versioned HAL, declared VINTF interface and APEX-packaged framework module with a signed API surface - carried forward across the client's AOSP upgrade path rather than rewritten each time
Business Outcome
The client's terminals authenticate to their corporate network the same way a managed Windows laptop does - using the same ClearPass policies, the same enterprise PKI, the same switch configuration and the same operational runbooks. From the network team's perspective, an Android signature terminal stopped being an exception requiring MAC bypass, a dedicated open VLAN or a documented security waiver, and became a standard 802.1X supplicant on a standard authenticated port.
Operationally, the provisioning application removed the deployment bottleneck. Branch installation no longer required an engineer with ADB access; staff configure the terminal on site through a guided screen, or receive a pre-provisioned profile pushed by MDM, and see connection status confirmed immediately.
Because the work was implemented as a proper platform feature - versioned HAL, declared VINTF interface, complete SELinux policy, APEX-packaged framework module with signed API surface - it carried forward through the client's AOSP 7 → 9 → 11 upgrade path rather than being rewritten each time, and could be handed to the ODM as a set of integrable patches applied consistently across all five hardware platforms.
What the engagement delivered:
-
IEEE 802.1X EAP-PEAP with MSCHAPv2 Phase 2 authentication and CA certificate validation on the wired interface of AOSP devices - a capability that does not exist in AOSP
-
A supportable public API surface (EthernetEnterpriseConfig, extended EthernetManager and IEthernetManager) rather than a private hack, so the client's own developers can build on it
-
Treble, VINTF, VNDK and SELinux compliance, including backported policy across five historical prebuilts/api snapshots, keeping CTS and VTS clean
-
Deployment across Rockchip RK3399, RK3566, RK3568 and Amlogic T972, T982 hardware, and across AOSP 7, 9 and 11 - re-architected from a pre-Treble native/JNI design to a HIDL HAL and finally to a Mainline APEX module as the platform evolved
-
On-site and MDM-driven provisioning workflows usable by non-technical branch staff
-
Validated end-to-end against production Cisco and HP Aruba switching with Aruba ClearPass as RADIUS and policy manager, and interoperability-tested against FreeRADIUS and other RADIUS implementations for deployment beyond the original environment