Ockam at Oktane 2020 - The Future of Trust

Trust in IoT? The Open Source Ecosystem is Coming to the Rescue!

Enterprises need to be able to trust the data that flows through their business operations.

What happens when that data is generated at the edge, in IoT, or connected devices that live outside of the data center? How should you think about trust as your business processes move out to the edge? More so: how difficult will it be to build and operate this new generation of applications?

In this session, we’ll discuss a framework for building trustful architectures and the importance of secure messaging between machines and the cloud – giving a view into the future for IoT by investigating what we have learned from the past decade of open-source, cloud-native application development.

This blog and video is a reproduction from Okta's Oktane 2020 conference.

You can find even more great videos by other luminaries in the identity space by visiting the home page for Oktane 2020 "The Future of Identity", here.

Transcript from this video:

My Journey To This Moment

So my journey to where we are today started right after I graduated from college in the late 90s. I spent about a decade building instrumentation systems for America's Cup racing boats. It's very much analogous to auto racing: there are a lot of sensors, data collectors, and real-time analytics tools. We moved information around and tried to make real-time decisions during races.

I then moved up to Silicon Valley, where my career pivoted from building instrumentation systems to building tools for developers. If you've ever seen weather on your phone, chances are it uses the weather API I built to get its data. Next I worked at Heroku, another developer tool company, in the early days of AWS and cloud. Then I moved to Microsoft, where I helped them pivot to the open source strategy that everyone today knows and loves.

Along that journey, I ended up coming full circle back to this question:

Why is it so difficult for devices at the edge and outside data centers to work together?

I've been looking at this concept of interoperability and examining the core blocker for why devices cannot talk to each other and interact functionally.

The Root Problem with IoT is...Trust

What I quickly realized was that interoperability is underpinned by trust. If you get a message from somewhere on the internet, you need to trust that the message has not been tampered with and is a trustworthy piece of information.

I started going down this rabbit hole of "what is trust in the edge and IoT" and realized that trust is underpinned by identity. It's critically important as a first step to understand which application is sending a piece of information that you're trying to act on in a distributed system.

Now, fortunately, the hardware community is helping us in this regard. There are companies that are creating the ability to store a cryptographic key in hardware. We already have their chips in many devices, including some Android phones, iPhones, and Macbooks. This capability creates a root of trust because that key is generated in the device, and it never leaves the device. You effectively have to destroy the device to potentially figure it out. This concept creates a world where we now have self-sovereign identity for things instead of relying on certificate authorities or some other attestation coming from outside those devices. A device can self generate an identifier and have a self-sovereign identity. There's a great project I encourage everyone to look into coming out W3C called decentralized ID or decentralized identifiers. They're doing a lot of groundbreaking work in this area for how those identifiers will work.

In this problem of sharing information between the cloud and the edge, we've had ten years of fast forward development in open source software driving many of the cloud services we know and love today. Whether it's Okta, Mongo, or Postgres, there are all sorts of open source projects that have become great commercial cloud services; most of those are running on the internet today and are very familiar tools to all of us.

The problem is on the edge side. There's still a lot of proprietary software, specifically with how the instruction set architectures work. The software that's directly talking to the hardware is still in a proprietary world, and that's the crux of the problem. Fortunately, while the edge hardware and IoT are about a decade behind cloud innovation, in my opinion, we actually have a really great playbook for how to innovate very fast, and that is around open source.

Why Open Source?

Before I go into the case study I mentioned earlier, let's discuss why open source is so great. Open source is great because of ecosystems.

A lot of people think of it as simply free software. I would encourage people to instead look at it through the lens of ecosystems, as that is the real power of open source. Let's take a look at what that means in practice. I'll start in the abstract, sharpening the concept as we go forward.

Think about the world as having two halves. One half is an open source community, and the other is a commercial entity. You see this pairing in most of the successful open source projects, going all the way back to Linux and Red Hat, to some of the newer technologies, such as Kafka and Confluent. Ockam is in a similar state. We have a commercial side to what we do and an open source side to what we're working on.

How do these two sides come together for open source software? Essentially, you have the commercial entity sponsoring the open source community and its development, and the open source community partnering with that commercial company to drive innovation forward.

This combination of sponsorship and partnership between commercial and open source ends up giving you innovation both on the business side and on the technical side. Specifically, on the open source side, we have faster innovation because the barrier to participate is so much lower, and there are more eyes and ideas on any particular idea. Effectively, this innovation is not limited just to what that commercial entity is driving for in their product roadmap. Adoption is also very frictionless; most code is available on GitHub or GitLab. Ockam's code is available on GitHub, for example. This all means it's easy for you to fork a project and incorporate it into whatever you happen to be building.

I also strongly believe that open source improves security. When security is wrapped in a black box, where you can't see the code, you just have to trust what happens in the black box. This situation is nebulous at best. By having more eyes on a piece of software and having more people using it, bugs and vulnerabilities surface quickly. Someone else doing something completely different from what you're working on might actually find a problem far before you do. You might not even have the expertise on your team, but someone else just submits a pull request with a patch, and then that hole is fixed. These unbound integrations are probably one the strongest pieces around open source with ecosystems. Because of these APIs and interfaces built in the software, anyone can use that interface to integrate whatever they're working on with another project. This creates an amazing graft relationship between pieces of software. You can really take a piece of software and build whatever sort of integration you want onto it for your specific use case. That is only limited to the imagination, not the commercial aspirations, of the project.

On the business side, you effectively see three business models. Companies can be any kind of combination of these three models. You have enterprise support: Red Hat Linux is a conical example there. You also have open-core licenses: these would be where you are getting the software and running it yourself. Usually, some proprietary software goes with that open source code, such as a dashboard or some role-based access control. And then you have software-as-a-service. GitHub is a good example of this. You have a core open source piece of software and it is delivered as a service in a hosted cloud environment where the infrastructure is all abstracted away. End-users are either accessing it through some sort of web portal or maybe even an API in cases like databases.

Case Study with Ockam

Now I want to go through a specific case study. I'll speak to something I know best: Ockam. These are the things that I'm thinking about every day, but this example is directly applicable to all sorts of other use cases. I think you'll see how we are building our open source activity at Ockam is ecosystem-first, and that is where we are focusing all of our energy.

So what does that look like in practice?

This is a diagram of our world.

As I said, Ockam is building tools for developers that aim to build trustworthy IoT applications. We have a messaging layer that effectively sits between the cloud and hardware at the edge. That software manages the identifiers and the chips down at the bottom level, establishes a connection between the hardware at the edge and the cloud, and sends trustworthy messages between the two. We call this a trust architecture, where you have trust up and down your stack.

You could have a business-level application, let's imagine you're in the oil and gas industry, and you are using Okta for identity access management of role-based access control. An employee that has the proper access to control valves out in West Texas can submit at the application layer the control to drive that change on that actuator on that valve. That flow of information is trusted down to the device out in the field. That valve can trust that data that's coming from the cloud. The valve opens, and maybe that device runs an ARM processor with some microchip key vault storage module, and it's connected to an influxDB time-series database. InfluxData has an agent called Telegraf that is running on that processor. It's sending messages to InfluxDB, and it's establishing the authenticated connection with that database and signing messages with its cryptographic identifier so that the server-side can be a hundred percent certain that that message originated from the device it thinks it has and can then act on that data.

So the question here is: what's in it for the community? Why would someone want to join this ecosystem? Because all the companies in our ecosystem are commercial enterprises, we can think through this in classic business development terms. What are the gives and gets? Why would someone want to do this? So if you're a hardware maker installing your hardware into edge environments, the core thing your hardware is trying to do is either get data from the cloud or send data to the cloud. If your hardware is a sensor, what you're looking for are strong connections to the cloud.

Fortunately, the cloud has mature cloud-native codebases. There are millions of open source developers. The hardware companies acknowledge this and are actively trying to build developer relations communities. For us, when we talk to Ockam customers or our cloud partners, we're bringing what edge providers would call sockets. We can help them with either SLA or support, and we have several features they can add into their software they ship in an OEM fashion. We also have a product called the Ockam registry that is of interest to cloud edge environment providers as well.

Now, what does the edge ecosystem give back to both the commercial and open source sides? Obviously, on the commercial side, we have business development partnerships and revenue. On the open source side, these edge environments have those critical Hardware roots trust; these are where the cryptographic identifiers are stored. This is really valuable for the rest of the ecosystem. What they can also do is audit the code in that interface between Ockam and their instruction set architectures. So they have a very clear surface area where they can heavily audit code and make sure they fix any security issues. This means the open source community doesn't have to worry that; they can trust that those chip manufacturers do the right things. They're also building interfaces and integrations to their features, making it simpler for anyone who's building software to interface with those edge environments.

On the cloud services side, they're getting a lot, too. As I said, they're getting that trusted hardware. There is a whole other world of developer relations that is focused on IoT. They get that audited code so they can trust data that's flowing to them on the open source side. And obviously, on our side, we have products effectively similar to what we do on the OEM side with the hardware manufacturers. We do the same with cloud services. We bring those hardware partnerships with us into conversations with cloud service providers along with use cases. We also obviously have support and service level agreement infrastructure that we can put in place there.

In return, the cloud service providers flow value back down into the system. Obviously, on the commercial side, they provide business development and revenue for Ockam. And then, on the open source side, they already have millions of developers that are very attractive to the hardware manufacturers they're trying to engage with, so that creates a really easy channel for them to establish communication. Because these cloud services have been around for almost a decade now, they have these thoughtful cloud-native APIs that are very developer and open source friendly. This gives the hardware manufacturers a wide breadth of integration paths.

Essentially what we are doing is creating an ecosystem between cloud services and edge environments.

Ecosystems happen when there is a virtuous cycle of value and trust.

The One Thing To Take Home With You

Now I want to leave everyone with one thing to take home with them. If you haven't picked up on it yet, it's that open source is ecosystem-first. This is the most important thing, and how you should think about open source. Specifically, I should also mention what open source is not. Open source is not a pricing strategy.

The point of open source software is not to give it away for free; it's to create an ecosystem, and that is job one.

There's a book that's part of our reading list at Ockam that I really like; our culture is very much based around a high-performance team. This is a great book by Bill Walsh called "The Score Takes Care of Itself," and I would encourage everyone to read this book. By reading this book, you see that ecosystem is the benefit of open source because all the what-abouts, like revenue and partnerships, end up taking care of themselves. If you have a strong ecosystem, the rest is actually quite easy. This the big take-home for everyone: add "The Score Takes Care of Itself" by Bill Walsh to your reading list. I think you'll really enjoy it.

If you want to get in touch directly with me or the rest of our team, we are readily available through simple Google searches. You can reach out to us through our website at ockam.io. Our project and all of our code are freely available, and we try to be as transparent as possible with it, so go check it out and ask us any questions, file issues in GitHub or on Twitter @ockam.

If you want to reach out to me personally, I'm on Twitter @lilfortran. Our website also has links to get in touch with us. We even have a community on in GitHub Discussions. We currently span across 15 time zones so it's a global community of great people.

Thank you for your attention and we’d be excited to hear from you.