A man walks up to a car, but doesn’t have the keys to the car. Not a problem. He takes out his mobile phone and clicks on an App that he wrote which invokes device APIs to unlock the car. Then he clicks on another function in the App to start the car and drives away. Does this sound like a convenience you would like? Well, I forgot to mention one important thing - the man does not own the car.

ZDNet recently wrote an article titled, “Nissan Leaf hackable through insecure APIs”. The article points out that the insecure APIs were not to unlock or start the car, but for less critical functions dealing with climate control and battery charge. However, I took license to exaggerate the possible implications of insecure APIs in automobiles.

The situation is not limited to automobiles. Directly accessible APIs access a security camera in a bank to cause it to shut off, pan in a different direction or otherwise not capture a crime that is being committed. Clearly I have watched too many bad movies.

Device interaction through APIs is one of the primary use cases for APIs and one that will grow exponentially over the coming years. In many cases, the APIs might be harmless and an openly accessible API to the device from any source might make sense. Understanding how much battery life there is in the Nissan Leaf doesn’t seem to be something too dangerous. But, perhaps it is possible that someone might come up with an inappropriate use of this information.

On the other hand, unlocking car doors, starting the car, issuing commands to security cameras, and many other scenarios need security for the API. First I would make the argument that if you have an API to a device, even if it is not documented, someone will find it. So, I would suggest that for sensitive security situations obscurity is not a solution. I have spoken to device manufacturers who were planning to use a Bluetooth connection from a mobile phone to communicate with the device APIs. Again, not a good approach as the Bluetooth connection can be used by others without proper authentication and authorization.

So, how should the API be secured? I would suggest that APIs that need security need to be managed. I would also suggest that there should not be a direct connection from the mobile phone to the IoT device. Instead an API should be created for a mobile phone application that “requests” the action to occur. This API request will be authenticated and checked for authorization at an enterprise server. Once the request is determined to be valid the server will issue the command to the device to perform the action. Several levels of security help ensure the action is only performed when appropriate:

  1. Access to the API itself can be limited to a selected audience of internal employees and if desired partners if this is deemed necessary. Although it could also be made available to a public audience.
  2. Any Application using the API will identify itself (using a key and secret) so that the access request can be tracked to that application.
  3. An authorized user of the device establishes an account with the enterprise (e.g. the Nissan Leaf owner has an account with Nissan).
  4. When the authorized user wishes to invoke the action using the App, they are prompted to authenticate themselves. This can be done with an approach such as Oauth so that the Application itself cannot see the authentication credentials.
  5. The request is sent through the API to the enterprise where the Application is validated and the user authentication is checked to ensure the user is authorized to invoke the action.
  6. Upon validation the enterprise server communicates securely to the IoT device to issue the command to perform the action. The device is secured to only accept commands from the enterprise server.

 

IBM API Connect can provide the capabilities outlined in this scenario to secure the device APIs. First, the APIs themselves can be created, tested and managed. Once ready for deployment, API Connect provides a developer portal and the ability to target API availability only to the developer audiences you choose. The necessary App security and user authentication functions are included with the API creation and App keys and secrets provided to the Application developer when they register to consume the API. At runtime the Application and the user identity are validated using the included API gateway function and the request is transmitted to the enterprise server. Secure connectivity is ensured throughout.

To understand more about IBM’s thoughts on the API Economy visit the IBM API Economy website. IBM API Connect is IBM’s complete foundation to Create, Run, Manage, and Secure APIs. You can find more information about IBM API Connect at the API Connect website. And you can also download a trial version of API Connect.

 

If you have questions, please let me know. Connect with me through comments here or via twitter @Arglick to continue the discussion.