A developer says he was able to run his own software on his car infotainment hardware after discovering the vehicle’s manufacturer had secured its system using keys that were not only publicly known but had been lifted from programming examples.
Daniel Feldman, a Minneapolis, Minnesota-based software engineer, wanted to modify the in-vehicle infotainment (IVI) system in his 2021 Hyundai Ioniq SEL.
To do so, he would have to figure out how to connect to the device and bypass its security.
After trying to figure out how to customize firmware updates for the IVI’s D-Audio2 system, made by the car company’s mobility platform subsidiary Hyundai Mobis, and have them accepted by the IVI, Feldman found an unexpected way – through Google.
The IVI accepts firmware updates in the form of password-protected ZIP archives. Feldman downloaded an update ZIP from Hyundai’s website and was able to bypass the simple password protection on the archive to access its contents, which included encrypted firmware images for various parts of the IVI.
His goal then became creating his own firmware images and encrypt them in a way within a ZIP that the car would accept, install, and run, thus allowing him to take control of the hardware from his own supplied code.
As luck would have it, Feldman found on Mobis’s website a Linux setup script that created a suitable ZIP file for performing a system update.
Turns out the encryption key in that script is the first AES 128-bit CBC example key listed in a NIST document
The script included the necessary ZIP password for the system update archives, along with an AES symmetric Cipher-Block-Chaining (CBC) encryption key (a single key rather than an RSA asymmetric public/private key pair) and the IV (initialization vector) value to encrypt the firmware images.
This information could also be used to decrypt the images.
That meant he could use the AES key to decrypt the firmware images, modify them, and then use the script to re-encrypt the images using the AES key and package it all up into a password-protected ZIP for Hyundai’s IVI update system to ingest.
But it wasn’t going to be that easy: some part of the supplied data, at least, would need to be cryptographically signed using an RSA private key, and Feldman didn’t have it. The updater would use the private key’s corresponding RSA public key to check the data was signed using the correct secret private key.
He thus needed to find the RSA private key to get any further.
“The script hinted at RSA signing being used, but unfortunately the key used for that was not in the source code,” Feldman explained in a blog post back in May that was brought to our attention by a reader this week.
“Turns out the [AES] encryption key in that script is the first AES 128-bit CBC example key listed in the NIST document SP800-38A [PDF],” he added.
As an aside, the consensus in the crypto community appears to be that CBC is difficult to use properly and other approaches are recommended. Microsoft last year warned that the use of AES CBC with padding may not be secure.
“Microsoft believes that it’s no longer safe to decrypt data encrypted with the Cipher-Block-Chaining (CBC) mode of symmetric encryption when verifiable padding has been applied without first ensuring the integrity of the ciphertext, except for very specific circumstances,” the company said. “This judgment is based on currently known cryptographic research.”
But Hyundai’s fault isn’t misimplementing AES CBC; it’s using yet another key published online as a secret.
With that symmetric key, Feldman was able to extract the contents of one of the encrypted firmware image files within the update ZIP.
And within the extracted files, he found the software that handles IVI updates, a binary called updateAgent. In other words, Feldman was now looking at the very code – the update tool in the IVI in his car – that he needed to defeat, which gave him a sporting chance to beat it.
“Since I already had the zip password and the encryption key, I decided to look for the signing key,” explained Feldman. “With any luck they left not only the public key but the private key too.”
His luck held out, in a way. Feldman found within the firmware image the RSA public key used by the updater, and searched online for a portion of that key. The search results pointed to a common public key that shows up in online tutorials like “RSA Encryption & Decryption Example with OpenSSL in C.”
That tutorial and other projects implementing OpenSSL include within their source code that public key and the corresponding RSA private key.
This means Hyundai used a public-private key pair from a tutorial, and placed the public key in its code, allowing Feldman to track down the private key. Thus he was able to sign Hyundai’s files and have them accepted by the updater.
At that point, Feldman had the opportunity to create custom firmware for his car’s IVI, as he describes in two subsequent online posts. He also has summarized his approach for other Hyundai owners.
Hyundai has not responded to a request for comment. ®