The researcher demonstrates that Honda's 10th-gen Civic infotainment accepts OTA updates signed with the AOSP testkey — a private key checked into a public Git repo with explicit warnings against production use. They walk through extracting the recovery image, verifying signatures with apksigner against the public AOSP certificate, and constructing an 'evil valet' attack where any malicious package signed with the downloadable testkey is accepted as legitimate Honda firmware.
By submitting this research to Hacker News where it gained 261 points, librick amplifies the position that this is a noteworthy security failure affecting millions of vehicles. The framing emphasizes that this isn't a sophisticated exploit but a basic code-signing misconfiguration that asks 'is this signed?' rather than 'is this signed by Honda?'
The editorial frames Honda as 'not victims of a sophisticated attack' but as having shipped the equivalent of an SSH key labeled '# example only.' AOSP test keys exist explicitly so developers can produce bootable images without signing infrastructure, and every piece of Google documentation warns to replace them before shipping — the AOSP build system itself prints a warning. The closest precedent cited is the 2022 Samsung platform-key leak, but this case is arguably worse because no leak occur
A researcher publishing at juniperspring.org pulled apart the OTA update mechanism on a 10th-generation Honda Civic infotainment system and found that updates are signed with the AOSP `testkey` — the private key that ships, in the clear, inside the public Android Open Source Project source tree at `build/target/product/security/testkey.pk8`. The key isn't leaked, lost, or reverse-engineered. It's checked into a public Git repo with a README that says, in capital letters, not to use it in production.
The post walks through the entire chain: extract the recovery image, inspect the signature block, run `apksigner` against the public AOSP certificate, and watch it verify cleanly. From there the author demonstrates an "evil valet" attack — a malicious update package, signed with the testkey anyone can download, that the head unit accepts as a legitimate Honda update. No exploit chain. No CVE. Just a code-signing check that asks the wrong question: "is this signed?" rather than "is this signed by Honda?"
The 10th-gen Civic shipped from 2016 through 2021 — millions of vehicles across global markets. The infotainment unit is a fairly standard Android-derived embedded build with CarPlay/Android Auto bridging, Bluetooth pairing, and an OTA flow that pulls signed packages over USB or, in some trims, cellular.
AOSP test keys are the canonical example of a credential that is *intentionally* public. They exist so that developers building AOSP from source can produce a bootable image without setting up a signing infrastructure. Every line of documentation Google has ever written about them says the same thing: replace them before shipping. The AOSP build system itself prints a warning. Vendors who ship test-key-signed builds to production are not victims of a sophisticated attack — they shipped the equivalent of an SSH key with the comment `# example only`.
The closest precedent is the December 2022 Samsung platform-key leak, where signing keys for system-privileged Android apps escaped into the wild and were promptly used to sign malware that ran with full platform permissions. That incident triggered a coordinated disclosure, key rotation across multiple Android OEMs, and a Google-led postmortem. The Honda case is structurally worse: there's nothing to rotate because the keys were never secret. Every Civic running the affected firmware has been shipping with a wide-open signature check since 2016.
The community reaction on Hacker News (261 points) split predictably. One camp argues this is overhyped — physical access to a car is already game over, and the threat model of a malicious valet running a custom OTA inside a five-minute parking window is contrived. The stronger camp points out that physical access isn't the only attack surface: USB-borne update payloads have historically been delivered by infected media (the Jeep Cherokee remote takeover started with a cellular vector, but most modern automotive exploits have started with a USB stick someone plugged in). A signed-update bypass collapses the cost of post-access persistence from "find a kernel bug" to "run `apksigner sign`."
The deeper problem is process. Honda's supplier — almost certainly a tier-one infotainment vendor, not Honda's own engineers — built an Android image, signed it, and shipped it without the most basic vendor-key-replacement step in the AOSP build documentation. Either the vendor's release engineering didn't run the standard `make dist` checks, or someone deliberately disabled signature verification for staging and forgot to re-enable it. Both possibilities indict the entire automotive software supply chain, where Tier-1 suppliers ship binaries that the OEM never independently audits and the regulator never sees.
It's also worth naming the regulatory vacuum. UN ECE R155 (cybersecurity management systems for vehicles) has been in force since July 2024 for new type approvals and requires OEMs to demonstrate signed software update integrity. R155 wouldn't have caught a 2016 Civic, but it does mean any OEM shipping a 2024+ vehicle with this defect is now non-compliant with a binding regulation in 64 countries. The Honda finding is going to be the case study every automotive cybersecurity consultant references for the next decade.
If you ship embedded Android — and far more teams do than realize it, because "embedded Android" now means cars, kiosks, smart TVs, point-of-sale terminals, medical imaging consoles, industrial HMIs, and the increasingly Android-ified payment terminals at gas pumps — audit your signing pipeline this week, not next quarter. The check is mechanical: extract a signed APK or OTA package from a production build, run `apksigner verify --print-certs`, and confirm the SHA-256 of the signing certificate matches a key your team controls, not `61ed377e85d386a8dfee6b864bd85b0bfaa5af81`. That hex string is the AOSP testkey fingerprint. If it shows up in your production artifacts, stop the release.
Beyond the immediate audit, the second-order lesson is that signature verification is necessary but not sufficient — the verifier has to pin the expected signer, not just check that *some* signature exists. This is the same anti-pattern as TLS clients that validate certificate chains but accept any CN, or JWT libraries that accept `alg: none`. The correct check on an OTA update isn't `verifySignature(package)`, it's `verifySignature(package) && signerCert.fingerprint == EXPECTED_HONDA_FINGERPRINT`. If your update flow doesn't pin, it's broken even when the keys *are* private.
For anyone building a hardware product on AOSP, the practical hardening list is short and known: replace all four AOSP test keys (`platform`, `shared`, `media`, `testkey`) with vendor-generated keys held in an HSM; enable `AVB` (Android Verified Boot) with vendor-rooted keys; pin the signer in your update-acceptance code; and run a release-time CI check that fails the build if any artifact verifies against the AOSP public testkey. None of this is new. All of it is in the AOSP documentation. The Civic shipped anyway.
Honda will almost certainly issue a service bulletin and a firmware patch, and the patch itself will need to be the *last* update the testkey can sign — flipping the trust root mid-flight is the hard part, and any attacker with the testkey can race the fix. Expect the next twelve months to surface similar findings across the automotive Tier-1 ecosystem; this researcher's tooling is now public and the marginal cost of checking the next OEM is hours. The interesting question isn't whether Honda gets sued — it's whether R155 enforcement teeth come out, and whether the SBOM-and-signing-attestation discipline that regulated industries (medical, aviation) have lived with for years finally arrives in the consumer-vehicle stack.
Most (if not all) cars on the road are terrible in terms of the security of the infotainment system and other onboard electronics. What makes this even worse is the sensors they have onboard these days; the microphones, cameras, GNSS receivers, wifi and BT radios make them into mobile surveillance p
In one thread people fighting the ever decreasing amount of hw ownership of most devices in our lives and when we have one that is more open, the crowds come to attack that too.The theat model with tech has always been that if an attacker has physical access to the device and time then it's gam
I wish other car makers were as reasonable as Honda here.No "evil valet" with half a brain cell would waste time hacking the head unit if they have physical access to the car. They would simply hide a spying device somewhere in the car.Not to mention that people with Civics are never targe
I’ve heard product managers proudly proclaim their firmware was signed using the corporate internal signing service (good).Of course, the question explicitly being asked (related to internal mandate) was if the firmware was signed — not if the firmware update process actually checked the signature (
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
To update 10th-gen Honda Civics, Honda ships updates on specially-formatted USB drives. They're essentially Android 4.2.2rc1-era recovery packages with some Honda-added version checks (which can be spoofed). The packages are signed with the publicly-known AOSP test key, so with physical access