Version 0.1.0

@barbara @colin @kevin @ethnic28

The @ Company
1900 Camden Avenue, Suite 101
San Jose, CA 95124
atsign.dev

Executive Overview

End-to-end encrypted everything

There is growing demand for real solutions that address the privacy concerns of consumers globally. The rise in popularity of applications with features like end-to-end encryption is but one example. But such solutions are difficult to build, expensive to operate and often insufficient in the degree that they actually deliver privacy. 

The current status quo, in which businesses collect and consolidate consumer data, results in large databases that are tempting targets for hackers. Because of this, new privacy laws such as the GDPR, CCPA, and 17 US state legislations are being implemented. Compliance with these laws is a challenge developers face today that is often treated as an afterthought,and we believe that a better approach is to use a platform that delivers “privacy by design” and assures compliance from the outset.

Thus we have created a new architecture that addresses these issues at a fundamental level, starting with a new network protocol and a modern development platform implementation that makes it easy for developers to deliver “privacy first” applications. 

If you are thinking about how to deliver applications that are end-to-end encrypted, surveillance-free, and resistant to malicious hacking, read on. The @platform is designed to make it easy to do just that.

The @ Company has created an open platform for developers who want to create applications that give people full control of their digital selves. The platform is based on the @protocol – a network protocol for the secure exchange of information only between known entities. It uses a unique identifier called an @sign that, combined with the @platform (which is based on the @protocol), allows people the freedom to share, withhold, or retract their information at will with minimal effort, and the developer no longer has to bear the cost and risk of storing and managing people’s personal data.

Technology Overview

This document describes a software platform with the necessary technology and tools to help developers create beautiful privacy-first mobile applications that are end-to-end encrypted, surveillance-free, and resistant to malicious hacking.

It is called the @platform, and is an open source project intended to make it easy for developers to develop and deploy just such applications including the requisite supporting infrastructure at no cost.

The @platform open source project is embodied in a public repository which includes a full stack reference implementation, SDKs for application developers, useful documentation, tools, samples, and examples. 

The reference implementation is licensed under the BSD 3-Clause “New” or “Revised” License. At the time of writing, a version written in the Dart language that supports the Flutter cross-platform framework has been released, with other languages and framework support expected in the future.

The technology is distributed via the Pub package manager as libraries for application developers, and via dockerhub as containers for developers’ infrastructure components.

From the Perspective of an Application Developer

The Beautiful Thing About a Protocol

There are many important and unique things that arise as a result of an architecture based on a protocol. There is ample precedence for this statement based on other successful examples (SMTP and TCP/IP come to mind). The most important things for an application developer to know about how to use the @platform are:

• Data and processing are pushed to the edge of the internet.
• Applications are based on a peer-to-peer shared data model. 
• The sharing of access to private data between application instances is end-to-end encrypted only between provable known parties to prevent surveillance, leakage, or other hijacking attacks.

These things are the result of the use of the @protocol and can seem very different from the traditional client-server or API means of sharing access to data. Thus, the mental model for such a system, especially from an application developer’s perspective, is worthy of discussion up front.

As shown above, an application developer need only use the platform SDKS to store the application data locally on the device and include an @sign to share it with; the @platform will ensure that the data gets routed to the intended destination in a safe and secure manner. This peer-to-peer model is in contrast to centralized data stores that are fraught with risk of intentional or accidental breach or exposure of private data.

A Different Way of Thinking About Data

Certainly, there are many benefits to a decentralized data model with strict control on the part of the owner, and the @platform ensures that sharing access to private data is end-to-end encrypted, surveillance free and resistant to malicious hacking. But, there are other benefits of this architecture that may not be so obvious.

People Own Their Data

While this is obvious for a “privacy by design” platform, there are additional features that arise from adherence to this principle.

Data can be portable between similar applications (i.e. swap one Calendar app for another without losing your data), which gives people more choices.

Application’s data can be shared between disparate applications (e.g. Contacts. Events, Messages) to create altogether new user experiences.

Applications can reason over “all” their data to produce compelling new services, perhaps aided by ML algorithms (with inferences executed on the mobile device in order to preserve privacy).

End-to-End Encryption

The @platform ensures that the owner of their data has complete control over it. This is a result of three basic things (though there are many more additional options available that are explained below):

1. Encryption happens at the edge.
2. The encryption keys are only available at the edge.
3. Data sharing is uniquely encrypted between the owner and the intended recipient.

Data on The Edge

A person’s private data is only available “in the clear” on either the owner’s device since only they have the keys to decrypt it or from cached data that can only be decrypted on the device of the recipient it was shared with. This removes the centralized target for hackers and makes any attempt at a large-scale data breach impractical.

P2P (peer-to-peer, person-to-person)

Also important to note is the fact that centralized, shared-tenant resources are no longer required for the sharing of access to private data. This not only saves cost, it also increases performance and security from things like denial of service attacks.

A Kind of Polymorphism

This means of end-to-end encryption of data has a very interesting side effect in that it produces a kind of polymorphism. Since the shared data is end-to-end encrypted uniquely peer-to-peer between two parties, the answer to a query depends on who is asking, and a different response may be returned for different parties for the same query. For example:

This has already been used to create some very interesting new UX (User Experience) designs and offers many other potential use cases.

Enforcing data ownership is another important concept as illustrated in Figure 3. In this system, application data becomes a combination of data created by one @sign combined with data that has been shared by others. Since the shared data is encrypted uniquely for the intended recipient, it can only be accessed by them. In addition, the owner maintains control of it (i.e. updates and deletes), though it may be cached for offline use. This means the owner can literally delete their information from another person’s phone.

The @platform Architecture (Under the Covers)

For those who are interested in the nitty-gritty details, this section covers many of the architecture and design details that have been used for the development of this project.

Functional Goals

• Provably true privacy and security.
• Support for all popular device architectures with native levels of performance.
• Robust, resilient, and scalable to internet levels.

Technical Goals

• Dependable – designed for global scale (~100 billion people, entities, or things).
• Extensible – the platform is simple and extensible.
• Near real time – data currency ensured.
• Online/offline use is supported.

Architectural Guidelines

• Modular, componentized design for flexibility and extensibility.

Design Patterns And Methodologies

Separation of Concerns
Great care has been taken when designing this architecture to apply the principles of “Separation of Concerns”. The result is a modular design that is easy to understand and maintain. 

Verbs and Verb Executors
While the SDK makes it simple and intuitive for developers to manage their data interactions, under the covers are the important use of protocol verbs. In order to ensure that verbs are handled in a consistent manner, the use of a “verb executor” repeatable pattern has been used. 

Use of Factory Classes
Across the entire project, you will find the use of factory classes to encourage ​​easy to implement, change, test, and reusable code. 

Interfaces and Implementation Classes
For the areas of software that represent modules that other developers may want to implement some other way, we have also created interface and implementation classes as a good practice of modular design.

Sequence Diagrams for the Important Flows on the Server

About Dart & Flutter

Dart is an object-oriented, class-based, garbage-collected language with C-style syntax. We selected it for our reference implementation for the following reasons:

• Dart is type-safe with both AOT and JIT compilers that are quick and reliable.
• Dart can compile to native code for most common HW+OS architectures.
• Flutter delivers near-native performance (approximately two times faster than JavaScript).
• Dart enforces object-oriented programming.
• Both Dart and Flutter have large open source ecosystems of contributors with many value-adding libraries released and many more being developed.
• The Pub package manager makes adoption and distribution of Dart and Flutter libraries simple.

Application Level Components (Starting at the Top)

One of the most compelling things about Flutter is the ability to easily integrate and manage application components (called widgets) written by others into your code. Not only does the @platform take advantage of this, it also includes a number of widgets that make it easy to develop an application, access data or take advantage of services that are provided by the platform.

Widgets (at_widgets)

The @platform currently includes the following list of widgets that are available on pub.dev as packages with the source code available on GitHub as well.

at_onboarding_flutter

A Flutter plugin project for onboarding any @sign in @platform apps with ease. Provides a QRscanner option and an upload key file option to authenticate.

at_chat_flutter

A Flutter plugin project to provide a chat feature between @signs built on the @platform to any Flutter application.

at_common_flutter

A Flutter package to provide common widgets used by other @platform Flutter packages.

at_backupkey_flutter

A Flutter plugin project for saving the backup key of any @sign that is being onboarded with @platform apps. The backup key can be used to authenticate in other @platform apps.

at_contacts_flutter

A Flutter plugin project to provide ease of managing contacts for an @sign using @platform.

At_contacts_group_flutter

A Flutter plugin project to provide group functionality with contacts using @platform.

at_location_flutter

A Flutter plugin project to share locations between two @signs and track them on OSM (OpenStreetMap).

at_events_flutter

A Flutter plugin project to manage events (time, place and attendees) using the @platform.

at_follows_flutter

A Flutter plugin project that provides a basic social “follows” functionality for any @sign. Provides a list of @asigns that follow you (followers) as well as the @signs that you follow (following) with the option to unfollow them.

Libraries (at_libraries)

In addition to the Flutter widgets listed above, there are a number of Dart libraries that provide useful functionality that can be used with the @platform as well.

at_persistence_spec

A Dart library containing abstract classes that defines what an implementation of the persistence layer is responsible for. This can be used to guide implementation of other persistence solutions for servers or SDKs as desired.

at_commons

A library of Dart and Flutter utility classes that are used across other components of the @platform.

at_client

A Dart library with the core, non-platform specific abstract and implementation classes that define what an atClient SDK responsibilities are.

at_client_mobile

A Flutter extension to the at_client library which adds support for mobile, desktop and IoT devices.

at_lookup

A Dart library that contains the core commands that can be used with a secondary server (scan, update, lookup, llookup, plookup, etc.). This library is also used for building command line tools.

at_persistence_secondary_server

A Dart library with the implementation classes for the persistence layer of the secondary server.

at_server_status

A Dart library that provides a means to check on the status of the @root server as well as the secondary server for any particular @sign.

at_utils

A Dart library that contains various utility classes such as atSign, atmetadata, configuration, and logger.

at_demo_data

A Dart library that contains test data, testable @sign credentials and demo environment variables that can be used for writing demo apps and testing with the local test environment.

at_utf7

A Dart library that provides methods to encode/decode strings to/from the UTF-7 format as defined in RFC 2152.

at_contact

A Dart library for managing contact data that developers can use for their applications.

at_base2e15

A Dart library for encoding binary data as text using a unicode string format for increased efficiency as compared to Base64 encoding. Each unicode character represents 15 bits of binary data.

at_server_spec

A Dart library containing abstract classes that defines what implementations of the root and secondary servers are responsible for.

The @protocol Verb Tree

Before we look at some of the sample code, the verb tree gives you the big picture of all of the verbs and what can be executed with the @protocol. Following this is the @platform implementation that most developers will use to develop their applications. 

It is worth noting that the @protocol verbs are involved in the secure exchange of information, either public or private only between two known parties. This requires such things as E2E encryption, key management, and passwordless, zero trust authentication. The SDKs are designed to take care of this complexity for the developer with the goal of making such security ubiquitous.

The AtClientSDK (at_client_sdk)

The AtClientSDK encapsulates the @protocol verbs and provides an application level abstraction that is familiar to developers.

Setup and Configuration Methods

The AtClientSDK requires initialization and setup. For convenience, there is a preference object with default settings that is used to configure the instance.

<setPreferences>

void setPreferences(AtClientPreference preference)

The setPreferences method sets the preferences such as sync strategy, storage path etc., for the AtClient instance.

<createClient>

Future<void> createClient(String currentAtSign, String? Namespace, AtClientPreference preference)

The createClient method is used to initialize the AtClient instance. This method accepts an @sign, non null application namespace and an AtClientPreference.

<getClient>

Future<AtClient?> getClient(String? currentAtSign)

Returns a new AtClient instance. This method requires a non null @sign.

Sync Verb Methods

The AtClientPreference model includes a parameter for how the application will handle synchronization of data to the secondary server. These can be set to one of three enumerated values.

<SyncStrategy.IMMEDIATE>

SyncStrategy.IMMEDIATE will synchronize changes to local keys immediately as they change to the secondary server for update and delete commands.

<SyncStrategy.ONDEMAND>

SyncStrategy.ONDEMAND will synchronize changes only when SyncManager.sync is invoked.

<SyncStrategy.SCHEDULED>

SyncStrategy.SCHEDULED will synchronize changes periodically once every time interval specified by AtClientPreference.syncIntervalMins has elapsed.

Scan Verb Methods

The scan verb is used to retrieve all the available keys that are either public or have been specifically shared with some @sign that has been authenticated. This has been abstracted in the getAtKeys method of the AtClientSDK so as to be more familiar to application developers

<getAtKeys>

Future<List<AtKey>> getAtKeys({String? regex, String? sharedBy, String? sharedWith});

The getAtKeys method is used to execute the scan verb and retrieve a list of all the relevant keys from a secondary server. These can be filtered by applying a regular expression [regex], by specifying the “sharedBy” or “sharedWith” @signs.

Update Verb Methods

The update verb is used to write entries in the secondary server as key/value pairs. This has been abstracted in the put method of the AtClientSDK so as to be more familiar to application developers.

<put> 

Future<bool> put(AtKey key, dynamic value, {bool isDedicated = false});

The put method in the AtClientSDK is used to write data into a secondary server as a key/value pair. The @sign must be authenticated to run this method.

<putMeta>

Future<bool> putMeta(AtKey key);

The putMeta method in the AtClientSDK is used to write metadata values for some key/value pair data on a secondary server without needing to update the value. This is done to increase efficiency. The @sign must be authenticated to run this method.

Lookup Verb(s) Methods

The lookup verbs are used to read a value from a secondary server using a key. There are several variations of the protocol verb that the SDK uses to retrieve:

• Lookup
  The lookup verb is used to lookup a value on a secondary server for another @sign’s secondary server.
• Plookup
  The plookup verb is used to lookup a public value from another @sign’s secondary server if the client is authenticated. The plookup verb can only be executed on a remote secondary server. 
• Llookup
  The llookup verb is used to lookup a value on the  local secondary server of the current @sign. 

These have been abstracted in the get and getMeta methods in the AtClientSDK so as to be more familiar to application developers

<get>

Future<AtValue> get(AtKey key, {bool isDedicated = false});

The get method in the AtClientSDK is used to read the value of some key. It first attempts to read from the local persistence store, then from a remote cloud secondary server.

<getMeta>

Future<Metadata?> getMeta(AtKey key);

The getMeta method in the AtClientSDK is used to read the metadata of some key that has been created automatically and contains useful information about the data, such as who it was created by, when it was created or updated, the current version, etc. It first attempts to read from the local persistence store, then from a remote cloud secondary server if not found.

Delete Verb Methods

The delete verb is used for deleting key/value pair data on a secondary server. The AtClientSDK also uses the term delete for its method as well.

<delete>

Future<bool> delete(AtKey key, {bool isDedicated = false});

The delete method in the AtClientSDK is used to delete the key and value from @sign’s local persistence and then syncs the deletion to the cloud secondary server according to the AtClient’s sync preference (e.g. immediate).

Event Verb(s) Methods

In order to efficiently ensure data gets communicated between secondary servers, there are two verbs that are used to manage the propagation of data events. 

• monitor

The monitor verb is used to stream incoming notifications from the secondary server to @Client.

• notify 

The notify verb is used to notify another secondary server of an update or delete to some key/value pair.

<startMonitor>

Future<void> startMonitor(String privateKey, Function? notificationCallback, {String? regex});

The startMonitor method in the AtClientSDK is used to create a persistent connection to a secondary server to receive notifications. Whenever a notification is created on the server, the monitor calls the specified notification’s notificationCallback function. Optionally, a regular expression can be passed to filter the notifications.

<notify>

Future<bool> notify(AtKey key, String value, OperationEnum operation,

   {MessageTypeEnum? messageType,

   PriorityEnum? priority,

   StrategyEnum? strategy,

   int? latestN,

   String? notifier,

   bool isDedicated = false});

The notify method in the AtClientSDK is used to propagate a change in the value for some key [AtKey] to the secondary server for the [sharedWith] @sign. Optionally, an operation can be specified and the data value and metadata can be sent along with the key as part of the notification. For rapidly changing data, the [isDedicated] parameter can be set to true to create a dedicated connection to the other secondary server.

<notifyAll>

Future<String> notifyAll(AtKey atKey, String value, OperationEnum operation);

The notifyAll method in the AtClientSDK is used to propagate a change in the value for some key [AtKey] to a list of [sharedWith] @signs. Optionally, an operation can be specified and the data value and metadata can be sent along with the key as part of the notification. 

<notifyList>

Future<String> notifyList({String? fromDate, String? toDate, String? regex});

The notifyList method in the AtClientSDK returns the list of received notifications of an @sign. Optionally, notifications can be filtered by from date, to date, and regular expression.

<notifyStatus>

Future<String> notifyStatus(String notificationId);

The notifyStatus method in the AtClientSDK is used to check the status of a notification based on a notificationId.

Stream Verb Methods

The @platform supports streaming connections in addition to asynchronous connections. The stream verb is used to create a direct connection between two AtClient instances that are joined together on the originator’s secondary server that can be used to send an encrypted stream between two devices with @signs.

<stream>

Future<AtStreamResponse> stream(String sharedWith, String filePath, {String namespace});

The stream method in the AtClientSDK creates a persistent connection for encrypting and sending a file from a device [filePath] to a [sharedWith] @sign.

File Sharing Methods

The @platform also includes a “store and forward” means of securely encrypting and sharing binary data (files) using a filebin2 service as a temporary storage mechanism. 

<uploadFile>

Future<Map<String, FileTransferObject>> uploadFile(List<File> files, List<String> sharedWithAtSigns);

The uploadFile method in the AtClientSDK can be used to upload a list of files to a filebin for temporary storage and then shares the file download url with [sharedWithAtSigns]. The method returns a map containing each sharedWithAtSign as the key(s) and [FileTransferObject] as the value(s) which contains the information required to download and decrypt the file. 

<downloadFile>

Future<List<File>> downloadFile(String transferId, String sharedByAtSign, {String? downloadPath});

The downloadFile method in the AtClientSDK can be used to download a list of files for a given [transferId] that has been shared by [sharedByAtSign]. Optionally, you can include a [downloadPath] to download the files.

Config Verb Method

The config verb is used to configure block list entries in the secondary server. If an @sign is added to the block list, then connections to the secondary server will not be accepted.

Verb Parameter Reference

required* optional’

Service Level Components

Root Server (at_root)

The root server is responsible for storing and retrieving the addressable location of an @sign’s secondary server. The architecture is highly distributed and horizontally scalable to internet levels (~50BN endpoints). The information it contains is public and it contains no personal information whatsoever.

Secondary Server (at_secondary)

The secondary server is an internet accessible microservice that is responsible for orchestrating the secure exchange of information between @signs and synchronizing data between the AtClient instances on an @sign owner’s various devices.

It is important to note that private data stored on a secondary server contains only data that has been encrypted on the data owner’s device and the keys are only accessible on that device. As a result, it is “provably true” that nobody else, including us, has access to private data.

Containers

Docker is used as a standard container format and public images are published on the  Docker Hub service for finding and sharing container images.

Container Management and Orchestration

Any container orchestration system can be used as long as it can use the Docker container standard. Both Docker Swarm and Kubernetes are used by The @ Company.

Privacy and Security

Since the architecture is one of the best “privacy by design” implementations around, people by virtue of the implementation itself have complete control of their data which is encrypted both in use and at rest. As the operator of some of the infrastructure that is deployed, we use best practices to ensure that the infrastructure is reliable and resilient to prevent denial of service attacks.

Supported Platforms

Dart, the underlying programming language that the @platform is coded in, can be compiled into native binaries for ARM32, ARM64, and AMD64 on Windows, OSX, and Linux operating systems and with the use of the Flutter framework, IOS and Android.

Dart can also be compiled to JavaScript Web but with some limitations.

Summary

This white paper has outlined the intent, architecture and implementation of the @platform that developers can use to create “privacy first” applications with advanced security features built into every exchange of data.

Our intention is that this will herald a new generation of applications that are end-to-end encrypted, surveillance-free, and resistant to malicious hacking. Please join our rapidly growing community and build something, contribute to the open source project, or just give us your feedback. 

This is important for all of us.

Who?
For IoT device manufacturers, solution owners, and systems integrators, who need a futureproof solution, data security, and privacy compliance; and want simple, scalable, provisioning. The ZARIOT/Atsign (formerly The @ Company) solution provides the answer using SIM-based, end-to-end encryption from device to application, and beyond, to users, management platforms, legitimate 3rd parties, and more.

Why?
This solution can be retrofitted to any cellular device with an eUICC SIM and can bring a level of security to “things” that previously missed certification processes. Unlike other solutions, this does not leave data visible at any point, provides provably security and privacy, and does not require added device hardware.

Overview

ZARIOT and Atsign have partnered to provide an important step forward in securing the IoT industry. The innovative Atsign security technology combined with the connectivity and SIM expertise of ZARIOT simplifies the delivery of IoT solutions, making projects more effective and faster to deploy while providing all important end-to-end encryption, controlled data access, and futureproof security and provisioning.

The partnership extends the security model to include true end-to-end encryption of IoT data by integrating the open-source atPlatform, and using the SIM as a root of trust. This comprehensively secures the data plane, in addition to the existing security for the cellular control plane. It also radically simplifies the ability for applications to access data from IoT devices securely.

Solution at a glance

Keys on SIM
Any format of eUICC SIM (removable, embedded, or iSIM) can be used as the device’s root of trust referenced to by the atPlatform service to enable complete control of data security to and from the application server. The move to eSIM/iSIM form factor fully supported by ZARIOT, further enhances security as it hampers physical access making the keys even more difficult to tamper with.

Secure Provisioning
Data between known parties can only be decrypted using the secret encryption keys, held only by the respective parties i.e., the end device or user, the secondary server has no visibility. The necessary private keys are created on activation and are only held and known by that edge device, fully protecting data integrity and privacy. Initial unique parameters are loaded in real-time automatically by the mobile network simplifying provisioning.

True Privacy
The open-source atPlatform defines true end-to-end encryption and ensures secure exchange of information, exclusively between known trusted entities. The system uses an innovative design proxying encrypted data via a secure secondary server, meaning devices are never contacted directly.

Beyond the Application
The protocol has been implemented with open-source tools and technology, enabling solution owners and designers to easily incorporate it into their solutions, and expand the use of user authentication further into their application to include users, management and administration and even possibly trusted 3rd party access. However, at all times under the auspices of the data owner’s control.

01. Solution in Action – The Hypothetical Story of ACME Widgets

ACME is based in Spain and are implementing a variety of IoT devices in their digital transformation. They have an existing hybrid cloud, but IoT is something new for them and requires the project to be designed from the ground up. ACME are very security aware and in their traditional business have employed excellent IT protection but they are looking for something new, innovative and effective to support IoT.

Requirements

• Full security of IoT devices, connectivity and their application
• Data privacy: consumer protection and regulation compliance
• Improved customer experience
• Easy deployment and provisioning
• Simplified maintenance and administration

Challenge:

This customer journey will demonstrate how the ZARIOT and Atsign solution addresses each of these needs through:

• Secure IoT connectivity for the long-term
• Data privacy as a right and experience
• Consumer protection and regulation compliance
• Easy, efficient security and management at scale
• Simple provisioning and retrofitting
• Flexibility to support the evolution of the solution over a lifetime
• Straightforward, futureproof partnership experience

02. Secure IoT Connectivity for the Long-term

Challenge:

Current IoT solutions require networks and applications to provide the security of the device and data. This demands security at every layer in the network.

• Unlicenced spectrum connectivity is not subject to the same level of national regulation or enforcement rigour as licensed and therefore potentially has long term risks.
• All connectivity options have inherent vulnerabilities that could cause breaches of sensitive data or disruption to operations if exploited

Solution:

Standards-based, global roaming connectivity within the licensed spectrum, fully secured to mitigate all known attacks, including data interception and denial of service.

Why Cellular?

ACME decide to use cellular connectivity, as their IoT widgets can be anywhere and cellular coverage is ubiquitous. They also see further security advantages in mobile networks being fully standards-based and using reserved licensed spectrum. Additionally, their legal department have highlighted that the global push for regulation means cellular access is probably seen by worldwide administrations as a long-term connectivity strategy for IoT. As they had done with their device manufacturer, who had successfully completed their GCF and CE self-assessment criteria, ACME do due diligence selecting their connectivity provider. They value a flexible, dynamic, and committed partner to help deliver the project rather than just sell them connectivity.

Secure Cellular

ACME performed a risk assessment, and are quite aware that while cellular does provide the most robust connectivity, it still has security issues, so decide on a security focused option with ZARIOT, recently awarded “Best Mobile Authentication and Security Solution” at Mobile World Congress 2021 and shortlisted again in 2022.
ZARIOT are experts in mobile security, and operate a secure network core, which protects ACME and their customers from mobile network signalling attacks such as DoS, location tracking and data disclosure.

This is crucial to an end-to-end security strategy, however there are some vulnerabilities left to address: to protect the device from DoS and data interception via fake base stations (fake cell towers), ZARIOT have incorporated an Anti-IMSI catcher SIM applet.

ZARIOT also offers a VPN to protect data as it travels from their network to the application server location. However, ACME require even more robust data security. Through partnership with Atsign, ZARIOT is able to deliver an end-to-end-encryption solution that uses the SIM itself as the root of trust.

03. Data Privacy as a Right and an Experience

Challenge:

• Current solutions provide end-to-end encryption between an accepted TLS Client and a TLS Server. Beyond this, data is exposed so true end-to-end encryption data security is needed.
• Current encryption solutions rely on hyperscalers.
• Encryption solutions provide encryption from device to datacenter or application but do not extend to the user or other end entities, creating vulnerabilities at the edges.

Solution:

To provide true end-to-end encryption, network layer data security for any cellular IoT device, without additional hardware requirements.

 Simple, Light, and In-House

Device to application data protection is absolutely integral to IoT security and privacy, and can be provided by GSMA’s excellent IoT SAFE program. The program uses the SIM as a tamper-proof security element to store the encryption keys i.e., the root of trust. However, ACME had thought they could not use this solution as IoT SAFE requires the use of one of the hyperscaler’s (AWS, AZURE, GCP) clouds.

The ZARIOT and Atsign SIM-based solution works very similarly to the IoT SAFE program, but allows ACME to continue to utilise their previous infrastructure investment, inhouse capabilities, and processes. This also represents a significant saving at the point of manufacture as they do not need to deploy a separate secure element or Trusted Platform Module (TPM) in the widget but can simply reuse the SIM.

 Zero Trust

The ACME project team are satisfied that the encryption secures privacy and security of data to their trusted environment. But sensibly, they employ a “Zero Trust” strategy, so protection and encryption must also be maintained within the local network.

Quizzing ZARIOT and Atsign on the point, they received an unexpected response and one that opens a raft of opportunities to innovatively secure and simplify device administration, customer access and GDPR overhead.

End-to-End NOT End-to-Environment

The ZARIOT/Atsign solution is not “device to environment”, it is true “end-to-end”.

The atPlatform exclusively enables encrypted communication, only between the end entities, and this is achieved by using an atPlatform secondary server as a proxy.

Described simply, the ACME widget reports its data to the secondary server using the encrypted data path.

The data is cached with access restricted at designated levels to various nominated individuals controlled by the device or user, who likewise communicate to the secondary server using the same encrypted connection as the widget.

For some ACME IoT services which consist of an IoT device controlled by a smartphone enabled with the atPlatform, the end-to-end encryption is all the way from the device to the user’s hand.

• ACME Widget updates its data too secondary server with each element of data encrypted so it is only exposed & available to nominated users or tools via their individual secure signatures (keys).
• ACME tools and users can only see or adjust data of widgets open to them and the restrictions on that data allocated.

04. Consumer Protection and Regulation Compliance

At present, IoT hosting providers are potentially able to access data from the device. Data protection, if any, currently relies on the hope that the solution design includes network access security and application layer policies that are nearly impossible to enforce.

 GDPR, HIPPAA, and more data privacy regulations are being passed and enforced. Increasing cybersecurity regulations on consumer products creating greater need for provable data privacy, consent, and control. These permissions and configurations are difficult to administer and costly to manage.

Some devices have multiple data sets that require different levels of privacy, and must be accessed by various 3rd party entities with unique access to only the data they are allowed to see.

Solution

To put the end user in control of their data, and ensure that only the intended recipients of the information can access it, with no intermediaries (including ZARIOT and Atsign) able to intercept, regardless of where the data transits or is stored.

 Server Access is Not Data Access

The above scenario maintains the Zero Trust philosophy, but ACME’s CISO is understandably now suspicious of the secondary server. They employ some experienced white hat hackers to provide penetration testing to discover any vulnerabilities. The penetration testers are able to access the ACME network via a phishing ploy. “Naive Neville” in accounts opened a corrupted cat picture, allowing the hackers to move laterally through the network to the hosted server and successfully attach to the operating system with admin privileges.

This exposes the secondary server completely. However, they find all of Atsign data is encrypted and they would need the keys of two end parties to read the information. Even then, it would be the subset they directly share with each other. While deeply disappointed in “Neville from accounts” the CISO realises that the data storage is provably secure, and they can rest easy that their customers’ privacy and own GDPR responsibilities are met. 

User Personas for Tailored Access

Since the atPlatform is end-to-end encrypted, each communication is point to-point and unique. This, in turn, means every interaction can be tailored, with the widget effectively sharing different data depending on who asks.

The ACME COO immediately asks for each department to get its own persona to access and manage their appropriate data securely. They realise that this could be a real differentiator for personal information.

GDPR Made Simple

The ACME widgets can collect a lot of information, but ACME have a strong policy on customer privacy. They only store and use the minimum information unless the customer explicitly consents for ACME to retain more. This is hard to administer and can cause expensive calls to customer services to explain and setup.

As “@” communication is locked to an end-to-end encrypted, 1-1 communication, the COO resolves to allow each customer to open their own widget information settings, and to control at any given moment which information they share with ACME and/or other entities, and for how long. This helps ACME maximise their potential functionality and the customer retains complete control over their data. The ACME COO is very happy with mitigation to their GDPR overhead and thinks there could be more options, so decides to call a meeting with the more commercial departments to brainstorm how else this can be utilised.

“The EU General Data Protection Regulation (GDPR) is among the world’s toughest data protection laws. Under the GDPR, the EU’s data protection authorities can impose fines of up to up to €20 million (roughly $20,372,000), or 4 percent of worldwide turnover for the preceding financial year—whichever is higher.” Source: www.tessian.com

Omnichannel Communication

The sales, marketing and accounts are full of ideas, from reducing administration by allowing customers to update their own addresses and contact details, to being able to allow users to dynamically opt in to new promotions and features. However, the head of the ACME customer contact centre is most excited.

If integration to the CRM was possible, the customer service agents could not only have access to client-administered data, but the customer could retain and make available all their conversations with ACME on demand. This would mean that however they contacted the ACME representatives, whether through chatbot, WhatsApp, or SMS, the info would be available to the agent. This massively improves the customer experience and is a step towards the ACME goal of Omnichannel interactions with the customer base.

05. Easy, Efficient Security and Management

Challenge:

Network addressability is a challenge that requires VPNs or on-premise gateways which are costly, complex and present security risks.

• Securely storing crypto keys centrally is a risk that is difficult to mitigate.
• IP network firewalls are expensive to implement and maintain, and difficult to manage for a mesh of internal and IoT network traffic.
• To access devices, many solutions require the use of a static IP, which are easy to find and attack.
• Lock-in effects can impact the future of a company, making business growth inflexible and difficult.

Solution:

Eliminate the requirement to use gateways or VPNs to access IoT devices, static IP addresses for devices, and reliance on other security infrastructure such as firewalling. Prevent lock-in with the use of open-source technologies and increased flexibility, and decentralise key storage.

Flexible Architecture for the Future

The ACME project team are highly skilled IT professionals and are naturally suspicious of solutions they have not tested. Many of their devices have lifecycles of a decade, and they are wary of long-term dependence on technology provided by vendors.

As The atPlatform is open-source, they realise there is no lock-in, which increases ACME’s business flexibility in the future.

The team are further put at ease when they find they can host the whole solution within the ACME hybrid data centre cloud environment.

They can connect directly from their network to the ZARIOT network via a private LAN, facilitated by a VPN tunnel.

 Fully Encrypted Keys

Where are the atPlatform keys held? The private keys only ever reside on the ACME device’s SIM, individually created by the device itself, never shared, and only written securely to the ZARIOT SIM by encrypted communication.

 No Static Ips

Having resolved the question of the secondary server security, the ACME CISO considers the impact of all the widgets on the network and asks the white hat hackers to attack the widgets

and report back on the devices, firewalls, and other security infrastructure that protect them. Happy for the extra work, they ask for some test widget IP addresses they can use.

ACME operations team tell the CISO that they haven’t been asked to provide any IPs. On investigation he finds that the atPlatform proxying the data via the secondary server means that the ACME devices only communicate in one direction, so there is no need for static IPs. If you can’t reach the device, you can’t hack it. “Great,” thinks the CISO, it is secure and it will significantly reduce his firewall budget, but he does wonder how on earth the COO will manage all these widgets.

Data Management

Prompted by the CISO, the ACME COO decides to take a much closer look at widget administration.Initial deployment is zero touch, so it is very straightforward using the ZARIOT API, but what happens afterwards? How can you communicate with the widget to get its data or change its settings?

The ACME engineering team explain their test findings. If the widget is offline for any reason, it doesn’t stop you looking at its data, because the data is all held on the secondary server. Not having to directly interrogate the device has additionally removed a potential delay in data availability. This significantly improves the customer portal experience that has caused them issues previously.

Simplified Updating

Updating the widgets is also simplified as the secondary server is the master database. The engineering team explain that by simply making a change on the secondary server means that when the widget next connects, the synchronization will update the settings. Each device has its own data, so changes can be managed for the whole deployment base or for individual units.

Visibility at all times, coupled with the database being incrementally updated on each communication, means that any changes are quickly and easily detected.

This allows very quick identification of any unexpected differences or changes to data or software, allowing ACME to react before issues occur.

Device Performance

The ACME widgets are wide ranging and have various functions, and therefore connection characteristics. These are supported by the comprehensive ZARIOT coverage, providing access to multiple networks in each country with the most appropriate type of cellular service.

Some of the widgets are very low power devices (LPWAN) so remain dormant when not in use in order to maintain battery life.

While dormant in Power Saving Mode (PSM) or Extended Discontinuous Reception mode (eDRX), they are only contactable on “Paging Occasions”, at small regular intervals for PSM or the short periods after data upload for eDRX. The ACME engineers recognise that the minimal incremental updates provided by the secondary server synchronization at the time of data upload mean that they can optimise the use of the “Paging Occasions”. They tell management this will need testing but that it could possibly boost battery performance.

06. Simple Provisioning and Retrofitting

Challenge:

• Provisioning is costly and slow.
• End-to-end encryption solutions based on industry standards require lengthy certification and cannot be retrofitted to existing devices.
• Designated secure storage solutions require a separate secure element or TPM, which adds cost and complexity.

Solution:

ZARIOT/ Atsign provides simple provisioning options that reduce cost while increasing security. Ensure that the technology can be retrofitted to suitable existing solutions and devices, and enable cellular IoT applications to easily incorporate these advantages without additional hardware cost.

Zero Touch Provisioning

The process is zero touch for the device on delivery of the ACME widget, achieving an effective, easy deployment and excellent customer experience, while securing all the data to the ACME environment. The process is explained to ACME from the point of manufacture.

1- Bootstrapping
KIGEN, the partner SIM manufacturer provide SIM with default ZARIOT profile to support bootstrapping.

2- SIM Profile
Using bootstrap detection, ZARIOT informs KIGEN that the @ enabled profile should be used. This is updated via the Remote SIM Provisioning (RSP) platform. The profile adds the file structure, atSign (a derivation of the IMSI), secondary server details, and temporary symmetric key.

3- Connect to Server on Boot Up
The ACME “@” secondary server IP address is internally locked down and routable via the ZARIOT network using VPN. Once the widget boots up and connects to the cellular network, it can then use the secure data channel to ACME and communicate with the hosted secondary server.

4- Private Key on SIM, Public Key to Server
Using bootstrap detection, ZARIOT inform KIGEN that the @ enabled profile should be used.This is updated via the Remote SIM Provisioning (RSP) platform. The profile adds the file structure, atSign which is a derivation of the IMSI, secondary server details, and temporary symmetric key.

Retrofit to Existing Devices

The ACME engineers have a wide range of widgets to support, and ubiquitous end-to-end encryption of all data across the install base really helps.

However, as a company, ACME expands not only through in-house innovation but also through acquisition.

The latest acquisition, a security camera, would obviously benefit from encrypting the video stream, but it is already deployed.

The good news is that the cameras use the new network programable eUICC eSIMs, and after discussion with ZARIOT, ACME have discovered that the SIM profiles can be remotely updated.

This allows ACME to retrofit the same connectivity and security to the deployed cameras as the green field widgets, homologising the whole install base and avoiding the need to send engineers onsite. This creates a huge saving in both time and money.

atPlatform Deployment Options

Deployment with Layered Encryption
Add end-to-end payload encryption layered on top of current TLS encryption. The existing capabilities for remote provisioning of network credentials remains as is. From there, device access and data encryption key pairs are generated on the device, never leaving the device and are thus more tamper resistant.

Device-Originated Connectivity
End to end encryption with device originated connectivity eliminating the need for device side TLS Client certificates

In this case, the device always initiates connectivity sessions to TLS Servers, removing the need for a device side TLS Client certificate, IP connectivity, gateway, VPN or special firewall configuration as a result.

This further simplifies the provisioning process and increases accessibility through firewalls, etc.

07. Straightforward, Futureproof Partnership Experience

Growing Partnerships

IoT connectivity and security need to be as agile as your business to be successful and this can only be achieved when all vendors in the ecosystem work together to deliver a shared ultimate IoT solution goal.

The Atsign/ZARIOT partnership brings together innovative security technology and connectivity expertise to simplify the delivery of IoT solutions, making projects more effective and faster to deploy.

Truly secure and successful IoT ecosystems can only be achieved through collaboration, cooperation and partnerships. This strong belief extends beyond the ZARIOT/Atsign collaboration to include all those in the ecosystem.

ZARIOT promises not customer service, but partnership support to ensure successful integration and flexibility of new connected systems for the lifetime of devices.

The ACME team can address a wide range of challenges by combining the innovative

Atsign/ZARIOT technology and connectivity.

Continuing Innovation

For ACME, the open and transparent relationship unlocks a wider discussion on SIMs, with ACME engineers interested in the other applets ZARIOT could provide.

The answer is hugely open. In all devices that ZARIOT supports, the SIM is evolving to become even more embedded, support more flexibility, and to be utilized in more ways than ever before. ZARIOT is currently looking at how to open up the potential of the SIM to support overall solution design.

Custom functions tailored for the device or service can be developed by ZARIOT in combination with OEM or IoT solution owner.

Some additional applets are already available, such as the patented Anti-IMSI catcher applet which returns the widget back to a real network should it come under attack from a fake base station. Other applets are in development. More important to ACME is the openness to support the ACME devices directly with custom SIM development.

Flexible, Lifetime Collaboration

ZARIOT explains that they believe that the complexity of IoT means that cooperation and collaboration between experts from multiple disciplines and technologies is the only way to deliver a service.

This will only increase in the future, so ZARIOT makes available an ACME technical contact to work with them on development using not only the SIM but the other monitoring and analytic tools available on the network.

08. The Solution in More Detail

The ZARIOT/Atsign SIM applet provides:

A simple microcontroller API that IoT client applications can use to access the secure capabilities of the SIM when using TLS, DTLS and GBA protocols to secure an IP connection to an IoT service platform.

The properties of a common SIM application where the credentials (e.g. certificates / keys) associated with TLS or DTLS mutual authentication protocols can be stored and used by the IoT application

A common way for IoT service providers to initially provision (i.e. one time), and potentially update (i.e. dynamic management) their internet security credentials (e.g. certificates / keys) and policies within the SIM using over-the-air management capabilities.

Secured Information

Secure Exchange of Information
A method for the secure exchange of information only between known parties where the data can only be decrypted using the encryption secret keys held only by the respective parties.

Local and Remote Data
The atPlatform implementation allows the IoT device to persist data locally, notify others that there is data to be looked up and cached for access, and synchronise data with a remote service where the data is encrypted with keys that remain on the device.

All devices using the atPlatform always initiate the connection to the secondary server to communicate with each other. The IoT device data cannot be directly accessed externally, instead it can only communicate via other cryptographically validated endpoints.

Unique Data Access
Provides a kind of polymorphism wherein different information can be provided to different parties for the same lookup. For example, every IoT device could look up @ configuration-acme and each would only receive their particular response which only they can decrypt and even validate the provider is legitimate with nonrepudiation.

Provable Restricted Access
Where the data is cryptographically secured in such a way that it is provably true that intermediaries cannot access the data and only the recipient is able to.

Keys 

Bootstrapping
A method for bootstrapping a device using a shared nonce secret that is deleted after the RSA secret keypairs are cut on the device from which they never leave. In production, the only thing that is required to be added to the SIM are an atSign and a small shared secret.

Security Keys Self-Generated
Presents no production risk associated with the generation of security secrets as they are generated on the device itself, not created by some service during production or activation and then loaded onto it, leaving them open to risk of being tampered with or accessed.

Separate Key Pairs
Authentication and encryption are enforced by separate key pairs.

Increases Ease, Reduces Cost

Standalone Encryption
After provisioning, the proposed scheme can work with, but does not require the deployment of any gateways, VPNs or firewall configurations to provide true end-to-end encryption.

Definitions/Glossary

API (Application Programming Interface)
A connection or interface between computers or software to allow exchange of information, usually to support integration of functionality or support business processes.

Bootstrapping
The technique for producing a self-compiling compiler — that is, a compiler (or assembler) written in the source programming language that it intends to compile.

CRM (Customer Relationship Management)
The databases and processes a business use to interact with customers. Frequently the customer contact and history database used to manage ongoing interaction including marketing outreach is referred to as the CRM system.

Device Certificates
An electronic or digital signature embedded into a hardware device, that enables mutual authentication and secure connections between two devices.

DoS (Denial of Service)
A denial-of-service attack (DoS attack) is a cyber-attack in which the perpetrator seeks to make a machine or network resource unavailable to its intended users by temporarily or indefinitely disrupting services of a host connected to a network.

eUICC (electronic Embedded Universal Integrated Circuit Card)
A software stack which allows for remote provisioning of mobile operator profiles over-the-air, effectively changing the mobile operator, it ‘belongs to’ without changing the SIM card in a device.

 Endpoint
Any connected device or node that communicates across the network. e.g. IoT Thing, laptop, phone, router or switch.

End-to-End Communication Encryption (DTLS)
Ensures the data between a Client and Server is encrypted during transport. After decryption by the Server, information is exposed and in the clear.

 End-to-End Data Encryption (The atPlatform, RSA PKI & AES 256)
The secure exchange of information only between known entities meaning that only the originator and intended recipient are able to access the data.

GDPR (General Data Protection Regulation)
This is a regulation in EU law on data protection and privacy in the European Union and the European Economic Area. These regulations require strict controls on how data is collected, stored and used. Violations of these regulations carry enormous fines and penalties. used. VIolations of these regulations carry enormous fines and penalties.

GSMA IoT SAFE (IoT SIM Applet For Secure End to End Communication)
Developed by the mobile industry, IoT SAFE (IoT SIM Applet For Secure End-2-End Communication) enables IoT device manufacturers and IoT service providers to leverage the SIM as a robust, scalable and standardised hardware Root of Trust to protect IoT data communications.

HIPAA (Health Insurance Portability and Accountability Act)
United States legislation that provides data privacy and security provisions for safeguarding medical information.

IMSI (International Mobile Subscriber Identity)
A number that uniquely identifies every device on a cellular network.

IMSI Catcher
An IMSI catcher is a device that appears to a mobile device as a cell tower (base station). The IMSI catcher is able to locate, track and effect all mobile phones and devices that are in its vicinity, When the device attaches to the fake base station, it detaches from the real network and effectively loses service and cannot be reached. In some circumstances the device can be forced to use previous less secure earlier generations of the cellular network e.g. 2G making data interception possible.

LAN (Local Area Network)
A network that interconnects computers and devices within a limited area, such as a residence, school, or office building, such as WiFi and BlueTooth.

Licensed Spectrum
“Spectrum” refers to the radio frequencies that carry wireless signals. Governments manage

spectrum use, and spectrums can be unlicensed, meaning anyone can use the frequency, or licensed, bought for exclusive use by specific providers. GSM or Cellular spectrums are licensed, whereas networks like LoRa and Sigfox are unlicensed.

 LPWAN (Low-Power Wide-Area Network)
A type of wireless telecommunication wide area network designed to allow long-range communications at a low bit rate among things, such as sensors operated on a battery. Sigfox and LoRa are examples of LPWANs.

 Nonce secret
Nonce (number once) is an arbitrary number that is used just once in a cryptographic communication.

Penetration Testing
A penetration test, colloquially known as a pen test or ethical hacking, is an authorized simulated cyberattack on a computer system, performed to evaluate the security of the system; this is not to be confused with a vulnerability assessment.

 Provisioning
The supplying of service to the network elements or device, connected to the mobile network.

Root of trust
Highly reliable hardware, firmware, and software components that perform specific, critical security functions. Because roots of trust are inherently trusted, they must be secure by design. Roots of trust provide a firm foundation from which to build security and trust.

RSA
RSA is a public-key cryptosystem that is widely used for secure data transmission. It is also one of the oldest. The acronym “RSA” comes from the surnames of Ron Rivest, Adi Shamir and Leonard Adleman, who publicly described the algorithm in 1977.

Service Activation Portal
This is used to orchestrate the enrolment of the device with AWS IoT Core, Azure IoT Hub (and soon Google Cloud) and to download the operational endpoint in the case of open market devices.

SIM (Subscriber Identity Module)
The module in a device that allows communication with the mobile network. It serves to identify and authenticate the device, and can also be used to store data. SIMs are traditionally referred to as SIM “cards” however new varieties of SIM are embedded (hardwired) to the circuit board of the device.

SIM Applet
A small application hosted on the SIM that performs a specific task supporting the wider software functionality.

 SIM Profile
The configuration file used to enable mobile network connectivity and functionality. Multiple profiles can be stored on eUICC SIMs allowing the device to switch mobile operators or enabled additional functionality or applets.

Secondary Servers
atPlatform solution proxy providing the central point of communication for all atSign enabled devices, services, or users.

TLS Client
Client side of Transport Layer Security (TLS) a cryptographic protocol designed to provide communications security over a computer network.

TLS Server
Server side of Transport Layer Security (TLS) a cryptographic protocol designed to provide communications security over a computer network.

TPM (Trusted Platform Module)
Also known as ISO/IEC 11889, is an international standard for a secure crypto processor, a dedicated microcontroller designed to secure hardware through integrated cryptographic keys.

 VPN (Virtual Private Network)
Protected information system link utilizing tunnelling, security controls, and endpoint address translation giving the impression of a dedicated line.

Zero Trust
Zero Trust is a security framework requiring all users, whether in or outside the organization’s network, to be authenticated, authorized, and continuously validated for security configuration and posture before being granted or keeping access to applications and data. Zero Trust assumes that there is no traditional network edge; networks can be local, in the cloud, or a combination or hybrid with resources anywhere as well as workers in any location.

Overview

Securing data sharing between multiple businesses is extremely difficult today, because it needs to be addressed at the networking level, often by spinning up separate cloud services for sharing the data. However, there are new technologies that can make this much easier and more secure by abstracting data sharing away from networking. Using Atsign’s Networking 2.0 technology, the time-to-market on your next data sharing project can be drastically reduced, allowing you to be far more agile than your competitors – all while providing better data protection and security.

Why Is Sharing Data So Hard?

Privacy legislation such as the General Data Protection Regulation (GDPR) in Europe and the California Consumer Privacy Act (CCPA) have made enterprises more responsible for the data that they collect, share, and store. At the same time, the world is becoming more collaborative, and Internet of Things (IoT) devices are generating far more data than ever before. All this at a time when the instances of ransomware are skyrocketing. Oftentimes, subsets of that data need to be shared among multiple companies. When using the current (Networking 1.0) approach, sharing this data securely with multiple parties has become a nightmare with substantial costs and huge security risks.

Networking 1.0 – An Outdated Data Sharing Model

Companies typically follow these steps:

1. Set up a shared database server. Often in the cloud in the form of data lakes or data warehouses, with some enterprises using demilitarized zones (DMZs) for this purpose.
2. Set up security for that server through firewalls and figure out access (often through VPNs) for both parties.
3. Configure an authentication service to make sure the right people from both companies are the ones actually accessing the data.
4. Figure out how to keep the data updated by both parties through some synchronization to their internal databases. Many enterprises use Extract, Transfer, Load (ETL) technology for this purpose.

This method is extremely costly to manage and maintain moving forward. Additionally, there are extra monitoring layers that must be added to make sure the data is not being compromised.

Client/server data sharing

Needless to say, the time to set all this up and get it working is substantial. The only thing that has changed about this architecture in the last 20 years is moving it from in-house to the cloud, it is still very complex to set up and maintain securely.

Now imagine this scenario where there are multiple companies involved. Imagine wanting to send subsets of sensor data to different vendors. For example, if you run a smart city you may want to send data from traffic lights to a third party vendor that is helping you with traffic control. But there is also a subset of data from those lights that needs to go to the vendor providing maintenance. Camera data from the lights needs to be routed to the citations and violations department. The bottom line is that you definitely don’t want all data being captured going to all other vendors. 

Setting up a server-centered architecture for this extremely complex scenario is challenging even for the most highly skilled IT staff. Using Networking 1.0, the city example above might look something like this:

Client/Server data sharing – Smart City example

Now imagine adding four or five more vendors to this scenario. It is not scalable or sustainable.

Introducing Networking 2.0

The Era of IT Simplification

Nick Lippis of ONUG notes that, “The IT industry is entering a transformative phase focused on simplification. This shift is a response to the complexity that arose from the overbuild during the 2020-2021 phase. The rapid expansion in IT infrastructure during this period has resulted in systems that are now overly complex and challenging to manage, necessitating a streamlined approach.”¹

The era of blockchain technology brought us decentralization, but it was both complex and resource intensive. Networking 2.0 brings us a simplification of decentralization and an abstraction from the network itself, delivering both quick deployments and privacy. 

If You Can Map It, You Can Build It: Streamlining Data Flows For Business Agility

Networking 2.0 technology makes it possible to directly address any person or device on the network. By using Networking 2.0 technology, the data sharing is completely abstracted from the network architecture which substantially decreases costs and time-to-market, all while increasing security and data privacy. Permission is attached to the data itself, and subsets of the data can be unlocked for different parties depending upon their assigned access credentials. All this is as easy to set up as mapping out which data goes to which vendor.

New Advances In Data Sharing

Controls

This data control can go even further by setting time controls on the data itself. The data could be shared for a limited period of time with share dates and expiration dates built in. This is particularly useful for AI model training.

Real Time Updates

This model requires no additional duplication or synchronization of data, allowing for real time updates from the source to be propagated instantly.

How Atsign Makes It Easy – Leveraging Networking 2.0 Architecture

With Atsign® technology, every vendor and every device has a unique, self-controlled identifier called an atSign. Each atSign has a Personal Data Service (PDS) called an atServer–a PDS for everything including people, entities, and things–where the encrypted data is stored, and each device has a public/private key pair that is cut out on the edge, so the keys for the encryption are on the device and not centralized where they could otherwise be compromised. The data subsets are uniquely encrypted for each atSign, so everything is encrypted from the device to its final destination. The atDirectory provides the location of all the atServers on the network.

Atsign’s Networking 2.0 Architecture: Peer-to-Peer end-to-end encryption

With this distributed model you can quickly and easily map data flows, and ensure that the right data always gets to the right party. There is no need for an additional authentication service as Zero Trust is built into the Atsign technology, resulting in better security.

Here is an example data map for a smart city:

Data flow map for smart city with multiple vendors

Adding more vendors in the data flow above is simple, expedient, and inexpensive.

These data flow maps work for multiple industries. Here is a mining example:

Data flow map for mining

Here is a healthcare example:

Data flow map for healthcare

Leveraging Atsign’s Networking 2.0 technology for data sharing and integrity provides the following benefits:

Business:

• Drastically reduced set up time, fast implementation
• Better data stewardship and lower liability concerns
• Far better data security and privacy
• Consistently up-to-date data
• No data silos or data duplication

IT Staff

• Little to no costs for IT staff
• Far better data security

There is no need to replace existing systems to implement this streamlined secure data sharing. Atsign technology lives alongside existing networks, offering frictionless time-to-market on a new project. Explore open-source SDKs from Atsign and contact info@atsign.com for in-depth guidance.

¹https://onug.net/blog/the-it-industrys-new-era-of-simplification/

Dear Reader,

In today’s digital world, the challenges of securing networks and communication have become more critical than ever. At Atsign, we recognized that existing approaches to network security often add layers of complexity without adequately addressing the root problems. This white paper represents our effort to share a fundamentally different approach to these issues—one that addresses security at the lowest possible level while enabling scalability, simplicity, and resilience.

NoPorts uses our core technology, the atPlatform, to eliminate the need for open network ports, the entry point for cyberattacks. By fundamentally rethinking network communication, we’ve created a zero trust, privacy-first environment that empowers organizations to embrace digital transformation without compromising security.

Sincerely,

Colin Constable
Co-Founder & CTO, Atsign, Inc.

Executive Summary

Traditional network security solutions, including VPNs, firewalls, and today’s “zero trust” models, often introduce complexity and overhead while failing to address a major root problem: open network ports that expose systems with unencrypted or private data to anyone or anything on the Internet (or any IP network). Atsign’s innovative approach leverages a global namespace, secure communication protocols, and a robust zero trust framework to:

• Eliminate Open Ports – Reduce the attack surface significantly.
• Enhance Security – Employ end-to-end encryption, ephemeral keys, and customer-generated cryptographic keys.
• Simplify Network Management – Streamline operations, simplify firewall rules, and reduce costs.
• Prioritize Privacy – Protect sensitive data and privacy.

NoPorts makes network infrastructure and devices invisible, creating a formidable defense against cyber threats. You can’t attack what you can’t find.

The Challenge of Traditional Network Security

Modern networks are increasingly complex, with a proliferation of IoT devices, cloud services, and remote access needs. Traditional security measures, such as firewalls and VPNs, add more complexity and often fall short, leaving organizations vulnerable to attacks. Even solutions like Zero Trust Network Access (ZTNA), Secure Access Service Edge (SASE), Security Service Edge (SSE), and Cloud-Based Security Deployment (CBSD) are incomplete solutions as they too leave network ports open.

Despite a surge in spending on traditional cybersecurity methods, with Statista reporting a 78% increase from 2018 to 2023, the financial impact of cybercrime continues to skyrocket, highlighting the limitations of traditional defensive methods.

Source: Statista.com Worldwide Cybersecurity Spending and Cost of Cybercrime

The sheer number of open ports worldwide underscores the vulnerability of traditional network security approaches. According to Shodan, there are over 703 million open ports, excluding common ports like 80, 443, and 25. This vast attack surface presents a prime opportunity for cybercriminals.

Source: Shodan.com on November 6, 2024

Atsign’s NoPorts Approach

Instead of securing networks by adding layers of complexity, Atsign built a new protocol, the atProtocol, that works on existing TCP/IP networks, and fundamentally changes network communication and security. 

NoPorts was designed on Atsign’s atPlatform, which consists of three key pillars:

• Global Namespace – Every person, device, and entity is assigned a unique, globally addressable identity (an atSign), enabling direct communication without relying on IP addresses or complex network configurations.
• Secure Communication – The atProtocol ensures secure, end-to-end encrypted communication between devices, eliminating the need for open ports.
• Zero Trust Framework – Atsign’s zero trust model enforces strict access controls, ensuring that only authorized entities can communicate.

How it Works

1. Software Installation – NoPorts operates using a lightweight software binary that is installed in the user space on devices, whether it’s a client, server, or IoT device.
2. Key Generation and Management – Devices generate cryptographic keys locally or on the edge, minimizing the risk of compromise.
3. Identity Verification – All connection requests are authenticated using public-key cryptography. Once trust is established, NoPorts uses a peer-to-peer connection.
4. Directory Lookup – Devices use the directory service to discover other devices based on their atSigns, a unique, human-readable character string that is used as an address and provides a unique, consistent identity across the network.
5. Secure Connection – The relay service establishes secure, encrypted connections between devices using ephemeral keys.
6. Access Control – The policy engine enforces granular access controls based on identity and context.

Benefits of NoPorts

• Enhanced Security – Reduced attack surface, strong encryption, and zero trust architecture.
• Simplified Network Management – Eliminates the need for complex network configurations (ex: firewalls only need one rule, reject all inbound traffic) reducing operational overhead.
• Increased Scalability – Easily accommodates growing numbers of devices and users.
• Improved Privacy – Protects privacy and sensitive data while in transit or at rest.

NoPorts: A New Era of Network Security

NoPorts offers a compelling solution to the challenges faced by organizations today. By adopting a zero trust, privacy-first model and eliminating open ports, NoPorts empowers organizations to build more secure, efficient, and scalable networks.

Both the atPlatform and NoPorts follow the architectural rule of never having ports open where there is anything of value, ports are only open where data is either public or where data is encrypted with keys that infrastructure never has.

Use Cases

Securing Sensitive Data in the Cloud

A leading cloud provider is working with Atsign technology to address the challenges faced by government agencies, particularly the Department of Defense and Intelligence Community, when securely sharing sensitive data. This collaboration focuses on solutions for:

• Reduced Visibility – Making remote government assets invisible on the internet, minimizing potential attack surfaces.
• Enhanced Data Security – Enabling secure data transfer without exposing data or opening ports on the network.

This approach significantly reduces both operational complexity and security vulnerabilities.

Here’s how NoPorts works in this context:

• atSign Identity – Cloud services authenticate with a unique identifier, ensuring only authorized users or services can communicate.
• Relay Service – This acts as a broker, facilitating communication between services without relying on traditional methods like VPNs.
• Policy Engine – This enforces access control rules, ensuring only authorized data exchanges occur.

By combining these elements with a zero trust framework, NoPorts allows seamless and secure communication across diverse environments while minimizing the risks associated with open network ports.

Securing Remote Access for Private 5G Networks

Managing private 5G networks often involves scattered transmitters that require secure remote access for troubleshooting and updates. Traditionally, “backdoor” access points are created, leaving networks vulnerable to breaches. Atsign’s NoPorts offers a secure solution. By installing NoPorts software on each Radio Access Network, technicians can access them remotely with zero exposed ports and strong cryptographic authentication. This ensures only authorized devices can connect, maintaining the privacy and security of the entire private 5G network.

Securing AI at the Edge

Deploying AI models across multiple edge devices for real-time video analysis often involves complex network configurations, VPNs, and open ports to securely transmit data to a central server. NoPorts simplifies this process by allowing AI-enabled edge devices to communicate directly with a host server using the atProtocol, eliminating the need for open ports. NoPorts’ zero trust model ensures data encryption and contextual access control, significantly enhancing security and privacy. This streamlined approach reduces deployment complexity while maintaining robust security measures.

Secure Data Sharing and APIs

A healthcare data sharing platform provides a secure and efficient way for hospitals, care providers, and insurers to seamlessly share data. Atsign’s atPlatform provides the foundation for this platform, ensuring best-in-class privacy and security, but more importantly, easy integration. IT hospital staff understand the importance of securing data. This can significantly slow down data sharing with other healthcare organizations because it often requires network changes and configuration. With the atPlatform, hospitals can be exchanging data with other verified healthcare providers within a matter of minutes, with no IT burden or intervention.

Appendix – More Technical Detail

Atsign Architecture and Components

NoPorts is built upon the atPlatform which consists of the following components:

• atProtocol® – The foundation of Atsign’s architecture, enabling the secure, end-to-end encrypted exchange of data without open ports or static IP requirements. It facilitates secure, peer-to-peer communication with minimal configuration.
• atServer – The atServer is responsible for managing identity and maintaining the key-value data store for each atSign (Atsign address). It performs cryptographic identity validation to ensure that each entity is who they claim to be, supporting secure interactions. It serves as a secure repository and only holds data that is either public or data that is encrypted with keys it never has.
• atDirectory – The atDirectory service helps in locating atServers across the network. It functions like a distributed phonebook, providing the necessary information to facilitate communication to atServers (DNS address and port number).

Additional NoPorts Components

• Relay –  Provides a TCP session rendezvous point over which encrypted traffic can flow between two endpoints.
• Policy Engine – The policy engine governs access decisions based on identity, context, and pre-defined rules. It ensures that all communication abides by zero trust principles, meaning that no entity is inherently trusted, and all access is explicitly granted based on policy rules. This granular control ensures that client/server communication remains secure and is only accessible to authorized entities.

By integrating these components, Atsign provides a control mechanism that keeps all devices invisible to attackers. The use of asymmetric encryption, dynamic session management, and identity-based directory services ensures that devices can communicate without exposing their network details. This approach minimizes attack surfaces and mitigates risks associated with open ports and static IP addresses.

Zero Trust Framework

Atsign’s zero trust model encompasses the entire communication flow, ensuring that no device or entity is inherently trusted. Access is granted based on identity verification and contextual access policies. 

Atsign’s zero trust approach is embedded across the data, control, and policy planes:

• Data Plane – All communication and data transfers are end-to-end encrypted, ensuring that data is private and secure at all times.
• Control Plane – The control mechanism dynamically manages connectivity without relying on static IP addresses or open ports, utilizing cryptographic techniques such as asymmetric key exchanges.

Policy Plane – Access control is governed by identity and contextual factors, ensuring a granular level of control over who or what can access each resource.

How It Works

Software Installation and Key Management

NoPorts operates using a lightweight software binary or library that is installed in the user space on devices or as a container, whether it’s a client, server, or IoT device. Once installed, the first step is generating cryptographic keys—often referred to as “cutting keys.” These keys are created directly at the edge, on the device itself, ensuring that private keys never leave the originating device. This significantly enhances security, as sensitive key material is not transmitted over the network or stored in centralized repositories. This also removes the need for SSL/TLS certificates on edge devices.

Connecting to the atServer

The atServer plays a key role in identity management. When a device or client wants to establish a connection, it authenticates itself using the public and private key pair it generated during the setup. The atServer maintains a secure key-value data store for each identity, holding the public key while the private key remains on the device. This identity verification step ensures that each entity attempting to connect is legitimate and authorized.

Directory Lookup

Once a device has authenticated, it may need to communicate with another device or server. The Directory service assists in locating the atSign identity of the intended target. The Directory functions much like a distributed phonebook that allows devices to discover each other without ever exposing IP addresses or network details of the client, instead delivering the atSigns atServer DNS Address and Port number.

Relay Setup and Secure Connection

The Relay service facilitates the connection between the two atSigns. Upon  receiving a request, the relay provides two random ports to the requesting atSign and starts listening on those ports. When the two devices connect to those ports, the Relay authenticates using PKI (public key infrastructure) and connects the two TCP connections. The relay never possesses the ephemeral symmetric key that the client and device use to communicate, which means it can never see the data being exchanged.  As the connections are terminated at the relay neither device ever needs open ports.

Access Control via Policy Engine

The Policy Engine is responsible for determining whether a connection should be allowed. When one device attempts to connect to another, the receiving device sends the request to the policy engines atSign.The Policy Engine checks predefined rules based on the identity and contextual information such as location, time, and type of request. The policy engine sends back a binary decision to the device and the connection is made or ignored. By using a zero trust model, the Policy Engine requires explicit verification for each connection, ensuring that only authorized communications are permitted. This further reduces risk, as every action must be validated.

Keys and Encryption

The keys used for communication in NoPorts include a combination of long-term identity keys (used for authentication) and ephemeral session keys (used for each communication session). The public key is stored at the atServer for identification, while the private key remains on the device. Each session’s ephemeral keys ensure that the communication remains secure and that keys are discarded after the session, reducing the potential for compromise.

All data transferred between devices is encrypted end-to-end using AES encryption (AES256 CTR), making it unreadable to anyone who does not possess the correct session keys. The key exchange process itself uses asymmetric encryption (RSA 2048), adding another layer of security to the setup of secure sessions.

The encryption algorithms used can be changed or extended as the whole of the atPlatform uses an abstracted encryption and hashing library. The underlying atProtocol is independent of the encryption layer so is forward compatible with any future encryption algorithm or technology, including quantum and quantum resistant schemes.

Closed Ports and Attack Surface Reduction

NoPorts eliminates the need for open ports like 22 (SSH) or 3389 (RDP), which are entry points for cyberattacks. By removing the requirement for open ports, the attack surface is significantly reduced, as potential attackers cannot scan for or exploit open ports to gain access to devices. All data layer connections are established through relays, with no ports exposed on the client or device to the Internet, thereby massively improving the overall security stance.

Additional Resources:

• NoPorts Documentation
• NoPorts GitHubRepository
• Atsign’s OpenSSF Scores (includes atServer & NoPorts reports)
• atProtocol Patent

A Brief Overview of the atPlatform 

Who hasn’t been frustrated with physically changing addresses? You are moving and not only do you have to deal with all the hassle of boxing up your things, you have to arrange for all your mail to be sent to the new address. Then the digital address changes are even more brutal. All the companies that you do business with, friends, acquaintances, family members – how many hours will it take you to update them all? And those are just the ones you remember! 

This is due to a fundamental architecture problem: the replication of your data across the internet, where everyone else owns it, except you. When something changes, you have to log into each different platform and manage whatever version of the data that company has. 

Here is today’s Internet architecture:

APPS own the data. 

Here are the problems this architecture causes developers/companies: 

• You must build and pay for a database to hold all the data 
• You are liable for and have to protect the data 
• You have to encourage your customers to keep their data up-to-date 
• You have to comply with constantly changing privacy laws surrounding the data 
• You have to help your customers manage their usernames and passwords 
• You want to use end-to-end encryption, but key management is challenging 

What does the next generation look like?

This is the atPlatform, where YOU own the data.

Everyone has a unique atSign and their own datastore tied into their phone and replicated in the cloud.

For the company/developer, this provides: 

• Automatic compliance to all privacy legislation 
• Less liability 
• Less, and in many cases, no infrastructure requirement, therefore substantial cost savings 
• Less support overhead because you don’t need to manage usernames and passwords 
• 30-50% faster time to market since you don’t have to build a user data structure 
• An easy way to create new peer-to-peer, end-to-end encrypted apps 
• A way to create new experiences for customers because the protocol is polymorphic