A builders guide to Trust in autonomous connected applications.

Replay from Okta Oktane21. A builders guide to Trust in autonomous connected applications. We'll show how cloud services can establish lightweight secure channels with IoT and edge devices that guarantee end-to-end data integrity, authenticity, and authorization.

Ockam at Oktane 2021 - A builders guide to Trust.


*Ockam builds open-source developer-first tools for mutual authentication and end-to-end encrypted messaging between distributed applications, in any environment, anywhere… Trust Data-in-Motion.*

Ockam has secured $12.5 million of Series A funding from [Craft Ventures](https://www.craftventures.com/), [Future Ventures](https://future.ventures/), [SineWave Ventures](https://sinewave.vc/), [OCV](https://www.ocvpartners.com/) and [Okta Ventures](https://www.okta.com/okta-ventures/), among others.

Ockam empowers development teams with the tools they need to easily build a “trust architecture” within their applications to ensure that data that moves over complex, multi-hop, multi-protocol routes is end-to-end encrypted, mutually authenticated, secure, and private.

Ockam has seen tremendous growth in developer engagement with its open source code over the past 6 months, and has become one of the fastest growing open source projects on GitHub. Developers resonate with Ockam’s open source project because it aligns with two important security trends: applications need to trust data, and developers need friendly easy-to-use tools.

Application security has historically relied upon network perimeters and intrusion detection to keep data that moves between applications secure. However as applications become ever more distributed across private, cloud, and edge environments, it has become impossible for application developers to rely upon network security, alone, to keep data-in-motion safe. This is the core principle in a Zero-Trust application architecture—applications must be responsible for data they create, or distribute, and place Zero-Trust in the network for security guarantees.

“With Ockam, the security of application data no longer implicitly depends on the defenses of every machine within the same, usually porous, network boundary,” said Mrinal Wadhwa, CTO of Ockam. “Instead, when applications connect with Ockam they can make granular authorization decisions about all incoming information and commands, ensuring that any data and communications between applications is secure and trustworthy.”

Ockam will triple the size of their engineering and product teams to tackle the next phase of Ockam’s growth. In particular, Ockam is immediately seeking a [Head of Engineering](https://www.ockam.io/team#open-roles), [Head of Developer Experience](https://www.ockam.io/team#open-roles), and a senior level [Applied Cryptographer](https://www.ockam.io/team#open-roles).

"Since the very earliest days of Ockam, we've built a community that shares our value of Trust,” said Matthew Gregory, CEO and founder of Ockam. “We're grateful for all the support we've received from the open source community, our users, add-on partners, investors, and advisors. I am exceptionally excited that we are able to recruit the very best people in the world to join our team. We’re also thrilled to have Patricia Muoio (SineWave Ventures) and Arra Malekzadeh (Craft Ventures) join Maryanna Saenko (Future Ventures) and Joanna Drake (Core Ventures) on our board.”

If you’d like to learn more about what Ockam has to offer, and are interested in joining a high-performing, remote-first, and dynamic team to empower every developer to build Trust for Data-in-motion, check out their [open roles](https://www.ockam.io/team#open-roles).

If you'd like to build an application with Ockam,[start hacking here](https://github.com/ockam-network/ockam#readme)!


Ockam raised $12.5 million of Series A funding from Craft Ventures, Future Ventures, SineWave Ventures, OCV, and Okta Ventures, among others.

Ockam raises a $12.5m Series A to build a remote-first, high-performance team.


# End-to-end encryption and mutual authentication between cloud and edge apps

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?

Enjoy this builders guide to Trust in autonomous connected applications. We'll show how cloud services can establish lightweight secure channels with IoT and edge devices that guarantee end-to-end data integrity, authenticity, and authorization.

This demo will show how a fleet of machines can be enrolled with cloud services and how applications can exchange attribute based cryptographic credentials to ensure granular, dynamic, policy driven access control.




<AspectRatio maxW="100%" ratio={16/9}>
    <iframe  src="https://www.youtube.com/embed/9VIjGd_uA68" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowFullScreen></iframe>
</AspectRatio>


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


<AspectRatio maxW="100%" ratio={16/9}>
  <iframe src="https://www.youtube.com/embed/b5RpsAmiZZQ" title="Building Ockam as a High Performance Team" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowFullScreen></iframe>
</AspectRatio>


**Transcript**

One of Ockam's core values is that we are a High Performance Team. Just like open source software builds on top of the shoulders of giants, so do our ideas around team building. Specifically about building a *High Performance Team*.

# The Team, The Team, The Team

I grew up outside of Detroit when Bo Schembechler was head football coach of the University of Michigan Wolverines - what would eventually become my alma matter. Coach Bo retired in 1989 with over 200 wins and 13 Big Ten championships. He was a builder of high performance teams.

There’s a [Bo Schembechler speech](https://www.youtube.com/watch?v=qjv2iDxiGBI) that inspired our approach to high performance teams:

> “We’re going to win this as a team. They can throw out their great backs and great quarterbacks and great defensive players. There’s going to be one team that plays solely as a team. No man is more important than The Team. No coach is more important than The Team.
>ć
> The team, The Team, The Team.
>
> And if we think that way, all of us, everything that you do, you take into consideration ‘what effect does it have on my team?’
>
>You can go into professional football, you can go anywhere you want to play after you play here. You will never play for a team again. You’ll play for a contract. You’ll play for this, you’ll play for that. You’ll play for everything except The Team.
>
> Think what a great thing it is. You’ll be a part of something that is a team. We’re doing to win it. We’re going to win the championship again. And we’re going to play as a team. Better than anybody else in this conference, we’re going to play together as a team. We’re going to believe in each other, we aren’t going to criticize each other, we aren’t going to talk about each other. We’re going to encourage each other.
>
> When we play as a team and the old season is over, you and I both know, it’s going to be Michigan again. Michigan.”
> Bo Schembechler, 1983

His mantra about “The Team, The Team, The Team” informed my earliest ideas of group performance. Over the years, I’ve noticed there are more similarities than differences between the best sports teams and the best companies. To achieve high performance, at any level, requires operating as a team.

In the rest of this talk, I’ll share the elements of a high performance team and the group mindset required to make one.

## A High Performing Team Knows What Winning Looks Like

Winning is a destination. I also like to call winning 'a dream with a deadline.'

Winning needs to be defined. Everyone on The Team needs to know what winning means for The Team.

For example. When we published the [Zero to IPO](https://www.ockam.io/blog/zero_ipo/) framework on this blog, a lot of people said, “whoa, whoa, whoa!” They thought we were way too early to talk about where the company is going. I disagree.

Our entire team wants Ockam to become a publicly traded company. We look to companies like Okta, Cloudflare, Snowflake who have come before us. These companies democratize complex internet infrastructure - at massive scale- just as The Ockam Team intends to do.

## Building blocks of a High Performance Team

Whether you are dealing with a sports team or a company team, there are a stack of skills that define the focus. Within those, there’s a normal distribution. Many teams and companies can do quite well just by showing up. I'd argue that if you have a functional team that can 'show up' you probably can be an average team. If you add some self management you can probably get outside of one standard deviation from the mean. You probably get out to two standard deviations with great leadership traits across The Team.

We don’t want to be average, somewhat-better than average, or even much-better than average. We are in the game to be the absolute best. Maybe the best - ever.

![Performance Bell Curve](/blog/team/bell.png)

It’s not enough to declare “we’re a high performance team.” In fact, it’s a rare thing to experience. Coach Schembechler knew this when he told his players 'they may never, really, play for a team again'. A high performance team is an aspiration, a process and something that doesn't happen by accident.

Let's break this down further:

![Performance Levels](/blog/team/levels.png)

### Show up

At the basic level, a team must show up. Individuals show up. Everybody delivers on time. There's an abundance of opinions and fixed mindsets. Congratulations. You and your team are average - you showed up.

### Management

Let's now layer in some management. If you add organizational rigor, some well tested MBA-style process, and even forecast and measure your key performance indicators - you can break away from the mean. This is actually a pretty difficult step. Just look at all of the time and energy organizations put into mastering this step.

To be the best, we need to do more.

### Leadership

Leadership is where we start to see empowerment across the organization. When The Team has a common vision, and the mission of The Team inspires everyones actions - all the time - then you have great leadership.

Real leadership is about everyone - not just the CEO, and executive, or a manager.

Think of a baseball team.

![Players on the Field](/blog/team/baseball.png)

There is no organizational structure to the players spread out across the field. There are nine world-class people that specialize in nine specific roles. When there’s a fly ball to left field, one person is responsible for the outcome: the left fielder. When the pitcher holds the ball on the mound, he’s in charge of what happens next. A center fielder might specialize in producing hits or even home runs.

Each player on The Ockam Team plays a critical role - not one is more important than the other on a High Performance Team. For The Team to win The Team needs everyone to both lead and to be excellent at their role.

> Leaders put The Team First

Netflix has a coaching documentary, The Playbook, that brought this lesson into clarity for me. The first episode kicks off with a quote from championship coach Doc Rivers. I’m in violent agreement with it. Like the quote from Bo Schembechler, it makes clear the priority you must set to become a high performance team:

> “Every time I walk in the locker room for the first time I tell my players, every year and I’ve told them for 21 years: ‘I’m Doc Rivers, and I’m human, and I’m going to make mistakes. Having said that, every decision I make will be about what’s good for The Team. And that may not be what’s good for you. Or me. But if it’s good for The Team, it’s good.’”
> Doc Rivers

In my role as the CEO at Ockam, my job is to make decisions that are good for The Team. Full stop. That's it. That's what I do here.

>The Team, The Team, The Team.

### Trust

 There is a common state of Trust across a High Performance Team. They believe in each other, to be responsible and accountable for their area of expertise. Being on a team like this is a once-in-a-lifetime experience. This is the rarified air; When everyone is focused on winning - as a team - you have Ubuntu.

## Ubuntu is a High Performance Team’s Way of Life

One element that we’ve brought into our high performance team is “Ubuntu.” Those of us that build with open source software, might immediately think of the open source Linux operating system distribution when we hear "Ubuntu". However the origin of the word comes from South Africa

It’s hard to express in English, but here’s how Archbishop Desmond Tutu explains it:

> “Ubuntu is the essence of being human. It says a solitary human being is a contraction in terms. I have to learn from other human beings how to be human.”

It turns out it also played an important role for Doc Rivers. He realized;

> I can’t be all I can be unless you are all you can be. I can never be threatened by you because you’re good. Because the better you are, the better I am.” ~ Doc Rivers

The season that Doc Rivers introduced Ubuntu at the Celtics, they went onto win the NBA championship - as a High Performance Team.

To me, Ubuntu transcends culture, politics, and sports. It's a philosophy for high performance. I’d venture that every winning team lives Ubuntu, even if they didn’t have the word specifically.

Compare that to the classic company approach where you’re given a new role and then someone says, “we’ll see how you do.” That’s not empowering! Empowerment is a prerequisite for a high performance team. The better you are, the better I am, and vice-versa.

High performance team members each bring their best to every day, every single meeting, every single pull request. As The Team grows and scales out, everyone is a leader, the captain of their role. The only way to grow excellent team members is to be an excellent team member. Even our youngest, newest members have responsibilities that place them at the top of the org chart. This is because the high performance team org chart actually has a graph relationships - with everyone at the top of the org chart from the perspective of their role on the team.

At Ockam we aim to empower everyone to be excellent in their role. Everyone puts the needs of The Team ahead of themselves. Everyone knows what winning looks like. And everyone helps one another to be the best that they can be. In fact, the most high performance people on The Team figure out how to enable others to be better than they could imagine for themselves.

You may only experience it once in your career, but you owe it to yourself, and those who work alongside you, to reach for the ideals of a high performance team.


High Performance Teams don't happen by accident. We've got a playbook to build one.

One of Ockam's core values is that we are a High Performance Team. Just like open source software builds on top of the shoulders of giants, so do my ideas around team building. Specifically about building a High Performance Team

How we build Ockam as a High Performance Team

*A partnership between InfluxData and Ockam brings trust to time series data.*

Let's investigate how to build applications with trusted time series data in a zero trust environment! To trust an application we need to trust the data that feeds into it. Increasingly, applications rely on time series data from outside the datacenter, at the edge, or in IoT. This means we need to think of trust and data in new ways.

This is why InfluxData and Ockam have partnered to bring trust to time series data streams and data warehouses. First let’s start with the challenges faced by application developers;

# Network boundaries are not sufficient for data-layer trust, security, nor privacy.

Time series data typically needs to traverse multiple networks to connect a machine at the edge with InfluxDB in the cloud. This makes it nearly impossible to control a network perimeter - particularly for an application developer.

The Zero Trust network architecture principles give guidance to how we should think about connections between the edge and InfluxDB. A Zero Trust architecture is based on the assumptions that;

* The network is always hostile,
* External and internal threats exist on the network at all times,
* Network locality is not sufficient for determining trust in a network,
* Every device, user, and network flow must be authenticated and authorized,
* Security and privacy policies must be dynamic and calculated from as many sources of data as possible.

To build an application that places zero trust in network boundaries can be challenging for an application architect who simply wants to connect an agent, like Telegraf, running on a device at the edge to a cloud hosted instance of InfluxDB. That’s why InfluxData has partnered with Ockam. Ockam abstracts away the complexities required to build such distributed applications.

Let's look at the components that make up Ockam's systems, and how they provide security and privacy to time series data streams.

# What is Ockam?

[Ockam is an open source](https://github.com/ockam-network/ockam) suite of tools, programming libraries and infrastructure that makes it easy to build devices that communicate securely, privately and trustfully with cloud services and other devices. Security, Privacy and Trust are application layer concerns and IoT developers should have simple tools to granularly control these aspects of their applications.

Ockam has taken proven cryptographic building blocks and applied them to build solutions for common IoT and edge-computing problems like:

* Secure, rapid enrollment of large fleets of devices.
* Scalable provisioning, proof of possession, rotation, and revocation of identity keys and credentials.
* End-to-end encrypted communication over low-bandwidth, intermittently connected, multi-protocol IoT and edge network topologies.

The goal is to provide this functionality in multiple programming languages with secure, high-level application interfaces that are easy to use correctly and hard to misuse. Let’s look at some of the core features of Ockam’s tools:

![Ockam Architecture, Features, Add-ons](/blog/trust_influx/architecture.svg)

## End-to-end encrypted secure channels

Ockam’s Secure Channels provide end-to-end encrypted and mutually authenticated communication that is safe against eavesdropping, tampering, and forgery of messages sent across multiple application layer hops. This enables an application to place zero trust in network boundaries and instead delivers granular control to application developers on what data is revealed where in their system.

## Machine identity and access management

Application developers need fine-grained control over data access in their systems, this can only be achieved if all interactions are mutually authenticated. To enable this, all devices must have unique cryptographically provable identities and access control must be managed with secure credentials. Enrolling large fleets of devices and managing the lifecycle of their keys and credentials can be quite challenging at scale. Ockam includes easy to use cryptographic protocols for;

* Device Enrollment
* Policy Enforcement
* Key Management, Rotation, and Revocation
* Credential Issuance
...and more.

## Built for InfluxDB developers

Ockam includes a suite of robust cryptographic protocols, accessible through simple to use programming libraries, that enable application developers to focus on the trust rules and policies of their IoT and time series data-dependent applications.

The Ockam programming libraries help easily encode, business specific, granular access control logic into applications without having to deal with the complexities of cryptographic protocols or falling back to weak, coarse grained security based on network boundaries. If you are building an application with InfluxDB, adding trust with Ockam is easy.
InfluxDB and Telegraf Add-ons for Ockam are easy to integrate

![InfluxData and Ockam Hub create secure channels](/blog/trust_influx/channel.png)

There are two ways to use Ockam with InfluxDB. Let’s start with Ockam Hub.

Ockam Hub is a service hosted in a cloud environment that makes it easy to route messages between an unlimited number of machines at the edge and InfluxDB. While it may work in a prototype, TLS is not the right tool for the job of securing our data streams at scale. It’s impossible to control the network boundary across the multiple networks you are likely to encounter in the real world, issuing unique tokens or credentials is onerous at enterprise scale, and it’s not user friendly for a typical application layer developer. Ockam Hub solves all of these problems, and more.

If you are deploying Telegraf agents into machines we have a solution for you as well. OckamD is a daemon that runs alongside Telegraf and is downloadable from Github. OckamD and Telegraf are preconfigured to create an end-to-end encrypted messaging channel all the way to your InfluxDB instance in the cloud.

**It’s that easy!**

[Click here to run the demo](https://www.ockam.io/learn/how-to-guides/using-add-ons/enterprise/influxdb/telegraf-influxdb-with-ockamd/)


A partnership between InfluxData and Ockam brings trust to time series data.

InfluxData and Ockam: How to build applications with trusted time series data in a zero trust environment.

Zero Trust in Time Series Data?


If you want to send secure communication back and forth with someone else, you'll each need a key to encrypt and decrypt that communication. The challenge with that lies in communicating what that key is without anyone finding out. It's quite the catch-22 as you can't exchange any communication securely without that key, yet you can't exchange that key because you don't have a secure communication method. What are you to do?

Well, one way to exchange keys securely without previously having a shared secret is the Diffie-Hellman key exchange. What is Diffie-Hellman? In fact, you're making use of it right now by visiting this web page. The Diffie-Hellman key exchange is a crucial component in securing internet traffic. Let's look at how exactly it works.

## A Paint Mixing Analogy

We'll begin by looking at this key exchange abstractly before discussing how it works mathematically. For now, just imagine two people (Alice and Bob) who'd like to have a shared secret key.

Let's imagine this shared secret key is a specific color of paint. They want to create this paint color secretly. How can they do that?

Alice and Bob both have access to some paint that anyone can access. For this example, it's yellow. They both take that yellow paint back to their rooms and add a color that only they know. For Alice, it's a specific shade of red, and for Bob, it's a specific shade of blue.

As a result, Alice now has a specific shade of orange that can only be made with her secret shade of red, and Bob now has a specific shade of green that can only be made with his secret shade of blue.

They leave their rooms and exchange their new mixes. This is done in public, but that's okay because someone won't be able to determine what exact shades were combined with the yellow to get these new colors. If you were perplexed why this cryptography metaphor uses paints, it's for this reason; a crucial part of the Diffie-Hellman key exchange is the difficulty in extracting the secret values, much like how it is difficult to determine what exact shade was mixed into paint.

Now, Alice has Bob's green paint and Bob has Alice's orange paint. They then add their secret shades to the other's paint. As a result, they each get the same shade of... most likely some type of brown. But a specific, non-reproducible shade of brown! Nobody else could have produced the same color, even if they had the same yellow paint they started with or even if they managed to grab some of the green or orange paint when Alice and Bob exchanged them in public.

Is this quite the simplification of a precise mathematical method? You betcha. But hopefully it helps you understand the main gist of what the Diffie-Hellman key exchange can accomplish. With this, you can exchange a shared secret key with another person without exposing it publicly, and thus prevent others from stealing that shared secret.

## Calculating Numbers: An Explanation

Of course, your browser and a website's server aren't exchanging buckets of paint. They're going through a similar process using math, instead. We'll be looking at a simple implementation of Diffie-Hellman by looking at how two parties, Alice and Bob, can use it to establish a shared secret key.

Before we do that, however, it's important to understand the concept of [modular arithmetic]. What happens when you divide a number by something other than one of its multiples? Well, it doesn't divide evenly. Modular arithmetic isn't concerned with how many times a number can be divided by another, it only deals with the remainder that doesn't divide evenly. For example,

5 mod 2 = 1,

because 5 divided by 2 equals 4 with a **remainder of 1**. Why does Diffie-Hellman use modular arithmetic? Well, because it's incredibly hard to undo, much like unmixing paint.

Diffie-Hellman starts off with a combination of public and private components. There are the public components _g_ and _n_ where:

- _g_ is a small prime number (specifically, a [primitive root modulo](https://en.wikipedia.org/wiki/Primitive_root_modulo_n))
- _n_ is a large prime number.

Then Alice and Bob both have a private component where:

- _a_ is an integer less than _n_ only known to Alice
- _b_ is an integer less than _n_ only known to Bob

These are all the components needed to begin the key-exchange.

First, both are going to apply modular arithmetic in combination with _g_ and their private component (either _a_ or _b_), and then send it to the other. These are their **public keys**

- Alice sends Bob: A<sub>public</sub> = g<sup>a</sup> mod n
- Bob sends Alice: B<sub>public</sub> = g<sup>b</sup> mod n

They're public because these are being sent insecurely (as they have yet to establish an encrypted channel). That's okay though because it's incredibly hard to work out what the **private** values _a_ and _b_ are, because of how difficult modular arithmetic is to undo.

The difficulty of figuring out _a_ and _b_ from _A<sub>public</sub>_ and _B<sub>public</sub>_ is dependent on the size of _n_. The values of _A<sub>public</sub>_ and _B<sub>public</sub>_ can be anything between 0 and n-1, so the larger _n_ is, the more secure _a_ and _b_ are.

Now that Alice and Bob have each other's public key, what can they do? They can use modular arithmetic again, first raising the other's public key to the power of their own private value, and then finding the remainder when divided by _n_:

- Alice calculates B<sub>public</sub><sup>a</sup> mod n
- Bob calculates A<sub>public</sub><sup>b</sup> mod n

What's great about this is that Alice's calculated value is **equal** to Bob's! Just like that, they now have a shared secret that nobody can calculate with their private keys. This is their shared secret key. These keys can then be used to securely exchange the more-efficient symmetric keys for encrypted communication.

## Diffie-Hellman's Place in Today’s Encryption

We've discussed how Diffie-Hellman is used to securely exchange keys, but when does that actually happen on today's web? Well, Diffie-Hellman is a crucial part of the most widely used internet communication encryption protocol: TLS.

You may have heard of TLS and its handshake, but let's give a brief overview: Back in the wild west of the internet, aka the ’90s, most internet communication was not encrypted. For obvious reasons, that became an issue when people's private information, such as banking info, began to be sent across the internet. TLS was created to ensure data between a user and a web server was encrypted. Its implementation is represented by an appended 's' to HTTP, resulting in the common HTTPS we see in most websites today. This, and the padlock most browsers show alongside it, is how we assume our traffic is safe. But what exactly does that mean? (Hint: it involves using a Diffie-Hellman key exchange)

Let's look at a website using TLS 1.2. By investigating the site's security information, you'll see something like this:

`(TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, 256 bit keys, TLS 1.2)`

This mashup of letters is the cipher suite, or the specific set of algorithms TLS is using to secure communication. We're only going to focus on a specific section: "ECDHE" Here, "ECDHE" is specifying the key exchange protocol used to exchange keys. In this case, you can explicitly see that the key exchange used is an Ephemeral Diffie-Hellman! If you're wondering what the ephemeral aspect entails, that just means a new key pair is generated for every exchange.

Nowadays, some websites you look at, including Ockam's, won't list Diffie-Hellman in the cipher suite:

`(TLS_AES_256_GCM_SHA384, 256 bit keys, TLS 1.3)`

Why's that? Well, it's not because Diffie-Hellman can't be secured; far from it. Many websites now use TLS 1.3, which is more secure than TLS 1.2 because it removed some insecure parameters as options. One of the most notable improvements was removing the option to use RSA as the key exchange. This is because TLS 1.3 _only_ accepts Diffie-Hellman as the key exchange, so there's no point in specifying it in the cipher suite! TLS 1.3 also takes a step to make sure the Diffie-Hellman key exchange is secure by requiring a sufficiently large _n_.

So what does that all add up to? A secure web experience for today's internet users. The peace of mind you have when entering your bank information on a website is thanks to TLS, and the Diffie-Hellman key exchange is one part of what makes TLS so secure.

It's nice that your browser's traffic is encrypted like that, right? Of course, nowadays, you don't access the internet only through a computer browser. No, this is the IoT age, and it's crucial that all those devices can also keep your data secure. That's why Ockam is working to make it easier to implement encryption for IoT devices. If you're curious about how Ockam is doing that, be sure to check out our [website](https://www.ockam.io/).


The Diffie-Hellman key exchange is a crucial component in securing internet traffic.

Diffie-Hellman Key Exchange Explained

Diffie-Hellman Key Exchange: How Does it Work?



My presentation at the [2020 Open Core Summit:](https://2020.opencoresummit.com/)

<AspectRatio maxW="100%" ratio={16/9}>
        <iframe  src="https://www.youtube.com/embed/19PeGYB2P54" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowFullScreen></iframe>
</AspectRatio>

The following is a transcript of this recording:

# Introduction

Ockam’s Zero-to-IPO map is a key strategy input to our tactical short, medium and long-term business planning. It focuses on the one-thing that _really_ matters, at specific points in time. We live our values at Ockam, and as an open source company, we want to share our roadmap.

As outlined in the progression below, we’ve plotted a course from stoking awareness to operating an enterprise sales machine.

![Zero to IPO map](/blog/zero_ipo/zero_1.svg)

The time scale for our route to IPO is, as you’d expect, years long. Given that startups plan around funding cycles, let’s plot funding cycles as waypoints on our course. It can generally be assumed that there is 18-24 months between these waypoints.

![Funding time scale](/blog/zero_ipo/zero_2.svg)

The cloud, edge, and open source landscape continues to evolve - which means that we need to chart our own course into the future. However, Ockam’s route to IPO also considers the various ways that other companies have run the gauntlet from Zero-to-IPO. I’ve been fortunate to have been ‘in the rooms where it happened’. Over the past 10 years I’ve directly worked with well over 100 companies that were underpinned by open source software projects. I’ve seen spectacular successes, breathtaking failures, modest acquisitions, and some companies that simply fade into the darkness. I'll save those stories for another time, maybe over a beer.

In the image below are experiences that I’ve drawn from the previous decade in the open source, cloud, and developer tool space.

![Rooms where it happened](/blog/zero_ipo/zero_3.svg)

Let’s dive into each stage, in turn, to unpack what we are doing, when we are doing it, and how we are going to measure it.

# Developer Awareness

## Motion

In order to recruit our team, or for a developer to consider using Ockam, first they have to know we exist. We create and distribute a tremendous amount of content at Ockam with one goal - driving developer awareness.

For example, The first product Ockam shipped was [a blog on our Values](https://www.ockam.io/learn/how-to-guides/high-performance-team/values_and_virtues_on_the_Ockam_Team/). The second was a white paper that shared our vision. Even this post is an example!  We have a learning library that outlines our thesis on the open source ecosystem, teaches computer science fundamentals, gives insights into our team culture, and demonstrates our technology. We’ve sat down for dozens of podcasts and interviews over the past two years. Ockam’s content is based around teaching. Being an effective listener and a great teacher are core underpinnings when building an open source community.

## Metrics

To gauge awareness we track activity including page views on ockam.io, 'contact us' webform inquiries, GitHub stars, social media mentions, followers and, most importantly, applications to join our team.

# OSS Community

## Motion

This is a critically important step in our progression to IPO. Building Ockam's community is a never-ending endeavor. It takes years of focus and unrelenting attention to get this step right. For example, Kafka spent it's first 5 years in this phase as an Apache project before Confluent was started.

We have three code interfaces to Ockam, which means that there are three different personas in our community:

**Application layer developers**

Ockam’s users build systems and applications with our simple APIs, OckamD binary downloads, and hosted cloud services.

To simplify what’s going on at this stage, we create packages that any developer can grab in the middle of the night, on the other side of the world, and get a quick win for their demo day at work. You’ve got a job to be done, and we’ve got a simple solution for you. You can get it right now and we will measure your time to a technical-win in the scale of minutes.

**Partners**

Community partners build add-ons, connectors, and plug-ins to connect Ockam to other codebases, cloud services and hardware components. Examples include InfluxData, Confluent - Kafka, Microchip, NXP, MacOS, and Microsoft Azure.

**Open source developers**

Ockam’s open source builders are engaged in development of Ockam's core codebase. They attend our monthly community meetings, and are hands-on with our OSS codebase on GitHub. Their participation ranges from updating a typo in documentation, to building complex features.

## Metrics

We track Monthly Active Users across all three personas in our community:

Binary downloads, account signups, or SaaS service IOPS are all indicators of usage. As hinted above, time to ‘technical win’, for an individual developer is also paramount. We’ve defined time to ‘technical win’ as the time it takes to go from an individual developer’s initial discovery to a working prototype that includes Ockam features.

The easiest user growth to track is the number of partner integrations. Since partners engage with us 1:1 on an integration, we are highly selective and deliberate about the partnerships that we support. Eventually the development of our technical partnerships will become programmatic. Programmatic examples from my past include the partner program for Heroku Add-ons and the Azure Marketplace partner portal.

We also track the intersection of partnerships and usage. For example, the number of Ockam Daemons that run alongside Influx Telegraf, or the number of IOPS in Ockam Routers that securely move packets to a Kafka Connector.

Finally open source activity and engagement is transparent through the tools in GitHub. Check out [how we are doing](https://github.com/ockam-network) with stars, forks and commits.

# Self-serve SaaS

## Motion

This is a really fun stage for a product-and-pricing-nut like me. By this point in our journey we have users, but not customers. To satisfy investor expectations and to further fund product development, we start to feed our product development machine with revenue.

This stage is far simpler than it’s often made out to be. Here’s my basic formula;

- If you are an individual developer, then Ockam is free.
- If you are a commercial enterprise, but have not yet had a ‘technical win’ with Ockam, then Ockam is free.
- If you are a commercial enterprise, and have had a ‘technical win’ with Ockam, then you pay.

From here things get a bit more complicated. Services need to be packaged and priced. This, in my opinion, is the most challenging, but also the most fun part of product development. The classic product marketing mix (aka the 4P’s) framework is durable and applies for Ockam’s planned product offerings. In this phase we are packaging **P**roducts (say S, M, L sizes), establishing a **P**rice for each product, **P**romoting the product through rigorous segmentation and targeting, and **P**lacing it into various channels and partner marketplaces for distribution.

Ockam’s SaaS products will have a freemium pricing and packaging structure. It’s worth calling out that freemium is not a pricing strategy. It’s a customer acquisition tactic that aligns with the formula above.

## Metrics

Monthly Recurring Revenue (MRR) is the top line / key metric during this phase.

The free-to-paid funnel is another key metric since it is a leading indicator and helps to forecast MRR. We will track both conversion and velocity of our freemium SaaS users.

The metrics we track in the Self-Serve SaaS phase allow us to A/B test in our demand generation funnel. A/B testing allows us to optimize month-over-month revenue growth. The target is 10-15% MoM growth.

# Inside Sales

## Motion

Inside Sales is a channel strategy for specific types of large customers we already have. This is mainly a cultivate-and-grow tactic. Our bottoms-up, Self Serve SaaS product model feeds leads to our Inside Sales Team. This team is technical, includes sales engineers and provides world-class support.

There are two separate objectives during this phase.

- Increase MRR through an increase in our customer base, and in the average ticket size.
- Learn about Customer Acquisition Costs (CAC) for specific segments, prior to launching the Enterprise Sales phase.

Monthly recurring revenue is still our top priority during the Inside Sales phase.

What’s less obvious is the second objective. Understanding CAC prepares us for an all-in Enterprise Sales motion. Moving from here onto the Enterprise Sales waypoint is probably the most challenging. It’s fraught with peril. Many, many smart companies, with great products, and ‘developer love’ die right here.

How can that be? It’s because Inside Sales is bottoms-up and Enterprise Sales is tops-down. This means entirely new buyers, new product-marketing mix, and new internal talent. We must hold onto our developer roots, while we also learn to sell to the suits. While we are executing on Inside Sales we are doing the primary research that will help spawn a new company from our company.

This is fantastically difficult - mostly from a cultural standpoint. Fortunately there are a lot of people with a lot of scar tissue from the past 10 years - including myself - and we will push through. The key is patience. We need to use our inside sales motion to find specific beachheads to land our Enterprise Sales motion.

## Metrics

MRR carries over as our key metric from the Self Serve SaaS phase.

CAC analysis for multiple customer segments.

## Anti-Metrics

There will be noise in our Inside Sales data!

The noise is any sale that looks like it could be Enterprise Sales. Up to this point, non-recurring engineering (NRE) and enterprise-like sales don’t count as Enterprise Sales, as we define the term in the next section. Typically they are one-off deals because the motion to win these deals isn’t scalable. We will do large custom deals to gain access to smart teams that deploy interesting technology. I prefer to categorize this class of revenue as ‘business development’ or even R&D.

Why is this an anti-metric? Because other Open Source startups typically stand up a couple one-off enterprises like sales as a way to puff themselves up and to convince themselves that they are ready to move to the next phase. I strongly caution my future self to parse the noise from the signal prior to launching Enterprise Sales.

Furthermore, there are other Open Source companies that entirely bypass the Self Serve SaaS phase in favor of the chunky revenue that comes with Enterprise Sales. Those companies tend not to be product companies. They become consulting and services shops that dress up to look like primary product companies. That’s not our vision. We are a tool company. We build products.

# Enterprise Sales

## Motion

Enterprise Sales is…

really, really expensive.

When we move into Enterprise Sales we will be pushing the entire company, and all of our work up to this point, in as the ante. Hyperbolic? Nope.

An Enterprise Sales motion has extremely high CAC and long sales cycles. Both are perfectly acceptable, if there is high customer lifetime value (CLVs) in these new customers. Failed Enterprise Sales experiments result in sales person turnover, halt product development, and ultimately kill great companies.

This is why we will put forth a focused effort on our segmentation analysis while we are in the low CAC environment of Self Serve SaaS and Inside Sales.

Do I sound doom-and-gloom about Enterprise Sales?

Far from it!

The upside for running a well tuned Enterprise Sales motion is staggering. The volume, the scale, and aggregate velocity of sales that I saw, first hand, at Salesforce and at Microsoft was astounding.

Remember what our Vision is:

> To enable trust between every connected device, every cloud service, everywhere.

We can not achieve our vision without visionary leadership from innovative organizations that want to solve complex global-scale problems. We need to deploy Ockam to fleets of devices, on the scale of millions, to achieve our ultimate goal and to realize our vision.

## Metrics

Annual Contract Value (ACV) is the typical metric to follow in Enterprise sales motions. Ockam is no exception.

What’s more interesting, at the scale of Enterprise sales, is the number of nodes (machines running Ockam software) that an enterprise deploys. At the scale of Enterprise Sales, Ockam achieves compounding network effects. This is because the odds that two machines will interact with each other becomes exponentially greater at scale. This means that machines will be able to autonomously reason about trust between each other as they have unforeseeable interactions with each other. When there is trust between every device and every cloud service, everywhere, everything changes!

# Summary

![Summary](/blog/zero_ipo/zero_4.svg)

# But wait! There’s more...

I love maps. In a previous life I was a navigator. [True story]

All maps have the same problem. They are two dimensional, and we live in a multidimensional world. This is why cartographers have invented hundreds of ‘projections’ of our world.

Navigators use a projection called ‘mercator.’ This projection has the benefit of making straight lines between two points. This comes at the expense of distorting scale on the north-south axis. The map I created above is a mercator projection where our journey from Zero-to-IPO is a straight line. But there are plenty of other dimensions we still need to consider to get a complete picture.

## The ‘building’ projection

We are builders at Ockam. We are building software, partnerships, community, and a business.

I think of everything we do in layers. We need to balance moving up the stack with fortifying the foundation. We build up and out at the same time. A pyramid is a good mental model for this projection.

Below are a couple examples for snapshots of our building in different states of construction.

![Building Projection](/blog/zero_ipo/zero_5.svg)

## The ‘feedback’ projection

We scout the waters ahead by running pilots, talking to customers and making opportunistic hires. For example, even though we are currently at the ‘OSS Community stage’ we still talk to potential enterprise scale companies about their problems. We mock up product bundles and think about distribution channels that could feed Inside Sales.

Our Zero-to-IPO implies forward motion. However we continuously back fill steps previously taken with new knowledge for continuous improvement to solidify the base in our ‘building’ projection.

We continuously look to the horizon, and keep building on what we’ve already accomplished.

![Feedback Projection](/blog/zero_ipo/zero_6.svg)

## The ‘virtuous cycle' projection

I love virtuous cycles. But, who doesn't?!

To get Ockam's business model you need to understand the virtuous cycle open source ecosystems.

"Open source? But how do you make money?!" I get this question a lot. The simple answer is that we create a virtuous cycle partnership with Ockam Inc, Ockam Open Source, and all sorts of Ockam Add-ons.

For Ockam's virtuous-cycle take on open source, I recommend you [watch my presentation from Oktane 2020](https://www.ockam.io/blog/oktane_2020_the_future_of_identity/).

![The Ockam ecosystem](/blog/zero_ipo/zero_10.svg)

## The ‘technology’ projection

We appreciate the complexity of our underlying technology.

Ockam is a deep tech company. It takes exceptional people to write the code that makes up Ockam's core. It takes time to build a high performance team with exceptional people. It takes a team to build deep tech. Ockam takes time.

Here’s an example for how this has played out over the past 10 months; We are a 6 person team. We’ve received 1800 resumes, and we’ve conducted about 250 interviews over that time. ‘High performance team’ is one of our values, and we live it as a virtue. It’s something we can not compromise.

Fortunately we’ve [built a team of investors](https://www.ockam.io/blog/ockam_raises_seed_round/) that know how to build for a grand vision of the future by solving exceptionally complex problems with world class teams.

## The ‘product roadmap' projection

Ockam is a product company.

At a high level, I think of our product roadmap in the following phases:

![Ockam's product roadmap](/blog/zero_ipo/zero_7.svg)

Content is a product. I think of the pixels on this website and in GitHub as part of our product suite. All of it is focused on educating and informing our community of builders on topics related to Ockam's vision to add trust to every device, every cloud service, everywhere.

We love tools, and we know that you do too. All builders do! Ockam's tools empower developers to do complex things, simply. We think of our SDKs, binaries, application interfaces, and partner integrations as part of our tool set.

Ockam's services simplify deployment for your production environments. You have products to build, and you don't want to worry about deploying infrastructure. That's our job!

At enterprise scale, Ockam becomes an interoperable architecture for universal trust between any device or cloud service anywhere. This is what we call the Ockam Platform.


We live our values at Ockam, and as an open source company, we want to share our roadmap

Ockam's Zero-to-IPO framework is a product and GTM roadmap for open source companies

Zero-to-IPO: Charting Ockam’s Route


# How to Fight Against Code Complexity in Open Source Projects

Complex code can be hard to manage and build upon. That's especially true for open source projects, where strong open source communication is crucial for success. Since we’re building an open source company, we made [simplicity a core value](https://www.ockam.io/learn/how-to-guides/high-performance-team/values_and_virtues_on_the_Ockam_Team)—and even referenced it in the name of our company: Ockam. Our approach with software is to create simple designs that enable us to build up our systems without them ever becoming overwhelming.

In this post, we'll be walking you through our open source software design philosophy, inspired heavily by _A Philosophy of Software Design_ by John Ousterhout.

## Complexity and the Flaws of Tactical Programming

Let's start by defining what we mean when we talk about _complexity_. Ousterhout's book contains a wealth of knowledge useful to any developer, including his conceptualization of complex code. In his words, complexity is "anything related to the structure of a codebase that makes it hard to understand or improve that codebase." This is an important clarification to make. We aren't using “complex” as a euphemism for technically challenging or impressively large systems. We're using it to describe code structure that is inherently _more_ complex than it has to be.

This concept of undue complexity emerges as a result of tactical programming, or the idea of coding to completion in the fastest way possible. While it may seem like a good idea, speed comes at the cost of future efficiency. Eventually, the shortcuts you took will make improving your code challenging, and in some cases, even impossible. This is caused by a combination of unnecessary dependencies and obscurity. When modules rely too heavily on one another, you quickly get situations like the following:

![Complex Code](/blog/complex_code.png)

What causes the eventual slowdown experienced by tactical programmers? It's a result of three problems:

- _Change amplification._ Simple changes are not simple at all. Making a change requires modifying many different sections of code.

- _Cognitive load._ Developers need to know a lot of superfluous information to make changes. That supposedly simple change that ends up needing you to modify a lot of other code sections? Well, you're wasting mental resources keeping track of how that change would affect those sections. And that leads us to the third problem.

- _Unknown unknowns._ When a simple change affects so much, how are you supposed to know what will be affected? Sure, maybe you've worked on the project before and are mentally wasting energy keeping track of that, but what if you haven't made that change before? You don't even know what all will be affected and will have to be modified. Heck, you might not even know what to change in the first place. You simply don’t know what you don’t know.

So what's the alternative? We mentioned that the hare would probably prefer the short-term focused goals of tactical programming, but what would the tortoise prefer? Let's look at the alternative to tactical programming: strategic programming.

## Strategic Programming Works Long-Term

So far we've discussed what _not_ to do. Let's move on to what we prefer: strategic programming. To quote Ousterhout once again, strategic programming is the idea that the "primary goal must be to produce a great design, which also happens to work."

What makes up design-first programming? Well, a lot of things, but let's look at a common example many developers think about: what to name variables. If you're in a rush, you may resort to the developer sin of naming something "x," and then the next variable "xx," and then perhaps "xxx" and so on. That creates problems the next time someone is looking at the code and has no idea what "x" is supposed to represent.

We're big fans of long, descriptive variable names. Yeah, it may be annoying to write out a 10, or even 20 character long name. However, that energy will be worth it the hundreds of times someone looking over the code immediately understands what's going on.

Comments are another concept your future self will thank you for. Technically challenging code can be hard to parse at a glance, no matter how well-designed. Comments describing a function, or even just delineating it from other things, greatly improve the time it takes the reader to understand what's going on.

Now, none of this matters if you're not consistent in the implementation. In that case, you're just another version of the hare.

### Code With a Modular Design

In some ways, however, naming and comments are just nice, albeit useful, decorations. True strategic programming systematically affects how the code itself is written and organized. A key part of this is writing with a modular design in mind.

Modular design embraces the breakdown of programs into collections or modules that can be independently changed. Remember how a flaw of tactical programming is the recurring problem of changing one thing that then affects multiple parts of the program? That wouldn't be the case with a modular design.

Another benefit of modular design is that when you want to change one thing of the program, you don't have to worry about how other modules work, just like how the other modules aren't affected by how your changed module works. By encapsulating complexity, you greatly decrease the cognitive load changes take. And remember, this is a design philosophy, so while it does work on a module level, you can also apply it on lower levels, such as for individual functions. All the better, in fact!

We've been introducing you to strategic programming in a broad sense. It's also good to show you specific examples of strategic programming at work. Good thing we’ve been practicing strategic programming!

## How Ockam Benefits From Strategic Programming

How do we at Ockam incorporate strategic programming? Well, it's a key pillar to being able to support and connect the vast array of IoT systems.

With so many protocols to interact with, we make use of deep modules to reduce complexity. While a few parameters need to be specified no matter what, such as user-specific values like their key pairs, deep modules are made to do a lot with a little information.

We also make use of "loose coupling." This is the idea that components can be replaced or changed internally without breaking what they connect to. With so many protocols to work with, we do this with polymorphism: the ability to present the same interface for differing underlying forms.

A key component of what Ockam does is enable the sending of messages to other processes. Strategic programming allows us to do that without worrying about what's going on within those processes. Our loose coupling design ensures that how we tweak our internals won't affect how those processes interact with our messages.

If you like the idea of getting first-hand experience with strategic programming, be sure to [check out our GitHub](https://github.com/ockam-network/) for ways you can get involved with Ockam. And if you want to go more in-depth into the philosophy of strategic programming, John Ousterhout is your guide. After all, he did write the [book](https://www.amazon.com/Philosophy-Software-Design-John-Ousterhout/dp/1732102201) on it.

You can also watch my presentation on this topic here:

<AspectRatio maxW="100%" ratio={16/9}>
   <iframe src="https://www.youtube.com/embed/W2CdtvIlQCQ" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowFullScreen></iframe>
</AspectRatio>

[You can grab the slides from this presentation here:](https://github.com/ockam-network/website/tree/production/src/content/blog/assets/Fighting_Complexity_in_Elixir_Codebases.pdf)


Our approach with software is to create simple designs that enable us to build up our systems without them ever becoming overwhelming.

The Ockam approach to software design is to keep it simple by fighting complexity in our open source code

Ockam: A Philosophy on Open Source Software Design


Modern web development is about collaboration and building on the work of others. Between open source frameworks, web and cloud tools, networking and education, joining the open source development community can be an invaluable experience. The open source community is, first and foremost, an open and collaborative environment for [improving a library of existing tools](https://www.ockam.io/blog/why_we_love_open_source). Tools you likely already use!

In this post, we’ll show you how to go from open source user to open source contributor—even if you aren’t a programmer. So much about open source is community and communication, often overlooked and important areas.

## You Don’t Have to Write Code

Regardless of whether you have a programming background, the easiest entrypoint into open source is outside of code. Take documentation—because teams don’t occupy a physical office together or may not share a Slack channel, documentation is a huge part of what keeps the open source world turning.

Additionally, There's more newbies can help with, from taking meeting notes or editing READMEs to summarizing and clarifying the project’s most pressing “issues.” In fact, that makes non-code a great place for engineers to begin participation with an open source community, too.

The open source community’s philosophy is that nothing cannot be improved. You can always leave things better off than you found them, regardless of your skillset or level of expertise. This is the overall mandate taken on by an open source contributor. The system thrives on passion and personal investment. So start by finding an ongoing project you feel strongly motivated to contribute to and improve, and let your talents take it from there.

## Contribute Code to Tools You Use

Once you have a better idea of what is needed by the community, you can move on to code contributions. In this case, you’ll need some programming experience, but that doesn’t mean you need to be a senior engineer. Most projects have enough strategic direction—they need people to execute. You may spend some time searching through the vast repository of assets and flag or fix elements that can be improved. The best thing you can offer to the project in this case is your passion.

Perhaps start by looking over the project’s README for a small issue or bug fix you can work on. Don’t try to take on something too big too soon. Make sure that when you do dive in on a fix, you have communicated in forums or issue comments so you understand the problem you’re fixing. This sort of communication keeps the community all on the same page.

Additionally, look to add support for a tool you personally find useful. If you’re a user, nobody knows better than you how the user experience can be improved. Some open source projects have an integration or plugin architecture that makes them particularly good choices for expansion. You might already have an idea of what’s missing and have an idea for how to fix it. This is the project for you!

Work up to larger features by engaging with the community members working on that project and developing mutual goals. Your contributions will be reviewed by this community, so teamwork is invaluable here. You may end up one of the project’s leaders if you show enough interest in the collaborative nature of open source. That puts you in a good spot to be as open and helpful with the next generation of open sourcers as well.

## Be Part of the Community

You may have noticed a “communication” theme. Discussions within an open source community are contributions, too. They might not get committed to a repository, but good conversations move the project forward. As you can read more about in [our previous post](https://www.ockam.io/blog/where_should_open_source_communities_chat), Ockam uses GitHub Discussions to facilitate communication with its open source community. It makes sense to chat in the same place where the rest of the project elements live. Good collaboration and willingness to participate are what makes the open source community greater than the sum of its parts. No project can survive if it’s difficult to communicate.

This means: don’t be afraid to share your opinion where it’s relevant! Every contributor is part of the team—even if the project has a Benevolent Dictator For Life. If a problem falls under your area of expertise, you should have the confidence and authority to captain the solution.

At the same time, ask questions when you’re confused. Everyone there is aware of the unusual form of the work environment and knows that helping others is one of the best ways to ensure the process goes smoothly, and the team maximizes everyone’s potential.

Finally, be ready to return the favor when someone newer than you comes along. Regardless of how green you feel, when someone new joins the project, they may very well need advice or practical help you can provide. Be generous with your support and offer friendly encouragement where it feels appropriate. When everyone is communicative, generous with newcomers and passionate about their work, the open source community can be a haven of collaboration and innovation, as well as an invaluable social experience.

## Contribute to Ockam’s Open Source Community

If you’re looking for a place to make your first open source contribution, have a look at what Ockam is doing. Taking on the big problem of trust across connected systems, an open source approach is needed to make this work.

You can:

- Write a blog post (like this one) for its [learning library](https://www.ockam.io/learn)
- Add documentation (or identify areas that could be improved)
- Create or summarize issues
- Build a feature (big or small)

Ockam even has a [contribution guide](https://www.ockam.io/learn/how-to-guides/contributing/CONTRIBUTING/) to explain the process. Your first or next open source contribution could help improve our connected future!


Learn how to transition from open source user to open source contributor.

You too can contribute to open source.

How to Make Your First Open Source Contribution


So much of our information is transmitted via the internet. Naturally, we're concerned with the security of that information, whether it's your private iMessages or your credit card payment information. You ensure you utilize HTTPS and you may have even started using privacy-focused messaging apps like Signal, but how do the algorithms behind those processes actually work? Their security involves the transmission of public and private key pairs among the participants in a process called _Public Key Encryption_. The math behind public key encryption makes it nearly impossible to be compromised.

In this article, we'll explain why public key encryption is so important, how it works, and whether it can be compromised by either hackers or by a government's desired "back-door."

## What Public Key Encryption Gets Right

As its name implies, public key encryption relies on public keys, though it actually uses public and private key pairs. It’s called public key encryption as its use of public keys is what makes it unique; private keys are what most of us think of when we think of encrypting something.

With private keys, the same key encrypts and decrypts the message. Whatever method you use is reversible. Public key encryption makes use of keys that are **not** reversible, hence why it’s also called **asymmetric encryption**. Let’s go over how that works.

As typical of the people who exist solely in hypothetical computer science examples, let’s imagine two people named Alice and Bob. They’d like to exchange secure messages with one another, and they’re going to do so with public key encryption.

Both Alice and Bob have two keys each. They each have a private key; Alice is the only one who has her key, and Bob is the only one who has his. They also have a public key: something that is available to anyone. The beauty of asymmetric encryption lies in how these keys relate to one another. Something encrypted with Alice’s private key can only be decrypted by her public key. Something encrypted with her public key can only be decrypted by her private key.

We’ll get to the math that makes that relationship possible, but for now, let’s look at what that enables Alice and Bob to do. Alice can take her message that she wants to go to Bob and encrypt it with his widely-available public key. She can send that through whatever service she likes, because anyone who sees this message can’t decrypt it. Why is that? Well, because the only thing that can decrypt a message encrypted with Bob’s public key is Bob’s private key. Since Bob is the only person who has his private key, he is the only person who can read the message.

Most developers—and many individual users—have used public key encryption, even if they didn’t know that’s what was happening. Far fewer have explored the math that makes it possible. As you’ll see, it’s not as scary as it sounds.

## The Math Behind Public Key Encryption

Remember that the concept of public keys works through asymmetrical encryption. Only the other key in the pair can unlock data a key has locked. Essentially, we need a way to easily encrypt something while making it hard to unencrypt without having another key.

The mathematics behind the ability to easily lock something while making it hard to unlock relies on one-way functions. These functions are quick to compute, but hard to reverse. There’s a specific type of one-way functions useful here: trapdoor functions. These are quick to compute, but hard to reverse **without some additional information**. To tie that back to public key encryption, the corresponding key is that additional information that makes it easy to reverse.

A simple example of this is the multiplication of two prime numbers. If I asked you “What two numbers multiplied together equals 34,427?”, it’d take you a while. You’d have to go through every prime number combination to get the answer. And while computers can do this much faster, I could just come up with a 20 digit number that would take them an infeasible amount of time.

That being said, it’s simple to create such a number. You just take two prime numbers, in this case they were 173 and 199, and multiply them together. It’s just as simple to find one of the numbers if you have the other, as well.

Another example of one-way functions can be found with [modular exponentiation](https://en.wikipedia.org/wiki/Modular_exponentiation). The mathematics behind today’s encryption is much more elaborate, but are built upon functions like these.

So how secure are these functions in practicality? As previously mentioned, a pure brute force attack is easily protected against. If you have a long enough key, the heat death of the universe would happen before computers could brute force it. While they aren’t quite that long in reality, they still take an insurmountable time for there to be any use in implementing a brute force attack.

Now, that’s all assuming these functions are designed without any vulnerabilities. This becomes relevant when discussing how a government “back door” to access encrypted messaging services would work. Because, with how public encryption works, it’s frankly not possible to do so without inherently weakening the encryption. The idea behind this is that the functions would have some vulnerability that only the government would know about. That vulnerability would have to perpetuate within the math itself, and there’s no math in the world that can only be exclusively used by government agencies. If a vulnerability is created for the government, it can be employed by others. Just look at how the NSA’s development of EternalBlue, an exploit for Windows computers, was leaked and became the basis for the infamous WannaCry ransomware attacks.

We’re concerned with the integrity of public key cryptography because of its widespread use in today’s internet infrastructure. Just how widespread? Well, let’s take a look.

## Public Key Cryptography's Importance Today

We’ve discussed what public key cryptography encrypts under the broad umbrella term of “messages.” Our example used the term quite literally and discussed the sharing of encrypted messages between two people, via some messaging service such as iMessage or WhatsApp. While personal messaging between two people is indeed one of the uses, there are many other types of messages in your day-to-day life that are encrypted with public key encryption.

Take the communication between you and a website. The protocol that secures our web traffic is TLS - Transport Layer Security. It uses public key encryption, but only at the beginning of a session, as part of the TLS handshake. Public key encryption is slower than private key encryption, so it's only used to securely exchange symmetric private keys. This way, you get the speed of symmetric encryption protected within the security of the asymmetric encryption. The information you’ll exchange with a website, your credit card details with an online shop, for example, are secured because of this. There are many other security protocols that have their particular uses, and many of them use public key encryption as well.

We’ve been discussing public keys with respect to their encryption abilities, but that’s not all they’re useful for! Public key encryption is part of the larger system of public key cryptography. This includes another cool use of asymmetric keys: digital signatures.

Let’s imagine what would happen if Alice encrypted her message to Bob with her own private key. Well, that wouldn’t be very good for securing the message, as anyone can use her public key to decrypt its contents. What it is useful for, however, is authenticating that the message came from Alice. If the message can be decrypted with her public key, then only her private key could have encrypted it, and only she has that key.

In fact, this post itself was signed with a public key! It’s part of Ockam’s process that allows anyone to make contributions to the [open-source website](https://www.ockam.io/blog/ockam_website_is_open_source).

That’s just one example of many where we can encounter public key cryptography. It’s no coincidence, as once you start looking you’ll see the security of the internet truly is dependent on public key cryptography. That’s why Ockam is trying to make sure that security extends to the internet-connected devices you use every day. You can learn more at [ockam.io](https://www.ockam.io/).


Public key encryption protects your data. Here's how it does so.

Public key encryption and why it's important for internet security.

Public Key Encryption Explained


Open source projects are the building blocks of the technologies developers use today. These projects are made possible because people come together to collaboratively work on them. With contributors from all over the globe, individuals must have a way to communicate with each other. Discussions are an important part of making any open source project into a community.

The people at Ockam are [fans of open source](https://www.ockam.io/blog/why_we_love_open_source/) and you should be too. The best way to support open source projects is to be actively involved in their communities. In this article, we'll go over what communities can provide, and the places communities can come together to push their projects forward.

## The Importance of Community

Not all open source contributions are code. The goal of an open source project is to build something with the help of other technologies and people. The most productive open source projects are developed and maintained by robust communities. After all, the more people working on the project, the more fleshed out it will ideally become. That applies equally to ideas and code.

But how do you get those people involved? You’ll need a place for individuals working on the project to congregate and share what they’re doing, so other people can notice what’s happening. You want to encourage diverse voices, which will lead to better decisions for the entire community.

Imagine an open source project without discussion. Code additions and deletions would come through pull requests without any context. It would be chaotic. All those extra hands are only as effective as they are organized with one another. Community brings organization and discussion brings community.

To steward a project, you need to provide a place for your community to gather.

## Why Ockam Chose GitHub Discussions

There are many ways to organize open source discussions. It makes sense to keep the conversation close to the code. For many open source projects, this means GitHub, which provides a number of collaboration tools. In particular, GitHub Discussions is the latest addition. Ockam was part of this feature’s beta testing group and they were convinced it’s the best place to focus their community’s most important conversations.

GitHub Discussions gives users within an organization the ability to chat in the same place their code lies.

![GitHub Discussions](/blog/github_discussion.png)

From just [saying hi](https://github.com/ockam-network/ockam/discussions/137) to gathering feedback on a potential project direction, a community can use GitHub Discussions to meet around topics that surround the code.

There are other places within GitHub that still make sense for conversation. However, they can be directed _in context_:

- **Pull Requests**: discuss details within the code of a specific contribution
- **Issues**: keep conversation focused on a singular problem, not a broader topic

There are certainly times when open source projects have stretched the use cases of these GitHub features. That’s why Ockam chose to use GitHub Discussions as the primary place for their community to congregate. It’s a good fit for many other open source communities, as well.

That said, it doesn’t fit every type of conversation for every community. You might also want to look for real-time options, as well as meet your community where they are already having discussions.

## Real-time and Open Dialogue: Twitter, Slack, and More

As there are so many communication platforms these days, it can be hard to decide on which ones to use. In some cases, conversations are already happening, so it’s a matter of making sure community leaders are listening. In other cases, a community might want a different experience that feels less formal. Real-time chat and social networks are both options to consider for your community.

Starting a new forum discussion can be a big hurdle for anyone, but especially for someone new to a community. The perceived need for an extremely well-thought and serious message can keep someone from posting. This is especially true if someone thinks they have a “dumb question.” For a community to truly thrive, however, there should be outlets for the sometimes more casual real-time chats that contributors participate in on a day-to-day basis. Think about where you want to direct people for these types of messages.

Of course, they may already be happening. For an extremely casual open forum, Twitter is by far the biggest name. Tweets might be too short for a serious proposal debate, but it’s great for the smaller conversations. Also, if a discussion naturally begins on Twitter, the community can always transition it to a more permanent place.

It’s important to listen on Twitter and other public forums like StackOverflow. You can point your community to one of those, or create your own real-time destination. A few platforms to consider:

- **Slack**: The chat client of the workplace, Slack has become popular with developer communities, likely because many already have the app installed.
- **IRC**: The staple of many open source projects. [Freenode](https://freenode.net/) is an IRC network specifically for open source.
- **[Discord](https://discord.com/)**: A growing messaging platform used by developer communities that includes text, audio, and video chat options.

Ultimately, real-time and social chat may be a decision left to your community. You’ll need leaders and contributors to listen for questions. You’ll want everyone engaged in the conversation and encouraging contributions.

Regardless of how you communicate around your open source projects, find communities that help you work on what you’re most passionate about. If that happens to be making the internet more secure, then check out Ockam's [open source community](https://www.ockam.io/learn/how-to-guides/high-performance-team/join_us)!


Open source communities can chat with GitHub Discussions, but there are other options as well.

Chatting with Open Source Communities.

Where Should Open Source Communities Chat?

# A beginners guide to key pairs in cryptography

As so much of our information is transported via the internet, it’s important to safeguard it just as we safeguard information in real life.

Imagine you need to hand off an important document; you could transport it via a physical lockbox. This way, the message can’t be viewed by anyone without the key. Perhaps you take additional security measures, such as signing and sealing the document so the recipient knows it isn't fake or tampered with. These methods are done to protect information security in real life.

But what happens when the document being transported is computer data? When data is digitally transported, you must take digital security measures. Cryptography and cryptographic keys can provide this security, though cryptographic keys have many more uses than the physical keys in your pocket.

In this article, we’ll take an introductory look at the different types of keys available, and when and how they’re useful.

## Symmetric Keys: Fast & Simple, Yet Potentially Vulnerable

Let’s say your confidential document isn’t secured via a physical lockbox, but via encryption. What does this look like? The answer lies in child's play.

Children often write messages in code so that other people only see gibberish if they find them. A simple way to do this is by using Caesar’s cipher. In this cipher, you substitute letters with the letters some fixed number away. For example, if you use Caesar’s cipher with a right shift of 1, the text “Hello World” becomes “Ifmmp Xpsme”. Just like that, the message has no meaning without knowing the correct cipher. At least, in theory. In reality, the uneven distribution of letters in English words makes this cipher easy to crack. However, today's encryption methods are much more complex.

There’s a catch to this type of encryption, though. How do you tell the recipient what the shared key to the cipher is? Whether it’s a physical key to a lockbox or a key to decrypt a cipher, you need to share a copy of the key with them. It can’t be protected in the same manner, because then you’d need another key to decrypt that cipher, and then the problem reemerges. In the real world, you'd deliver the key's copy via some other method you trust. Perhaps you two would exchange the key to the cipher in a dark alley at twilight?...

The encryption of messages nowadays extends well past physical notes. With online communication, symmetric encryption does provide some security. But the same flaws exist. These flaws stem from the fact that you need both parties to have the same (symmetric) key, and you need both parties to have that same copy of the key without it being compromised. Ideally, this should be done without needing to hang out in dark alleys!

In order to get around these problems, we have additional security methods. Introducing: **asymmetric key pairs**.

## Asymmetric Key Pairs: A Slower, More Secure Method

Asymmetric key pairs are a creative way to transmit messages without exposing compromising information, like symmetric keys. Let’s go back to our lockbox example for this:

You want to send an important document to Bob, but there's a problem. If you secure the document in a lockbox, how does Bob get a key to open it? There really isn’t a way to do this. Instead, Bob comes up with an idea. He sends you his own unlocked lockbox while keeping the key. When you get the lockbox, you put the document inside, close it, and lock the padlock. Now you can send his lockbox back to him and he can open it with his private, secret, one-off key. You've managed to send a secure message without copying the secret key.

Asymmetric key pairs work similarly. Instead of a lockbox and key pair, you have a public and private key pair. The public key is just that: public. Anyone can see your public key. Your private key is something you keep under wraps; you never need to reveal it. Your public key can unlock things that were locked with your private key, and vice versa.

In our example, Bob gives you a lockbox to secure the message, and he has the only private key to open it. When encrypting online communication, you would secure the messages with Bob’s public key, and that information can only be unlocked via his private/secret key.

There are many advantages to using asymmetric key pairs. By encrypting your message with your private key, you are essentially validating it has originated from you, as you are the only one with that key. Anyone can confirm that you signed it with your private key when they can use your widely-available public key to do so. By securing the message with your private key and their public key, you get the benefits of both authenticating your [identity](/learn/concepts/machine-identities-and-credentials/) and keeping the message safe from prying eyes.

## The Importance of Cryptographic Keys

Both symmetric keys and asymmetric key pairs are used in our online communication. Symmetric keys are incredibly fast to implement, and thus are used for encrypting large amounts of data. Asymmetric keys are slower but are much more secure. This results in technologies making use of a combination of asymmetric key pairs and symmetric keys.

Remember, the biggest flaw of symmetric cryptography is the inability to securely send the key to the recipient. Its biggest strength, however, is its speed in encrypting large amounts of data. For these reasons, it’s common to establish an asymmetric key pair to transmit a symmetric key securely. Then, with the symmetric key in the hands of both the sender and the recipient, the data itself can be encrypted and unencrypted using the faster symmetric cryptography.

This combination of cryptographic keys forms the basis for many types of encryption you’ve heard about. For example, perhaps you’re aware that companies like Apple, WhatsApp, and Signal provide end-to-end encryption for their messaging services. When you’re using end-to-end encrypted messaging, only you and the recipient can read the actual messages. And how is this encryption set up? Well, by initially using an asymmetric key pair to securely provide a symmetric key to both end-users.

End-to-end encryption is most often thought of in association with messaging platforms, but that’s not the case. At Ockam we provide end-to-end encryption SDKs for IoT devices. Just like how your message is encrypted with iMessage or WhatsApp, we’re creating technology to ensure the data your IoT devices are sending are encrypted as well.


As so much of our information is transported via the internet, it’s important to safeguard it. Cryptographic keys make this possible.

Symmetric and asymmetric keys both play an important role in cryptography, the foundation of Internet security.

What are Cryptographic Keys?


# 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.


<AspectRatio maxW="100%" ratio={16/9}>
    <iframe src="//play.vidyard.com/ZGM56e47p7YRxvjj8Ec9jk.html?" width="100%" height="360" scrolling="no" frameborder="0" allowtransparency="true" allowFullScreen></iframe>
</AspectRatio>

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](https://www.okta.com/resources/oktane-content/2020/future-of-identity/).

# 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.

![The Ockam ecosystem](/blog/open_source_as_an_integrator/ockam_ecosystem_map.svg)

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?

![The Ockam ecosystem](/blog/open_source_as_an_integrator/ockam_ecosystem_map.svg)

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](https://twitter.com/ockam).

If you want to reach out to me personally, I'm on [Twitter @lilfortran](https://twitter.com/lilfortran). Our website also has links to get in touch with us. We even have a community on in [GitHub Discussions](https://github.com/ockam-network/ockam/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.


Matthew Gregory presented his view of the future of Trust at Oktane 2020. He believes that Trust in IoT will be driven by an ecosystem of open source technologies.

Matthew Gregory presented his view of the future of Trust at Oktane 2020. He believes that Trust in IoT will be driven by an ecosystem of open source technologies. This is a video of his presentation at the Okta conference

Ockam at Oktane 2020 - The Future of Trust


Modern web development involves building on the excellent work of others. Between open source frameworks and cloud tools, you can get a big boost in your projects. Indeed, that’s one of the reasons [why we love open source](https://www.ockam.io/blog/why_we_love_open_source) and why we are building Ockam as an open source centric company.

When set out to build a new version of our company website, we naturally gravitated to open source tools to get it done. This site is built with React and Gatsby. All major content is stored as Markdown in GitHub and generated as static content by Gatsby. Azure Pipelines deploy a new version every time there’s an update to our site’s code. And that repo is public—open source, even—so you can learn from, and build upon our experience for your own projects.

We’ll walk through how we built our new site in this post:

## The Ockam.io Open Source Stack
Ockam doesn't need to reinvent the wheel. The oldest websites on the internet were static HTML files without the fancy functionality that has been added to the modern browsing experience. Now with serverless public cloud technologies, these old ideas are the newest iteration of distributing content. Simple, modern tools - used in creative ways - allow developers to design and build with elegant simplicity.

Simplicity is one of our founding values, reflected in our own namesake, Ockam. Similarly to the principle of Occam’s Razor, we believe that more complexity doesn’t always mean better products. This is reflected in how we built our JAMStack website using Gatsby - classic approach reinvented for a modern product.

## What is the JAMStack?
The JAMStack is a new way of building websites using established web development tools combined with modern architectural practices. JAM stands for the three main concepts used in this process: **J**avaScript, **A**PIs, and **M**arkup. With the JAMStack, developers design component templates, generate content and website actions, and then build and bundle the website into HTML pages with a static site generator. We use [Gatsby](https://www.gatsbyjs.org) with Ockam.io.

With the JAMStack, dynamic content and functionality runs in the client's browser for a performant user experience. APIs are used to abstract out server-side functionality. Traditional websites rely on a back-end server which can be functionally replaced with serverless API calls from within the client browser. Gatsby even provides a [GraphQL endpoint](https://www.gatsbyjs.org/tutorial/part-five/#introducing-graphiql) to query your data. But the 'back-end' of our static website could be anything we want it to be with different API calls.

Finally, the website is served as an inherently static HTML (Markup) file. With a static site generator, this can be created from a source written in a format such as Markdown, which is what we used. Markdown is a straightforward markup language as it uses plain-text-formatted syntax for easier internet writing.

## Why We Chose JAMStack
There are two primary advantages for the ockam.io site to use JAMStack:

1. Generating content is simple because source is written in markdown and stored in GitHub.
2. Building and hosting are decoupled

Because Ockam is an open source code base utilizing the same workflows as the rest of our code base means that anyone can submit a pull request to add a blog post, fix a broken external link, or add documentation and code examples.

The JAMStack architecture provides several benefits, including page speed and automatic change tracking. Also, when a user requests a webpage, the html file has already been built and is served from Azure's Content Delivery Network (CDN). This is how we achieve a fast and streamlined user experience. Finally, because we serve static pages to users, there is no software layer or database to attack.

As we update our site, the changes are tracked with Git and hosted on GitHub. [The git repository](https://github.com/ockam-network/website) contains every line of code for our entire website (did we mention it's open-source?). It is continuously rebuilt and deployed to the cloud with each change.

Finally, there’s not a huge codebase for our team to maintain. Ockam engineers can stay focused on [our other open source projects](https://github.com/ockam-network) rather than reinventing the wheel with our website.

## Deployed in Azure
I spent over five years working in cloud hosting services, most recently as an 'Intrapreneur' at Microsoft. I helped guide Azure's shift to open source software and Container Services. Azure's dedication to open source software and Ockam's mission to enable a robust and seamless system design made the choice to host our website with Azure an easy one. We use Azure Pipelines and Azure CDN to build, test, deploy, and distribute our website across the world.

I suppose that the apple doesn't fall so far from the tree?

## Azure Pipelines
In order to build our website automatically, we need continuous integration and delivery (CI/CD). Azure Pipelines offers container support and the workflows we needed to orchestrate the build.

The integration with GitHub ensures anything we put in our website repo is available to the cloud. Whenever changes to the master branch are detected, Gatsby is invoked to generate the HTML files of our website. Docker instances running Node allocate the necessary resources and build tools to Gatsby in multiple containers to quickly regenerate the website and send it down the pipeline.

Pipelines not only builds our website, but also quickly deploys the new site where it needs to be. In our case, that’s Azure CDN.

## Azure CDN
A static site is already likely to load quickly. When that’s paired with a CDN, we can decrease the latency across a worldwide network. By distributing and caching our website files at locations across the globe, there is always a server nearby to quickly deliver any page to any person as quickly as possible. Azure's CDN has over 130 point-of-presence (POPs) locations across 80 metro regions worldwide. Geo-filters direct traffic to local servers for the fastest experience.

## Layer on External Services, Like Algolia and Lever
By keeping our website stack relatively simple, we’re able to easily integrate new services. For example, after we launched the first version in February, we realized it would be useful for visitors to search our [expanding Learn section](https://www.ockam.io/learn). If our site relied on a heavy CMS or custom software, that could turn into a big project. Instead, we integrated a Gatsby plugin and an external service.

We turned to [Algolia](https://www.algolia.com/)’s search-as-a-service to easily augment our static site. We call its search API via JavaScript and the [Gatsby search plugin](https://www.gatsbyjs.org/docs/adding-search-with-algolia/) ensures the content stays synced.

Because we chose a popular open source project like Gatsby, it simplified the effort. Someone had already built the Algolia plugin, which made it easy for us to implement. As we’ve said previously, [open source is the Internet’s most important integrator](https://www.ockam.io/blog/open_source_as_an_integrator/). Naturally, we also chose to make our own site open source, as well.

Another API that we call is Lever. Lever is a tool that we use to manage applications to our team, and to publish job descriptions on Ockam.io/team.

## Ockam is Open Source, Of Course!
Ockam is built on open source and we are also building open source. Our website is a key way we get our message to the world, as well as communicate with our community. A public repository and an open source license for our website was essential. But we thought that wasn’t far enough.

Every page of our site includes a prominent 'edit' link, encouraging the community to contribute back. We think it’s part of supporting the [virtuous cycle of open source](https://www.ockam.io/blog/why_we_love_open_source/). One mistake that developers make in their early career is to assume that open source contributions need to be feature releases or a brilliant piece of code. Most open source code becomes great because of little changes. If you know markdown, and the git/GitHub workflow, you could fix a typa on our site. You'd be an open source contributor and you'd be our hero. I'll mail you an Ockam hat!

We built our website with the same ethos that we’re building our Ockam — secure, performant, and dependable technology that is transparent. New modern architectures like JAMStack are open source solutions that allow us to build the best website for our developer team and for everyone else who wishes to use it.

Feel free to [fork our repo](https://github.com/ockam-network/website) and follow the instructions to build out your own static site. If you build something cool, be sure to let us know about it!

We have a ockam.io/learn section of our website. Feel free to submit a pull request to have your blog, code example, or content published!


All of the source code and build tools for Ockam.io is OSS. This is how we built it...

To build ockam.io as open source we used Azure Pipelines, a CDN, JAMstack, GitHub and a bunch of other awesome tools. This is how we did it.

Even this website is open source...


<AspectRatio maxW="100%" ratio={16/9}>
    <iframe src="https://www.youtube.com/embed/_rwsHF9HrNg" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowFullScreen></iframe>
</AspectRatio>

Hi. My name is Mrinal Wadhwa.

I'm CTO at Ockam and I'm passionate about enabling a future where autonomous machines work together,
using intelligent algorithms, to improve the way we live and work.

The status quo, however, is that most connected applications, today, are not very secure, private
or dependable ... at Ockam, we are determined to change that.

Machines, within the Internet of Things, operate by exchanging messages, with cloud services and
other connected machines.

If we wish to build applications that are secure against attackers, malware, ransomware etc.

Applications that can safely carry our customers’ private and proprietary data.

Applications that are dependable ... in crucial scenarios like health care, public utilities, transportation, and manufacturing.

If we wish to build such trustworthy applications …

Then we must ensure that the messages that carry configuration data, sensor readings, control
instructions and firmware updates ...

These messages are safe against eavesdropping, tampering, and forgery.

Regrettably, most IoT and Edge applications that are built and deployed today are unable to provide
these three basic protections… protection against eavesdropping, tampering, and forgery of messages.

These weaknesses are usually due to the following four reasons:

1. Implicit Trust in network boundaries.

A naive way to protect messages that are flowing between applications … is to create physical or
virtual network boundaries and only allow select trusted machines into such boundaries.

This, sort-of, worked when there were a lot fewer computers in the world and those computers were
fixed to a desktop or a server cabinet.

IT and OT departments have learnt that network boundaries cannot be enforced in the modern
landscape … of mobile devices, internet of things, cloud applications and a remote workforce.

It is also unrealistic to expect home users to successfully guard their network boundaries when it
is increasingly common for homes to have a large number of connected devices that come and go.

Unfortunately, many IoT and edge applications in homes and in industrial environments are still
built with implicit trust in network boundaries.

Here’s an example of a connected switch from a prominent vendor .. if anyone sends THIS message to
the switch… the switch reveals whether it is ON or OFF

If they send this other message …. the switch will turn ON.

It is trivial for an attacker to tamper or forge such messages and remotely take-control of the
switch because the embedded application code in the switch implicitly trusts all incoming messages
without authenticating the sender or validating the integrity of the message.

Secure applications should not do this they should instead place Zero Trust in Network Boundaries

Every message, that is received by an application, must carry a proof to assure that the message
wasn’t tapered or forged.


A dependable application must be able to dynamically decide if it has enough assurance to trust
and act on the information or a command received in a specific incoming message.

2. The second reason connected applications often have weaknesses is that their architecture
lacks the ability to establish **mutual** trust.

It is common for IoT application architects to take inspiration from how they design browser based
web applications and only establish trust in cloud services with one-way authentication. They
decide that it's okay to not authenticate devices because it seems too complicated to manage unique
credentials in a large fleet of devices …

And that their devices are just simple sensors … so they don’t need to authenticate or authorize them.

This is a flawed tradoff, because if their business and its customers are relying on the information
collected by these sensors, then there is incentive, for an attacker, to tamper or forge that information.

Dependable IoT applications must instead be able to mutually authenticate and authorize … all
exchanges of sensed information and control instructions.

3. The third common reason for vulnerabilities in connected applications is … poor management of
credentials.

Once application developers discern that in order to have trust-worthy,
dependable information flowing within their applications they need to mutually authenticate and
authorize all exchange of messages …

Once they discern this … they are faced with some hard challenges …


To ensure that sensor readings and command acknowledgements sent by remote devices cannot be
forged or tampered each device must possess unique cryptographic keys and credentials.

How should a system generate, deliver and store these UNIQUE credentials in a large fleet of
thousands of devices?

Every IoT development team ends up hand rolling mechanisms for provisioning keys, activating
devices and bootstrapping trust.

This is often a source of mistakes like default passwords or hard coded secrets.

Architects are faced with further daunting challenges if they wish to follow good security hygiene
and make these device credentials short-lived, rotable and revocable.

Teams shouldn’t have to design ad-hoc protocols for enrollment and access control in devices; they
need simple and proven tools to safely manage keys and credentials at scale.

4. The fourth common reason for weaknesses in connected applications is the lack of end-to-end
safety for messages at the application layer

To protect en-route messages against eavesdropping, tampering, and forgery … we usually need a
cryptographic secure channel protocol.

Most IoT message transport protocols support some way to establish a secure channel.

However, such secure channel protocols have traditionally been tightly coupled to their
corresponding transport protocols.

Their security guarantees are limited by the length and duration of a single transport layer connection.

This constraint, often leads to application architectures that violate the foundational security
principle of least privilege ... exposing applications to a vulnerability and liability surface that
is a lot bigger than it needs to be.

It is common, for messages in intelligent, connected applications, to traverse a complex path that
isn’t a simple point-to-point transport protocol connection.

To support occasionally connected devices, low power radio protocols and
containerized microservices... messages usually travel via a number of message queues and caches,
often over a series of network layer connections… before reaching their end destination.

Since, the protections offered by traditional secure channel protocols are limited by the length
and duration of a point-to-point transport connection these traditional protocols are unable to keep
our application messages safe along their entire path.

A compromise of a third party cloud service, or a network intermediary or low power radio gateway
can cause our application data and commands… to be snooped on, tampered or forged.

Secure, Private and Dependable connected applications, instead… need end-to-end trust in application
layer messages … they need end-to-end encrypted secure channels.

To summarize:
Implicit trust in network boundaries, lack of **mutual**, **end-to-end** trust in information and
commands that are exchanged at the application layer, and poor management of credentials - are the
root causes that are holding back developers from building and scaling... secure, private and
dependable connected applications.

At Ockam, we’ve built … easy to use, open source programming libraries and protocols … that make it
simple to tackle all of these core challenges.

We’ve made it simple, for you, to build dependable connected applications that place zero trust in
network boundaries and third party infrastructure.

Applications that safely exchange credentials to provide granular, attribute based, privacy
preserving, policy driven, access control over connected machines to your users.

Applications .... that communicate Securely and privately using end-to-end encrypted, mutually
authenticated channels

Applications that embrace the principle of least privilege and can be dependable parts of a
future with autonomous systems.

If you're interested in learning more about Ockam's approach to Secure Messaging, we're discussing our protocols
and architecture openly on the [Ockam Proposals](https://github.com/ockam-network/) repository and on Ockam
[Discussions](https://github.com/ockam-network/ockam/discussions), come join us.


Mrinal Wadhwa on why IoT needs Secure Messaging

Secure end-to-end encryption among distributed systems is critical for a Trust Architecture.

Why IoT needs Secure Messaging


It’s easier than ever before to create software. This results in an expanding number of tools developers can use. From various programming languages to frameworks and adaptors, someone has likely solved a technical problem similar to yours before.

The modern software developer owes their simplified experience to open source giants. Open source software is built by the community, for the community. Its wide-scale availability has led to immense popularity, especially around connected technology like the Internet. As a result, open source has become the de facto standard for things ranging from web servers to databases.

Proprietary software also sees benefits of open source. In addition to using open source, it can build upon open source interfaces to allow it to work with other tools. Not only that, but open source software’s transparency ensures security and reliability. Certainly [we love open source](https://www.ockam.io/blog/why_we_love_open_source/) at Ockam. As you’ll see in this post, its status as the most important integrator is a big reason why.

## How Open Source Became the De Facto Standard

In theory, open source software is widely used by the community because it is built with the community’s needs in mind. But how does that work out in practice? The theory holds, as open source software has become the de facto standard for many fields.

A clear example of this phenomenon can be seen with web servers. As open source software has a clear majority of the market share for in-use web servers, it would not be far-fetched to say the internet itself depends on open source. The [most popular web server](https://w3techs.com/technologies/overview/web_server) is the Apache HTTP Server, more commonly referred to as Apache, which serves around 40% of all websites. Apache is an open source web server software that was released over 25 years ago. That’s 25 years of development and maintenance by the community itself, ensuring it has the reliability people desire in the number one web server.

While open-source software is built by the internet community, that does not mean the entire community has the same preferences. It’s for this reason that not only is the number one web server open source, but the number two web server is as well. NGINX is reported as the second most popular web server, serving around 32% of websites. With it being open source as well, it’s clear that open source web servers are the standard.

Another example of open source being widely used can be seen in database management engines. MySQL and Postgres, both open source, are the [second and fourth most popular engines](https://db-engines.com/en/ranking), respectively. MySQL, whose co-founder forked it to make MariaDB, is a good example of how having open source software as the standard is good for the community, regardless of how it changes over time. If a company ever decides to make future versions proprietary, it won’t be catastrophic to the community. They can follow this method and fork the open source version to continue building off of that. Being the de facto standard causes open source software to be built with reliability in mind, but also results in continued reliability as the community maintains it.

Open source software also makes it easy to build connecting tools. An example of a company doing this is Heroku, who has add-ons that build off of these open source projects, such as [Apache Kafka](https://www.heroku.com/kafka), a streaming data service, and [Heroku Postgres](https://www.heroku.com/postgres), a managed SQL database-as-a-service. Tools like these are more likely to be built if open source projects are de facto standards, and their creation makes it even more advantageous to be familiar with open source software.

## Open Source as a Translation Layer

The [virtuous cycle of open source](https://www.ockam.io/blog/why_we_love_open_source/) encourages its use as a translation layer. Its widespread use leads to a community focus on reliability, which causes even more usage. A popular project then becomes like a Rosetta Stone for future projects.

Let’s say you’re a developer trying to connect two tools. You make the translation layer you built open source, letting others use it for their tools. As a result, those developers get the benefit of having the work for this integration already done for them, and you get the benefit of harnessing the power of the community to ensure its continued reliability. And, because it's open source, and thus owned by the community, there’s no risk of these tools becoming disconnected at any one contributor’s whim. Plus, in accordance with [Kerckhoff’s principle](https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle), there is added security when systems are designed without obscurity in mind.

With the proliferation of devices, apps, and web APIs, there are an incredible amount of tools that are integrated with each other. Without open source interfaces widely available to encourage their integration, they would be much less connected than they are now.

## You Can Connect Systems Without Building Every Integration

With so many tools available, no developer can possibly build every possible integration. Translation layers solve this problem. That’s why we chose to build Ockam to support this need. Specifically, the open source projects of Ockam address many of the needs for translation layers between devices and cloud services.

Ockam provides software development kits and hosted cloud services to securely connect your devices to popular cloud servers like Amazon Web Services, Microsoft Azure, and Google Cloud. Our tools are open source, encouraging both community introspection and contribution. Building upon open source’s natural role as an integrator, we’ve focused on a thin—but important—layer of the stack.

![Ockam Ecosystem Map](/blog/open_source_as_an_integrator/ockam_ecosystem_map.svg)

The [Ockam Cloud SDK](https://www.ockam.io/product/cloud-sdk) allows you to direct encrypted data from your edge devices to cloud services. With the Cloud SDK, there’s a trustworthy way for cloud applications to get messages from applications on these devices.

The same trustworthiness can be present if you’re connecting your edge devices to Ockam-enabled cloud applications. Great for Linux-based devices (another example of the widespread use of open source software), the [Ockam Edge SDK](https://www.ockam.io/product/edge-sdk) makes sure you can trust the data coming from them.

We believe that open source can make it easier to integrate devices and cloud services. That’s why we’re working on a number of open source tools to help the developer community. Be sure to check out the [full product list](https://www.ockam.io/product) to see how we help you navigate connected systems.


Ockam is open-source-as-an-integrator. Ockam tools create interfaces between hardware at the edge and cloud services to enable a trust across a distributed application.

We love open source software tools. If you have to integrate software systems, look to the open source community to solve your IoT worries.

Open Source is the Internet’s Most Important Integrator


A device may be in your pocket, in your home, or in the field. While it’s tempting to talk about “device security” as a singular thing, that disguises the complexity. Worse, it could keep you from recognizing how devices could be vulnerable. Much like the [STRIDE framework](https://www.ockam.io/blog/introduction_to_STRIDE_security_model/) is used to anticipate potential threats, it can be useful to consider a broad view of what device security means.

In this post, we’ll cover five common areas of device and network security you should consider:

- Authentication and identity
- Database and data ingest
- Cloud hosting
- Hardware
- Messaging

Within each, we’ll show how open source projects and services can help you maintain security best practices.

## Authentication and Identity Security
Authentication and authorization are at the heart of secure systems. Any requests that retrieve private data or initiate operations that might change a system must be secured. You want to know who is making the request and ensure they have permissions to do so.

Our partners at [Okta](https://www.okta.com/), for example, provide workforce and customer identity solutions. They specialize in giving developers the tools to make the right authentication security decisions. Yet, Okta integrates with hundreds of other tools, because security is not singular. It’s connected to everything.

“Never trust, always verify” is the motto recommended by Okta and other authentication experts. A secure system for authentication and identity gives you a place to check that a request is valid.

## Database and Data Ingest
Most applications will need to store, access, and transform data. You’ll want to ensure anything read from your data store is obtained with permission. Similarly, be careful which processes can write data—you’ll want to know you can trust its authenticity. Finally, consider other ways someone might gain access to the data, such as direct access or during transit.

If possible, encrypt the data at rest, especially sensitive data like access tokens or personally identifiable information. Always use encryption for data-in-transit, even within your own networks. For example, the distributed streaming platform [Kafka](https://kafka.apache.org/) recommends encryption whenever reading and writing data across security domains.

You may want to make your database available for public Internet access. In these cases, you’ll want to pay extra attention to how you secure your datastore. InfluxDB, for example, makes [several recommendations](https://docs.influxdata.com/influxdb/v1.7/administration/security/) for securing the open source time series database, including use of encryption, user permissions, and limited ports.

## Cloud Hosting Security
It's likely that much of your data is stored in cloud hosting where you also have servers to transmit it to devices. The early cloud may have drawn skeptics, but modern wisdom is that it’s much more secure to use the cloud than attempt to build your own physical network. However, you still have security responsibilities with cloud hosting.

The major cloud vendors provide secure defaults and tools to customize your security. For example, though any cloud is by definition a shared resource, memory and network traffic are isolated. Other customers cannot access your resources. You can use firewalls, network groups, and other tools to meet your needs while maintaining security.

Microsoft Azure, for example, [identifies several areas](https://docs.microsoft.com/en-us/azure/security/fundamentals/overview) of cloud hosting security and how to make the best use of them.

## Hardware Security
Most software, especially when running in the cloud, does not need to be concerned with hardware security. However, IOT device security obviously must factor hardware into its plan. From where the hardware is located to how you interact with it, you must seek to eliminate vulnerabilities.

If you have control of the device’s network, you can restrict access by routing public traffic through another service. However, you must often assume that a device may attach to unknown networks. In some cases, such as with phones and tablets, you can bet a device will move between networks frequently. You must depend on secure authentication, databases, and encryption, among other areas of security.

In some cases, you want security embedded on the device itself. There must be a method that allows you to trust messages received by the device and similarly know anything it sends is authentic.

## Messaging Security
IOT devices rely on messages to communicate their state and receive updates from a server. You could have secure authentication, database, cloud hosting, and hardware and still be vulnerable if you aren’t able to send secure messages between them.

Much like with databases, you want to encrypt data-in-transit. However, you can go even further with end-to-end encryption. Every point that decrypts a message expands the surface area of a potential attack. A more secure messaging system allows devices to exchange messages through a server without the intermediary knowing the decrypted contents of the message.

Ockam is building open source tools for developers to send end-to-end encrypted messages through your connected systems. We want to make it easier to build distributed systems of interconnected devices. [See how we do it](https://www.ockam.io/).


When it comes to device security think of technology stacks, not platforms.

Every layer of your application needs to be secure. At Ockam we suggest that developers think in stacks. Here's how...

IOT Device Security is Not One-and-Done


Every company must now at least dabble in software. In fact, to be competitive, many will need to make building and running software a core competency. To meet their software needs, companies obviously can’t write everything from scratch. They’ll need to work off the efforts of others.

The future for building code is around community and people. That requires an open source approach, with contributions from a large number of developers. As a result, you’ll see more reliability, security, adoption, and interoperability—all at a faster velocity.

This post covers those five benefits of open source software:

- Reliability
- Adoption
- Security
- Interoperability
- Velocity

These areas have both business and technical implications, which all lead to creating better software.

## Open source brings reliability

There’s a reason that most of the Internet runs on open source. From Linux to WordPress to most frameworks and utilities, they’re powered by open software. The level of usage encourages contributions, which encourages further usage. It’s the virtuous cycle of open source to which we all contribute and from which we all benefit.

Reliability is one of the important benefits created by the contribution/usage cycle. As a follow up to this article I recommend that you look up Peter Levine’s [presentation and blog post](https://a16z.com/2019/10/04/commercializing-open-source/) where he describes the cycle related to open source based business models. As a first step to business success in open source, Levine cites project-community fit, where a group of developers actively contribute.

As more developers rely upon an open source project, the more likely they’ll be able to contribute. One important side effect of contributions is that software becomes more reliable. It’s not just one company responsible for reliability, it’s a shared concern by the entire community that supports the project.

![The Ockam ecosystem](/blog/zero_ipo/zero_10.svg)

## Open source increases adoption

Greater reliability and usage certainly encourage adoption of open sourced code, as well. It’s not simply a matter of developers choosing what’s most popular. The availability of open source itself helps drive adoption and makes it the prudent choice.

Developers want to be able to try software they’ll rely upon and, if possible, see how it works. Open source checks both of those boxes in a big way. By its very nature, open source is available—at both tire-kicking and code-digging levels.

For example, [Ockam’s open source projects](https://github.com/ockam-network/) become more durable and valuable the more they are used by the community. The virtuous cycle comes into play here, too, which ultimately increases adoption of complicated and important security protocols for millions of developers.

Further, access to open source goes beyond any single company’s support. Developers want to adopt software they know they’ll be able to use regardless of one company’s internal decisions. Open source shines against proprietary software because it’s available now and will continue to be in the future.

## Open source creates a virtuous cycle for security.

Another area that proprietary software is deficient compared to open source is security. There’s a myth that the reverse is true, but a black box is a poor home for any security solution. Closed source software cannot be rigorously inspected, so there’s no way to know the full extent of its vulnerabilities.

Of course, being open source itself does not make software more secure. It’s the eyes of many engineers, with a vested interest in its invulnerability, that makes dependable open source security.

When issues are discovered in open source, a developer may flag it publicly. Then, the entire community may prioritize a fix. In many cases, the fix comes from the developer who identified the problem. The entire community benefits, without relying on any single company’s development timeline.

The virtuous cycle compounds the security of open source software, and everyone ends up with better tools.

## Open source unbinds interoperability

Community contributions and usage also encourage integrations between open source and other projects. The most used open source software become de facto standards, but even nascent projects benefit from interoperability.

Developers who need a particular integration may write the code necessary to connect two tools. For example, that may come in the form of implementing an interface that one of the tools expects. Frequently, that implementation will also be open sourced, or even contributed back to the original open source project. The next developer that comes along now receives the benefit of both the original project and the integration—all without business development conversations or partnership contracts.

When you look specifically at connected devices, interoperability is a big problem. There are billions of combinations of potential connection configurations. It’s impossible to implement all of the permutations.

Yet, chip makers, device OEMs, network and cloud service providers need to integrate with each other. Open source interfaces, such as Ockam's, provide the community with much more interoperability than re-creating each combination anew.

## Open Source Helps You Move Faster

The virtuous cycle of open source has many benefits. When put together, they provide developers and their employers with increased velocity. It takes time to build reliable and secure software from scratch. Yet, open source allows the entire community to gain from the efforts of many.

Open source adoption is both a benefit and a driver of the other advantages, including interoperability. When more developers can access a solution, they will build the necessary connectors, which allows the whole community to move that much faster.

For Ockam, there wasn’t another option for our business. To build components and services that developers will trust, Ockam needed to be open source. It makes developer sense and it makes business sense.

See how we enable developers to [establish an architecture for trust within their applications](https://www.ockam.io/).


5 reasons why Ockam loves open source, and you should too!

Open source software drives reliability, security, adoption, and more for IoT and edge devices.

Why Ockam loves open source, and you should too!


Everyone wants to build secure software, but it’s not simply a checkbox you select. There are a number of factors, from how you validate input to the libraries you choose that could cause vulnerabilities. Threat modeling provides a little preparation that can help you identify blind spots in your application’s security.

One common threat modeling approach is the STRIDE framework, which has six areas of focus:

- Spoofing
- Tampering
- Repudiation
- Information Disclosure
- Denial of Service
- Elevation of Privilege

Authored in 1999 by two Microsoft security researchers, STRIDE remains a useful approach to surface potential issues. In this post, we’ll cover each of the six areas of STRIDE you can use to proactively limit threats as you build your systems.

## Spoofing

When you provide access to your systems or data, you need to authenticate every request. The security of your systems depends upon trust in the other party’s identity. A threat to this trust is spoofing — when someone claims to be a person or system they are not.

There are many types of spoofing, from the teenager’s fake ID to more serious infiltration of technology systems. A major area of concern is network security, as much of our connected devices are dependent upon trusting the [identity](/learn/concepts/machine-identities-and-credentials/) of other devices. In these systems, passwords, keys, tokens, and signatures are among the methods used to authenticate requests. The level of vulnerability varies based on the method.

For example, here are some common authentication methods for systems and what would be required to spoof a request:

- **Single key**: many APIs use a single API Key to authenticate requests to their service. The value is static, though it can typically be deleted and regenerated in a user interface. Anyone who obtains the key would have access to the systems that trust it indefinitely.
- **Access token**: similar to the single key, an access token is one value that authenticates a request. However, the access is usually limited in some way, often only usable for a short period. Anyone with an access token would only have minimal usage before needing additional credentials to generate another token.
- **Signatures**: in contrast to the other two methods, signature-based authentication uses encryption, which requires private keys. Each request is signed using a shared secret that you can verify. To spoof a signature, the attacker would need access to the sender's private key.

These are just a few common examples of spoofing. The important thing to consider is what mechanism you’re using to communicate identity and how you know the identity can be trusted. Look to common methods and conventions, such as open source libraries, to ensure your systems are secure and not vulnerable to spoofing attacks.

## Tampering

Even if you feel confident in your authentication security, trust must extend to all systems you touch. When you retrieve data from a system, for example, you should feel confident that it’s reliable. Data is especially susceptible to threats of tampering, but physical machines or hardware may also be vulnerable.

Most packaged food available in the supermarket contains a seal or other method to determine whether it has been altered. Similarly, there are methods to both prevent and discover tampering with networked systems. Firewalls and partitioned storage are among the techniques you might employ to ensure your data cannot be overwritten. Log files and notifications are common methods to detect tampered data.

Often, data tampering coincides with other potential threats. For example, data may be altered to spoof access, or data tampering could be caused by artificially-elevated privileges. Further, data tampering may cover the tracks of other vulnerabilities, such as overwriting log files that would show how the system was accessed.

## Repudiation

You can’t prevent attempted security threats, but you can implement auditing to catch and trace these activities. Done correctly, you can be certain that these nefarious efforts can be connected to the source of the vulnerability. Repudiation threats take aim at your auditing and tracing, ensuring that bad behavior cannot be proven.

Have you ever been locked out of a system when you’ve repeatedly input your password incorrectly? Without logging to connect these errors to your account, it would be much harder to stop actual attackers from brute force attempts. For this reason, all events with security importance should be logged.

Secure systems should build in non-repudiation mechanisms, such that the data source and the data itself can be trusted. For this reason, repudiation is intertwined with other elements of the STRIDE framework. For example, tampered logs or a spoofed account both could lead to the user denying wrongdoing.

## Information Disclosure

Underlying the security threats mentioned so far is data exposure. Any system that stores or accesses private information may accidentally disclose it. There are any number of methods that can be used to access private data. These disclosures can impact a single user, multiple people, or be specific to a business itself.

Significant data breaches have made headlines in recent years. Passwords, payment details, and other personal data can be expensive disclosures. At a minimum, customers have to be notified and high profile incidents have extended consequences.

Along with threats like spoofing, disclosures can be caused by backups and other files left in accessible locations, which might include servers, laptops, or external drives. In other circumstances, private data can be inadvertently exposed due to buggy code or attacks such as buffer overflows.

## Denial of Service

Another security threat from the technical news, a denial of service makes a system unreachable by exploiting resources so they can’t be used for legitimate purposes. In networking, this can mean overloading a system with incoming requests, making it impossible for users to connect.

You should consider all areas of your system that might be subject to a denial of service threat. For example, storage and processing may be areas of concern. A denial of service’s impact may increase when combined with other security threats, which might give the attacker access to additional resources.

## Elevation of Privilege

The final area of the STRIDE framework could be the most threatening. Where spoofing is focused on authentication, elevation of privilege is related to authorization. In other words, the attacker not only claimed to be a valid user, but one with an expanded role.

A sophisticated elevation of privilege attack may use all of the other areas of STRIDE for an especially outsized impact. With admin access, the attacker may be able to tamper with systems outside of the typical interfaces. The lack of audit trail could cause both repudiation and information disclosure without any trace. Of course, as mentioned in the previous section, more privileges likely translate to greater resources for a denial of service.

## Use STRIDE in Your Work

Now that you know the six areas to evaluate, put it into practice. When you begin new projects, proactively consider how STRIDE applies. Either by yourself or with your team, evaluate how each area could be exploited, then plan the steps to limit each threat.

Better yet, check out Ockam's products or reach out to The Team at Ockam. We are glad to help you on your journey!


A Beginners Guide to the STRIDE Security Threat Model

How to think about security and threats in your distributed application


Check out our list of favorite links for Ockam content around the internet. We move fast, so some content out there is out of date, so we prune this list from time to time to keep things current. Enjoy.

## Blog Posts and Articles

[TechCrunch](https://techcrunch.com/2019/11/30/ockam-raises-3-2-million-in-seed-funding-to-make-it-easier-for-developers-to-secure-and-scale-their-iot-apps/)

[Silicon Republic](https://www.siliconrepublic.com/start-ups/ockam-iot-funding-future-ventures)

[Okta](https://www.okta.com/blog/2020/05/founders-in-focus-matthew-gregory-of-ockam/)

[Stacey on IoT](https://staceyoniot.com/two-startups-aiming-to-secure-the-iot/)

[State of Identity](https://oneworldidentity.com/podcast/ockam/)

[Samsung NEXT](https://medium.com/samsungnext/love-for-the-game-what-keeps-ockam-founder-matthew-gregory-going-during-the-current-situation-1c9b8e5fe31e)


## Podcasts

[DevToolsTopia](https://devtoolstopia.buzzsprout.com/1063450/5908849-the-future-of-iot-security-with-mrinal-wadhwa)

[State of Identity](https://podcasts.apple.com/us/podcast/ockam-architecture-for-trust/id1183881265?i=1000477528615)

[Diginomica](https://jonerp.podbean.com/e/solving-the-vexing-problem-of-iot-security-mrinal-wadhwa-of-ockams-open-source-community-challenge/)

[IoT for All](https://www.iotforall.com/podcasts/podcast-e007-askiot-smart-city-iot-adoption/)

[Edge Computing Association](https://edgecomputingassociation.com/opinion/founders-podcast-matthew-gregory)


## Conferences

[Oktane 2020](https://www.okta.com/resources/oktane-content/2020/future-of-identity/)

[Oktane 2021](https://www.youtube.com/watch?v=9VIjGd_uA68)

[IoT Slam '20](https://iotslam.com/session/iot-needs-secure-messaging/)


## And more...

[InfluxData](https://www.influxdata.com/partners/ockam/)

[RISC-V](https://riscv.org/membership/9902/ockam/)

[Stack Overflow](https://stackoverflow.com/jobs/companies/ockam)


Did we miss something?
Add your favorite by editing this page!


A list of links to Ockam stories around the internet

Our list of favorite links to Ockam content around the internet

Media Links

Today we are excited to announce a major milestone in the evolution of Ockam. We closed $4.9 million in seed funding from a group of world class investors: Future Ventures, Core Ventures Group, Okta Ventures, and SGH Capital. These additional resources will accelerate our mission: to enable the builders who are ushering in our shared vision of a seamless connected world.

Since inception we have forged our vision of a seamless, connected world into a simple suite of products that democratize secure IoT development. For far too long, it’s been exceptionally difficult and expensive to build secure connected device systems. These additional resources allow us to grow our high performance team, and to help the builders of IoT systems tackle their complex challenges.

# The Team

Our team philosophy is central to our values at Ockam - so much so that we refer to [“The Team”](https://www.ockam.io/team) as a proper noun. We’re grateful for all the support we’ve received from mentors, advisors, customers, partners, analysts and press. The group of investors participating in this round takes the The Team to the next level.

## Future Ventures

We are thrilled to be working with the amazing team of Maryanna Saenko and Steve Jurvetson of their newly launched [Future Ventures](https://future.ventures/). They have pushed us to think big and far into the future. Moreover they have the technical depth to grasp the complexity of the challenges that face connected device and IoT builders. Maryanna notes, “The security challenges associated with IoT are staggering. In Ockam we recognized a team capable of building a world of connected systems we can actually trust. Their collective knowledge and experience puts them miles ahead in the field." Maryanna has also joined Ockam's Board of Directors.

## Core Ventures Group

We are excited to be working with Joanna Drake, General Partner of Core Ventures Group, who brings hands-on operational expertise to The Team. Core’s focus on founders and their engaged investment model is a great fit for us. Joanna noted, “We are excited to invest in Ockam’s vision. Their approach to solve complex real world problems is a testament to the engineering and industry experience of Matthew Gregory and Mrinal Wadhwa. We are thrilled to be backing such a passionate group of builders.”

## Okta Ventures

We believe the connected device ecosystem will evolve similarly to what happened with open source software and public cloud. No one knows this better than [Okta](https://www.okta.com/). The best way to empower developers is to enable them with tools that allow them to assemble the very best stack for their application.

“Ockam shares our fundamental belief that trust begins with identity, and that integration and partnerships are essential to building trust across the ecosystem. Both Okta and Ockam have a partner-driven ethos, which is apparent in how we build our products, collaborate with partners, and empower the developer ecosystem,” said Monty Gray, SVP, Corporate Development, Okta. "We look forward to partnering with the Ockam Team as they extend identity to IoT and work to secure the devices of the future."

# What’s next for Ockam?

The next few months will be focused on extending our Team capabilities with the most passionate builders who want to join us in our mission to tackle big problems in IoT. To learn more about our plans to scale, please check out our [Team page](/team) .

We hope you’ll join us on our journey.

# About Ockam

## Ockam's Vision

Ockam believes that interoperable systems of connected devices, across consumer and enterprise, will be able to interact autonomously. These systems will be secure, trustworthy, and respect user privacy.

## Ockam's Mission

Ockam enables the builders.

We empower developers to build trustful IoT systems with our easy to use tools, methods, and protocols. We are building an open source ecosystem so that builders can collaborate on our vision.

## How We Do It

Ockam is a tool company. We make it simple to interconnect hardware at the edge with software services in the cloud.

You can use Ockam to:

* Manage identity, cryptographic keys, and credentials for devices, people, and services.
* Create cryptographically authenticated channels between devices and services.
* Send end-to-end encrypted messages across channels.


Ockam secures $4.9 million in seed funding from Future Ventures, Core Venture Group, Okta Ventures and others.

Okta, Core Ventures Group and Future Ventures team up to fund Ockam's quest to build beautiful tools for developers.

Ockam Raised Seed Funds to Empower The Builders Of A Seamless Connected Future.

At Ockam, we are breaking new ground for developers in IoT, but when juxtaposed against the broader cloud-developer-tool landscape our playbook is straightforward. Ockam has a developer experience (DX) layer that abstracts away the complexities of cloud infrastructure, cryptographic handshake protocol best practices, end-to-end encrypted messaging, embedded hardware configurations and secure key storage. The lazy way to describe Ockam is as ‘a developer platform for IoT’. Which begs the question: is Ockam similar, or does it compete with other IoT ‘platforms’, like say, the AWS IoT Platform?

*Definitely not.*

This is because ‘Platform’ is a loaded word, if not a confusing one, when talking about developer tools. What makes “Platform + IoT” even more confusing is that it implies that an existing IoT ‘platform’ could solve all of problems with IoT all on it’s own. You only need to look into the growth pains of IoT to realize that the IoT developer tools are extremely immature and that a consolidated ‘do it all’ platform doesn’t exist yet. If a platform already existed, would many IoT system still be waiting in limbo to break out of the pre-production pilot phase? Or would millions of devices still be plagued with insecure firmware and networks? I could go on and on...

I want to set context for how industries mature to really understand what the IoT Developers’ future looks like, what tools are needed, what a ‘platform’ is, and how Ockam's tools fit into this landscape. Then, I’ll map the industry maturation cycle to what I’ve experienced in the software development industry, and finally set the stage for where IoT is going and discuss how Ockam fits into the upcoming IoT developer tool stack.

## An Introduction Into How Industries Mature Through Vision, Specialization, Consolidation Phases.

When a industry or product cycle is brand new, the company that is first-to-market must be vertically integrated. This means that the firm must design, test, build, market and sell their product; They do it all. Because they are the only company that has a vision for a new industry or product they must be fully self-sufficient to bring the product to market. If they are successful and find product market fit, then the product takes flight and a new industry is born.

Eventually, the original vision for the product is limited by the expertise of that one firm. At some point specialty component entrants emerge to accelerate the development of the product or industry. Even though these new entrants disrupt full control of the product category from the vertically oriented incumbent, they greatly increase product benefits for the customer, and thus increase the total value of the market. Or to put it another way, during the speciality phase in an industry maturity cycle, specialty entrants organize horizontally and collaborate to build the category. The net result is that through this collaboration, the industry becomes so large that most slices of the market can become large sub-industries. In fact, these sub-industries are much larger than the original firm could have been if they tried to maintain tight vertical control of their entire product. This is partially due to the increase in customer utility that is derived through a steep innovation curve.

For example, imagine trying to build the first cars in the early 1900s. A auto startup needed to design every aspect from the car from the tires to the engine, and from the seats to the structure. Tire, windshield, seat, and electronics speciality OEMs would eventually innovate components that go into the automobile. The Ford Motor Company inevitably integrated suppliers into their design and manufacturing as the automotive industry organized into horizontal layers. This specialization flourished by the time the Model-T was released and Ford was able to innovate with the modern assembly line. The sum of these parts, in a horizontally organized industry with specialist parts, helped to create better customer products and drove innovation forward at a rapid pace.

There is a third phase, consolidation, that occurs when an industry matures and innovation flattens. In order to continue to drive value the major players in the industry adopt a vertical integration strategy, focus on operational efficiencies, and consume the horizontally organized suppliers through direct competition or acquisition. We can pass over this phase for the purpose of this blog post since developer tooling is still in the early, high growth, horizontal organizing phase.

## Application Innovation Breakthroughs Happen When Developer Tool Stacks Emerge.

The cloud software industry is in the horizontally organized, specialty phase. However we typically refer to the horizontal layers as components in a ‘stack’. In the 2000’s the cloud software development industry was accelerated by the LAMP stack. This stack of Operating system (Linux), Web Server (Apache), Database (MySQL, etc), and Programing Language (PHP, etc) became the basis that unlocked innovation for most born-in-the-cloud applications that thrive today. Instead of needing to create an entire platform to build a modern app, a product engineer could use the tools in the LAMP stack as a baseline to build upon.

Another reference stack emerged as speciality technologies emerged to solve problems in Big Data. The SMACK stack includes the essential tools needed to build applications around big data: Analytics (Spark), Datacenter resource management (Mesos), Concurrency in messaging (Akka), Database (Cassandra), Data ingestion (Kafka).

Finally if we look at DevOps we have code versioning and repositories (Git), code delivery (Jenkins), and infrastructure as code (Terraform, Chef, etc), containerization (Docker), container orchestration (Mesos and Kubernetes) and many, many more who can be put together to form DevOps toolchains.

Open Source developer tools were the core focus of mine while I was on the Microsoft Azure team. I worked with dozens of companies that built enterprises around developer tools so that Azure’s Open Source Software (OSS) developers would be enabled to innovate at the app layer — fast. The dev tool companies that were most successful not only produced a beautifully simple developer experience, but they also understood how their products would integrate into the broader developer tool ecosystems. This further drove developer productivity when developers built their applications around stacks.

*Everyone won.*

Azure pivoted from a tightly coupled, vertically integrated, Windows app platform into a horizontally organized, open infrastructure provider. Azure exploded into a market leading business that now generates billions in revenue each year, young OSS tool companies matured into unicorns, and app developers got to narrow their focus to their line of business applications.

Cloud Infrastructure-as-a-Service, LAMP, SMACK, DevOps, et al, stacks have enabled a cloud-native app ecosystem by allowing application developers to focus on their line of business apps. Those app companies have created billions upon billions of dollars of market value in an exceptionally short period of time as a result.

What’s equally as interesting is that each of the layers in these stacks contain example after example of wildly successful enterprises that have found a niche horizontal problem and excelled at it. We’ve seen exits from the LAMP, SMACK and DevOps stacks already. RedHat was recently purchased for $34B, MongoDB IPO’d and now has a $4B market cap, Cloudera and HortonWorks are in the unicorn club with valuations over a billion dollars, and GitHub was nabbed by Microsoft for $7.5B. There are dozens of other privately held unicorn scale companies that are thriving as specialists that build developer tools. Finally it should be explicitly pointed out that each of these commercial successes is based on an open source code base.

Not only do the IoT stacks need to be created and defined, but so do the companies that make up the specialized developer tools in those stacks. I am certain that over the next several years, dozens of newly formed companies, OSS code bases, and industry standards will emerge as developer toolchains are built for IoT. There is certainly an abundance of untapped demand, given the problems that all developers have working with IoT.

## Where Is IoT In The Maturation Cycle?
It’s just getting started…

Existing products that are classified as “IoT + Platform” are the first entrants in the market. At best, they are akin to the very first automobiles. These IoT ‘platforms’ solve incomplete and highly generalized problems. No single solution solves the full-stack IoT developer problem. We need specialty new market entrants to build the horizontally organized tools that will eventually be grouped into reference stacks.

It’s probably important to specifically call out the Azure, Google Cloud, and AWS IoT ‘platforms’ for why they were built by the infrastructure giants. These products exist because they solve a customer retention problem for the cloud providers. The Clouds are in the business of turning on VMs. IoT devices generate a lot of data. Data gravity is a strategic sticking point that helps to keep the lights turned on and dials spinning in data centers. That being said, I don’t fault the cloud providers for their strategy. I see them as part of the IoT and application stack. Ockam plans to integrate in a horizontal layer below each one.

Today’s IoT developer tools are just the tip of the iceberg for what’s to come. Specialized OSS tools will be built and they will organize horizontally as IoT matures. Dozens of companies will be built and billions of dollars of value will be created over the next decade. IoT is undoubtedly as compelling as cloud native applications and big data ecosystem stacks — so we should expect similar outcomes, and massive value to be created in both depth and scope as we did with LAMP, SMACK and DevOps tooling companies.

Ockam will be a key part of the soon-to-emerge reference IoT stack. We are focused on a Identity, Trust and Interoperability layer. We plan to make this specialized layer as simple and elegant as we can for developers. We will also integrate into other specialized layers around us. We already rely on public cloud infrastructure and plan to integrate with a big data analytics layer, so a stack will emerge. Ockam is building a new specialized layer in a new developer tool space that is tuned for IoT developers.


The Next Wave In Developer Tools Will Be The Catalyst That Enables The Internet Of Things.

Developers, just like all builders, love their tools! In this blog we will look to the past to learn how developer tools will transform security and threats in IoT

***“Ockam is tuned for connected devices”***

So what exactly goes into tuning a network for IoT? Let me tell you about the the nine-factors that influence IoT network design:

## Factor I: IoT Is Naturally Multi-Party.

One brand’s device needs to talk to another brand’s device and it needs to be controlled by an app that runs on another machine: that’s multi-party. Connecting devices is a n-squared problem. To connect nodes of a network, you need as many connections as the number of devices and apps in the system — squared. This is typically done with APIs and each device, or back-end server, needs to work with as many APIs as it is connected to. Changes to APIs require changes to firmware. This is impossible to scale across all the permutations of APIs that any one device could connect to.

Multiple parties need a simple and common way to trustfully interact. The open source Ockam is shared by the entire ecosystem — as opposed to some of the emerging IoT Platforms that are centrally controlled and operated by a potentially competitive stakeholder. The Ockam Network is designed around community building in multi-party IoT systems.

## Factor II. Cloud Technologies Are Organized Horizontally, So IoT Tools Need To Connect To Other Standards And Systems.

In a previous blog I discussed why developers hate the idea of universal, siloed, do-it-all, top-to-bottom IoT ‘platforms’. The cloud’s developer tools and services are organized into horizontal specialized layers that make up stacks. Ockam must be interoperable with other layers in an IoT stack.

Ockam Network uses a common identity standard called DIDs (Decentralized Identifiers). This makes it easy to create cryptographically secure identities for an array of entities. This feature extends not just to devices, but also possible for DIDs that represent people, organizations, or any type of entity that you could think of compatible with an did:ockam registered device. In this way, developers are able to easily codify complex graph relationships between people, organizations, devices, and assets from a multitude of cloud services.

## Factor III. IoT Relies On Knowing ‘Who Sent What Data’ With Certainty

IoT systems should rely on an immutable and unique cryptographic identity that has been claimed by each device in the network. Every time a device sends data to another device, or to a datastore, it should establish a trusted connection, encrypt the data for the recipient, and sign that data with its cryptographic key.

Ockam Network solves this by utilizing the universal did:ockam identity scheme that enables best practices around key management. Regardless of the signature cryptography capability of the device on the network, a device can generate a did:ockam that can be reconciled by any other device with a simple verification to the Ockam Registry. Every message in the Ockam Network must be cryptographically signed. This guarantees that every bit of data that moves through the Ockam Network can be trusted and any device can be certain of ‘who sent what data’.

## Factor IV. IoT Interacts With The Real World - There’s No Going Back.

IoT systems require fast finality in a state machine and require consistent data everywhere in the network. By comparison, many general purpose or financially tuned blockchain networks, are OK with temporary forks (aka data partitions) because the digital world can be corrected upon group consensus as time passes. Unfortunately in the case of IoT, finality affects real world outcomes. Consider the case of a remote controlled floodgate. If an actuator on a floodgate gets a command to open the gate, water will rush down the hill. However, after a couple of minutes if the actuator learns that it was connected to a partition of the network that had bad data, it can’t go back and put the water back where it’s supposed to be.

In distributed systems, what I just described is referred to as the CAP Theorem. The CAP Theorem states that a distributed system can not have consistency, availability, and partition tolerance all at the same time. You must pick two at the expense of the third. Because IoT affects the real world, the Ockam Network is consistency + partition tolerant (CP) orientated system.

## Factor V. The Network Should Be Close To The Device.

The closer a device is to the network the faster, and more reliable the connection is between device and network.

An Ockam Network can be distributed globally thanks to the global footprint of public cloud infrastructure that the Ockam Network is built upon. This means that an Ockam Network can be located as close as possible to any device anywhere in the world. This proximity maximizes performance between the IoT device and the Network.

## Factor VI. IoT Devices Are Already Deployed At Massive Scale, And Growth Is Only Accelerating

Future scalability is a hot topic in IoT. Today’s IoT networks need to process high volumes of data. Tomorrow’s will need to produce tremendous amounts!

The hub and zone structure of an Ockam Network solves this problem. As IoT demands increase, Ockam Network can scale horizontally by adding as many zones as are needed for throughput demand.

## Factor VII. IoT Systems Produce A Ton Of Data

A network tuned for IoT needs sufficient efficiency to accommodate the huge volume of data that IoT devices generate. In isolation, this data is of relatively low value. However the true value of IoT is unlocked when huge amounts of data feed higher order processes such as AI/ML. To put it simply: moving data in an IoT network can’t cost more than the data packet is worth!

## Factor VIII. Flexibility For Public + Private Consortiums
A device owner may only want to share data among trusted business partners. However they may also want to deliver a zero knowledge proof on the state of their data to an external regulator, partner, or customer.

The Ockam architecture allows private zones to interact with the public root zone. A private zone will commit the merkle root of its state to the main hub. This will keep the data in the zone private to the zone, but still allow permissions and proofs to be represented externally. This feature is further enabled by how did:ockam identifiers are specified.

## Factor IX. Lots Of IoT Devices Are Hardware And Connectivity Challenged, But Still Need To Validate State.

Most IoT devices are built to extremely tight tolerances and don’t have resources to spare. Low power wireless devices with simple hardware need a low bandwidth way to stay in sync with the current state of the network.

The Ockam SDK allows small devices to offload complex or always-on requirements to external servers or gateways.

…And that’s it.

Those are the Nine-Factors that go into make “Ockam tuned for IoT”.

‍


The Nine-Factors Of A Well Tuned Network Of Connected Devices

IoT and distributed systems are all unique. They are complicated. Let's look at what makes them the same.

In this week’s post we introduce Trust Architectures for connected devices. A reoccurring theme in the Ockam Blog is our position that there is a lot to learn about the future for connected devices by looking back through the history of cloud-native development.

## Why service-oriented systems rule cloud development
Over the past decade, cloud-native developers have embraced service-oriented design for their applications as ‘the rule’. APIs and micro-services are the most talked about implementations of these principles.

As a quick review of service-oriented design, most narratives focus on highly flexible code functionality that is broken down into small components. Those components make their functionalities discoverable and interoperable to other parts of the system as-a-service. Such an architecture allows these micro-services to be reused in the future via simple program interfaces (APIs). Without such decomposition, scaling applications and adding new functionality to hard-coded applications with a monolithic architectures becomes difficult, or even impossible. For example; an analytics micro-service could be scaled-up with on-demand cloud hardware independently of the user sign-in service. Or, a new feature could access that analytics service without any changes to the existing service. This is how modern cloud-native apps are able to adapt so quickly.

Open source tools, cloud infrastructure, and a community of knowledge sharing have moved best practices forward for building modern application systems with service architectures.

## Applications have moved into hardware at the edge, creating new challenges.

Modern connected devices utilize standard APIs to communicate with supporting infrastructure, and the ones that don’t, should. However, the nature of connected devices at the edge leaves much to be desired in connected device architectures; IoT devices tend to be designed from the inside out, have a monolithic code base, and are optimized for communicating with their manufacturer’s back-end web app.

Most connected devices are in physically insecure locations, scattered around the real world, outside of the cloud. As such, they are susceptible to attacks by hostile actors. At the very least, it’s practically impossible for a system architect to understand the attack surface of devices with the same fidelity that they do with applications built on infrastructure that is secured by cloud providers.

There is also an n-squared complexity with connected device integration as larger fleets of devices are installed in the field. For vast networks of interoperable systems to work together, they need more horsepower than service-oriented designs provide on their own.

## Connecting devices requires a Trust Architecture.

Service-oriented systems are built for availability, interconnection, and scalability. Application micro-services, cloud infrastructure, and security tools enable service-oriented systems to be adopted as a best practice for all developers and for all modern applications.

A Trust Architecture provides a framework that enables trusted data to flow through a service-oriented system. When a connected device is providing data to another system participant as-a-service, it must go further than simply providing an endpoint to supply data: It must cryptographically prove its identity and it must cryptographically sign all data that it sends into the rest of the distributed system. In other words, a device should serve its identity and data in a way that any other device or application can trust, anywhere in the application stack. Recipients of this data should have a common and openly available way to verify the origin and cryptographic signatures of all data received.

The only way for secure interoperability to exist among vast networks of connected devices is for devices to serve trusted data to their entire ecosystem as-a-service in a verifiable way. It’s the responsibility of devices to serve metadata that allows other services to reason about their trustworthiness — that is a Trust Architecture.

*Ockam enables a Trust Architecture.*

The Ockam SDKs allow a developer to build a Trust Architecture into cloud applications, edge gateway servers, and for embedded software. When a developer adds an Ockam SDK to the firmware in connected devices, those devices become clients to the Ockam Network, receive a unique Decentralized Identity (did:ockam), can share data as a signed verifiable claim with other devices, and can verify data that is received from other devices and entities registered with the Network. DID:Ockam is the underpinning of a Trust Architecture implementation in connected devices because it makes the identity and attestation of a device universally resolvable by any other device. With DID:Ockam in place, all services in an application can determine the trustworthiness of data from other connected devices.

Just as application developers assume service-oriented design in their web apps, they now need to adopt Trust Architecture principles when building application stacks with connected devices. Only then can billions of connected devices safely scale to serve the applications that rely upon their data. This is how autonomous systems in the future will be able to arrive at well-reasoned determinations of data trustworthiness in their ecosystems.


Introduction to building Trust Architectures

What is a Trust Architecture and how service oriented systems help us think about trust in software development?

Our company name, Ockam, is a tribute to Ockam Instruments, and it’s founder Dick McCurdy who was incredibly influential at that start of my career.

*It’s 1970…*

…the world of professional sailing is about to be disrupted;

Dick McCurdy published a white paper on “Improved Instrumentation for 12-Meter Yachts” as his Master’s thesis at MIT. This paper pioneered the idea to bring early ‘portable’ computers onboard racing sailboats so that the sailors could use wind and boat telemetry data, in real time, to make more informed tactical decisions on the race course.

Using the technology that Dick invented, the yacht Courageous successfully defended the America’s Cup in 1974. In that moment, sailing was forever changed from a seat-of-the-pants sport and into a data-driven one.

![Ockam Instruments Logo](/blog/ockam_instruments_logo.png)

Building on his success, Dick built a company called Ockam Instruments to bring simplified computing technology to all racing boats. His company was named in reference to Ockham’s Razor, which, most simply, states ‘keep things simple’.

*Fast forward 30 years, to 2000…*

Fresh out of engineering school, I was hired by the Stars & Stripes America’s Cup team to build out the instrumentation, data logging, and performance modeling systems for their race boats. The team had a long history with Ockam Instruments, but this was my first introduction to Dick McCurdy. Throughout the 3 years that I spent working on the team, Dick was a mentor, a friend, and an inspiration.

*Skip ahead, another 17 years, to 2017…*

“Why doesn’t this work like an Ockam Instruments system?!”

I said it over, and over, and over, again as I ruminated on the connected device problem I was trying to solve. The elegance and simplicity of an Ockam Instruments system is breathtaking. In contrast, managing a network of connected devices feels like a gut punch.

One day it occurred to me that I hadn’t talked to Dick McCurdy in a couple years. I picked up the phone and called him out of the blue.

After a quick catch up, I shared my story about the connected device quandary. With an aged perspective, I told Dick of the appreciation I had for his teachings about seamless system design. I also shared that I wanted to start a new company, inspired by his engineering principles.

__Ockam, circa 2017, is a tribute to the legendary Ockam Instruments.__
