Security and privacy
IBM Edge Computing Manager for Devices, based on Horizon, is as secure as possible against attacks and safeguards participant privacy. IBM Edge Computing Manager for Devices relies on geographically distributed autonomous agent processes and agreement bot (agbot) processes for edge software management and to maintain anonymity.
To maintain anonymity, the agent and agbot processes share only their public keys throughout the entire discovery and negotiation process for IBM Edge Computing Manager for Devices. All parties within IBM Edge Computing Manager for Devices treat each other party as an untrusted entity by default. The parties share information and collaborate only when trust is established, negotiations between the parties are complete, and a formal agreement is established.
Distributed Control Plane
In contrast to typical centralized Internet of Things (IoT) platforms and cloud-based control systems, the control plane of IBM Edge Computing Manager for Devices is mostly decentralized. Each role within the system has a limited scope of authority so that each role has only the minimum level of authority that is needed to complete associated tasks. No single authority can assert control over the entire system. A user or role cannot gain access to all nodes in the system by compromising any single host or software component.
The control plane is implemented by four different software entities:
- Horizon agents
- Horizon agbots
- Horizon exchange
- Horizon switchboard
Horizon agents and agbots are the primary entities and act autonomously to manage the edge nodes. The Horizon exchange and Horizon switchboard facilitate discovery, negotiation, and secure communications between the agents and agbots.
Horizon agents outnumber all of the other actors in IBM Edge Computing Manager for Devices. An agent runs on each of the managed edge nodes. Each agent has authority to manage only that one, single, edge node. The agent advertises its public key in Horizon exchange, and negotiates with remote agbot processes to manage the local node's software. The agent only expects to receive communications from the agbots that are responsible for deployment patterns within the agent's organization.
A compromised agent does not have any authority to affect any other edge node, or any other component of the system. If the host operating system, or the agent process on an edge node, is hacked or otherwise compromised, then only that edge node is compromised. All other parts of the IBM Edge Computing Manager for Devices system are unaffected.
The edge node agent can be the most powerful component of an edge node, but is the least capable component for compromising the security of the overall IBM Edge Computing Manager for Devices system. The agent is responsible for downloading software onto an edge node, verifying the software, and then running and linking the software with other software and hardware on the edge node. However, within the overall system-wide security for IBM Edge Computing Manager for Devices, the agent has no authority beyond the edge node where the agent is running.
Horizon agbot processes can run anywhere. By default, the processes run automatically. Agbot instances are the second most common actors in Horizon. Each agbot is responsible for only the deployment patterns that are assigned to that agbot. Deployment patterns consist primarily of policies, and a software service manifest. A single agbot instance can manage multiple deployment patterns for an organization.
Deployment patterns are published by developers in the context of an IBM Edge Computing Manager for Devices user organization. The deployment patterns are served by agbots to Horizon agents. When an edge node is registered with Horizon exchange, a deployment pattern for the organization is assigned to the edge node. The agent on that edge node accepts offers only from agbots that present that specific deployment pattern from that specific organization. The agbot is a delivery vehicle for deployment patterns, but the deployment pattern itself must be acceptable to the policies that are set on the edge node by the edge node owner. The deployment pattern must pass signature validation, or the pattern is not accepted by the agent.
A compromised agbot can attempt to propose malicious agreements with edge nodes and attempt to deploy a malicious deployment pattern on edge nodes. However, the edge node agents accept agreements for only the deployment patterns that the agents requested through registration and that are acceptable to the policies that are set on the edge node. The agent also uses its public key to validate the cryptographic signature of the pattern before it accepts the pattern.
Even though the agbot processes orchestrate software installation, and maintenance updates, the agbot has no authority to force any edge node or agent to accept the software that the agbot is offering. The agent on each individual edge node decides what software to accept or reject. The agent makes this decision based on the public keys it has installed, and the policies that are set by the edge node owner when the owner registered the edge node with Horizon exchange.
Horizon exchange is a centralized, but geographically replicated and load balanced, service that enables the distributed agents and agbots to join and negotiate agreements. For more information, see Overview of how IBM Edge Computing works.
Horizon exchange also functions as a shared database of metadata for users, organizations, edge nodes, and all published services, policies, and deployment patterns.
Developers publish the JSON metadata about the software service implementations, policies, and deployment patterns that they created into Horizon exchange. This information is hashed and cryptographically signed by the developer. Edge node owners need to install public keys for the software during the edge node registration so the local agent can use the keys to validate the signatures.
A compromised Horizon exchange can maliciously offer false information to agent and agbot processes, but any impact is minimal due to the verification mechanisms that are built in to the system. Horizon exchange does not possess the credentials that are required to maliciously sign the metadata. A compromised Horizon exchange cannot maliciously spoof any user or organization. Horizon exchange acts as a warehouse for the artifacts that are published by developers, and by the edge node owners, for use in enabling agbots during the discovery and negotiation process.
The Horizon switchboard mediates and secures all communications between the agents and agbots. Horizon switchboard implements a mailbox mechanism where participants can leave messages that are addressed to other participants. To receive messages, participants must poll the Horizon switchboard to see whether their mailboxes contain any messages.
Both agents and agbots share their public keys with the Horizon switchboard to enable secure and private communications. When any participant needs to communicate with another, that sender uses the intended recipient's public key to identify the recipient. The sender uses that public key to encrypt a message to the recipient. The recipient can then encrypt their response by using the public key of the sender.
This approach ensures that the Horizon switchboard is incapable of eavesdropping on messages because it lacks the necessary shared keys to decrypt the messages. Only the intended recipients can decrypt the messages. A corrupted Horizon switchboard has no visibility into the communications of any participant, and is incapable of inserting malicious communications into any conversations between participants.
Denial of the central services
Horizon relies on two centralized services, Horizon exchange and Horizon switchboard. Centralized services in typical Internet of Things systems are generally vulnerable to denial of service attacks. For IBM Edge Computing Manager for Devices, these two centralized services are used only for discovery, negotiation, and update tasks. The distributed and autonomous agent and agbot processes use the centralized services only when the processes must complete discovery, negotiation, and update tasks. Otherwise, when agreements are formed, the system can continue to function normally even when those centralized services are offline. This behavior ensures that IBM Edge Computing Manager for Devices remains active if there are attacks on the centralized services.
Most of the cryptography in IBM Edge Computing Manager for Devices is based on asymmetric key cryptography. With this form of cryptography, you and your developers must generate a key pair, and use your private key to cryptographically sign any software or service that you want to publish. You must install your public key on the edge nodes where the software or service needs to be run so that the cryptographic signature of the software or service can be verified.
Agents and agbots cryptographically sign their messages to each other by using their private keys, and they use their counterpart's public key to verify the messages that they receive. The agents and agbots also encrypt their messages with the other party's public key to ensure that only the intended recipient can decrypt the message.
If the private key and credentials for an agent, agbot, or user are compromised, only the artifacts that are under the control of that entity are exposed.
By using hashes, cryptographic signatures, and encryption, IBM Edge Computing Manager for Devices secures most parts of the platform against unwanted access. By being mostly decentralized, IBM Edge Computing Manager for Devices avoids exposure to most attacks that are typically found in more traditional Internet of Things platforms. By constraining the scope of authority and influence of participant roles, IBM Edge Computing Manager for Devices contains the potential damage from a compromised host, or compromised software component to that part of the system. Even large-scale external attacks on the centralized services of the Horizon services that are used in IBM Edge Computing Manager for Devices have minimal impact on the participants that are already in agreement. The participants that are under a working agreement continue to operate normally through any disruption.