A vulnerability was recently exposed in the Nissan LEAF's mobile control APIs. Security researcher Troy Hunt discovered the ability to gain inappropriate access to the vehicle's data with limited control over its operation, all through the Nissan companion application. He was able to connect to his LEAF over the Internet and control features, but he could also control other people's LEAFs.
Troy's full post provides a great description of the forensic process (and the ethical implications). The jist of it is that anyone who knows the vehicle identification number (VIN) of a LEAF can access non-critical features such as climate control and battery charge information from across the Internet.
Notice that the word 'secret' is nowhere to be found in the above definition? Yes, a VIN is public, and it's proudly displayed for the world to see through the vehicle's front windshield.
The LEAF vulnerability stems from the fact that knowledge of a particular LEAF's VIN is all that's required to access that car's systems through the Internet.
In the LEAF 'security' architecture, the VIN is effectively a bearer token for the API calls by which the mobile application interacts with the Nissan cloud. So, if you have a VIN (either by direct knowledge or by guessing) then you can take limited control of the corresponding LEAF. And by their nature, bearer tokens must be both secured and secret--neither of which is true for VINs.
But what if we took the VIN out of the picture? Let's imagine an alternative registration and authentication model:
A LEAF is shipped from the factory with a unique code that's not easily accessible. Maybe it's in the glovebox? Maybe instead of simple digits, it's a QR code? Or how about a unique audio code like a triple-tap on the horn? (At least code theft would be more difficult.)
The proud new LEAF owner could create an account and sign on to the mobile companion app on their phone.
In the app, they go to the 'Claim LEAF' tab and enter the code or take a picture of the QR code. The code is sent to the Nissan cloud to validate that it's a recently sold LEAF and that the code isn't already claimed. The Nissan cloud might even perform a geolocation check to verify that the phone's location is consistent with where the LEAF was sold.
The Nissan cloud associates that LEAF with its new owner, and nobody else can claim the LEAF until the owner releases it (perhaps at resale).
The Nissan cloud then issues tokens that reflect the relationship between the owner and the LEAF, and a native mobile application uses those tokens on subsequent calls to the Nissan cloud.
Aside - An implication of this token-based model is that additional accounts could be created (for a spouse, etc.) after the LEAF's owner has been assigned. The other accounts could have differentiated privileges with respect to the car's data and operations. For instance, if the car was able to recognize a particular driver, then it could enforce a 'Safe Driving Mode' for any teenage drivers, limiting speed, radio volume, etc.
For extra points, let's sprinkle some additional authentication factors on the example model above. For particularly sensitive operations (e.g., WRITE vs. READ, new account creation, or the eventual release), the owner is required to scan their fingerprint.
When things (like cars, thermostats, smart scales, etc.) operate on behalf of users or groups of users, the security of the procedure by which identities are bound to those things is critical. If that step is weak, there can be little trust or assurance in any subsequent operations. Hopefully the LEAF vulnerability (and eventual fix) will highlight this requirement for all IoT sectors--not just connected cars.
I discussed this and other aspects of 'Connected Cars and Identity' on a podcast with Secure ID News. Have a listen here.