State of Urgency for Distributed Systems
The 2021 Texas power-grid failure is only the latest in a series of major humanitarian events around the world that underscore the decisive need for community-centric, peer-to-peer, and distributed communications systems. As a USAF intelligence operations veteran, my experience with mission critical systems comes from being a security manager, working with Combat Search and Rescue (CSAR) helicopter pilots, and supporting medical evacuation operations in remote locations.
With these scenarios in mind, our work at PLAN Systems is aimed at designing systems for real-time collaboration & information visualization that can be relied on by not only first responders, but also educators, wellness networks, and local neighborhoods. Now that much of the critical information flows and essential services run on software, it's far past time to get serious about network security and resilience at local levels.
Img. 2: A Space Channel is a 3D container for other types of channels (data compartments) and glyphs (2D-3D icons / models).
The Impact of Distributed & Real-time Systems
Recently here in Texas, nearly 4 million people found themselves in freezing cold temperatures without power for over 5 days. Community members scrambled to provide care and assistance to those in need during this historical outage. Much of the organization we saw was coordinated via online social media networks. However, with power outages limiting access to internet service, some were left completely disconnected from the aid so desperately needed. The systemic grid failure proved the necessity of a more robust communication and organization infrastructure.
What was needed and what we are building is PLAN; including realtime maps, secure messaging, and spatial planning capabilities that will give community organizers the ability to rapidly mobilize to assist those in need. Employing a distributed and peer-based system like PLAN means that even when the power goes out, there is a local alternative to centralized servers or cell phone towers (which may not be accessible).
Traditionally, that void is filled by HAM radio, which requires special hardware, training, and technical operation. These factors make HAM radio largely inaccessible for practical use for most communities, and they do not offer information visualization, or a way of easily operating with modern hardware devices and smartphones.
Img. 3: First Responders Module - PLAN modules make it possible to add custom 3D content and environments to Spaces.
With a decentralized and peer-to-peer approach like PLAN, critical services and information would be made redundant and accessible by adjacently operating nodes to help compensate for short or long term outages. We also wouldn’t have to trade off safety or privacy in the case where rescues are being coordinated on a corporate platform designed to monetize that content.
With peer-to-peer decentralization, volunteers running off of generators or battery power would have the ability to host an entire neighborhood support network, and quickly coordinate the haves and needs of nearby residents. In fact, future power grids could be revamped entirely to operate off of very similar distributed protocols in order to distribute the power infrastructure itself in a much more robust and intelligent manner.
PLAN Systems is pioneering peer-to-peer and distributed systems to connect and secure a community's network. PLAN infrastructure includes a highly pluggable interface that is designed to continue operating even in low-bandwidth conditions or when disconnected from the internet entirely. I cannot underscore enough just how important capabilities like this are when it comes to ensuring survivability of vital support networks. Real-time and peer-based communications can save lives and help keep communities comfortable and secure even in the face of crisis. It's time to create resilient communities that are able to weather any storm.
PLAN Engineering Update
-
- Node infrastructure system
- "Visor" / HUD interactive interface (UI/UX) system
- Standard "out of the box" Channel templates, content, and usability, offering any group, community, or organization immediate value
BRINGing 2d and 3D interfaces together in immersive spaces and environments.
Img. 4 & 5. 3D Imagery and floorpans serve an essential role in the spatial planning process.
An Extensible 2D-3D Interface System
Let's dive into the three levels of PLAN's user interface system. Level 1 and (optionally) level 2 are contained in the forthcoming PlanSDK, which will deliver turn-key interfaces and infrastructure for building integrated 2D-3D environments. Level 1 consists of the node infrastructure system, which is the data "plumbing" that allows for securely communicating and staying in sync with active channels. The visor / hud interface system (level 2) is a flexible and pluggable interface solution that is designed to bring 2D and 3D content together and scale from mobile devices, multi-screen desktop arrays, to next generation augmented and mixed-reality (AR / MR) hardware.
Some projects or organizations may only want the visor UI and intend on developing their own menu system. Some projects may use both layers in order to have a turn-key way to store and access their community's data; or perhaps they start out with a single layer and then grow to add the others. The bottom line is that you don't have to understand how it all works to effectively utilize these tools and instruments for practical, everyday applications, such as organizing or volunteering on an industrial sized farm providing critical services to the community.
Img. 6: PLAN provisions for multi-tasking in integrated 2D-3D spaces with secure communications and archival storage.
Moving on to Level 3, this layer of PLAN consists of more complex channel implementations that are high-value for data compartments and visualizations; for example, a Space Channel. A Space Channel is simply a 3D container for other types of channels (data compartments) and glyphs (2D-3D icons / models). In other words, the PLAN app that we are developing is basically the PlanSDK on top of our own set of channel implementations, namely Space and NodeSpace Channels that integrate along with the PLAN Module subsystem. PLAN modules make it possible to add custom 3D content and environments, allowing even non-technical data organizers and designers to enhance and extend the user experience.
Level 3 isn't part of the PlanSDK, but it serves to demo what the infrastructure / channel system is capable of supporting. This model lets us drive adoption and bring in other sponsors & partners by offering a turn-key interface API solution that "just works." These solutions can be provided via a peer-to-peer market, the Unity asset store, or a self-hosted distribution. The other benefit is that this compartmented framework organizes the client engineering roadmap cohesively in order to unambiguously articulate a clear value proposition.
Security and Encryption Infrastructure
Let’s take a moment to get to know the security authentication flow in PLAN. Recognizing that securing communities and the data they rely on is essential, PLAN Systems has invested tremendous effort in developing an authentication model that respects identity sovereignty, while recognizing that communities need to shield critical information systems from bad actors, or recover a key when it's lost.
PLAN’s data-model compartments information for a “key fob” way of being, improving physical security of systems while easing the burden of manual password entry.
Img. 7: A tablet running the cross-platform PLAN app.
Img. 8: PLAN Software Design Principles - Total Data Ownership, Total Data Privacy, Community Centric Permissions, Off-grid Operation, Universally Accessible, Pluggable & Extensible, Gatekeeperss Infrastructure & Interfaces, P-2-P Redundancy, Hardware Agnostic and OpenSource, Native 2D-3D
Terminology:
- user: person using the PLAN app on Linux, macOS, Windows, iOS, Android, or other future supported platforms.
- community authority / admin: a PLAN community member or group that has been granted member administration security privileges such as adding and removing community members and resetting private keys.
- member: an identity in a PLAN community (analogous to an “account” on a traditional device OS). Members are only added to a community's internal registry channel when a community administrator digitally signs a proper invitation addressed to a given member. This also doubles as a persistent “paper” trail of who-invited-whom to the community (accountability). Only specific members have the access privilege to add new members.
- keyring: a container of keys that correspond to each security “epoch” of a community or community channel (the community member registry is itself a channel).
- epoch: demarcates use of a new set of key pairs to use for encrypting community or channel entries. [a key issue]
- latest community key: the most recently issued symmetric key issued by a community that PLAN uses to encrypt (persistent) community channel entries. New community key epochs are essential when removing/revoking community member access (note that the data vault store in principle is an append-only model).
- community keyring: a keyring that stores all the community keys issued by a community over time.
- pnode: the headless Go daemon (a modern data server) that serves the client (user interface) and is the “repo” (repository) for a set of communities or organizations where the user is a member. Our security model puts this on the same device as the graphical client because:
a. the security compartment is in lock-step with the client
b. Go is the preferable environment for handling keys and crypto
c. the more functionality within the pnode, the less that has to be duplicated in the 2D-3D front-end client
Real World Security Provisioning
Q: Why all this “epoch” and “keyring" terminology?
A: Real-world security provisioning. When Bob leaves his key fob at a cafe table or Alice's PC gets compromised, there is a standard operating procedure to recover their data without involving entities outside their community trust circles.
Img. 9: Mission planning on a mobile phone.
From Key Loss to Data Compromise
Shockingly, so few projects bring real-world security scenario into the discussion. For example, in Secure Scuttlebutt (SSB), you just have your private key and thats it. If you lose that or it gets compromised, every post you’ve ever made might as well as be from a stranger (or would be permanently hijacked if you got compromised). All the key access in (4) and (6) is via the device/local security enclave. Companies like Apple have also figured out the strategic importance of having a sealed and capable enclave abstraction allowing for enhanced security.
One of the key areas of development right now is the Vault, a secure & immutable distributed ledger that is a community's archive. We are continuing to consolidate and cleanup this core infrastructure as we get closer to getting the Vault in production. We believe the user authentication flow above is really at the heart of a proper “community OS”, allowing it to capture all the security benefits that crypto currencies enjoy. However, PLAN's “epoch” approach is a critical cut above any system that has not been designed for real-world security mistakes and incidents, such as key loss.
Hopefully it's becoming clear that a light-weight and dynamic system like PLAN is exactly what our emergency first responders, businesses, and communities all need. It comes with all the benefits of a simple protocol like Internet Relay Chat (IRC) which appeared in the 70s and 80s, then becoming a mission critical communications system for emergency and defense (DoD) applications. We hope that prospective sponsors and partners can see that we’re shining this value onto the general public and community for not just emergency situations, but also economic development, art and wellness building (rather than DoD projects).
Security & Authentication Flow
1. User steps to proximity of client device (iPad, phone, laptop, PC) and opens/activates the PLAN client (`plan-client-unity`)
2. Like a PC coming back from screensaver mode, PLAN issues a local challenge}
(a) If the user is on a key fob, she presses the button when it blinks
(b) If the user has a biometric fob, she uses her fingerprint, retina, etc
(c) If no fob, the container for the user keys comes from the local device if it’s still valid (or can prompt for an unlocking passcode, etc).
3. The challenge response is validated (in in the case of 2c, a password hive can now be open for access). So this is really the SKI in principle: access to the local device key repo/enclave. The end product is the local client being able sign and encrypt newly authored entries that get sent.
4. Now with an SKI session open, the client can process any new community entries that have arrived from the vault while the user was away:
(a) for each entry, decrypt the entry using the latest community key (or successively try older keys until one works). If the channel is private within the community (e.g. between for Alice and Bob and Charlie only), then decrypt the channel content based on the latest channel keyring epoch.
(b) verify that the sig on the entry validates with the latest pub key on the authors pub keyring in the community registry.
(c) unpack+merge the entry to the pnode’s channel repo (and propagate to the client if that client is subscribed to that channel).
5. Alice, sees a talk channel she has open populate with some new entries (messages from Bob in the this case) that are able to be merged and propagated to her client session.
6. Alice enters in a response to Bob in the channel. Let’s suppose this is a private channel in community ABC.
(a) The “channel adapter” (the front end pluggable UI component in Unity), in this case the Talk channel adapter, packages the Talk channel entry into a generic “Node” changeset that the client sends to the pnode.
(b) The pnode signs the entry using the member’s most recent/active key associated with their current member epoch.
(c) For a private channel, the entry is encrypted with the key associated with the channel’s latest ACL (security) epoch.
(d) The entry is encrypted with Alice’s latest community key (making the entry completely opaque to the outside world)
(e) The pnode sends the now-opaque entry to the community’s vault swarm.
Img 10: Immersive Education - Cave Builder
