Securing the IoT for Decades to Come

In 2007 Kevin Kelly gave a TED talk in which he forecasted how the World Wide Web would look 5000 days into the future, prophesizing the emergence of the IoT and AI. He envisioned a more connected planet where all manufactured goods tap into a single, global, intelligent network.

At the time, the Internet of Things (IoT) was only a nascent idea thrown around by futurists. Now, however, it’s a hot potential market, accelerating large corporate moves and entrepreneurial initiatives throughout the world. Gartner predicts there will be over 20 billion IoT devices by 2020.

So, let’s model Kelly’s thought process and take the long view yet again. What will the next 5,000 days bring? What will the world look like in 2030? Drone deliveries, self-driving cars, and more innovation is surely coming, but so are unprecedented vulnerabilities to the user. In 2030, the way IoT sensors and devices share data must be secured, or else we are creating our own doomsday.

According to Travis Spencer, founder of Twobo Technologies, the IoT can only exist if identity checks are properly implemented at the API level — as any IoT device must know who is requesting data, and what they are allowed to do with that data.

The creation of a global device-oriented network is only possible by using APIs for standard information design, as well as adopting internally recognized open standards (like OAuth, OpenID Connect, SCIM, etc.) as a foundation for the identity management that is so critical for protecting user safety and data.

We’ve discussed at length the need for standardized APIs within the IoT, but scaling IoT platforms from a security perspective is another beast entirely. In this post, we’ll look decades into the future to see how IoT and API security must unite, so that developers can begin to scale their platform and security measures accordingly.

Watch Travis Spencer, founder of Twobo Technologies, speak at the Nordic APIs Platform Summit:

Looking into the Crystal Ball: The World in 2030

The world is changing rapidly, and IoT is gaining true momentum. By 2030, we’ll see the ubiquity of driverless cars and drones. Highways are already being designed for driverless cars, drones have expanded beyond hobbyist usage into numerous applications, and sensors are driving the fog computing movement.

As the IoT leaves the realm of hobbyism and integrates into our daily lives, Spencer sees connected apparel, space tourism, 3D printing, smarter healthcare, and secure electronic voting as realistic implementations.

“The IoT is not hype. It’s everywhere — it’s in the room.”

There will also be major restructuring within our industry and workforce. Entire companies will vanish and new ones will emerge. Futurist Thomas Frey predicts that by 2030, 2 billion jobs will disappear from the planet.

But this transformation will also reinvigorate the workforce; It’s been said that by 2030, 1 in 5 jobs will require programming as a basic skill, and the need for programmers is growing 12% faster than other areas.

Today’s tech will appear absolutely archaic in comparison to future devices, yet the software architecture could remain constant if open standards are adopted. Let’s see what IoT evolution will mean for scaling security architecture for decades to come…

Identity is the #1 Impediment to Safe IoT Connections

As we embed devices into our bodies and immediate surroundings, Spencer sees political, religious, and social systems being reinvented and questioned. But something that won’t ever change is the human desire to form relationships. People will always want to know who or what it is that they are interacting with.

“Within social, big data, and all different aspects of computing impacting our lives, we need to know who we are talking to — who’s on the other end of that API?”

Without identity control in place, trusting an IoT gadget poses a serious threat. Consider a skiier using smart goggles that describe upcoming conditions on the slope. If someone hacked this platform and edited the terrain, this could lead to a fatal crash. To prevent this, we need to intimately understand who is accessing IoT devices.

Whereas humans intimately understand relationships, all a computer understands are 0s and 1s. So how do we train IoT devices to recognize identity? Spencer sees the solution lies in incorporating an open standards-based identity management system within your API management makeup, using specialized systems to authorize and federate access across API connections.

Building on Open Standards will Secure Future Identity in the IoT

The open standards we’re talking about are communication specifications defined and generally agreed upon by the international web development community. According to Spencer, deploying these open, internationally recognized standards will enable long-lasting IoT/API platforms to be constructed.

The Neo-security Stack achieves this, and is built on the following open standards:

Within the Neo-security stack, these standards are combined within three subsystems: An Identity Management System, API Management System, and an Entitlement Management System — three fundamental systems that should be recognizable and supported within all IoT organizations. All are cleverly powered by open standards to ensure platform longevity.

For example, the goal of an Identity Management System is to answer the fundamental question of who is calling. Once it figures out the identity, it then forwards this information to other subsystems. An identity management system should be comprised of:

  • A user management service to perform Create Read Update Delete (CRUD) operations on things like user information, groups, or connections between users. It uses SCIM, the standardized identity API by IETF.
  • A federation service to allow you to reuse credentials in another trusted domain. It brokers cryptographically secure credentials using OpenID Connect.
  • A security token service that issues a security credential token, implementing the OAuth standard.
  • An authentication service is another important facet of the overall identity management system. It covers many bases — it can log you in, collect credentials, act as a self-service registration, and provide Single-Sign On (SSO) capabilities. It also integrates with different directories such as SQL databases, other integration providers, social networks, or exterior identity providers. An authentication service is often built to the specific requirements of the organization, and in doing so may need to deal with older, non-standard protocols.

Acknowledgement: Open Standards Fluctuate

Spencer recommends that developers build on new security standards that will stand the test of time, yet they should loosely couple them in a way that allows for revising or adding new standards to the stack. This is because standards, and the products they support, will inevitably evolve:

The world is changing and shifting… if we don’t build in a loosely coupled way where the interfaces between these systems are governed by open standards then it’s going to be hard to replace those products.

By 2030, your API platform may not be replaced in it’s entirety, but it will be likely be reiterated and extended. Ensuring the platform is open from the start, based on standards you can implement yourselves or find replacements for, goes a long way to extending lifespan. It also ensures that security will evolve alongside this evolution.

The Nuances of IoT-Based Communication

Much of what we’ve discussed so far has been related to internet-based communication. In which, the API security management system is talking to APIs that are accessing the internet over HTTP or HTTP 2. However, IoT devices may be working with other protocols, such as CoAP, a specialized web access protocol designed for machine-machine dialogue.

We typically use JWT (JSON Web Token) as the standard token, as it creates lower technical barrier, is easier parse JSON over XML, and integrates well with lower level languages. With a little maneuvering, we can send an OAuth message inside of a CoAP stream.

Since HTTP 2 redesigned HTTP as a binary protocol for compactness, it would make sense to use the same message format but as a binary representation. To do so, you can use CBOR Web Tokens to create a compact profile of the JWT. This could be used within an IoT setup as a way to optimize throughput.

Also visit or API Security Insight page for poignant API security lessons

5 Actionable Steps Toward Improving IoT Security

We glimpsed into the near-distant future, and discovered a rapidly changing world greatly impacted by the advent of the IoT. In the Internet of Things, identity control will be paramount for protecting users, but to get there, we need a long-lasting API security architecture founded on open standards.

With all this information, where do we go from here? Spencer recommends 5 solid next steps to begin implementing better API security:

  1. Gap analysis assessment: Could your systems benefit from a more secure identity architecture? How important are the components for your business?
  2. Gauge the impact on the platform: Assess how a new security service will impact your existing databases. How would this alter how clients must call the APIs?
  3. Pilot and deploy in baby steps: Assemble a proof of concept and test it with your users, assess the strengths and weaknesses, and iterate.
  4. Go live with HTTP 2!: We should all embrace HTTP 2 as it’ll make the internet a speedy, happier place!
  5. Research IoT-specific protocols: To make data transfers truly compact, consider CoAP as an IoT specific protocol, and CBOR for distributing your JWT tokens.

Our future digital world will be truly incomprehensible compared to the present, and perhaps, somewhere in the cloud exists the world’s biggest internet company, yet to emerge. Now that the IoT has become a reality, we must future proof the API security platform at it’s core. As identity will be pivotal for understanding relationships between devices, the best we can do now is to build identity management systems that embrace open standards that are poised to stick around, decoupling them so that as products evolve we can synergize them with new components.